Improving Authenticated Dynamic Dictionaries, with Application to Cryptocurrencies
1 like170 views
The document proposes using authenticated dynamic dictionaries to improve the efficiency of validating transactions in cryptocurrencies. It describes how storing the balance of each public key (PK) in an authenticated data structure like an AVL+ tree, along with a proof of the sender's balance included in each transaction, allows lightweight validation of transactions and blocks. Batching multiple proofs together can further reduce the proof size for validating multiple transactions, improving efficiency and allowing full validation on low-end hardware. This approach avoids the need to store the full state locally and enables light clients and SPV mining.
![Header
Consensus data
Transactions
Merkle tree
Tx_root
Header
Consensus data
Transactions
Merkle tree
Tx_root Tx_proofs_root
Transaction
proofs
Our proposal
Idea [early versions in Miller ‘12, Ethereum/Wood ‘14, White ‘15]:
Use authenticated data structures (root in block header)
and include a proof of sender’s balance with each transaction.
Authenticated Dictionaries to the Rescue](https://image.slidesharecdn.com/authdict-fc-2017-170411155102/85/Improving-Authenticated-Dynamic-Dictionaries-with-Application-to-Cryptocurrencies-5-320.jpg)
Improving Authenticated Dynamic Dictionaries, with Application to Cryptocurrencies
- 1. Improving Authenticated Dynamic Dictionaries, with Applications to Cryptocurrencies Leonid Reyzin1 , Dmitry Meshkov2 , Alexander Chepurnoy3 , Sasha Ivanov4 1.Boston University, http://www.cs.bu.edu/faculty/reyzin Research supported by the Waves platform, wavesplatform.com 2.IOHK Research, dmitry.meshkov@iohk.io 3.IOHK Research, alex.chepurnoy@iohk.io 4.Waves platform, sasha@wavesplatform.com
- 2. Motivation: validating transactions PKA PKD 14 Stateless validation: Check syntax, signature of PKA, etc. Stateful validation: Check that PKA has 14 (+ fee) All required info is in the transaction itself Requires knowing how much PKA has based on prior transactions Large (and growing!) dictionary data structure. Currently in Bitcoin: 1.5GB (serialized). Even worse in multiasset blockchains: one per asset. PKA 36 PKB 684 PKD 13 PKC 2 PKE 347 PKF 98 PKH 54 PKG 50 PKI 12 PKJ 285 PKL 3 PKK 463 PKM 12 PKN 76 PKP 88 PKO 3 …
- 3. Miners should validate transactions efficiently. They can: 1.Keep State in RAM => Mining centralization 2.Do not keep State => SPV mining Motivation: big state problems
- 4. Problems for users: ● Can’t validate blocks on low-end hardware ● Long validation on commodity hardware => ● Users move to centralized services Motivation: big state problems
- 5. Header Consensus data Transactions Merkle tree Tx_root Header Consensus data Transactions Merkle tree Tx_root Tx_proofs_root Transaction proofs Our proposal Idea [early versions in Miller ‘12, Ethereum/Wood ‘14, White ‘15]: Use authenticated data structures (root in block header) and include a proof of sender’s balance with each transaction. Authenticated Dictionaries to the Rescue
- 6. ● Make state authenticated ● Easy: proof of a sender's balance (standard Merkle tree proof with respect to the root). ● More complicated: ensuring the prover changed the balances correctly. ● Important: we do not wish to trust the prover! Merkle Root PKA : 36 PKB : 384 PKD : 13 PKA 36 PKB 684 PKD 13 PKC 2 … Proofs: authenticated state
- 7. ● Prover ● Light verifier Proofs verify balances and calculate new root hash Root N-1 PKA 36 Root N Transactions PKB 684 PKD 13 PKA 22 PKB 684 PKD 27 Txs + proofsRoot N-1 Root N proofs Blockchain parties
- 8. Skiplist1 Lookup proof size 1.5 H log2 N Insert proof size 1.5 H log2 N Deterministic 1) Papamanthou and Tamassia. "Time and space efficient algorithms for two-party authenticated data structures." 2007. N = # of PKs H = length of hash Prior work
- 9. Skiplist1 Red-black tree2 Lookup proof size 1.5 H log2 N (H + K) log2 N Insert proof size 1.5 H log2 N 3 (H + K) log2 N Deterministic 1) Papamanthou and Tamassia. "Time and space efficient algorithms for two-party authenticated data structures." 2007. 2)Miller, Hicks, Katz, Shi. "Authenticated data structures, generically." 2014. N = # of PKs H = length of hash K = length of PK Prior work
- 10. Skiplist1 Red-black tree2 Our AVL+ tree Lookup proof size 1.5 H log2 N (H + K) log2 N H log2 N Insert proof size 1.5 H log2 N 3 (H + K) log2 N H log2 N Deterministic 1) Papamanthou and Tamassia. "Time and space efficient algorithms for two-party authenticated data structures." 2007. 2)Miller, Hicks, Katz, Shi. "Authenticated data structures, generically." 2014. N = # of PKs H = length of hash K = length of PK Our improvements: AVL
- 11. ● For N=106 , AVL+ proof size 765 bytes (32-byte hashes, 32-byte keys, 8-byte values) Single operation proof size
- 12. Root ● There are a lot of transactions in block ● Transactions may change same public key ● Multiple proofs can be combined together PKA 36 PKB 684 PKD 13PKC 2 PKE 347 PKF 98 PKH 54PKG 50 hash hash hash hash hashhash 14 PKD PKA Our improvements: batching
- 13. Root ● Proofs can contain same hashes 14 PKD PKA PKB 684 PKD 13PKC 2 PKE 347 PKF 98 PKH 54PKG 50 hash hash hash hash hashhash PKA 36 Our improvements: batching
- 14. Root ● Some hashes from one proof may be calculated from other proofs 14 PKD PKA PKA 36 PKB 684 PKD 13PKC 2 PKE 347 PKF 98 PKH 54PKG 50 hash hash hash hash hashhash Our improvements: batching
- 15. ● For tree N=106 and batch B=103 , compressed proof size is 400 bytes, plain 765 bytes Multiple operations proof size
- 16. Conclusion Authenticated data structures enable: ● Verification on low-end hardware ● Mining on commodity hardware
- 17. ● Paper: https://ia.cr/2016/994 ● Code: https://github.com/input-output-hk/scrypto ● Coming on: https://wavesplatform.com ● Slides: https://www.slideshare.net/DmitryMeshkov ● Twitter: https://twitter.com/DmitryMeshkov ● Email: dmitry.meshkov@iohk.io Thank you!