(Vir irtual) State Channels Sebastian Faust Credits: Stefan - - PowerPoint PPT Presentation

Off-chain Protocols: (Vir irtual) State Channels

Sebastian Faust

BDLT 2019, Vienna, Austria

Credits: Stefan Dziembowski, Lisa Eckey, Julia Hesse, Kristina Hostakova, Sebastian Stammler

1

Hot topic in cryptocurrencies and academia

payment channels state channels Plasma MVP Plasma Cash channel networks

“Channels” is our main focus in this talk. Initiated by [Decker & Wattenhofer] [Poon & Dryja] (plus many informal online publications). “Plasma”initiated by [Poon & Buterin] (plus countless informal online publications).

2

Many interesting state channel projects

We follow the terminology of Perun

(L4 Counterfactual, Connext und Magmo are very similar)

3

Main goal: off-chain contracts

Chess contract

Bob Alice

On-chain contract: deployment and execution on-chain Off-chain contract: deployment and execution off-chain

Chess contract

Bob Alice

4

State Channel Variants

Goal: Off-chain execution of contracts

Ledger state channel: channel built „over ledger“ Virtual state channel: channel built „over ledger channels“ Multiparty state channels: channels for multiparty contracts

Bob Alice Ingrid

This talk

5

Outline

1. Introduction

• 2. Ledger Channels

a. Recap: Ledger Payment Channels b. Ledger State Channels

• 3. Virtual State Channels
• 4. Security analysis
• 5. Summary

6

Main ingredient of off-chain protocols

Bob Alice

Smart contract ≈ „programmable money“ Examples: Ethereum

1. Parties deploy contract and deposit coins to the contract 2. Execute the contract 3. Coins can be assigned back to the users

𝑦𝐵 coins 𝑦𝐶 coins

Contract rules

(in Ethereum written in Solidity)

𝒚𝑩 + 𝒚𝑪 coins Function call f

• n input m

𝑦𝐵 + 𝑦𝐶 coins

Updating the state

7

Ledger Payment Channels

• 1. Create
• 2. Update
• 3. Close

Alice

1 coin 1 coin 2 coins

Off-chain! On-chain 1 On-chain Dispute On-chain Bob Bob

Goal: Execute payments off-chain directly over ledger Examples: Raiden Network in Ethereum, Lightning Network in Bitcoin

Payment channel contract 1 0.9 1.1 2 𝟑 coins

8

𝝉𝐁𝐦𝐣𝐝𝐟 ≔ 𝐓𝐣𝐡𝐨𝐁𝐦𝐣𝐝𝐟(0.99, 1.01, 1) 𝝉𝐂𝐩𝐜 ≔ 𝐓𝐣𝐡𝐨𝐂𝐩𝐜(0.99, 1.01, 1)

Updating the ledger payment channel

Bob Alice

Goal: Update to new balance 0.99 for Alice and 1.01 for Bob Idea: exchange signatures on message containing new balance m := (0.99, 1.01, 1)

1 1

New balance of the parties An index called version number

𝝉𝐁𝐦𝐣𝐝𝐟 𝝉𝐂𝐩𝐜

0.99 1.01

9

Further updates

Bob Alice

For each update increase version number: version = version + 1

0.98 1.02

𝝉𝐁𝐦𝐣𝐝𝐟 𝝉𝐂𝐩𝐜 𝝉𝐁𝐦𝐣𝐝𝐟 ≔ 𝐓𝐣𝐡𝐨𝐁𝐦𝐣𝐝𝐟(0.98, 1.02, 2) 𝝉𝐂𝐩𝐜 ≔ 𝐓𝐣𝐡𝐨𝐂𝐩𝐜(0.98, 1.02, 2)

10

Closing the payment channel

Bob Alice

Suppose Bob wants to close the channel

0.98 1.02

Payment channel contract

Close(0.98, 1.02, 2, 𝝉𝐁𝐦𝐣𝐝𝐟) Alice gets notified that close was sent Alice has 1 hour time to react 1 hour = maximal time needed to post on the ledger Ping() 1.02 coins 0.98 coins Verify 𝝉𝐁𝐦𝐣𝐝𝐟 and pay

