Overview

The Big Picture

A parallel EVM allows for multiple transactions to be processed concurrently, significantly improving the overall processing speed and performance of the network. However, adding concurrency support to the EVM directly would require extensive modifications to the standard implementation, leading to major forward and backward compatibility issues.

Arcology chose a more lightweight approach by intercepting the communication between the EVM and the StateDB to detect all the state access. This involves virtual no modification to the existing EVM implementation, therefore much more future proof than redesigning the EVM to add concurrency support.

Transaction-level

Arcology's concurrency happens at the transaction-level. In Arcology, each transaction is treated as an independent unit of execution, similar to how a thread operates in traditional computing systems. These transactions are processed concurrently by multiple Ethereum Virtual Machine (EVM) instances.

Each transaction in Arcology is like a thread in traditional systems, but there are some differences due to the unique characteristics of blockchain environments. Transactions can be executed in parallel as long as they do not conflict with each other in terms of accessing shared resources. The concurrency control mechanisms in Arcology ensure that transactions are processed in a way that avoids conflicts and maintains the consistency of the blockchain's state.

Distributed Design

Arcology adopts a distributed implementation that can coordinate multiple EVMs running on multiple interconnected machines in an inter-process scenario. Arcology's concurrency control can leverage the combined resources of multiple machines, enabling it to handle workloads that surpass the capabilities of a single machine. It is particularly beneficial for demanding applications or scenarios where the computational requirements exceed the capabilities of a single hardware unit.

Storage Only

In EVM, memory variables in a smart contract are local to each individual transaction and are not shared among different transactions. Each transaction's memory variables are isolated and private, ensuring that concurrent transactions do not interfere with each other's memory.

In contrast, storage variables are shared among transactions and are stored on the blockchain as part of the contract's state. Conflicts can arise when multiple transactions attempt to modify the same storage variable simultaneously. This is why Arcology's concurrency control mechanism focuses on managing conflicts related to storage variables while leaving memory variables out of the equation.

Slot

In the Ethereum Virtual Machine (EVM), a slot is the smallest data unit that the EVM keeps track of within a smart contract's storage. Each storage slot can hold 256 bits or 32 bytes of data. Smart contracts use these slots to store and manage their state variables, which are the persistent data values that the contract maintains. Each storage slot serves as the basic unit of storage granularity in Ethereum's smart contracts. Contracts can read from and write to individual storage slots.

A slot-level concurrency control design offers several advantages:

• Simplicity: Storage slots provide a clear and consistent unit of data storage within a smart contract. Concurrency control mechanisms operating at this granularity are straightforward to implement and reason about. By focusing on storage slots, concurrency control ensures that conflicting accesses to the same slot are properly detected. This helps maintain the consistency of the contract's state across multiple concurrent transactions.

• Minimized Overhead: As storage slots are a fundamental storage unit in Ethereum, a slot-level concurrency control design fits well with the underlying architecture of the EVM and blockchain. The granularity of storage slots allows for efficient conflict detection and resolution, minimizing the overhead associated with managing concurrent transactions.

• EVM Compatibility: Ethereum's EVM is built around the concept of storage slots, making slot-level concurrency control a natural fit that aligns with the platform's design. Developers and users can expect a consistent and predictable behavior when it comes to managing shared resources within smart contracts.

When a conflict occurs, with slot-level concurrency control and variable packing, since transactions don't access individual variables directly but rather access the entire slot, it can be more challenging to identify the specific variable causing a conflict.

Synchronization-Free

There is no inter-thread synchronization as each EVM instance operates in complete isolation. The state access operations are intercepted and temporally stored in separate read/write datasets during the execution.

Rule-Based Conflict Detection and Resolution

After transaction execution, a state conflict detection module comes into play. The state conflict detector employs a set of predefined rules to scrutinize the read and write sets of transactions.

Selective Commitment

Only those transactions that exhibit non-conflicting state changes are given the opportunity to commit their changes to the State DB. The transactions are only finalized if they do not interfere with the concurrent execution of other transactions.