Flux has rebranded to SEDA, learn more at seda.xyz!
By Mario Cao, Head of Research at SEDA Protocol
Blockchain oracles connect smart contracts to external data, allowing them to perform executions depending on real-world inputs and outputs. Despite the numerous iterations and protocols attempting to build that bridge between the on-chain and off-chain worlds, none of these solutions have been able to find the perfect tradeoff between data security, economic guarantees, and scalability.
“Imagine the ideal protocol. It would have the most trustworthy third party imaginable — a deity who is on everybody’s side. All the parties would send their inputs to God. God would reliably determine the results and return the outputs.” — “The God Protocols” by Nick Szabo
Szabo’s utopian “The God Protocols” article could be interpreted as the idea that the perfect oracle might not actually be possible. It makes sense if one thinks about the non-deterministic nature of data combined with the spurious interests of the involved parties within a decentralized distributed system.
However, at Flux Protocol, we are convinced that we are moving one step forward in the race for building a next-gen decentralized oracle with the Flux Endgame Protocol.
In this article, we will deep dive into the foundations of building this protocol. We will also cover the design decisions and main challenges.
Why is the Flux Endgame Protocol Necessary?
Before jumping into technicalities, we will review why oracles are crucial for blockchains, but most importantly, why the Flux Endgame Protocol will become an essential infrastructure component in the space.
Why decentralized oracles?
Blockchains without oracles are like computers without an internet connection. They are isolated from the outside world and can only access on-chain information. Oracles act as bridges toward the external world, but it is paramount that they are secure and reliable as they might directly determine the output of smart contracts.
To not defeat the purpose of using a blockchain network (hundreds or thousands of nodes running the same software), oracles should aim to be as decentralized as possible. Thus, avoiding single points of failure (e.g., nodes or data sources going offline or acting dishonestly).
However, an unbelievable amount of the most widely-used protocols — such as in DeFi, or NTFs — are not truly decentralized. They are still using permissioned infrastructure or trusted third parties. Some strong arguments are that they rely heavily on risk management and accountability, and some decentralized solutions cannot guarantee a sufficient quality of service (e.g., data accuracy and latency). In some cases, data providers can be seen as the custodians of the funds in the smart contracts.
Why the Flux Endgame Protocol?
Oracles are a critical but often overlooked component of many decentralized protocols. They are complex to build, and there is probably no silver bullet perfect for all use cases. Decentralization brings significant advantages to the table (transparency, security) along with some considerate drawbacks (speed, accountability).
At Flux, we believe we can build a protocol with all these advantages while overcoming (or reducing) most of its drawbacks. It has not been an easy journey. At Flux, we started building a fully decentralized oracle protocol, whose security was based on staking and a court system. However, we soon realized that the non-deterministic time-to-finality of the system was a critical impediment for many protocols consuming this data. After that experience, we implemented a First Party Oracle (FPO), where we sacrificed complete decentralization in pursuit of the highest quality of service (i.e., data quality and latency).
Now we leveraging our previous experience in the space to build a next-gen oracle infrastructure that will become the HTTP for Web3 technologies. The Flux Endgame decentralized protocol aims to be a secure yet performant oracle at the service of any other protocol on any chain.
Main design decisions: What should it look like?
As with any other blockchain oracle, the Flux Endgame protocol aims to guarantee the expected properties such as safety, liveness, and fault tolerance. Yet, we would like to focus on the design decisions that will make Flux different from other solutions.
Built-in multi-chain support
Native support for multiple chains was one of the top priorities while envisioning the oracle protocol. The architecture design has bridging mechanisms as part of the core protocol. The main goal is that protocols and smart contracts can interact with the Flux protocol seamlessly from other chains without having to know anything about Flux protocol specifics.
Economic guarantees based on PoS
Okay, this is not necessarily too different from other existing solutions, but security is one of our cornerstones, and we could not leave it out. Our security model is based on a Proof-of-Stake scheme, where node operators will stake part of their funds to perform some tasks (e.g., resolving data requests) and to contribute to the overall system security (e.g., validating a global state).
Fast-finality
The third problem decision is clearly about performance. Many protocols require an oracle service that is not only reliable but with almost no delay. Most of them are time-sensitive, and data requests lose value if they are not recent. At Flux, we will prioritize having a fast and deterministic time-to-finality of the data request execution on any chain.
Decentralized sustainable ecosystem
The Flux endgame protocol is a permissionless decentralized protocol. The idea is to foster a rich ecosystem in which different interested parties can easily coexist, i.e., developers and protocols, node operators, and data providers building a symbiotic community around the Flux oracle protocol. Additionally, the protocol will be governed by a DAO compromised by its community, i.e., anyone that holds $FLX tokens.
There are many more design decisions that we decided not to include in the previous list because we believed they should be part of any existing oracle solution. Some examples are data tamper resistance, sybil resistance, protocol upgradeability, censorship resistance, multi-source fact checking, etc.
What are the main challenges?
Building a decentralized protocol is a complicated problem, not only for the substantial amount of hidden complexities but also because all its pieces have to fit perfectly together. Here are the main identified challenges that need to be addressed before moving to the protocol implementation.
Architecture design
There are many moving pieces within a decentralized oracle protocol. The figure below shows a high-level abstraction of the system architecture. Each box requires consequent analysis and design before the implementation phase. Some challenging topics include: security analysis and potential attacks, core protocol dynamics, cost analysis, and data request execution latency.
Sub-chain bridging
Analyzing and designing how bridging would work in a multi-chain decentralized oracle is clearly the most critical challenge we faced.
As the Flux Endgame Protocol will support other chains for oracle services, forwarding states to different chains will be required. It means designing the interactions between parties with potentially different interests within a multi-chain context.
Tokenomics
The following piece of the puzzle is token economics, i.e., the economic dynamics that guarantee that interests are aligned and that the system is secure. It is a complex analysis in which the end goal is to maximize the overall system security by identifying the proper incentives for each participating party, i.e., node operators, data request executors, nodes acting as relayers, consumers, etc.
Where are we now?
During these past few months, we have been working on analyzing the previously described main challenges. In this analysis stage, we laid the foundations of the protocol by proposing technical solutions for all identified problems. We also started with a high-level architecture design while deep diving into those topics of special relevance. Some of the topics that have been covered so far:
- Consensus algorithm based on PoS
- Global state and its data structure (incl. commitments and proofs)
- Bridging between main-chain and sub-chains
- Data request execution based on WASM
- Data request committees using VRF sortition
- Data request lifecycle and commitment scheme
For the upcoming quarter, we aim to shift the focus to additional design tasks such as:
- Drafting a high-level technical paper (or litepaper)
- Continue with architecture design tasks such as defining contract interfaces and main data structures
- Start designing P2P overlay network (message schema, gossip protocol, serialization protocol, etc.)
- Specific Proofs-of-Concept (PoC) might be implemented to be used as reference or formal verification of research outcomes.
Please take the previous goals just as an informational note. Priorities and tasks can always be subject to change.
Closing Thoughts
As often happens with decentralized protocols, challenges and technical solutions tend to be quite complex. This often leads to solutions that lack some core characteristics that, we believe, should be present in any decentralized oracle.
At Flux, we are committed to building the next-gen oracle protocol. A fast and reliable protocol with the ambition of becoming an essential infrastructure to any blockchain protocol on any chain.
Stay tuned for future research and engineering updates!
About SEDA
SEDA is a multichain, permissionless protocol connecting real world data to any network on-chain.
SEDA is backed by world-class investors such as Distributed Global, Coinbase Ventures, Reciprocal Ventures, Coinfund, Maven 11, Flow Ventures, among others.
Join SEDA’s community:
Telegram: https://t.me/sedaprotocol
Discord: https://discord.com/invite/wsNwx2N75B
Twitter: https://twitter.com/sedaprotocol
