Run It!

This is the actual docker run command that pulls it all together.

The entrypoint passes the arguments from the docker run command to the consensus service.

See Configuring Your Node, below, for more details on how to set up the values for the parameters unique to your Consensus Validator Node.

The arguments to the consensus service are the following:

ArgumentValueFunction

peer-responder-id

address:port

The “Responder ID” which is used in attestation with peers and as an identifier for your node in broadcast messages. This is also the value that peers will add to their quorum sets when they trust you.

client-responder-id

address:port

The “Responder ID” which is used in attestation with clients.

peer-listen-uri

URI, for example:

mcp://0.0.0.0:8443/?tls-chain=/certs/your-tls.crt&tls-key=/certs/your-tls.key

The URI on which your node is listening for consensus message traffic from peers.

See Accepting Connections from Trusted and Untrusted Peers.

network

Path to network.toml

Defines the networking and trust configuration for your peer. See Configuring your Node to Connect with your Trusted Peers.

ias-api-key

IAS credential

Your API key for attesting with the Intel Attestation Service. See Getting Intel Attestation Service Credentials.

ias-spid

IAS credential

Your Service Provider ID for attesting with the Intel Attestation Service. See Getting Intel Attestation Service Credentials.

msg-signer-key

Base64-encoded key

Used to sign every consensus message emitted by this node. See Signing Consensus Messages.

ledger-path

Path to local ledger

The purpose of consensus is to agree on the validity of transactions and append to this ledger. The ledger should be persistent in case consensus must be restarted.

sealed-block-signing-key

Path to local sealed backup location.

The block signing key signs each block to provide an audit trail of which enclaves participated in consensus for each block. The signing key is created in the enclave, and never leaves the enclave. The seal key is tied to the CPU, so the signing key is written as backup to the sealed-block-signing-key path, and can be read in the case that consensus restarts on the same CPU. If consensus is rescheduled on a different CPU, a new signing key will be created, and the signatures will indicate that a new enclave is participating in consensus.

origin-block-path

Path to local origin block, if ledger-path is an empty directory.

If the node is starting up without an existing ledger, you can provide the origin-block-path, which will copy the origin-block contents to the ledger-path on startup.

admin-listen-uri

URI, for example: insecure-mca://127.0.0.1:9091/

The admin http gateway sends gRPC requests to the admin-listen-uri for the consensus service, which is listening as specified. The scheme is either mca or insecure-mca to indicate whether TLS is used. Since the admin gateway runs inside the container, insecure-mca is sufficient.

Last updated