Annual Review of Universal Blockchain: Efforts to Break the Impossibility Triangle of Public Chains

Written by: Cui Chen, Office of Chief Economist at Wanxiang Blockchain

Reviewed by: Zou Chuanwei, Chief Economist at Wanxiang Blockchain

As 2022 comes to a close, reflecting on the ups and downs of the industry over the past year, whether it be technological breakthroughs, innovative applications, or the rise and fall of ecosystems, all have become historical footnotes in the development of the industry. As in previous years, Wanxiang Blockchain has launched a series of significant annual review articles at the end of the year: "Public Chain Technology," "Applications," and "Regulation," aiming to document the current snapshot of industry development.

The impossible triangle problem of public chains has always been a barrier to the development of public chain technology, which in turn affects the performance of on-chain applications. Historically, the development goals of public chains have focused on how to break through the impossible triangle problem or find the best balance within it. Innovations in public chains are reflected in Ethereum's updated roadmap, EVM-compatible public chains, modular public chains, and high-performance public chains represented by Solana and Aptos. The following text will interpret the differences in various solutions to the impossible triangle from the perspectives of the impossible triangle and transaction processes.

Understanding the Impossible Triangle

Concept of the Impossible Triangle

The most basic function of a public chain is to record information on-chain and maintain information security, that is, to prevent information from being tampered with (rollback) in an open network (trustless), relying on underlying components such as cryptography, consensus mechanisms, and distributed networks. Cryptography includes public-private key cryptography and hash functions, which ensure the correctness of verification signatures and the rules of the chain structure.

In a blog post in 2017, Ethereum founder Vitalik Buterin proposed that among the three characteristics of scalability, security, and decentralization, a blockchain system can at most possess two simultaneously. When discussing the impact of the impossible triangle on public chains and breakthroughs in the impossible triangle, we need to understand the definitions of these three aspects and their impact on the system.

Scalability measures the ability of a public chain to support transaction speed and scale, reflected in the time it takes for a transaction to be proposed and confirmed. Public chains with slow transaction processing speeds struggle to achieve many application functions, such as instant payments, which limits the scope of applications and affects user experience.

Security measures the system's ability to withstand attacks, representing the reliability of the system in the face of failures, mainly reflected in fault tolerance and the difficulty of modifying consensus. Low system fault tolerance makes it easier for the system to be attacked, and modifying consensus changes confirmed transactions, equivalent to tampering with past transaction records.

Decentralization measures the degree of dispersion of public chain nodes. Since public chains are not established through trusted third parties, they can only be maintained by a distributed peer-to-peer network. On this basis, the decentralization of public chain nodes provides the trust foundation for the system. Combined with cryptography and consensus mechanisms, public chains can function normally. Decentralization also represents the power of users to participate in transaction verification and reflects users' voice in the public chain system.

Decentralization manifests in two levels: first, measured by the number of nodes; the lower the entry threshold for nodes, the more numerous they are, and the higher the degree of dispersion; second, measured by actual controllers. If there are roles in the public chain, such as mining pools, where one role controls multiple nodes, it can lead to centralized transaction review issues.

In summary, the indicators and specific meanings measured by the impossible triangle of public chains are shown in the table below.

Table 1: Indicators and Specific Meanings Measured by the Impossible Triangle

Understanding the Impossible Triangle and Optimization from the Perspective of Transaction Processes

The transaction process on a blockchain can be simplified into the following four steps:

1. The user signs the transaction and broadcasts it to the nodes, adding it to the unconfirmed transaction pool;
2. Consensus nodes verify and execute the transaction, packaging these transactions into a block;
3. The block is broadcast to other nodes in the network;
4. Other nodes verify the block and store it after adding it to the blockchain.

These steps influence the three indicators of public chains from different angles.

1. Scalability

Scalability is affected by steps 2, 3, and 4. In step 2, the speed of transaction verification, execution, and consensus affects scalability. Factors such as the blockchain's account model, virtual machine, and consensus mechanism all influence the speed of completing step 2. For example, if the consensus time is shortened by reducing the number of consensus nodes, it will affect the degree of decentralization of the system.

