A previous post elaborated on the various working groups contributing to the Marlin protocol. This post aims to share updates to the structure of the working groups and their priorities. It is hoped that posting on the forum as opposed to the blog will make it easier for contributors to follow major updates from other groups on a more regular basis.
Structure
The groups that are currently active include:
- Oyster (Oyster | Offchain services powered by TEEs)
- Kalypso (Kalypso | The ZK proof marketplace)
- Applications (test cases)
- Monitoring and visualizations (https://hub.marlin.org)
- Orchestrator (dedicated chain/rollup/L3 for Marlin)
- Commons (tooling, primarily around TEEs)
The Kalypso group spun out of the Applications group as details of the ZK prover marketplace became clearer. Similarly, as gas prices on Arbitrum seem unviable for Oyster and Kalypso in the long term, the priority for the erstwhile Clusters & Gateways groups (which were to be dissolved after the Marlin Relay merged with Oyster) has turned to figuring a cheap settlement and orchestration solution. It is called the Orchestration group.
Highlights
Notable updates from each group:
- Oyster
- On-chain attestations are live (repo)
- Access to networking is available (setup, TCP proxy, raw proxy)
- Additionally, TLS connections are possible (requires custom configs in addtion to caddy)
- Secure channels can be established using attestations (repo)
- Functions can now be deployed on Serverless (Executor, Gateway, Billing, Control Plane)
- Preliminary tests of SGX/TDX have been successful
- Kalypso
- Enclave image to deploy the matching engine on Oyster
- Templates for provers and verifiers
- Applications
- Reproducible builds works (relevant script)
- AI models have been benchmarked on Oyster against zkML libraries (sample image)
- Tested a MEV relay inside Oyster, but with a full node outside the TEE
- Gateways
- Added Prysm gateway
- Monitoring and visualizations
- New marlin.org homepage
- Launch of hub.marlin.org
- Specs for monitoring protocol for Oyster
- Orchestrator
- A TEE-based node that can log and route requests is already live
- Commons
- Tooling to develop applications on Oyster Serverless
- Helper tool to easily build enclave images
- SDK for apps to interact with Kalypso
Integrations that likely benefited from these features:
- Private AI on Verida - repo
- teeML for Hyle’s Vibe Check
- AI agents on Naptha, Autonolas
- Decentralized frontends with 3DNS, SpaceID and Bonfida
- Morpheus AI agents
- LLMs on Flock
- IPFS gateway
- eth.limo gateway
- Avail Wallet on Aleo
- Circuits/zk applications written in Noir, SP1
- Payments on zkBOB
Current priorities
Based on the information available at this moment, the current priorities of the different groups are mentioned below:
- Oyster
- Subscriptions for periodic requests - Q3
- Enabling multiple job environments - Q3
- Ability to update enclave while maintaining IP - Q3
- File caching for serverless execution - Q3
- Support for SGX/TDX in smart contracts in addition to Nitro - Q4
- Faster networking (Tuna image) - Q4
- Scaling TDX with H100s - Q4
- Sandboxing support - Q4
- Verification of certificate extensions for Nitro - Q4
- Bootstrapping Oyster verifier nodes - Q4
- Improve local debug process for enclaves - Q4
- Replicate enclave environment within docker - Q4
- Implementing the monitoring protocol - Q1 2025
- Support cross builds with enclave builder - Q1 2025
- Expand the options of compute tiers on Serverless - Q1 2025
- Implementing auto scaling - Q2 2025
- Design of APIs if TDX & Nitro are combined - Q2 2025
- Kalypso
- Design of staking contracts - Q3
- Symbiotic and possibly Mellow integration - Q3
- Implementation of monitoring protocol - Q4
- Update Kalypso to be mechanism agnostic in order to support auctions - Q4
- Refactoring Kalypso codebase - Q4
- All-in-one tooling to prepare enclaves given prover/IVS binaries/executables - Q4
- Add fault tolerance to the matching engine - Q1 2025
- Auto scaling the matching engine - Q1 2025
- Elegantly create submarkets when proof generation can be split - Q1 2025
- Coordination between multiple matching engines - Q2 2025
- Applications
- Implementing the Oyster bridge for Kalypso - Q3
- Implementing a credits system for Oyster - Q3
- Deploying Oyster contracts on Monad - Q4
- Shared instances for easy deployments of decentralized frontends - Q4
- Module to easily deploy NodeJS and Python apps - Q4
- Implement the current relay network as an app on Oyster - Q1 2025
- Monitoring and visualizations
- Improve the dashboards for Oyster & Kalypso - Q3/4
- Orchestrator
- Run reth inside Oyster - Q4
- Figure a secure way to bridge tokens - Q4
- Commons
- Enclave image to verify attestations - Q3
- Enabling TLS for enclave to enclave communication - Q3
- Basic storage design for Oyster - Q4
- TDX related tooling - Q4
- Integrate Oyster with terraform and other infra management tools - Q4
- Libraries for programatic deployment of instances/serverless - Q4
- Simplify setting up secret keys within enclaves - Q4
Some open problems for which no clear solution exists but worth exploring due to their significance:
- Open architectures for TEEs
- Using PUFs as a source of entropy
- Preventing DDoS on decentralized frontends
- Running a MEV relay inside Oyster with a full node inside the TEE (light client still requires a RPC which adds to latency)