Towards a Generalised Blockchain Fabric @ CodeBlock 2018

Towards a Generalised
Blockchain Fabric
Code Block 2018
Alexei Zamyatin

Motivation
Different
Properties
Privacy
Scalability
Security
Expressiveness
Transparency
Consensus
Finality
Challenge:
Secure, privacy preserving,
scalable and decentralized
cross-chain communication
Today:
Over 1500 heterogeneous
cryptocurrencies
Towards a Generalised Blockchain Fabric - Code Block 18 - Alexei Zamyatin

Why not simply agree on a single standard?

Why Decentralization?

X

Miners
Developers
P2P
Network

Cross-Blockchain Communication Today
• Assumption: (Most) permissionless blockchains are decentralized
• How about the communication between these systems?
• Centralized liquidity providers necessary
• „Trusted“ 3rd parties (exchanges, …)

Transfer via Liquidity Providers
Liquidity Provider (LP)
Bob‘s BTC Wallet
Bob‘s
BTC
Account
Bob‘s
ETH
Account
Alice‘s ETH Wallet
LP‘s
BTC Wallet
LP‘s
ETH Wallet
LP fee
Tx fee Tx fee
BTC‘s P2P Network ETH‘s P2P NetworkTowards a Generalised Blockchain Fabric - Code Block 18 - Alexei Zamyatin

Properties Relevant for Interoperability
Interoperability
Privacy
Scalability
Security
Expressiveness
Transparency
Consensus Finality
(Simplified)

(Non-Exhaustive Example!)Towards a Generalised Blockchain Fabric - Code Block 18 - Alexei Zamyatin

General Categorization of Approaches
1. Centralized Exchanges
• ShapeShift, …
2. Notary Schemes
• Liquid, Interledger, Comit Network
3. Atomic Cross-Chain Swaps
• Pegged Sidechains and Cross-chain
Payment Channels (Lightning)
4. Chain Relays
• BTCRelay (BTC-ETH), PeaceRelay (ETC-ETH),
Project Alchemy (ZEC-ETH)
5. Merged Mining
• PoW reuse, Drivechains
6. Meta-layer constructions
• Polkadot, Cosmos
7. Sharding
• Aspen, Elastico
8. Based on Trusted Execution
Environments
• Tesseract, Teechan

General Categorization of Approaches
1. Centralized Exchanges
• ShapeShift, …
2. Notary Schemes (Trust N/M)
• Liquid, Interledger, Comit Network
3. Atomic Cross-Chain Swaps
• Pegged Sidechains and Cross-chain
Payment Channels (Lightning)
4. Chain Relays
• BTCRelay (BTC-ETH), PeaceRelay (ETC-ETH),
Project Alchemy (ZEC-ETH)
5. Merged Mining
• PoW reuse, Drivechains
6. Meta-layer protocols
• Polkadot, Cosmos
7. Sharding
• Aspen, Elastico
8. Based on Trusted Execution
Environments
• Tesseract, Teechan
Covered in today‘s session

Atomic Cross-Chain Swaps
• Operations on chain A and chain B have the same „trigger“
• E.g. revealing of a hash preimage
• Also referred to as Hash Locking
 Idea: Lock funds on A, while unlocking corresponding funds on B

BTC LTC
Alice
(has BTC wants LTC)
Bob
(has LTC wants BTC)
time
No broadcast
 No effect
Published to LTC
Published to BTC
Unpublished /
Sent directly to user
Legend

