Multiprocessor

Multiprocessing Manager

Multiprocessor is a powerful package enabling developers to manually spawn EVM instances for parallel processing, allows the programmer to fully leverage the computation power of modern multiple processor design. These jobs run in isolated EU instances and are subject to the same commutativity checks as EOA-submitted transactions. The system automatically detects conflicts and merges safe updates deterministically.

How It Works

The parent execution unit (EU) spawns multiple child EUs to execute transactions in parallel. Each child runs in isolation, and its state changes are passed to the Conflict Detector. Only clean, non-conflicting changes are merged back into the parent EU, ensuring deterministic and safe parallelism.

• Storage: Child EUs receive a snapshot copy of the parent’s storage state at the moment of forking. They do not write directly to global storage during execution. They accumulate tentative state changes in a local cache. After execution, these changes are passed to the Conflict Detector, only clean, non-conflicting storage changes are committed back to the parent EU.

• Memory: Each spawned EU gets its own memory space. Memory is not shared, not snapshotted, and has no impact on conflict detection. You can use memory freely within each parallel job without restriction. Since they have no impact on the global state.

The conflict rules applied to EOA transitions are also applicable to these multiprocessor-spawned tasks.

---

This diagram is a visual explanation showing how a parent execution unit (EU) spawns child EUs and how conflict detection and state merging work.

Implementation

The Multiprocess offers a queue, which temporarily holds a list of tasks before execution begins. State consistency is rigorously guaranteed all the time. The actual parallel execution of the task in the queue won't start until the function run() is called. After execution, it checks for conflicts (e.g., write to same storage) and only merges non-conflicting (commutative) state changes back into the main state.

Function	Descriptions
Multiprocess	Manages job queue and controls execution across isolated EUs.
push(...)	Adds a job to the queue — each job includes a gas limit, value to transfer (optional, 0 by default), target contract, and calldata.
run()	Executes all jobs in parallel.
Conflict Detection	After run() is called, Arcology automatically performs conflict detection to ensure state consistency. Any jobs that violate commutativity (e.g., write to the same storage key) are reverted and excluded from the final state merge.

Examples

The examples highlight the main features and applications of Arcology's multiprocessing capability. They demonstrate how Arcology's technology can enhance the execution of smart contracts and provide significant benefits in terms of scalability and efficiency.

Parallel Assignment

This contract illustrates how two independent value assignments can be executed in parallel, safely merged back into the global state, and verified for correctness — all within a single transaction.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.8.0 <0.9.0;

import "@arcologynetwork/concurrentlib/lib/multiprocess/Multiprocess.sol";

contract ParaAssigment {
    uint256 _1;
    uint256 _2;
    
    function call() public  { 
       Multiprocess mp = new Multiprocess(2); // Two parallel processors.
       
       // Pushes two parallel jobs into the queue, each with a gas limit, address 
       // and calldata-very similar to address.call{}() syntax. 
       mp.push(50000, address(this), abi.encodeWithSignature("assigner(uint256)", 0));
       mp.push(50000, address(this), abi.encodeWithSignature("assigner(uint256)", 1));
       
       /* 
        Run two jobs with two new EU instances in parallel.
        Conflict detector will check the state they touch to preserve 
        commutativity after execution. Only clean state changs are merged back to the 
        parent EVM instance.
        */
       mp.run(); 

       assert(_1 == 10); // Check if the changes have been merged back.
       assert(_2 == 12);
    }

    function assigner(uint256 v)  public {
        if (v == 0) {
            _1 = v + 10; // For the first call
            return;
        }
        _2 = v + 11; // For the first call
    }
}   
 

1

The contract declares two state variables, _1 and _2, and sets up two parallel jobs using the Multiprocess API with two execution units. Job 0 runs assigner(0), setting _1 = 10, while Job 1 runs assigner(1), setting _2 = 11.

2

These jobs are executed in parallel inside isolated EU instances using mp.run(). After execution, Arcology’s conflict detector verifies that the two jobs modify separate, non-overlapping state, confirming no conflicts.

3

Since the updates are commutative and independent, their changes are safely merged back into the parent context. The final assertions verify that _1 is 10 and _2 is 11, confirming the success of deterministic parallel execution.

---

Parallel Assignment with Conflict

The contract ParaAssignmentWithConflict contains a function call() that utilizes the Multiprocess contract to execute the function assigner() in parallel. The assigner() function takes an input v and assigns the value v + 10 to the element at index v in the results array.

This example shows how Arcology detects and resolves write-write conflicts at runtime. Two jobs write to the same storage slot (results[0]). The system reverts one of them while preserving deterministic execution for the others. Only non-conflicting results are merged into the final state.

Here's a step-by-step explanation of what happens:

1

The call() function is called, and it creates a new instance of the Multiprocess contract with 2 threads (processes).

2

Two messages are pushed into the Multiprocess container with the function signature "assigner(uint256)" and respective values 0 and 1.

3

