Guardian nodes
What the three guardian nodes are, what they do for every registration and value transaction, why their code can be trusted, and what they can and cannot do.
Guardian nodes are three independent services that must all co-sign every registration and every value transaction before the shielded pool accepts it. Each also holds one share of the viewing key that every transaction carries.
What they are
Each guardian node runs inside an AWS Nitro enclave on the Turnkey Verifiable Cloud (TVC), Turnkey's service for running enclave applications, under QuorumOS, the enclave operating system Turnkey builds. Together the three nodes form a guardian cluster, which the shielded pool reads for every transaction.
No person holds a guardian node's keys. They exist only inside its enclave. Each node's long-lived key material comes from its own QuorumOS quorum key, which is split among the node's quorum members and reassembled only inside the enclave, at each boot. The keys its committee signature depends on come from a root that is generated inside a dedicated enclave, root-gen, and delivered only to enclaves running approved code. The quorum keys themselves are generated by another enclave, quorum-gen.
What they do
Co-sign. Each node signs the transaction's context digest, a hash of the whole public transaction, with its BLS key. Your device combines the three nodes' signatures with those of the other attesters into one combined attester signature, which the pool checks. Because the digest covers the whole transaction, the signature authorises exactly that transaction. See signatures.
Hold a viewing-key share. Your device splits a viewing key three ways and sends each node its share, encrypted to that node alone: your outgoing viewing key at registration, and the per-transaction viewing key in every value transaction. One share reveals nothing about the key. See secret sharing.
Escrow the share. Each node returns its share re-encrypted under a key only its own enclave can derive, and the relay in front of it stores the result in write-once storage. The share therefore survives the node being restarted.
What they check
Before it signs, a node checks that the request is meant for it, that its share decrypts, and that the share matches the commitment inside the transaction's zero-knowledge proof. A transaction therefore cannot collect the guardians' signatures while carrying shares that do not rebuild the key it actually used.
A node does not verify proofs, read the chain or screen addresses. Those checks belong to the shielded pool program and the other attesters.
Why their code can be trusted
Which enclave code a cluster accepts is approved through governance, and a node's key counts only once its AWS attestation, which proves the code running in its enclave, has been verified on chain against that approval. A node that restarts must attest again before it signs for the pool. See trusted execution.
What they can and cannot do
They cannot move funds. The pool releases tokens only for a transaction with a valid zero-knowledge proof, fresh nullifiers and the combined attester signature. A guardian's signature is required but never enough, and the viewing-key shares they hold can read, never spend.
Any one of them can stop transactions. The pool accepts only a signature all three nodes produced, so one node that is offline, restarting or refusing halts every registration and value transaction until it is back. The escape hatch needs no guardian signature and stays open.
Who controls the cluster
Which nodes are members of the cluster, and which enclave code they may run, are decided through timelocked governance. A node's own operator can also take it out of the cluster at once, and anyone can evict a node running code the cluster no longer approves. See governance and upgrades.
Related
Last updated