Proof Request

Proof Requests are fundamental to interacting with Kalypso. They tell the system exactly what kind of zero-knowledge (ZK) proof you need and your constraints or preferences for generating it.

Let's break down how this differs from traditional approaches before diving into making requests:

Traditional approach: In traditional setups, you generate the ZK proof entirely on your own device. This can be computationally demanding. Kalypso offloads this work to specialized solvers.

With Kalypso: On Kalypso, you submit a proof request with inputs which are encrypted if supposed to be private. A Proof Generator who satisfies specified constraints is chosen by the Matching Engine. After successful proof generation, the Generator puts the proof on-chain from where you can retrieve the proof. Detailed information is available in the section on Proof request and delivery lifecycle.

Request

The prover initiates a proof Request on-chain on the Kalypso contract. A Request has the following structure:

    struct Bid {
        uint256 marketId;
        uint256 reward;
        uint256 expiry;
        uint256 timeForProofGeneration;
        uint256 deadline;
        address refundAddress;
        bytes proverData;
    }

marketId: Market ID
reward: The number of USDC tokens issued as payment to the generator upon successful job completion.
expiry: Specifies the cutoff timestamp by which the matching engine must assign the task to the proof generator.
timeForProofGeneration: Specifies the maximum duration allotted to the generator for completing the proof once the job has been assigned.
deadline: The timestamp by which the proof must be submitted on-chain. (Note: This value is derived and varies based on the job assigned to the operator.)
refundAddress: The address where any refund will be sent (if applicable).
proverData: Public/non-confidential data of the job

The Request includes additional components that are not stored on-chain but are instead exposed through events. Since secrets cannot be processed, they are transmitted as part of these events.

function createBid(
        Struct.Bid calldata _bid,
        Enum.SecretType _secretType,
        bytes calldata _privateInputs,
        bytes calldata _acl,
        bytes calldata _extraData
    )

_secretType: Currently, only the CALLDATA secret type is supported. In this mode, the encrypted secret is transmitted via calldata. Support for additional secret types may be introduced in future updates.
_privateInputs: Encrypted private inputs required for secure proof computation.
_acl: Specifies the access control list for decrypting the private inputs. This list ensures that only the Matching Engine is authorized to decrypt and access the data.
_extraData: Any extra unencrypted data, that is not part of Bid

Request​

Request