Cryptocurrency with multiple modes

(This is a joint post by Alexander Chepurnoy and Hong-Sheng Zhou.)

Bitcoin-like cryptocurrencies have proven to be a phenomenal success. The underlying techniques hold a huge promise to change the future of financial transactions, and eventually our way of computation and collaboration. We will thru this weblog illustrate  important concepts and techniques that have been explored in the cryptocurrency research&development community; we will also discuss our own perspectives.

In this post, we will focus on the modes (or, roles) in a cryptocurrency system.
Cryptocurrencies are often multi-mode systems: some network nodes are running in the full mode, and each full-mode node records and checks the complete history of transactions, and is capable of verifying the integrity of history and the validity of new transactions by itself; the remaining nodes may run in certain light modes, and they might store only partial history. The Bitcoin whitepaper, along with description of a full-node, is proposing the first known alternative mode, an SPV (Simple Payment Verification) mode. While a full-node is downloading and validating proofs of work, linking structure correctness and also correctness of each transaction in each block, an SPV client skips the validation of the transactions. An SPV client is consuming less bandwidth, storage and processing resources, as it is downloading and processing only block headers (part of a block which is enough to validate a proof of work, linking structure and authenticity of transactions; in Bitcoin, a header is just of 80 bytes). The security assumption here is that an honest majority of miners are working on chains with valid blocks only, so a longest chain found in the network is also a valid one.

To validate a transaction, a node usually maintains a validation state, which is a compact result of transactions processing. In a simplest case of a cryptocurrency, this state is a balance sheet (in Bitcoin, UTXO set). Unlike Bitcoin, Ethereum has an authenticated digest of the validation state written into a header of a block. It allows Ethereum to have a new mode, which is called fast in the Geth client and warp in the Parity client (we call this mode fast further). In this mode, a node is first downloading headers to check proofs of work and linking structure. Then a node is downloading a historical validating state snapshot (for example, from 1024 blocks ago). For the suffix after the snapshot, full blocks with transactions are to be downloaded and validated. Being very known in the community for very fast bootstrapping, this mode lacks rigorous security analysis. We for the first time provide[2] such an analysis and prove security of the mode. The security notion here is multi-mode soundness: if we start to watch for two nodes running the protocol amongst others, one in full mode, another in fast mode, both are whether accept an arbitrary block or reject it.

Our cryptographic analysis for the fast mode assumes that players are storing historical snapshots. However, this assumption could be broken, especially when validation state becomes big (tens or hundreds of gigabytes). Possible solution for this problem that we are proposing in the paper [3] (with implementation available at [4]) is to modify Proof-of-Work puzzle scheme in such way that it is needed to present a proof of historical snapshot possession in order to generate a valid block (and be rewarded for it). We call this mode enforced-fast.

Another interesting mode is introducing asymmetry in node roles and provides a possibility to have lightweight full-nodes which are not maintaining validation state in order to validate new blocks. Miners are still need to hold validation state, and they put proofs of the state transformations into the blocks. A light full-node is able then to check the proof against the transactions. For this, validation state is needed to be authenticated with the help of a two-party authenticated dynamic dictionary. The scheme is presented in the paper [5]. We call this mode light-full further.

Modes mentioned above are trying to be more efficient than traditional full nodes (validating everything from genesis), and have the same or almost the same security level. Developing modes which are less secure, we note two advances. First, we can have SPV mode which is much more efficient. With more details, by using additional links between blocks in the blockchain, we can build interactive[6] or non-interactive[7] proofs of proof-of-work, and then an SPV client can check correctness of a header-chain by processing a proof which size is log(|C|), where |C| is a length of the header-chain (in contrast with traditional SPV client which needs to download and process the whole header-chain). Second, we can build hybrid modes. A hybrid approach of secure thin client was proposed in [8]. A secure thin client is doing adaptive verification of blocks with regards to the level of targeted confidence. That is, this kind of client is checking part of transactions in arbitrarily-chosen suffix of the blockchain, and a user is choosing how much resources to spend on this probabilistic validation (more resources to be spent means higher confidence in the suffix contents).

Concluding, we provide the following table with modes we mentioned, their security level and assumptions, and the main achievement for a node running in a mode of interest (the column Secure shows whether a node running in a mode is always agree on validity of an arbitrary block with a full-node, if security assumptions hold).

Mode Secure Assumption Achievement
Full + Node validates everything
Fast + Nodes are storing state snapshots deep enough No need to download and process all the full blocks, only suffix is enough
Enforced-Fast + No rollback deeper than a security parameter is possible No need to download and process all the full blocks, only suffix is enough
Light-Full + Miners are storing validation state Fullnodes can avoid maintaining validation state
SPV Miners are working on valid chains No need to download any full blocks
Secure Thin Client Probabilistic validation Only part of full blockchain suffix is to be downloaded and verified

References:

  1. Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008. https://bitcoin.org/bitcoin.pdf
  2. Tuyet Duong, Hong-Sheng Zhou, and Alexander Chepurnoy. Multi-mode cryptocurrency systems. To appear, 2017. Draft is available at https://cryptographylab.bitbucket.io/pubs/mMode.pdf
  3. Alexander Chepurnoy, Tuyet Duong, and Hong-Sheng Zhou. Trim: A robust pruning method for blockchain. To appear. Previous version of the protocol description could be found at https://arxiv.org/abs/1603.07926
  4. Trim source code. https://bitbucket.org/trimtrim/trim/
  5. Leonid Reyzin, Dmitry Meshkov, Alexander Chepurnoy, and Sasha Ivanov. Improving authenticated dynamic dictionaries, with applications to cryptocurrencies. In FC, 2017. http://eprint.iacr.org/2016/994
  6. Aggelos Kiayias, Nikolaos Lamprou, and Aikaterini-Panagiota Stouka. Proofs of proofs of work with sublinear complexity. In International Conference on Financial Cryptography and Data Security, pages 61–78, 2016 (http://fc16.ifca.ai/bitcoin/papers/KLS16.pdf)
  7. Aggelos Kiayias, Andrew Miller, and Dionysis Zindros. Non-interactive proofs of proof-of-work. http://eprint.iacr.org/2017/963
  8. Davide Frey, Marc X Makkes, Pierre-Louis Roman, François Taı̈ani, and Spyros Voulgaris. Bringing secure bitcoin transactions to your smartphone. In Proceedings of the 15th International Workshop on Adaptive and Reflective Middleware, page 3. ACM, 2016. https://hal.archives-ouvertes.fr/hal-01384461/document