Ethereum is still working on a complementary plan to parallel EVM, but Bitcoin could soon expect its own parallel VM layer 2.
Let's first understand why Ethereum cannot achieve parallel EVM.
To maintain network consistency and security, EVM has a critical design feature: it executes transactions sequentially. Sequential execution ensures that transactions and smart contracts can be executed in a specific order, making it easier to manage and predict the state of the blockchain. 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 possible to simply add paths? Refer to existing solutions for so-called parallel virtual machines, including partition chains such as Near. These chains proposed to expand the scope of the blockchain by introducing more virtual machines to extend the scope of smart contracts. Essentially, the workload of a single smart contract still resides in a particular virtual machine. If all smart contracts in this chain consume an equal amount of TPS, the problem will be solved. However, if only a few contracts, such as the Aave and Uniswap protocols, take up more than 90% of the block space, then having contracts running on a single shard only means chain-level scaling without benefiting from the improvements resulting from sharding. Adding lanes without the ability to switch lanes presents the current dilemma of virtual machine parallelization.
Parallel EVM involves chunking or caching data at the data layer. However, because it is limited by the EVM programming model, Solidity, as the most popular smart contract programming language, cannot maximize the potential of the parallel blockchain architecture. It's like not programming with SQL on an NVIDIA GPU. Hardness lacks expressions for parallel constructs such as relay implementation and lacks a definitive atom defined for parallel transactions.
True parallelism in blockchain architecture requires achieving the result that a single smart contract transaction can run on multiple virtual machines simultaneously. A programming model such as CUDA is needed to take full advantage of the parallel model in blockchain architecture.
Bitrixy Bitcoin introduces a 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 virtual machines, PREDA.
How BitReXe Achieves Parallel Vms on Bitcoin
Parallel virtual machines
The following infographic highlights the differences between BitReXe and other initiatives promoting parallel virtual machines. As shown in the leftmost part of the figure, Ethereum adheres to a single state machine model, where all tokens (smart contracts) and states (data) are replicated and managed by each blockchain node through its own Ethereum Virtual Machine (EVM). Existing projects use parallel electronic machines, as shown in the middle section of the figure, where a single smart contract is deployed on a dedicated virtual machine (or virtual machines within a particular segment to support consensus). All transactions related to the smart contract are processed by the virtual machine (or virtual machines for the part in a completely redundant manner).
In BitReXe's unified parallelization model, as shown in the rightmost part of the figure, all smart contracts are deployed across all virtual machines of the network. Smart contract instances undergo partitioning and distribution across distinct VM instances, ensuring non-overlapping allocation. In turn, smart contract transactions are hashed and distributed for independent and parallel processing across virtual machines. Ideally, this approach facilitates linear scaling of total transaction throughput and state capacity with an increasing number of virtual machines.
The primary challenge is to efficiently manage dependencies between execution logic (code) and contract state (data) while enabling independent VM execution and avoiding synchronization, since the end-to-end execution logic of a transaction may entail accessing multiple segments of contract states, each residing in separate VMs after Situation division.
Know
We present the distributed architecture for parallel execution (Know), an innovative programming model designed to scale smart contracts on participatory blockchains, parachain systems, and layer-2 blockchains. PREDA supports a parallel architecture: If Solidity for Ethereum is likened to software on a single-core CPU, then PREDA's parallel architecture for BitReXe is like CUDA for an NVIDIA GPU.
The PRIDA model introduces two main components: (1) “Programmable Node Scopes”, enabling programmers to define node state partitioning based on application data access pattern, narrowing the scope of data access and reducing data dependency; and (2) “asynchronous functional migration,” allowing programmers to articulate transactional 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 asynchronous functional migration statements.
The figure shows the PREDA version of a simplified ERC20 contract. The “@address” keyword defines the range of user credits, which is equivalent to defining a Solidity map but defines precise, separable instances for partitioning by address. At runtime, instances partitioned by address are managed by a set of virtual machines in the BitReXe chain. Different states are not maintained by different sets of virtual machines. The transfer function within the “@address” scope, called by payers (i.e. user addresses that initiate transfer transactions), initiates a “posting” of the deposit to the payee. This migration, which is performed by a virtual machine hosting the payee's address instances, adds funds to the payee's balance.
In PREDA, a smart contract can have multiple scopes with specific variables and functions. Multiple functions and variables can be defined of arbitrary types including containers in scope. Multiple relays can be started, conditionally or unconditionally, in a single function call, allowing for repeated initiation and enabling multi-hop transfer of the transaction execution flow across different VM instances. This relay execution method decomposes a transaction into multiple microtransactions, ensuring limited access to state in a single VM and avoiding race conditions. In the PREDA Transfer Smart Contract, parsing the transaction into a “withdraw” microtransaction and a “deposit” microtransaction allows parallel execution of these two types of microtransactions, as long as their targets (addresses in this case) are mapped to different virtual machines.
BitReXe organizes virtual machines into multiple consensus pools, each of which independently runs a consensus protocol (based on proof-of-work implementation) to reach consensus on executed transactions. Consensus is implemented across the pool to maintain the correctness and consistency of asynchronous functional relays, which are implemented as relay transactions in BitReXe.
Bitcoin layer 2
Locke says the model of issuing assets on the Bitcoin layer such as Pattern continually exploits a security vulnerability in Bitcoin. While money never sleeps, inscriptions may never die. Bitcoin is in desperate need of a truly scalable layer 2 that can release such pressure and save the size of the ledger from growing too quickly which will weaken decentralization. This goal is unlikely to be achieved with an EVM+Bridge solution.
BitReXe proposes parallel virtual machines and PREDA to scale Bitcoin. At the same time, it adapts to Bitcoin security. It uses BTC as gas fees, shares the security of Bitcoin, and provides trustless asset settlement between the two chains.
BitReXe reuses the hash computing power powered by the Bitcoin network that is transmitted by on-chain blocks, orphan blocks, and early proof-of-work blocks to create valid blocks in the Layer 2 network without modifying the Bitcoin protocol. Merge receive miners rxBTC As rewards, Bitcoin is pegged 1:1 on the BitReXe network. Users pay gas fees using rxBTC for transactions, interaction with smart contracts and other on-chain activities. Fullnodes Lab, PREDA and BitReXe development team are about to present a trustless asset settlement bridge solution between Bitcoin and BitReXe, where pegging rxbtc is at the same time pegging someone's BTC. Official link addresses are no longer required, thus the assumption of trust is 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 this issue stems from EVM's lack of parallel mechanisms leading to the blockchain trilemma and aims to solve it directly on Bitcoin Layer 2.
If this problem can be solved on Bitcoin, measuring TVL or even surpassing Ethereum by more than three times on Bitcoin Layer 2 would represent a fundamental breakthrough.”
This is a guest post by BitPnova. The opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.