BitReXe: Enabling Parallel VMs on the Bitcoin Network

Ethereum is still developing complementary plans for parallel EVMs, but Bitcoin will soon be expecting its own parallel VM layer 2.

First, let’s understand why Ethereum cannot achieve parallel EVM.

To maintain network consistency and security, EVMs have important features in their design. Transactions are executed sequentially. Sequential execution allows transactions and smart contracts to execute in a deterministic order, making blockchain state easier to manage and predict. This design choice prioritizes security, reducing the potential complexity and vulnerabilities associated with parallel execution. However, under high transaction request loads, this sequential execution can lead to network congestion and delays, similar to a single-lane highway.

Is it possible to simply add a lane? It refers to existing solutions of so-called parallel VMs, including sharding chains such as Near. These chains proposed to scale the blockchain by introducing more VMs to scale smart contracts. Basically, the workload of one smart contract still resides on a specific VM. The problem is solved if all smart contracts on this chain consume the same amount of TPS. However, when only a few contracts, such as the Aave and Uniswap protocols, consume more than 90% of the block space, running contracts on a single shard means that they do not benefit from the improvements that sharding brings and only scale at the chain level. Adding lanes without the ability to switch lanes represents the current dilemma in VM parallelization.

Parallel EVM involves truncating or caching data in the data layer. However, due to EVM’s programming model, Solidity, the most widely used smart contract programming language, cannot maximize the potential of parallel blockchain architectures. This is similar to not programming with SQL on NVIDIA’s GPUs. Solidity lacks representation for parallel architectures such as Relay Execution and lacks final atomicity defined for parallel transactions.

True parallelism in blockchain architecture requires achieving the result that transactions in one smart contract can be executed simultaneously on multiple VMs. To fully utilize the parallel model in blockchain architecture, a programming model such as CUDA is required.

BitReXe noted that Bitcoin has introduced Turing-complete parallel VM Layer 2 to provide underlying infrastructure support for real-world applications in the Bitcoin ecosystem and PREDA, a proprietary programming model for parallel VMs.

How BitReXe Achieves Parallel VMS on Bitcoin

Parallel VMs

The following figure highlights the differences between BitReXe and other initiatives promoting parallel VMs. As shown in the leftmost part of the figure, Ethereum adheres to a single system state model, where all code (smart contracts) and state (data) are replicated and managed on each blockchain node via the Ethereum Virtual Machine (EVM). Existing projects utilize parallel EVMs, as shown in the middle part of the figure. Here, a single smart contract is deployed on a dedicated VM (or a VM within a designated shard to maintain consensus). All transactions involving smart contracts are processed by VMs (or, in a fully replicated manner, VMs in a shard).

As shown in the rightmost part of the figure, in BitReXe’s integrated parallelization model, all smart contracts are deployed to all VMs in the network. The state of the smart contract is partitioned and distributed across different VM instances to ensure non-overlapping allocations. Accordingly, transactions in smart contracts are partitioned and distributed for independent and parallel processing across VMs. Ideally, this approach promotes linear scaling of overall transaction throughput and state capacity as the number of VMs increases.

The main challenge is to efficiently manage dependencies between execution logic (code) and contract state (data) while enabling independent VM execution and avoiding synchronization. This is because the comprehensive execution logic of a transaction may involve access to multiple segments of contract state, each of which resides. After the state is split, it is stored in a separate VM.

teach

Introducing Parallel Relay-Execution Distributed Architecture (PREDA), a groundbreaking programming model designed to scale smart contracts on sharded blockchains, parachain systems, and layer 2 blockchains. PREDA supports parallel architecture. If Solidity for Ethereum is likened to programming on a single-core CPU, PREDA’s parallel architecture for BitReXe is similar to CUDA for NVIDIA GPUs.

The PREDA model introduces two main components: (1) “Programmable contract scope,” which allows programmers to define contract state partitioning based on the data access patterns of the application, narrowing the scope of data access and minimizing data dependencies; (2) “Asynchronous Functional Relay” allows programmers to clearly express transaction logic using 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 relaying asynchronous functions.

The figure shows a simplified PREDA version of the ERC20 contract. The “@address” keyword is equivalent to a map definition in Solidity, but defines a user balance range that specifies a granular and separable state for partitioning by address. At runtime, the state partitioned by address is managed by a set of VMs in the BitReXe chain. Different sets of VMs do not maintain different states. A transfer function within the scope “@address” that is called by the payer (i.e. the user address initiating the transfer transaction) initiates a “relay” to deposit the money to the payee. This relay, run by a VM hosting the recipient’s address state, adds funds to the recipient’s balance.

In PREDA, smart contracts can have multiple scopes where variables and functions are defined. Multiple functions and variables of arbitrary types, including containers, can be defined in a scope. Multiple relays can be started from a single function call, conditionally or unconditionally, allowing for recursive starting and allowing the transaction execution flow to traverse multiple hops across multiple VM instances. This relay execution approach decomposes transactions into multiple micro-transactions, ensuring limited state access and preventing race conditions in a single virtual machine. By decomposing transactions into “withdrawal” microtransactions and “deposit” microtransactions in the PREDA transfer smart contract, these two types of microtransactions can be executed in parallel as long as the destination (in this case the address) is: Maps to another virtual machine.

BitReXe organizes virtual machines into multiple consensus groups, each group independently running a consensus protocol (PoW-based in its implementation) to reach consensus on executed transactions. Asynchronous functions implemented as relay transactions in BitReXe To maintain the correctness and consistency of relays, inter-group consensus is implemented.

Bitcoin Layer 2

Asset issuance paradigms in Bitcoin’s layer, such as Inscription, continue to exploit Bitcoin’s vulnerabilities, Luke says. Just as money never sleeps, while inscriptions never die. Bitcoin desperately needs a scalable Layer 2 that can alleviate that pressure and prevent ledger size from growing too quickly, undermining decentralization. These goals are unlikely to be achieved with an EVM+Bridge solution.

BitReXe proposes parallel VMs and PREDA for Bitcoin scaling. At the same time, it also adapts to the security of Bitcoin. It uses BTC as a gas fee, shares the security of Bitcoin, and provides trustless asset settlement between the two chains.

BitReXe reuses the hashing computing power of the Bitcoin network, performed by on-chain blocks, orphan blocks, and premature blocks, as a proof-of-work to generate valid blocks in the layer 2 network without modifying the Bitcoin protocol. Merge miners are rewarded with rxBTC, a Bitcoin pegged 1:1 to the BitReXe network. Users pay gas fees in rxBTC for transactions, smart contract interactions, and other on-chain activities. Fullnodes Labs, the development team behind PREDA and BitReXe, plans to introduce a trustless asset settlement bridge solution between Bitcoin and BitReXe that pegs in someone’s BTC while simultaneously pegging out rxbtc. The official pegout address is no longer needed, so the trust assumption is removed.

Our high expectations for the Bitcoin ecosystem stem from its ability to solve problems that Bitcoin’s testnet, Ethereum, could not.

@Bit_ReXe believes that this problem stems from the EVM’s lack of parallel mechanisms leading to a blockchain trilemma and aims to solve it directly at Bitcoin Layer 2.

“If this problem can be solved in Bitcoin, then a more than 3x outperformance of Ethereum on the TVL benchmark or even Bitcoin Layer 2 would represent a fundamental breakthrough.”

This is a guest post by BitPnova. The opinions expressed are solely personal and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.