State Connector & Attestation Providers | Flare Network

Scroll to the bottom for the 8 minute video.

Connecting data between individual blockchain networks has been both limited in capability and lacking security. A reliable way to pass information between blockchains is vital to power applications such as bridges that allow use of wrapped tokens on other networks. It’s an important discussion because billions of dollars worth of crypto tokens rely on systems which pass data between blockchains and as we have seen, when lacking security guarantees we observe hacks like on Ronin, Wormhole and Poly amounting to almost $1.6b worth of compromised tokens.

With bridges aside, today’s blockchains are missing out on the power of interoperability due to the inability to access cross-chain data. Allowing the requesting and verification of various data sets from other blockchains, or even from off chain real world API’s, will bring brand new innovations to the blockchain space.

This is exactly what the State Connector from Flare Networks is offering, the means to request off-chain data but with new security guarantees, flexibility and accelerated speed.

The true beauty of the state connector comes from its “RCR” and “Branching” protocols.

RCR Protocol

It’s the RCR protocol which allows any network participant, human or smart contract, to request information about a connected blockchain or API to be proven. Now, the core purpose is to prove data existence or non existence which would make you assume we would only get a binary answer from the State Connector - but you’ll see shortly how we not only get an answer of whether our requested data exists off chain or not, but also the raw data being proven.

RCR stands for Request, Commit, Reveal, these are the three sequential phases of the protocol; and if you’re familiar with the FTSO system, it works similarly to data providers' commit and reveal scheme.

During the Request phase any user can submit a request to the State Connector to have some type of information proven from off-chain. The type of information that is available to request is limited to what has been integrated into the State Connector. So while the State Connector can request most types of data, it must first be meticulously built and assessed for any safety concerns before being an option. New types of data must be distinctly decidable which ensures every provider understands exactly how to process the request. New types of requestable data can be proposed through governance.

Next is the Commit phase where Attestation Providers process all requests from the previous phase and determine the off-chain existence of each request; this is called an attestation. Every attestation is hashed and builds, what is known as, a merkle tree which is an efficient way of storing data. But importantly, another hash is created from all the hashed attestations. This hash is known as the Merkle Root and is a representation of all the data in the merkle tree, if even one user request is missing or not properly processed by the attestation provider, this hash will be different. The significance of this fact will be seen shortly. But before the attestation provider's job is complete for the commit phase, they obfuscate this merkle tree root and submit this to the State Connector. Obfuscation means that no one can read what the submitted hash truly is, preventing any other attestation provider from watching others' submissions and copying them, thus avoiding doing any work.

Finally is the Reveal phase which is where attestation providers submit their unobfuscated merkle root to the State Connector and can be compared to their obfuscated hash to prove it was their submission. Each hash can be considered a vote, as we previously described, a merkle root will always be the same if created from the exact same data. Therefore, a majority consensus can be reached by counting the number of times the same hash is submitted and conclude the three RCR phases.

With a one hash now being found as being submitted by the majority of Attestation Providers, we can safely assume the data contained in the Merkle Tree to have been processed correctly and have accurate results.

The Merkle Tree can then be deconstructed with each attestation now being able to be read by the original user or smart contract that requested it - with the safety of it being verified by the majority of Attestation Providers. This means that every leaf of the Merkle Tree is an attestation with data inside of it specific to the type of attestation that was submitted and is verifiable as it is a part of the Merkle Tree.

Attestation Providers

Now you might be wondering, who and what are these Attestation Providers? Simply put, Attestation Providers are a piece of software that is run by a decentralised group of Flare Network participants. While anyone can run an Attestation Provider, not all will have a vote in the RCR protocol. This is where we define the “default set” of attestation providers who are assumed to be good acting participants. This set is composed of FTSO Data Provider operators who already have trust in the network due to the FTSO vote power mechanics and therefore can be trusted with voting privileges.

All Attestation Providers run their software 24/7 and manage their own blockchain nodes including their own Flare node. That is, they run a node for each blockchain that the State Connector connects to, enabling them to process attestations in the RCR protocol. This can become a costly operation which means they must be compensated for their work so all attestation providers in the default set earn a portion of Flare’s annual inflation.

So in the general sense, it’s not economical for everyone to operate as an Attestation Provider so you might ask why anyone would if they’re not a part of the compensated “default set”. The answer is that it’d be likely for entities that already operate blockchain nodes in their current business operations, such as centralised exchanges, to run their own Attestation Provider as part of their “local set” parallel to the “default set” but the incentive to do so is because of Flare’s “Branching Protocol”.

Branching Protocol

The Branching Protocol is a safety mechanism built into Flare nodes to prevent incorrect information from being ingested by applications utilising the State Connector. There is always a “default branch” which is Flare’s state; based on the majority of Attestation Providers opinions. Now, with the assumption an Attestation Provider is attesting honestly, they will always be correct in their view. So if a provider disagrees with what the majority are submitting on the default branch, it will discard the attestations for that RCR round and come to a stop giving an indicator to the provider that either the default set is faulty or they have made a mistake. At the moment it stops, the node forks into a new branch away from the default branch.

In this instance, anyone using the halted providers node will not be able to retrieve attestations for the latest or future rounds until the halt is rectified; therefore in the providers view, protecting applications from using potentially incorrect data. This would, for example, stop an asset being released to a user through a bridge because the users deposit of the asset to be bridged would not be able to be verified of its existence. No deposit, no wrapped asset for the user.

There are two outcomes when a providers node halts:

They recognise they made a mistake or something went wrong with their own Attestation Provider and simply switch back to the default branch and catch up on any data missing while it was halted.

The other scenario is they in fact did not make a mistake and were correct against the majority of providers. This is a rare possibility if more than 50% of providers were wrong. In this case, if other providers recognize they made a mistake following the main branch they can move backward to the last known correct branch and continue from there.

The important distinction here is that as long as an application or user utilises a node with an Attestation Provider they undoubtedly trust, such as their own, they will never be wrong and always have the correct state of the network.

You now have a high level understanding of the State Connector; the tool which is at the core of Flare’s F-Asset & LayerCake protocols; the two native use cases of this amazing system. ..And it won’t stop there with all applications having access to this immensely powerful system, we’re going to see some truly amazing innovations come to the Flare.