Why the existing blockchain parallelization including Monad can never achieve scalability.
A BitReXe Research
From Sharding to Parallelization?
It is well-known that Ethereum operates on a single-core CPU-like architecture, similar to a single-lane highway or a washing machine that can only handle one task at a time. However, all modern CPUs are multi-core, and it is not feasible for blockchain to continue running on a single-core architecture.
Scalability is the consensus in the industry, and there are two main ways to scale the computational architecture: increasing the number of lanes, also known as horizontal scaling or sharding, and enhancing the capabilities of system components, including data read-write capabilities or hardware acceleration, splitting and enhancing the capabilities of each system component, which is known as vertical scaling or modular blockchain.
Ethereum’s recent danksharding update introduces Blob. It can be understood as adding a caching system. If the system is running under a heavy load, more data will be placed in the cache to alleviate the system’s read pressure. The method of modularized scaling is not discussed in this article, hence no further discussion.
This article is written by the BitReXe research team, aiming to provide a historical overview of the mainstream parallel blockchain iteration from parallel chains to the smart contract level and introduce the ultimate parallel execution blockchain scalability solution.
- Chain Pallelization- Polkadot
The first parallel narrative was initiated by Polkadot, which expanded by increasing the number of sub-chains, and distributing the number of smart contracts processed by each chain to achieve “scalability.” As long as smart contracts are processed on different sub-chains, parallelization can be achieved at the chain level.
The Relay chain only needs to be responsible for security and transaction finality (Finality), without directly handling transactions. If the TPS requirements of each smart contract are similar, the blockchain’s scalability dilemma has not been solved by Polkadot.
However, the problem is that only a few contracts, such as Uniswap and USDT, consume 90% or more of the block space. If contracts are still running on one sub-chain, it’s equivalent to only expanding the chain layer, and smart contracts have not enjoyed the improvement brought by the parallel chains.
Increased lanes but not being able to switch lanes is the current dilemma of Polkadot’s parallel chains.
2. Chain State Pallelization — Near
In the post-Polkadot era, the market discovered that scalability can be achieved not by adding more sub-chains but by separating the states of a chain. Near uses a single-chain sharding architecture to process different smart contracts on different shards. As shown in the figure, a block contains multiple Chunks, and each Chunk processes different smart contract transactions. As long as the transaction is not from a single smart contract, it can be executed in parallel without the involvement of a beacon chain.
However, the lack of a beacon chain makes it difficult for the state of one shard to be easily read by other shards. At the same time, the most resource-intensive smart contract is still forced to be partitioned in a certain Shard, queuing up in a Chunk queue in a certain block. Parallelization has not been achieved.
3. Parallel Smart Contracts (Smart Contract Pallelization) — Monad
Monad’s further partition of smart contracts is one step closer to the endgame of solving the blockchain trilemma. It officially announced on April 9 that it has received over $200 million in funding led by Paradigm, which indirectly verifies the advancedness of its solution.
Monad’s parallization method is as follows. When A finishes washing clothes at 6 PM, at 6:30 PM, because it does not submit updates to the same state root, 2 EVMs can process A’s drying needs and B’s washing needs simultaneously.
Parallelization is possible as long as the Merkle tree read of one smart contract is not the same type. One EVM can process Uniswap’s swap requests and NFT’s Transfer requests simultaneously, thus achieving parallelization.
Get BitRexe Network’s stories in your inbox
Join Medium for free to get updates from this writer.
However, there will be issues with incorrect execution orders being submitted to the block. The solution is to lock the database write-in before updating, either by locking it in advance or rolling back after an error occurs. Monad adopts the latter, also known as Optimistic Concurrency Control (OCC).
This is based on an assumption — if one smart contract’s transaction requests have so many different states, Monad can solve the expansion problem. However, in reality, most transactions are washing clothes (Transfer), and parallel occurrences are not so frequent. The following figure shows the source of gas fee consumption on Ethereum on January 1, 2024; you will find that although the distribution is not as high as that of popular smart contracts, different transaction types do exist in an uneven distribution.
Further Towards Parallelization?
Based on the iteration from Polkadot to Near, we can easily infer the next iteration direction for parallel blockchain — internal state partitioning of smart contracts.
Parallel 4.0 (Smart Contract State Partition Parallelization)
Partitioning the smart contract state and letting 1 transaction be processed in parallel by multiple Parallel VMs, achieving final atomicity in the fragmented Relay time; this will be the ultimate solution for Parallel VM — it does not involve the data rollback that Monad may face, and through Global Shard, it can make cross-shard data asynchronous calls more convenient. More importantly, after the smart contract is divided into states, there is no need to assume that all smart contracts consume the same block space or that the transaction types within the smart contract are evenly distributed.
Data remains unchanged, and the code follows the data.
This sounds simple, but at least the following solutions need to be implemented:
- A new smart contract programming model that completes the state division when writing contracts;
- Solving the final atomicity problem across shards;
- Solving the asynchronous call problem of data in the shard chain structure of the Relay transaction;
This ultimate parallel blockchain solution is very likely to be achieved by the PREDA programming model developed by a blockchain development team composed of Microsoft Research Institute, Ph.D. from the Chinese Academy of Sciences, a professor from Ohio State University, and an AMD programming language development engineer.
- PREDA Parallel Programming Model
To fully exploit the performance of parallel blockchain, a programming model that supports parallel architecture, PREDA, is indispensable. If we compare Ethereum to a single-core CPU, then BitReXe’s parallel architecture is like NVIDIA’s GPU, and PREDA is like CUDA for Blockchain. Compared to Solidity, PREDA allows developers to freely divide smart contract states, fully exploiting the power of parallel blockchain. This model introduces “programmable scopes” (Programmable Scope) for state division and “functional relays” (Functional Relay) for handling data dependencies. The former reduces the additional computational cost brought by global Merkle tree updates, solving the repetitive computation problem in EVM. The latter solves the problem of each order state machine (a chain) running independently in a multi-chain system and coordinating through message passing (relay transactions) to form a parallel computing system. PREDA models distribute account book status and transactions on these chains to utilize the existing parallelism of multi-chain systems. It also allows any function call (triggering function) executed on one chain to trigger one or more subsequent asynchronous calls of functions (relay functions) on other chains.” Programmable scopes” describe the scheme of dividing smart contract states into non-overlapping independent parts.
2. The team solved the cross-shard atomicity problem in the 2019 paper
The paper proposed Asynchronous Consensus Zones (Asynchronous Consensus Zones),
which can linearly scale blockchain systems without affecting decentralization or security. This is achieved by running multiple independent and parallel single-chain consensus instances (regions). Consensus occurs independently within each region, with minimal communication, dividing the workload of the entire network and ensuring that the burden on each node is reasonable as the network grows. The final atomicity is proposed to ensure the atomicity of cross-region transactions, ensuring the efficient completion of transactions. In a test network environment with 1,200 virtual machines supporting 48,000 nodes, this system provides throughput and capacity of $1,000 per second, comparable to the Bitcoin and Ethereum networks. In a recent Uniswap V2 three-year data backtest, it achieved a uTPS (using relay transactions) of 140,000+ for a single smart contract in 16 parallel VM environments.
3. Deterministic Parallelism (Deterministic Parallelization)
By exposing the structure of contract code accessing the contract state at the execution moment to the execution layer, the execution layer can easily and reasonably schedule, completely avoiding the rollback of execution results.
The first Bitcoin layer 2 network to support parallel VMs, BitReXe, will be deployed on the Bitcoin network and adopt a combined mining method to reuse Bitcoin’s wasted computing power, significantly reducing block intervals while sharing Bitcoin’s security. The Bitcoin layer 2 network will soon open a bridge for mining BRX according to coin×days and the Bitcoin version of parallel fomo3D, which will also be the first parallel smart contract alive written in PREDA.
Financial Infrastructure that powers the unprivileged average
