System Components
Last updated
Last updated
Arcology's concurrency architecture is designed to support efficient and scalable execution of smart contracts through parallel processing and conflict management. The system components work together to achieve this goal by leveraging advanced concurrency control mechanisms and innovative design principles. Below is an overview of the key components that make up Arcology's system:
Arcology's Concurrent API is a collection of Solidity-based data structures and tools designed to enable developers to create contention-free smart contracts that leverage the platform's parallel execution capabilities.
Arcology has adopted a straightforward approach by incorporating lightweight plugins into the standard EVM implementation, enabling the interception of communications between the EVM and the StateDB to monitor all state access.
The EU is an abstracted execution unit for transaction processing on the Arcology network. Each instance handles a subset of the transactions provided by the scheduler. Each EVM instance has its own Read/Write (RW) Set, which keeps track of the state changes (reads and writes) made by the transactions it processes. The module consists of:
EVM: The Ethereum Virtual Machine.
EVM-adaptor: Middleware that connects to the parallelized EVM, handling executable messages and producing state transitions.
Local Write Cache: Temporarily stores data before committing to the stateDB.
This set contains the data read from and written to the state database by the transactions processed by an EVM instance. It's essential for tracking the changes made by each instance to detect any conflicts.
When a list of transactions comes into the scheduler in Arcology's parallel execution architecture, it performs a static analysis of the transactions to to understand their characteristics, such as dependencies, conflict history, resource requirements, and priorities.
The scheduler then groups transactions based on their characteristics, clustering those that are less likely to conflict with each other into the same group, called generations. There can be multiple generations. Transactions within the same generation are executed in parallel, while different generations are executed sequentially.
In optimistic concurrency control, transactions are allowed to proceed without acquiring locks initially. Conflict detection happens during the validation phase before committing. Transaction causing conflict will be reverted and re-executed to maintain data consistency. This approach assumes conflicts are infrequent, so the success of OCC depends largely on keeping conflicts to a minimum.
Arcology's transaction scheduler aims to find a balance between minimizing the chance of transaction rollbacks and maximizing parallel execution. It is an integral part of the concurrency control system.
In Arcology, transaction Scheduler is a critical component dedicated to optimizing transaction processing. The scheduler aims to balance the benefits of parallel processing between different batches of transactions while maintaining the state consistency. A well-designed scheduler can significantly reduce the chances of conflicts and the need for rollbacks.
When a list of transactions comes into the scheduler in Arcology's parallel execution architecture, it performs a static analysis of the transactions to to understand their characteristics, such as dependencies, conflict history, resource requirements, and priorities.
The scheduler then groups transactions based on their characteristics, clustering those that are less likely to conflict with each other into the same group, called generations. There can be multiple generations. Transactions within the same generation are executed in parallel, while different generations are executed sequentially.
The scheduler takes into account several factors to create a scheduling plan:
Resources Available: The availability of system resources, such as CPU cores, and memory directly impacts the scheduling plan. The scheduler allocates resources efficiently to maximize utilization and throughput. The scheduler can prevent resource contention, bottlenecks, and performance degradation.
Transaction Characteristics: Different transactions have varying characteristics that influence their scheduling. For example:
Transaction Priority: High-priority transactions might need to be scheduled before lower-priority ones.
Resource Requirements: Some transactions require more resources than others. The scheduler needs to allocate resources appropriately to ensure fair treatment.
Conflict History: The conflict history provides insights into how transactions have interacted in the past. By analyzing past conflicts and their resolutions, the scheduler can make better predictions about potential conflicts by putting the conflict-prone transaction into serial execution sequences.
A full scheduling plan consists of a number of parallel batches called generations:
Inter-Batch Parallelization: Different batches are processed simultaneously, leveraging available system resources and improving overall throughput.
Intra-Batch Serial Execution: Within each batch, transactions are executed in a strictly sequential manner. This intra-batch serial execution ensures that the conflict-prone transactions within a batch do not conflict with each other.
This approach can help manage resources efficiently and minimize contention.
In Arcology's parallel execution environment, a conflict detector is a module that examines the read and write sets of transactions after their execution to identify instances where multiple transactions have accessed the same shared resources concurrently, potentially resulting in conflicts.
When all the executions in a single generation are completed, the conflict detector checks the RW sets for conflicts. If two or more transactions attempt to modify the same data concurrently, a conflict is detected.
Once the conflict detector has verified that there are no conflicts (or has resolved any that were found), the state changes can be committed to the state database. Clear transitions represent the successful commitment of these changes to the state database, ensuring the blockchain state is updated consistently.
Apart from conflict detection, the conflict detector will also provide conflicting information about the interactions and conflicts that have occurred between past transactions. The transaction scheduling module uses the conflict history to make informed decisions about how to schedule transactions concurrently. Learning from the conflict history, the system can optimize scheduling to reduce contention, improve throughput, and minimize rollbacks.