validator_operator/validator_onboarding

[giscus[bot]]

validator_operator/validator_onboarding

https://docs.dev.sync.global/validator_operator/validator_onboarding.html

[simonletort-da]

It would be useful to add details in the doc about the requirement of limiting IPs per validator, i.e. "asking nodes to put their AZs behind a single gateway rather than submitting an IP per AZ".

[simonletort-da]

and also (feedback from Stef @ Kaiko) specify that IP for Mainnet has to be different from IP for dev/testnet (allowed to have same there)

maybe here: https://docs.dev.sync.global/validator_operator/validator_onboarding.html#onboarding-process-overview

[waynecollier-da]

The whitelisted IP must be different for all three networks.

[stephencompall-DA]

hyperledger-labs/splice#2157

[simonletort-da]

It would be great to detail in the docs how many SVs need to have to whitelisted a given IP address for a validator to be able to connect. I think it's 2/3.

[waynecollier-da]

The default setting is 2/3. But the Validator can configure this up or down, at their preference.

Tradeoffs are:

1. You can't necessarily trust a single SV, or a small number. So keeping at 2/3 is good for the Validator
2. If a Validator always routes its traffic through the same SV, and the load is high, that SV might choose to block that Validator.
3. If the Validator changes its configuration to link to only a few SVs, then those SVs could more easily block the Validator.
4. If the Validator requires all the SVs to accept it, that delays the onboarding process for the Validator.

I agree it would be helpful to explain this in the docs, show how to do it, and describe the tradeoffs.

[martinflorian-da]

Just to avoid confusion:

You can't necessarily trust a single SV, or a small number.

You can absolutely configure your validator to trust a single SV (trust fully, no BFT; both for scan and for sequencer; documented here / nonSvValidatorTrustSingleScan and ff). However your only alternative to that is currently "BFT over all SVs". A validator will also never fully stop trying to reach an SV that hasn't whitelisted it, so at the very least they can expect some log noise in such cases.

[stephencompall-DA]

hyperledger-labs/splice#1979

[sosaucily]

For the section on "Validating if your IP has been Approved" consider adding the URLs for testnet and mainnet as well. It's not clear from the context that the sample URL provided is just for devnet

[stas-sbi]

the URLs are different in docs for testnet and mainnet

• https://docs.test.sync.global/validator_operator/validator_onboarding.html
• https://docs.sync.global/validator_operator/validator_onboarding.html

[waynecollier-da]

"If you want to access the Canton Coin Scan Web UI from your laptop, you also need to ensure that you can connect to a VPN operated by one of the SVs."

To be more precise, you need to access the Canton Coin Scan web UI from any IP address whitelisted by the SVs. This could be a VPN operated by your company and whitelisted by the Super Validators, or a cluster already whitelisted by the SVs, or a VPN operated by a Super Validator and whitelisted by the others.

[waynecollier-da]

Validator Party Hints:

Make sure your validatorPartyHint follows the correct format, which is:

--<1>

Formally, it will be checked during install against this regex expression:

[a-zA-Z0-9_]+-[a-zA-Z0-9_]+-[0-9]

[configuration-ninja]

Hi,

I’d like to confirm whether my IP address has been approved. I’m attempting to reach the endpoint:

https://scan.sv-1.global.canton.network.sync.global/api/scan/v0/scans

However, I’m currently getting a timeout. Does this indicate that my IP is still being processed?
In other words, is it necessary for the IP to be whitelisted in order to receive a response from this endpoint?

Additionally, I noticed that there are separate onboarding documents for testnet and mainnet.
Should the whitelisted IP be able to successfully curl the scan endpoint specific to the corresponding network?

For example, if I’m onboarding to testnet, should I expect a successful response only from the testnet scan endpoint?

[waynecollier-da]

Have you attempted the instructions here:

https://docs.dev.sync.global/validator_operator/validator_onboarding.html#validating-that-your-ip-has-been-approved

