What Beacons are and why they matter to Web3: Without source transparency is an Oracle decentralized?

What Beacons are and why they matter to Web3: Without source transparency is an Oracle decentralized?

Background of Oracles within Web3

In what is a relatively new category within cryptocurrency and the surrounding Web3 ecosystem, an Oracle’s role is to enable blockchain-based applications to be able to communicate with off-chain, real-world systems and access data.

It is argued that data being fed into the blockchain requires aggregation of multiple APIs to obtain an aggregate value, which removes data input as a point of failure in an autonomous financial system based on smart contracts.

As per the API3?whitepaper?and as outlined in the medium post “The API Connectivity Problem”: it is evident the race to solving the ‘oracle problem’ has introduced third-party infrastructure operated by middlemen, whilst sacrificing some of the broader fundamentals of blockchain.

More essentially: the oracle problem is?ill-posed?— its name suggests an impossible solution. An analogy would be to approach the problem of getting from Point A to Point B as the “teleportation problem”. Further, ideal architectures for solving the oracle problem drastically change depending on the data type at hand (e.g. objective vs subjective information). Such a problem inevitably leads to impractical and/or sub-optimal solutions.

It is a largely adopted belief that aggregating multiple feeds reduces the risk of a single API sending incorrect data to the blockchain. However blindly following this logic has created negative implications across the broader smart-contract ecosystem.

These trades-offs within the current oracle category have potentially:

1. introduced additional intermediaries (or middlemen) to the data supply-chain in the form a middle node layer
2. incentivised oracle nodes to use untrustworthy or anonymous sources when serving data
3. removed transparency and introduced centralized operating entities

Additionally operating & maintaining a validator node is a sizeable investment that also requires system administration skills. Without there being a clear reason to make that investment it is difficult for a Web2 API owner to service Web3 dApps, thus creating a barrier to entry.

With the explosion of DeFi in 2020 it is clear that real-world data enables innovation within smart-contract based applications, yet outside of DeFi there are few incentives to deploy APIs onto Web3 if node set up is a prerequisite.

The architecture matters:?first-party

The development of the serverless Airnode middleware has pioneered the?first-party?oracle architecture. In essence, with the node being deployed in the cloud architecture this brings the reputation of the API provider on-chain with it, with data served onto the immutable blockchain ledger.

Thus this shift in oracle architecture means first-party delivers on the promise of transparency within a decentralized ecosystem. In application this means that the dApp calls the source of the data, not a middle node layer, thus also representing the removal of an intermediary.

Individual first-party oracles will fare better in the case of data source problems, while third-party solutions obscure weaknesses until a catastrophic failure.

It’s fair to say that these trade off factors have been little discussed so far. Yet this is simply due to the lack of alternatives for what is fairly complex infrastructure. That said, first-party feeds known as Beacons are the first iteration of a next generation Oracle solution that more importantly offers an alternate with alternate attributes.

So, what exactly are Beacons?

Within the price reference API market there are a handful of highly reputable data providers that currently serve the majority of data on-chain. These organizations have legacy in data provision to not only crypto but also traditional financial markets and operate to existing web2 regulatory standards, with established processes and long standing reputations.

In a nutshell, Beacons are going to deliver a continuous signal to smart contracts that is recorded within the blockchain. It is a single-source data feed being brought on-chain via the first party architecture outlined above. As such the reputation of the source is also reflected within the immutable characteristics of DLT.

Additionally, Beacons are autonomous in regards to the updating of price feeds on-chain. These deviation thresholds can be optimised as per dApps requirements. Setting deviation at 0.5% means if ETH/USD moves down 0.5% a script will trigger a Beacon to update the on-chain feed. Where there are large capital exposures, perhaps within stablecoins, there is a great potential for efficiencies to be realised when deviation thresholds are dynamic.

A single source feed brings a new range of use cases to Web3. Take a think about Legal Data being brought on-chain. Or for example, if you know that the price of a stablecoin is being fed by a bank do you trust that reference data?

Whilst API3’s roadmap outlines the introduction of dAPIs that will see the aggregation of Beacon-derived feeds. Due to the transparency derived from first-party oracles, developers will have more confidence that their data is aggregated from independent, high-quality sources. Thus fewer feeds will be required to reach the pre-existing security of incumbent oracles.

Additional security benefits come from the removal of the middle-node layer, thus eliminating the Sylbil-vulnerable third-party node layer, furthering reducing fees by cutting out the “middleman tax” paid to these node operators for their services.

In summary

The first-party nature of Beacons re-introduce the transparency that is crucial to the attributes of a decentralized ecosystem, whilst adding benefits to security & scaleability.

API3 is excited to see Beacons at the upcoming ETHDenver on the Ethereum & Polygon testnets. These testnet deployments represent the launch of first-party oracles to Web3 — something I think will be looked back on as a defining moment for innovation within smart-contract based applications.