Tweet
Tweet

Slide 1

Slide 1 text

Quisquis: A New Design for Anonymous Cryptocurrencies Prastudy Fauzi, Sarah Meiklejohn, Rebekah Mercer, and Claudio Orlandi
 Aarhus University / University College, London Thanks Claudio and Prastudy for slide inspiration!

Slide 2

Slide 2 text

Cryptocurrencies Network layer Transaction layer Consensus layer 2

Slide 3

Slide 3 text

The UTXO model 5 2 3 3

Slide 4

Slide 4 text

The UTXO model 5 2 3 4

Slide 5

Slide 5 text

The UTXO model 5 2 3 6 5

Slide 6

Slide 6 text

The UTXO model 5 2 3 6 5 2 3 6 1 6

Slide 7

Slide 7 text

The UTXO model 5 2 3 For reference, as of September 2019, the bitcoin blockchain is 243GB in size, but its UTXO set is only ~5GB. 5 2 3 6 1 7

Slide 8

Slide 8 text

Private cryptocurrencies There are different primitives available to help us: • Tumblers • Ring signatures • Zero-knowledge proofs/ zkSNARKS • Batching/aggregating
 
 
 8

Slide 9

Slide 9 text

Private cryptocurrencies And different questions to consider: • Coordination? • Trust in third parties? • Size of UTXO set? • Assumptions? • Plausible deniability? • Provable anonymity? 9 There are different primitives available to help us: • Tumblers • Ring signatures • Zero-knowledge proofs/ zkSNARKS • Batching/aggregating
 
 


Slide 10

Slide 10 text

The UTXO model in private cryptocurrencies y z x 10

Slide 11

Slide 11 text

The UTXO model in private cryptocurrencies y z x u 11

Slide 12

Slide 12 text

The UTXO model in private cryptocurrencies y z x u 2 w y z x u 12

Slide 13

Slide 13 text

In private cryptocurrencies, does the size of the UTXO set always increase? • In private cryptocurrencies based on ring signatures, typical transactions look like this: } + 13

Slide 14

Slide 14 text

• In private cryptocurrencies based on ring signatures, typical transactions look like this: } + • So here, the UTXO set size does always increase. In private cryptocurrencies, does the size of the UTXO set always increase? 14

Slide 15

Slide 15 text

• In private cryptocurrencies based on zero knowledge proofs, the situation looks like this: In private cryptocurrencies, does the size of the UTXO set always increase? 15

Slide 16

Slide 16 text

• In private cryptocurrencies based on zero knowledge proofs, the situation looks like this: In private cryptocurrencies, does the size of the UTXO set always increase? 16 • So here, the UTXO set size does always increase too.

Slide 17

Slide 17 text

• But this property isn’t inherent! • We use the following tools in order to get around this, in the UTXO and the account based setting: • Updatable public keys • Lightweight zero knowledge proofs In private cryptocurrencies, does the size of the UTXO set always increase? 17

Slide 18

Slide 18 text

