Skip to content

State Connector#

The State Connector on Flare enables proving real-world events to any contract on Flare. Uniquely, the State Connector can also handle any notional value represented by the events it proves. This property of the system is achieved by automated branching of the Flare Network state to correct event outcomes, without degrading the time-to-finality or throughput metrics of the network.

Voting Protocol#

There are three phases of the State Connector voting protocol, delineated based on the current timestamp on Flare, and overlapping such that multiple sets of requests for event proofs can be worked on in parallel.

The three phases of the State Connector voting protocol

The three phases of the State Connector voting protocol.

Request Phase#

At any point in time, any user can submit a request to the State Connector contract to have an event proven. The window in time that this request enters the network state is known as the request phase from its perspective.

Commit Phase#

During the next window of time, attestation providers have the opportunity to commit a hidden vote regarding their belief in the outcome of the events requested in the previous phase. Anyone may operate as an attestation provider without any capital requirement, but a default incentivized set is used as the minimal requirement for passing a vote about the events in the previous set.

Reveal Phase#

Finally in the next window of time, attestation providers reveal their votes that they committed to in the previous round. Once this reveal phase concludes and the next phase begins, the revealed votes are automatically counted and all valid events become immediately available to all contracts on Flare.

Branching Protocol#

The State Connector branching protocol protects Flare against incorrect interpretation of real-world events, proactively, such that there are never any rollbacks on the Flare blockchain state. Instead of having rollbacks, contention on state correctness is handled via automatic state branching into a correct and incorrect path. The security assumption is that if you as an independent node operator are following along with the correct real-world state, then you will always end up on the correct branch of the blockchain state.

The State Connector branching protocol.

The State Connector branching protocol.

Default Attestation Providers#

The minimum requirement to confirm the existence and validity of a blockchain transaction is for it to be confirmed by a majority of the default set of Attestation Providers.

Local Attestation Providers#

Anyone may also operate their own local attestation provider(s) without any capital requirement. Every Flare node operator, no matter how prominently they feature in the overall network, defines which local attestation provider(s) they wish to use for the State Connector branching protocol.

A Flare node will only pass a State Connector vote if both the default set and their locally-defined set of attestation providers pass the vote:

  • If a Flare node's locally-defined set of attestation providers disagrees with the vote made by the default set, then:
  • The Flare node will automatically create a backup of the blockchain state at the last point that it will have in common with the default set.
  • The Flare node will then proceed along the branch that it locally believes is correct.
  • Else if the default set fails to pass a vote, then:
  • No branching occurs.

Scalability#

Below are examples of design considerations in the State Connector that make it highly scalable.

Overlapped Voting Protocol#

Overlapped voting protocol.

Overlapped voting protocol.

Every window of time during the State Connector voting protocol is an opportunity to request event proofs, meaning that while a new event is being requested, prior events can be voted on in both the commit and reveal phase. This multiplies the throughput of the state connector by a factor of three.

No Storage of Requests#

When requests for new events are submitted to the State Connector contract, storage is not invoked. Instead, a Solidity event is emitted. This enables the total cost of the event request transaction to be below 2k gas, i.e. less than 0.1x the cost of a simple payment.

Merkle-Tree Root Voting#

The gas usage of attestation providers is always constant, despite the number of event proof requests they handle, because they construct the valid events into a merkle tree and simply vote on the merkle tree root hash. The merkle tree algorithm can also be swapped out over time to more efficient algorithms without impacting the core State Connector voting protocol which always just votes on the root hash.

New Event-Type Integrations#

New real-world event-type integrations are introduced to the State Connector via acceptance by the default attestation providers, and without requiring any changes to the core voting or branching protocols described above. This enables rapid deployment of new use-cases without any validator-level code changes.


Last update: 2022-06-29
Back to top