Building With Symbiotic: Oracles

In this article, we’ll dive into how Symbiotic can be integrated into oracle networks. We will begin with an abstract representation of what such a protocol might look like, and identify specific areas where Symbiotic infrastructure may be required. It is important to note that although we attempt to cover a wide range of possibilities with an abstract example, this serves merely as an illustration of what such a network might look like, rather than a direct implementation guide.

What is an Oracle Network?

An oracle network is a collection of participants (or nodes/operators) that deliver a set of off-chain data to a target network. This data can include the price of a specific asset, the answer to a given question, or virtually any type of information. One could envision a protocol where each participant submits their version of the data separately, but this approach is associated with certain challenges and limitations for both the protocol and its participants.

Data Verification and Aggregation

Depending on the type of data being submitted by the oracles, various methods of verification and aggregation are typically implemented. For price oracles, aggregation might be based on the average or median price value, and certain requirements may be imposed regarding deviation from the mean in the submitted data, among many other methods. For data with a known and finite set of responses, algorithms for validating and aggregating data can also be devised. For instance, if the response is either 0 or 1, aggregation could be based on the most frequently occurring answer. Generally, the task of verification and aggregation for each specific problem is addressed individually.

Let us introduce a system of price oracles where any participant can submit their version of the price. Assume that time in this system is divided into epochs, and the price within an epoch is aggregated within the smart contract of the target network simply as the average of the submitted prices. This system faces two significant issues: liveness and safety. If the number of participants is not limited, and no requirements are imposed on them, a malicious actor could create a sufficiently large number of nodes and submit their version of the price, causing the average value to be close to the price desired by the attacker. As noted, sometimes the system includes checks for the maximum difference between submitted data; in such cases, a malicious actor could submit a wide range of data, causing the system to not provide any price at all. If no such checks are in place, the attacker could effectively achieve any desired average price by leveraging a large number of nodes.

Challenges in Oracle Networks

For this reason, it is not advisable to allow just anyone to submit data into the system. This issue can be addressed by limiting the number of network participants. Many protocols simply use a whitelist; however, their number can also be restricted by requiring a certain stake of operators.

Symbiotic's Vault System

Symbiotic, on its part, offers a flexible vault system with which the network can interact to determine the stakes of operators. In the illustration, the section related to Symbiotic contracts is depicted in green.

An important question is where the information about these stakes is stored. We will consider a situation where the network’s stake is held (in Symbiotic’s case, it is on Ethereum) and the target network for reports do not necessarily coincide (in cases where they do coincide, accounting for stake is not a complex task). Globally, there are two options for stake accounting:

1. Accounting for stake during the acceptance of a report.

2. Accounting for stake during the formation of a report.

Let’s explore each of these options:

Method 1: Accounting During Report Acceptance

The first variant is to account for the stakes of operators in the target network.

Based on these stakes, a decision can be made to accept or reject a report. In some implementations (if data aggregation occurs in the target network), part of the data from the report may not be used if the operator providing the report does not have sufficient stake. Additionally, information about the operators themselves may be transmitted along with the report, which also depends on the protocol.

The issue of transmitting information about stakes to the target network is the most crucial in this solution variant. Depending on the implementation, this could involve either a trusted party or a highly secured bridge. It is also possible not to verify this explicitly, but instead use fraud proofs in the future to check that an operator submitted a report without actually having the right to do so.

Let's look at this problem from the perspective of the Ethereum network. Operators opt in to vaults and the network via OptInService contracts. In some cases, the network must additionally register operators within its middleware. This middleware also provides information about the current operator set stakes.

Method 2: Accounting During Report Formation

The second variant is to account for the current operators stake during the formation of the report. This will likely require some consensus mechanism among operators. During the process of receiving reports, operators share information and also examine the stakes of other operators (for example, using a light client). The target network receives either a set of operator responses or the final result along with an aggregated signature.

Slashing Mechanisms

In certain systems, the issue of liveness is not the only concern, but also safety. In such protocols, a slashing mechanism for operators may be utilized. Slashing, once again, can be implemented in several ways: fraud proofs, a solution with a trusted third-party, or using a consensus algorithm, depending on the protocol.

The main challenge here is defining the slashing rules. For arbitrary data types, it is quite difficult to slash for incorrect reporting because it is almost impossible to prove on-chain that the report was incorrect. However, for certain types of reports, this can still be done. For instance, if the report pertains to a certain state in another network, a fraud proof system can be established, which will slash the operator either during the report generation or afterwards. Additionally, slashing rules can be introduced at the consensus level (for incorrect data, if feasible, or for operator activity without sufficient stake, etc.)

Key Points for Implementation

In this post, we covered a high level oracle implementation using Symbiotic that follows several key points:

1. The implementation of a decentralized oracle system may require staking. It is important to decide whether the system addresses only the problem of liveness or also the problem of safety, as this can influence whether slashing is necessary or not.

2. To integrate Symbiotic into your protocol, it is necessary to create middleware that includes a component responsible for selecting and scheduling validators (validator set). This will allow operator teams to understand when they can operate within the network and under what conditions. Additionally, it is important to consider how operators will access this information, whether through transmission to another network or by creating a light client, etc.

3. In certain situations, slashing may be required. In such cases, a set of contracts must be developed to validate information about operators' performance and correctness within the Ethereum network for subsequent slashing (if slashing is indeed part of the protocol). This requires formulating slashing rules and secure methods for transmitting information to the Ethereum network. It is also essential to determine who exactly initiates the slashing and to specify this in the contracts.

As we continue to explore and expand the capabilities of Symbiotic, we invite the community to get involved. Whether you're a network builder, an operator, or simply an enthusiast interested in the future of shared security, there's a place for you. If you are interested in learning more or collaborating with Symbiotic, reach out to us here.