State Connector System
Proving the state of any underlying chain for all smart contracts on Flare.
Flare Network is purpose-built for safely interpreting the state of all underlying chains. The state connector system built into the Flare validator codebase ascertains the existence, validity and ordering of any transaction from any underlying blockchain. The ability to prove these properties about any transaction from any chain is available to all apps on Flare, including the F-asset protocol for representing assets from other networks directly onto Flare.
The state connector is a 'natively verified' state relay approach, meaning that Flare's own validators verify the state of other chains. Typically, native verification is performed by running a light client (i.e. SPV proof) of one chain in the VM of another chain. However, the state connector differs here by enabling each Flare validator to connect to their own full client of another chain that they may run themself, to verify anything about the state of that chain. This results in better security in interpreting the underlying chain, and increased utility beyond simple payments.

Simple Payment Verification (SPV) Proofs Considered Harmful

Recommended reading: "Simplified Payment Verification (SPV): A Primer" by tBTC https://docs.keep.network/tbtc/#spv
A simple payment verification (SPV) proof is a way to prove to a blockchain that a payment has occurred on another blockchain. The proof typically consists of a header that contains a consensus proof such as a proof-of-work, or a signed k-of-n multisignature from a set of validators that are currently believed to be in control of the underlying chain being presently considered. The SPV proof itself then just contains a merkle-tree based set of hashes that proves that a provided payment forms the pre-image to a hash that is contained within the provided merkle tree.
"The SPV security model is strictly weaker than the Nakamoto Consensus model" - from 'SPV: A Primer'
One of the main advantages of a blockchain is that we do not depend on its validators for anything other than being tie-breakers in sequencing transactions. That is, validators on a blockchain cannot insert erroneous transactions into the network that do not conform to the state transition rules that everyone agrees to run. For example, as a miner on a blockchain, one cannot compel the movement of a single coin that does not belong to them, the only way to do so is to sign a valid transaction that can be traced all the way back to the network genesis state as having a valid transfer of ownership history.
However, an SPV proof breaks this separation of powers guarantee -- it permits validators to now submit an isolated merkle tree proof that is self-referential and cannot be tied back to the genesis of the network. For example, if validators collude to manufacture a false SPV proof, they could convince a separate blockchain that a transaction sending them a billion units of an asset has occurred, when they had in fact never owned such an amount.
SPV proofs are also complicated for non-proof-of-work chains by having to keep track of changing validator sets on an underlying chain over time. Consider the scenario where an outgoing set of validators from an underlying chain refuses to sign a proof to Flare that they are now leaving power -- what penalty do they have for refusing to do this? Trying to manage validator sets in this way relies on the enforcement of bad behavior to be conducted by the same set of operators that have performed the bad behavior.
We cannot know whether staker signatures represent the current validator set without complete history. - from 'SPV: A Primer'
SPV proofs are therefore considered harmful for the purpose of proving the state of an underlying chain to another network. The approach escalates the privilege of underlying chain validators to be able to falsify the ownership of an asset, and the enforcement of bad behavior in the approach must be conducted by the same set of operators that have performed the bad behavior.

The State Connector Security Model is Stronger than SPV

The state connector system is a competitive approach for proving the state of an underlying chain to a smart contract, and it has the following advantages:
    1.
    Transaction validity references back to an underlying chain's genesis block: Other approaches like the SPV proof do not check the validity of a transaction.
    2.
    Safety only depends on an underlying chain's validators: There is no trusted third-party service that has its own set of economic incentives and risks. Trust is minimized by leveraging the guarantee that safety can only be lost in the state connector if an underlying chain's validators encounter a Byzantine fault.
    3.
    No cooperation needed from an underlying chain's validators: Validators from an underlying chain do not need to modify their chain's code base to permit Flare to interpret their network. An underlying chain's validators do not even need to be aware that Flare exists in order for the state connector system to operate.
    4.
    Can read the state of any blockchain: The state connector can operate on any possible Sybil-resistance technique of an underlying chain. For example: proof-of-work, proof-of-stake and even federated byzantine agreement where there is not global agreement on the set of validators in control of a network.
    5.
    No encoding of the current validators in control of an underlying chain to a smart contract on Flare: This requirement of other state-relay approaches such as the SPV proof leads to the hazardous scenario where the enforcement of bad behavior in relaying state needs to be conducted by the same set of operators that have performed the bad behavior.
    6.
    Constant-sized proofs: both the data availability proof and the payment proof are constant-sized, independent of the number of other payments in the data availability period being considered.
    7.
    Every Flare validator independently verifies an underlying chain's state: If your own Flare validator observes the canonical state of an underlying chain, then you will not lose safety against that chain.

State Connector Design

The high-level premise for how the state connector system operates is best motivated by its threat-model: in order to absorb incorrect state into a Flare Network app from an underlying chain, an attacker would need to compromise:
    1.
    Your own Flare validator's view of the underlying chain
    2.
    A majority of other Flare validators' views of the underlying chain
    3.
    A sustained attack that lasts longer than the number of underlying-chain block confirmations independently required by your app on Flare
This threat model is achieved by requiring each Flare Network validator, no matter how prominently they feature in consensus, to independently observe the ongoing state of all integrated underlying chains. Propositions about the state of an underlying chain are only applied to a validator's local copy of the Ethereum Virtual Machine (EVM) on Flare after the validator independently verifies the proposed underlying-chain state.
In the following sections, the 2-stage mechanism design of the state connector is defined. The first stage enables Flare validators to enact congestion control by agreement on the span of data from an underlying chain that is currently available, and the second stage involves the actual proof of a transaction from an underlying chain.

Stage 1: Congestion Control by Agreement on Data Availability

Before being able to prove an underlying chain transaction on Flare, the span of blocks from the underlying chain that are globally available across all Flare validators is continuously agreed. Anyone can contribute to this process by participating in the Flare Time Series Oracle (FTSO) as a data provider.
The FTSO is generalised with respect to what type of time-series data it can be used to vote on. Traditionally, it is thought of as a use-case for agreeing prices for assets like BTC, etc. However, the FTSO can also be leveraged for agreeing on the block height of underlying chains. These latest available block height values are used as a sense-check on incoming state connector proofs to ensure that spurious proofs referencing block heights on underlying chains that aren't available yet are promptly discarded.

Stage 2: Proving a Transaction

The process of proving a transaction from an underlying chain is straightforward and just involves sending a transaction called setPaymentFinality:
1
function setPaymentFinality(
2
uint64 chainId, // An identifier for the underlying chain being referenced
3
uint64 ledger, // The block/ledger height that the tx exists in
4
bytes32 txId, // The transaction hash of the tx
5
uint16 utxo, // For UTXO chains, the UTXO output index that's being proven
6
bytes32 paymentHash) // A hash of {destination, data, amount}, where 'data'
7
// is a free-floating input and can pertain to for
8
// example EVM's data field, or a currency type on a
9
// payments network
Copied!
Any contract on Flare can then query the finality of an underlying chain transaction that's been proven to Flare by using the get method getPaymentFinality:
1
function getPaymentFinality(
2
uint64 chainId,
3
uint64 ledger,
4
bytes32 txId,
5
uint16 utxo,
6
bytes32 destinationHash,
7
bytes32 dataHash,
8
uint256 amount
9
) external view returns (
10
bool _proven
11
)
Copied!
Two-phase commit protocol of the state connector for proving transactions from underlying chain
Last modified 6d ago