TL;DR
Marlin enhances the processing power and expressivity of smart contracts using easily verifiable off-chain computing resources.
It features two products, Oyster and Kalypso, which use TEEs and ZK proofs respectively to ensure the correctness of computations.
Serverless capabilities allow developers to “fire-and-forget” code, relieving them of tedious DevOps. Autoscaling and fault tolerance are baked into the Marlin protocol.
The GPU-powered network allows developers to invoke programs, send inputs, and receive results using smart contract calls, making AI-powered DeFi apps and games practical.
Backends deployed on Oyster can expose HTTPS endpoints allowing low-latency orderbook exchanges, RPC gateways, or decentralized frontends to be deployed on them.
Introduction
A blockchain consists of a large number of nodes redundantly processing transactions to prevent malicious users from double spending their coins or executing invalid transactions. This tends to make blockchains slow and expensive. Even layer 2 scaling solutions like rollups are limited in their capabilities as they can not access blockchain history to compute credit scores, run large machine learning models to develop dynamic games, or achieve a latency low enough to deploy responsive order-book exchanges.
Coprocessors like Marlin allow large and complex algorithms to be computed over off-chain nodes with added access to Web 2 APIs and blockchain history. Instead of evaluating the same program over multiple machines, each program is executed on a single node, which speeds up execution, reduces cost, and increases parallelizability. The correctness of results in the absence of redundant computation of the original program is guaranteed using software structures known as Zero-Knowledge (ZK) proofs and Trusted Execution Environments (TEEs), where compact proofs and attestations of computation are verified on-chain much more quickly and cheaply.
What Is Marlin?
Marlin is a verifiable computing protocol. It consists of a decentralized network of nodes, which allow arbitrary programs to be executed in them. The programs can be written in Solidity, C++, Rust, and Go, or target any other WASM environment. They can be deployed on individual Marlin nodes like dockerized containers and invoked using smart contract calls.
The protocol ensures that the programs execute correctly despite running off-chain on nodes operated by untrusted third parties. The output of the programs can then be relayed back on-chain or made available through API endpoints. If a node becomes unavailable or if the workload suddenly increases, the protocol automatically creates new instances, providing users with a serverless interface.
Release history
Here is a brief overview of Marlin’s release history:
OpenWeaver was released in Q4 2019, which allowed low-latency global relay networks to be deployed amongst a cluster of nodes.
Marlin Cache was released in Q2 2020 to allow nodes to store and serve frequently accessed data.
In Q4 2020, OpenWeaver was deployed over a public network of over 800 nodes called the Marlin Relay.
Over Q2 2021, mev-bor, a Flashbots client for Polygon, was released to receive MEV bundles via the Marlin Relay.
Oyster added computational capabilities using TEEs to the network in Q2 2022.
Kalypso allows the generation of ZK proofs to be outsourced to the network and was announced in Q4 2023.
How Does Marlin Work?
As a decentralized compute network, Marlin’s architecture is optimized for three tasks:
(i) receiving computation requests
(ii) performing the computation
(iii) making the results of computation available
In the spirit of decentralization, anyone is free to join the network and perform these tasks. Based on the tasks, nodes are assigned different roles, namely,
Gateway nodes
Execution nodes
Monitoring nodes
Gateway nodes
Gateway nodes are responsible for receiving requests and forwarding them to the execution nodes. Requests to compute can be made by invoking HTTPS endpoints exposed by the gateway nodes. Alternatively, for smart contracts to be able to make requests, a relay contract is deployed on the blockchain. Gateways listen for events originating from the relay contract and then appoint execution nodes to process the request.
Gateways, thus, act as the defacto load balancer as they check which execution nodes are busy or idle before forwarding requests. Similarly, gateways also act as the conduit to pass back results. Based on the requirement of users making the request, gateways can make smart contract transactions to pass results back on-chain.
Serverless execution: In fact, the same properties allow gateway nodes to detect when execution nodes have a high rate of utilization or have become unavailable. They instruct new execution nodes to take over. As the gateways coordinate with the pool of execution nodes, developers aren’t required to pick and monitor individual execution nodes.
Execution nodes
Execution nodes include everyday laptops and servers but also specialized hardware like GPUs, ASICs, and FPGAs. They are entasked to run computations like matching algorithms for trading engines, which would be prohibitively expensive on-chain. Additionally, they can also infer using machine learning models or generate ZK proofs, which would be simply impossible on-chain.
The programs to be executed can be directly shared with the execution node by saving them in a transaction’s calldata or on IPFS and pointing the execution nodes to them by mentioning the transaction or IPFS hash in the request. As the programs can be written in any language, they can also include servers, which can operate on the execution node and serve user requests like a decentralized backend.
Monitoring nodes
Monitoring nodes check the service-level guarantees (SLAs) made by the gateways and execution nodes, including uptime and network reachability. In case a node doesn’t meet the expected guarantees, its stake can be slashed by the monitoring nodes. Thus, the monitoring nodes play a key role in keeping the network honest and high-performing by weeding out the dishonest and low-performing nodes.
Correctness guarantees
Considering that anyone can run these nodes, what happens if the execution nodes return incorrect results? A lot could go wrong if an oracle running on Oyster returned the wrong price of an asset or if a perpetuals exchange mistakenly liquidated a trader. Just as bad, a node operator could potentially snoop into private data like a proprietary machine learning model powering a credit scoring service.
In order to provide users with the comfort of secure execution, Marlin employs two technologies: TEEs and ZK proofs.
Trusted Execution Environments (TEEs)
A TEE or secure enclave is a protected system in a machine where data and code are isolated from other processes at a hardware level. Many cloud providers and server manufacturers provide such instances. Oyster execution nodes make use of TEEs to ensure programs run correctly as neither the operating system nor any other process running on it can access programs within a TEE.
Data sent to a TEE is often encrypted and decrypted only inside the TEE, preventing sensitive information from being leaked to node operators. An on-chain verifiable attestation can be obtained when computations are performed inside a TEE.
Zero-Knowledge (ZK) Proofs
A zero-knowledge proof is a cryptographic scheme that allows someone performing the computation to prove to someone else that the result is correct by sharing a proof. The cryptography behind the generation of proof makes it very easy to verify but almost impossible to fabricate unless the computation was indeed performed correctly. Computations outsourced to Kalypso execution nodes generate such a proof, which can then be verified on-chain.
The Kalypso ZK prover marketplace is an orderbook-based exchange that allows anyone to create a market for any ZK proving scheme. Since the generation of ZK proofs is time-consuming and expensive, the market connects resource-constrained devices with idle hardware providers to increase their revenue and resource utilization.
What Makes Marlin Unique?
Marlin is a network of off-chain coprocessors and not a blockchain. This offers a few key advantages:
Blockchain-agnostic: Marlin can work with any layer 1, layer 2, or rollup-as-a-service provider to augment their computational capabilities.
Off-chain data access: Marlin nodes can access information from databases, Web 2 APIs, or blockchain archival nodes, which isn’t possible on-chain.
Parallel computing: Coprocessor nodes on Marlin do not perform the same computations redundantly allowing each node to concurrently work on different tasks.
HTTPS endpoints: TLS connections can be terminated inside TEEs, allowing Oyster nodes to send/receive data using HTTPS connections.
Circuit-agnostic: Unlike dedicated ZK prover networks, Kalypso is designed to be permissionless, allowing proof generation for any circuit, zkVM, or proving system.
Unlike most blockchain systems where computing is transactional, programs deployed on Marlin can be left to run forever, provided an associated wallet keeps paying for it.
What Is the POND token?
The Marlin ecosystem relies on the POND token to derive its security guarantees. Nodes in the network are required to stake POND in order to join. They risk losing their stake in case of misbehavior. This ensures that different actors in the network adhere to protocol-defined rules.
Closing Thoughts
Oyster and Kalypso position Marlin as a reliable coprocessor for DApps built on any layer-1, layer-2, or roll-as-a-service provider. Its customizable nature ensures DApps have a choice of using TEEs, ZK proofs, or both to provide security for off-chain computations. Its flexibility provides a wide variety of deployment options, interaction modes, programming languages, and runtime environments. Ultimately, its openness allows anyone to join, provide computing power, and deploy engaging applications.