RFC: Sub-second finality - #117
Open
msbrogli wants to merge 3 commits into
Open
Conversation
Draft RFC for two-tier (sub-second soft + PoW hard) finality, written from the v1 implementation in hathor/finality/. Includes the BLS backend benchmark (moved from hathor-core plans/) as a companion document. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The PoC uses native blst (via the htr_lib Rust extension) as the BLS backend. Update the RFC and companion benchmark to present blst as the backend throughout, keeping py_ecc only as the slow reference the benchmark measured against. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add the companion end-to-end soft-finality latency benchmark (collect 2f+1 -> admit to mempool) and fold its findings into the design: a Latency subsection (soft finality ~= 2L + ~5 ms, flat in committee size) and a drawback noting per-validator O(N) vote-verification work from all-to-all gossip. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pedroferreira1
moved this from In Progress (Done)
to In Progress (WIP)
in Hathor Network
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A fast soft-finality tier produced by a fixed committee of finality validators, layered on Hathor's existing merged-mined PoW hard-finality tier. Each validator pins and BLS-co-signs the first spender it sees of a UTXO and never signs a conflict; a weighted quorum (
2f+1of3f+1) aggregates into a constant-size Finality Certificate. One consensus rule binds the tiers: a PoW block is invalid if it confirms a transaction conflicting with an already-certified one, so PoW ratifies the fast path and can never silently reverse a soft-final payment. Written from the v1 implementation inhathor/finality/.Motivation
PoW settlement is objective but probabilistic and multi-second — the most visible gap against card networks and payment-oriented chains for the point-of-sale / stablecoin use cases Hathor targets. This adds a sub-second, cryptographically verifiable confirmation on top of unchanged PoW, with no new operator that can steal or forge state (validators can at worst stall).
Guide-level explanation
Introduces finality validators, the pin, votes, the Finality Certificate, soft vs. hard finality, and the ratification rule. Includes the quorum-intersection safety argument (any two
2f+1quorums in a3f+1committee share ≥f+1validators, hence ≥ 1 honest), worked examples (no conflict / conflict that resolves / conflict that gets stuck), the open question of stuck-UTXO recovery, and the two-layer security model (fast tier + the battle-tested PoW consensus that alone guarantees no on-chain double-spend even if the fast tier has a bug).Reference-level explanation
Covers the
hathor/finality/package: BLS crypto on the nativeblstbackend; weight-basedW=3f+1/ quorum2f+1committee config;Vote/FinalityCertificatewire formats; authoritative (non-rebuildable) pin and certificate stores; the in-memory pending pool; theFinalityServicevoting/certification/admission logic; p2p transport and capability; the certified-only mempool gate; and the consensus ratification rule that voids an offending block. Includes the quorum-intersection safety argument and a measured latency section (soft finality ≈2·L + ~5 ms, flat in committee size — e.g. a 100-validator committee on 100 ms links reaches soft finality in ~205 ms).Drawbacks
Soft finality is weaker than PoW (honest-quorum assumption); validators are a new centralisation/censorship locus; new liveness corner cases (wedged UTXOs, partitions, multi-owner griefing); operational complexity and layer coupling; a native crypto dependency in the hot path; per-validator vote-verification work grows
O(N)with committee size (all-to-all gossip), even though latency stays flat.Rationale and alternatives
Consensusless quorum certificates (chosen) vs. a single leader/sequencer (reintroduces a privileged operator) vs. full total-order BFT for everything (pays consensus latency for payments that never conflict; reserved for the Nano-Contract path). The certificate-as-block-validity-rule is the load-bearing choice that makes the two tiers coherent. Plus implementation-level rationale (BLS vs. Schnorr, weight-based calibration,
tx_id-only pin-message, certified-only mempool, voiding vs. crashing).Prior art
FastPay, Sui Lutris/Mysticeti, Dash InstantSend+ChainLocks, Thunderella, Babylon, Casper FFG/Gasper & GRANDPA, Syscoin Z-DAG. The contribution is binding a consensusless fast certificate to merged-mined Bitcoin PoW via a block-validity rule.
Unresolved questions
PoA vs. PoS and who slashes; handshake committee-membership proof; stuck-UTXO recovery policy; multi-owner griefing; late-FC reconciliation edge cases. Out of scope: Nano-Contract BFT design, validator economics, confidential-transaction interaction.
Future possibilities
Batch/parallel certificate verification; binding FC-root block header for light clients; PoS staking + economic slashing; epoch governance/rotation + epoch-boundary unlock; ChainLocks-style fallback hard tier; the Nano-Contract total-order path; confidential and cross-chain settlement.
Files in this PR
text/0000-subsecond-finality.md— the design RFC.text/0000-subsecond-finality-bls-benchmark.md— companion BLS signing/verification benchmark (blst).text/0000-subsecond-finality-latency-benchmark.md— companion end-to-end soft-finality latency benchmark.🤖 Generated with Claude Code