feat: restrict onboarding on the dedicated synchronizer - #36
Conversation
1277ed1 to
5aa46a6
Compare
| .copy(maxBaseTrafficAmount = baseTrafficAmount) | ||
| ) | ||
| ), | ||
| onboardingRestriction = if (permissionedSynchronizer) RestrictedOpen else UnrestrictedOpen, |
There was a problem hiding this comment.
i'm not sure this is gonna work properly, if you go from unrestricted -> restricted, you need to actually issue trust certificates for all existing nodes. We also need tests for this.
There was a problem hiding this comment.
For unrestricted -> restricted I think the trust certificate is already there while onboarding the need to given ParticipantSynchronizerPermission.
So what do you think we should keep it Non restricted by default? Or the other way might be Started Restricted and do the steps required to give the permission.
And testing is coming in the next PR.
There was a problem hiding this comment.
Sorry yes I meant participant synchronizer permission not the trust certificate.
So what do you think we should keep it Non restricted by default?
I would just not have the trigger change the permissioning at all. Instead directly set the permissioning level when you bootstrap the synchronizer.
And testing is coming in the next PR.
Our usual policy is that by defaults should always be in the same PR that introduces a change.
1cbb4cb to
4855555
Compare
The reconciliation trigger sets the onboarding restriction alongside traffic control, so a dedicated synchronizer admits only participants its owner has permissioned. Configurable, and on by default. Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>
5aa46a6 to
7dfce3f
Compare
…ated-synchronizer-onboarding-restriction [ci] Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>
The bootstrap permissions the participants already on the app-synchronizer and then sets RestrictedOpen, so the operator never changes the permissioning itself. The LocalNet end-to-end test asserts the restriction and that an admitted participant still transacts. Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>
2 participants
Part of ChainSafe/canton-extending-mainnet#99
Summary: The app-synchronizer is bootstrapped restricted: its participants are permissioned first,
then the synchronizer goes to
RestrictedOpen, so the sync operator never changes thepermissioning itself. Stacked on #33.