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.
The “Responder ID” which is used in attestation with clients.
The URI on which your node is listening for consensus message traffic from peers.
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.
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.
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.
URI, for example:
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
insecure-mca to indicate whether TLS is used. Since the admin gateway runs inside the container,
insecure-mca is sufficient.