Securing decentralized ZK prover networks through restaking

We are pleased to share that Kalypso, the ZK proof marketplace, will be collaborating with Symbiotic in a first of its kind partnership to secure decentralized prover networks with restaked ETH.

Advancements in cryptography have made usage of ZK proofs practical in a variety of applications for scaling and privacy. As their usage in rollups, bridges, coprocessors, gaming engines, payment, AI and identity solutions explodes, so will the number of proofs generated. However, the generation of ZK proofs today still remains compute intensive leading to high costs and poor response times for users.

In general, high resource or capital requirements have a centralizing effect which translates to second-order issues in maintaining liveness, fairness and censorship-resistance of associated systems. Proposer-Builder Separation (PBS) solves this elegantly by separating the commoditized task of validation and signing from specialized activities of ordering and MEV extraction. Similarly, proving networks emerge as a critical component of the ZK end game required to ensure the permissonlessness of other layers of the modular ecosystem.

Securing proving through stETH on Symbiotic

Proving networks consist of hardware operators who specialize in generating ZK proofs. Due to the transitive relationship through other components of the infrastructure, it is important that the proof supply chain also provide liveness and censorship-resistance guarantees that end users desire. Proving networks should, therefore, onboard a diverse set of operators and back the protocol’s guarantees with robust mechanism design.

Symbiotic is a permissionless protocol that enables trust-minimized formation of shared security agreements. It simplifies the coordination between operators, providers of economic security (the restakers) and networks to onboard prover hardware for a given set of incentives and slashing conditions. Protocols are only as secure as their weakest link. Amongst different types of collateral, Symbiotic allows networks to be secured by staked ETH, possibly the most credible collateral in the interwoven modular trust infrastructure ecosystem. 

Symbiotic is uniquely suited for Marlin. Marlin consists of a TEE-based network called Oyster. Kalypso uses Oyster to deploy its matching engine. The Oyster protocol itself consists of various protocol actors performing different functions who are kept in check through a mix of incentives and penalties. In addition to stETH and access to a diversified operator base, Symbiotic’s flexible design allows POND, Marlin’s native protocol token to be easily restaked across Oyster and Kalypso.

What is Kalypso?

Kalypso is a ZK proof marketplace that connects users, apps and protocols requiring ZK proofs with hardware providers who can generate them. A competitive market incentivizes hardware providers to try to reduce cost and the time it takes to generate ZK proofs. They may achieve this by securing access to better hardware (GPUs, FPGAs, ASICs), fine-tuning their software, securing affordable energy and cheap colocation facilities.

Key benefits of using a decentralized proof marketplace include:

1. Higher resource efficiency: Operating a prover dedicated to a single network can result in long idle times and poor utilization rate.
   A prover market, on the other hand, aggregates and serves more requests. As the fixed costs can be amortized across several users, protocols and networks, it leads to better resource efficiency which translates to lower costs for users and higher revenue for hardware providers. This in turn allows hardware providers to invest in better quality hardware and software, and upgrade more regularly.
   
2. Stronger liveness and availability guarantees: It is hard and expensive to maintain reliable infrastructure. Faults are a norm and not an exception when it comes to large-scale distributed systems. Additionally, in Byzantine systems, provers may intentionally censor certain transactions or fail to produce proofs halting the protocol.
   A decentralized proof market secured through economic stake ensures that the cost of intentional or unintentional failure is high and that there is sufficient redundancy available.
3. Shorter response times: Client-side proving is constrained by the specs of the user device. What runs smoothly in one stalls another creating uncertainty for application developers. In the case of server-side proving, it leaves teams with the option of constantly upgrading their hardware or being left a generation behind by competitors.
   Kalypso allows proof requesters to mention what they prioritize more - price or time-to-proof, and in case it’s the latter, only the fastest survive.

As a result, Kalypso enables the free market to compete on infrastructure while letting developers focus on their app or protocol.

Leveraging Oyster for optimizing resource allocation

An important design choice for proof marketplaces like Kalypso is the technique used for hardware allocation. Censorship resistance and decentralization are a spectrum and their relationship with cost and proof time are expressed through the mechanism behind the matching protocol. 

Some popular techniques are:

1. Proof races: Allow all nodes to compete to satisfy every available proof request. It provides the highest redundancy and fastest proving time but increases the average cost per proof as hardware providers need to charge higher to recover the cost of races they participate in but lose out on. It also has a centralizing effect on the network.
   
2. Round-robin: Assign requests to hardware providers one after another serially. It provides randomization to prevent coordinated censorship attacks but is a naive strategy in terms of price or proving time optimality.
   
3. Auctions: Allow hardware providers to provide their best bids for price and proving time, preferably in a sealed way. It provides hardware providers with the most flexibility to offer point-in-time quotes based on demand and supply at a given moment. However, they add to matching time delays.
   
