Parallel Execution Model
Last updated
Last updated
Arcology's parallel execution and concurrency control utilizes an optimistic strategy, specifically tailored for blockchain requirements. It allows transactions to proceed concurrently without preemptive acquiring locks or other synchronization mechanisms.
Hybrid Concurrency Control Strategy: Arcology employs a hybrid control strategy, primarily focusing on an optimistic approach.
Conflict Detection and Resolution: The state conflict detector employs a set of predefined rules to scrutinize the read and write sets of transactions.
Commutativity-Centric Design: The system is built around the principle of . Any operation that breaks this property during parallel execution is considered a conflict, and the associated transaction is reverted to maintain consistency.
EVM Integration: Arcology's parallel execution engine seamlessly integrates with the standard EVM implementations, adding minimal code and plugin modules. This guarantees 100% compatibility and allows effortless upgrades to the latest EVM versions.
Selective Commitment: Only those transactions that exhibit non-conflicting state changes are given the opportunity to commit their changes to the State DB. The transactions are only finalized if they do not interfere with the concurrent execution of other transactions.
Concurrent APIs in Solidity: Optimistic concurrency control excels only when contention is low. To address this issue, Arcology's offers a set of data structures and tools designed to empower smart contract developers in creating efficient, contention-free code that fully capitalizes on Arcology's parallel execution design.
Distributed Design: Arcology's concurrency control is capable of coordinating EVM instances across a network of interconnected machines, enhancing scalability beyond what a single machine can offer.
The system is built around the principle of . Any operation that breaks this property during parallel execution is considered a conflict, and the associated transaction is reverted to maintain consistency.
Arcology's concurrency architecture is designed to efficiently and execute smart contracts through parallel processing and conflict management. On Arcology, each transaction occupies an independent EU instance, completely isolated from others. There is no intercommunication between these instances while running. Only when all transactions are completed will the system assemble them to check for potential conflicts.
The system components work together to achieve this goal by leveraging advanced concurrency control mechanisms and innovative design principles. Here's a step-by-step overview of the workflow:
Transaction Input: Transactions from the transaction pool are fed into the execution process.
Scheduling: The scheduler performs static analysis on the incoming transactions to understand
Parallel Execution: Multiple Execution Units (EUs) operate concurrently to process transactions. Ultimately, each EU produces a record of the accesses made during its execution.
Read/Write Sets: Each EVM instance maintains an RW Set that contains the data read from and written to the state database by the transactions it processes. This is essential for tracking the changes made by each instance and for detecting conflicts.
Conflict Detection: After all executions in a single generation are completed, the conflict detector examines the RW sets to identify instances where multiple transactions have accessed the same shared resources concurrently, potentially resulting in conflicts. If two or more transactions attempt to modify the same data concurrently, a conflict is detected.
Conflict Resolution and Storage Commitment: Once the conflict detector has verified that there are no conflicts or has resolved any that were found, the clear state changes are then committed to the state database.
Feedback Loop: Information about conflicts is fed back into the scheduler to improve future transaction grouping and scheduling decisions.