In step 3, if there are many nodes, the synchronization speed among the nodes will also slow down. When trying to improve scalability by increasing block capacity, it becomes challenging to broadcast the block to all nodes within the originally planned time. In the absence of complete network synchronization, processing transactions after different blocks can lead to forks, thereby affecting the network's security. Conversely, if the number of nodes is reduced to speed up synchronization, it will impact the system's decentralization.

Step 4 signifies the final confirmation of network transactions. If nodes can quickly verify after receiving the block, scalability can be improved, but it faces similar issues of compromising security and centralization.

2. Security

The difficulty of being attacked in steps 2, 3, and 4, specifically the difficulty of being controlled by malicious nodes, affects the system's security. This is particularly reflected in step 2 as the performance of the consensus mechanism. If the fault tolerance of the consensus mechanism is low or easily manipulated by malicious actors, it will reduce system security or lead to centralization of nodes.

3. Decentralization

Distributed nodes are the underlying foundation of public chains. The more nodes that join, the more nodes recognize the public chain, avoiding risks from single points of failure, and increasing the cost of attacks by malicious actors, as they need to control more nodes under the same fault tolerance. Increasing the degree of decentralization requires lower entry costs for nodes, but as mentioned above, increasing the number of nodes under the same security conditions will reduce the system's scalability.

When understanding decentralization from the perspective of actual controllers of nodes, the focus is on the issue of "transaction censorship." When nodes are responsible for packaging transactions, if they selectively choose and order transactions based on their preferences, it can make it difficult for some transactions to be executed and confirmed on-chain after being proposed. This affects the ability of transactions proposed in step 1 to be selected and verified in step 2.

In summary, public chains can make improvements and optimizations in various steps of the transaction process, but due to the influence of the impossible triangle, optimizing one aspect will always come with at least one negative impact on another aspect. Public chains need to find a balance within the impossible triangle to meet more application scenarios. The following text discusses the optimization attempts of different public chains in various links, including Ethereum's latest roadmap, Ethereum-compatible public chains, and high-performance public chains.

Ethereum: Optimizing the Impossible Triangle with New Technologies and Frameworks

In Ethereum's recently announced roadmap, some improvements in the impossible triangle and user experience can be observed.

Figure 1: Ethereum's Latest Roadmap

Merge: Transitioning the Consensus Mechanism from PoW to PoS

The consensus mechanism primarily affects the block generation and verification synchronization process. After Ethereum transitions to PoS, it adopts the LMD GHOST + Casper FFG formula mechanism, achieving two goals: producing a block within each slot (12 seconds) and conducting corresponding witness voting, with finality confirmed after two epochs (one epoch includes 32 slots). Rolling back a block requires destroying at least one-third of the staked ETH on-chain.

In Ethereum's Merge phase planning, Ethereum also aims to shorten the final confirmation time to a single slot, eliminating the need for several minutes of waiting time for transaction confirmation, achieving higher efficiency and enhancing user experience. However, achieving single-slot confirmation requires improvements to the consensus algorithm, which may reduce the cost of attacking the chain (changing consensus) and decrease the number of validating nodes, impacting the security and decentralization of the public chain.

Surge: Using Rollup and Danksharding to Improve Transaction Processing Speed

Ethereum expands its capacity through Layer 2 solutions, specifically the Rollup expansion method, where the Layer 2 network executes content from the main network off-chain and then returns verifiable results to the chain. Currently, Rollups in Ethereum primarily follow two routes: Optimistic and ZK.

In Optimistic Rollup, due to its generality, it has a first-mover advantage in terms of user numbers and overall locked value. There are many controversies regarding the sorters in Optimistic, as the sorters of Arbitrum and Optimism currently produce blocks in a centralized manner, which may lead to transaction censorship issues. ZK Rollup focuses on two main issues: first, the construction of zkEVM, choosing between compatibility with EVM and building a completely independent virtual machine, which involves a trade-off between practicality and performance. Second, accelerating the speed of zero-knowledge proofs, generating zero-knowledge proofs through hardware devices is also an option. To further reduce the on-chain data availability cost, both types of Rollups have introduced off-chain data storage models, suitable for scenarios requiring high-frequency interactions, although this increases the trust cost on nodes.

