Distributed ledgers: how, why, and why not? Sarah Meiklejohn - - PowerPoint PPT Presentation

distributed ledgers how why and why not
SMART_READER_LITE
LIVE PREVIEW

Distributed ledgers: how, why, and why not? Sarah Meiklejohn - - PowerPoint PPT Presentation

Distributed ledgers: how, why, and why not? Sarah Meiklejohn (University College London) company company data consumers data producers company company 2 (icons by parkjisun from noun project) data consumers data producers 3 (icons by


slide-1
SLIDE 1

Distributed ledgers: how, why, and why not?

Sarah Meiklejohn (University College London)

slide-2
SLIDE 2

2

data consumers data producers company

(icons by parkjisun from noun project)

company company company

slide-3
SLIDE 3

3

data consumers data producers

(icons by parkjisun from noun project)

slide-4
SLIDE 4

4

10 usability 9 governance 8 comparisons 7 key management 6 agility 5 interoperability 4 scalability 3 cost-effectiveness 2 privacy 1 scalability top ten obstacles for blockchains

slide-5
SLIDE 5

5

1 scalability 10 usability 9 governance 8 comparisons 7 key management 6 agility 5 interoperability 4 scalability 3 cost-effectiveness 2 privacy

slide-6
SLIDE 6

6

Bitcoin / blockchains / distributed ledgers “mining”

slide-7
SLIDE 7

7

  • ver 4 EH/s (4 × 1018 H/s) to achieve 7 tx/s!
slide-8
SLIDE 8

8

full state replication

slide-9
SLIDE 9

9

120 GB and (always) rising

slide-10
SLIDE 10

10

full state replication ↑ computational power ⇒ ↓ throughput

slide-11
SLIDE 11

11

monetary supply ledger

central distribute decentral decentral central central

transparent?

y y (or n) n

pseudonyms?

y y (or n) n

computation

high! low low RSCoin

RSCoin [DM NDSS’16]

slide-12
SLIDE 12

12

mintette mintette mintette mintette bank user mintettes already reach consensus before sending info to bank mintettes store info only within a given shard

slide-13
SLIDE 13

13

RSCoin consensus

mintette1 mintette1 user

1 2 tx:

3 4

service mintette1

1 2

1

mintette2 mintette2 mintette2

1 tx

✓ ✓

2

tx tx

simple adaptation of Two-Phase Commit (2PC)

slide-14
SLIDE 14

14

user

1 2 tx:

service

1 2

1

t r a n s a c t i o n s

mintette mintette mintette mintette mintette mintette mintette mintette mintette mintette mintette mintette mintette mintette mintette mintette mintette mintette

1 : 2 :

slide-15
SLIDE 15

15

mintette1 mintette1 user

1 2 tx:

mintette1

1

service

1 2

1

mintettes check for double spending… …using lists of unspent transaction outputs (utxo)

slide-16
SLIDE 16

16

mintette1 mintette1 user

1 2 tx:

mintette1

1

2

service

1 2

1

signed ‘yes’ vote

slide-17
SLIDE 17

17

mintette1 mintette1 user

1 2 tx:

3

service mintette1

1 2

1

mintette2 mintette2 mintette2

1 tx

✓ ✓

2

“bundle of evidence” contains ‘yes’ votes from majority of mintettes in shard mintettes check validity of bundle by checking for signatures from authorized mintettes…

slide-18
SLIDE 18

18

mintette1 mintette1 user

1 2 tx:

3 4

service mintette1

1 2

1

mintette2 mintette2 mintette2

1 tx

✓ ✓

2

tx tx

…and if satisfied they add transaction to be committed and send back receipt

slide-19
SLIDE 19

19

security properties

no double spending (if honest majority per shard) non-repudiation auditability (if mintettes log their behavior)

slide-20
SLIDE 20

20

consensus features

conceptually simple no broadcast mintettes communicate only with users no expensive hashing! scalable

↑ computational power ⇒ ↑ throughput

slide-21
SLIDE 21

21

T = set of txs generated per second Q = # mintettes per shard M = # mintettes

  • comm. per mintette per sec =

∑tx∈T 2(mtx+1)Q

scales infinitely as more mintettes are added!

M consensus features

slide-22
SLIDE 22

22

each new mintette adds ≈ 75 tx/sec compared to Bitcoin’s 7

slide-23
SLIDE 23

23

mintette mintette mintette mintette bank user

slide-24
SLIDE 24

24

Elastico [LNZBGS CCS’16]

committee member consensus committee directory committee committee member committee member committee member run PBFT run PBFT

slide-25
SLIDE 25

25

Elastico [LNZBGS CCS’16]

slide-26
SLIDE 26

26

1 scalability 10 usability 9 governance 8 comparisons 7 key management 6 agility 5 interoperability 4 scalability 3 cost-effectiveness 2 privacy

slide-27
SLIDE 27

27

8 comparisons 1 scalability 10 usability 9 governance 7 key management 6 agility 5 interoperability 4 scalability 3 cost-effectiveness 2 privacy

slide-28
SLIDE 28

28

mintette mintette mintette mintette bank

RSCoin [DM NDSS’16]

user

slide-29
SLIDE 29

29

mintette mintette mintette mintette user

slide-30
SLIDE 30

30

user log server

log

log server

log

log server

log

log server

log

no unified log ⇒ no need for consensus can (retroactively) detect inconsistencies between logs

slide-31
SLIDE 31

31

system Log CheckEntry GenEventSet Inspect Gossip evidence log server

log

monitor

snap BE E

auditor snap CheckEvidence

transparency overlays [CM CCS’16]

slide-32
SLIDE 32

32

system Log GenEventSet GenEventSet log server

log

log server

log

log server

log

log server

log

slide-33
SLIDE 33

33

auditors (efficiently) determine if events are in the log

system Log CheckEntry GenEventSet (meaning |snap| ≪ |log|) auditor snap log server

log

slide-34
SLIDE 34

34

monitors (inefficiently) detect bad events in the log

system Log CheckEntry GenEventSet Inspect log server

log

auditor snap monitor

snap BE E

(meaning |E| ≈ |log|)

slide-35
SLIDE 35

35

auditors and monitors ensure consistent view of log

system Log CheckEntry GenEventSet Inspect Gossip evidence log server

log

monitor

snap BE E

auditor snap CheckEvidence (can output evidence of inconsistencies)

slide-36
SLIDE 36

36

security properties

consistency: log server can’t offer different views of log non-frameability: auditor and monitor can’t frame the log accountability: log server is held to its promises

slide-37
SLIDE 37

37

log server

log

monitor

snap BE E

auditor snap prover verifier ? ?

slide-38
SLIDE 38

38

log server

log

monitor

snap BE E

auditor snap prover verifier ? ?

slide-39
SLIDE 39

39

Log CheckEntry Inspect Gossip evidence log server

log

monitor

snap BE E

auditor snap CheckEvidence

Bitcoin

sender receiver miner blockchain

sender and receiver don’t need to store blockchain gives rise to hybrid system (≈RSCoin) with no mining

slide-40
SLIDE 40

40

Log CheckEntry Inspect Gossip evidence log server

log

monitor

snap BE E

auditor snap CheckEvidence

Certificate Transparency [LL13]

CA client website

bad certificate issuance is exposed ⇒ clients are less likely to accept bad certificates

(icon by parkjisun from noun project)

slide-41
SLIDE 41

41

Log CheckEntry id provider

log

auditor snap

CONIKS [MBBFF USENIX Sec’16]

client client

(icon by parkjisun from noun project)

Inspect

slide-42
SLIDE 42

42

Log CheckEntry ILS log validator

snap

ARPKI [BCKPSS CCS’13]

CA client website

(icon by parkjisun from noun project)

ILS log

slide-43
SLIDE 43

43

RSCoin

  • paque

centralized transparent decentralized

what is this distance?

CONIKS ARPKI

slide-44
SLIDE 44

44

security properties

consistency non-frameability accountability no double spending non-repudiation auditability

⇔ ⇔ ⇔

privacy (of what)? privacy (of what)?

(transparency overlays) (RSCoin)

slide-45
SLIDE 45

45

RSCoin

  • paque

centralized transparent decentralized

what is this distance? what security properties to look for?

CONIKS ARPKI

slide-46
SLIDE 46

46

8 comparisons 1 scalability 10 usability 9 governance 7 key management 6 agility 5 interoperability 4 scalability 3 cost-effectiveness 2 privacy

slide-47
SLIDE 47

47

1 scalability 10 usability 9 governance 7 key management 6 agility 5 interoperability 4 scalability 3 cost-effectiveness 2 privacy

Thanks! Any questions?

8 comparisons