From f13233b00a4cbeb02a1c7dbd429256d4712c11f8 Mon Sep 17 00:00:00 2001 From: Nicholas Dudfield Date: Mon, 27 Apr 2026 15:45:27 +0700 Subject: [PATCH] docs(consensus): clarify validation sidecar signing rule Remove the stale TMValidation exportSignatures field from the draft proto path now that export signatures ride signed proposal sidecars. Document that any future validation-carried ConsensusExtensions data must be covered by the signed validation payload and duplicate/replay identity, not an unsigned wrapper field. --- include/xrpl/proto/ripple.proto | 5 ----- .../consensus/ConsensusExtensionsDesign.md | 20 +++++++++++++------ 2 files changed, 14 insertions(+), 11 deletions(-) diff --git a/include/xrpl/proto/ripple.proto b/include/xrpl/proto/ripple.proto index 97f760a9d..ca70fa428 100644 --- a/include/xrpl/proto/ripple.proto +++ b/include/xrpl/proto/ripple.proto @@ -225,11 +225,6 @@ message TMValidation // Number of hops traveled optional uint32 hops = 3 [deprecated = true]; - - // Legacy export signature gossip field retained for wire compatibility. - // Current proposal-based export signatures use - // TMProposeSet.exportSignatures. - repeated bytes exportSignatures = 4; } // An array of Endpoint messages diff --git a/src/xrpld/app/consensus/ConsensusExtensionsDesign.md b/src/xrpld/app/consensus/ConsensusExtensionsDesign.md index 94c74576e..6cb33ad58 100644 --- a/src/xrpld/app/consensus/ConsensusExtensionsDesign.md +++ b/src/xrpld/app/consensus/ConsensusExtensionsDesign.md @@ -48,12 +48,20 @@ and the ledger still closes. to distinguish payloads and `HashPrefix::sidecar` for item hashes. They are fetched through sidecar sync, not parsed or submitted as transactions. -6. Proposal-visible extension data must be signed. +6. Proposal-visible or validation-visible extension data must be signed. Do not attach behavior-changing sidecar payloads as unsigned out-of-band - proposal data. If stripping or changing a field would alter RNG or export - behavior, that field must be covered by the proposal signature and by the - proposal identity used for duplicate suppression. + proposal or validation wrapper data. If stripping or changing a field would + alter RNG or export behavior, that field must be covered by the relevant + signed payload and by the identity used for duplicate suppression/replay + checks on that path. + + Today ConsensusExtensions uses signed proposal sidecars, not validation + sidecars. If a future design carries extension material through + validations, the same rule applies: the behavior-changing data, or a digest + of it, must be inside the signed validation payload and bound to the + validating key and ledger. A protobuf field outside the signed validation is + only transport metadata; it must not affect consensus-extension behavior. ## Validator Set And Quorum @@ -178,7 +186,7 @@ When changing consensus extension code, check these questions: - Are quorum calculations using the active validator view, not recent proposers as the denominator? - Are sidecar entries typed as sidecars, not pseudo-transactions? -- Are proposal-visible sidecar fields covered by proposal signing and - duplicate suppression? +- Are proposal-visible or validation-visible sidecar fields covered by the + relevant signature and duplicate/replay identity? - Are export signatures verified before they count? - Are CE and Export still independently gated and independently stoppable?