While Rollup seems to solve the impossible triangle problem of public chains, it has two inherent issues. First, Rollup's information processing capacity has an upper limit, especially since Rollup relies on the underlying network for implementation; the carrying capacity of the underlying network determines the operational capability of Rollup. Second, different Rollups on-chain can lead to interoperability issues.

To maximize the functionality of Rollup, Ethereum's EIP 4844 (proto-danksharding) proposes expanding block capacity to accommodate blob data blocks that carry data returned from Rollup to the main chain. While increasing block capacity improves scalability, the consensus and synchronization of large data will also bring challenges. Therefore, in the Surge phase, there are plans to launch DAS (Data Availability Sampling).

DAS allows nodes to verify data without downloading and verifying all data; instead, the data is divided into several blocks, and nodes only need to randomly download a portion to verify if data is missing. The accuracy of DAS detection will be improved through erasure coding, which can expand additional data to recover lost original data, serving as a data redundancy mechanism. The effectiveness of the erasure coding expansion is guaranteed by the cryptographic mechanism KZG commitment.

Assuming there are 4 data blocks waiting for verification, nodes have a 25% chance of discovering that one original data block is missing. By using erasure coding to double the data to 8 blocks, if more than 50% of the data is lost, the original data cannot be recovered, meaning the probability of nodes discovering data loss exceeds 50%. As the number of validating nodes increases, the probability of discovering data loss also increases. Assuming there are n nodes conducting random sampling, when 50% of the data is lost, there is only a 1/2^n chance that all nodes sampled the undamaged data blocks. Therefore, with a large number of nodes, the DAS verification method is sufficient to ensure data security.

In summary, increasing block capacity to enhance overall block scalability will reduce synchronization efficiency, impacting system security. To improve synchronization speed, reduce node storage, and ensure sufficient decentralization, only cryptographic improvements can be made at the mechanism level, but overall, it still affects the network's security.

Separation of Node Roles: Proposers and Builders

Ethereum employs PBS (Proposer/Builder Separation) to divide the tasks of nodes into two roles: Proposers and Builders. Builders are responsible for constructing the main body of the block and submitting bids, while Proposers only need to execute the highest bidding block without knowing the transaction contents within the block, reducing transaction censorship.

The implementation of Danksharding will require Builders to have higher bandwidth resources, and Builders may become centralized organizations due to specialization, while Proposers represent a broad decentralized group to balance centralization risks. As long as there is one honest Builder, Ethereum blocks can be produced normally. To prevent Builders from censoring transactions, Proposers will pass a crList representing the transaction list that Proposers want to package, and Builders need to fill the block with transactions from the crList. This is a mechanism to weaken MEV, while in the large block model, it divides nodes into two roles to ensure sufficient decentralization.

Verkle Trees, Historical Expiration, and Multi-Dimensional Fee Markets

The vast historical data can impact Ethereum's decentralization, especially as the growing state data leads to various inefficiencies. To avoid affecting decentralization while achieving the aforementioned scalability plans, some mechanisms are needed to ensure that the same security standards can be met and that the system operates more efficiently.

Verkle trees are a simpler data storage model that requires less proof space compared to existing Merkle trees, which is an improvement made by cryptographic technology. Coupled with a historical data expiration mechanism, it reduces the storage pressure on nodes and continues to lower the entry threshold for nodes.

The historical data expiration mechanism can solve the problem of data bloat, as clients do not need to store data beyond a certain time. Proto-Danksharding can also implement independent logic to automatically delete blob data after a period, so large blocks no longer become a barrier to expansion. This does not mean that block data is permanently lost; before data deletion, sufficient time is given for users needing the data to back it up. There are also nodes in the network that retain all historical data, including dedicated protocols, Ethereum Portal Network, block explorers, data service providers, individual enthusiasts, and scholars analyzing data who will save all node data.

In the multi-dimensional fee market, each type of resource has a target value and capacity limit, just as the implementation of EIP 1559 sets requirements for gas. The degree of resource usage relates to the pricing of resources. Ethereum will begin to implement more granular pricing and charging from aspects such as EVM execution, transaction calldata, witness data, and storage capacity, including the upcoming blob blocks in Proto-Danksharding. The ultimate goal is to achieve pricing for each individual opcode, which will enhance user experience during fee statistics.

