Execution Model

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

Execution Phases

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):

• SIGNER_ADD / SIGNER_REMOVE
• ACCOUNT_DATA
• VERIFICATION_ADD / VERIFICATION_REMOVE
• LINK_ADD / LINK_REMOVE
• REACTION_ADD / REACTION_REMOVE
• PROJECT_CREATE / PROJECT_REMOVE / FORK (modify account project_count)

Phase 2: Project Execution (Serial per project)

Project-scoped messages are grouped by project_id and each group is executed serially:

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

Both phases execute against a shared BatchStore — a mutations overlay on committed QMDB state. Phase 2 sees all account changes from Phase 1.

State Root Computation

After execution, the BatchStore is merkleized via QMDB's batch API, producing a single BLAKE3 state root digest (QMDB MMR root).

This is deterministic — all validators execute the same messages in the same order and produce the same root.

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 per-project grouping already provides the isolation needed for future parallel or sharded execution without cross-shard coordination (except for FORK, which includes a state proof from the source project).