EU

The Transaction Execution Unit

Arcology introduces a new concept called Execution Unit. The EU is an abstracted execution unit for transaction processing on the Arcology network and consists of a number of carefully designed modules.

L1 Sequential EVM

The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts on the Ethereum blockchain. Arcology focuses on inter-VM parallelization, leveraging multiple sequential EVM instances to enable concurrent transaction processing across isolated execution units (EUs). Each EU runs a single EVM instance. Arcology makes no major modifications to the original EVM implementation. Its core functionality remains unaltered and is treated as a black box within the system.

The minor modifications made to the original EVM implementation remain entirely transparent to the smart contract developers.

StateDB Adaptor

EVM works closely with the state DB for state access. To work with the original EVM implementation, the Execution Unit (EU) also includes Cache and implementations of the StateDB interfaces, to replace the original state DB and bridge between the original EVM and the underlying Arcology storage layer.

The adaptor also intercepts and tracks communications between the EVM and the StateDB to monitor all state access.

Local Cache

Each Execution Unit (EU) maintains a transaction-level cache that temporarily stores state data before committing it to the StateDB. In addition to buffering writes, the cache also tracks all accessed state entries during execution.

At the end of each transaction, the cache:

• Sends its RW set to the global conflict detection module, and

• Resets itself to prepare for the next transaction.

Read/Write Sets

Each EU instance has its own Read/Write (RW) Set for each transaction it processed, which records the state accessed and modified by the transactions it processes. After a transaction is executed, its RW set is submitted to a global conflict detector, which checks for overlapping state access with other transactions in the same generation. Transactions that conflict are reverted to preserve state consistency. The set plays a critical role in tracking state changes and detecting conflicts during parallel execution.

Concurrent Extension

In Arcology, the integration of Arcology's concurrency control with the original L1 EVM is achieved through a lightweight extension. The extension facilitates communication between the VM and the concurrency control module. This approach aims to minimize disruptions to the existing EVM workflow while adding the necessary components for concurrency control.

API Handlers

The module acts as a bridge between the EVM and Arcology's concurrency control system. It allows developers to directly utilize the parallel design execution features through the concurrent APIs in native Solidity. The module manages concurrent API calls within contracts, providing controlled access to Arcology's parallel execution capabilities.