Quick Introduction

An Short Overview of Arcology's Core Technologies

This document is a brief overview of the Arcology Network, consolidating information that is otherwise scattered across multiple sources into a single, concise summary to highlight some key features. For a deeper dive into Arcology, please refer to our detailed documentation here.

Modern processors are multi-core, built for parallel tasks. However Ethereum rollups are all single-threaded, can only use one core at a time. Single-threaded rollups fall short of meeting high performance demands. The resource underutilization leads to significant scalability limitations.

Arcology is a parallel rollup network capable of processing multiple transactions simultaneously. It can handle tens of thousands of transactions per second, outperforming all existing high-performance blockchains.

Comparison With Other L2s

Layer 2 solutions aim to overcome Ethereum’s scalability and cost challenges, but many still face limitations in throughput, fee stability, and security. Arcology redefines these benchmarks, delivering unmatched performance and efficiency.

Unprecedented Gas Limit

Arbitrum has a targeted gas limit of 7 million per second. With each coin transfer costing 21,000 gas, the network can handle roughly 333 of the simplest transactions per second — not to mention the significantly reduced capacity for complex smart contract calls, which consume far more gas.

Optimism, by comparison, is even slower, with a gas limit of 5 million per block and a block time of 2 seconds. This translates to just 2.5 million gas per second, allowing for only about 119 simple transactions per second, and even fewer for gas-intensive operations.

Arcology Network stands out with its massive gas limit of 1 billion gas per second, targeting 2 billion at mainnet launch—vastly surpassing the 5–10 million targeted gas limits of L2 solutions like Optimism and Arbitrum. This allows Arcology to achieve 10,000–15,000 TPS, enabling complex applications and reducing transaction costs by up to 3x, making it a scalable and cost-efficient choice for developers.

• Arbitrum: ~333 TPS (7 million gas/second)

• Optimism: ~119 TPS (2.5 million gas/second)

• Arcology: 10,000–15,000 TPS (1 billion+ gas/second)

Stable Fee Stability Under Load

One of the key issues with Ethereum and its L2s is unstable fees during periods of high network activity. Arcology's architecture is designed to prevent fee spikes, maintaining low and stable transaction costs even during periods of high network activity. This contrasts with some L2 solutions where increased demand can lead to significant fee increases.

Enhanced Security

Arcology's parallel execution model eliminates MEV (Maximal Extractable Value) opportunities by processing transactions concurrently, preventing the ordering manipulations that enable sandwich attacks. This architecture allows the construction of DEXs where users can trade securely without the risk of front-running or other MEV-related exploits.

What Arcology Means for Applications

Arcology’s parallel execution model enables a new generation of resource-intensive applications. For example, it empowers DEXs to handle tens of thousands of transactions per second, making high-frequency trading and complex operations seamless and efficient.

• High-Performance DEXs: Enables decentralized exchanges to process tens of thousands of transactions per second, supporting high-frequency trading and complex operations effortlessly.

• Scalable Gaming: Supports large-scale blockchain games with real-time updates and interactive gameplay, thanks to its massive throughput.

• Cost-Efficient Operations: Reduces transaction costs for complex smart contracts, making blockchain more accessible for developers and users.

• New Applications: Arcology’s architecture fosters innovation by enabling applications that were previously impractical on traditional blockchain platforms.

---

What is Arcology

Arcology has a scalable, parallel processing-focused architecture, a redesign of traditional, sequential-centric blockchain systems. Not only does Arcology address the need for parallel execution but also other key bottlenecks in the original Ethereum, including slow storage access. Key features include:

• EVM equivalent & composable

• Deterministic parallel transaction execution

• STM-based Optimistic Concurrency Control

• Dual storage(Parallelized, asynchronous MPT with dedicated execution storage)

• Concurrent library with CRDT data structures to help developers build parallel contrasts.
• Event-driven, microservice-based architecture

Parallel Execution

Parallelization execution is a technology that leverages modern multicore computer architecture to run multiple tasks in at once. Workload is cut into independent tasks and allocated to individual core for more efficient processing. It is an effective scaling solution in computing. All supercomputers rely on parallel execution to scale, and blockchain scaling should be no different.

A parallel blockchain can handle significantly more transactions in a fraction of the time. It is wildly used in many areas. For blockchain, this means:

• Significantly higher scalability.

• reduced transaction costs.

Sequential vs Parallel Execution

Concurrency Control

For a parallel blockchain to work to its full potential, the following intertwined issues in the current blockchain design must be addressed with comprehensive solutions:

• Deterministic concurrency control: Transaction executions must generate deterministic results, a fundamental requirement for blockchain. Unfortunately, most commonly used concurrency control tools in the centralized systems aren't designed for this, so a blockchain-native concurrency solution is the key.

• Low performance StateDB: Even with parallel execution, overall throughput won't improve much if other bottlenecks persist; Ethereum's original stateDB design is the single biggest one. The module needs a substantial upgrade to keep up with parallel execution.

• Parallel contract development: It's a common misconception that a blockchain with a parallel execution engine alone is enough to fully realize the benefits of parallelism. This is not true. Contracts must be designed and built for parallelization to unlock the full potential of the underlying parallel execution architecture.

The parallel design relies on an effective concurrency control system to maintain data consistency and integrity. Arcology needs one too. Generally, there are two main concurrency control strategies: Pessimistic Concurrency Control and Optimistic Concurrency Control.