• ut balance

Close(0.98, 1.02, 2, 𝝉𝐁𝐦𝐣𝐝𝐟)

11

Handling disuptes

Bob Alice

Suppose malicious Alice closes channel with earlier balance

0.98 1.02

Payment channel contract

Close(0.99, 1.01, 1, 𝝉𝐂𝐩𝐜) 1.02 coins 0.98 coins Verify 𝝉𝐁𝐦𝐣𝐝𝐟 and 𝝉𝐂𝐩𝐜 Close(0.98, 1.02, 2, 𝝉𝐁𝐦𝐣𝐝𝐟) Pay out balance according to highest version number Close(0.99, 1.01, 1, 𝝉𝐂𝐩𝐜) Close(0.98, 1.02, 2, 𝝉𝐁𝐦𝐣𝐝𝐟)

12

Outline

1. Introduction

• 2. Ledger Channels

a. Recap: Ledger Payment Channels b. Ledger State Channels

• 3. Virtual State Channels
• 4. Security analysis
• 5. Summary

13

State channels – motivation

One way to look at the payment channels: Alice and Bob maintain a simulated ledger between themselves. The contents of the “simulated ledger” is registered on the “real ledger” only if:

• the channel is closed, or
• the parties run into a dispute.

A natural question: can we also have contracts “inside of the simulated ledger”?

14

Ledger State Channels

• 1. Create
• 3. Execute
• 4. Close

Alice

1 coin 1 coin 2 coins

Off-chain! On-chain 1 On-chain Bob Bob

Goal: Execute contracts off-chain directly over ledger

State channel contract 1 2

• 2. Add

Off-chain! 𝟑 coins

15

Add a contract

Alice Bob Bob

Recall: Contracts own coins and maintain state Idea: Extend signed tuple by coins and state of contract m := (𝒚𝑩, 𝒚𝑪, 𝒛, 𝒕𝒖𝒃𝒖𝒇, version)

𝒚𝑪

Alice’s coins Bob’s coins Contract’s off- chain state Contract’s coins

𝑧=𝑧𝐵 + 𝑧𝐶

Initial state

𝝉𝑩𝒎𝒋𝒅𝒇= 𝑻𝒋𝒉𝒐𝑩𝒎𝒋𝒅𝒇(𝒏) 𝝉𝑪𝒑𝒄= 𝑻𝒋𝒉𝒐𝑪𝒑𝒄(𝒏)

𝒚𝑩 𝒚𝑪-𝒛𝑪 𝒚𝑩-𝒛𝑩

16

Executing a contract

Alice

Suppose Alice wants to execute contract on function Move with input a How can a contract execution be done in a state channel? 1. Peaceful execution: optimistic (off-chain)

• 2. Forceful execution: in case of dispute (on-chain)

Move(a) Function

Current state

𝒛

New state’

𝒛

Input

17

Peaceful execution

Alice

Idea: Executing the contract in the state channel Suppose latest state was: (𝒚𝑩, 𝒚𝑪, 𝒛, 𝒕𝒖𝒃𝒖𝒇, version) Both parties locally compute: Parties exchange signatures on: (𝒚𝑩, 𝒚𝑪, 𝒛, 𝒕𝒖𝒃𝒖𝒇′, version+1)

Bob Bob

Execute Move(a) Move(a)

Current state

𝒛

New state’

𝒛

18

Forceful execution

Alice

Idea: If dispute during execution occurs, parties move on-chain Suppose latest state was: (𝒚𝑩, 𝒚𝑪, 𝒛, 𝒕tate, version) Register latest state (𝒚𝑩, 𝒚𝑪, 𝒛, 𝒕𝒖𝒃𝒖𝒇, version) in channel contract From then on: continue execution on-chain

Bob Bob

Execute Move(x) Bob does not reply register Move(x,a)

19

Security and efficiency guarantees

Consensus on create & add: Agreement required from Alice & Bob Guaranteed execution: Once contract is added, its execution cannot be halted  achieved via forceful execution Optimistic execution in O(1) rounds: When both parties honest contract execution is in real time  achieved via peaceful execution

