Docker Compose Validator Deployment

Documentation Index

Fetch the complete documentation index at: https://docs.canton.network/llms.txt

Use this file to discover all available pages before exploring further.

• Application development, where one needs an ephemeral validator that is easy to deploy.
• Production validators, with the following caveats:
  • The default deployment is highly insecure. Authentication should be enabled as described in the authentication section.
  • There is no support for ingress from outside your machine, nor is there support for TLS. The deployment should be kept local to your machine only and not exposed externally.
  • Reliability & scalability: docker-compose will restart containers that crash, and the deployment supports backup&restore as detailed below, but a docker-compose deployment is inherently more limited than a cloud-based Kubernetes one.
  • Monitoring: The deployment, as opposed to a Kubernetes-based one, does not include monitoring.
  • For production settings, you should aim to keep your validator up and running constantly, in order to avoid losing out on rewards, and avoid issues with catching up on ledger state after significant downtime.

​

Requirements

1. A linux/MacOS machine with the following:
   1. docker compose - at least version 2.26.0 or newer
   2. curl
   3. jq
   Note that both AMD64 and ARM64 architectures are supported.

   > docker compose version
   Docker Compose version 2.32.1
   > curl --version
   curl 8.11.0 (x86_64-pc-linux-gnu) libcurl/8.11.0 OpenSSL/3.3.2 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.64.0
   Release-Date: 2024-11-06
   Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
   Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
   > jq --version
   jq-1.7.1

2. Your machine should either be connected to a VPN that is whitelisted on the network (contact your sponsor SV to obtain access), or have a static egress IP address. In the latter case, please provide that IP address to your sponsor SV to add it to the firewall rules.
3. Please download the release artifacts containing the docker-compose files, from here: Download Bundle, and extract the bundle:

tar xzvf 0.6.3_splice-node.tar.gz

​

HTTP Proxy configuration

  services:
    validator:
      environment:
        JAVA_TOOL_OPTIONS: >-
          -Dhttps.proxyHost=your.proxy.host
          -Dhttps.proxyPort=your_proxy_port

  services:
    participant:
      environment:
        JAVA_TOOL_OPTIONS: >-
          -Dhttps.proxyHost=your.proxy.host
          -Dhttps.proxyPort=your_proxy_port

​

Bypassing the proxy for specific hosts

• Patterns match the request host name case-insensitively.
• * is a wildcard. Conventionally it is used at the start (*.internal) or end (10.*) of a pattern.
• Matching is performed on the raw host string from the request URI. No DNS resolution is performed, so localhost and 127.0.0.1 are treated as different names unless you list both.
• An empty value (e.g. -Dhttp.nonProxyHosts=) means “no bypass patterns”.

services:
  validator:
    environment:
      JAVA_TOOL_OPTIONS: >-
        -Dhttps.proxyHost=your.proxy.host
        -Dhttps.proxyPort=your_proxy_port
        -Dhttp.nonProxyHosts=localhost|127.0.0.1|*.internal|10.*

​

Deployment

1. Change to the docker-compose directory inside the extracted bundle:

   cd splice-node/docker-compose/validator

2. Export the current version to an environment variable: export IMAGE_TAG=0.6.3
3. Run the following command to start the validator node, and wait for it to become ready (could take a few minutes):

./start.sh -s "<SPONSOR_SV_URL>" -o "<ONBOARDING_SECRET>" -p "<party_hint>" -m "<MIGRATION_ID>" -w
```text

Where:

`<party_hint>` will be used as the prefix of the Party ID of your validator's administrator.
This must be of format `\<organization\>-\<function\>-\<enumerator\>`, e.g. `myCompany-myWallet-1`. It cannot be changed over time as it is part of the validator operator party ID.

​

Logging into the wallet UI

​

Logging into the CNS UI

​

Accessing the Canton Participant APIs

​

Configuring Authentication

./start.sh -s "<SPONSOR_SV_URL>" -o "<ONBOARDING_SECRET>" -p "<party_hint>" -m "<MIGRATION_ID>" -w -a

​

Configuring Automatic Traffic Purchases

   export TARGET_TRAFFIC_THROUGHPUT=20000 # target throughput in bytes/second
   export MIN_TRAFFIC_TOPUP_INTERVAL="1m" # minimum interval between top-ups

​

Configuring sweeps and auto-accepts of transfer offers

# sweep by transferring directly through the transfer preapproval of the receiver,
# if set to false sweeping creates transfer offers that need to be accepted on the receiver side.
# Note that this refers to the preapprovals described in https://docs.dev.sync.global/background/preapprovals.html
# and not to auto accepting transfers. Auto accept transfers does not setup preapproval contracts that allow
# for a direct transfer but just automates the acceptance of the transfer offer so in that case
# useTransferPreapproval should be set to false.
services:
  validator:
    environment:
       - |
          ADDITIONAL_CONFIG_WALLET_SWEEP=
            canton.validator-apps.validator_backend.wallet-sweep {
              "<senderPartyId1>" {
                max-balance-usd = 1000
                min-balance-usd = 100
                receiver = "<receiverPartyId>"
                use-transfer-preapproval = false
              }
            }

services:
  validator:
    environment:
       - |
          ADDITIONAL_CONFIG_AUTO_ACCEPT_TRANSFERS=
            canton.validator-apps.validator_backend.auto-accept-transfers {
              "<receiverPartyId>" {
                from-parties = ["<senderPartyId1>", "<senderPartyId2>"]
              }
            }

​

Integration with systemd and other init systems