Arcology uses a hybrid control strategy, primarily focusing on an STM-based optimistic approach. Given that optimistic concurrency control is sensitive to conflicts, Arcology also includes a concurrent library in Solidity to help developers write conflict-free contracts.

---

How Arcology Works

The EVM is a single-threaded system by design. To add parallel execution capability, it must either be reimplemented to include the necessary enhancements or wrapped in an external parallel execution framework as a unit of execution. Arcology chose the latter because it doesn't alter the EVM's core structure.

To keep track of all the Arcology inserted an intermediate layer between the EVM and the Ethereum StateDB to intercept state accesses. These records are later assessed by a dedicated conflict detection module to protect the state consistency. Arcology’s concurrency control system includes:

• The system starts multiple EVM instances, each with its own cache. More instances generally mean better performance, but the number should not exceed the available processors.

• Each EVM processes a transaction, temporarily saving read and written data in its cache. The EVMs run independently without communicating during processing.

• An RW Cache that acts as an intermediary between the EVM and the StateDB.

• A conflict detector to identify potential conflicts in state access.

• A state committer to write clear state transitions to the storage.

• The conflict history will be fed back to the scheduler to prevent future occurrences.

Storage Variables Only

In the EVM, there are memory variables and storage variables. Arcology’s concurrency control only tracks storage variables, treating memory variables as local to their transactions since they don’t affect the overall blockchain state directly. In Arcology's concurrent execution design, the system keeps track of three types of state operation during transaction processing:

Operation	Read	Write	Delta Write
Read				The read retrieves data only and conflicts with everything except other reads.
Write				A write updates a memory slot and conflicts with all.
Delta Write				A delta write adds a difference to the original and conflicts with all except other delta writes.

For more information on conflict rules please check out this link.

---

Concurrent Data Structures

Optimistic concurrency control is effective when conflict likelihood is low. However, many contracts designed sequentially have contention points that ultimately result in conflicts, preventing them from fully benefiting from parallel execution. To fully harness the advantages of parallelism, developers need mechanisms to mitigate the impact of contention in their code.

The Concurrent Data Structures are a set of CRDT that help developers to write contention free smart contracts that can take best use of Arcology's parallel processing design.

Vending Machine Example

To better understand this, consider the following example from the Ethereum developers docs:

Original Version

In the original implementation, the cupcakeBalances mapping is a shared variable accessed and modified by multiple functions (refill and purchase), and it is shared among different users interacting with the contract.

pragma solidity 0.8.7;

contract VendingMachine {

    // Declare state variables of the contract
    address public owner;
    mapping (address => uint) public cupcakeBalances;

    // When 'VendingMachine' contract is deployed:
    // 1. set the deploying address as the owner of the contract
    // 2. set the deployed smart contract's cupcake balance to 100
    constructor() {
        owner = msg.sender;
        cupcakeBalances[address(this)] = 100;
    }

    // Allow the owner to increase the smart contract's cupcake balance
    function refill(uint amount) public {
        require(msg.sender == owner, "Only the owner can refill.");
        cupcakeBalances[address(this)] += amount;
    }

    // Allow anyone to purchase cupcakes
    function purchase(uint amount) public payable {
        require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake");
        require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase");
        cupcakeBalances[address(this)] -= amount;
        cupcakeBalances[msg.sender] += amount;
    }
}

Parallelized

In the parallelized version, the shared variable cupcakeBalances uses a new data type U256Cum provided by Arcology, enabling concurrent updates. The parallelized contract is as follows:

pragma solidity 0.8.7;

import "@arcologynetwork/concurrentlib/lib/commutative/U256Cum.sol";

contract VendingMachine {

    // Declare state variables of the contract
    address public owner;
    U256Cumulative cupcakeStock;
    mapping (address => uint) public cupcakeBalances;

    // When 'VendingMachine' contract is deployed:
    // 1. set the deploying address as the owner of the contract
    // 2. set the deployed smart contract's cupcake balance to 100
    constructor() {
        owner = msg.sender;
        cupcakeStock = new U256Cum(0, 100);
    }

    // Allow the owner to increase the smart contract's cupcake balance
    function refill(uint amount) public {
        require(msg.sender == owner, "Only the owner can refill.");
        cupcakeStock.add(amount);
    }

    // Allow anyone to purchase cupcakes
    function purchase(uint amount) public payable {
        require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake");
        cupcakeStock.sub(amount);
        cupcakeBalances[msg.sender].add(amount);
    }
}

Analysis

If two users, Alice and Bob, attempt to purchase their own cupcakes and the transactions are processed in parallel. These two versions will behave differently.

• Original Version: Only one transaction will go through due to the obvious conflict caused by the concurrent accesses to cupcakeBalances. The parallel execution of transactions interacting with this contract won't bring any performance benefit.

• Parallelized Version: Both transactions will go through because the cupcakeBalances variable is concurrently updatable. Alice and Bob will both receive their cupcakes as long as there are enough in stock.

Performance

Contract Name	Vending Machine(Parallelized)
Arcology Version	V 1.9.0
Deployment Mode	Standard-alone, single process
Operating System	Ubuntu 22.04
CPU	AMD Ryzen Threadripper 2950X 16-Core Processor
RAM	128G RAM
Storage	2T M2 SSD
Average gas burned/S:	712,118,171.6
Max gas burned/S	1,005,206,703