Tracking: Public Sequencer and Scan on the Global Synchronizer

[pasindutennage-da]

Implementation of the new validator onboarding workflow

• Add integration test with 1 SV & 1 validator
  • directly against Canton: bootstrap synchronizer in permissioned mode
    • reference SV1Initializer:bootstrapDomain (or ConsoleMacros:synchronizer but probably too inflexible)
  • start SV app, should detect that synchronizer is already initialized
  • directly against Canton: create ParticipantSynchronizerPermission for aliceValidator
  • start aliceValidator
• Extend integration test to at least 2 SVs
  • basically the same flow but now when creating the ParticipantSynchronizerPermission for alice you will need two signatures
• Extend SvAppBackendConfig with a feature flag for permissionedSynchronizer, defaults to false
• Change Sv1Initializer to initialize synchronizer in permissioned mode if permissionedSynchronizer = true
  • Replace manual call in integration test by just starting the SV app
• Write Daml code for ValidatorPermission + tests
• Add endpoint to SV app to create ValidatorPermission instead of a secret
  • existing endpoint for creating a secret is prepareValidatorOnboarding
  • All endpoints should also be behind the feature flag
• Add trigger to SV app that creates ParticipantSynchronizerPermission topology txs based on ValidatorPermission Daml contracts
• Extend trigger in SV app to create ParticipantSynchronizerPermission for SvOnboardingRequest
  • needs double checking that this works, if not add a second step before that which just creates the ParticipantSynchronizerPermission
  • integration tests should have no manual stops to create topology txs anymore
• Change validator app to create ValidatorLicenseRequest if feature flag is set
• Add automation to SV app to look for ValidatorLicenseRequest and create ValidatorLicense
• Add scan endpoint to lookup if a given participant id is permissioned
• Change validator app to poll scan until it is permissioned
• Add UI to SV app to permission validator through new flow

DevNet validator onboarding workflow

• (a) Implement SV UI and App support to save public keys (config or database).
• (b) Implement SV App changes to automate onboarding requests from key-known validators

Implementation of new validator revocation workflow

• Extend Daml code to support revocation by setting flag on ValidatorPermission
• Add SV app endpoints to vote on those flags
  • if the existing one is not sufficiently generic
• Add automation to revoke ParticipantSynchronizerPermission based on ValidatorPermision flags
• Add UI to trigger the vote

Implementation of workflow to change the DynamicSynchronizerParameters OnboardingRestriction to RestrictedOpen

• Integration test
  • bootstrap network with 4 SVs and aliceVaildator in unrestricted open mode
  • directly through Canton: issue ParticipantSynchronizerPermission for the 5 existing nodes
  • directly through Canton: change to permissioned mode
  • check that a new unpermissioned node fails to onboard
    • consider just starting the participant
  • check that SV1 can permission bobValidator and it works™
• extend Daml models with a flag on whether sync is permissioned
• add automation to SV app to issue ParticipantSynchronizerPermission for all existing nodes once flag is se
• add automation to SV app to switch to restricted open once flag is set + ParticipantSyncPermission has been created for all existing nodes