1 The trilemma of Blockchain
Blockchain system always face an inherited trilemma, which means a single blockchain system can only provide two of three properties simultaneously: scalability, decentralization, and security. One must be sacrificed to make sure the other two. According to Gemini’s definition, explanation of these three properties are:
This trilemma roots in blockchain’ s degree of decentralization is proportional to the number of nodes, more nodes leads to more decentralization. Since every transaction must be broadcast to nodes and validated, more nodes also result in longer time for verification. For some transactions has not accepted by some nodes, a fork chain may emerge (nodes start to retain two copies of ledger) thus impair the security of original chain(consensus split). If adopting smaller group of nodes, throughput can be elevated, however in the cost of decentralization.
2 Monolithic blockchain and modular blockchain
Here are some practices to solving this trilemma. Traditionally, from Layer1 perspective, sharding is typical solution. From layer 2 perspective, sidechains/rollup are the possible options. With the rise of rollup centric in Ethereum road map, a more complicated rule called modular blockchain emerge to tackle this trilemma.
A common blockchain chain always can be divided into three parts: consensus layer, execution layer and data availability layers and most of chains compress these three parts into one monolithic structure, a design inherited from Bitcoin, so coming along the trilemma.
For example, if we want to achieve high scalability, we can adopt short number of nodes and increase block size, leading to less decentralization. If we try to engage more and more participators, more nodes and less hardware reequipment are needed, resulting in slow transaction speed.
Modular blockchain is not coming from scratch. Rollup as a layer2, is the model of separating execution layer from the original Monolithic chains, but consensus is assured by Ethereum chain itself, an example of modulization.
Ethereum has been conduct a series of research on DAS (data availability sampling) and its functionality to support Layer2s. Vitalik in his “Base Layers And Functionality Escape Velocity” has pointed out: If a blockchain allows for the publication and guarantees the availability of a reasonably large amount of data, even if its capacity for computation remains very limited, then the blockchain can support these layer-2 protocols and achieve a high level of scalability and functionality.
- Fig1 . Monolithic and Modular blockchain
Rollup can bring > 1000 TPS for Ethereum users and further abstraction data availability layer from consensus layer? Ethereum has been conduct a series of research on DAS (data availability sampling) and its functionality to support Layer2s. Vitalik in his “Base Layers And Functionality Escape Velocity” has pointed out: If a blockchain allows for the publication and guarantees the availability of a reasonably large amount of data, even if its capacity for computation remains very limited, then the blockchain can support these layer-2 protocols and achieve a high level of scalability and functionality.
Prevailing modular blockchain evasion with layer segregation is like this:
· The data availability layer provides a standard layer of available data sets that are only responsible for storing and sorting data and accepting new data along with transaction layer changes, either in a decentralized or semi-decentralized/centralized manner.
· Execution layer lean to get transaction orders to execute quickly, regardless of data availability and security. All they do is extract the data, execute it, and submit to security or data availability layer(depends on the structure). The typical execution layer include are mainly Layer2s, including Validium/StarkEX from Starkware, Arbitrium from Offchain labs, zkSync from Matter labs, Optimist rollup from Optimism.
· The security/consensus layer is the base layer and the most difficult to implement. It will face non-technical challenge with path dependence and also a history of precipitation. There are only two that are big enough to be recognized as consensus layers: Bitcoin and Ethereum. Other so-called high-performance Layer1s are not as safe as these two.
If this three-layer modular solution is adopted, in optimism case it can dramatically speed up transactions without falling into the Trilemma and, more importantly, without sacrificing underlying security. Mainstream monolithic design can run three layers together, however L2s separates the execution layer from the other two, initiate the modular blockchain era.
Part 3 Typical modular designs
In this part, we will give a deep dive into different layers and to see major player’s
3.1 Execution: layer2
Layer2 are typical execution layers for Ethereum, there are 6 types of layer2s, Optimistic rollup ZK rollups, state channel, sidechains, Validium and Plasma. OP and ZK rollups have enjoyed the most attention from community, based on their on-chain data model and inherent decentralization. Plasma has been abandoned due to its insecurity and long term fund claim period. Team of Plasma dismiss this project and reorganise a new product team Optimism and develop Optimistic rollup leverage some features from Plasma.
Rollup is very similar to Plasma, except that Rollup solves the data availability problem. The CALLDATA function is used to post data to L1. The cost of CALLDATA function is much lower than the transaction cost of L1, thus Rollup can scale the network. Currently call data cost is 16 gas per byte of data, and a transaction on Layer1 will cost >200 gas per byte of data. And there are proposals to further reduce it to 3 gas per byte of data:
https://github.com/ethereum/EIPs/pull/4488
https://notes.ethereum.org/@vbuterin/data_sharding_roadmap
The discussion on different layers can be found everywhere. To simplify the understanding, here just put a classic comp table from Matterlabs.
Fig2: Six layer2s comp table
Except this renowned layer2, we also have some second tier candidates like Hahmii, Boba and Metis forked from Optimism already build up their ecosystem with token incentives. Boba largely speed up the fund exit process to only few minutes from original Optimism’s 7 days. Metis on the other hand, leverage multiple sequencers to pool MVM(Metis virtual machine) submission, achieving more decentralization and less risk, and let users to freely build decentralized autonomous company. Nahmii features its state pools to make transactions happens irreversible, a finality.
Although these new Layer2 are alleged to have such improvements, but at present it has not posed a threat to Optimism and Arbitrum. Perhaps going through a (current) bear market will form a better perspective of whether their claimed improvements will be bought by community.
Fig3: Layer2s design (sorted by TVL)
3.2 Consensus: security, decentralization
As mentioned earlier, the security layer is the consensus. Only Bitcoin and Ethereum have achieved massive consensus globally. The layering of execution and security layers on Ethereum is already in full swing (see L2). This can be called vertical expansion.
The Ethereum Foundation revealed that it had removed all references to “Eth1” and “Eth2” in favor of calling the original blockchain the “execution layer” and the upgraded proof-of-stake (PoS) chain the “consensus layer.” And Vitalik illustrated in his ”endgame” how different layers in Ethereum will work together.
Fig4 Ethereum Endgame
Other Layers like Cosmos system is popular to have security guarantee in another way. The security/consensus of the system is not carried out by Cosmos Hub alone, but by each Tendermint hub/zone. Single chain security decreases, but compared with high performance monolithic chain, the overall security is still high. For example, if one chain fails, other chains in this ecosystem will not be affected and can take on similar tasks.
Avalanche is a Monolithic chain, but its structure is much more complex than other layer1s, with P Chain, C Chain, and X Chain hybrid architectures. Contract chain (C) is responsible for deploying applications and is compatible with Ethereum EVM, where DeFi used by common users runs. X Chain is dedicated to issuing assets and transferring money. P chain Coordinates authentication nodes and creates and tracks subnets. AVA nodes can be self-assembled to form a custom chain, and the subnet is responsible for verification. In other words, Avalanche can run hundreds of chains without having to build its own underlying network, creating subnets through P chain. Avalanche can also be considered modular, just not in the same way as the current mainstream modular narrative.
Fig5 Avalanche system
3.3 Data availability designs:
There are several ways to solve data availability, original Validium reply on single trusted operator, the improved version leverages several members – data availability committees. Celestia intend to provide a pure trustless DA layer and a general compatible l2, so does Polugon Avail. And Ethereum’s newest data sharding – Danksharding is a new design to provide data availability to roll ups in a sharding way.
3.3.1 Validium
Original Validium's mechanism is very similar to zkRollup's, the difference lies on zkRollup has on-chain data availability, whereas Validium only has off-chain data availability. As a result, throughput for Validium is much higher -- but there is a trade-off: Validium has the single operator to control the offchain data and can refuse client(from layer2) to move fund.
Single operator model is a significant risk thus there are two ways to tackle this. One is through rollup, transit off-chain availability to on-chain availability, with the cost of scalability. The second way is to scale one operator into a group of permissions operators to generate new status update, this is the data availability committee (DAC).
DAC
DAC is a group of trusted nodes to provide off-chain data, and they can post attestation on chain. The benefit for DAC is cost effective, which only require ~30,000 gas(by Celestia estimate. 10 member * 3000 gas fee per singnature).
According to DiversiFi, three typical functions of DAC include:
· Protect user trading privacy by allowing balance updates and trades to be hidden from other users.
· Check the balances state and if valid sign to allow the merkel root of the state to be updated on-chain.
· Publish all balances data if DeversiFi and or StarkWare were ever to go offline or withhold data.
DiversiFi’s DAC consist of some big names: StarkWare, ConsenSys, DeversiFi, Nethermind, Cephalopod, Iqlusion and DeversiFi. User has to trust these nodes before they actually using these data to engage with layer2. DAC will receive new status transition and when enough number DAC sign to the commitment, on-chain execution layer will accept and update the status.
However, there are still security issues with DAC. Because members are reputable or even licensed, they may be restricted by traditional laws and regulations requiring clients to do KYC/AML, or they may lose their private keys, resulting in client funds being locked up. Thus DAC structure can be further decentralized to completely permissionless.
If wecompare DAC-based Validum and ZK rollup, ZK rollup is more secure. As long as users can show Merkle to prove their ownership of the account, they can withdraw funds from the account, a feature of on-chain data availability (ZKrollup), instead of being controlled by DAC.
On-chain data availability leads to reduced throughput, StarkEx Validium can handle 9000 + transactions per second, while ZKrollup can only handle 2000+ transactions per second.
3.3.2 Volition and beyond
In later design, Starkware propose Volition's solution for data availability and security. Volition allows end users to choose between the Rollup scheme (on-chain data availability) and the Validium scheme (off-chain data availability) for each transaction.
As an example, Starkware assume a company that could choose to trade funds in an off-chain data account during the day and transfer them back to the on-chain data account for safekeeping at the end of the day. In this way, the convenience of off-chain data availability is utilized to ensure the security of funds to a certain extent (up-chain of funds).
Fig6 Volition and Validium
In addition to Volition Starkware came up with an even bolder idea last year, Layer3. Layer3 takes Starknet, as an Ethereum-like settlement layer, and develops and launches dedicated DApps on Layer3 rather than on Layer2. Different application can take choices among different scalability solutions, according to Starkkware:
· low cost applications will prefer private StarkNet with Validium data availability
· Application-specific StarkNet systems customized for better application performance, for example, by adopting specified storage structures or data availability compression.
· Specific StarkEx systems (like dYdX/Immutbale) with Validium or Rollup data availability
This reflects a more complex application of block chain modularity. Application and special execution layer are integrated, while general execution layer has the role of like a certain consensus layer. The modularity of DA layer is more refined to provide data availability services dedicated for a certain application. But the idea is based on Starkware's ambitions for Starknet, which will have to be tested after Starknet full function launch.
Fig7. Starkware Layer3 design
3.3.3 Zksync and zkPorter
The solution of zkSync to solve DA problems is zkPorter. By leverage off-chain data availability, zkPorter can offer a 20,000+ TPS, much faster than current rollups.
zksync2.0 will consist of zk-rollups(on chain data availability) and zkporter(off chain data availability). The processing scheme of zxPorter is very similar to Starkware's Volition in that users can choose between on-chain and off-chain data availability. The transaction speed of off-chain data availability will increase dramatically, 20K-100K TPS vs 1K-5K TPS on-chain. Volition can specify on-chain or off-chain accounts for each transaction (as Starkeware did earlier), whereas zkPorter must specify on-chain or off-chain accounts in advance.
In order to ensure the data availability of zkPorter's account, zkPorter introduced the guardian system, where the guardian holds the zkSync token and participates in the PoS network to provide data availability support, and any failure to provide data availability will result in slash. In zkPorter, the guardian attack can only lead to the network locking funds, instead of stolen, which will greatly reduce the willingness to attack. This security features can not be achieved by optimistic rollups, where attackers can transfer fund due to fraud proof model.
zkSync2.0 launched its testnet on Feb22 2020, with new support to Native support of ECDSA signatures, Web3 API, Ethereum cryptographic primitives. However the zkPorter will be only included in further upgrades, together with L2 → L1 smart contract messaging, Account abstraction, etc..
Fig8. Design of zkSync2.0
3.3.4 Dedicated data availability (DA) layers
DA layers can be taken as a permissionless DAC, like a network which have extra slash mechanism towards malicious nodes. By leverage data availability sampling, light node can easily detect malicious action from node operators. There are currently two blockchains focused on providing data availability, one is Celestia and the other is Polygon Avial.
Celestia
Celestia is a PoS blockchain. It orders data and makes it available, however do not execute transactions. Celestia itself builds based on Cosmos SDK and uses Tendermint as its consensus engine to build solutions focused on EVM and Cosmos SDK. Celestia tent to be friend to common hard ware users, so their validation expansion mode does not rely on high performance hardware.
The key to the Celestia’s scalability design is that its verification burden are not proportional to the size of the block. Clients only need to download the square root of the amount of data they are going to validate. To verify the availability of N blocks of data, the user only needs to download a <N^0.5 size data to complete the verification.
If there are more and more nodes in the network, the size of such blocks can be very flexible without affecting the speed. Light nodes in the network (like our common user's mobile wallet) can verify data availability without concerning about block headers and block data inconsistence.
Celestia can be used in two ways, either as a consensus layer and data availability layer on its own, or as a data availability layer for other public chains, and provide a additional rollup like Layer2 for execution.
· For former one, Celestia nodes will work just to get consensus. This allows any executive layer to be built on Top of Celestia, such as Layer2 to upload transaction data to Celestia regardless of consensus and global state. Developers can focus on developing the available implementation layer.
· For latter one, Celestiums(build by Celestia team) is a layer2 for Ethereum. To cooperate with Ethereum, three parts is needed, one is DA layer from Celestia, one is layer2 Celestiums, the last one is Quantum Gravity Bridge to connect Ethereum and DA layer, illustrated in the following pic.
Fig9: Celestia based scalability solution for Ethereum
The Celestia network and The Ethereum L2 protocol can work together like this:
· L2 publishes transaction data to the Celestia network, which is then forwarded from Celestia to Ethereum (via a quantum gravity bridge) in the form of DA attestation. The authentication is a Merkle root of L2 data signed by a Celestia validator to prove that the data is available on Celestia.
· The quantum Gravity Bridge contract validates the signature on the DA attestation from Celestia. When the L2 contract updates its status, it does not rely on the transaction data published to Ethereum by Calldata but checks and ensures that the correct data is available on Celestia by querying the DA bridge contract.
· Celestiums is the dedicated Ethereum L2 protocol, which can bring higher speed and layer 2 security to Ethereum, combined with the Celestia network.
Tradeoff of using Celestia as an independent data security layer is that higher cost is needed on Celestia's DA attestations on Ethereum, thus the data fees on Celestia will be decided by a fee market，however save the CALLDATA cost to upload data on chain. Since these things are permissionless, the security is better than using DAC.
Celestia fullfilled the above performance by leveraging light nodes and proof of fraud with verifiable data. There are two main technique components here: Namespaced Merkle tree and 2-dimensional Reed-Solomon Merkle Tree.
· Namespaced Merkle tree (NMT )allows any executor layer (such as Rollup) to download only data related to their chain on Celestia, ignoring data from other executor layers, given that the Merkle tree ha sit own name space ID.
· 2-Dimensional Reed-Solomon divides information (blocks) into N * N two-dimensional pieces of length and width. When verifying data, the light node only needs to download horizontal or vertical data, so the amount of data to be downloaded directly becomes block size/N rather than whole block size. If adopting probabilistic validating rule, the sample size can reduced further.
Below is the test results from their working paper. For the probabilistic validity rule that Celestia adopted, only 15 samples are needed to take the data availability validate.
Fig 10 Celestia data download
Polygon Avail
Polygon came up with his own DA Layer Avail in June 2021, which is similar to Celestia in terms of technology. But the project team has not do anything for months, and the code base was barely updated. So it's safe to assume that the project is on hold. So among this type, Celestia should be the first to go on the main network. Celestia launched a test network in December 2021 and is expected to go live mainnet in the second half of 2022.
3.3.5 Danksharding – data availability through data sharding
Danksharding is a data sharding that combines a consensus layer with a data availability layer to provide data availability for Rollup or other scaling solutions. Danksharding comes from Ethereum researcher Dankrad Feist. The following designs are featured:
• Proposer-builder separation (PBS), used to separate proposer and Block Builder to prevent centralization and MEV from flowing to large mining pools
• Censor-resistant scheme -- crList (Censor-resistant List) is a "hybrid PBS" design that prevents a single efficient Block Builder from permanently censoring certain transactions. crLists allow proposers to specify transaction lists that builders must include.
• Beacon chain provide data availability + superlight client verification
• Instead of creating A PBS for every shard, a validation board validates all beacon blocks and shard data, greatly simplifying the architecture between Rollup and Layer1
Fig 11. Danksharding design
Advantages of Danksharding from Dankrad:
· simple design, can directly use the existing executive cost market infrastructure
· Tight coupling between execution chain and shard
· Separate PBS is not required for every shard
· Bribery resistant is enhanced;
· Small validation sample size for data availability sampling
Danksharding is an Ethereum sharding solution that has just been proposed this year. It is not just a category of modular blockchain solution but an integrated plan toward to Ethereum end game. We will look deeper into Danksharding in later stages.
4 Conclusion and outlook
With the launch of Layer2 last year and possible native coin issuance this year, modular blockchains are likely to be the focus of discussion for a while. Whether it's an Ethereum-based modular setup like zkSync, Starknet or a Tendermint-based like Celestia, they may all potentially mimic the Layer1 narrative of last summer（in optimistic scenario）.
At present, the main situation of modular blockchain is to tackle the separation of execution layer and security layer and the following issues like security, cost reduction etc.. The data availability layer and security layer are still superimposed together in current design. Vitalik was working with Celestia CEO Mustafa Al-Bassam on light client verification, and DAS is one direction for the Ethereum final centralize production, decentralize validation and strong anti-censorship blueprint. The narrative of a separate data availability layer remains to be seen on how beneficial further abstraction can bring.
Fig 11 Modular Ethereum blueprint
