Storage State Access

Concurrent State Mangement

This workflow is 100% transparent to smart contract developers.

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.

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.

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, the new workflow is described below:

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.


That this is just a fictional representation and might differ from the ones use in Arcology.

Blow is an illustrative example of a JSON structure that represents the information about variables, read and write operations, updated values, and transaction IDs.

  "variables": [
      "variable_name": "variable_A",
      "slot_id": "slot_1",
      "read_operations": 3,
      "write_operations": 1,
      "updated_value": "new_value",
      "transaction_ids": ["txn_123", "txn_456", "txn_789"]
      "variable_name": "variable_B",
      "slot_id": "slot_2",
      "read_operations": 2,
      "write_operations": 0,
      "updated_value": null,
      "transaction_ids": ["txn_456", "txn_789"]
      "variable_name": "variable_A",
      "slot_id": "slot_3",
      "read_operations": 1,
      "write_operations": 0,
      "updated_value": null,
      "transaction_ids": ["txn_123"]
  • Variable Name (Slot ID): This field would indicate the name or identifier of the state variable being accessed, along with its corresponding slot ID. This helps in grouping variables that share the same slot.

  • Number of Read Operations: This field would represent the count of read operations performed on this variable by the transaction.

  • Number of Write Operations: Similarly, this field would indicate the count of write operations executed on the variable.

  • Updated Value: If there were write operations, this field would include the updated value after the write operation.

  • Transaction IDs: This field would list the IDs of transactions that accessed this variable, indicating which transactions were involved in reading or writing this variable.


By redirecting all state accesses through the RW set, Arcology ensures that every change made to the blockchain's state is first recorded within the transaction's RW set. This enables the system to analyze potential conflicts among concurrently executing transactions and only committing the clear updates to the StateDB at the end of each blocking cycle.

Last updated