Regulation of Cryptocurrencies - HUJI – May 2019

Ittay EyalTechnion EE and IC3

Payments Channels and Performance in Blockchain Systems

2

Cryptocurrency Key Challenges

A

B

C

1. No stealing: Only Alice can move her money 2. Minting: Fair money creation 3. No double-spending: Alice cannot duplicate her money

3

Cryptocurrency Key Challenges

A

B

C

1. No stealing: Only Alice can move her money 2. Minting: Fair money creation 3. No double-spending: Alice cannot duplicate her money

4

Cryptocurrency Key Challenges

A

B

C

1. No stealing: Only Alice can move her money 2. Minting: Fair money creation 3. No double-spending: Alice cannot duplicate her money

5

1. No stealing: Only Alice can move her money 2. Minting: Fair money creation 3. No double-spending: Alice cannot duplicate her money

Cryptocurrency Key Challenges

A

B

C

6

Cryptocurrency Key Challenges

𝐴 → 𝐵

Log

A B C

7

Cryptocurrency Key Challenges

𝐴 → 𝐵

Log

A B C

𝐴 → 𝐶

8

Nakamoto’s Solution

Reach consensus on all transactions

Widely adopted • Cryptocurrencies: Bitcoin, Ethereum, Zcash, … • DLTs: Corda, Ripple, Hyperledger, …

9

Nakamoto’s Solution

Reach consensus on all transactions

Implication: • Low throughput • High latency

10

Payment Channels

• Each side places a deposit amount on blockchain

• Payments via direct communication

• Each can unilaterally terminate channel • Place settlement transaction on blockchain• Receive its current balance

11

Toy Example: Unidirectional Channel

RefundTime-

Locked

Alice Bob

SetupIn blockchain:

$100

12

Toy Example: Unidirectional Channel

Alice Bob

SetupIn blockchain:

$100

Payment$97

$3

$3

RefundTime-

Locked

13

Toy Example: Unidirectional Channel

Alice Bob

SetupIn blockchain:

$100

$97

$3

Payment$95

$5

$3

$2

RefundTime-

Locked

Payment

14

Toy Example: Unidirectional Channel

Alice Bob

SetupIn blockchain:

$100

$97

$3

Settlement$95

$5

$3

$2

RefundTime-

Locked

Payment

15

Bidirectional Channel

Each party can settle channel

But

No party can roll back channel state.

16

Bidirectional Channel

Simple solution: 2 unidirectional channels

Deposit: $100

Deposit: $100

17

Bidirectional Channel

Simple solution: 2 unidirectional channels

But: redundant resets on depletion

Deposit: $100 $100

$50 Deposit: $100

The Lightning Network

19

Lightning Network

Poon and Dryja. 2016

Coordinated state updates. Payment is:

1. Capability to close channel at current state

2. Capability to take all if other side settles at older state

20

Lightning Network

Poon and Dryja. 2016

Coordinated state updates. Payment is:

1. Capability to close channel at current state• A signed transaction settling current state

2. Capability to take all if other side settles at older state

21

Lightning Network

Poon and Dryja. 2016

Coordinated state updates. Payment is:

1. Capability to close channel at current state• A signed transaction settling current state

2. Capability to take all if other side settles at older state • A secret nullifying deprecated settlement transaction

22

Lightning Network

Poon and Dryja. 2016

Coordinated state updates. Payment is:

1. Capability to close channel at current state• A signed transaction settling current state • Abortable with a secret

2. Capability to take all if other side settles at older state • A secret nullifying deprecated settlement transaction

23

Multihop Payments

24

Multihop with HTLC

HTLC: Hash Time-Lock Contract

HTLC (𝐻(𝑆),𝑇,𝐵): Can only claim by knowing S and

B’s signature before time T

25

Payment Chain – Lightning (HTLC)

𝑆

𝐻(𝑆)

26

Lightning Network and similar solutionsRequire real-time blockchain access

Teechain

28

Software Guard Extensions (SGX)

Untrusted Operating System & Hypervisor

Untrusted Application Code

Code & Data

Untrusted Hardware

TrustedProcessor

1. Confidentiality (including SRNG)2. Integrity 3. Remote attestation

