SEDA is a decentralized modular data layer designed to bring data from the real world onto the blockchain. It is a multichain, permissionless protocol that connects any on-chain network to real-world data. This enables the integration and use of external events and data in smart contracts which vastly expands the potential design space.

Overview

Blockchains have traditionally been isolated networks, essentially a computer with no internet connection. They can access and act upon any data available on-chain but, similar to a computer with no internet connection, they are disconnected from off-chain data. Furthermore, this isolation prevents blockchain networks from unlocking their full potential as access to off-chain data massively expands the design space. The inability of blockchains to access external data is called ‘the oracle problem’, and is solved with a piece of infrastructure called an oracle.

Modular Design

As the modular blockchain design space has gained traction, there has been a proliferation of L1s and L2s that all need to be connected to one another in order to function smoothly. However, for an oracle or bridge to integrate with a new chain, it can take 9 months until the integration reaches full functionality. Smart contracts need to be built and deployed, monitoring needs to be implemented, all the different data infrastructure providers need to be plugged into – there is an inordinate amount of additional work that needs to be done.

Instead of repeatedly building all the data layer infrastructure, what if there was a central data hub that all chains could plug into? This is where the SEDA network comes into play.

The SEDA network can be thought of as a plug-in data layer. They built an open source prover contract that any network can deploy, the network then pings the prover and the data request is routed to the SEDA network. Additionally, now that they have launched mainnet, there are 230+ networks that SEDA is actively looking to integrate with.

SEDA goes far beyond today's definition of an oracle, it’s a data transmission and computation network enabling a permissionless environment for developers to deploy data feeds. The fully modular interface allows developers to dictate which data feeds to fetch and how this data should be used for computation. Moreover, they have used game theory, cryptography, and strong backstops to ensure security guarantees consistent with leading L1 networks.

Protocol Mechanics

The everything oracle – SEDA’s design allows it to collect and deliver any data from any source to any chain.

The SEDA network consists of:

1. The SEDA Chain: used for settlement, and data storage for distribution.

2. The Overlay Network: a Multi-Party Computation (MPC) network that does the data querying and computation.

3. Solvers: the entities forwarding new data requests to the SEDA chain and forwarding results to destination networks.

4. Data Providers: the (private) data providers plugged into the SEDA network.

The diagram below is a high level overview of how data requests are posted and filled, let’s walk through a stylized example. The data request flows from right to left (destination network → data source), and the data then flows left to right (data source → destination network).

Let’s say Compound (destination network) needs the price of ETH/USD. Compound sends a transaction to a prover contract that's deployed on the L1. The prover passes the query onto a solver in the SEDA network. The solver is willing to solve the data request for some fee, the request is then passed to the SEDA chain (which acts as the central hub for informational flow). The SEDA chain passes the request onto the Overlay network which consists of 1000s of lightweight nodes. The overlay nodes are tasked with querying data provider feeds (price feeds, RPC feeds, RWA feeds, eSports data, etc.) This data is then permissionlessly published to the SEDA chain and makes its way back to the destination network.

Relay

The diagram below outlines the data exchange process between a consumer (i.e., a smart contract) and a solver.

Any network can plug into SEDA, read and then verify the data. As mentioned earlier, all they have to do is deploy SEDA’s open source relay contract (the relay contract is the same as the prover contract mentioned above).

Request – the destination network requires some external data, it details these specifics through the relay contract, a solver then picks the request up. The solver is the party responsible for fetching the required data from the external sources.

Response – the solver fetches the data batch from the SEDA chain and sends it back to the relay contract which uses the requestid to fetch the appropriate data from the solvers batch. The data is then accessible to the consumer contract.

The general flow can be understood as follows: The consumer contract provides gas fees for computation and pings the relay contract with a reference of which program it wants to run. This is then picked up by a solver, the solver then processes the request and fetches the data. The relay contract collects the appropriate data (as per the program that was requested) and returns it to the consumer contract.

SEDA Chain

The SEDA chain is an application specific blockchain built using the cosmos SDK. It functions as the settlement and checkpointing layer, this is where the slashing and staking happens. As a destination network, I can deploy a program on the SEDA chain that specifies instructions on how data should be queried, where it should be queried from, and how it should be computed – this program is then stored on the SEDA chain. If the destination network would like this data queried, it pings the SEDA chain referencing the contract ID of the program. Because SEDA is a permissionless protocol, once a program has been written to the SEDA chain, any destination network can ping it and request data.

Once a contract has been pinged, the SEDA chain then picks the nodes on the overlay network to perform the requested computation. The result is written to the SEDA chain where it is batched, with any other requests that arrive in the same block, the batch is collected in a merkle tree and the root is signed.

The SEDA chain provides a reliable single point of truth for all operations across the connected networks. This is a critical role in an environment where multiple sources and types of data must be both synthesized and verified before being utilized in blockchain operations. For all intents and purposes, the SEDA chain is the central hub of the SEDA network.

Overlay Network

The Overlay Network is designed to handle the execution of data request programs and manage the data verification through Multi-party Computation. The MPC network consists of thousands of lightweight nodes executing data requests independently of the main chain (SEDA Chain) - this ensures the SEDA chain is not overloaded.

Data request handling: The network receives data requests which are processed by nodes within the Overlay network. Each request is accompanied by a Verifiable Random Function (VRF), the overlay nodes use the VRF to generate a random number which determines eligibility to participate in data processing – this ensures randomness and fairness. Once selected, a node is responsible for fetching, computing, and verifying the data. In order to prevent collusion, the nodes selected don’t know which other nodes have been selected. After processing the data, the nodes submit the results through a commit-reveal scheme, this ensures all data remains confidential until all computations are both verified and agreed upon.

The program deployed to the SEDA chain can select the replication factor – this outlines how many of the overlay nodes they would like to have run their data feed. This allows the program to cater to specific data security needs based on the use case of the data, the general idea is that the set of overlay nodes requested increases with the security implications of the data.

Anchor Network

Given the importance of SEDAs data layer in the operation of all protocols that use it, it’s imperative that this data is trustworthy. Should an attacker gain control of the SEDA network, they could alter the blockchains state to their advantage. The use of Anchor Network aims to mitigate this risk.

The Anchor Network acts as an additional layer of safety by allowing multiple, independent verifications of the data processed by the SEDA network. When issuing a data request, the issuer can select anchors to perform the data request in parallel with the SEDA network, thus the results can be checked against each other – this acts as a parallel validation mechanism.

The destination network sets a deviation threshold, this specifies a maximum deviation between the data returned by the SEDA network vs the Anchor network. If the deviation exceeds the stated threshold, the data is then ignored and the data request is reissued.

Concluding thoughts

In summary, SEDA has reimagined a key piece of infrastructure. Their modular data layer is a key unlock, it lowers both the time and effort required for new chains to connect to the modular economy.