# Overview

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. 
* **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 [**concurrent API** ](https://doc.arcology.network/concurrent-programming-guide/)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.

{% hint style="danger" %}
**Commutativity-Centric Design:** The system is built around the principle of [**commutativity**](https://pdos.csail.mit.edu/papers/commutativity%3Asosp13.pdf). Any operation that breaks this property during parallel execution is considered a conflict, and the associated transaction is reverted to maintain consistency.
{% endhint %}

### Why Parallel Execution

Parallel execution uses multicore processors to run many tasks at once, splitting workloads into independent tasks for faster processing, enabling far higher transaction throughput in less time.

{% columns %}
{% column %}
Sequential Execution

<figure><img src="/files/PXtQoFh8CoQxc9Kneip0" alt=""><figcaption></figcaption></figure>
{% endcolumn %}

{% column %}
Parallel Execution

<figure><img src="/files/qwfQDO1IX9IMR8avlnkB" alt=""><figcaption></figcaption></figure>
{% endcolumn %}
{% endcolumns %}

### Key Components

The system components in Arcology 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.

<figure><img src="/files/SoFoPcbGTVjCpPeuyheX" alt=""><figcaption></figcaption></figure>

{% stepper %}
{% step %}
**Transaction Input:** Transactions from the transaction pool are fed into the execution process.
{% endstep %}

{% step %}
**Scheduling:** The scheduler performs static analysis on the incoming transactions to understand&#x20;
{% endstep %}

{% step %}
**Parallel Execution:** Multiple Execution Units (EUs) operate concurrently to process transactions. Ultimately, each EU produces a record of the accesses made during its execution.
{% endstep %}

{% step %}
**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.
{% endstep %}

{% step %}
**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.
{% endstep %}

{% step %}
**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.
{% endstep %}

{% step %}
**Feedback Loop:** Information about conflicts is fed back into the scheduler to improve future transaction grouping and scheduling decisions.
{% endstep %}
{% endstepper %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.arcology.network/parallel-execution-design/overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.