The protocol,
end to end.

01The one idea

Chain security and scientific work are two different mechanisms that most blockchains conflate. MLabChain keeps them separate.

• Chain security is provided by SHA-256 proof-of-work. It seals blocks and gives a Sybil-resistance signal. It has nothing to do with machine learning.
• Scientific work is provided by ML_WORK transactions. Each one commits a trained model, an architecture, a challenge, and a set of metrics. Only these mint Mera.

Separating the two means the ML verifier can be replaced without touching consensus, and the block-sealing rule can be changed without touching the reward math. That is what makes the project auditable.

02Two layers

The system is split into two programs that talk over a subprocess boundary.

The C++ core is authoritative for monetary state. The Python layer is authoritative for what a training run actually produced. Neither can override the other. A bug in Python cannot mint Mera; a bug in C++ cannot train a model.

03Challenge manifests

No reward is paid against a free-form submission. Every reward is against a challenge — a fixed object that pins the task, the data, the split, the metric, and the baseline.

A challenge is registered with a bond, becomes active after maturity, and expires after a fixed lifetime. Registration costs prevent spam. Maturity gives other nodes time to observe. Expiry bounds the total issuance any single challenge can produce.

04The verifier contract

A verifier is a rule for checking that a submitted model was actually trained the way the submission claims. In v0.3 there is exactly one:

MLabChain-linear-v4

It is deterministic linear regression with a seeded dataset generator, a fixed SGD update order, and a fixed train/test split. Every node can replay it byte-for-byte. Two identical submissions produce identical models, identical metrics, and identical reward.

05Symbolic operations

The reward is denominated in symbolic operations, not in wall time and not in hardware cycles. For the native verifier:

ops = epochs × n_train × (3 × n_features + 4)

This counts one multiply-add per feature per forward pass, one per feature per weight update, plus the constant terms. It is a model of the algorithm, not a measurement of the machine. A slower machine does not earn more. A faster one does not earn less per proof.

The count is bounded by MAX_OPS_PER_WORK = 10^15, so a single submission cannot claim arbitrary amounts of work.

06The reward formula

The reward for a submission depends on two things: how many symbolic operations it performed, and how much it improved the challenge's frontier. Both are integer-quantised in C++.

# fixed-point NMSE, scaled by 1e9
quality_ppm = clamp( (baseline − model) × 1e6 / baseline, 0, 1e6 )

# difference from the current best accepted quality
delta_q = quality_ppm − challenge.best_quality_ppm

# integer reward in atomic units (1 MERA = 1e8 atomic)
reward = min( 50 MERA, ops × delta_q × 1e8 / (1e7 × 1e6) )

Three constraints apply on top of the formula:

• reward ≤ challenge.budget_remaining
• total_supply + reward ≤ 100,000,000 MERA
• delta_q > 0, or the reward is zero

07Marginal rewards, elaborated

The key design choice is marginality. A submission is rewarded not against the challenge's original baseline, but against the current best that the challenge has already paid for.

Concretely: if a challenge starts with a baseline NMSE of 1.0 and the first submission achieves 0.5, the first submitter gets paid for the full delta. If a second submission achieves 0.4, the second submitter gets paid only for the difference between 0.5 and 0.4. If a third submission achieves 0.6, it is paid nothing, because it did not improve on the best.

08Consensus and fork choice

Blocks are sealed by SHA-256 proof-of-work with an adaptive target. Difficulty is retargeted every 16 blocks toward a 60-second target, bounded to ±1 step per retarget and clamped to the range [1, 8].

When two chains compete, the one with the highest cumulative work wins. Ties break by lower tip hash. On reorg, the winning chain is replayed from genesis and the canonical state is replaced.

Signed block proposals

Every block header includes the producer's address, public key, and signature over the canonical header. A block is only valid if address_from_pubkey(pubkey) == producer and the signature verifies.

Timestamps

A block's timestamp must be strictly greater than the median of the last 11 blocks and no more than 2 minutes ahead of the node's local clock. This is a simple policy, and the docs say so; production would need peer-clock sampling.

09The P2P layer

The reference node speaks a small line-based protocol over TCP. The commands are PING, STATUS, GETCHAIN, TX|<wire>, and BLOCK|<wire>. Peer addresses are supplied on the command line; there is no discovery.

Sync is pull-based: a node polls its peers for status, and if a peer advertises greater cumulative work, the node requests the full chain and runs a fork-choice comparison.

10The honest boundary

MLabChain v0.3 solves a narrow problem, and everything on this site is written to make that narrowness visible. The four things it does not solve:

These are not bugs to be fixed in the next release. They are the research problems the field has been circling for years, and MLabChain's value is partly in stating them clearly.

Next: the Mera unit →