How Quorum-QaaS works

Practical Byzantine Fault Tolerance (Castro and Liskov, 1999), hardened, running on four validators, with one narrow way in from the internet.

The path of one digest

1. You send a digest. POST /api/v1/quorum/notarize with your API key and a 64-character SHA-256 hex digest, optionally a request_id. Anything else is refused with 400.
2. The gateway builds one operation. The only operation the internet can order is qaas_notarize of one digest. The validators' state machine treats it as non-mutating, so a tenant can neither write nor delete cluster state. Your tenant id is replaced by a pseudonym (qaas-…) before anything is signed.
3. PRE-PREPARE. The primary for the current view proposes the operation at the next sequence number and signs the proposal.
4. PREPARE. Each validator checks the proposal and signs a PREPARE vote for (view, sequence, digest). 3 matching votes make a PREPARE certificate: the validators agree on the order.
5. COMMIT. Each validator signs a COMMIT vote. 3 matching votes make a COMMIT certificate: the operation is committed and cannot be reordered or replaced, even if one validator lies.
6. The gateway checks before it answers. It fetches both certificates and verifies them itself. A commit it cannot certify is reported NOT_NOTARIZED (503), never as success.
7. You get a receipt. The membership, both certificates with every signed vote, the operation and the sequence.

Why 4 and why 3

PBFT tolerates f Byzantine (arbitrarily faulty or malicious) nodes with N = 3f + 1 nodes. With N=4, f=1. A certificate needs a quorum of ceil((N+f+1)/2) = 3 distinct members. Any two quorums of 3 out of 4 share at least 2 members, at least one of them honest, so two conflicting commits at the same sequence cannot both be certified.

What the verifier checks

• The receipt's membership hashes to its configuration_hash, and that hash equals the one you pinned.
• The operation notarizes exactly the receipt's digest (and the digest you expected, if you pass one).
• The COMMIT certificate has at least 3 distinct member signatures. Votes are keyed by signer; each vote's sender_id must match its key; each signature is checked against the key in the membership, never against a key shipped inside the vote.
• Each vote is the right type (COMMIT in a COMMIT certificate), for the same cluster, epoch, view, sequence and digest.
• The PREPARE certificate verifies, its leader proposal was signed by the primary of that view and carries exactly this operation, request id and client id.
• Certificate and decision hashes match their content; signatures must be canonical base64.

Consensus notarizes; it does not authorize

A CAIN-42 doctrine: consensus cannot make an unauthorized action authorized. A Quorum-QaaS receipt says a digest was ordered and committed. It does not say the thing behind the digest is true, allowed or good.

FIRME AI CORPORATION · CAIN-42 is a Byzantine trust fabric. Numbers marked "our own check" were run by us, not by an independent party. Nothing on these pages is a certification.