Polkadot Ethereum Bridges security analysis - sub0.pptx

Polkadot Ethereum Bridges security analysis - sub0.pptx

1. © Polkadot

Wg soa al
Polkadot <> Ethereum ee -
Bridge: E. Ss
m Security Analysis =

Bhargav Bhatt
Web3 Foundation

ae A

ata ; 4

SEHR, ES + Bangkok, March 2024
A, A AE

2. ‘© Polkadot subO
What are Bridges?
e Infra for interoperability b/w independent, technically diverse chains

e Chains can fetch and believe the state of the other
e Interesting Applications can be built upon this basic functionality

os
de?

3. © Polkadot subo

Bridges via Trusted Intermediaries

o Cons:
6 ® e Extra trust assumptions
& € e Centralised (SPoF):
& o Safety
o Liveness

o Censorship

Trusted Intermediary:
Usually a Multisig

4. Polkadot

$80M lost in first hack of 2024. -

‘South Korea Orbit bridge ot $80 min n ack moving a recurent theme

NEE

You cannot make this up

Hacker steals $600MM in ETH from Ronin blockchain the
one underlying Axie

Hacker then goes short Ronin & AXS (Axe token) knowing
as soon as news breaks that tokens will plummet

But NO ONE ¡and they get liquidated on short
before news:
6:32 PM. Mar 29, 2022

Harmony
@harmonyprotocol - Follo

1/ The Harmony team has identified a theft occurring this

„ Morning on the Horizon bridge amounting to approx.

| $100MM. We have begun working with national authorities
1 and forensic specialists to identify the culprit and retrieve
[the stolen funds.

subo

5. © Polkadot subO

Trustless Bridges

Definition: Requirements:

No additional trust assumptions on e Anyone can run a relayer (no stake)

intermediaries/relayers for safety of bridge e Any misbehaviour traceable to validators
e Do not shoot the messenger!

Light-Clients
on Approach

ee =D

+ ETH Light Client running as a Trust-less Relayers: ., Polkadot Light Client run on a

parachain Relay messages & Smart Contract on Ethereum

Listens to Finality on ethereum collect fees + Listens to finality on Polkadot, via
via Altair (sync-committees) BEEFY

6. ¿5 Polkadot subO

Ethereum > Polkadot

os Sync-Committee:
4 0 — _——— 512 Validators out of
- © 500k sign the block

N
I 1
\ 7 ETH Light Client running

on a parachain checks

validity of the signatures.

Y

No»

7. © Polkadot
Polkadot > Ethereum

Polkadot Light Client
—— = — as Smart Contract;
0 > listens to Finality

1 Random Sampling
1 Interactive protocol which reduces
1 costs while retaining security

BEEFY

Challenge: Running a Light Client Smart Contract is
expensive. How to efficiently listen to finality on Polkadot?

subo

| Easier for Ethereum and |
¡ on-chain light clients to follow. :

8. © Polkadot subo
Baseline Protocol

Do 0
9 = |

2f+1 validators sign
BEEFY finalised block

i
Relayer submits 2f+1

signature
Smart Contract verifies
all 2f+1 signatures

$ +
11, f Expensive!!

i

i

i

i

1

i

i

i

i
o

fu

9. €: Polkadot = = sub®
Interactive Random Sampling

1
L

e :
Co» Dei

2f+1 validators sign A
BEERY finalised block i
i

Relayer claims to have A

Sa Uses RANDAO to randomly
sample m signatures
i

i
i
i
i
Gathers and sends the m ;
i
o

signatures 4 N
a Verifies m signatures

mis the security parameter!
Probability of light client being duped is 1/2™

J
ee ppg hea ps a ad a -

10. e”
.e

FARR ree

F

Polkadot = 2 ¿subo

Security Analysis
e Derive m (# signature checks) to ensure security and efficiency
e Crypto-Economic argument:

Exp_Val = p*(DOTMarketCap) + (1-p)*(-Slash) < 0

© p: probability of successful attack = 1/2”.
o Slash: slash value for signing invalid BEEFY blocks.
Note: we only slash the validators and not relayers.
o DotMarketCap: attack value bounded by total DOT market cap

Hang on ....

11. ©) Polkadot subo
Two issues...

We assumed that the protocol is one-shot but it is interactive.

1. RANDAO Randomness is biasable

2. Concurrency can be exploited to increase
probability of successful attacks

12. © Polkadot subo
15 Issue: RANDAO Biasibility

g Shorter Tail of Malicious Producers

Longer Tail of Malicious Producers

e Last-revealer Attack: an ETH block producer skips authoring to bias 1-bit
e Performed state-of-the-art Markov Chain analysis to quantify this bias.

e Solution: Add extra signature checks to negate the bias. ~10 extra sig
checks assuming 67% honesty on Ethereum.

13. Polkadot subO
re Issue: Concurrency 6
I

wo

© .® Signs Malicious B Der
& __--Reláyer2 _-

Signs Malicious B Retäyer-n 7

e Only Validators get slashed
e It takes a delay D to slash
malicious behaviour

Concrete Attack:
Es wee e Spawn multiple relayers using same malicious sigs.

1° While the same malicious validators stake is slashable

Signs Malicious B | Multiple roll of dice (RANDAO) without incurring

| repercussions

14. © Polkadot
2 Solution: Dynamic Sampling

a 5

"2 Signs Malicious B__---"" + ” Al A

- ce Rel or Light Client =

= elayer-2 E 3 R =
= Lo Dynamically increase security parameter

= Signs Malicious B Le Bun @ when attack is detected. 2

Le y Signature checks = m + 2’log (n)+1
E ;
if Features 1 San
Signs Malicious B >

E le signature checks increases only when attack is launched a

le No limit on # of relayers and no trust assumptions I ts

u le Can Relayers start spamming just to increase the security I wi

ur I parameter? NO, such griefing attacks are too expensive | LE

PA, A

15. © Polkadot
Conclusion
ae
aL
ar
== #Signat
a ren depend on

a Sam

Honesty Assumption on
Ethereum

Honesty Assumption on Polkadot
# Polkadot Validators

DOT Market Cap

Minimum Validator Stake
Slashing Rate

RANDAO parameters

Claims signed by Same Voliclator