KIP-21: Partitioned sequencing commitment with O(activity) proving by michaelsutton · Pull Request #36 · kaspanet/kips

michaelsutton · 2026-02-24T23:20:01Z

Summary

This PR adds KIP-21 as a draft consensus spec for replacing the current linear per-block seqcommit recurrence with a partitioned, lane-based commitment scheme.

The design keeps a single header commitment (accepted_id_merkle_root) while enabling lane-local proving that scales with lane activity (O(activity)), via two global anchors plus lane-local witnesses/diff.

Scheme illustration:

Global chain:  S0 -> S1 -> S2 -> ... -> Sn
                 |    |              |
                 v    v              v
               A0    A1             An      (A = ActiveLanesRoot)

Lane L proof:
  inclusion(L, A0) ---- lane-local compressed transition ---- inclusion(L, An)

This PR includes

Defines lane extraction and lane-tip state transition rules.
Defines ActiveLanesRoot as an SMT over active lane tips.
Defines SeqStateRoot and selected-parent recurrence for SeqCommit(B).
Preserves the ability to reconstruct global sequencing order from committed lane activity using merge_idx plus lane witnesses/SMT-diff proofs under SeqCommit anchors.
Commits accepting-block context (timestamp, daa_score, blue_score).
Commits mergeset miner payloads (including non-accepted mergeset coinbase payloads) with block hash + blue work binding.
Defines purge rules and oldest-first purge index behavior.
Defines reorg-safe incremental maintenance via reversible diffs.
Adds proving guidance:
- global order reconstruction notes,
- two-anchor lane proof model,
- reactivated-lane non-inclusion pattern,
- optional persistent witness store.

For prior research context, see "Subnets sequencing commitments": https://research.kas.pa/t/subnets-sequencing-commitments/274

someone235 · 2026-03-02T07:31:14Z

+
+This KIP replaces the current per-chain-block linear sequencing commitment recurrence with a partitioned sequencing commitment scheme.
+
+Instead of committing to all accepted transactions in every chain block as one global append-only stream, consensus maintains a commitment over the tips of active application lanes. Each active lane has its own recursive tip hash and last-touch blue score. Global order remains reconstructible via `merge_idx` (Section 10.1), but is no longer directly committed as one monolithic per-block list. The block header continues to expose a single `accepted_id_merkle_root` value (consumed by `OpChainblockSeqCommit`), but post-activation it commits to (i) the active-lanes sparse Merkle tree (SMT) root and (ii) per-block context and mergeset miner payloads, chained through selected-parent recursion.


You mention the term "lane" a lot. I think you should write "(as defined below)" or something similar after the first usage.

someone235 · 2026-03-02T07:43:44Z

+This document mixes consensus rules and proving/operations guidance. Use this reading path:
+
+* Consensus implementers: read *Terminology* through *Script Semantics*, then *Reorg-Safe Incremental Maintenance* and *Purge Index*, then *Relationship to Covenants++ Workstream* and *Backward Compatibility*.
+* Proving/witness implementers: read *Per-Lane Block Activity Digest (§4.2)*, *Update or Initialize Lane Tips (§5.2)*, and *Commitment Structure (§6)* (especially §6.3-§6.7), then *Complexity (§10)* and *Optional Persistent Witness Store (§11)*.


Consider using links every time you use a section number

someone235 · 2026-03-02T09:17:50Z

+
+### 1. Terminology
+
+* Lane (`lane`): the logical application lane tracked by this commitment scheme. (In this KIP, lanes are extracted from `tx.subnetwork_id`; future KIPs may define finer-grained lane extraction such as account-level lanes.)


Maybe add something like "a lane is some ordered subset of mergeset's accepted transactions" or "a lane defines a predicate to filter mergeset transactions"

someone235 · 2026-03-02T09:29:39Z

+Rationale for keying:
+
+* The committed SMT key is `lane_key(lane) = H_lane_key(lane_id_bytes(lane))` (Section 6.1).
+* Because key width is normalized by `H_lane_key`, zero-padding lane IDs is unnecessary.


This paragraph is not very clear. Do you mean that zero-padding might be needed to accommodate for SMT leaf requirements? I think the standard is that leaves are always hashed items, so there's no need to mention it (I mean, padding would violate the standard and would require justification)

someone235 · 2026-03-02T10:15:37Z

+
+Rationale for keying:
+
+* The committed SMT key is `lane_key(lane) = H_lane_key(lane_id_bytes(lane))` (Section 6.1).


What is lane here? Is it just an abstract concept? I think it's clearer to write lane_key(lane_id) = ...

I think the whole document will be easier to reason about if you'll replace lane with lane_id in many places (mainly in code snippets).

someone235 · 2026-03-02T11:39:00Z

