Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cryptocurrency with central bank regulations: the RSCoin framework

1,328 views

Published on

An overview of the RSCoin cryptocurrency framework developed for central bank applications, its implementation in Haskell and proposals for further development.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Cryptocurrency with central bank regulations: the RSCoin framework

  1. 1. Cryptocurrency with central bank regulations: the RSCoin framework Roman Oliynykov, Ph.D., Dr.Habil., Arseniy Seroka, Jonn Mostovoy IOHK IACR Summer School on Blockchain Technologies Corfu, Greece June 1st, 2016 Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 1 / 41
  2. 2. Outline Thanks to George Danezis and Sarah Meiklejohn, developers of RSCoin, for essentially new approach in architecture of cryptocurrencies. Bitcoin open problems and governmental interest to Blockchain-based technologies application. Architecture and general properties of RSCoin. Haskell implementation of RSCoin. Open questions of RSCoin. Proposals for RSCoin further development. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 2 / 41
  3. 3. Some open problems for Bitcoin poor scalability: practically available number of transactions up to 7 per second; cf: VISA and MasterCard can process tens of thousands transaction per second; network latency: long time for transaction approval: up to tens of minutes or even longer in specific cases; liquidity limits (still actual in 2016): exchanges which trade bitcoins unable to convert really big amount of bitcoins to the fiat currency; stability and predictability issues: exponential growth of mining difficulty leads to oligopoly of Bitcoin network control: a very few mining pools may dictate rules for the whole Bitcoin network; a Goldfinger attack: an entity with computational resources over a some threshold can effectively work against the rest of the Bitcoin network; wasting computational power and energy (up to 1 GW); enormous Bitcoin miner bonus on each transaction (paid by a big number of newcomers): at least, $3 even on penny-size money transfer (cf.: more than $600 millions annual miners’ reward in 2015 and not more than 7 transactions per second, with 31.5 millions seconds per year). Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 3 / 41
  4. 4. Governmental interest in Blockchain-based technologies https://www.gov.uk/government/uploads/system/ uploads/attachment data/file/492972/gs-16-1-distributed-ledger-technology.pdf Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 4 / 41
  5. 5. Open problem for traditional decentralized cryptocurrencies: governmental application the loss of control over monetary supply; little to no flexibility for macroeconomic policy; extreme volatility in their value as currencies. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 5 / 41
  6. 6. RSCoin: cryptocurrency framework proposal for central banks a central bank is a trusted entity (and the central bank only); centralization of the monetary supply: every unit of a particular currency is created by the central bank; a transparent transaction ledger; a distributed system for maintaining transaction ledger; a globally visible monetary supply (and more visible transactions on shares, derivatives, etc.); easily scalable solution (to provide necessary amount of transactions per second). Proposed in ”Centrally Banked Cryptocurrencies” by George Danezis and Sarah Meiklejohn Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 6 / 41
  7. 7. Different types of participants in RSCoin a central bank (the only trusted entity); mintettes (institutions authorized by a central bank for validating transactions for some period of time); users (senders and receivers of transactions). NB: mintettes and users are not trusted and their misbehavior can be detected and ultimately held accountable. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 7 / 41
  8. 8. Functions of each participant in RSCoin (I) central bank: authorization of mintettes for a given period of time (authorization is accomplished by a PKI-type functionality); forming higher-level block from lower-level blocks provided by mintettes; arbitration procedures (when necessary); monetary supply for macroeconomic policy. NB: there is no interaction between the central bank and users. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 8 / 41
  9. 9. Functions of each participant in RSCoin (II) mintette: transaction certification that for its input addresses there is no double-spending (for transactions provided by users); verification of transactions with evidence from other mintettes; including these transactions into own lower-level block and providing to the user evidence that the transaction will be included in the higher-level block; providing lower-level blocks to the central bank for forming higher-level block. NB: there is no direct interaction between mintettes, but they have cross-hashing for their lower level blocks. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 9 / 41
  10. 10. Functions of each participant in RSCoin (III) user: requesting evidence of double-spending absence from sender’s mintettes; sending that evedence to receiver’s mintettes and obtaining confirmation that the transaction will be included in the higher-level block; Users’ transactions are divided between mintettes into ”shards”, each transactions is served by several mintettes. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 10 / 41
  11. 11. Simplified model of RSCoin transactions Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 11 / 41
  12. 12. Including only valid transactions in the next block each (honest) mintette verifies all transactions provided by user; only valid transactions will be included to its lower-level block; a central bank receives cross-hashed lower-level blocks from mintettes and forms higher-level block; each user has the evidence from the mintette(s) (with digital signature) that the transaction will be included in the higher-level block. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 12 / 41
  13. 13. Incentivizing mintettes for active participation reward fees for transactions; special coin generation transactions (cf.: block mining reward in Bitcoin) allowed by a central bank. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 13 / 41
  14. 14. Key integrity properties no double-spending; non-repudiable sealing; timed personal audits; universal audits; exposed inactivity. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 14 / 41
  15. 15. Consensus parties for each transaction a user; mintettes of input (sender) address; mintettes of output (receiver) address; the central bank. NB: consensus is reached by some subsets of mintettes with the central bank arbitration (not by the whole network like in Bitcoin) Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 15 / 41
  16. 16. General properties of RSCoin a framework that allows any central bank to deploy their own cryptocurrency; full control over monetary supply, its visibility for the central bank more visible transactions on shares, derivatives, etc.; scalability and fast transaction approval: adding mintettes allows linear scaling; simulation by authors of the paper gives that 30 mintettes process approx. 2000 trans/sec (cf. 7 trans/sec for Bitcoin); no wasted resources (electricity, etc.) with proof-of-work; the central bank is always assumed to be honest; a cross-hashed transaction low-level ledgers from mintettes; it may be invisible to users (or visible if it is allowed by the central bank); Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 16 / 41
  17. 17. Haskell implementation of RSCoin Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 17 / 41
  18. 18. Current implementation Followed by Dr. Danezis and Dr. Meiklejohn work Close to paper as much as possible Implemented everything from scratch Haskell as programming language Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 18 / 41
  19. 19. Why haskell? Industrial applicability Ease of implementation of academic papers Strong guarantees during the compilation QuickCheck as testing framework authored by Dr. Hughes generic testing of distributed systems by Konstantin Ivanov of ITMO University with help of David Turner Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 19 / 41
  20. 20. Codebase Open: https://github.com/input-output-hk/rscoin-haskell ≈ 900 commits, 6 contributors Clean Hackable Decoupled Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 20 / 41
  21. 21. Implementation details (technologies) MsgPack-RPC for communication debuggable binary protocol our team developed a patch Blake2b for hashing ED25519 for signing acid-state as persistence layer conduit as streaming data processing Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 21 / 41
  22. 22. Performance Benchmarking, profiling, tuning, tweaking, etc. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 22 / 41
  23. 23. Performance pitfalls Networking (lots of communication due to protocol) Haskell-related (immutability, GC) IO (database) Threads (context switches, locks) Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 23 / 41
  24. 24. Approach (1 / 2) Tuning GC with right RTS options Persistence almost as fast as memory-based Fast libraries (text, bytestring, unordered-containers, vector, pqueue, etc.) Strictness Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 24 / 41
  25. 25. Approach (2 / 2) Green threads over native ones stm for transactions
  26. 26. Profiling tools Compiler and RTS options ghc-prof-flamegraph & FlameGraph ThreadScope for OS threads ghc-events-analyze for green threads criterion for pure functions strace Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 26 / 41
  27. 27. Benchmark conditions and results (1) Serokell version: 1 computer, 4 cores 1 bank 1 mintette 2 users (2000 transaction total) 760 TPS (transactions per second) Paper (Danezis) version: Amazon EC2 t2.microinstances 25 users 5-30 mintettes 9 mintettes: ≈ 760 TPS 1 mintette: ≈ 400 TPS Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 27 / 41
  28. 28. Further development of RSCoin Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 28 / 41
  29. 29. Open questions of RSCoin (I) 1 Mintettes incentive procedure for fair fee distribution. The need to take into account mintettes activity both from input and output shards, with condition of unreliable (delayed) physical network and possibly of users’ software dishonest behaviour. 2 Mintette incentive for their investments to infrastructure for providing better service. Building own reliable data center with reserved high-speed internet channels, etc. should definitely give possibility to maximize mintette profit. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 29 / 41
  30. 30. Open questions of RSCoin (II) 3 Potentially long time between the periods for a high-level block generation by the central bank. Merging all lower-level blocks from mintettes requires removal many duplicated records of transactions, that needs many sequential operations and cannot be fully run in parallel. 4 Variants for further increasing attack complexity of double-spent transactions. As in RSCoin there are no transaction ledger forks and network votes for selection one of them, a double-spent transaction, if it appears, may be removed by administrative means of the central bank only. Complexity of such attacks may be additionally increased (comparing to the current model where the majority of some shard mintettes are dishonest ones). Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 30 / 41
  31. 31. Potential weaknesses of the RSCoin current version (the worst case scenario) The system may not have its best performance. There is no principal advantage for mintettes which invest into infrastructure. Not clearly defined procedure for mintette rewards might lead to (being presented as network transport problems): user’s software may infiltrate competitive mintettes replies, decreasing their income (in case when user’s software implemented by a company affiliated with some mintette). Problems with transparent investigation of mentioned cases. Presence of dishonest officials in the central bank might help to hide unfair competition. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 31 / 41
  32. 32. Proposed further features for RSCoin Mintette rewards clear procedure with possibility for transparent control of the competition fairness (not involving administrative requests to the bank, etc.) Additional info needed to check the competition fairness should be automatically included to the ledger. Transparent transaction ledger obligatory available to all mintettes. For the current version of RSCoin, the central bank may share UTXO for specific shards only (not revealing high-level blocks), and it will be enough to have normal work of the system. High-level block is produced by mintettes. For a rather long period involving millions of transactions, merging of lower-level blocks by the central bank may require significant time, delaying the next period. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 32 / 41
  33. 33. Proposal for further RSCoin development High-level block is formed by mintettes (based on RSCoin-like and BitShares-like procedure) and only signed by the central bank. The system becomes transparent (mintettes have access to the transaction ledger in any case) and a new period is not delayed by the bank due lower-level blocks merging procedure. Introducing mintette ”veto” on transactions. As all mintettes are authorized by the bank and may be penalized by it, such a feature increases attack complexity for double-spent transaction be included in the high-level block. User software includes mintettes replies obligatory preserving their order. This feature allows to select the fastest mintettes to get addtional reward. If users’ software returns list of incorrect order, it can be easily revealed by simple analysis. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 33 / 41
  34. 34. High-level block is formed by mintettes It is introduced another layer of mintettes forming high-level block. Output (receiver) mintettes on confirming user’s transaction not only include it into their lower-level block, but also spread it among the shard of ”high-level” mintettes (like users do). Such a ”high-level” mintette: having enough confirmations for a consensus among output (receiver) mintettes, send the transaction to the current ”witness” mintette for including into the high-level block (obligatory preserving confirmation list order); being a ”witness” in its turn, collect transactions from other mintettes and form a high-level block (in predefined order, like in BitShares), spreading the new block among other mintettes; The central bank just take transactions from high-level block (skipping replies from sender and receiver mintettes, etc.) and signs such a block. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 34 / 41
  35. 35. Advantages of forming high-levels block by mintettes The system running improved cryptocurrency: has obligatory transparency for ”high-level” mintettes in all cases, they need all transactions, which, in turn, have a lot of additional info from users and mintettes; the fair competition may be easily verified by any ”high-level” mintette; remains easily scalable; may produce high-level blocks with required frequency (e.g., 1 per second); does not lead to delays from the central bank between periods. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 35 / 41
  36. 36. Introducing mintette ”veto” on transactions All mintettes are authorized by the bank and required to have honest behaviour. A single contradiction among mintettes means misbehaviour (not processing the last block for UTXO update) or attempt to work against rules by some mintette(s). A transaction with at least one ”veto” vote is blocked, and send to the central bank for the investigation for penalizing dishonest participants and rewarding honest. Application of RSCoin by commercial companies may additionally include security deposits from mintettes for penalizing and assurance policy. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 36 / 41
  37. 37. Advantages of mintette ”veto” on transactions Attack difficulty of double-spent transaction to be included in high-level block increases. An attacker must create a transaction where a majority of mintettes are dishonest (to the rest of honest it is not sent); such a statistics where there are a few confirmations from sender mintettes may be additionally verified by receiver mintette as suspicious, that also increases attack difficulty; attacker must also take into account the majority of receiver shard; or all sender mintettes are dishonest; the number of collaborating dishonest mintettets increases as the attack difficulty. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 37 / 41
  38. 38. User software includes mintettes replies obligatory preserving their order The fastest mintettes will statistically appear to be first in most transactions. The central bank pays additional bonus to mintettes which faster serve users (e.g., to 33% of the fastest mintettes). It creates an incentive for mintettes to invest into their infrastructure for providing better service. Dishonest user software can be easily revealed by analyzing statistics in transaction ledger (by comparing replies from different user software clients working at the same network provider). The same principle is also applied to output mintettes. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 38 / 41
  39. 39. Advantages of obligatory preserving order of mintettes replies mintette incentive to create the best infrastructure for fastest processing of users’ requests (the central bank reward); combined with transparent transaction ledger, it allows verification of competition fairness to any participant (”high-level” mintette); dishonest users’ software is easily revealed by statistical analysis of the ledger, as well as to collect the direct evidence by analysis of input and output traffic. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 39 / 41
  40. 40. Additional properties of RSCoin with implemented proposals Mintettes’ incentive to invest to infrastructure for providing the best service. Transparent fee distribution among mintettes, easily verifiable by any participant (”high-level” mintettes). The central bank dictates its rules, but every participant may verify if everyone follows them, not depending on official investigation by the bank. High-speed of high-level block production, remaining highly-scalable. No significant delay before starting a new period by the central bank. Increased difficulty of double-spending attacks. All key integrity properties of the current version of RSCoin remain valid. Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 40 / 41
  41. 41. IOHK CASCADING DISRUPTION Roman Oliynykov, Arseniy Seroka, Jonn Mostovoy The RSCoin framework 41 / 41

×