ethereum is still working on a companion plan for parallel EVM, but bitcoin can soon look forward to its own Layer 2 parallel VM.
First of all, let's 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 state of the blockchain. This design choice prioritizes security, reducing the potential complexities and vulnerabilities associated with parallel execution. However, under a large number of transaction requests, this sequential execution may cause network congestion and delays, similar to a one-lane highway.
Is it feasible to simply add lanes? It refers to existing solutions of so-called parallel virtual machines, including sharding chains such as Near. These chains proposed to scale blockchain by introducing more virtual machines to scale smart contracts. Basically, the workload of a smart contract still resides in a certain virtual machine. If all smart contracts on this chain consume the same amount of TPS, then the problem is solved. However, if only a few contracts, such as the Aave and Uniswap protocols, consume more than 90% of the block space, having contracts running on a single shard means only scaling to the chain level without benefiting from the improvements that sharding brings. Adding lanes without the ability to switch lanes represents the current dilemma of virtual machine parallelization.
Parallel EVM involves slicing or caching data at the data layer. However, limited by the EVM programming model, Solidity, as the most popular smart contract programming language, cannot maximize the potential of parallel blockchain architecture. It's like not programming with SQL on the NVIDIA GPU. Solidity lacks expressions for parallel architectures like Relay Execution and lacks a final atomicity defined for parallel transactions.
True parallelism in blockchain architecture requires ensuring that smart contract transactions can be executed on multiple virtual machines simultaneously. A programming model like CUDA is needed to fully take advantage of a parallel model in the blockchain architecture.
BitReXe mentions that bitcoin features Turing Complete Parallel VM Layer 2 to provide underlying infrastructure support for real applications in the bitcoin ecosystem and a unique 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 that promote parallel virtual machines. As shown in the leftmost segment of the figure, ethereum adheres to a single-machine state model, in which all code (smart contracts) and states (data) are replicated and managed by each blockchain node through its ethereum Virtual Machine (EVM). Existing projects use parallel EVMs, as shown in the middle section of the figure, where a single smart contract is deployed on a dedicated VM (or VM within a designated shard to maintain consensus). All transactions related to the smart contract are processed by the VM (or VMs in the shard in a fully duplicate manner).
In BitReXe's unified parallelization model, as shown in the rightmost segment of the figure, all smart contracts are deployed to all virtual machines in the network. The states of a smart contract are split and distributed across different VM instances, ensuring non-overlapping allocation. Consequently, smart contract transactions are segmented and distributed for independent and parallel processing between virtual machines. Ideally, this approach facilitates linear scaling of overall transaction throughput and state capacity with increasing numbers of virtual machines.
The main challenge lies in efficiently managing the dependencies between the execution logic (code) and the contract state (data), while allowing independent execution of the VM and avoiding synchronization, since the execution logic Integration of a transaction may involve access to multiple segments of contract states, each of which resides on separate virtual machines after state partitioning.
teach
Introducing the Distributed Parallel Relay Execution Architecture (teach), an innovative programming model designed to scale smart contracts on sharded blockchains, parachain systems, and layer 2 blockchains. PREDA supports a parallel architecture: if Solidity for ethereum is compared to a program on a single-core CPU , PREDA's parallel architecture for BitReXe is similar to CUDA for the NVIDIA GPU.
The PREDA model introduces two key components: (1) “Programmable Contract Scopes”, which allow programmers to define contract state partitioning based on the application's data access pattern, reducing the data access range and minimizing data dependency; and (2) “Asynchronous Functional Relay,” which allows 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 declarations for asynchronous functional relaying.
The figure illustrates the PREDA version of a simplified ERC20 contract. The “@address” keyword defines the scope of user balances, equivalent to Solidity's map definition, but specifies detailed, separable states for partitioning by address. At runtime, address-split states are managed by a set of VMs on the BitReXe chain. Different sets of virtual machines do not maintain different states. The transfer function within the scope “@address”, invoked by payers (i.e. user addresses initiating transfer transactions), initiates a “relay” to deposit to the payee. This relay, executed by a virtual machine that hosts the beneficiary's address states, adds funds to the beneficiary's balance.
In PREDA, a smart contract can have multiple scopes with defined variables and functions. Multiple functions and variables of arbitrary types, including containers, can be defined in a scope. Multiple relays can be started, conditionally or unconditionally, in a single function call, enabling recursive starting and allowing the transaction execution flow to move in multiple hops between different VM instances. This relay execution approach decomposes a transaction into multiple microtransactions, ensuring limited state access on a single virtual machine and avoiding race conditions. In the PREDA transfer smart contract, decomposing the transaction into a “withdrawal” microtransaction and a “deposit” microtransaction allows parallel execution of these two types of microtransactions, as long as their goals (addresses in this case) are assigned to different ones. Virtual machines.
BitReXe organizes virtual machines into multiple consensus groups, each of which independently executes a consensus protocol (based on PoW in the implementation) to reach a consensus on executed transactions. Cross-group consensus is implemented to maintain the correctness and consistency of asynchronous functional relays, implemented as relay transactions in BitReXe.
bitcoin layer 2
The asset issuance paradigm at the bitcoin layer, like enrollment, consistently exploits a vulnerability in bitcoin, Luke says. While money never sleeps, just as inscriptions never die. bitcoin desperately needs a truly scalable layer 2 that can release that pressure and prevent the size of the ledger from growing too quickly, which will weaken decentralization. It is highly unlikely that this goal will be achieved with 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 a gas fee, shares the security of bitcoin, and provides trustless asset settlement between the two chains.
BitReXe reuses the hash computing power of the bitcoin network, which is transported via on-chain blocks, orphan blocks, and premature blocks as proof-of-work to create valid blocks on the Layer 2 network without modifying the bitcoin protocol. The merged miners receive rxBTC as a reward, a bitcoin linked 1:1 on the BitReXe network. Users pay gas fees with rxBTC for transactions, interaction with smart contracts, and other on-chain activities. Fullnodes lab, PREDA and BitReXe development team is about to introduce a trustless asset settlement bridge solution between bitcoin and BitReXe, where pegging rxbtc is at the same time pegging someone's btc. Official connection addresses are no longer required, eliminating the assumption of trust.
Our high expectations for the bitcoin ecosystem stem from its ability to solve problems that ethereum, as a bitcoin testnet, has not addressed.
@Bit_ReXe believes this problem is because EVM lacks parallel mechanisms leading to the blockchain trilemma and aims to solve it directly in bitcoin's layer 2.
If this problem can be solved in bitcoin, then benchmarking TVL or even outperforming ethereum by more than three times at bitcoin Layer 2 would present a fundamental breakthrough.”
This is a guest post from BitPnova. The opinions expressed are entirely their own and do not necessarily reflect those of btc Inc or bitcoin Magazine.
