PoC (draft): buy dedicated-synchronizer traffic in CC (rung 2/2)

[salindne]

Draft PoC, rung 2 of 2, stacked on multi-sync-poc-registration (#1).

What this does

Adds the on-ledger purchase step: a buyer burns Canton Coin (Amulet) on the decentralized synchronizer to buy extra traffic for a registered dedicated synchronizer, reusing Splice's existing traffic-fee and burn machinery unchanged.

• AmuletRules_BuyDedicatedSyncTraffic choice:
  • requires a matching RegisteredSynchronizer (supplied via explicit disclosure), the registration gate from rung 1;
  • reuses computeSynchronizerFees (bytes to USD to CC) and splitAndBurn exactly as the existing AmuletRules_BuyMemberTraffic does, so the economics are identical to the decentralized-sync traffic buy;
  • enforces the minTopupAmount floor and an expectedDso anti-tamper check;
  • records a DedicatedSyncTraffic.
• DedicatedSyncTraffic template: the purchase record. Signatory is the DSO party, and it is observed by the operator, so the operator's node can pick up the purchase on-ledger (event-driven, no polling) and later grant the traffic on its own sequencer. Separate template; no MemberTraffic schema change.

How it's verified (TestBuyDedicatedSyncTraffic, Daml Script)

• test_BuyDedicatedSyncTraffic (happy path): register, fund a buyer, run the buy; asserts a non-zero Amulet burn (amuletPaid > 0), a DedicatedSyncTraffic with the expected dso/operator/synchronizerId/memberId/totalPurchased, and operator visibility.
• Negatives: below-minTopupAmount rejected; mismatched expectedDso rejected before any burn; empty synchronizerId rejected.

Design notes

Additive and reuse-first: no new economics, no MemberTraffic schema change, no change to the existing AmuletRules_BuyMemberTraffic path. The registration gate means traffic can only be bought for a governance-registered synchronizer.

Out of scope (next phase)

On-ledger only. This proves authorize, burn, record. The operator actually granting traffic on its sequencer (reconcile trigger + operator node) and a LocalNet register/buy/grant end-to-end are the next workstream.

Tracked in

Internal work breakdown in ChainSafe/canton-extending-mainnet (private): #29 (AmuletRules_BuyDedicatedSyncTraffic + DedicatedSyncTraffic); part of Epic #13 (E1) and #12 (E0). Follow-ups from review: #34 (merge machinery), and registry-held migrationId validation (#27 / #29).

[timwu20]

The PoC's registration model is a set of free-standing, DSO-signed RegisteredSynchronizer contracts, and AmuletRules_BuyDedicatedSyncTraffic derives synchronizerId and operator from whichever registration cid the buyer discloses. Every such cid is genuinely governance-created, so there's no forgery issue — but nothing on-ledger says "at most one live registration per synchronizer id," and nothing links successor registrations to their predecessors.

The scenario that makes this bite needs no attacker, just operator rotation: sync S hands over from operator A to B; governance registers (S, B); the old (S, A) contract stays active because nothing archives it. Buyers holding the old cid keep purchasing against it — the burn succeeds, the DedicatedSyncTraffic record is created with A as observer, and B's reconcile automation never sees it. Net: the buyer's Amulet is burned and the traffic grant is never applied, with no error anywhere. Once reward reporting lands, a stale registration is also a lever for misattributing another sync's activity.

The template can't self-defend as written: choices can't query the ACS, and Daml 3.x has no contract keys — so uniqueness needs a serialization point. Proposal: make a singleton registry the only factory for registration children, keeping the operator-observer and disclosed-fetch mechanics of this PR untouched:

template SynchronizerRegistry with
    dso : Party
    entries : Map Text (Party, ContractId RegisteredSynchronizer) -- syncId -> (operator, live child)
  where
    signatory dso
    choice Registry_Register : ... with synchronizerId; operator
      controller dso
      do require "not already registered" (not (Map.member synchronizerId entries))
         child <- create RegisteredSynchronizer with dso; synchronizerId; operator
         create this with entries = Map.insert synchronizerId (operator, child) entries
    choice Registry_Rotate : ...     -- archives the predecessor child + inserts the new one, atomically
    choice Registry_Deregister : ... -- archives the child + removes the entry

Because every register/rotate consumes the singleton, concurrent registrations become a clean ledger conflict (one wins, one rejects) — uniqueness by UTXO semantics rather than by discipline. Rotation archives the predecessor in the same transaction, and since an archived cid can no longer be fetched, buyers holding a stale reference fail fast instead of burning into a void. Serialization through one contract is a non-cost at governance cadence, and a dedicated singleton avoids growing AmuletConfig.

[timwu20]

Flagging for when this carries real traffic: we'll need a merge path for these records. Every purchase creates one (numPurchases stays 1) and nothing consumes them — at the auto-top-up cadence that's ~144/day per active member per sync. MemberTraffic handles this with DsoRules_MergeMemberTrafficContracts + the SV merge trigger + numMemberTrafficContractsThreshold; since this is deliberately a separate template we need the twin of that machinery. Without it: every SV participant stores every record forever (dso is sole signatory), the reconciler's exact sum per (memberId, synchronizerId, migrationId) is O(n) over an ever-growing set (the grant is an absolute total, so no windowing), and none of it is ever prunable.

One gotcha: the merged record must keep operator as observer, or our on-ledger ingestion goes blind right when compaction starts. Ties into Itai's note about scoping the merge trigger per sync id — same work item from this template's side.

[salindne]

Agreed, this is required before it carries real traffic. Tracked in ChainSafe/canton-extending-mainnet#34, which I've expanded to cover the on-ledger merge choice (twin of DsoRules_MergeMemberTrafficContracts) + a threshold config + per-sync-id scoping, and I called out the operator-must-stay-observer constraint explicitly. Out of scope for this on-ledger PoC (it's in the next workstream), but captured. Thanks for the detailed flag.

[timwu20]

Heads-up: migrationId is buyer-supplied with no validation and no on-ledger discovery path. The reconciler will only sum the current migration id, but for a dedicated sync that id is operator-managed — a buyer passing a stale one burns Amulet into a record we'll never count, silently. Upstream BuyMemberTraffic has the same shape, but there the top-up automation knows the gsync migration id; our buyers have no equivalent.

If we go the registry-singleton route (see the registry comment), the registry entry is the natural home for the sync's current migrationId — closes the validation gap and gives buyers discovery in one move. (memberId is similarly free text with only a non-empty check; lower stakes, same idea.)

[salindne]

Agreed, and the registry-singleton fix is the right shape. Tracked: ChainSafe/canton-extending-mainnet#27 (hold the sync's current migrationId on the RegisteredSynchronizer entry, for validation + buyer discovery) and ChainSafe/canton-extending-mainnet#29 (validate the buy against it), which closes the silent-loss and discovery gaps in one move. We'll decide whether to fold it into this PoC now or take it next iteration.

[timwu20]

Tiny one: "non-decentralized" reads backwards — a BFT extension sync is decentralized. Maybe "separately-operated synchronizer"? Stays inside the vocabulary rules.

[salindne]

Good catch, "non-decentralized" does read backwards. Will change to "separately-operated synchronizer" (stays within the vocabulary rules). Comment-only, so it rides the next DAR regen.