s  𝑟𝑎𝑛𝑑𝑜𝑚()
Tx1  if (𝐻 𝑖𝑛𝑝𝑢𝑡 = 𝐻 𝑠 ∧ ∃𝑠𝑖𝑔 𝐵 ∨
BTC LTC
Alice
(has BTC wants LTC)
Bob
(has LTC wants BTC)
time
No broadcast
 No effect
Published to LTC
Published to BTC
Unpublished /
Legend

BTC LTC
Alice
(has BTC wants LTC)
Bob
(has LTC wants BTC)
time
t1
No broadcast
 No effect
Published to LTC
Published to BTC
Unpublished /
Legend

BTC LTC
Tx2
𝑠𝑖𝑔𝑛 𝑠𝑘 𝐵, 𝐓𝐱𝟐
Alice
(has BTC wants LTC)
Bob
(has LTC wants BTC)
time
t1
No broadcast
 No effect
Published to LTC
Published to BTC
Unpublished /
Legend

BTC LTC
Tx2
Tx1
Alice
(has BTC wants LTC)
Bob
(has LTC wants BTC)
time
t1
A can use Tx2
after 𝑡1to get
refund
Published to LTC
Published to BTC
Unpublished /
Legend

BTC LTC
Tx2
Tx1
t1
Alice
(has BTC wants LTC)
Bob
(has LTC wants BTC)
time
A can use Tx2
after 𝑡1to get
refund
t2
Published to LTC
Published to BTC
Unpublished /
Legend
Tx3  if (𝐻 𝑖𝑛𝑝𝑢𝑡 = 𝐻 𝑠 ∧ ∃𝑠𝑖𝑔 𝐴 ∨

BTC LTC
Tx2
Tx1
Tx4
𝑠𝑖𝑔𝑛 𝑠𝑘 𝐴, 𝐓𝐱𝟒
t1
Alice
(has BTC wants LTC)
Bob
(has LTC wants BTC)
t2
time
A can use Tx2
after 𝑡1to get
refund
Published to LTC
Published to BTC
Unpublished /
Legend

BTC LTC
Tx2
Tx1
Tx4
Tx5 (spends Tx3 revealing s)
t1
Alice
(has BTC wants LTC)
Bob
(has LTC wants BTC)
t2
Tx3
time
A must spend
Tx3 before 𝑡2,
otherwise B
can claim
refund;
B must spend
Tx1 before 𝑡1,
otherwise A
can claim
refund
Published to LTC
Published to BTC
Unpublished /
Legend

BTC LTC
Tx2
Tx1
Tx4
Tx5 (spends Tx3 revealing s)
Tx6 (spends Tx1 using s)
t1
Alice
(has BTC wants LTC)
Bob
(has LTC wants BTC)
t2
Tx3
time
Swap
completed!
Published to LTC
Published to BTC
Unpublished /
Legend

Interledger
Source:
Thomas, Stefan, and Evan Schwartz. "A protocol
for interledger payments." URL
https://interledger. org/interledger. pdf (2015).
• „Ledger-provided“ escrows
• Lockbox  unlock by proof that receiver
has received payment
• Must be implemented on-chain
• Atomic Mode:
• Two-Phase Commit with N notaries
as coordinators (PBFT, …)
 3f + 1 honest notaries required
• Global timeout
• „Federated“
• Universal mode: hash locking

Atomic Cross-Chain Swaps – Pro‘s / Con‘s
+ Atomicity
• Swap only performed if both parties perform the necessary Tx on the respective chains
+ Both parties can withdraw funds after time limit in case of failure
- Funds locked until swap complete or time lock passed
• DoS attacks possible
- Sender and Receiver must monitor both chains
• N chains  N running clients
• Alternatively: Federated constructions (e.g. Interledger)
• Potential use case for SPV-Proofs / NiPoPoWs
- Requires timely action from both parties

Atomic Cross-Chain Swaps - Properties
• StatelessTransferred Information
• Cryptographic (although other types also applicable)Validation
• Bi-directionalDirection
• OptionalTTP
• ProbabilisticFinality Guarantees
• Sender + Receiver online
Party Availability
Requirements
• Limited to the least expressive chain‘s scriptScript Expressiveness

Chain Relays
• System inside chain A is able to read, interpret and validate
events/state of chain B.
 Idea: prove that a transaction occurred on chain A to release funds
on chain B.

BTC Relay
• Smart Contract on ETH validating BTC
headers (like SPV Clients)
• Headers fed to SC
• Transactions in BTC can then be validated
• Can notify swap contract that BTC has been
transferred
• Validation must be possible on-chain
• E.g. not feasible for Scrypt
• Native support?
Source: http://btcrelay.org/

BTC Relay – BTC Swap
Ethereum
Bitcoin
BTC Swap
Has BTC, wants ETH Has ETH, wants BTC

Ethereum
1) Bob sends
 ETH
 Alice s ETH account
 his BTC address
 agreed exchange info
to escrow contract
Bitcoin
BTC Swap

Ethereum
1) Bob sends
 ETH
 his BTC address