Alice Bob Bob

1. Create: Contract requires confirmation from both parties

• 2. Add: Protocol requires signature

from both parties

20

Summary – ledger channels

Payment channels State channels Purpose 2-party payments 2-party contracts Create channel On-chain On-chain Update/Execute Off-chain balance changes Off-chain contract execution Close On-chain On-chain

Main features compared to on-chain transactions

• Low costs
• Instantaneous updates/execution

21

Outline

1. Introduction

• 2. Ledger Channels

a. Recap: Ledger Payment Channels b. Ledger State Channels

• 3. Virtual State Channels
• 4. Security analysis
• 5. Summary

22

Channel networks

Problem: every pair of parties requires a separate channel Can we do better? Yes! Option 1: Routing each payment via Ingrid

• Hashed Timelock Contract (HTLC): used for payments in e.g., Lightning

Option 2: Creating virtual state channels

• Used for state channel networks

Bob Alice Ingrid

23

Virtual state channel – overview

Bob Alice Ingrid Bob, let’s play!

virtual channel contract

• 3. Execute

Off-chain! On-chain On-chain

• 2. Add

Off-chain!

Virtual channel

• 1. Create
• 3. Execute
• 4. Close
• 2. Add

Ledger channel

• 1. Create
• 4. Close

Off-chain! Off-chain! Off-chain! Off-chain!

24

Virtual state channel: create

Bob Alice Ingrid

𝟏. 𝟐 𝟏. 𝟑

𝟐 𝟐 𝟐 𝟐

Our goal

Virtual Channel Contract (VCC)

𝟏. 𝟐 𝟏. 𝟑 𝟏. 𝟑 𝟏. 𝟐

Ingrid puts collateral 𝟏. 𝟑 to take role of Bob

Add contract 𝑫𝑩 Add contract 𝑫𝑪

𝑫𝑩 𝑫𝑪 Ingrid puts collateral 𝟏. 𝟐 to take role of Alice

25

Bob Alice Ingrid

𝟐 𝟐 𝟐 𝟐

𝑫𝑩: OK! 𝑫𝑪: OK!

Virtual state channel: create

Virtual Channel Contract (VCC)

𝟏. 𝟐 𝟏. 𝟑 𝟏. 𝟑 𝟏. 𝟐

Ingrid puts collateral 𝟏. 𝟑 to take role of Bob 𝑫𝑩 𝑫𝑪 Ingrid puts collateral 𝟏. 𝟐 to take role of Alice Ingrid agreed Ingrid agreed

26

Bob Alice Ingrid

𝟏. 𝟐 𝟏. 𝟑 𝟏. 𝟐 𝟏. 𝟑

𝟏. 𝟐 𝟏. 𝟑 𝟏. 𝟘 𝟏. 𝟗 𝟏. 𝟗 𝟏. 𝟘

Summary: Use sub-protocol „add“ of underlying state channel to add contract representing virtual state channel

𝑫𝑩 𝑫𝑪

Virtual state channel: create

27

Virtual state channel: contract lifecycle

Bob Alice 𝟏. 𝟐 𝟏. 𝟑

1. Adding contract

• 2. Peacful execution of contract
• 3. Closing contract

𝟏. 𝟐 𝟏. 𝟑

Exchanging signatures on new version tuples between parties

𝟏. 𝟑 𝟏. 𝟐

28

Virtual state channel: close

Bob Alice Bob Alice Ingrid

𝟏. 𝟘 𝟏. 𝟗 𝟏. 𝟗 𝟏. 𝟘

After close:

𝟏. 𝟑 𝟏. 𝟐

Bob Bob Alice Alice Ingrid

𝟐. 𝟐 𝟏. 𝟘 𝟏. 𝟘 𝟐. 𝟐 Gained 0.1 coins Lost 0.1 coins Financially neutral

Before close: Alice gained 0.1 coins and Bob lost 0.1 coins

𝟏. 𝟑 𝟏. 𝟐

29

So far: All parties behave honestly How to handle malicious parties? Forceful execute protocol in virtual channels

