Skip to main content

Kalypso

Kalypso is composed of its core smart contracts and a matching engine. The system aims to facilitate the creation and integration of new Markets into the Kalypso ecosystem through which Proof Requesters can request proofs from hardware operators. The section below aims to give a brief overview of the software components composing the Kalypso Marketplace.

If you are rather interested in learning more about Kalypso's architectural design, check out the protocol description instead! And if you would like to get your hands dirty directly,

Do not forget to install the kalypso-sdk which simplifies interactions with Kalypso smart contracts.

Kalypso architecture

Core Smart Contracts​

  • Proof Marketplace Contract: Manages operations within the proof marketplace.
  • Generator Registry Contract: Oversees the registration of Generators.
  • Key Registry Contract: Handles key registration processes.

Matching Engine​

  • Ensures efficient matching of Proof Requesters with Proof Generators.

Markets​

Each circuit and app has its own peculiarities like minimum stake amount (based on estimated cost of attack or opportunity cost of proof delays), requirement for TEE support (based on whether private inputs are involved), recommended proving software and more. Unique markets can thus be created for different circuits.

Overview​

Various markets can co-exist on the Kalypso Marketplace. A Market is composed of a subset of the components below. Most of these components come pre-built but a few have to be provided by the Market Creators. By utilizing these components, Kalypso aims to create a versatile and integrated marketplace.

Proof Generators​

There are two types of Proof Generators in Kalypso: those that can generator proofs for Markets which support confidential inputs and those that can't.

Proof Generators for Markets supporting only public inputs

The key components of these kinds of Generators are:

  • kalypso-listener: This needs to be downloaded and run based on the system being used.
  • prover-gateway: The prover-gateway is responsible for producing the proofs for requests it receives via the webhooks. The API standard of the webhook will be explored in upcoming sections. This component is to be built by Market Creators and then plugged on to the kalypso-listener.

Proof Generators for Markets supporting confidential inputs

The key components of these kinds of Generators are:

  • generator-client: This component comes as part of the Generator enclave setup. The operator of the Generator can interact with the Generator using the generator-client and kalypso-sdk.
  • kalypso-listener: It also comes as part of the Generator enclave setup. It listens for requests assigned to the Generator and forwards the to the prover-executable.
  • prover-executable: The prover-executable is responsible for producing the proofs for requests it receives via the webhooks. The API standard of the webhook will be explored in upcoming sections. This component is to be built by Market Creators and then plugged on to the kalypso-listener.

Input Verification Enclave​

The Input Verification Enclave helps Generators verify inputs and prevent spam. If proofs can't be generated for a given input, it provides an attestation for the same and shares it with the Generator.

  • input-verification-executable: This is the main executable responsible for checking whether a proof can be created for a given input. The API standard of the webhook will be explored in upcoming sections.

Proof Verification Contracts​

Proof verification is necessary to check whether the proofs generated by Generators are valid. You can use any one of the following two Proof Verification methods:

  • On-chain verification: Most libraries/tools to generate zk proofs also generate a proof verification contract that can be plugged into Kalypso with slight modification.

  • TEE-based verification: If proofs would be too expensive to verify on-chain, the proofs can be verified in a TEE and a contract that verifies TEE attestations can be deployed instead.

info

Note: Not all components may be required for a Market. Also, it may be possible to merge the logic from multiple components into a single component for operational or cost efficiency in some types of Markets.