The mp.run() function is called, which executes the two messages in parallel using the specified number of threads (2).

4

Arcology detects the overlapping write to the same storage key. One of the conflicting jobs is reverted. The third job (assigner(1)) writes to results[1] and is conflict-free, so it’s committed.

5

Only one write to results[0] is retained.results[0] == 10, results[1] == 11 so the assertions pass.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.8.0 <0.9.0;

import "@arcologynetwork/concurrentlib/lib/multiprocess/Multiprocess.sol";

contract ParaAssignmentWithConflict {
    uint256[2] results;
    function call() public  { 
       Multiprocess mp = new Multiprocess(2); 
       mp.push(50000, address(this), abi.encodeWithSignature("assigner(uint256)", 0));
       mp.push(50000, address(this), abi.encodeWithSignature("assigner(uint256)", 0));
       mp.push(50000, address(this), abi.encodeWithSignature("assigner(uint256)", 1));
       mp.run();
       
       assert(results[0] == 10);
       assert(results[1] == 11);
    }

    function assigner(uint256 v)  public {
        results[v] = v + 10;
    }
} 

---

Parallel Mint

The subcurrency example comes from the official Ethereum documentation and implements the simplest form of a cryptocurrency. It isn't a standard ERC-20 contract, but it’s complex enough to cover many of the issues developers may encounter when using a multiprocessor execution in contrasts.

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.4;

contract Coin {
    // The keyword "public" makes variables
    // accessible from other contracts
    address public minter;
    mapping(address => uint) public balances;

    // Events allow clients to react to specific
    // contract changes you declare
    event Sent(address from, address to, uint amount);

    // Constructor code is only run when the contract
    // is created
    constructor() {
        minter = msg.sender;
    }

    // Sends an amount of newly created coins to an address
    // Can only be called by the contract creator
    function mint(address receiver, uint amount) public {
        require(msg.sender == minter);
        balances[receiver] += amount;
    }

    // Errors allow you to provide information about
    // why an operation failed. They are returned
    // to the caller of the function.
    error InsufficientBalance(uint requested, uint available);

    // Sends an amount of existing coins
    // from any caller to an address
    function send(address receiver, uint amount) public {
        if (amount > balances[msg.sender])
            revert InsufficientBalance({
                requested: amount,
                available: balances[msg.sender]
            });

        balances[msg.sender] -= amount;
        balances[receiver] += amount;
        emit Sent(msg.sender, receiver, amount);
    }
}

Parallel caller

The SubcurrencyCaller contract utilizes Arcology's Multiprocess library to perform parallel processing of multiple minting transactions on the Subcurrency contract, greatly improving the overall efficiency.

1

Parallel Minting Transactions: In the call function of the SubcurrencyCaller contract, four minting transactions are added to the Multiprocess queue. These transactions are designed to mint tokens for four different addresses: Alice, Bob, Carol, and Dave.

2

Execution and Verification: After adding the minting transactions to the Multiprocess queue using mp.push(), the contract checks if the number of transactions in the queue is equal to 4 by using mp.length(). This ensures that all four minting transactions have been successfully added to the queue.

3

Parallel Execution: The mp.run() function is then called, which executes all the minting transactions in parallel. Arcology's parallel processing capability allows these transactions to be processed simultaneously, reducing the overall execution time and gas cost.

4

Verification of Minted Balances: After the parallel execution, the contract verifies the balances of the four addresses by calling the getter function of the Subcurrency contract. This demonstrates that the transactions were executed correctly, and the minted amounts were applied to the corresponding addresses.

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.19 <0.9.0;

import "../../lib/multiprocess/Multiprocess.sol";
import "./Subcurrency.sol";

contract SubcurrencyCaller {
    function call(address coin) public{        
        address Alice = 0x1111111110123456789012345678901234567890;
        address Bob = 0x2222222220123456789012345678901234567890;
        address Carol = 0x4444444890123456789012345678901234567890;
        address Dave = 0x3333337890123456789012345678901234567890;
   
        Multiprocess mp = new Multiprocess(4); // Number of threads
        mp.push(100000, address(coin), abi.encodeWithSignature("mint(address,uint256)", Alice, 1111));
        mp.push(100000, address(coin), abi.encodeWithSignature("mint(address,uint256)", Bob, 2222));
        mp.push(100000, address(coin), abi.encodeWithSignature("mint(address,uint256)", Carol, 3333));
        mp.push(100000, address(coin), abi.encodeWithSignature("mint(address,uint256)", Dave, 4444));
        require(mp.length() == 4);
        mp.run(); // Start parallel processing

        require(Coin(coin).getter(Alice) == 1111);
        require(Coin(coin).getter(Bob) == 2222);
        require(Coin(coin).getter(Carol) == 3333);
        require(Coin(coin).getter(Dave) == 4444);
    }
}

---

Conclusion

Arcology ensures data consistency and integrity when concurrent operations are performed on shared state variables, allowing developers to harness the power of parallel execution without worrying about data corruption or conflicts.