4. Orderbook: Perhaps the most transparent mechanism which provides the market with a fair view of how much different operators charge to provide proofs with what sort of timing guarantees. They also provide the flexibility to cancel existing and quote new orders, thus, replicating auctions. However, the benefit of fast matching through limit orders and lack of privacy probably negate their dual use as an auction mechanism practically speaking.

Kalypso takes a mechanism-agnostic approach to matching requests. It allows proof requests to be created on-chain and indexed by appropriate Markets, an abstraction that defines the applicable Matching Protocol. The Matching Protocol can be based on order books or auctions. The benefit of this approach is that order books allow for higher transparency and quick job assignment while sealed auctions can lead to better pricing. Tasks are then created on-chain by the Matching Engine and worked upon by the assigned hardware providers. Such separation between the frontend and backend is popular in other fields of computer science, for instance, compiler theory and allows Kalypso to be used for diverse use cases, whether rollups, games or payment apps.

The Kalypso Matching Engine runs inside an Oyster node. Oyster is a TEE-based coprocessing network by Marlin. Trusted Execution Environments or TEEs, in short, are protected systems in computers and servers where data and code are isolated from other processes usually at a hardware level. They enable verifiable computing by ensuring that programs that run in them are free from external interference and that no program or person can see encrypted data sent to them for processing.

Running the Matching Engine in Oyster provides certain unique advantages:

1. Low latency: Oyster coprocessors leverage TEEs to provide nearly server like performance which is required for high throughput matching engines.
   
   
2. Ease of development: It is very easy to deploy custom code in Oyster environments. This facilitates quick deployment of new matching protocols whether as an auction system or an order book based exchange.
   
   
3. Private inputs: Several zk apps rely on private inputs. Such data isn’t meant to be leaked to third parties. Allowing provers to optionally use TEEs (to secure such private data) and having a matching engine that can aid in the re-encryption process helps Kalypso cater to a larger variety of applications.
   
   
4. Resource optimization: A TEE-operated matching engine allows orders to be placed and canceled with low latency. This allows Kalypso to allow provers to be registered in multiple markets when available and auto-cancel orders from other markets when matched against a Task. This reduces fragmentation of compute power across Markets and increases the hardware utilization rate of hardware providers.
   
   
5. Granular preferences: Proof requesters have the ability to specify bounds on the maximum price they are willing to pay, the maximum time by which they want to have the proofs and also their preference between the two if multiple hardware providers meet the criteria.

Armed with this feature set, Kalypso relies on economic security put on stake by hardware operators to provide liveness and response time guarantees. Nonetheless, proof requesters can increase their redundancy requirements by placing additional proof requests.

Increasing capital efficiency through Symbiotic

While we have talked at length about increasing the hardware utilization rates, an important aspect of proof-of-stake systems is the cost of capital. Hardware providers are required to put economic value at stake to disincentivize them from acting maliciously. In the case of Kalypso that translates to not providing valid proofs within committed deadlines. Kalypso leverages the Symbiotic protocol to increase capital efficiency.

Kalypso’s contracts are currently deployed on Arbitrum Nova while Symbiotic plans to deploy their contracts on Ethereum initially. Kalypso thus pioneers a novel cross-chain restaking architecture with Symbiotic. Symbiotic follows an epoch-based model for deposits, withdrawals and slashing which will be replicated in Kalypso for stake coming from Symbiotic, just with a small offset to allow for communication delays. This allows Kalypso to bridge in staking information from Symbiotic as well as bridge back slashing information in a safe manner. In order to ensure there’s sufficient time to bridge data between Ethereum and Arbitrum, a vault epoch time of 7 days would be ideal. 

Symbiotic is very flexible in terms of tokens that can be staked and the possible slashing mechanisms. In addition to POND, Kalypso operators will be able to accept stake from ETH and wBTC-based vaults from Symbiotic. This can be used to increase the stake capacity of operators that allows them to take on high value jobs requiring a higher stake amount as well as more jobs in general. Kalypso’s native slashing mechanisms that guarantee prover liveness carry over to the vaults as well.

Symbiotic also features resolvers in the network who have veto powers over slashing. While response time-based slashing conditions in Kalypso are objective, vaults can use a veto committee to rule out slashing incidents that couldn’t have been avoided by operators. 

Next steps

We expect prover networks to play a pivotal role in the modular infrastructure stack. This first of its kind collaboration between Kalypso and Symbiotic is fundamental to keeping ZK apps and protocols fair, secure and available. More details on Kalypso’s architecture can be found in the docs. We invite hardware operators, ZK protocols and Symbiotic vault creators to reach out via any of several existing social channels to learn more. Instructions to create and join different markets accompanied with various tutorials are available here.

Follow our official social media channels to get the latest updates as and when they come out!

Follow our official social media channels to get the latest updates as and when they come out!

Twitter | Telegram Announcements | Telegram Chat | Discord | Website