SEDA brings the much-needed and battle-tested consensus algorithms from some of the largest blockchain protocols to the oracle space. Protocols no longer need to simply trust intermediaries and their oracle solution to send them accurate data; their data can now be secured using the same Proof-of-Stake implementation as the networks they already build on.
While many of the same qualities exist in transaction-based consensus as they do in data provision-based consensus, PoS blockchain networks are able to fork or roll back the chain to a previous block if the network were attacked. However, if an oracle is attacked and the data is manipulated to drain value from the protocols using it, the network is very unlikely to roll back the blockchain.
SEDA is multi-chain native and leverages the robust security of a greater consensus layer to secure all value and information transmitted across chains.
The main chain is the blockchain network that is responsible for SEDA’s security, consensus, and proof generation. It is the hub where all value in the SEDA network is exchanged, and where all data requests are processed.
A subchain is any blockchain network that is connected to the SEDA network through bridging nodes and an on-chain contract. Protocols can leverage the security of the entire SEDA network without leaving their blockchain. They simply submit their data requests to the SEDA contract deployed to their chain, and the bridging nodes will relay the requests to the main chain and return the updated data.
In the unlikely event that data request resolvers collude to attempt to manipulate a data update, SEDA connects protocols to a network of anchor nodes to perform data requests parallel to the SEDA network. These anchor nodes act as a failsafe for protocols; in the event that the network is attacked and has a data update manipulated, protocols can automatically check the network’s update against the anchor node’s update, and build in measures to prevent any funds from being drained.
While anchor nodes are the most significant point of centralization within the network, the only way the network could be impacted from this potential attack vector would be if an anchor node delayed its data update. SEDA provides protocols with the ability to check anchor node liveness and rotate between a set of anchors in the event that one fails.