Flare Community Call - April 27.pdf

flare.xyz @flarenetworks flarenetworks
Flare Community Call
27th April

What we are going to cover today
1. Intros to some of the wider team
2. Recap of Flare’s vision & protocols
3. FTSO update
4. State Connector deep dive & demo
5. Q&A with community guests

Max Wolter
Lead Distributed
Systems Engineer
Previously: Core developer to
Flow Blockchain by Dapper Labs,
contributor to MakerDAO & Ethereum
Ilan Doron
Smart Contract Lead
Previously smart contract lead at
Kyber Network
Dr. Alen Orbanić
Lead System Engineer
Previously CTO & co-founder of 3
companies, among them a crypto
exchange. Math PhD and a
university professor of
computational mathematics.
Engineering Team Intros

Engineering Team
Hugo Philion - CEO, Co-Founder
Previously commodity derivatives portfolio manager at two $1bn+ funds.
BSc Investment and Financial Risk Management. Studied Machine
Learning UCL.
Dr Nairi Usher - Chief Scientist, Co-Founder
Previously postdoctoral researcher at UCL working on quantum
and classical machine learning. Physics PhD in quantum computing.
Joshua G. Edwards - VP Engineering
Extensive background in engineering from tier one consultancies such
as Accenture and Capgemini to start-ups such as Block Matrix, EOS
Infra, and Bottle Pay.
Dr Jernej Tonejc- Senior Security Engineer
Math PhD from University of Wisconsin-Madison, a renowned
cryptographic & security expert and a research scientist with over 20
years of experience in software and security development.
Anna Angelova - Blockchain Software Engineer
Blockchain apps, cryptography and distributed networks
Dr. Boštjan Kovač - Senior Solidity Engineer
Math PhD with over 10 years in software development. Expert for secure
and reliable systems in accounting, crypto exchanges and smart
contracts.
Dr. Gašper Košmrlj - Senior Automation Engineer
Math PhD in graph theory, over 10 years in software development, built
a crypto exchange clearing engine.
Dr. Iztok Kavkler - Senior System Engineer
Math PhD, expert in C/C++, C#, Java, Python, OCaml, Haskell,
Mathematica, JavaScript, XML+XSLT
Moris Kamau - Senior DevOps Engineer
Previously worked at IBM with a focus on Hyperledger.
Sean Rowan - CTO, Co-Founder
ECE Engineer. Golang developer. Leading the research and development
for the State Connector and FCP. MSc Machine Learning UCL.
Dr. Satyajit Das - Golang Engineer
Patent holder and published papers cited over 1000 times, PhD from
Cambridge University. Exceptional Talent visa holder in UK
Filip Koprivec - Senior Solidity Engineer
PHD in Mathematics & Computer Science complete in 2023..

Engineering Team continued
Luka Avbreht
Senior Solidity Engineer
Previously at AFLabs
Dr. Xavi Artigas
Head of Tech Docs
Previously at NEM Protocol
& Samsung

Nick Campion
Head of Marketing
Previously:
EA Sports Global Advertising @
Cicy Zhu
Grants Associate
Previously:
Community Manager @
Max Luck
Ecosystem Growth
Lead
Previously:
Ecosystem Growth @
Ecosystem Team Intros

L1 with 2 unique components:
FTSO: Proof of Stake based Price Oracle.
State Connector: Comes to consensus over the state
of external systems.
Everything else follows from this…

Price: ”The price of an asset.”
Problem: Hard to determine the price of a given asset across
fragmented markets.
Solution: The FTSO is a price oracle leveraging
proof-of-stake.
Open & Decentralized: Token holders are rewarded for
delegating to successful price providers. System price based
on delegation weight.
Providers are arbitraged when their price deviates from the
market. Reward algorithm penalizes monopolies and
collusion.
The system will be able to handle 1000’s of price providers
and 1000’s of price series.
The FTSO is a scalable, decentralized self-correcting
solution to price.
The Flare Time Series
Oracle: solving price

