Skip to content

feat: bootstrap a dedicated synchronizer - #33

Open
sadiq1971 wants to merge 7 commits into
mainfrom
feat/dedicated-synchronizer-parameters
Open

feat: bootstrap a dedicated synchronizer#33
sadiq1971 wants to merge 7 commits into
mainfrom
feat/dedicated-synchronizer-parameters

Conversation

@sadiq1971

@sadiq1971 sadiq1971 commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

Closes ChainSafe/canton-extending-mainnet#98

Summary: The app-synchronizer is bootstrapped with traffic control on, and the sync operator
narrows its base traffic amount to zero once the DSO registers the synchronizer, refusing to start
if traffic control is off. A LocalNet end-to-end test covers registration, the zero base rate, and
a member buying traffic before it can transact.

splice-localnet-compose.sh start -O

@sadiq1971
sadiq1971 force-pushed the feat/dedicated-synchronizer-parameters branch 7 times, most recently from ee11c3b to 3dd7eca Compare September 9, 2026 12:57
The operator keeps traffic control on for the synchronizer it serves, at a
zero base traffic amount so that all of its traffic is paid for. Enforcement
waits for the DSO registration, since members onboard with charged topology
transactions and traffic cannot be bought for an unregistered synchronizer.
Its store ingests that registration, and it now waits for Scan instead of
failing when Scan is still initializing.

On LocalNet the operator runs behind the sync-operator profile, which
splice-localnet-compose.sh -O turns on, since it cannot start until the
app-synchronizer has been bootstrapped.

Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>
@sadiq1971
sadiq1971 force-pushed the feat/dedicated-synchronizer-parameters branch from 3dd7eca to 4855555 Compare September 9, 2026 13:01
@sadiq1971
sadiq1971 marked this pull request as ready for review September 9, 2026 13:03
@sadiq1971 sadiq1971 self-assigned this Sep 9, 2026
The two reward-accounting BFT reads already have their 'disagreed with
consensus' warning ignored by trigger. They emit 'Consensus not reached.'
when no peer converges at all, which was ignored only for named suites,
so SvTimeBasedAmuletPriceIntegrationTest failed the simtime shard.

Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>
Comment thread project/ignore-patterns/canton_network_test_log.ignore.txt Outdated
@sadiq1971
sadiq1971 force-pushed the feat/dedicated-synchronizer-parameters branch from 1cbb4cb to 4855555 Compare September 10, 2026 10:18
It is unrelated to this PR: the simtime shard flake it silences comes from
SvTimeBasedAmuletPriceIntegrationTest, not from anything here.

Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>
Look the registration up with findAnyContractWithOffset rather than a
one-element listContracts.

Make the traffic control parameters configurable, the same four the SV
exposes through SynchronizerFeesConfig, defaulting to Canton's own values.
The trigger applies those four and leaves the rest as the synchronizer has
them.

Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>
…end to end [ci]

The app-synchronizer is bootstrapped with traffic control at Canton's defaults, and the
sync operator refuses to start against a synchronizer that does not run it.

Adds a LocalNet end-to-end test: the DSO registers the synchronizer, the operator narrows
the base rate to zero, and a member buys traffic before it can transact on it.

Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>
Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>
The compose start returns before the SV serves its DSO info and before the validator
has onboarded the operator's ledger API user, so CI failed on a 404 from /v1/dso.

Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>

private val synchronizerId = store.key.synchronizerId

// Members onboard with charged topology transactions, and traffic cannot be bought for this

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand what you mean with a "charged topology transaction". I also don't see why you need this condition at all. This trigger does not purchase traffic, it just configures the right traffic management parameters.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The guard delayed lowering the base rate until the registration existed: connecting is free, but everything a participant does after that (vetting DARs, the multi-sync flag) is a charged send, so zeroing the base rate before the DSO had registered the synchronizer left a participant still setting up with no allowance and no way to buy. That state is only transient though, once registered it can buy and its pending sends go through.

But starting with base rate 0 - that is not required so I will remove

_.update(trafficControl =
Some(
TrafficControlParameters(
maxBaseTrafficAmount = NonNegativeLong.tryCreate(10 * 20 * 1024),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't look right to me, we should already bootstrap with traffic = 0.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing this runs into: with base rate 0 at bootstrap, plain -M (multi-sync without the sync operator, which LocalNetReassignIntegrationTest uses) stops working, since nothing grants the mediator or the participants any traffic. Two options: apply base rate 0 only when the operator is started (-O), keeping Canton's default for plain -M; or make -M always start the sync operator?
It's something like should we be backward compatible for this flag or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[P2-E8.1] Synchronizer bootstrapping

2 participants