⚓Anchor Network

Some PoS security assumptions don’t hold up for interoperable networks such as SEDA. The design of SEDA ensures that we secure and trigger certain smart contract protocols across a diverse range of networks based on the data SEDA provides.

Consequently, if a malicious actor gains control over the SEDA Network—even momentarily—they could jeopardize the assets on the affected chains. In the case of an attack, Proof of Stake networks can fork off or roll back the chain to a pre-attack state, resulting in the attacker's profit of attack being lower than their cost of attack. Given the negligible likelihood of a destination network implementing SEDA rolling back its state due to an attack stemming from an exploit on SEDA, this solution should not be a consideration in the design of SEDA's network security.

To counteract these limitations, SEDA employs an “Anchor Network.” When issuing a data request, the issuer can optionally select an array of anchors to perform the data request in parallel to the SEDA Network. The outcome provided by the anchors acts as a backstop to SEDA Network's outcome. The destination network should not consume this outcome. Instead, the network can set a deviation threshold based on the type of data queried, which, if crossed, should result in a sensible action for the issuer's use case e.g., this outcome gets ignored, and it reissues data request. Running an anchor is permissionless; projects with large amounts of value at stake should query multiple anchors and potentially run their own.

Anchors add a layer of security to data requests by acting as a backstop mechanism. You could argue that anchor nodes can censor certain data requests by passing incorrect data, which will stall the data request. Data consumers can circumvent this by checking for anchor liveness and rotating between a set of anchors in a case where they suspect an anchor is actively censoring their requests.