feat: add DIP for Compact Quorum Proof Chains #175
Conversation
Introduces a new DIP specifying trustless verification of LLMQ public keys using ChainLocks and merkleRootQuorums. This enables light clients and the Platform SDK to cryptographically verify Platform quorum public keys without trusting external parties. Key features: - Compact proofs (~1 KB typical) using chainlock-based verification - No header chains needed - verifies against chainlocked block's cbtx - New P2P messages (GETQUORUMPROOFCHAIN, QUORUMPROOFCHAIN) - gRPC API for Platform SDK integration Co-Authored-By: Claude Opus 4.5 <[email protected]>
📝 WalkthroughWalkthroughA new design specification document is introduced that defines compact quorum proof chains for trustless platform verification. It specifies data structures, verification algorithms, P2P messages, gRPC API endpoints, and security considerations for cryptographically verifying quorum public keys using ChainLocks and merkleRootQuorums. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@dip-pasta-compact-quorum-proofs.md`:
- Around line 115-116: The ChainlockEntry height is declared as a signed type in
the table and protobuf; change the data-structure table entry from int32_t to
uint32_t and update the protobuf field type from int32 to uint32 (e.g., in the
ChainlockEntry message) so heights are consistently unsigned; also find and
update the other occurrences of the same field/type elsewhere in the spec (the
other ChainlockEntry listings) to use uint32 to match the checkpoint height
modeling and avoid negative values or interop issues.
- Line 434: Hyphenate the compound modifier in the proof size analysis sentence:
change "one per ~2 day interval" to "one per ~2-day interval" (locate the
sentence containing "When the checkpoint is 30+ days old, approximately 15
bridging chainlock quorums are needed" in the proof size analysis section and
update the phrase accordingly).
| | height | int32_t | 4 | Height of the chainlocked block | | ||
| | blockHash | uint256 | 32 | Hash of the chainlocked block | |
There was a problem hiding this comment.
Use unsigned heights consistently (int32_t → uint32_t / int32 → uint32).
Heights are non-negative and already modeled as uint32_t elsewhere (e.g., checkpoint height). Using signed types here risks negative values and interop inconsistencies in implementations. Consider making ChainlockEntry height unsigned in both the data-structure table and the protobuf.
🛠️ Proposed spec edits
-| height | int32_t | 4 | Height of the chainlocked block |
+| height | uint32_t | 4 | Height of the chainlocked block |-message ChainlockEntry {
- int32 height = 1;
+message ChainlockEntry {
+ uint32 height = 1;Also applies to: 368-370
🤖 Prompt for AI Agents
In `@dip-pasta-compact-quorum-proofs.md` around lines 115 - 116, The
ChainlockEntry height is declared as a signed type in the table and protobuf;
change the data-structure table entry from int32_t to uint32_t and update the
protobuf field type from int32 to uint32 (e.g., in the ChainlockEntry message)
so heights are consistently unsigned; also find and update the other occurrences
of the same field/type elsewhere in the spec (the other ChainlockEntry listings)
to use uint32 to match the checkpoint height modeling and avoid negative values
or interop issues.
|
|
||
| #### Very Old Checkpoint | ||
|
|
||
| When the checkpoint is 30+ days old, approximately 15 bridging chainlock quorums are needed (one per ~2 day interval). |
There was a problem hiding this comment.
Hyphenate compound modifier (“2-day”).
Minor grammar fix for readability in the proof size analysis section.
🧰 Tools
🪛 LanguageTool
[grammar] ~434-~434: Use a hyphen to join words.
Context: ...chainlock quorums are needed (one per ~2 day interval). | Component | Count | Si...
(QB_NEW_EN_HYPHEN)
🤖 Prompt for AI Agents
In `@dip-pasta-compact-quorum-proofs.md` at line 434, Hyphenate the compound
modifier in the proof size analysis sentence: change "one per ~2 day interval"
to "one per ~2-day interval" (locate the sentence containing "When the
checkpoint is 30+ days old, approximately 15 bridging chainlock quorums are
needed" in the proof size analysis section and update the phrase accordingly).
| 3. Find the index of the target commitment's hash | ||
| 4. Construct the merkle path from that index to the root | ||
|
|
||
| ## P2P Messages |
There was a problem hiding this comment.
Needs new protocol version. Also, Platform doesn't talk to Core via p2p afaik. Or is it for Core level SPV light clients?
| | checkpointQuorumCount | compactSize uint | 1-9 | Number of known chainlock quorums | | ||
| | checkpointQuorums | QuorumEntry[] | variable | Known chainlock quorum entries from checkpoint | |
There was a problem hiding this comment.
These are redundant, full nodes already have this info
| | checkpointQuorumCount | compactSize uint | 1-9 | Number of known chainlock quorums | | |
| | checkpointQuorums | QuorumEntry[] | variable | Known chainlock quorum entries from checkpoint | |
| | checkpointBlockHash | uint256 | 32 | Block hash of the client's checkpoint | | ||
| | checkpointHeight | uint32_t | 4 | Height of the checkpoint block | |
There was a problem hiding this comment.
Also redundant - you can deterministically derive block height from block hash (always) and vice versa (but only if it's chainlocked).
2 participants
Summary
merkleRootQuorumsKey Features
GETQUORUMPROOFCHAIN,QUORUMPROOFCHAINProof Size Analysis
Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.