Flare’s State Connector is the first consensus protocol purpose built for external blockchain data. It securely and trustlessly proves the state of other blockchains onto Flare. The State Connector enables Flare to power:
- Better bridging, including fast, decentralized, multilateral and insured bridging between smart contract chains.
- Cross-chain composability, with data and assets able to flow freely and securely between all chains.
- Secure, fully interoperable multi-chain solution.
The below is an introductory summary of the State Connector. Full detail is available within our Technical Documentation pages.
Introduction to the State Connector
The State Connector allows Flare to come to consensus on the state of any blockchain, and for those proofs to be used in smart contracts or relayed to another chain in a trustless, decentralized manner. It’s faster and safer than existing approaches, and has been designed to integrate with any other blockchain.
Other solutions either require trust in centralized third parties, or they force other chains to conform to their standards — in effect changing the independent chain’s protocol and code so they can communicate. By contrast, the State Connector can directly validate state correctness and withstand safety and liveness attacks on connected chains, without requiring a centralized third party or a code change on the underlying chain.
Better bridges
The State Connector is a new and foundational technology that makes it possible to build better bridges between chains:
- Decentralized bridging of non-smart contract chains onto Flare – FAssets.
- Fast, decentralized, insured and multilateral bridging between smart contract chains, including bridging of FAssets onto other chains – Layer Cake.
Cross-chain composability
Developers can use the State Connector to build truly interoperable dapps that can access the value, liquidity and information of multiple blockchains through a single deployment on Flare.
It is able to securely prove the state of other blockchains in a decentralized manner, and provide that data to dapps on Flare. For example, the State Connector can prove whether a specific lock, mint, burn or redeem action has happened on the Solana or Ethereum network and trustlessly provide that information to a smart contract on Flare in order to automatically initiate a pre-defined action.
It’s faster and safer than existing approaches, such as light client relays, optimistic relay, and multi-sig schemes, and has been designed to integrate with any other blockchain.
Further, the State Connector enables a model of staked relay of data between multiple chains, including Flare, which powers secure two-way interoperability across a network of chains. Instead of relying on governance, relay secured by the State Connector will have automated slashing of faulty relay nodes through the State Connector’s ability to prove what any node has relayed to another chain.
Security
The State Connector is more secure than previous interoperability mechanisms because it is able to fully query the validity of a transaction, including its history. Other approaches like the Simplified Payment Verification proofs used by Light Client Relays are unable to do this, and so the “proof” has no detailed history to support its validity. This also means the State Connector is able to mitigate the risk of reorg attacks on connected chains — enabling cross-chain interoperability with the security of a multi-chain network.
Decentralized consensus
When an application on Flare requests a proof of a blockchain transaction, the State Connector sends this request to a decentralized group of Attestation Providers (APs). It is the APs that allow the State Connector to come to decentralized consensus on external data.
Anyone may operate as an AP without any capital requirement. The security assumption is that if an independent Attestation Provider is correctly attesting the requested state, then they will always end up on the correct branch of the Flare state. A detailed explanation of how this process works is available in our recent Layer Cake white paper and on the Flare Technical Documentation pages.
Process Overview
Anybody can request an attestation of a specific external event from the State Connector contract running on the Flare Network. Requests are yes/no questions regarding things that happened outside the Flare Network, for example, “Has transaction 0xABC been confirmed on the Bitcoin network?”. Available request types are strictly binary and objective by design so there can be no contention between honest operators.
The State Connector signals all Attestation Providers about a request. This is done through very gas-efficient EVM events.
Attestation Providers fetch the requested data by means that depend on the type of attestation, for example retrieving data from another blockchain.
Attestation Providers submit their results to the State Connector in a Commit and Reveal fashion to prevent collusion. For performance reasons, all requests collected during a 90s round are answered at once, using a cryptographic hash (Merkle tree root) to summarize them all.
The State Connector runs consensus on the replies and if more than 50% of the providers agree, the answers are made public to applications on Flare. If agreement is not reached, requests remain unanswered and must be issued again. This should not happen if the majority of APs are honestly and objectively relaying the requested state.
Attestation Providers are rewarded with the native token for their honest participation in the process.
