Scalability trilemma is a well-known problem in the blockchain space. It states that there's always a trade-off between blockchain security, decentralization, and scalability. Specifically, it claims that you can choose only two of those but never all three. Or rather any improvement in any of the three will require a trade-off in one of the other two.
The point of this post is to try to convince you that we do not need one blockchain that achieves all of these properties together. What we need is:
- Slow chain: blockchain that is maximally secure and decentralized;
- Fast chain: separate blockchain that is fast and scalable;
- Fast chain to be a fully validating client of the slow chain;
Now, you're probably thinking that the 3rd one is impossible. That seems to be what the whole blockchain thinks. But, in reality, if the 3rd is impossible it just means that the slow chain component is not slow (secure) enough. Yes, I really mean it when I call it the slow chain. I mean weekly blocks of size up to 1 MB. You read that right - blockchain where you would have 1 week of time in between blocks.
Why would we need such a slow blockchain? Let me explain.
Blockchain security as interaction between consensus processes
Blockchains run a consensus process among a set of nodes to determine the set of transactions that are included in blocks and their order. Typically distribution in some resource (like the amount of proof-of-work done or stake in some token) determines the amount of influence each node has on the sequence of transactions in each block. Naturally, it means that some quorum of super-majority, as determined by the distribution of that resource, is able to do stuff like censor transactions, other block producers, or re-order transactions.
Now, if you keep the above understanding in mind, the concept of a 51% attack does not make sense. Specifically, it does not make sense to call it an attack. The protocol defines rules which determine who is able to make decisions. Someone follows these rules to gain power, in a way that does not conflict with the rules at all. So how is it an attack? We call it an attack, but from the perspective of the protocol everything is working correctly. By correctly I mean that the algorithm is working according to specification. If we ask any software engineer to write specification for Bitcoin, none of them would include a rule that prevents certain parties from gaining 51% of power. It's impossible to create that kind of rule because we cannot know in advance if the takeover is fair and organized by the community or if it is a centralized party organizing an attack. Furthermore, we might never agree on fairness of a takeover. So it is not only that the protocol is not able to recognize 51% takeovers as attacks, it's also that rest of the world might not have consensus on whether to call this an attack.
Imagine joining to play a game willingly and calling the result of a game an attack on you, even though you are provided with cryptographic proof that game rules were followed as defined. This is us when we call what's known as a "51% attack" an attack.
Let me offer a perspective, which I think is much more useful:
- What is normally called a "51% attack" is not an attack from the perspective of the protocol;
- If some group of people calls it an attack, it simply means that this group of people does not have enough representation in the consensus process of a protocol;
So the problem that we refer to as the "51% attack" is really just about a mismatch between who is represented by a consensus process and who expects to be represented by a consensus process.
An output of consensus protocol that distributes power based on proof-of-work or proof-of-stake cannot be expected to always match expectations of the average user. We have to admit that users are not represented in the consensus process of typical blockchains. Even though, I think we can all agree, that the intended end goal of blockchains is to serve the average user (or to serve each user fairly).
So how can we fix this? We start by expressing the will of the user or rather his community. Expecting the system to be fair and democratic to users without them explicitly stating their will is much like expecting someone to read your mind to do what you want. Community has to learn to express its consensus. It needs a consensus process and this process have to be totally autonomous and independent from other consensus processes.
Fractally consensus process
Fractally is interesting because it introduces a consensus process, but unlike typical projects in blockchain space this process requires active human participation. You could say that it is a consensus process for humans as opposed to machines.
In fractally process, people meet every week to reach consensus among each other. As defined in fractally whitepaper, they reach consensus on rank-order of each others contributions (which can be used for the distribution of any kind of value), but it is easy to see how analogous processes can be used for many other problems which require human consensus (like electing delegates).
Remember the slow chain I talked about, in the beginning? This is the use case for it.
Fractal blockchains
What I want to suggest in this post is that Fractally DAOs do not need to depend on any kind of blockchain infrastructure to run their consensus meetings and to clearly signal their consensus to the rest of the world. They can simply create their own blockchain which produces blocks weekly. Every block could specify links to where the blocks will be published next week. Storage for these blocks is about the only kind of infrastructure that fractal needs to signal its consensus. But like blockchains do not depend on any single specific node being online, the same way these fractal blockchains do not need to depend on any specific storage provider. It can be using multiple of them at all times. A protocol would need to be defined for how to deal with conflicting blocks, but that's what all blockchains have to solve.
Consensus meetings could be run in a totally peer-2-peer way. Fractal contributors are online anyway during their consensus meetings. Bitcoin blocks in the beginning were built on laptops. There's no reason why fractal blocks cannot be built by end-users. Or other blockchains or even centralized servers could be used to help coordinating the meeting. But they would not be determining fractal consensus they would just be helping build a block. Contents of a block determine fractal consensus. And if the server or a blockchain is censoring fractal transactions, preventing coordination, fractal can simply use different tools to build its block.
Now, this kind of fractal blockchain alone might not seem very useful. Fractally whitepaper describes some of the dApps that a fractal would have, but you obviously cannot run these types of dApps on a blockchain that produces blocks only weekly. But this slowness is also its power. The fact that it is such a slow blockchain means that a typical blockchain-based smart contract platform should be able to process its blocks. So you can build an on-chain smart contract that would validate blocks of a fractal blockchain and compute the state of consensus of a fractal. This means that other smart contracts on that chain can read this state. This enables all the dApps described in fractally whitepaper and anything else that might use information from fractal consensus meetings. Just to illustrate with one example, you could have a reward fund smart contract on-chain, which distributes rewards to fractal contributors.
So fractal blockchain would only contain consensus from weekly meetings between fractal participants and this consensus would not change in between the meetings. Then smart contracts on normal chains can fully process that information and run any normal applications which depend on fractal consensus.
Normal blockchains become validators of a fractal blockchain. The same way that a normal blockchain does not depend on any single validator, fractal blockchain would not depend on any single validator blockchain. In fact, many blockchains can process fractal blocks and derive information about the state of a fractal at all times. Fractal would not be limited by the need to choose a single blockchain for its participants or its applications.
The power of naming
Earlier I claimed that the problem that is referred to as the "51% attack" can be solved by a community explicitly stating its own consensus. A fractal chain, as described above, allows a community to state its consensus to the world in an autonomous way. Let me now show how this can solve scalability trilemma and "51% attack" for a fractal community.
One very useful thing fractal can reach consensus on are names. For example, a fractal could encode information in one of its block like: TOK: chainA.contractA, where TOK is the name of a token given by a fractal, chainA is some blockchain with smart contracts, contractA is a smart contract on that blockchain. So basically this is a name of a token and its address. When users or dApps want to use the TOK token, they would look up fractal blockchain to see its address. Then interact with the smart contract specified there.
Let's say something happens to chainA. It could be taken over by centralized parties and start censoring or some massive hack could have happened. Could be anything. During the next consensus meeting fractal could build a block that says: TOK: chainB.contractA. That's it, users and dApps will start using token on chainB as TOK instead of the old token on chainA. Of course, state of contractA would have to be migrated to the new chain. Also, interfaces of the new chain and the newly operated smart contracts would have to stay the same as they were on the old chain, but that's a matter of having standard interfaces. The point is the community is in total control over what TOK is, and its state, at all times. The same applies if an individual smart contract fails instead of the whole chain.
This means that fractal community can run applications on scalable and fast chains, which sacrifice decentralization or security, without applications themselves sacrificing either decentralization or security. So fractal can get all three of scalability, decentralization, and security for its applications.
Conclusion
The core of fractally process is a human-run consensus process. Every other potential application of fractally is rooted in the trust derived from this consensus process run by humans. Executing this consensus process does not in theory require any infrastructure. It could be achieved through standalone client-side app, which outputs blocks that represent fractal consensus as it defines it. It could be up to each fractal to publish its blocks wherever it wants to and to integrate its consensus process with whatever dApps they want.
A lot of what is referred to as security or decentralization issues in blockchains are caused by a mismatch between expectations about who blockchain consensus process should represent and whose will it is geared towards representing in reality. To fully protect end-user you have to run a consensus process that is fully controlled by end-users (participating actively). This consensus process will be slow, but it can be fast enough for some critical use cases like naming. Furthermore, the slowness of the consensus process makes it easier to integrate it into other, faster consensus processes, which enables all the applications that require speed. Overall you get an ecosystem where users can enjoy speed and scalability as well as security.