feat(external-call): enable hashing scheme V4 on protocol version 36 - #644
feat(external-call): enable hashing scheme V4 on protocol version 36#644angelol wants to merge 2 commits into
Conversation
Replace the dev row of MinimumProtocolVersionToHashingVersion with v36 (the map's onwards semantics keep dev supported), and bind the ProtoVersion(32) codecs of ExternalAuthorization and SubmitterMetadata - whose v31-to-v32 delta is the HASHING_SCHEME_VERSION_V4 enum value plus the Stable-to-Alpha proto-version marker that a v36 codec binding needs - to v36 accordingly. This is the first slice of shipping external calls at protocol version 36: V4 is the hashing scheme that covers recorded external-call results in prepared transactions. Fallout folded in: the ExternalTransactionProcessorSpec rejection test now expects the v36 minimum (and no longer runs at v36, where V4 is accepted); the interactive-submission demo derives its schemes via getHashingSchemeVersionsForProtocolVersion so its dev coverage survives the dev row's removal (resolving the TODO on the exact-key lookup); the five ledger API proto comments claiming V4 is dev-only are updated, with proto-data.yml and openapi.yaml regenerated via GenerateJSONApiDocs; and UNRELEASED.md notes the promotion. Mirrors the V3-to-v35 promotion (86cea8e).
Restores the V4 section, the V3/V4 tabbed exercise-node encoding with the external-call-result encoding, and the V3 wording fixes that were merged in digital-asset#549 (8c30730) and unintentionally reverted by the 2026-07-02 internal sync (ff509b0). The supported-schemes table row says v36 rather than the original dev, matching the promotion.
There was a problem hiding this comment.
We currently don't change the rst files. Can you revert the changes?
@thibault-da What is the procedure to have this reflected in the public docs?
There was a problem hiding this comment.
The public docs are now in a different repo, for this specific file it's here: https://github.com/canton-network/cf-docs/blob/main/docs-main/appdev/deep-dives/external-signing-hashing-algorithm.mdx
My understanding is that one should open a PR directly in that repo to update docs. Not sure how it works for external contributions regarding access
There was a problem hiding this comment.
Would you agree to port the changes to the CF repo ? (not urgent)
rgugliel-da
left a comment
rgugliel-da
left a comment
There was a problem hiding this comment.
LGTM
Please revert changes in the rst file.
simonmaxen-da
left a comment
simonmaxen-da
left a comment
There was a problem hiding this comment.
So this enabled the V4 hashing scheme version, that supports the hashing of external call results, to be used on PV36 but does not actually support the population of external call results (that will be included in follow up PR).
4 participants
First slice of landing external calls in PV36 (per the Slack plan with @paulbrauner-da; September 2nd train). This slice is self-contained and independent of the serialization-version decision for external-call results, which the remaining slices depend on.
What it does
MinimumProtocolVersionToHashingVersionfromdevtov36(onwards semantics keep dev supported), mirroring the V3-to-v35 promotion (86cea8e).ProtoVersion(32)codecs ofExternalAuthorizationandSubmitterMetadatato v36. Their v31→v32 delta is exactly theHASHING_SCHEME_VERSION_V4enum value plus the Stable→Alpha marker, matching the pre-existingViewParticipantDataProtoVersion(32) -> v36binding; codec selection at v35 and below is unchanged.ExternalTransactionProcessorSpecrejection test expects the v36 minimum and no longer registers at v36; the interactive-submission demo derives its schemes viagetHashingSchemeVersionsForProtocolVersion(keeps its dev coverage, resolves the TODO on the exact-key lookup); the five ledger-API proto comments claiming V4 is dev-only are updated withproto-data.yml/openapi.yamlregenerated;UNRELEASED.mdnotes the promotion.external_signing_hashing_algorithm.rst(V4 section, V3/V4 tabbed exercise encoding incl.external_call_results, V3 wording fixes) that was merged in feat(external-call): protocol and transaction-hash foundation #549 and unintentionally reverted by the 2026-07-02 internal sync (ff509b0), with the supported-schemes table saying v36 per this promotion.What it deliberately does not do
External-call results themselves remain gated (LF feature at 2.dev;
minExternalCallResults = VDev;ViewParticipantData.supportsExternalCallResultsat dev) — a v36 V4 flow never encounters a node it cannot hash. Those gates move in the next slices once the serialization version for external-call results below 2.dev is settled.Verification
CANTON_PROTOCOL_VERSION=36:ExternalTransactionProcessorSpec(the ungated honor test now runs V4),InteractiveSubmissionVersioningIntegrationTest+ExternalPartyOnboardingIntegrationTest(external-party flows with V4 as the default scheme, 21 tests green),SerializationDeserializationTest(24/24, round-trips V4 through the v36 codecs),HashingSchemeVersionSpec.devruns of the same suites green — v35-and-below behavior is unchanged, dev keeps V4 via the map's onwards semantics.sbt format+ whole-reposbt scalafixCheckclean. Comment-only proto changes:buf breakingis structure-only, so no snapshot churn.