Skip to main content

Solvers

Solvers, i.e., Proof Generators, are the actors who provide an enclave to generate proofs.

The market creator provides the image to be run by the generator. The image contains utilities to decrypt the encrypted private inputs and pass the necessary inputs to a sandboxed environment, which does not have access to the network and the entire file system. The image also contains the verification logic for proofs created by the generator based on the private inputs.

The process of decryption of private inputs before they are used in the sandboxed environment can be expressed mathematically as follows:

Decrypted Inputs=ECIESpriv_keygen1(Encrypted Inputs)\text{Decrypted Inputs} = \text{ECIES}^{-1}_{\text{priv\_key}_{\text{gen}}}(\text{Encrypted Inputs})

Where:

  • Encrypted Inputs\text{Encrypted Inputs} refers to the data encrypted using the generator's public key, initially handled by the Matching Engine.
  • priv_keygen\text{priv\_key}_{\text{gen}} is the generator’s private ECIES key used for decryption.

The Generator is able to set up and load the code necessary for creating proofs inside the sandboxed environment. The sandboxed environment takes public inputs as well as decrypted private inputs as arguments and is expected to return a proof, which is verified by a verifier that will be part of the enclave image.

The operation performed within the sandboxed environment can be described with the following equation:

Proof=GenerateProof(Public Inputs,Decrypted Inputs)\text{Proof} = \text{GenerateProof}(\text{Public Inputs}, \text{Decrypted Inputs})

This encapsulates how the solver (proof generator) uses both public and decrypted private inputs to generate a cryptographic proof. The generated proof is then subject to verification:

Verification Result=VerifyProof(Proof)\text{Verification Result} = \text{VerifyProof}(\text{Proof})

Where:

  • GenerateProof()\text{GenerateProof}(\cdot) represents the computational process to produce a proof based on inputs.
  • VerifyProof()\text{VerifyProof}(\cdot) is the function run by the verifier against a smart contract (zkapp verifier/ tee verifier) to check the validity of the generated proof, ensuring its correctness and integrity.

Staking and Slashing

Kalypso introduces a unique staking mechanism known as "actively locked staking," designed to optimize the allocation of staked assets in a dynamic and efficient manner. This approach allows stakeholders to participate in the network's security and consensus mechanisms while ensuring that their assets are utilized effectively in response to actual demand.

The Mechanism of Actively Locked Staking

In Kalypso's framework, the total stake (S) represents the sum of all assets staked by a generator within the network. However, not all of this stake is statically locked. Instead, Kalypso dynamically locks a portion of the stake based on the real-time demand for services (e.g., processing transactions or validating information). This dynamically locked portion is referred to as the "actively locked stake" (AS).

The calculation of AS is formalized as follows:

AS=i(ni×ki)AS = \sum_{i}(n_i \times k_i)

Where:

  • nin_i denotes the number of requests assigned to the generator in the ith market.
  • kik_i represents the cost stake locked per request for the ith market.

This formula ensures that only the necessary amount of stake is locked to service current demands, allowing the rest of the stakeholders' assets to remain free or "unlocked."

How Slashing Works in Kalypso

In the event that a generator fails to produce the required proof within a predetermined timeframe, Kalypso enforces a penalty by slashing a portion of the stake associated with the failed task. The amount slashed corresponds to kik_i which is the cost stake locked per request for the ith market as defined in the actively locked staking model.

Stake Slashed on Failure=ki\text{Stake Slashed on Failure}=k_i

Where:

  • kik_i represents the cost stake locked per request for the ith market.

Implications of Actively Locked Staking

The actively locked staking mechanism ensures that the total stake SS minus the actively locked stake ASAS remains unlocked and available for other purposes unless there's a surge in demand. Specifically,

Unlocked Stake=SAS\text{Unlocked Stake} = S - AS

This portion of the stake, while not actively locked, is still under the control of the matching engine, which reserves the right to lock additional stakes in response to increased demand from the market.

Advantages of This Approach

  • Efficiency and Flexibility: By only locking the portion of the stake that is needed based on current market demands, Kalypso ensures that the staking mechanism is both efficient and flexible.
  • Market Responsiveness: This model allows Kalypso to quickly adapt to changes in demand, locking additional stakes as required to meet the needs of the market.

This actively locked staking approach presents a significant evolution in how staked assets are managed, promising enhanced efficiency and adaptability for blockchain networks.