(Two methods: indirect vs. direct disputes)

30

Virtual state channel: forceful execute

Alice Bob Bob Alice Ingrid Bob is not responding Bob Bob

Start registration Start registration

Bob is not responding

Move registration on-chain

Forceful execute via indirect dispute: dispute resolution via intermediary

31

Virtual state channel: forceful execute

Alice Bob Bob Alice Ingrid Bob Bob

Move registration on-chain

Forceful execute via indirect dispute: dispute resolution via intermediary

Finalize registration

Continue to execute

• ff-chain
• Advantage: Alice does not need to go on-chain
• Disadvantage: Longer time for dispute resolution

32

Virtual state channel: forceful execute

• Advantage: Conflicts can be resolved faster
• Disadvantage: Honest Alice needs to go to ledger

Bob

Alice

Bob is not responding Continue to execute

• n-chain

dispute board contract

Forceful execute via direct dispute: dispute resolution directly on blockchain

State registration

33

Extension: longer channels

Idea: Underlying (ledger/virtual) state channels are used as building block

Party 3 Party 1 Party 2 Party n

…

Party n-1

I want to play I want to play

…

34

Two additional security and efficiency guarantees

Balance neutrality: Ingrid never looses money Whatever malicious Alice and Bob do, Ingrid will always receive back her 2 coins Pessimistic execution for virtual channels built over n ledger state channels:

• Direct dispute: O(n) rounds
• Indirect dispute: O(1) rounds

Bob Alice Ingrid

𝟏. 𝟐 𝟏. 𝟑

𝟏. 𝟘 𝟏. 𝟗 𝟏. 𝟗 𝟏. 𝟘

𝟏. 𝟐 𝟏. 𝟑 𝟏. 𝟐 𝟏. 𝟑

35

Summary – ledger vs. virtual

Ledger channels Virtual channels Create On-chain Off-chain Update/Execute Off-chain Off-chain Close On-chain

• ff-chain

Technique to connect ledger channels

• Used mainly for state channel networks

Minimize interaction with intermediary

36

Outline

1. Introduction

• 2. Ledger Channels

a. Recap: Ledger Payment Channels b. Ledger State Channels

• 3. Virtual State Channels
• 4. Security analysis
• 5. Summary

37

Complex protocols

38

How to analyze complex protocols

39

One approach – Modern cryptography

Define security

• f protocol

Design protocol Prove security

Provable security: Sound methodology for complex protocols Two ways of defining security:

• Game-based: adversary violates certain security guarantees.

Example: IND-CPA security for encryption

• Simulation-based: Adversary in real-world cannot do

„better“ than in ideal world. Example: crypto protocols in the universal composability model.

Adversary 𝑛0, 𝑛1 𝐹𝑜𝑑(𝑛𝑐) Challenger Real world Ideal world Ideal adversary

≈

40

The UC model – Environment

Describes “everything else” happening in the world (e.g., other protocol executions etc.)

Protocol P

Environment API Side effects

Environment orchestrates:

• The parties by providing inputs to and receives
• utputs from them
• The adversary that can corrupt parties and

communicate with environment in each step of protocol execution via side effects (communication, consumed time and resources, etc.)

Analyse security of protocol by analysing its effects on the environment

41

The UC model – The Ideal world

How to analyse the effects that a protocol has on its environment?

• Define an ideal functionality ℱ capturing “ideal effects” on the environment
• Construct simulator that simulates “real effects” on the environment
• Show that P and (ℱ, 𝒯) “look the same” for any environment ℰ

ℱ

Environment 𝓕

Simulator 𝒯

API Ideal side effects Simulated side effects

≈

Protocol P

Environment API Side effects

42

The UC model – The formal security definition

P UC-realizes 𝓖 if ∃ 𝓣 s.t. ∀ 𝓕 the interaction with (ℱ, 𝓣) is indistinguishable from the interaction with P

Might be difficult to prove if P very complex

Technique: Modularize protocol and proofs ℱ

Environment 𝓕

Simulator 𝒯

API Ideal side effects Simulated side effects

