Optimizing Contracts for Parallelization

​

Principles for parallel-friendly contracts

• Minimize shared writes: The scheduler can parallelize transactions that do not write to the same storage keys. Avoid hot globals (for example, a single counter that every call updates).
• Partition state: Shard storage by user, asset, or ID so that independent transactions touch disjoint keys.
• Prefer pull over push: Let users claim funds instead of paying many recipients in a loop.
• Avoid unbounded loops: This applies especially to loops that write to storage or iterate over dynamic arrays or mappings.
• Batch internal work and isolate external effects: Do heavy computation in memory and commit a minimal set of storage writes.
• Use precompiles when available: Precompiles are highly optimized and cost less than the same logic written in Solidity.

​

Storage design patterns

​

Partition state by key

// Good: disjoint keys by user and id enable parallelism
mapping(address => mapping(uint256 => Position)) public positions;

function updatePosition(uint256 id, int256 delta) external {
    Position storage p = positions[msg.sender][id];
    // in-memory arithmetic first
    int256 newQty = p.qty + delta;
    // commit minimal writes
    p.qty = newQty;
}

• Writing a global totalVolume += amount; in every transaction
• Maintaining a single on-chain queue or registry that most calls update

​

Prefer pull payments

// Better: users pull their own rewards, isolating writes to their key
mapping(address => uint256) public accrued;

function accrue(address user, uint256 amount) internal {
    accrued[user] += amount; // isolated write
}

function withdraw() external {
    uint256 due = accrued[msg.sender];
    accrued[msg.sender] = 0; // single-key write
    (bool ok, ) = msg.sender.call{value: due}("");
    require(ok, "TRANSFER_FAILED");
}

​

Avoid large storage writes in loops

​

Gas-efficient Solidity practices

• Use external for externally called functions. Mark pure and read-only functions with pure and view.
• Pack variables to share storage slots (for example, multiple uint8 values in one slot).
• Prefer bytes32 over string when applicable.
• Cache array lengths in loops and short-circuit cheap conditions first.
• Use unchecked for arithmetic when overflow is impossible.
• Prefer memory over storage for temporary data, and commit only final values.

​

Leverage Sei precompiles

• JSON (0x1003)
• P256 (0x1011)

​

Testing and analysis

• Use Foundry or Hardhat gas reporters to track changes per function.
• Benchmark under concurrent load to detect hot keys (addresses or IDs) that serialize execution.
• Inspect execution with JavaScript tracers and runtime logs.