State Operations

In Arcology, a "state operation" refers to a specific action that a transaction performs on the data items stored in the StateDB. Operations are used to interact with the data, retrieve information or make changes. Each operation corresponds to a certain type of interaction with the data, and the Arcology processes these operations to manage the underlying database efficiently and maintain data integrity.

Operations

There are three types of state operations.

1. Read

The "read" operation retrieves data from the database without making any changes to it. Read operations provide information to the user or application and are essential for querying the StateDB.

2. Write

In Arcology's concurrent execution design, a "write" operation refers to an action where a transaction modifies the value of a data item in the StateDB. Unlike read operations that retrieve data without changing it, write operations involve updating data to reflect new information or changes made by the transaction.

3. Delta Write

Arcology supports delta-write on selected data types only. Please refer to concurrent API document for more details.

A "delta write," also known as a "delta update" or "delta change," refers to a type of data modification operation in Archology where the change made to a data item is recorded as the difference or "delta" between the new value and the original value. The delta change represents the incremental update that needs to be applied to the original value to get the new value.

Delta changes can reduce conflicts between transactions that attempt to modify the same data item. Since the actual update is deferred until later, transactions can accumulate their changes without immediately conflicting with each other's write operations.

The "write" operations on the same data item by multiple transactions can lead to conflicts, requiring transactions to be reverted. With delta writes, the conflicts can be reduced because transactions are not directly modifying the original data. Instead, they're recording delta changes, which can often be applied without conflicts during read operations.

The "Delta write" operation as the following key features:

• Deferred Application: Instead of directly modifying the original value of a data item when an update is performed, a delta change is not immediately applied to the original value during the update operation. Instead, it's recorded or stored separately.

• Conversion to Write: The delta change is only converted into an actual write operation when a read operation needs to access the data. At this point, the delta change is applied to the original value, and the updated value is then used for the read operation. This ensures that the most up-to-date value, including the applied delta changes, is provided to the user.

• Transaction Commit: The delta changes are applied when the transaction that made the changes is committed. This happens when a new block is produced.

Comparison

There are some key differences between the "write" and "delta write" operation:

• Data Update: A write operation replaces the original data with the new data, while a "delta write" records the change that needs to be applied to the original data.

• Immediate vs. Deferred Update: A write operation immediately updates the data, while a delta write defers the update until a read operation is performed, or the transaction is committed.

• Read Overhead: Delta writes can introduce computational overhead during read operations because the delta changes need to be applied before providing the data to the user. Writes don't have this additional overhead during reads.