[waynecollier-da]

To your second question, yes, separate IPs for TestNet and MainNet, and separate responses.

[configuration-ninja]

Hey @waynecollier-da super thanks for clarification!

Could you confirm my understanding?
Each network uses separate IP whitelists and scan endpoints, if I’m requesting access for testnet, I should be checking the testnet scan endpoint and following the testnet-specific docs, from that whitelisted host (curls). Same goes for devnet and mainnet.
When I query an endpoint for a network I haven’t been approved for yet (or should not be), I expect to get a timeout or no response.

[waynecollier-da]

Yep.

[pv-rahil]

I am trying to set up a Canton validator, and I see that if I want to set it up on the Devnet, I need to get my IP whitelisted. What is the procedure to get my IP whitelisted for the running validator on the Devnet? Also, if I want to run a validator on the Testnet, how can I get a sponsor SV?

[waynecollier-da]

Hi, Rahil. The process is spelled out here:

https://sync.global/validator-request/

You can either reach out to an existing Validator operator, and ask them to run a node for you, or you can request to become a Validator operator yourself. If you become a validator operator, your sponsor will handle the IP whitelisting process.

[pv-rahil]

Thanks for the reply, I appreciate it.
I still have some doubts:

1. Is the whitelisting procedure the same for both Devnet and Testnet?
2. If I become a validator operator on my own, do I still need a sponsor to whitelist the IP?
3. Can I become a Super Validator on my own and run my validator node without sponsorship, or is sponsorship necessary to run the validator?

[waynecollier-da]

All new nodes require either a Super Validator or an existing Validator Operator to sponsor them through the whitelisting process.

The whitelisting procedure is the same for DevNet, TestNet and MainNet.

Super Validators must be approved by vote of 2/3 of the existing Super Validators, via a Canton Improvement Proposal process. You can find the Canton Improvement Proposals here:

https://github.com/global-synchronizer-foundation/cips

[pv-rahil]

Thanks for the reply.

I have some doubts regarding building a non-custodial wallet solution on the Canton Network.

• If I want to run or setup multiple wallets, do I need to run a separate validator node for each wallet?
• The main concern is that the user must have full custody of their wallet keys and wallet data. If the platform is providing wallet services, is this possible?
• As a platform that provides non-custodial wallets, how can it be managed on the Canton Network?

Could you please help me with my queries, or let me know where I can reach out to the Canton community to get the answers?

[waynecollier-da]

Rahil: Please join the discussion on this topic of wallets and nodes at the Global Sync Forum, here:

https://lists.sync.global/g/globalSyncForum/topic/running_a_validator_with/112208596

[stas-sbi]

Here are slightly tuned snippets to check access to Scans and Sequencers which:

• are more concise
• are better handling timeouts
• show better error messages (e.g. show HTTP error 403, 404, etc instead of cryptic JQ errors)
• work with older versions of JQ

for url in $(curl -fsS -m 5 https://scan.sv-1.dev.global.canton.network.sync.global/api/scan/v0/scans | jq -r '.scans[].scans[].publicUrl' ); do
  echo -n "$url: ";
  curl -fsS -m 5 "$url/api/scan/version" | jq -r '.version';
done

for url in $(curl -fsS -m 5 https://scan.sv-1.dev.global.canton.network.sync.global/api/scan/v0/dso-sequencers | jq -r '.domainSequencers[].sequencers[].url | sub("https://"; "")' ); do
  echo -n "$url: ";
  grpcurl --max-time 10 "$url:443" grpc.health.v1.Health/Check;
done

[waynecollier-da]

Many thanks, Stas!

[perbergman]

For testnet is the URL https://scan.sv-1.test.global.canton.network.sync.global/api/scan/v0/scans?

Per

[waynecollier-da]

You can use any of the Scan addresses posted by the Super Validators in the TestNet tab here:

https://sync.global/sv-network

[stephencompall-DA]

hyperledger-labs/splice#1982