In summary, Ethereum urgently needs performance improvements and has proposed Rollup and Danksharding ideas to enhance performance. At the same time, to allow more Rollup data to be stored cheaply and without bloat, it has proposed solutions for data availability while mitigating the security reduction issues it brings. Ethereum still needs to address its technical debt through planning such as PBS, historical, and state expiration to continue protecting node decentralization. With the introduction of new technologies and frameworks, Ethereum aims to maximize scalability while ensuring decentralization and security.

Ethereum-Compatible Public Chains: Solving Different Impossible Triangles at Different Levels

EVM-Compatible Chains

In recent years, Ethereum has sacrificed scalability for security and decentralization, as evidenced by Ethereum being the public chain project with the most nodes globally, and it has not experienced large-scale network interruptions during its operation over the years. The network does not go down due to the failure or exit of individual nodes, proving that it has sufficient redundancy. Meanwhile, nodes require a long consensus synchronization time, resulting in slower transaction processing speeds and rising transaction fees.

Simply put, the structure of Ethereum's mainnet includes an execution layer and a consensus layer. The execution layer refers to the process in which nodes execute user instructions in Ethereum, including transfers and EVM. With a large number of nodes, consensus and synchronization will inevitably be affected. Therefore, the simplest way to enhance Ethereum's performance is to modify its consensus layer, reducing consensus synchronization time to achieve faster efficiency.

This can be seen in the competition among Ethereum-compatible public chains (i.e., various EVM-compatible chains). Especially when the execution environment is the same, migrating applications becomes easier. Thus, we can see that homogeneous public chains adopting Ethereum's architecture have modified Ethereum's consensus method, reduced the number of nodes, and shortened consensus time while retaining the functionality of the execution layer. Although this may lead to centralization issues, it quickly meets the overflow demand for applications on Ethereum, replacing Ethereum as the issuance ground for application projects. For example, BSC, Polygon, and Avalanche are representative public chains of EVM-compatible chains, all of which significantly reduce the number of nodes participating in consensus.

Modular Public Chains

Among Ethereum's competing public chains, "modular public chains" have emerged, layering Ethereum's functions and operating in a modular manner. This is actually a representative idea; although the impossible triangle exists, a compromise point can be found within it.

Applications with different focuses will choose public chains that emphasize different aspects, as their needs for performance, security, and decentralization vary. For example, privacy public chains do not allow for transaction censorship and are willing to pay extra costs to protect their decentralization. Public chains supporting financial applications place a higher emphasis on security, while gaming public chains demand extremely high performance experiences and lower their requirements for decentralization.

Thus, modular public chains abstract each layer of demand, dividing the blockchain into: consensus layer, execution layer, settlement layer, and data layer. Each layer can have multiple solutions, and depending on the different needs of the chain, these solutions can be directly integrated to achieve optimal results. At the same time, the solutions at each layer are modular, allowing public chains to switch between them, thereby balancing application demands and indirectly breaking through the limitations of the impossible triangle.

Non-Homogeneous Ethereum Public Chains: Rethinking Focus Directions within the Impossible Triangle

Due to Ethereum's performance bottleneck issues, almost all new non-homogeneous public chains have chosen performance-first planning, combined with PoS-like consensus, and introduced new technologies to strengthen their performance advantages or compensate for security deficiencies.

Solana first increased the block capacity, expanding the amount of data a block can carry by ten times. Secondly, to reduce the number of nodes synchronized each time, Solana publishes the list of responsible nodes in advance, so each transaction only needs to be transmitted to the responsible Leader, while other validators only need to verify their respective parts without verifying the entire block.

In addition, Solana pre-judges before executing transactions; if conditions are met, it will use parallel computing to improve transaction processing speed. If serial processing is necessary, it will switch to a less efficient operation mode than Ethereum. It is evident that Solana sacrifices security and decentralization in pursuit of scalability, as network interruptions can occur when leader nodes fail or when there are errors in determining whether to process in parallel.