Resilient to software attacks(OS, BIOS, viruses etc.)

Resilient to Physical attacks (ram, disk, bus, peripherals)

Resilient to software attacks(OS, BIOS, viruses etc.)

29

Software Guard Extensions (SGX)

Untrusted Operating System & Hypervisor

Untrusted Application Code

Code & Data

Untrusted Hardware

TrustedProcessor

Attestation: • Output • Fingerprint • signature

1. Confidentiality (including SRNG)2. Integrity 3. Remote attestation

output

30

Strawman: single TEE

31

Strawman: single TEE

Can prevent parties from settling

32

TEEChain Crux

• TEEs share a secret key, unknown to Alice and Bob • TEE only produces settlement transaction once, then stops

participating

TEEBTEEA

[1] Joshua Lind, Ittay Eyal, Florian Kelbert, Oded Naor, Peter Pietzuch, Emin Gun Sirer. TR. 2017.

33

Channel Setup

• TEEs form secure channel • Each creates public/private keypair (DH) • Use attestations (Teechain running in sgx)

TEEBTEEA

[1] Joshua Lind, Ittay Eyal, Florian Kelbert, Oded Naor, Peter Pietzuch, Emin Gun Sirer. TR. 2017.

34

Deposits

• Alice sends money to TEE address • Notifies TEE of deposit

TEEA

deposit a1$100

deposit a2$30

deposit a3$150

35

Deposit Association

deposit a1$100

deposit a2$30

deposit a3$150

TEEBTEEA

• Alice associates deposit with channel • Instruction to her TEE • TEE produces message for Bob

• Bob verifies that deposit on blockchain

Red channel

36

Payment

deposit a3$150

TEEBTEEA

Red channel

deposit b3$80deposit b1

$30

• Alice instructs TEE to pay • TEE produces payment confirmation • Alice sends confirmation to Bob (one message)

37

Deposit Dissociation

TEEBTEEA

• Alice can dissociates unused deposits after confirmation from Bob

• (She can settle channel if dissociation fails)

Red channel

deposit a3$150

deposit b3$80deposit b1

$30

38

Settlement

deposit a3$150

TEEBTEEA

Red channel

deposit b3$80deposit b1

$30

• Each TEE can settle channel using associated deposits on both sides

• Then stops, no more state updates

39

Asynchronous Blockchain Access

After deposits are in the blockchain: • Payments without blockchain appends • Parties need not monitor blockchain

Instant Blockchain Payment

40

Crash Fault Resilience – Persistent Storage

• Naively: store state and reload after failure • Replay attack

• Use monotonic counters• Increment on each store • Only load if count matches

• But: slow… (10/sec)

41

Crash Fault Resilience – Chain Replication

commandcmd cmd

Output

Can settle But nothing else

Chain broken, no more payments

• But: requires much more resources

withattestation

withattestations

withattestations

42

AtlanticOcean

Satoshi’s across The Atlantic

Protocol Throughput (no batching)

[k tx/sec]

Throughput (batching) [k tx/sec]

Latency (no batching)

[msec]

Latency (batching)

[msec]

Lightning - 1 - 400

Teechain: no FT 130 150 90 200

Teechain: chain replication

35 135 300 500

43

Payment Chain - TEEChain

• No blockchain access or monitoring (beyond deposits)

• Any party can settle at any time• Either pre-payment or

post-payment

locklock

lock

signsign

sign

promise Apromise A

promise A

promise Bpromise B

promise B

updateupdate

update

idle idle idle idle

lockedlocked

locked

signedsigned

signed

Promised APromised A

Promised A

Promised BPromised B

Promised B

updatedupdated

updatedrelease

releaserelease

idleidle

idleidle

44

Conclusion

• Payment channels: potential to resolve scalability issues • Assume either

• synchronous blockchain access (Lightning) or • TEEs (Teechain)

• Middlemen allow multi-hop

₪ ₪

45

Conclusion

• Payment channels: potential to resolve scalability issues • Assume either

• synchronous blockchain access (Lightning) or • TEEs (Teechain)

• Middlemen allow multi-hop

₪ ₪

Much more, like state channels and

virtual channels