State: “What has happened on another chain.”
Problem: Hard to prove the state of another system.
Solution: The State Connector uses a binary consensus
algorithm to enable the state of any blockchain or external
system to be proven on Flare.
● Uses the open FTSO to generate a default state
attestation set.
● Any/all nodes on the network provide independent
oversight of the default set.
● Disagreements are managed through the binary
branching protocol - resulting in Flare maintaining the
correct state.
It is faster for safe state acquisition than any existing
solution such as oracles, light client relays and
LayerZero.
The State Connector:
solving state acquisition
Figure 3: An intuitive depiction of the branching protocol of the state connector on Flare network.
Independent nodes, represented by triangles in the figure, can be run by anyone without any stake in the
network.
1) Independent nodes agree with the default state connector relayed state at Flare block N.
2) Independent nodes fork when they disagree with the incoming default state connector relayed state. The
state connector branching protocol always guarantees a binary decision that causes all independent nodes
that fork to be consistent.
3) At block N+1, there exists two possible states of the Flare network after forking occurs: one that adopts
the default majority decision of the state connector, and another that has the same state as if the default
state connector set couldn't reach any majority decision. Anyone in the world watching the network can
independently discern that they should ignore and discard the default path if it is faulty as depicted in the
diagram above.
4) Without communicating to each other and with open membership, all independent nodes can determine
what the correct branch is, and the rule for the network is that this branch must be adopted as the only valid
state transition at this block height.

So what are Flare focussing on first?
The $17 Billion problem:
*Approximately $17Bn is held in Ethereum bridges on 27th April 2022 (Dune Analytics)
Bridges

Bridge Hacks
Within the last year:
August ‘21 - Poly Network - $611M
January - Qubit - $80M
February - Wormhole - $320M
February - Meter - $4.2M
March - Ronin - $540M
Total hacked
$1.55 Billion

What do bridges need?
Must have:
● Insurance
● Risk Mitigation
● Decentralization
Nice to Have:
● Uniﬁed liquidity
● Speed

Focus: Evolution
Interoperability: Serve all chains with a single
deployment on Flare.
Another type of “bridging”:
Web2 to Web3 compatibility.

FAssets
The FAsset protocol bridges “non-contract” L1 tokens to Flare,
unlocking the large value of these under-utilised assets.
Flare is initially integrating: BTC, DOGE, XRP, XLM, LTC, FIL and
Algo. Others can easily be added.
Unlike traditional synthetics, FAssets do not require the FAsset
minter to collateralize on Flare. The minter simply pays a fee to
a collateral provider to mint their asset on to Flare.
A holder of FAssets can redeem their FAssets directly back 1:1 for
the underlying asset.
Holders of FAssets earn $FLR as a reward.
FAssets can be bridged to other networks through LayerCake.

Layer Cake
● Fast, decentralized, fully insured bridging for smart contract
tokens.
● A step change in security and speed bridging.
● Provides zero user collateral bridging of any asset to Flare or
between any set of connected smart contract networks, L1 or L2.
● Allows bridging of FAssets through Flare
to any smart contract platform.
● Universal vs. Bilateral. Unifies rather than fragments liquidity.
● Fast and supersedes the need to rely on SPV proofs
for interoperability under normal operation.
● Decentralized & resistant to chain re-organisations.
● Useful in an environment of proliferating chains and subnets.

1. Speed & Safety
How to build fast, decentralised, and
fully insured bridges.
2. Chain Reorganisation
Operating safely across diﬀerent
zones of Sovereignty.
3. Scaling linearly vs.
Quadratically
Connecting all chains without
fragmenting liquidity.
Building (Much) Better Bridges

Speed & Safety
How to build fast, decentralized and fully insured bridges.

A decentralised bridge for smart contract platforms should have
smart contracts on both sides that operate only through a
decentralised relay protocol.
The Challenge:
Deﬁne Light Client Relay and what are the
gaps with them for bridging.
Problem:
A validly decentralised relay protocol (using a
light client relay) can ONLY operate SAFELY if it
is operating SLOWLY. (There are other
problems too but outside of the scope of this
presentation.)
This means 2 things:
a) Decentralised transfers between chains can
only be done slowly. This is poor for usability.
b) The relay model means that decentralised
bridges have to be bilateral.
Chain A
Bridge Contract Bridge Contract
Chain B
Speed vs. Safety | How to build fast, decentralised, and fully insured bridges

