Local Cache

Concurrent State Mangement

One of the key aspects of concurrency control is to ensure the proper management and protection of shared resources from concurrent accesses by multiple transactions, which is something original EVM totally lacks. In order to incorporate the concurrency control to the EVM, it is necessary to capture and protect all state accesses initiated by the EVM during transaction execution.

This workflow is 100% transparent to smart contract developers.

State Access Redirection

The original EVM interacts with the StateDB using a set of interfaces. These interfaces facilitate operations related to the blockchain's state, including reading and writing to storage variables. To capture all the state accesses, Arcology has re-implemented these interfaces. Instead of directly performing state access operations on the underlying StateDB, this re-implementation involves redirecting all state-related requests initiated by the EVM to the read/write set associated with the executing transaction.

During execution, the cache intercepts and records all state access attempts. Once execution is complete, these records are sent to the conflict detector, which checks for potential conflicts before finalizing the updates. Only the transitions from clear Transactions are going to be persisted to the storage.

RW Set

In Arcology, the RW set acts as an intermediary buffer that contains the data items that a transaction reads values from during its execution and the data items a transaction modifies or updates. The RW sets helps in conflict detection and resolution. It is crucial for execution isolation and detecting conflicts between transactions in Arcology's concurrent execution design.

How It Works

In Arcology's concurrency control mechanism, the state access workflow has been modified.

1. Initialization

The read/write sets of a transaction are initialized at the beginning of the transaction's execution. When a transaction starts, it records the data elements it intends to read and write as part of its read/write sets. These sets are populated based on the specific operations and data accesses performed by the transaction during its execution.

2. Redirection

When a transaction executes and accesses the blockchain's state, such as reading from or writing to storage variables, the modified stateDB implementation intercepts these accesses. Instead of directly interacting with the underlying stateDB, the system redirects the access to the RW set associated with the executing transaction. The relevant information about the state access is recorded within the RW set.

3. Buffering

The RW set acts as a temporary buffer that holds information about the state accesses made by a transaction during its execution. This redirection of state accesses to the RW set allows Arcology's concurrency control mechanism to analyze and manage these accesses in a way that enables conflict detection, resolution, and deterministic execution, ultimately leading to consistent and reliable results within the blockchain's state.

4. Submission

The accumulated state changes within the read/write (RW) buffer are assembled into a data package. This data package is then forwarded to an independent module referred to as the "Arbitrator." The Arbitrator module is tasked with the crucial role of conflict detection, where it examines the contents of the RW sets to identify potential conflicts among concurrently executing transactions.

5. Clearing

After a transaction completes its execution, all the state the read/write sets are cleared. This happens before the transaction is either committed or aborted, depending on the outcome of its execution. Clearing the read/write sets ensures that the transaction's impact on the blockchain state is appropriately managed based on its success or failure.