The idea pks pk1 pk2 } { pk4 pk3 pkr We want to perform n-to-n transactions, without interaction.
 pks wants to send money to pkr, adding transactions from pk1 and pk2 to pk3 and pk4 for anonymity. 18

Slide 19

Slide 19 text

The idea How do we move other people’s money, while also preventing theft? pks pk1 pk2 } { pk4 pk3 pkr 19

Slide 20

Slide 20 text

An idea that doesn’t work The sender chooses random public keys and includes them in the transaction, with the constraint that the money stays where it is. This is great because it prevents theft! But it provides no anonymity. pks pk1 pk2 } { pk2 pk1 pkr 20

Slide 21

Slide 21 text

pks pk1 pk2 } { pk2’ pk1’ pkr But what if we have a way to update public keys! An idea that does work! 21

Slide 22

Slide 22 text

Updatable public keys pk1 pk2 pk3 pk4 22

Slide 23

Slide 23 text

Updatable public keys } { Updatable public keys allow users to create updated public keys, without changing the underlying secret key. pk1 pk2 pk3 pk4 pk1’ pk2’ pk3’ pk4’ 23

Slide 24

Slide 24 text

Updatable public keys } { Shuffling these keys then allows us to hide which of the updated keys is associated with which initial key. pk1 pk2 pk3 pk4 pk1’ pk2’ pk3’ pk4’ 24

Slide 25

Slide 25 text

Updatable public keys } {pknew Updated public keys are indistinguishable from freshly generated public keys. pk1’ pk2’ pk4’ pk1 pk2 pk3 pk4 25

Slide 26

Slide 26 text

Updatable public keys Senders take the keys of other users, including their intended recipients, to form a list of public keys that act as the input to a transaction. pks pkr pk1 pk2 } { pk1’ pk2’ pks’ pkr’ 26

Slide 27

Slide 27 text

Updatable public key construction 27 • Gen( ) : sk = x; choose random s; 
 pk = (gs, gsx) = (a, b) • Update(pk) : choose random r; pk’ = (ar, br) 
 
 Correctness : ✅


Slide 28

Slide 28 text

Updatable public key construction 28 • Gen( ) : sk = x; choose random s; 
 pk = (gs, gsx) = (a, b) • Update(pk) : choose random r; pk’ = (ar, br) 
 
 Indistinguishability : (a, b, ar, br) ~ (a, b, ar, bs), from DDH

Slide 29

Slide 29 text

Updatable public key construction 29 • Gen( ) : sk = x; choose random s; 
 pk = (gs, gsx) = (a, b) • Update(pk) : choose random r; pk’ = (ar, br) 
 
 Unforgeability : outputting x from pk is equivalent to breaking DL

Slide 30

Slide 30 text

We associate each public key with a secret value, and call this pair an account.
 } { Account based model pks, vs pkr, vr pk1, v1 pk2, v2 pks’, vs’ pkr’, vr’ pk1’, v1’ pk2’, v2’ 30

Slide 31

Slide 31 text

Updatable account construction • Accounts are a public key and a commitment to a balance associated with the public key. • We have pk defined as before ((a, b) = (gs, gsx)), and the commitment com(pk, v) = (a, gvb) 31

Slide 32

Slide 32 text

Anatomy of a transaction - Sender: pks
 - Receiver: pkr
 - Random: pk1, pk2 32 - pkr’ = Update(pkr)
 - pk1’ = Update(pk1)
 - pk2’ = Update(pk2) } { pks, vs pkr, vr pk1, v1 pk2, v2 pks’, vs’ pkr’, vr’ pk1’, v1’ pk2’, v2’

Slide 33

Slide 33 text

Anatomy of a transaction Accompanied by a zkp for the following:
 - not revealing which ones, “n - 1 of these public keys were updated using Update( )”;
 - “I know the sk corresponding to the last public key” 33 } { pks, vs pkr, vr pk1, v1 pk2, v2 pks’, vs’ pkr’, vr’ pk1’, v1’ pk2’, v2’

Slide 34

Slide 34 text

Lightweight zero- knowledge proofs • The sender proves that they have correctly updated the keys and have not taken money from anyone except themselves. • The witness for the zero-knowledge proof is limited to this single transaction, so we use discrete-log-based techniques. • Other tradeoffs could be achieved instead: it is possible to instantiate Quisquis with zk-SNARKs. 34

Slide 35

Slide 35 text

Lightweight zero- knowledge proofs • The sender proves that they have correctly updated the keys and have not taken money from anyone except themselves. • The witness for the zero-knowledge proof is limited to this single transaction, so we use discrete-log-based techniques. • Other tradeoffs could be achieved instead: it is possible to instantiate Quisquis with zk-SNARKs. 35

Slide 36

Slide 36 text

Lightweight zero- knowledge proofs • The sender proves that they have correctly updated the keys and have not taken money from anyone except themselves. • The witness for the zero-knowledge proof is limited to this single transaction, so we use discrete-log-based techniques. • Other tradeoffs could be achieved instead: it is possible to instantiate Quisquis with zk-SNARKs. 36

Slide 37

Slide 37 text

• We need to prove three statements about each transaction: • No balances go below zero. • Total value in is equal to the total value out. • For each public key in the initial set, either: • You know the private key, and the value decreased, or the new key is an updated version of the old key, and the value has not changed. Making a lightweight proof 37

Slide 38

Slide 38 text

• We need to prove three statements about each transaction: • No balances go below zero. • Total value in is equal to the total value out. • For each public key in the initial set, either: • You know the private key, and the value decreased, or the new key is an updated version of the old key, and the value has not changed. Making a lightweight proof 38

Slide 39

Slide 39 text

• We need to prove three statements about each transaction: • No balances go below zero. • Total value in is equal to the total value out. • For each public key in the initial set, either: • You know the private key, and the value decreased, or the new key is an updated version of the old key, and the value has not changed. Making a lightweight proof 39

Slide 40

Slide 40 text

• We need to prove three statements about each transaction: • No balances go below zero. • Total value in is equal to the total value out. • For each public key in the initial set, either: • You know the private key, and the value decreased, or the new key is an updated version of the old key, and the value has not changed. Making a lightweight proof 40

Slide 41

Slide 41 text

• The most straightforward way to prove these statements would be with an OR proof for each of the public keys selected. Making a lightweight proof 41

Slide 42

Slide 42 text

• This means, for each of them, there is a proof that says ‘either I know the sk of this pk OR it’s an updated pk and the value is the same as before’ • This means the size of the proofs would be proportional to the number of parties in a transaction, multiplied by the number of options for statements. • Instead, we can make use of shuffle arguments, with an intermediate offline step. Making a lightweight proof 42

Slide 43

Slide 43 text

• This means, for each of them, there is a proof that says ‘either I know the sk of this pk OR it’s an updated pk and the value is the same as before’ • This means the size of the proofs would be proportional to the number of parties in a transaction, multiplied by the number of options for statements. • Instead, we can make use of shuffle arguments, with an intermediate offline step. Making a lightweight proof 43

Slide 44

Slide 44 text

• This means, for each of them, there is a proof that says ‘either I know the sk of this pk OR it’s an updated pk and the value is the same as before’ • This means the size of the proofs would be proportional to the number of parties in a transaction, multiplied by the number of options for statements. • Instead, we can make use of shuffle arguments, with an intermediate offline step. Making a lightweight proof 44

Slide 45

Slide 45 text

• The sender selects their anonymity set, puts their own pks at the top, the recipients’ pks next, and the anonymity set pks after that. Making a lightweight proof 45 pks, vs pkr, vr pk1, v1 pk2, v2

Slide 46

Slide 46 text

• They prove they know sks of pks, vs does not go below zero, the vi are unchanged, and the total value is unchanged. Making a lightweight proof 46 pks, vs pkr, vr pk1, v1 pk2, v2 pks’, vs-v pkr’, vr+v pk1’, v1’ pk2’, v2’

Slide 47

Slide 47 text

• Keys are shuffled with a verifiable shuffle, and the proof and output public keys and values are sent to the network as a transaction. pks, vs pkr, vr pk1, v1 pk2, v2 pks’, vs-v pkr’, vr+v pk1’, v1’ pk2’, v2’ pks’, vs-v pkr’, vr+v pk1’, v1’ pk2’, v2’ Making a lightweight proof 47

Slide 48

Slide 48 text

Comparisons 48

Slide 49

Slide 49 text

Benchmarks 49

Slide 50

Slide 50 text

Thanks! Questions? Quisquis summary & future directions: - Non-growing UTXO set: theoretical and practical optimisations - Theft prevention: 
 other applications for updatable public keys and design principle? - Anonymity: 
 empirical analysis? 50