Proof request and delivery lifecycle

Once a Market is created, Requesters can place Proof Requests for the corresponding circuit. Apps or clients would normally use the Kalypso SDK to place Requests. The SDK allows developers to configure the Market identifier, required response time guarantee and pricing strategy. The latter two fields can either be hardcoded, be dynamically set at runtime by programming some strategy or be left exposed to let end users to decide on the go.

The lifecycle of placing a proof request to its eventual delivery and settlement can be broken down into the following steps:

Step 1: The Requester either through the SDK or via some other means to make Smart Contract calls places a Proof Request. This Proof Request persists on-chain.

Step 2: The Matching Engine monitors the Smart Contract for Proof Requests across all Markets. Upon observing a new Request, it adds the Request to its local orderbook. It uses the Matching Protocol to assign the Request to a suitable Generator registered for the Market. If the Request involves private inputs, the Matching Engine also re-encrypts the inputs with the Generator’s public key at this stage. This assignment is published on-chain as a Task. The timestamp of the block in which the Task gets included is recorded as the start time for purposes of slashing related response time guarantees.

Step 3(a): The Listener module of Proof Generators monitors the Smart Contract for Tasks assigned to it. When a new Task is detected, it decrypts any private inputs and forwards the Task along with the inputs to the Prover module which initiates the proof generation process.

Step 3(b): If the Prover can’t generate proofs for inputs specified in the Request, the Generator either conveys the same directly to the Input Verifier or shares an attestation from the authorized Generator Image (for private inputs) or authorized Input Verification Image (for public inputs that can’t be directly checked on-chain) proving that the inputs were invalid. Upon such a successful claim before the deadline, the Task is canceled, the Generator’s stake is released, the Generator is paid his quoted PricePerProof from the Requester’s deposit and the rest is refunded back to the Requester.

Step 3(c): In cases where the proof can’t be verified on-chain, the Generator sends the proof to the enclave hosting the authorized Proof Verification Image associated with the Market and receives an attestation of the proof’s validity.

Step 4: The Listener module sends the Proof and, if applicable, attestation from the enclave hosting the authorized Proof Verification Image on-chain. If the proof (or its attestation) is valid and is submitted before the deadline, the Generator’s stake is released, the Generator is paid his quoted PricePerProof from the Requester’s deposit and the rest is refunded back to the Requester.

If the proof or its attestation is invalid, the transaction reverts and nothing changes. The Task is still considered pending until its deadline.

Step 5(a): Upon submission of a valid proof, the Kalypso SDK retrieves the proof, decodes it and passes it to the app or client.

Step 5(b): If the proof isn’t received by the expected deadline, anyone (and very likely the Requester itself) can place a slashing request to slash the defaulting Generator.