While Ethereum is still working on plans to complement its parallel EVM, Bitcoin can expect its own parallel VM layer 2 soon.
First, let’s understand why Ethereum cannot achieve a parallel EVM.
To maintain network consistency and security, the EVM’s design has an important feature: sequential transaction execution. Sequential execution makes the blockchain state easier to manage and predict, as transactions and smart contracts are executed in a deterministic order. This design choice prioritizes security and reduces potential complexities and vulnerabilities associated with parallel execution. However, under high loads of transaction requests, this sequential execution can cause network congestion and delays, similar to a single-lane highway.
Is this feasible by simply adding more lanes? We refer to existing solutions of so-called parallel VMs, including sharded chains like Near. These chains proposed to scale the blockchain by introducing more VMs to scale smart contracts. Essentially, the workload of one smart contract is on a specific VM. If all smart contracts on this chain consumed the same amount of TPS, the problem would be solved. However, when a small number of contracts, such as the Aave or Uniswap protocols, consume more than 90% of the block space, running the contract on a single shard means scaling only 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 VM parallelization.
Parallel EVM cuts or caches data at the data layer. However, the limitations of the EVM’s programming model prevent Solidity, the most popular smart contract programming language, from realizing the full potential of parallel blockchain architectures, just as you can’t program with SQL on NVIDIA’s GPUs. Solidity doesn’t have a representation of parallel architectures, such as Relay Execution, and it doesn’t define eventual atomicity of parallel transactions.
True parallelism in blockchain architecture requires achieving the outcome of allowing transactions of a single smart contract to be executed simultaneously on multiple VMs. To fully utilize the parallel model in blockchain architecture, a programming model like CUDA is required.
Bittrex Bitcoin introduced the Turing-complete Parallel VM Layer 2 to provide underlying infrastructure support for real-world applications in the Bitcoin ecosystem, as well as PREDA, a programming model specifically for parallel VMs.
How BitReXe enables parallel VMs on Bitcoin
Parallel VMs
The following diagram illustrates how BitReXe differs from other efforts driving parallel VMs: As shown in the left-most section of the diagram, Ethereum adheres to a single-machine state model, where all code (smart contracts) and state (data) are replicated and managed by each blockchain node via the Ethereum Virtual Machine (EVM). Existing projects utilize parallel EVMs, as shown in the center section of the diagram, where a single smart contract is deployed on a dedicated VM (or a VM in a shard designated to maintain consensus). All transactions related to the smart contract are processed by the VM (or the shard’s VM in a fully replicated manner).
In BitReXe’s unified parallelization model, all smart contracts are deployed across all VMs in the network, as shown in the right-most segment of the diagram. Smart contract state is partitioned and distributed across separate VM instances to ensure non-overlapping allocation. Smart contract transactions are segmented and distributed to be processed independently and in parallel across VMs accordingly. In the ideal case, this approach allows overall transaction throughput and state capacity to scale linearly as the number of VMs grows.
The main challenge is to efficiently manage dependencies between the execution logic (code) and the contract state (data) while enabling independent VM execution and avoiding synchronization, since the overarching execution logic of a transaction may require access to the contract state of multiple segments, each of which may reside in separate VMs after the state split.
Preda
Parallel relay execution distributed architecture (Preda) is a groundbreaking programming model designed to scale out smart contracts on sharded blockchains, parachain systems, and layer-2 blockchains. PREDA supports parallel architectures: if Ethereum’s Solidity can be likened to a program on a single-core CPU, BitReXe’s PREDA’s parallel architecture is similar to CUDA on NVIDIA GPUs.
The PREDA model introduces two main components: (1) “programmable contract scope”, which allows programmers to define partitions of contract state based on the application’s data access patterns, narrowing data access scope and minimizing data dependencies, and (2) “asynchronous function relay”, which allows programmers to clearly express transaction logic with implicit data dependencies, allowing flexible execution across multiple execution engines (VMs). Implemented as an extended Solidity language, PREDA includes additional syntax for programmable contract scope and asynchronous function relay statements.
This diagram shows the PREDA version of a simplified ERC20 contract. The “@address” keyword defines the scope of a user’s balance. This is equivalent to a map definition in Solidity, but specifies fine-grained separable state for splitting by address. At runtime, the state split by address is managed by a set of VMs in the BitReXe chain. Different states are not maintained by different sets of VMs. The transfer function in the “@address” scope is called by the payer (i.e. the user address initiating the transfer transaction) and initiates a “relay” for the payment to the recipient. This relay, executed by the VM hosting the recipient’s address state, adds the funds to the recipient’s balance.
In PREDA, a smart contract can have multiple scopes with variables and functions defined. A scope can have multiple functions and variables of any type, including containers. Multiple relays can be started by a single function call, conditionally or unconditionally, allowing recursive starts and moving transaction execution flows across multiple VM instances. This relay execution approach decomposes a transaction into multiple microtransactions, guaranteeing limited state access in a single virtual machine and avoiding race conditions. By decomposing a transaction into a “withdraw” microtransaction and a “deposit” microtransaction, the PREDA transfer smart contract allows these two types of microtransactions to run in parallel as long as the targets (addresses in this case) are mapped to different virtual machines.
BitReXe organizes virtual machines into multiple consensus groups, and each group independently runs a consensus protocol (PoW-based in our implementation) to reach consensus on the executed transactions. The consensus between groups is implemented to maintain the correctness and consistency of the asynchronous functional relay, which is implemented in BitReXe as relay transactions.
Bitcoin Layer 2
Luke states that asset issuance paradigms on the Bitcoin layer, such as imprint, constantly exploit Bitcoin’s vulnerabilities. Just as money never sleeps, imprint may never die. Bitcoin desperately needs a truly scalable Layer 2 that can release such pressure and prevent the rapid growth of ledger size that weakens decentralization. Such a goal is very likely not achievable with an EVM+bridge solution.
BitReXe proposes Parallel VM and PREDA to extend Bitcoin while at the same time adapting to Bitcoin security: it uses BTC as gas fee, shares Bitcoin security, and provides trustless asset settlement between the two chains.
BitReXe reuses the Bitcoin network’s hashing power carried by on-chain blocks, orphaned blocks, and immature blocks as proof-of-work to create valid blocks in the Layer 2 network without modifying the Bitcoin protocol. Merge-miners rxBTC Rewards are provided in Bitcoin pegged 1:1 on the BitReXe network. Users pay gas fees in rxBTC for transactions, interactions with smart contracts, and other on-chain activities. PREDA and BitReXe development team Fullnodes lab are introducing a trustless asset settlement bridge solution between Bitcoin and BitReXe. In this solution, an rxbtc peg-out is simultaneously someone’s BTC peg-in. An official peg-out address is no longer required, thus eliminating the assumption of trust.
Our high hopes for the Bitcoin ecosystem stem from its ability to solve problems that Bitcoin’s testnet, Ethereum, has yet to solve.
@Bit_ReXe believes that this issue stems from the lack of a parallel mechanism in the EVM, leading to the blockchain triple threat, which he aims to solve directly in Bitcoin Layer 2.
If we could solve this problem for Bitcoin, it would be a fundamental breakthrough for TVL to benchmark Ethereum on Bitcoin Layer 2 or outperform Ethereum by more than 3x.”
This is a guest post by BitPNova. The opinions expressed here are entirely BitPNova’s own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