to escrow contract
Bitcoin
BTC Swap
2) Alice sends BTC to Bob’s address (TxBTC)

Ethereum
1) Bob sends
 ETH
 his BTC address
to escrow contract
Bitcoin
BTC Swap
3) Alice calls
btcrelay.relayTx(TxBTC, addrBTCSwap)

Ethereum
1) Bob sends
 ETH
 his BTC address
to escrow contract
Bitcoin
BTC Swap
3) Alice calls
4) BTC Relay verifies TxBTC was
performed in Bitcoin

Ethereum
1) Bob sends
 ETH
 his BTC address
to escrow contract
Bitcoin
BTC Swap
3) Alice calls
5) BTC Relay invokes
processTransaction() in
BTC Swap

Ethereum
1) Bob sends
 ETH
 his BTC address
to escrow contract
Bitcoin
BTC Swap
3) Alice calls
5) BTC Relay invokes
processTransaction() in
BTC Swap
6) BTC Swap
releases payment to
Alice

Chain Relays – Pro‘s / Con‘s
+ “Non-interactive”
• Publicly verifiable computations in Smart Contracts
+ Multi-purpose
• More use cases than 1:1 asset exchange
• Events on chain A can trigger complex processes on chain B (e.g. for bribing miners [McCory et al. ‘18])
- Relay contract must contain all headers of the connected chain
• Ongoing research to reduce storage requirements / simplify proofing mechanism
- Sufficient incentive for users to submit block headers necessary
• At least to cover gas costs
• Working fee model necessary
- Currently no freshness guarantees
• i.e., BTC relay may fall far behind Bitcoin

Chain Relays - Properties
• StatelessTransferred Information
• CryptographicValidation
• UnidirectionalDirection
• NoneTTP
• ProbabilisticFinality Guarantees
• Contract deployed & available, Receiver online
Party Availability
Requirements
• „Turing complete“Script Expressiveness

Meta-Layer Protocols
• Introduce a second communication layer
• Abstraction of blockchain-specific properties
• Rely on game theoretic incentives
• Interactions between different actors/roles
• Utilize described mechanisms to integrate external chains
• Notary schemes, chain relays, atomic swaps,…
 „Bridges“

Polkadot
• One of Parity‘s flagship projects
• Two chain types:
• Para(llel)chains – globally-coherent dynamic data structures/blockchains
• Relay chain(s) – base communication/synchronization layer
• Relay Chain consensus:
• Initially: permissioned, i.e., 3f+1 BFT algorithm (e.g. HoneyBadgerBFT,
Tendermint, …)
• Planned: Delegated Proof-of-Stake (DPoS)

Polkadot - Relay Chains and Parachains
Source:
Wood, Gavin. "Polkadot: Vision for a heterogeneous multi-chain framework." URL
https://github.com/polkadot-io/polkadot-white-paper/raw/master/PolkaDotPaper.pdf (2016).
Relay Chain Parachain
n1

mn
Source:
https://github.com/polkadot-io/polkadot-white-paper/raw/master/PolkaDotPaper.pdf (2016).Towards a Generalised Blockchain Fabric - Code Block 18 - Alexei Zamyatin

Source:
Chain
Relay Chain
connects to
m
n
Parachain