≈

Protocol P

Environment API Side effects

43

The UC model – Simplifying via hybrids and composition

Ideal world Hybrid world Real world

𝓕

P

𝜍

𝝆 𝝆 𝝆

𝓕

ℋ ℋ ℋ

ℱ 𝒯

𝓕

𝜍

≈

Show hybrid protocol (𝜍, ℋ) UC-realizes ideal functionality ℱ

≈

Modularize protocol P: P composed of (𝜍, 𝜌) with 𝜍 the main protocol and 𝜌 sub-routines Show that 𝜌 UC-realizes ℋ

ℋ 𝝆 𝒯

≈

𝓕 𝓕

44

The UC model – Overview of approach

Ideal world Real world

1. Ideal functionality ℱ

• Abstract specification

2. Protocol P

• Define behavior of each party

3. Simulator 𝒯

• 4. Prove indistinguishability
• ∀environment ℰ, real and ideal

world indistinguishable

ℱ

P

𝒯

≈

𝓕 𝓕

45

The UC model for ledger based protocols

How to model a public ledger in UC?

• Global ideal functionality
• List of accounts
• Everyone can read its state
• State must be the same

in real and ideal world

Ideal world Real world

ℱ𝑑ℎ input input

• utput
• utput
• utput
• utput

Ledger Alice 5 Bob 6 … Ledger Alice 5 Bob 6 … Also the environment!

46

• 1. State Channels – Define ideal functionality

State Channel Functionality Create Add Close Execute Ledger Alice 5 Bob 6 …

• utput

input

• utput

input

47

• 2. State Channels – Design protocol

Ledger Alice 5 Bob 6 …

input

• utput
• utput

input

State channel smart contract hybrid world

State Channel Smart Contract

• Modelled as an ideal functionality
• Hybrid functionality of the protocol

48

• 3. State Channels – Build simulator

Main tasks:

• Changes on the ledger
• Same amount
• At the same time
• Outputs
• Same content
• At the same time

Ideal world Hybrid world

ℱ𝑑ℎ Ledger Alice 5 Bob 6 input input

• utput
• utput

Ledger Alice 5 Bob 6 𝑢1 𝑢2 𝑢3 𝑢1 𝑢2 𝑢3 Ledger Alice 4 Bob 6 Ledger Alice 4 Bob 6

• utput
• utput

𝒯

Transact now! Output now!

49

Main tasks:

• Changes on the ledger
• Same amount
• At the same time
• Outputs
• Same content
• At the same time

Ideal world Hybrid world

ℱ𝑑ℎ Ledger Alice 5 Bob 6 input input

• utput

Ledger Alice 5 Bob 6 𝑢1 𝑢2 𝑢1 𝑢2 𝑢′3 Ledger Alice 4 Bob 6 Ledger Alice 4 Bob 6

• utput

𝒯

𝑢′3

Even if parties are corrupt

• 3. State Channels – Simulator

Ledger Ledger ℱ𝑑ℎ(2) 𝛲(2) ℱ𝑑ℎ(1) Ledger ℱ𝑑ℎ(3) = = 𝛲(3) Ledger 𝛲(1) = Recall: protocol design Proof steps

1. Channel of length 𝑗 build on top of channels of length ≤ 𝑗 − 1 2. UC Composition 3. Channel of length 1 build using state channel smart contract 4. UC Composition

P

• 4. State Channels – Proofs using modular approach

Outline

1. Introduction

• 2. Ledger Channels

a. Recap: Ledger Payment Channels b. Ledger State Channels

• 3. Virtual State Channels
• 4. Security analysis
• 5. Summary

52

Summary

53

• 1. Use cases require different off-chain solution
• 2. Much more research that was not covered in this talk: Multiparty

state channels, Services, Privacy, Routing, Optimizations,…

• 3. Future research directions:

a) More formal modelling and proofs needed b) Hybrids of Channels & Plasma c) Explore limitations via lower bounds d) Optimization and implementation e) ...

Thank you for your attention!

Icons made by Freepik, Smashicons, and Nikita Golubev from www.flaticon.com

54