Ethereum Virtual Machine EVM

EVM and Solidity

Smart contract development is a fundamental skill for blockchain engineers. Developers typically use Solidity or other high-level languages to implement business logic. However, the EVM cannot directly parse Solidity code and needs to compile it into low-level languages executable by the Virtual Machine, such as ( opcode/bytecode ). Currently, there are tools available that can automatically complete this conversion process, alleviating the burden on developers to understand the compilation details.

Although compiling introduces some additional overhead, engineers familiar with low-level coding can write program logic directly in Solidity using opcodes to achieve maximum efficiency and reduce gas consumption. For example, the trading protocol of a well-known NFT trading platform extensively uses inline assembly to minimize users' gas costs.

EVM Performance Differences: Standards and Implementations

The EVM(, also known as the "execution layer" ), is the final execution point for the compiled smart contract opcodes. The bytecode defined by the EVM has become the industry standard. Whether used for Ethereum Layer 2 networks or other standalone blockchains, compatibility with the EVM standard enables developers to efficiently deploy smart contracts across multiple networks.

Although following the EVM bytecode standard makes the Virtual Machine an EVM, the specific implementation can vary greatly. For example, one Ethereum client implements the EVM standard in Go, while another team from the Ethereum Foundation maintains a C++ implementation. This diversity allows for different engineering optimizations and custom implementations.

Parallel EVM Technology

Historically, the blockchain community has mainly focused on innovations in consensus algorithms, with some well-known projects becoming famous more for their consensus mechanisms than for their execution layers. Although these projects also have innovations in their execution layers, their performance is often mistakenly thought to stem solely from the consensus algorithms.

In fact, high-performance blockchains require a combination of innovative consensus algorithms and optimized execution layers, similar to the barrel theory. For EVM blockchains that only improve the consensus algorithm, enhancing performance often requires more powerful node hardware. For example, a well-known smart chain processes blocks under a gas limit of 2000 TPS, requiring machines far more powerful than Ethereum full nodes. Although a certain Layer 2 scaling solution theoretically supports up to 1000 TPS, actual performance often falls short of expectations.

demand for parallel processing

In most blockchain systems, transactions are executed in order, similar to a single-core CPU, where the next computation must wait for the current computation to complete before it can begin. This approach, while simple and with low system complexity, is difficult to scale to an internet-level user base. Shifting to a multi-core CPU parallel Virtual Machine can handle multiple transactions simultaneously, significantly improving throughput.

Parallel execution brings some engineering challenges, such as handling concurrent transactions writing to the same smart contract. New mechanisms need to be designed to resolve these conflicts. Parallel execution of unrelated smart contracts can proportionally increase throughput according to the number of parallel processing threads.

Innovation of Parallel EVM

Parallel EVM represents a series of innovations aimed at optimizing the execution layer of blockchain systems. Taking a certain project as an example, its key innovations include:

• Parallel Transaction Execution: Using an optimistic parallel execution algorithm, allowing multiple transactions to be processed simultaneously. This method starts transactions from the same initial state, tracks inputs and outputs, and generates temporary results for each transaction. It decides whether to execute the next transaction by checking if the inputs of the next transaction are related to the outputs of the currently processed transaction.

• Delayed Execution: In the consensus mechanism, nodes can achieve a formal ordering of transactions without requiring the master node or validation nodes to execute the transactions. Initially, the master node sorts the transactions and reaches a sequential consensus among the nodes. Execution is deferred to independent channels, maximizing block time and improving overall execution efficiency.

• Custom State Database: Optimizes state storage and access by directly storing the Merkle tree on SSDs. This approach minimizes read amplification effects, improves state access speed, and makes smart contract execution faster and more efficient.

• High-performance consensus mechanism: An improved version based on the HotStuff consensus mechanism, supporting synchronization among hundreds of globally distributed nodes, with linear communication complexity. It uses a pipelined voting phase, allowing different stages of the voting process to overlap, reducing latency and increasing consensus efficiency.

Challenges and Considerations

Parallel EVM faces two major challenges: the long-term engineering value capture of Ethereum and node centralization. Although the current development stage has not been fully open-sourced to protect intellectual property, these details will ultimately be disclosed when the testnet and mainnet are launched, facing the risk of being absorbed by Ethereum or other blockchains. Rapid ecosystem development will be key to maintaining a competitive advantage.

Centralization of nodes is a challenge for all high-performance blockchains, requiring a balance to be struck within the "Blockchain Trilemma." Metrics such as "TPS per hardware requirement" can help compare the efficiency of blockchains under specific hardware conditions, as lower hardware requirements can enable more decentralized nodes.

The Landscape of Parallel EVM

The parallel EVM architecture includes multiple projects, some of which are Layer 1 blockchains, while others may be Layer 2 solutions. Some projects are based on other networks, along with the development of open-source clients.

Currently, the existing parallel EVM networks can be divided into three categories:

1. EVM-compatible Layer 1 networks upgraded through parallel execution technology: These networks initially did not adopt parallel execution and were upgraded through technological iterations to support parallel EVM.

2. EVM-compatible Layer 1 network that adopts parallel execution technology from the very beginning.

3. Layer 2 networks using non-EVM parallel execution technology: These include scalability-oriented Layer 2 EVM-compatible chains. These networks abstract the EVM into pluggable execution modules, allowing the selection of the best "VM execution layer" as needed to achieve parallel capabilities.

Conclusion

With the development of blockchain technology, attention to the execution layer and consensus algorithms is equally important to achieve high performance. Innovations such as parallel EVM offer promising solutions to improve throughput and efficiency, making blockchain more scalable and capable of supporting a broad user base. The development and implementation of these technologies will shape the future of the blockchain ecosystem, driving further progress and application in the field.