Source:
Chain
Relay Chain
connects to
m
n
Parachain
Transaction
Interchain On-chain
contains
1n
triggers
11

Polkadot - Actors
• Validator
1. Validates parachain transactions/blocks
2. Agrees on interchain TX  relay chain
validation
• Stake slashed in case of misbehaviour
• Nominator
• Can provide stake for validator
• Collator
• Collects parachain TX and sends block
candidates to validators
• Fisherman
• Monitors validators for misbehaviour / Reports
to other validators
• Clients/Light Clients
Source:
https://github.com/polkadot-io/polkadot-white-paper/raw/master/PolkaDotPaper.pdf (2016).Towards a Generalised Blockchain Fabric - Code Block 18 - Alexei Zamyatin

Polkadot - Actors
• Relay Chain:
• Validator
1. Validates parachain transactions/blocks
2. Agrees on interchain TX  relay chain
validation
• Stake slashed in case of misbehaviour
• Nominator
• Can provide stake for validator
• Parachain
• Collator
• Collects parachain TX and sends block candidates
to validators
• Fisherman
• Monitors validators for misbehaviour / Reports
to other validators
• Clients/Light Clients
Participant
ValidatorNominator FishermanCollator
Relay node
Para-node
stakes for
nm
monitors / reports failure
n m
provides parachain
blocks
n m
validates/
slashes
n
m

Polkadot – Domain Overview (simplified)
Chain
Participant
ValidatorNominator FishermanCollator
Transaction
Interchain
Transaction
Parachain
Transaction
triggers
11
Relay node
Para-node
has
1
connects to
m
n
n
1 1
n
stakes for
nm
monitors / reports failure
n m
provides parachain
blocks
n m
Participant/Transaction relations
omitted for simplicity
validates/
slashes
n
m
n
FIFO Transaction
Queue
contains
n
1

Polkadot - Challenges
• Game theoretic incentives not sufficiently studied
• Modelling of incentives and potential attacks necessary
• High communication complexity
• Extent of necessary overhead unclear
• A lot of technical details still not clearly defined
• How to maintain information on asset state after cross-chain TX?
• Consensus finality  what happens if parachains fork? Or relay chain forks?
• Address/account scheme
• Privacy features
• ….

Cosmos
• Cosmos Hub and Zones (child blockchains)
• Each Zone can become a hub in turn
• Zones run Tendermint BFT (3f + 1)
• Fixed known set of validators
• Cross-chain communication similar to two-
way-peg
• Bridges to other chains necessary (e.g. ETH)
• Permissioned setup
• Tested with 65 validator nodes
• Initially 100, scale up to 300 within 10 years
Source:
Kwon, Jae, and Buchman, Ethan. „Cosmos: A Network of Distributed
Ledgers“. URL
https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md (2016)

Outlook
• Rapidly increasing number of projects promising „Multi-blockchain protocols“
• Often limited technical details provided  unclear how exactly communication will be
facilitated.
• Many rely on versions of atomic swaps or chain relays under a (semi-) centralized setup
• Active development
• 1:1 Bridges between Ethereum and other networks in development
• Lightning cross-chain swaps between BTC and LTC
• Overlay protocols / Colored Coins
• …
• No “truly decentralized” solution yet
 Alarming shift towards centralized approaches

Questions?
Alexei Zamyatin
a.zamyatin@imperial.ac.uk
PGP ID: 0x5485B999
PGP FP: 2F5F E92D CDAC 15B0 84A6 9FE9 9018 A958 5485 B999
@alexeiZamyatin

Towards a Generalised Blockchain Fabric @ CodeBlock 2018

Recommended

Recommended

More Related Content

What's hot

What's hot (10)

Similar to Towards a Generalised Blockchain Fabric @ CodeBlock 2018

Similar to Towards a Generalised Blockchain Fabric @ CodeBlock 2018 (20)

Recently uploaded

Recently uploaded (20)

Towards a Generalised Blockchain Fabric @ CodeBlock 2018