PoC: register dedicated synchronizers via governance (rung 1/2) - #1
Conversation
… 1/2) [ci] Signed-off-by: Sebastian Lindner <33971232+salindne@users.noreply.github.com>
51a8808 to
56e4666
Compare
…isfy check-daml-warts The trailing doc comment on the choice's `p` field ended with the word "fetch", which the grep-based scripts/check-daml-warts.sh flags as a naked fetch invocation (it only ignores full-line -- comments). Reword to drop the word; no code/behaviour change. Fixes the static_tests "Run Daml warts check" step. [ci] Signed-off-by: Sebastian Lindner <33971232+salindne@users.noreply.github.com>
…for damlc docs gen-daml-docs.sh (dpm docs) rejects a Haddock '-- |' doc comment attached directly to a choice: 'parse error on input -- |'. Splice's own choices use plain '--' comments (0/81 in splice-amulet use '-- |' on a choice), and damlc build ignores the distinction, so the Daml tests stayed green while the docs build failed. Convert the doc comments on RegisteredSynchronizer_Fetch and DsoRules_RegisterSynchronizer to plain comments. Verified locally with dpm docs on splice-amulet and splice-dso-governance (both exit 0). [ci] Signed-off-by: Sebastian Lindner <33971232+salindne@users.noreply.github.com>
…erSynchronizer last (SCU) Two issues surfaced by static_tests, both previously masked by the damlc-docs parse error that ran earlier in the same step: 1. DAR lock: the PoC changed splice-amulet + splice-dso-governance source but the checked-in daml/dars/*.dar and daml/dars.lock were stale (DarLockChecker: 'update the checked-in DAR'). Regenerated with 'sbt damlDarsLockFileUpdate'. No version bump needed: 0.1.22 / 0.1.28 are not in release-line-0.6.11. 2. Smart-contract upgrade (per @timwu20 review on PR): moved SRARC_RegisterSynchronizer to the END of DsoRules_ActionRequiringConfirmation. New constructors of a serializable variant must be appended after all existing ones - LF encodes constructor ranks, so inserting mid-list re-ranks the following constructors and breaks upgrade compatibility with the released splice-dso-governance. Semantically identical (matching is by name); the case arm and the choice are unchanged. [ci] Signed-off-by: Sebastian Lindner <33971232+salindne@users.noreply.github.com>
…esources
static_tests' illegal-references check bans deployment-specific vocabulary
in daml/ ("global", "CC", DSO outside allowed phrases, lowercase dso in
comments). Reword the PoC comments to the upstream whitelabel terms: "the
decentralized synchronizer", "Amulet", "DSO governance" / "DSO party".
Comment-only, but Daml-LF embeds source locations, so package ids change
anyway: regenerated the checked-in DARs + dars.lock (sbt
damlDarsLockFileUpdate) and DarResources.scala (sbt updateDarResources).
The latter was still carrying pre-refresh package ids, which is what
failed the Scala shards ("No package found for template ...") in the
last CI run.
Verified locally: splice-dso-governance-test and splice-amulet-test
damlTest both green (test_RegisterSynchronizer_viaVote: ok).
[ci]
Signed-off-by: Timothy Wu <tim.wu@chainsafe.io>
0cee7c8 to
c514673
Compare
Per review on PR #1: doc comment via -- ^ after the choice declaration (damlc docs accepts this placement), drop the kept-last upgrade note and the redundant nonconsuming/vote-dispatch explainer; regenerate artifacts. Signed-off-by: Timothy Wu <tim.wu@chainsafe.io>
moritzkiefer-da
left a comment
There was a problem hiding this comment.
thx, I would recommend to not merge into main (even if this is a fork) but have some long running feature branch that we can merge things into. Just gets less confusing when switching between upstream splice and this fork
Makes sense — done: created One CI note from checking the workflow triggers: PR CI ( |
PoC, rung 1 of 2, on DA's
splice-multi-syncfork (using this fork's CI).What this does
Adds the on-ledger registration step for the "Extending Mainnet" CIP: letting DSO governance authorize a dedicated (operator-run) synchronizer so its traffic can later be funded in Canton Coin, the way the decentralized synchronizer's traffic is today.
RegisteredSynchronizertemplate: a registry entry binding asynchronizerIdto theoperatorparty that runs it. Signatory is the DSO party; the operator is an observer, so it learns it has been registered. A publicRegisteredSynchronizer_Fetchchoice (mirrorsOpenMiningRound_Fetch) lets a later buyer read it via explicit disclosure.DsoRules_RegisterSynchronizergovernance action (SRARC_RegisterSynchronizervariant + choice + dispatch inexecuteActionRequiringConfirmation): a supermajority SV vote creates the registry entry.In plain terms: a DSO vote records "synchronizer X, run by operator Y, is authorized for CC-funded traffic."
How it's verified (
TestRegisterSynchronizer, Daml Script)test_RegisterSynchronizer_viaVoteruns a real 4-SV supermajority vote (RequestVote, CastVote x3, CloseVoteRequest,executeActionRequiringConfirmation,DsoRules_RegisterSynchronizer) and asserts the resultingRegisteredSynchronizercarries exactly the{dso, synchronizerId, operator}voted for and is visible to the operator. Negative: emptysynchronizerIdis rejected by the templateensure.Design notes
Additive: new template + new governance variant/choice only; no change to existing templates or
MemberTraffic. The newSRARC_RegisterSynchronizerconstructor is appended last (SCU upgrade-safe).Out of scope (next phase)
On-ledger only. The off-ledger side (the operator node granting the traffic) and a LocalNet end-to-end are the next workstream, not in this PR.
Rung 2 (the CC-funded buy) stacks on this in #2.
Heads-up for review: two code comments in this diff refer to the buy rung by its earlier sibling name (
AmuletRules_BuyDedicatedSyncTraffic); #2 reworked the buy rung to extendAmuletRules_BuyMemberTrafficand corrects those comments.Tracked in
Implements E1-1 (ChainSafe/canton-extending-mainnet#27) and E1-2 (#28); ChainSafe work breakdown; part of Epic E1 (#13). Follow-ups from review: registry uniqueness (ChainSafe/canton-extending-mainnet#54), registry-held
migrationIdwith operator-controlled bump (#55), and registration lifecycle (#30).Update (2026-08-19): tracked under the phase-based plan as [P2-E1.2] ChainSafe/canton-extending-mainnet#81 and [P2-E1.3] ChainSafe/canton-extending-mainnet#82 (both closed as shipped by this PR; the FR-1 authorization-model decision is ChainSafe/canton-extending-mainnet#80). Registry uniqueness carries as [P2-E1.4] ChainSafe/canton-extending-mainnet#54.