Ethereum is still working on a complementary plan for parallel EVM, but Bitcoin can be soon expecting its own parallel VM layer 2.
Let’s firstly understand why Ethereum cannot achieve parallel EVM.
To maintain network consistency and security, EVM has a crucial feature in its design: transactions are executed sequentially. Sequential execution ensures that transactions and smart contracts can be executed in a deterministic order, making it easier to manage and predict the blockchain’s state. This design choice prioritizes security, reducing potential complexities and vulnerabilities associated with parallel execution. However, under high loads of transaction requests, this sequential execution can lead to network congestion and delays, similar to a single-lane highway.
Is it feasible to simply add lanes? Referencing existing solutions of so-called parallel VMs, including sharding chains like Near. These chains proposed to scale blockchain by introducing more VMs to scale smart contracts. Essentially the workload of one smart contract still lies in a certain VM. If all smart contracts on this chain consume an equal amount of TPS, then the problem is solved. However, if only a few contracts, such as Aave and Uniswap protocols, consume over 90% of block space, having contracts running on a single shard means only scaling at the chain level without benefiting from the improvements brought by sharding. Adding lanes without the ability to switch lanes represents the current dilemma of parallelization of VMs.
The Parallel EVM involves cutting or caching data at the data layer. However, limited by EVM’s programming model, Solidity, as the most popular smart contract programming language, cannot maximize the potential of parallel blockchain architecture. It’s akin to not programming with SQL on NVIDIA’s GPU. Solidity lacks expressions for parallel architectures like Relay Execution and lacks a defined final atomicity for parallel transactions.
True parallelism in blockchain architecture requires achieving the result that transactions of one smart contract can run on multiple VMs simultaneously. A programming model like CUDA is needed to fully leverage a parallel model in blockchain architecture.
BitReXe mentions Bitcoin introduces Turing-complete parallel VM Layer 2 to provide underlying infrastructure support for real applications in the Bitcoin ecosystem and an exclusive programming model for parallel VMs, PREDA.
How BitReXe achieves Parallel Vms on Bitcoin
Parallel VMs
The following illustration highlights the distinctions between BitReXe and other initiatives promoting Parallel VMs. As shown in the leftmost segment of the figure, Ethereum adheres to a single-machine state model, wherein all codes (smart contracts) and states (data) are replicated and managed by each blockchain node through its Ethereum Virtual Machine (EVM). The extant projects utilize Parallel EVMs, as shown in the middle section of the figure, where a single smart contract is deployed on a dedicated VM (or VMs within a designated shard to uphold consensus). All transactions pertaining to the smart contract are processed by the VM (or VMs of the shard in a fully duplicated manner).
In BitReXe’s unified parallelization model, as shown in the rightmost segment of the figure, all smart contracts are deployed across all VMs of the network. The states of a smart contract undergo partitioning and distribution across distinct VM instances, ensuring non-overlapping allocation. Correspondingly, transactions of the smart contract are segmented and distributed for independent and parallel processing across VMs. In the ideal case, this approach facilitates a linear scaling of overall transaction throughput and state capacity with an increasing number of VMs.
The primary challenge lies in efficiently managing the dependencies between execution logic (code) and contract state (data) while enabling independent VM execution and avoiding synchronization, since the comprehensive execution logic of a transaction may entail access to multiple segments of contract states, each residing in separate VMs after state partitioning.
PREDA
We present Parallel Relay-Execution Distributed Architecture (PREDA), a groundbreaking programming model designed to scale out smart contracts on sharding blockchains, parachain systems, and layer-2 blockchains. PREDA supports a parallel architecture: if Solidity for Ethereum is likened to program on a single-core CPU, PREDA’s parallel architecture for BitReXe is akin to CUDA for NVIDIA’s GPU.
The PREDA model introduces two key components: (1) “Programmable Contract Scopes”, enabling programmers to define contract state partitioning based on the application’s data access pattern, narrowing data access range and minimizing data dependency; and (2) “Asynchronous Functional Relay”, allowing programmers to articulate transaction logic with implicit data dependencies for flexible execution across multiple execution engines (VMs). Implemented as an extended Solidity language, PREDA includes additional syntax for programmable contract scopes and statements for asynchronous functional relay.
The figure illustrates the PREDA version of a simplified ERC20 contract. The “@address” keyword defines the scope of users’ balances, equivalent to Solidity’s map definition but specifies fine-grained and separable states for partitioning by address. At runtime, states partitioned by address are managed by a set of VMs in the BitReXe chain. Different states are not maintained by different sets of VMs. The transfer function within the “@address” scope, invoked by payers (i.e., user addresses initiating transfer transactions), initiates a ” relay” for depositing to the payee. This relay, executed by a VM hosting the payee’s address states, adds funds to the payee’s balance.
In PREDA, a smart contract can have multiple scopes with variables and functions defined. Multiple functions and variables of arbitrary types including containers can be defined in a scope. Multiple relays, conditionally or unconditionally, can be initiated in a single function call, allowing recursive initiation and enabling transaction execution flow to be moved multi-hops across different VM instances. This relay-execution approach decomposes a transaction into multiple Micro-Transactions, ensuring limited state access in a single virtual machine and avoiding race conditions. In the PREDA transfer smart contract, decomposing the transaction into a “withdraw” micro-transaction and a “deposit” micro-transaction enables parallel execution of these two types of micro-transactions, as long as their targets (addresses in this case) are mapped to different virtual machines.
BitReXe organizes virtual machines into multiple consensus groups, each independently running a consensus protocol (PoW-based in the implementation) to reach consensus on executed transactions. Across-group consensus is implemented to maintain correctness and consistency for asynchronous functional relays, implemented as relay transactions in BitReXe.
Bitcoin Layer 2
Asset issuance paradigm on Bitcoin layer like inscription is constantly exploiting a vulnerability in Bitcoin, says Luke. While money never sleeps, just as inscriptions may never die. Bitcoin is in desperate need of a truly scalable layer 2 that can release such pressure and save the ledger size from growing too fast which will weaken the decentralization. Such a goal is very unlikely to be achieved by an EVM+Bridge solution.
BitReXe proposes Parallel VMs and PREDA to scale bitcoin. Meanwhile, it adapts to the security of bitcoin. It uses BTC as gas fee, shares the security of Bitcoin, and provides a trustless asset settlement between the two chains.
BitReXe reuses hashing computing power by the Bitcoin network which is carried by on-chain blocks, orphan blocks, and premature blocks as proof-of-work to create valid blocks in the layer-2 network without modifying the Bitcoin protocol. Merge miners receive rxBTC as rewards, a 1:1 pegged bitcoin on the BitReXe network. Users pay gas fees with rxBTC for transactions, interacting with smart contracts, and other on-chain activities. Fullnodes lab, the dev team of PREDA and BitReXe is about to introduce a trustless asset settlement bridge solution between Bitcoin and BitReXe, where rxbtc peg-out is at the same time someone’s BTC peg-in. Official peg-out addresses are no longer required, thus trust assumption is therefore eliminated.
Our high expectations for the Bitcoin ecosystem stem from its ability to solve problems that Ethereum – as Bitcoin’s testnet – has not addressed.
@Bit_ReXe believes that this issue stems from EVM lacking parallel mechanisms leading to blockchain trilemma and aims to directly solve it on Bitcoin Layer 2.
If this issue can be resolved on Bitcoin, then TVL benchmarking or even surpassing Ethereum by more than three times on Bitcoin Layer 2 would present a fundamental breakthrough.”
This is a guest post by BitPNova. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
