In alchemy, albedo is the second of the four major stages of the magnum opus...[1] ... This phase is concerned with "bringing light and clarity to the prima materia (the First Matter)".[2] In this process, the subject is divided into two opposing principles to be later coagulated to form a unity of opposites… [3]
» Wikipedia
Blockchains seek to provide independence from centralized institutions for an individual. Yet these same blockchains end up being run by the same greed that is running the centralized institutions. This is exemplified by the fact that most blockchains and DAOs built on them distribute political power and the rights to produce blocks in their consensus protocols based on distribution of some resource valued by the market and the distribution of that resource of course follows a Pareto distribution. Those who already have the resource and power, are getting more of it, and so on. The elephant in the room in the blockchain space is that blockchains are not that decentralized.
Naturally, some people in the blockchain space have got enough of this. Enter ƒractally. It is a design for DAOs (called fractals in ƒractally), where power is distributed to individuals based on their contributions in the eyes of other members. Thus power is derived directly from the people instead of being distributed based on some resource (token or hardware power). It is a new type of democracy and a new type of DAO that tries to avoid the pitfalls of both.
Ƒractally community faces a problem though. It needs a blockchain. However building on existing blockchains is problematic, because that would make ƒractally democratic governance process dependent on non-democratic token-weighted governance that is running the underlying blockchain. It could launch its own blockchain. That would work if everyone would trust people in the fractal that is running the blockchain. But, however good the governance process is, the outcome won't be better than the intentions of people running the process. Therefore, it would probably be naive to expect that all of the crypto community will accept any blockchain run by any fractal. Furthermore, the same problem will have to be faced by every new fractal - should every new fractal launch its own blockchain? Or should it use a blockchain run by an existing fractal? Fractals will not necessarily have aligned interests just because they are run by the same governance process. So fractals depending on other fractals blockchain might also be undesirable.
Ƒractally DAOs of course want to be accepted by the crypto community and it wants easy interoperability between many different ƒractals. That's how it can attract more people, and in general - it is hard to imagine how a community could flourish if it is isolated. Therefore DAOs built using ƒractally process need communication and interoperability with the rest of the blockchain world in order to flourish. At the same time, if ƒractally is successful, existing blockchains have a lot to gain too. There's huge potential for synergy, if we are just able to create a conditions in layer 1 blockchain, that would work for both sides.
The purpose of this post is to suggest a vision for how this synergy could eventually be achieved. If this vision is fulfilled, it would bring value not just to BPs of traditional blockchains and ƒractally DAOs. It would also make the consensus process of underlying blockchains more decentralized, which provides security for the average blockchain user.
Step 1: Separate a DAO from the platform (blockchain) it uses
The definition of a DAO (decentralized autonomous organization) as outlined in the ƒractally whitepaper echoes the philosophy behind the first step on this path. The critical property of a DAO is autonomy:
The critical ingredient to being autonomous is being sovereign over information. Bitcoin, when viewed as a company, can make no promises, hold no secrets, and hold no assets that it is not fully self-sovereign over. By “fully self-sovereign” it means they are solely subject to the Bitcoin consensus algorithm.
Fractally whitepaper
In other words, if some other organization or a platform can determine the state of a DAO then that DAO is not truly autonomous and hence not a true DAO. Most blockchains are true DAOs. The famous "DAO" on ethereum was not, because another DAO (Ethereum) was able to fork it:
A smart contract is only as decentralized and autonomous as it is independent. If “The DAO” had no shared state with Ethereum (the ETH balances), then there would be no way for an Ethereum fork to change “The DAO” and “The DAO” would have had to fork itself if there was any dispute.
Fractally whitepaper
Here we come to the essence of the issue: ƒractally wants to use an existing blockchain (like the Ethereum "DAO" did), while it also wants to remain completely autonomous. It needs to use a blockchain, without giving it power to determine consensus on the state ƒractally DAO.
This issue might seem impossible to resolve, but before making conclusions, let's look at the basics of what goes into achieving consensus on state.
Components of consensus on smart contract state
Let's say we have a smart contract with state x. A transaction comes in that transforms this state to state y. How does this happen? A transaction carries information that represents arguments to a smart contract. A smart contract is just a deterministic function (which we also call smart contract code), which takes the old state as well as arguments (represented by a transaction) and outputs the new state. A deterministic function is a function, which always returns the same outputs for the same inputs. In this context, it means that for any transaction z and for any old state x, applying z to x will always produce the same new state. It follows that in order for everyone to have a consensus on the smart contract state, they need to run the same smart contract function using the same transactions and the same old state. Now the old state is just a product of a chain of previous transactions right up to the first transaction which operated on the initial state that was set by the smart contract code. Therefore, in order to achieve consensus on a smart contract state we only need two components:
- Consensus on smart contract code.
- Consensus on a sequence of transactions that apply to a smart contract.
Honest parties who have a consensus on both of these will always compute the same smart contract state.
Normally special transactions create on-chain smart contracts which set the code. That means that blockchains normally determine consensus on both of these components.
Now, for the sake of making a fractal autonomous, consider what would happen if we separated these components? Consider this design:
- Fractal selects a blockchain A.
- Fractal publishes its smart contracts as well as block number of A, from which they become active.
- Transactions applying to fractal's smart contract are recorded in blockchain A in a way that would not trigger any on-chain smart contract.
- Nodes chosen by a fractal compute the state of fractal's smart contracts, based on fractal transactions recorded in A.
The publishing done in the 1st step here should be done in a way that the public would be sure which smart contract code to use for which block of A. Worst case - another existing blockchain could be used for that (hashes of latest smart contracts could be published there).
This kind of design is not completely new. The idea to only use a blockchain for transaction ordering and to do computation off-chain is implemented by a number of different projects like Counterparty, Blockstack, colored coins. But let's look at what it achieves in this context. First of all, a blockchain used by a fractal now has no power to determine the state of a fractal since it can determine only one of two components needed for consensus on the fractal's state. Second, this design makes migration to another chain a lot easier. This is critical because a fractal still needs a blockchain to achieve consensus on the order of transactions. But in this design, if a blockchain stops working for a fractal it could migrate by simply changing a smart contract to say that "from this block, we use blockchain X". No need to interact with the old blockchain (which would help if the old chain is censoring). Since smart contract code is decoupled from a blockchain there's no need to rewrite all the smart contract logic in order to migrate. This decoupling might also provide additional benefits, for example, changes could be made to smart contract computation platform, without changes to the underlying blockchain.
Through ease of migration and guarding its power to determine smart contract code, a fractal can be in full control of its state (which makes it autonomous). The next important question to ask is - what are the nodes chosen by a fractal to compute its state and how will they be chosen? This brings us to the second step.
Step 2: Electing block producers to be state producers
We already have block producer infrastructure all over the world, used to perform smart contract computations. Why not use them to compute the state of a fractal?
Are we coming back to where we started (using blockchain to perform transaction ordering as well as all computations)? Yes, but there's a twist. With our knowledge from step 1 we can ask the following question: if we need a blockchain consensus mechanism only for ordering transactions why are we paying participants of this consensus process for smart contract computations as well? Most importantly, why are we paying them based on a token-weighted scheme?
We can use existing block producers for smart contract computations, but:
- We do not have to use all of them
- We do not have to compensate all of them
- We can choose how much to compensate each of them
I propose the following (updated design from the previous section):
- Fractal selects a blockchain A.
- Fractal publishes its smart contracts as well as block number of A from which they become active.
- Fractal chooses a set of BPs from a blockchain A. Let's call these BPs - state producers.
- Users submit fractal transactions through API provided by state producers.
- State producers submit fractal transactions to blockchain A in a way that wouldn't trigger any on-chain smart contract computations.
- State producers compute the state of fractal smart contracts using the fractal transactions recorded on-chain.
- Fractal pays state producers for its computation, storage and API access.
A fractal would pay the existing blockchain network for bandwidth, but for CPU and smart contract state storage it would only pay to its select block producers.
The result
Now, this is where it gets interesting. Imagine being a state producer for a fractal (or multiple fractals) becomes more profitable than being a typical block producer. A state producer is someone who performs his normal block producer duties, but additionally provides state computations for a fractal and gets paid for that. So, of course, it will be most profitable for BPs to try to maximize their typical BP profits and try to be a state producer for a fractal as well.
And this is the lever that fractals can use to affect the governance process in the underlying chain. Here, I will propose a couple example strategies, for a DPOS chain.
Firstly, a fractal could decide to choose only BPs that are all not among the top block producers of the chain. This would support these BPs to the degree that the fractals smart contracts are used (how much fees are collected by state producers). In theory, if existing BP rewards would be modest enough, these state producers could eventually start earning more than normal block producers. Thus, normal BPs would become incentivized to fall down the ranks in order to become eligible to become state producers, while existing state producers would get more and more funds needed to rise in the BP ranks.
If rewards for state producers are not big enough for this to work, a fractal could choose a different strategy. For example, decide to always reward BPs in positions 19-21 (assuming they perform state producer duties). These BPs would get rewards for being a top BP as well as for being state producer. So for BP in position 18 it might become more profitable to fall down to position 19. In other words, we are incentivizing bottom-of-the-top BPs to compete for 19-21st position. Meanwhile, we could also be rewarding BPs outside of the top 21 for their state producer duties. That might give them enough support to eventually jump over the BPs which are competing for positions 19-21, since these competing BPs have to balance their votes for themselves so that they do not rise above 19th position.
A fractal could also tell a BP that he can become a rewarded state producer if he delegates part of his stake to the lower BPs, that a fractal supports.
A fractal could also influence governance decisions more directly by rewarding for state producer work only those BPs in the top 21, which vote for proposals, which governance process of a fractal agrees with. Sort of like bribing, but instead of giving money, an opportunity to earn (or continue earning) for useful work is given. If the word "bribe" left a bad taste in your mouth, remember that the "bribing" fractal is run by a democratic process involving many people and there might be many fractals choosing state producers and influencing the on-chain governance process.
Of course, a fractal will have to balance its need to affect the governance process of the chain with its need for good state producers. Fortunately, state computed by state producers can easily be validated by other state producers. So there's no need to trust all the chosen state producers. As far as security goes, a fractal only needs to choose a set of state producers such that they will not all collude to lie about the state.
Whether any of the strategies briefly mentioned here would actually work to decentralize any particular blockchain remains to be seen. Game theory needs to be worked out which depends on a specific blockchain, how existing BPs already earn, and what are other influences on the BPs. The point here is that through state producer fees a fractal can potentially leverage its popularity in order to affect the governance process of the underlying blockchain. This leverage does not depend on abstract arguments, but talks in a language that everyone understands: profit.
A fractal does not need a perfect strategy before it starts. Since it is run by the people, not code or tokens, it can adjust its strategy on the fly adjusting to its own size (in terms of usage and fees generated) and lessons learned in the process.
Synchronization and other problems
State producers will have more work than normal block producers since they will have additional computations to do on fractal transactions. This might make them fall behind in some situations. This is a technical problem that I believe has a solution, but I think is a better subject for another post. There are probably a lot more technical and economic issues, that will have to be faced when implementing this and specific issues depend on the specifics of each blockchain. This is only a high-level proposal for the direction of research.
Conclusion
In step 1, we showed how separating consensus on smart contract code from consensus on the sequence of transactions can enable a DAO that is truly autonomous. In step 2 we showed how this DAO could outsource work needed to compute its state, in a way that would give this DAO influence over governance decisions in the underlying chain.
While DAO running as a smart contract on a chain cannot select who and how much it pays for running a consensus process, it can (and I argue that it should) select who it pays for performing state computations for its smart contracts. This power to select who gets paid for state computations enables applications and DAOs to support the block producers that are doing valuable work in their eyes, instead of further supporting the richest. Additionally, it provides means for a DAO to affect the on-chain governance process.
Let me know what you think.
Thanks to @rimantas for a feedback, which helped improve early versions of this text.
References
[1] Cavalli, Thom F. (2002-03-04). Alchemical Psychology: Old Recipes for Living in a New World. Penguin. ISBN 9781101143612
[2] Euryphaessa, Thea (2010). Running Into Myself. Leicester: Troubador Publishing Ltd. p. 39. ISBN 9781848763739.
[3] R. van den Broek, Wouter J. Hanegraaff. Gnosis and Hermeticism from Antiquity to Modern Times. SUNY Press. 1998. p.158-159
[4] Fractally whitepaper Accessed: 2022-03-31
I was only just shown this post today. Thanks very much for the time and thought you put into this post, it's clear you're very knowledgeable on the subject matter.
One thing I really appreciate about the mechanism you describe is that you’re using non-coercive free-market forces (pay to voluntary state-producers) to influence the underlying consensus structure. It's very important to me that we use voluntary, non-coercive, credibly neutral solutions. I have also spent a lot of time considering similar solutions (I helped write the fractally whitepaper, and you can also see the EPN Whitepaper for similar ideas).
But I have some reservations with your solutions described here.
It may be unnecessary
I’m not convinced that the separation of transaction ordering and state computation is necessary for a community to be fully autonomous. I understand that this separation has some advantages, perhaps it makes the process of migration between chains easier. But in fact it’s already possible for DAOs to migrate between chains, so long as the DAO doesn’t hold any assets it’s not sovereign over. Especially if you consider running one's own chain a possible solution, which I think we should, then you can even simply replay all transactions from chain A on chain B to arrive at the same state (More complicated in EOSIO, because you would need to turn off TAPOS for the replay).
It’s technologically complex
This solution requires special APIs and state computation infrastructure to be run by existing block producers, which is socially and technologically difficult. You also require a community of validators to ensure the state producers remain honest. Given this technological complexity, any community willing to undertake it may as well just run their own blockchain.
It’s game-theoretically tricky
State producer pay as described is not proportional to the state-producer’s stake in the underlying chain. If you choose which BPs to reward by rank (as proposed) or another objective metric, it incentivizes a sybil attack.
Final thoughts
I think most of the worry about violations of autonomy do not come from the fear that the underlying network validators will censor or abuse your community, but rather that the community itself will depend on state outside of the control of their own contracts, and thereby prevent their ability to resolve internal disputes by forking state. I think ~90% autonomy can be achieved simply by ensuring that a community uses it's own token, rather than using the underlying network token, and by eliminating any dependencies on off-chain assets. The final 10% autonomy can then be gained once the community earns enough revenue to afford running its own blockchain infrastructure.
Congratulations @sim31! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s):
Your next target is to reach 100 upvotes.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out the last post from @hivebuzz:
Support the HiveBuzz project. Vote for our proposal!
This is over my head, but I wish to share to larger EOS community.