Concurrency Control

Parallelization & Concurrency Control Models

Parallelization is widely used in to improve system throughput. All modern supercomputers are parallel machines, and even quantum computers utilize this principle to achieve their goals. By allowing multiple transactions or tasks to be executed concurrently, parallel processing can significantly boost blockchain throughput. This approach capitalizes on modern multi-core processors and distributed architectures, maximizing the utilization of computational resources. Arcology is built around the idea of parallel transaction execution.

A key challenge with parallel execution is managing concurrent access to shared resources while maintaining state consistency. The concurrency control system is responsible for this task.

---

Control Strategies

Concurrency control models have been extensively researched and validated in conventional computing settings, providing a solid foundation for understanding concurrency and data access patterns. There are two major concurrency control strategies: Pessimistic Concurrency Control (PCC) and Optimistic concurrency control (OCC). Both approaches aim to improve the scalability of blockchain networks, but they differ in their focus and implementation.

Pessimistic Concurrency Control

Pessimistic concurrency control involves locking resources to prevent conflicts between multiple concurrent transactions. This approach assumes that conflicts are likely to occur and tries to prevent them from happening.

Pros:

• Provides strong consistency guarantees

• Prevents conflicts before they occur, reducing the likelihood of rollbacks

• Suitable for systems with high contention and low throughput

Cons:

• Can lead to blocking and reduced concurrency if there are many conflicts

• Can lead to deadlock if locks are not released properly

• Can reduce system performance if locks are held for a long time.

In blockchain environments, pre-declaring resources can pose challenges due to the inherent difficulty in accurately predicting which states will be accessed during transaction execution. Consequently, resource declarations often need to be coarse-grained, potentially limiting concurrency in many scenarios.

Optimistic Concurrency Control

The basic idea behind OCC is to allow concurrent access to shared resources and only check for conflicts at the time of update. In other words, if multiple threads are accessing the same data, each thread can make changes to that data without checking with the others, assuming that there will be no conflicts.

When a thread tries to commit its changes, the system checks whether there have been any conflicts with changes made by other threads. If there are no conflicts, the changes are committed; otherwise, the thread must roll back its changes and retry.

OCC works by allowing all threads to make changes to the data without any locking, assuming that there will be no conflicts. However, if a conflict does occur, one of the threads must roll back its changes and retry, which can lead to reduced performance.

There are some pros and cons to using OCC in this context:

Pros:

• OCC can provide better throughput than traditional synchronization-based mechanisms.

• It can help reduce the amount of contention for shared resources.

• Developers typically don’t need to manually manage resource to avoid potential conflicts.

Cons:

• OCC is most effective when contention is low, and conflicts are relatively rare.

• OCC can result in higher rollback rates if conflicts occur frequently.

• OCC requires careful tuning to ensure that it provides the desired performance benefits.

---

Issues With traditional Design

One of the key limitations of traditional concurrency control mechanisms is their lack of determinism. While determinism is mostly optional in traditional computing environments, it is a critical requirement for blockchain systems due to their decentralized and consensus-driven nature. Blockchains demand that all participants agree on the outcome of executed transactions, necessitating a deterministic behaviors across all nodes.

Arcology's Concurrency Control

Arcology's concurrency controls employs a hybrid approach that combines both optimistic and pessimistic control models to effectively manage all concurrency-related issues with a number of key characteristics:

• Secure & Deterministic: The concurrency control system must ensure that concurrent executions follow security protocols and maintain the integrity of the blockchain data. Unlike traditional databases, blockchain networks require deterministic execution to achieve consensus among nodes. This means that parallel-processed transactions must produce consistent results, ensuring all nodes in the network reach the same final state. Therefore, the concurrency control system must enforce deterministic execution.

• Efficiency: Optimistic concurrency control inherently more sensitive to the conflicts when multiple transactions access shared resources concurrently. A proper blockchain native concurrency control system must offer means to help and incentivize smart contract developers write conflict free smart contracts.

• Usability: One of the goals of a concurrency control system is to empower developers to write efficient and contention-free smart contracts. Providing user-friendly APIs and tools that abstract the complexities of concurrency control can simplify the development process and encourage best practices in concurrent programming.

In addition, given that optimistic concurrency control is sensitive to conflicts, Arcology also offers a concurrent library in Solidity to help developers write conflict-free contracts.