Aptos claims to represent the next generation of high-performance public chains, continuing various functions of the Ethereum public chain through different methods. Aptos adopts the AptosBFT consensus mechanism, which is a BFT-based consensus mechanism that requires only two network round trips to verify and submit blocks without needing multiple rounds of voting, allowing for quick finality. Aptos blocks only include summaries of transaction records and do not contain all transaction record information, allowing for more transactions to be included in each block. It groups transactions into batches and merges them into blocks after reaching consensus, processing them in batches in subsequent execution and storage, which improves efficiency.

Aptos also employs parallel processing using the Block-STM engine, which defaults to parallel processing for all transactions. When conflicts occur, unsuccessful transactions are re-executed, relying on a scheduler to prevent the same transaction from being executed simultaneously and to gain more security confirmations after re-executing transactions. Additionally, fast state synchronization is also a consideration for Aptos.

State synchronization refers to the process of synchronizing the results of state transitions to other nodes after a transaction is completed. Inefficient state synchronization can lead to most nodes not being able to sync to the latest state information, affecting user experience and making it difficult for new nodes to join the consensus process, impacting the network's decentralization. Aptos provides various state synchronization methods, including using RocksDB or nodes synchronizing state changes through Merkle proofs generated by validators, skipping the transaction execution phase to sync states. This approach reduces the significant computational resources required for node synchronization but needs to be based on the use of substantial network resources. Aptos recommends that consensus nodes run on cloud servers, as personal computers may struggle to meet its requirements.

Aptos believes that Ethereum's virtual machine is also its bottleneck, as Ethereum cannot make large-scale updates to its language, whereas Aptos does not have such technical burdens. Aptos and SUI both use the Move language, which innovatively treats assets as resources. There are certain restrictions when creating, using, and destroying resources, which prevents common reentrancy attack issues seen in Ethereum, allowing for safer smart contract construction and enabling the virtual machine to process multiple transactions in parallel. Charging rent based on storage resources also becomes possible.

In summary, new public chains prioritize scalability over security and decentralization, which differs from Ethereum's approach. Therefore, they have re-selected their focus directions within the impossible triangle, and such changes are very noticeable to users, as evidenced by the downtime issues experienced on Solana.

Reflections and Conclusions

The consensus mechanism and distributed node network ensure the reliable operation of public chains from two aspects:

First, ensuring system fault tolerance: the consensus mechanism has a certain degree of fault tolerance, meaning that as long as the proportion of faulty nodes is below a certain threshold, the system can still verify information. Freely joining distributed nodes can supplement new normal nodes.

Second, increasing the cost of attacks on the system: the consensus mechanism represents the way nodes reach a consensus on the state of existing blocks. The party that controls the consensus mechanism represents malicious actors who have the power to modify consensus (alter ledger records) and censor transactions (decide transaction ordering and whether to package them on-chain). The consensus mechanism and distributed nodes can increase the difficulty and cost of attacks from a regulatory perspective.

On this basis, the impossible triangle problem of blockchain can be understood as follows:

Ethereum itself has already taken shape, making it difficult to start anew and make changes. Therefore, Ethereum is making every effort to introduce new technologies (cryptographic technologies, single-slot finality algorithms) and new frameworks (Rollup, data availability) to optimize its performance bottlenecks, hoping to significantly enhance performance while maintaining a relatively stable level of decentralization and security, thereby optimizing the impossible triangle.

Homogeneous Ethereum public chains, EVM public chains, and modular public chains are much more flexible. The hierarchical breakdown of Ethereum allows them to find their own "social division of labor" to match different applications, such as supporting finance, gaming, privacy, etc. Based on application demands, they can derive the requirements for different layer technical frameworks, helping them find new balance points within the impossible triangle.

Non-homogeneous Ethereum public chains, free from technical burdens, can completely start anew, using entirely new architectures and technical means. Unlike Ethereum, which pursues performance under sufficient decentralization and security (homogeneous Ethereum public chains lie somewhere in between but lean more towards performance), they all coincidentally choose a performance-first path. The benefit of this is that users can intuitively feel their progress (in terms of TPS), but the issues of security and decentralization also pose hidden risks.