Chain A
Chain B
State Connector
Flare’s State Connector can safely acquire
state of another chain and do so substantially
faster than a light client relay.
This lets us employ a mechanism to secure
a fast moving bridge via Flare.

5
0
0
E
T
H
T
o
k
e
n
s
Ethereum
Solana
Bandwidth Providers: Their Role
For an ETH bridge: In the ﬁrst step, Bandwidth
Providers use the State Connector to securely
mint wETH on Flare and deposit this collateral
into the LayerCake contract on Flare.

Ethereum
Bridge Contract
Solana
B
a
n
d
w
i
d
t
h
i
s
5
0
0
E
T
H
B
a
n
d
w
i
d
t
h
i
s
5
0
0
E
T
H
Bridge Contract
Bandwidth Providers: Short-term Collateral
Flare now communicates to each bridge
contract how much bandwidth collateral the
Flare contract holds.
This amount is the maximum that may cross
the bridge in any one unit of time - initially
speciﬁed as 1 hour.

Ethereum
Bridge Contract
Solana
Bridge Contract
ETH
+ Fee
The bandwidth providers now operate the
bridge. They can operate it only up to the
total collateral held by Flare can cross the
bridge in any one time period. This is
enforced by the smart contracts.
User User
If the Bandwidth providers are dishonest and mint for
themselves, the total loss can only equal the total amount
of collateral held as bandwidth. Hence the bridge can be
fully compensated by the funds held by the contract on
Flare. The dishonest bandwidth providers can easily be
removed from the system.
Importantly if the bandwidth providers all disappear
the bridge still operates but reverts to a slow relay.
This means user funds cannot get frozen. This same
mechanism can be used to bridge unlimited
amounts, slowly and safely without relying on
bandwidth collateral.
sETH
Bandwidth Providers: Accountability

Ethereum
Bridge Contract
Solana
Bridge Contract
ETH
The multisig signs for transactions on each chain.
They eﬀectively have control over ALL of the collateral in the contracts.
They can steal it, or more generously when they get hacked (e.g. Ronin) the losses to the contract are unlimited.
There is no speed limit (bandwidth) and there is no insurance (Bandwidth collateral).
Multisig
Sign sETH
The traditional Model: Multisig
Sign

Chain Reorganisation
Operating safely across diﬀerent zones of Sovereignty.

Ethereum Solana
Bridge Contract
Bridge Contract
Each chain has its own consensus mechanism. If chain B relies on chain A because a bridge is built between
them, then chain B is exposed to the risk of consensus on chain A.
The key risk here is something called a reorganisation attack.
Chain reorganisation | Operating safely across diﬀerent zones of Sovereignty
The Challenge

Ethereum Solana
Bridge Contract
Bridge Contract
Large amount
of ETH
Reorganisation Attack Description
At time 1, the User deposits a large amount of ETH in a bridge contract on Ethereum.
User

Ethereum Solana
Bridge Contract
Bridge Contract
Large amount
of sETH
$$$
User
At time 2, the User receives the sETH on Solana and sells it.

User
Ethereum Solana
Bridge Contract
Bridge Contract
At time 3, the User attacks the consensus on Ethereum and returns the chain to the state
prior to the initial ETH deposit.

Large amount of ETH
+
$$$
The User now has their original large amount of ETH plus the money they sold their sETH for.
The bridge contract on Ethereum is now deﬁcient in ETH collateral relative to the amount of sETH minted on
Solana.
This means that the price of the sETH token will unpeg from the value of ETH because it is no longer 1:1
redeemable. This has serious downstream eﬀects on the DeFi ecosystem on Solana.

Ethereum
500 ETH Tokens +
reorganisation protection
collateral
Solana
Bridge Contract
Bridge Contract
Bandwidth Provider Role
In LayerCake, the bandwidth provider sends
both short term collateral for immediate
bridge crossing AND collateral to protect
against chain reorganisation. The risk of
chain reorganisation at a block diminishes
exponentially with each additional block.
Therefore this collateral can be used to
recapitalise the bridge contract in the case
of chain reorganisation.
This means that the bridge is resistant
both against the bandwidth providers
becoming malicious AND against a chain
reorganisation attack.