+
+```
+TipUpdateHash(parent_ref, lane_id_bytes(lane), activity_digest, MergesetContextHash(B)) =
+    H_lane_tip(parent_ref || lane_id_bytes(lane) || activity_digest || MergesetContextHash(B))


Just a thought: maybe add here SeqCommit(parent(B)) and replace parent_ref with ZERO_HASH when inactive? This way the structure will be more "deterministic"

someone235 · 2026-03-02T11:52:41Z

+
+Current encoding (subnetwork lanes):
+
+* Let `subnetwork_id` be the canonical 20-byte `tx.subnetwork_id`.


So users are now allowed to use freely any non-reserve subnetwork ID? I think it's worth writing it explicitly - it's another consensus change triggered by this KIP

someone235 · 2026-03-02T12:00:29Z

+Consensus sets:
+
+```
+B.header.accepted_id_merkle_root = SeqCommit(B)


This seems unrelated - the previous sentence doesn't mention SeqCommit(B). Maybe it shoule be part of "6.6 Sequencing State Root (Normative)"?

someone235 · 2026-03-02T12:17:17Z

+    H_mergeset_context(
+        le_u64(B.header.timestamp)
+        || le_u64(B.header.daa_score)
+        || le_u64(B.header.blue_score)


Maybe it's a little far-fetched, but utxo_commitment might also be relevant for an L2 application that needs to get the full L1 UTXO set.

someone235 · 2026-03-02T12:37:31Z

+1. `peek_oldest_score()`
+2. `pop_oldest_while(score <= purge_cutoff)`


Maybe change score -> blue_score? (Also below)

biryukovmaxim · 2026-03-03T12:54:17Z

+
+Rationale for keying:
+
+* The committed SMT key is `lane_key(lane) = H_lane_key(lane_id_bytes(lane))` (Section 6.1).


do we really need hashing here? Cant we reuse lane_id_bytes and add 20 zeroes as padding?

michaelsutton added 4 commits February 24, 2026 22:46

kip 21 initial commit

5811ed2

diagram

e7dc5d4

refs alignment

70fa11e

ibd clarification

6740f92

someone235 reviewed Mar 2, 2026

View reviewed changes

biryukovmaxim reviewed Mar 3, 2026

View reviewed changes

refine vProg compatibility and commitment framing

bd4cfe4

biryukovmaxim mentioned this pull request May 7, 2026

/lore misleadingly links KIP-10 from the Toccata section kaspamedia/kaspa-org#2

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

KIP-21: Partitioned sequencing commitment with O(activity) proving#36

KIP-21: Partitioned sequencing commitment with O(activity) proving#36
michaelsutton wants to merge 5 commits intokaspanet:masterfrom
michaelsutton:kip21

michaelsutton commented Feb 24, 2026 •

edited

Loading

Uh oh!

someone235 Mar 2, 2026

Uh oh!

someone235 Mar 2, 2026

Uh oh!

someone235 Mar 2, 2026

Uh oh!

someone235 Mar 2, 2026

Uh oh!

someone235 Mar 2, 2026

Uh oh!

someone235 Mar 2, 2026

Uh oh!

someone235 Mar 2, 2026

Uh oh!

someone235 Mar 2, 2026

Uh oh!

someone235 Mar 2, 2026

Uh oh!

someone235 Mar 2, 2026

Uh oh!

biryukovmaxim Mar 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants


		This KIP replaces the current per-chain-block linear sequencing commitment recurrence with a partitioned sequencing commitment scheme.

		Instead of committing to all accepted transactions in every chain block as one global append-only stream, consensus maintains a commitment over the tips of active application lanes. Each active lane has its own recursive tip hash and last-touch blue score. Global order remains reconstructible via `merge_idx` (Section 10.1), but is no longer directly committed as one monolithic per-block list. The block header continues to expose a single `accepted_id_merkle_root` value (consumed by `OpChainblockSeqCommit`), but post-activation it commits to (i) the active-lanes sparse Merkle tree (SMT) root and (ii) per-block context and mergeset miner payloads, chained through selected-parent recursion.


		### 1. Terminology

		* Lane (`lane`): the logical application lane tracked by this commitment scheme. (In this KIP, lanes are extracted from `tx.subnetwork_id`; future KIPs may define finer-grained lane extraction such as account-level lanes.)


		Rationale for keying:

		* The committed SMT key is `lane_key(lane) = H_lane_key(lane_id_bytes(lane))` (Section 6.1).


		Current encoding (subnetwork lanes):

		* Let `subnetwork_id` be the canonical 20-byte `tx.subnetwork_id`.

		1. `peek_oldest_score()`
		2. `pop_oldest_while(score <= purge_cutoff)`

Conversation

michaelsutton commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

This PR includes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

michaelsutton commented Feb 24, 2026 •

edited

Loading