Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Parallel Execution – Makechain
Skip to content

Parallel Execution

Makechain uses a single consensus chain with parallel per-project execution within each block, rather than separate shard chains.

Execution Model

Within each block, messages are processed in two phases:

Phase 1: Account Pre-pass (Serial)

Account-level messages are applied serially because they modify shared account state (key registrations, project counts):

  • KEY_ADD / KEY_REMOVE
  • ACCOUNT_DATA
  • VERIFICATION_ADD / VERIFICATION_REMOVE
  • PROJECT_CREATE / PROJECT_REMOVE / FORK (modify account project_count)

Phase 2: Project Execution (Parallel)

Project-scoped messages are grouped by project_id and each group is executed in parallel using rayon:

  • PROJECT_ARCHIVE / PROJECT_METADATA
  • REF_UPDATE / REF_DELETE
  • COMMIT_BUNDLE
  • COLLABORATOR_ADD / COLLABORATOR_REMOVE

Each project group operates on its own copy-on-write overlay store (OverlayStore) that can read the base state plus any account changes from Phase 1 (via SnapshotStore), ensuring isolation between projects.

State Root Computation

After execution, state diffs from all projects are combined into a global state root:

  1. Each project's diffs produce a per-project merkle root (BLAKE3 of sorted key-value pairs)
  2. All project roots are sorted and combined into a global root

This is deterministic regardless of parallel execution order.

Future: Sharding

The protocol spec reserves the possibility of sharding by project_id for horizontal scaling:

shard_index = project_id[0..4] as u32 % num_shards

The current parallel execution model is a stepping stone — the per-project isolation already provides the separation needed for future sharding without cross-shard coordination (except for FORK, which includes a state proof from the source project).