The risk of chain reorganisation due speciﬁcally to the LayerCake
bridge is reduced if total bandwidth is below the threshold at which
it is desirable to attack the chain. Attacking a chain is very expensive
so in practise this threshold is a very large number.
For providing collateral against these risks, bandwidth providers earn a
small fee for each bridging event.
At a 10 basis point bridging fee (0.1%) Bandwidth Providers will earn ~
37% per year at full utilisation.
To our knowledge, LayerCake provides the most decentralised and
lowest risk way of moving value between chains whilst remaining
economically competitive for both users and bandwidth providers.

Scaling Linearly vs. Quadratically
Connecting all chains without fragmenting liquidity.

The Challenge
Connecting all major chains with Bilateral bridges is infeasible.
The number of bilateral bridges required to fully connect the top 100 chains is 100!/(2*98!)
= 4950 bilateral bridges(!)
1 Bridge 3 Bridges 6 Bridges
Scaling Linearly vs. Quadratically | Connecting all chains without fragmenting liquidity.

The Challenge
If one project can’t build all the required bilateral bridges then separate projects will build different bridges.
Different routings mean that different tokens are created. These tokens are not naturally interchangeable and are not
necessarily all equally supported by dApps.
This fragments liquidity.

Flare can create a universal bridge for 100
chains with just 101 smart contracts (vs 4950
bilateral bridges.)
The token issued by the contract on each chain is
the same regardless of what chain it originated
from.
This uniﬁes liquidity and is a more user friendly
design.
Tokens do not Flow through Flare in the process,
all though they can Flow to Flare as with any
other chain.
In a world of proliferating chains, parachains,
subnets, sidenets and supernets, Flare can
Connect Everything.

What can you do at each stage:
Mainnet Launch: FTSO & StateConnector:
● Governance. (Including using SGB in Governance)
● Delegation to the FTSO.
● Build applications that use prices from the FTSO.
● Build applications that use events from the State Connector.

FAssets:
● Mint and use on Flare: FBTC, FXRP, FALGO, FDOGE, FLTC, FXLM.
○ Uses: DeFi, Crowdfunding, Payments.
● Deploy your FLR as an Agent to earn in the asset you are securing -
eg. BTC, XRP, etc.

Crowdfunding Contract
Stake
FLR
FBTC
FXRP
FDOGE
FLTC
FALGO
FXLM
FAnything
Crowdfunding for everyone
ADA
ETH
USDT
USDC
ETC
Yield
Capital
Yield
Project
tokens
Project

LayerCake:
● Bridge between connected chains with insurance, speed and
decentralization.
● Use assets from connected chains on Flare.
Build dApps on Flare that can use any of the tokens from
connected chains, with information from each connected chain
and/or information from any connected system. Deploy once, serve
many.

Problem:
● Hard to determine the price of a given asset
across fragmented markets.
● Many solutions are either centralized or prone to
manipulation (attacks)
Why FTSO - the oracle problem

● Open & decentralized
● Leveraging proof of stake
● Best prices (middle prices) get rewarded
● Up to 100 providers - later up to 1000’s
FTSO

● Independent price
(FTSO) providers
● Multiple data feeds
(prices)
● Price epoch every
few (3) minutes
● Per Price epoch →
weighted median
FTSO

● All token holders can
participate and receive
rewards.
● No token locking is required
FTSO
Token holder
delegates vote power

● 7 day reward epoch
● Per reward epoch token holders can choose a new price provider.
● Price provider vote power is capped so no single price provider can
have too much vote power.
● Each day around 12 millions SGB distributed in rewards
● 100 competing data providers and 3 trusted providers as a fail safe
mechanism
Technical details

FTSO Analytics
● FTSO evolution
● Tools we and community use
● Some insights

● Started with Songbird network deployment
● Epoch (week) no. 31
● Now, almost all data providers submitting
FTSO Evolution

● Constant monitoring, checking for possible
attacks, exploits, anomalies, collusion etc.
● Our analytics tools are available to data providers
Monitoring

● Great community of data providers (Telegram)
● Strong competition, thinning rewarded price range
● Prices stable (impressively)
● The best providers heavily invested (specialized
teams)
Data providers

● Community analytics
tool
● Reward rate (yield) -
the basis for
delegation decisions
Flaremetrics.io

