# EU 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. Each transaction occupies an independent EU instance, completely isolated from others. There is no intercommunication between these instances while running. Only when all transactions are completed will the system assemble them to check for potential conflicts.
### 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. {% hint style="success" %} **The minor modifications made to the original EVM implementation remain entirely transparent to the smart contract developers.** {% endhint %} ### 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.arcology.network/parallel-execution-design/eu.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.