ARCHIVE/xahaud
3
0
Fork 0
mirror of https://github.com/Xahau/xahaud.git synced 2026-04-29 15:37:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(consensus): clarify validation sidecar signing rule

Browse Source 
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.
This commit is contained in:
Nicholas Dudfield
2026-04-27 15:45:27 +07:00
parent a61f334ca2
commit f13233b00a
2 changed files with 14 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
include/xrpl/proto/ripple.proto
View File

@@ -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

20
src/xrpld/app/consensus/ConsensusExtensionsDesign.md
View File

@@ -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?