● Internal tool
● Used by data providers as
well
● Compare performance
● Detect anomalies
FTSO Monitor

● Almost all data
providers are
submitting prices.
Number of votes these days

● ETH price from
Binance compared to
the the FTSO price.
Quality of prices

● Rewarded range (gray
area) around the median
price (50% of weight) got
very thin due to
competition.
● Median price usually
very close to the prices
20-30s before the end of
the commit epoch.
Price and rewarded price range

Success rate - how often the submitted
price appears within the reward belt
How good is a data
provider?
● Top 5 data providers: 70%+ success rate
● Top 50: 20%+ success rate
● Top 75: 15%+ success rate

Top 20 data providers
Data provider competition
Data providers compete for the reward
on 5th decimal digit.

Traﬃc when claiming rewards
● At the end of the reward epoch, rewards get
claimed.
● Rewards are used in other DeFi systems (e.g. Flare
Finance).

Summary
● We are satisﬁed with prices, security
and performance in general.
● Competition has locked prices to a
very narrow reward belt that is hard to
move (50% of voting power needed).
● Community very helpful in detecting
possible colluders.
● Planning to add price drift and collusion
prevention mechanisms.

● The State Connector is a Smart
Contract running on the Flare
blockchain that can retrieve
oﬀ-chain information on demand.
● It works like an on-demand oracle.
● It only answers yes/no questions
which are objectively veriﬁable.
● It has Web2-level scalability.
Overview

Use case
Retrieving the state of other blockchains
⬇
Checking if a transaction happened or not
⬇
Critical building block for F-Assets or the LayerCake bridge!

● Requests sent to the State
Connector are forwarded to a
number of independent
Attestation Providers (APs).
● APs fetch the information
and submit it back to the State
Connector.
● The State Connector runs
consensus on the replies and
produces an agreed-upon
answer.
General scheme

● We’ll make a transfer on the
Algorand network.
● We’ll request the State
Connector (on the Songbird
network) to check if the
transfer happened or not.
● While the check is in progress
I’ll give more details about
the procedure.
● Let’s start the demo!
Demo

● The transfer is complete and
we have its transaction hash
and block height.
● The dApp sends a request to
the State Connector.
1 - Request

● The request is forwarded
to all Attestation Providers
using EVM events.
2 - Request

● Attestation Providers fetch the
requested data.
3 - Fetch Data

● Requests are answered in
rounds.
● Attestation Providers pack all
answers for the round in a
Merkle root and submit it.
● This allows huge amounts of
attestations to be packed into
a single round.
4 - Attestation

● The State Connector counts
the received Merkle roots and
if there’s a 50% consensus it
makes the result publicly
available.
● Otherwise no result is
published and requests must
be performed again.
5 - Attestation Proofs

User requests and Attestation Provider answers happen in a 3-phase protocol:
● Request: Users send their requests to the State Connector.
● Commit: Attestation Providers send obfuscated answers to the State Connector.
● Reveal: Attestation Providers send the deobfuscation key.
RCR protocol
… Request n Commit n Reveal n Request n+3 Commit n+3 Reveal n+3 …
… Reveal n-2 Request n+1 Commit n+1 Reveal n+1 Request n+4 Commit n+4 …
… Commit n-1 Reveal n-1 Request n+2 Commit n+2 Reveal n+2 Request n+5 …

Default Flare State
Alternate Flare State
It’s a safe state.
No transaction will be reverted as long as the
Local APs are correct.
Branching Protocol
● Validators on the Flare network can use Local Attestation Providers.
● If the Local APs disagree with the default set, validators naturally fork and halt.
● This adds a second consensus validation to the State Connector.

State Connector Main Takeaways
1. External information doubly secured by consensus.
2. Opens the door to powerful interoperability tools like
F-Assets and LayerCake.
3. You don’t need to build on it to use it.
4. Web3 attestations with Web2 scalability.

Flare Community Call - April 27.pdf

Flare Community Call - April 27.pdf

Recommended

Recommended

More Related Content

Similar to Flare Community Call - April 27.pdf

Similar to Flare Community Call - April 27.pdf (20)

Recently uploaded

Recently uploaded (20)

Flare Community Call - April 27.pdf