UPTEC F 17041 Examensarbete 30 hp Juli 2017

Distributed ledger technology in the capital market Shared versus private information in a permissioned blockchain

Alessandro Piccolo

Abstract Distributed ledger technology in the capital market

Alessandro Piccolo

Teknisk- naturvetenskaplig fakultet UTH-enheten This master thesis explores how blockchain technologies can be utilized within the financial sector with focus on how to store both private and Besöksadress: public information on the blockchain. The capital market is looking into Ångströmlaboratoriet Lägerhyddsvägen 1 ways of cutting down administrative work through streamlining the financial Hus 4, Plan 0 process by using blockchain technologies. Public key encryption together with hash functions and a consensus mechanism make up the basis for creating Postadress: a shared trustless database system. The thesis was conducted by extensive Box 536 751 21 Uppsala research concerning cryptographic topics, and a literature study was made to compare existing solutions. This was done in order to come up with a new Telefon: design which suggests how to utilize blockchain technologies in order to 018 – 471 30 03 create private transactions. The design solves issues regarding key

Telefax: management and how to handle both private and public information on the 018 – 471 30 00 blockchain. The proposed design is an extension of Visigon's existing permissioned blockchain, and it introduces different roles within the peer Hemsida: to peer network as well as a concept of having regulating nodes that http://www.teknat.uu.se/student together with the involved bank's nodes handle the process of private transactions. Private transactions are encrypted by using symmetric keys and thereafter recorded on the blockchain. In conclusion blockchain technology might not be the most suitable database system for banks to keep transactions private. Future solutions should consider the best attributes of blockchain technologies and create a new system with the single purpose of being a tool for the financial market.

Handledare: Gustav Ekeblad Ämnesgranskare: Tjark Weber Examinator: Tomas Nyberg ISSN: 1401-5757, UPTEC F 17041

Popul¨arvetenskaplig sammanfattning

Detta examensarbete ¨ar gjort i samarbete med Visigon f¨or att b¨attre kunna f¨orst˚a hur man kan lagra b˚adeprivat och publik finansiell information med hj¨alp av block- kedjeteknik. Syftet med blockkedjeteknik f¨or banker ¨ar att revolutionera post-trade delen av deras system f¨or att minska administrativa kostnader och s¨akerhetsst¨alla att alla banker har samma ¨overblick av det finansiella landskapet.

Examensarbetet fokuserar p˚ahur banker inom den den nordiska kapitalmarkna- den kan nyttja blockkedjeteknik f¨or att lagra tillg˚angari en gemensam databas. Blockkedjeteknik ¨ar en distribuerad databas som garanterar att lagrad data ¨ar of¨or¨anderlig, vilket inneb¨ar att de som delar p˚adatabasen inte beh¨over ta h¨ansyn till att n˚agonskulle kunna ¨andra p˚abefintlig information. Blockkedjetekniken kan komma att ers¨atta bepr¨ovade tekniker inom transaktionshantering som f¨or exem- pelvis v¨arde-pappershandel. F¨or att en transaktion ska bli lagrad p˚ablockkedjan s˚askall transaktionen f¨orst godk¨annas av majoriteten av bankkonsortiet som styr blockkedjan.

Andra anv¨andningsomr˚adenf¨or blockkedjeteknik ¨ar vid lagring av personliga upp- gifter s˚asomID, e-H¨alsa, kontrakt och l˚an.Det finns ¨aven m¨ojlighet att sk¨ota micro-transaktioner mellan maskiner.

Ett krav som banker har ¨ar m¨ojligheten att d¨olja inneh˚alletav en transaktion f¨or andra deltagare i n¨atverket. Detta medf¨or sv˚arigheter,d˚ablockkedjetekniken ¨ar designad med ¨andam˚aletatt all information skall vara publik f¨or de involve- rade akt¨orerna. Examensarbetets syfte ¨ar att unders¨oka alternativa l¨osningar och f¨oresl˚aen design p˚ahur detta problem kan l¨osas. Designen grundar sig p˚as¨aker kommunikationsprotokoll och kryptografi.

Avslutningsvis ¨ar slutsatsen att blockkedjeteknik har m¨ojligheten att vara kataly- satorn f¨or att skapa ett nytt paradigm f¨or hur vi hanterar och lagrar information.

Contents

1 Introduction 1 1.1 Problem Discussion ...... 2 1.2 Objective & Research Questions ...... 2 1.3 Methodology ...... 3

2 Background 4 2.1 Basic Cryptography ...... 4 2.2 Bitcoin Overview ...... 5 2.3 Bitcoin Cryptography ...... 6 2.4 Bitcoin Transactions ...... 7 2.5 Consensus ...... 8 2.6 Merkle Tree ...... 9 2.7 Forks ...... 9 2.8 Double Spending Attacks ...... 10 2.9 Permissioned Chains ...... 11

3 Theory 11 3.1 Smart Contracts ...... 12 3.2 Merkle-Patricia Trie ...... 13 3.3 Advanced Cryptography ...... 14 3.3.1 RSA ...... 15 3.3.2 Elliptic Curve Cryptography ...... 16 3.3.3 Lamport Signature ...... 18 3.3.4 Paillier Cryptosystem ...... 19 3.4 Future Solutions ...... 19 3.4.1 Cryptographic Obfuscation ...... 19 3.4.2 Zero-Knowledge Proof ...... 20 3.4.3 Bitcoin: Account Linking Problem ...... 20 3.4.4 Ring Signature ...... 20 3.4.5 Homomorphic Encryption ...... 21 3.5 Key-Management ...... 21 3.5.1 Wallet ...... 21 3.5.2 Flooding ...... 21 3.5.3 Bitmessage ...... 21 3.5.4 Internet Certificate ...... 22 3.5.5 Secure Sockets Layer & Transport Layer Security ...... 23 4 Literature Review 23 4.1 Ethereum ...... 24 4.2 Quorum ...... 25 4.3 Corda ...... 27 4.4 Ripple ...... 28

5 Design 30 5.1 Visigon’s Blockchain Project ...... 30 5.2 Design Aims & Requirements ...... 32 5.3 Design Choices ...... 33 5.3.1 Observer, Voter, Creator & Regulating Nodes ...... 33 5.3.2 Account & Storage Sharding ...... 34 5.3.3 Public & Private Transactions ...... 35 5.3.4 Transaction & Block information ...... 35 5.3.5 Transaction Process ...... 36 5.3.6 Consensus ...... 37 5.3.7 Key Management ...... 38 5.3.8 Malicious Attacks ...... 40

6 Discussion 41 6.1 Existing projects ...... 41 6.1.1 Bitcoin ...... 42 6.1.2 Ethereum ...... 42 6.1.3 Quorum ...... 42 6.1.4 Corda ...... 43 6.1.5 Ripple ...... 44 6.1.6 Comparison between Design Choices ...... 45 6.2 Proposed Design ...... 48 6.2.1 Main Design Features ...... 48 6.2.2 Difficulties & Trade-Offs ...... 49

7 Conclusions 50 1 Introduction

The Nordic capital market uses a centralized backend system for keeping track of transactions and who owns what. This system requires a huge amount of adminis- trative work to function properly. The administrative process can be automated by using a technology called blockchain, which is a trustless distributed ledger tech- nology. It is estimated that a decentralized database system such as blockchain would save banks up to 10 billion dollars annually, due to the fact that processes would be streamlined which in its turn reduce administrative work [42]. This is a conservative estimate and there are those who claim that it can cut costs even more [35]. However, the system is not truly trustless since it requires some level of trust by the user in the system. Blockchain technology has the possibility to be the next disruptive technology, which could be used for any type of data storage.

The current financial system depends on a central security deposit as shown in Figure 1 for data access and storage. This thesis suggests that the Nordic capital market should use a permissioned blockchain which would imply that only a small number of appointed major banks and institutes would manage the blockchain, in contrast to the popular technology that the cryptocurrency Bitcoin uses. Ba- sically, the peer to peer (P2P) network would facilitate data access by reducing administarive work [36].

Figure 1: The left side represents the financial market with a centralized database, the central security deposit in the center. The right side shows a financial market using a distributed P2P ledger technology. The information flow is displayed by the connecting lines.

1 1.1 Problem Discussion Blockchain technology offers a solution to the problem of knowing that different databases are synchronized. The current financial market can be viewed in more detail in Figure 2 and the same market using an integrated blockchain can be seen in Figure 3. A permissioned blockchain has great potential in cutting down admin- istrative work. Although, there are technical difficulties that needs to be resolved before a revolution in the financial market can occur. One of these problems is that banks want to keep some data private from other actors in the blockchain. The original blockchain technology, created by the Bitcoin founder, provides trans- parency which is an unwanted attribute for the financial market.

Figure 2: The current system for trading assets. The red, blue and orange repre- sents agents, principals and exchange platforms respectively.

1.2 Objective & Research Questions This thesis focuses on the Nordic capital market and discuss questions such as, how can distributed ledger technology store both public and private information. Other questions are, what data should be shared among participants and what data should be private, aspects regarding key management and technical methods for reporting to authorities.

2 Figure 3: The permissioned blockchain overview system that would replace the current system. The red, blue and orange represents agents, principals and ex- change platforms respectively.

1.3 Methodology The information gathering for this thesis has been done through extensive research about the subject as well as a literature review to understand current solutions to how to store both public and private information on the blockchain. This thesis also proposes guidelines of how Visigon can adapt their current blockchain plat- form to the capital market.

The first topic of the thesis is to give the reader an overview of how Bitcoin’s blockchain architecture works. It looks into topics such as the transaction process, consensus mechanism, how to handle forks, double spending attacks, immutability through hashes and permissioned chains. The following section is about advanced concepts such as smart contracts, Merkle-Patricia trie, different encryption meth- ods, key-management and Internet certificates. Thereon, a literature review of existing solutions on how to hide private information on the blockchain is intro- duced. This in turn makes it easier to understand the proposed design choices. Lastly, the discussion and conclusion discuss the design choices and whether or not blockchains are an appropriate database for the financial sector.

3 2 Background

The following sections will give the reader an extensive overview of the Bitcoin architecture, such that the reader can truly understand the concept of blockchain technologies and the challenges that the financial market is facing.

2.1 Basic Cryptography This section will start by explaining some simple theory about cryptography, which will be useful for understanding blockchains better. In cryptography the plaintext refers to the information in its normal form denoted by variable m, while the ciphertext or cryptogram, which is the transformed plaintext, is denoted by z. Encryption works by taking a message and apply a mathematical operation to it, which in turn yields a random-looking ciphertext.

Symmetric key is when only one key is used for both encryption and decryption. Even more interesting the asymmetric key pairs, also called public key encryption, which in contrast have an encryption key and a decryption key. The one-way func- tion is one of the main pillars of cryptography. The function is defined by being easy to compute but computationally hard to reverse. Public key encryption is based on one-way functions [12].

A hash function, h(m), is a one-way function that generates a unique output given a random sized input. The output is deterministic for a given input since it follows a certain algorithm. The hash function’s output should be unique for each unique given input, this implies that two different messages should not have the same output. Given m1 6= m2 then equation (1) should not uphold or it should at least be hard to find such an example. Such examples are called collisions. Variable x in equation 1 denotes the fixed output bit sequence of the hash function.

h(m2) = h(m1) = x (1) Digital signatures can be achieved by using a signature function, S, together with the hash of a plaintext and a private key. The signature is denoted by variable s and the private key is represented by kprivate. The hash is encrypted with the private key.

S(kprivate, z) = s (2) The receiver can verify the signature by using a verification function which depends on the signature and the public key kpublic. Basically, the receiver can validate the signature by decrypting the signature using the public key. The result should be

4 the hash of the signed message for the signature to be valid. It is important that one should not be able to forge a signature of a message m by using brute force. For the signature to be valid, equation 3 needs to be true.

V (kpublic, s) = z (3)

2.2 Bitcoin Overview The technology behind Bitcoin is called blockchain which is built upon a peer- to-peer network. A blockchain is built out of blocks that contains transactions, meaning that each transaction ever made is stored in a block on the blockchain. The block header consists of the block’s hash, previous block hash, block time stamp and data regarding the different transactions such as the sender, the re- ceiver, the amount of Bitcoins to transfer and a transaction time stamp. The current Bitcoin’s blockchain is 100 GB with a total of 5 · 105 blocks with a new block added to the chain every 8 minutes (2016-01-28) [8]. Each block is linked to the previous block through cryptography using a hash function called SHA256. The hash-linkage outputs a unique sequence of hashes which means that a small alteration within a block will propagate through the subsequent blocks modifying the successive hash sequence. This in turn makes it easy to keep track of different versions and identify fraudulent blockchains [32]. More details about the different cryptographic techniques used in blockchain are discussed in section 2.3.

The process of getting a new block on the blockchain starts with a user, often called miner, in the Bitcoin network selecting a number of valid transactions into a block. Valid transactions are where the sender controls enough assets. The sender needs to prove that he possesses these assets by creating a cryptographic signature using the corresponding private key of the asset. The miner validates the transactions against his own local version of the blockchain [28]. The miner needs to win the mining process to put up the newly created block on the blockchain. The mining process is a part of the Proof of Work consensus algorithm that Bitcoin uses. The winner of the mining process gets to broadcast the block to the rest of the network. This is done in a way that not a single miner can put up several malicious blocks on the blockchain [10].

The miner enters the mining process by hashing the transaction data together with the previous block’s hash and by adding a random integer called nonce (number used once). The winner is the miner who gets a hashed output value, in hexadec- imal, that is lower than a certain threshold. Moreover, the miner can increase his odds by changing the nonce value and recomputing the hash. The probability of winning the mining process is proportional to the relative computational power

5 the miner owns in comparison to the rest of the network. The mining process also prevents Sybil attacks. The Sybil attack tries to overtake a reputation system such as voting, by creating multiple users hence gaining more influence. As of today, in average it requires approximately 269 hashes for a block to be put up on the blockchain [14]. The required average number of hash operations will increase since hardware become more efficient at computing the hash of the block. The threshold is adjusted so that the creation of a block takes roughly ten minutes, the difficulty becomes harder with a lower threshold. The winner will get all transactions fees within the block as well as some newly created Bitcoins. The amount of newly created Bitcoin is going down and the creation of new Bitcoins will cease to exist in 2140 [2]. The blocks also store a timestamp for each transaction which enforces a strict chronological order. This means that transactions can not be removed from the blockchain and that each Bitcoin in the transaction is only spent once. The main purpose of the mining process is to prevent double spending attacks which is explain in further detail in section 2.8 [44].

Data that is on the blockchain can not be removed or altered since it would change the block’s hash which would then invalidate all following blocks’ hashes. This link- ing system makes the blockchain robust against changes in the blockchain. This system also makes it easy to detect faulty nodes to prevent Byzantine failures. These failures occurs when a malicious miners tries to overtake or disrupt the sys- tem [25]. Although, a transaction is not truly considered to be valid until at least five additional blocks have been put on the longest fork. Forks are explained in section 2.7 [9].

The Bitcoin process can be simplified and summarized with the following steps. All nodes select a couple of transactions from a pool of unconfirmed transactions to put in their block, and validate them against their own blockchain. Each miner tries to solve a difficult mathematical problem for its block. The winning block is put up on the network if the transactions are valid and not already spent. The other nodes validates the winning block and is subsequently appended to the blockchain. The recently approved block’s hash is going to be used by the miners in the following mining process.

2.3 Bitcoin Cryptography Bitcoin uses a one-way hash function called SHA256 which stands for Secure Hash Algorithm 256 bit during the mining process. Computing the plaintext of the hash is computationally infeasible.

6 For a transaction to be valid it needs to go through a certain protocol. A transac- tion requires a public key, a private key and a Bitcoin address which works as an unique identifier. The private key is generated from a large random number. The private key is normally a 256 bit in hexadecimal which is 32 bytes or 64 characters in range from 0-9 or A-F. The public key is generated by using a method called Elliptic Curve Digital Signature algorithm (ECDSA) from the private key (which is a large random number). The Bitcoin address is then generated by hashing the public key using SHA256 or RIPEMD160 and then using a custom Base58Check encoding. This public key is used to verify the signature on a transaction [40].

Figure 4: Public and private key transformation as well as how to generate the Bitcoin address.

Each bitcoin (the coin) is represented by a Bitcoin address. The ownership of a bitcoin is confirmed by the owner creating a signature using ECDSA which uses elliptic curve arithmetic on the message, the corresponding private key, and a random number. The signature can be validated by any user using elliptic curve arithmetic together with the public key. The private key is essential in keeping track of Bitcoin ownership and is therefore important to be kept secret to avoid theft. The signature depends on the unique transactions plaintext which makes it impossible to use the same signature twice [33][38].

2.4 Bitcoin Transactions Transactions might have several inputs and outputs. Inputs are previous transac- tion output addresses that are owned by the sender, and outputs are the receivers’ Bitcoin addresses together with the amount to be transferred, as can be seen in Figure 5. All the supplied Bitcoins in a transaction need to be unspent. Unspent Bitcoins can be looked up by searching through the blockchain for references to your Bitcoin address. Each Bitcoin address used as input needs to be consumed (a Bitcoin address can represent any number of Bitcoins), hence if the sender has a surplus of input Bitcoins then the sender needs to add another Bitcoin address

7 which the sender owns in the output receiving field. Transactions should also include fees so that the miner will have an incentive to mine it [44].

Figure 5: Shows what inputs and outputs are needed for Alice to pay Bob 7, 0 BTC.

Complete anonymity cannot be achieved even if new key pairs are generated for each transaction, since there will be linkage in transactions as seen in Figure 5 which would reveal that the transaction sender owns certain Bitcoin addresses. There are storage and key-management programs called wallet, used for storing multiple Bitcoin addresses and respective private and public keys. The private key is stored in a Wallet Import Format by using a custom Base58Check encoding in order to make it easier to copy [28]. Base58Check stands for Base 58 binary-to-text encoding which is used for encoding byte arrays into strings that are easy to type. Basically, Base58Check is used to improve the user experience.

2.5 Consensus The consensus protocol’s purpose is to enforce a chronological order on the blockchain. It allows different nodes on the network to agree on the state of the system. Proto- cols are usually categorized as being probabilistic or deterministic. A deterministic protocol does not produce any forks, since it has a fast block finalization. There are different kinds of protocols depending on factors, such as if the blockchain is

8 public or private. Some consensus protocols are Proof-of-Work (Bitcoin mining), Proof-of-Stake, Practical Byzantine Fault Tolerance protocol and deterministic voting system [6][28].

Different kinds of consensus models require different degrees of computational work. Proof-of-Work protocol impacts the climate negatively due to it requiring a lot of electricity. A conservative estimated power consumption average of the Bitcoin mining network in October 2013 was 1 MW [29]. By 2020 it is estimated that it will consume as much as Denmark [14]. The carbon dioxide footprint will eventually become too large to be economically and environmentally sustainable. It is therefore important to reach consensus in an environmentally friendly way. An additional complication with the mining process is that mining companies move to places with low electricity costs, which creates unforeseen geopolitical complexities.

2.6 Merkle Tree The Merkle tree is a binary tree used in Bitcoin as a validation method for pre- venting alterations of transactions within a block. Each transaction within a block is hashed, which serves as the transaction ID. All of the transactions will be paired up and the combined ID will be hashed once again as seen in Figure 6. This pro- cess is repeated until there is but one node left, the Merkle root, and hence we have created a Merkle tree. Now, if you would try to tamper with a transaction it would change the transaction ID and the ripple effect would successively also alter the Merkle root, invalidating the entire block [27].

2.7 Forks Forking happens when two nodes want to put their block on the blockchain si- multaneously. This could happen in the Bitcoin network when two miners solve the hash problem at the same time. Both miners will put their winning block on their version of the blockchain and broadcast it to the rest of the network. This will result in two versions of the blockchain, let’s call them version A and B, both versions are going to coexist temporarily on the network until the fork can be resolved. Miners will receive either one of the versions and continue working as usual. The subsequent block that is put up on the blockchain will determine which version to keep. If the next block that is put up on the blockchain belongs to version A, then version B will be discarded. Transactions in blocks that were put on the invalidated blockchain, and do not exist in version A, will be returned to the pool of pending transactions.

9 Figure 6: The Merkle tree consists of combinations of multiple hashed transactions as node leafs. The h(ti) represents transaction i being hashed.

The blockchain has a scoring algorithm such that users can keep track of which blockchain version to work on. In general, the blockchain with the most number of blocks will be considered to be the best, since it has required the most compu- tational work to create. The incentive to overwrite previous blocks becomes less due to the scoring algorithm. The probability of a block being superseded goes down exponentially as more blocks are put up on the blockchain. A miner that receives a broadcast sharing that a higher scoring version of the blockchain exists, will simply switch to that blockchain version [44].

2.8 Double Spending Attacks Double spending happens when a malicious user tries to spend the same coin twice. There are different ways that the Bitcoin systems handle these malicious attacks.

One example of a double spending attack is an addition of two transactions in a block that use the same Bitcoins. However, this is easily detected by other users. Another attack is for Eve (malicious user), in order to send two transactions that use the same Bitcoins to different miners. This attack is prevented since the transactions will have different timestamps. Alice could also try to send out a payment to Bob, and simultaneously send the same amount back to another account controlled by her. She could then try to fork the blockchain and mine faster than the main blockchain. This is computationally costly since she has to mine several blocks in a row. If Alice controls 50% of the computational power

10 of the mining network, the probability for Alice to mine five blocks in a row is 0.55 ≈ 3 % which is a low chance of success for Alice [22]. The Blockchain robustness, due to the hash linkage in combination with time-stamping, makes it difficult to do double spend attacks.

2.9 Permissioned Chains Permissioned blockchains, also called private blockchains, are an oligopoly of who controls the blockchain. Only a selected number of parties have access to create and validate blocks. This would imply that users of the blockchain would have to trust these operating nodes since they have the absolute control over the consensus process. Read and write permissions can also vary for different users, and some users might be pure observers. Permissioned blockchains might prove beneficial for the capital market since it would allow centralized control from a selected number of major banks with regulatory bodies overseeing transactions. Financial trans- actions need to be supervised by regulators and other such authorities in order to prevent fraud and ensure the collection of taxes according to the law. Some regulators in the Swedish capital market are Euroclear and VPC, which keep track of administrative tasks for the stock market [43][14].

Permissioned blockchains are more susceptible to hacker attacks since there are only a few central nodes of power. However, in the example of the capital mar- kets, these operating nodes would be managed by major banks with extensive security protocols. Another problem would be if a major bank would become ma- licious, what would happen then [14]?

Open blockchains have a scalar advantage, since they will generally have a larger number of nodes which in its turn implies a more rigorous block validation. Fur- thermore, the scalability would be improved for a permissioned blockchain, since features such as Proof-of-Work could be replaced by simply stating that a block will be created with an even interval [14]. Nodes within the network could follow a certain protocol stating which node’s turn it is. This approach, in comparison with the Proof-of-Work consensus used in Bitcoin mining, would also be less harmful to the environment, see section 2.5.

3 Theory

The following subsections introduce concepts more in depth such as solutions and problems concerning blockchain technologies in the financial market, in order for the reader to understand the proposed design.

11 3.1 Smart Contracts Smart contracts, also called Blockchain 2.0, are enforced trustless contracts which eliminates any ambiguities by enforcing certain rules by coding it into the blockchain architecture. A smart contract is simply code stored on the blockchain that is trig- gered by a transaction and is made for facilitating and automating processes even further. Some areas of application are financial derivatives such as options, differ- ent kinds of stock emission, automated tax collection, intellectual property, legal contracts (also called smart legal contracts), handle access control to shared ac- counts, machine-to-machine commerce such as a washer buying its own detergent and so on [27].

Smart contracts are not only beneficial for automation, but they also solve the problem of what a script is actually executing, since normally one can only see the input and output of a program. Smart contracts enable all the nodes in the network to keep track of every single computation by nesting logic and data into the blockchain [15]. The Bitcoin protocols support some of these features, such as multisig (when a transaction requires multiple signatures to be valid) but lack Turing-completeness. A system of data manipulation rules is Turing-complete such as the computer’s instruction set.

This feature ensures that parties, that do not trust each other, uphold the terms that they have agreed on. Smart contracts can also be used in order to assure third parties that the contract has been fulfilled. New data can be given the smart contract through the transaction message.

Information that smart contracts use should be deterministic, such as that all nodes within the system use the same data. For example it is problematic if one were to create an insurance contract that depends on the weather, since the weather is not deterministic. A way around this issue would be to use a trusted source, an oracle which would store the right information on the blockchain. Then again this implicitly undermines the goal of a decentralized system.

Smart contracts can not be updated directly since blockchains are immutable. There are ways to circumvent this issue such as to use a versioning system or an entryway contract that forwards the call to the most recent contract version.

The most widespread smart contract platform out on the market, is the Ethereum blockchain which is discussed more in depth in section 4.1, but there are also smaller platforms such as Ripple’s project called Codius [40].

12 3.2 Merkle-Patricia Trie Ethereum and Quorum use a combination of Merkle tree and Patrice trie (a trie is also called a digital tree, radix tree or prefix tree), in order to store the balance of accounts (account states). The trie is a key value map where the key is the address, and value is the amount that each address contains. The easiest way of explaining the trie is by looking at Figure 7. Basically, each node can have sixteen children (nibbles) due to using a hexadecimal base. The hashing algorithm KECCAK256 is used for the root hash so that the trie gets a cryptographic fingerprint, meanwhile the storage structure resembles a Patrice tire [27]. The hash sum is not dependent on the order of updates but on the actual data. The trie is O(log(n)) efficient for inserts, lookups and deletes as the depth of the tree is bounded.

Figure 7: Overview of the Merkle-Patricia trie as explained in the Ethereum Project Yellow Paper. source: Lee Thomas [1]

13 3.3 Advanced Cryptography One of the main problems with cryptography is secure key distribution, which was partially solved by Martin Edward Hellman in cooperation with Whitfield Diffie. They published an article in 1976 called ”New Directions in Cryptogra- phy”. The article proposed a new method for distributing cryptographic keys, called the Diffie–Hellman key exchange. This article made the cryptographic com- munity boom and a new class of keys known as asymmetric keys was introduced shortly thereafter.

The Diffie–Hellman key exchange is easily explained through a practical numeri- cal example. This example will use the basics of RSA encryption which in turn uses a one-way function (easy in one direction and hard to reverse) and modular arithmetic.

3x mod 17 (4) Will yield a number in between [0, 16]. This is also a trap-door function, since it is easy to compute the solution knowing x but hard to find x knowing the solution. Hence, 315 mod 17 ≡ 6 is easy to compute meanwhile finding x from 3x mod 17 ≡ 6 is difficult. Example, Alice chooses a private number x = 15 and calculates 315 mod 17 ≡ 6 and sends it to Bob. Bob goes through the same procedure, x = 13 and sends the solution 313 mod 17 ≡ 12 to Alice. Alice and Bob respectively compute the following equations.

Alice : 1215 mod 17 ≡ 10 (5) Bob : 613 mod 17 ≡ 10 (6)

Which proves that they have reached the same hidden number [13]. The math behind this is explained in section 3.3.1. Equations (6) triple equal sign stands for a congruence relation which is explained as A ≡ B mod C is equal to A mod C = B mod C.

The upcoming sections will introduce concepts such as public and private key encryption through RSA and Elliptic Curve Signature as well as future develop- ments in cryptography and finally key management methods such as Bitmessage and different Internet protocols.

14 3.3.1 RSA RSA public key encryption is based on modular arithmetics. The first thing to do in order to create a key pair is to select a maximum large number as arithmetic modulo. Any calculation that results in a number larger than the maximum gets wrapped around to a number in the valid range, this also prevents truncation er- rors. In RSA encryption the maximum number is derived from multiplying two random prime numbers. The private key is derived from the two prime numbers together with the public key. The public key is chosen at random in the positive interval.

The base of RSA encryption and decryption is stated in equation (7)-(10). De- noting the plain text as m, ciphertext z, public key x, private key y and with the modular base set to the maximum number n. The private key equation can be derived from equation (10) by modifying the Euler’s theorem.

mx mod n ≡ z (7) zy mod n ≡ m (8) ⇒ (mx mod n)y mod n ≡ m (9) ⇔ mxy mod n ≡ m (10)

The base modular number is calculated by multiplying two random prime num- bers, p1 · p2 = n. Prime factorization of large numbers can be computed by using brute force, however, this is computationally costly. Hence it is difficult to com- pute p1 and p2 by only knowing the product, n.

The Euler’s totient function is denoted by φ and is used as the trap-door function of the RSA algorithm. Euler’s totient function calculates the integer k, which is also called totatives of n, in the range 1 ≤ k ≤ n for which the greatest common divisor gcd(n, k) equals to 1. Euler’s totient function of primes is easily calculated by using the following tricks with the variable p being a prime number.

φ(p) = p − 1 (11)

⇒ φ(n) = φ(p1 · p2) = φ(p1) ∗ φ(p2) = (p1 − 1) · (p2 − 1) (12)

Hence, solving φ(n) for a large n number is computationally heavy if the prime factorization is unknown. This is the trap-door trick used by the RSA algorithm. As previously mentioned the private key equation can be derived by the Euler’s theorem theory, which is shown in equation (13).

15 mφ(n) ≡ 1 mod n (13) This theorem requires m and n to be coprime, meaning that the greatest common divisor is 1. A modified version of the equation (13) is used to derive the private key in the RSA encryption.

1k = 1 (14) ⇒ mk·φ(n) ≡ 1 mod n (15) 1 · m = m (16) ⇒ m · mk·φ(n) ≡ 1 · m mod n (17) ⇔ mk·φ(n)+1 ≡ m mod n (18) Comparing equation (10) with (18) gives the equation for the private key (20).

xy = k · φ(n) + 1 (19) k · φ(n) + 1 y = (20) e The public key x has to be a small odd number that does not share the same factor as φ(n). The private key y and the prime numbers p1 and p2 should be hidden. Only the public key and prime product n should be public, since they are used for encryption. Although, RSA encryption might not be the ideal sys- tem for cryptography in the future since there are specialized algorithms that are moderately successful in solving prime factorization, such as the Quadratic Sieve and the General Number Field Sieve. This leads to that the size of the keys needs to become rather large, which is not sustainable for mobile phones and other low powered devices, since they have limited computational power. The conclusion is that the trap-door function needs to be improved [34].

3.3.2 Elliptic Curve Cryptography An elliptic curve is the set of points that solves equation (21). A simplified version of the curve is displayed in Figure 8. Bitcoin uses a specific elliptic curve called secp256k1, with equation y2 = x3 + 7.

y2 = x3 + ax2 + bx + c (21) The solutions are not ellipses, instead the names comes from the integral used when calculating arc length in ellipses. With a, b, c ∈ R equation (22) gives the integral to solve.

16 Figure 8: Elliptic curve representation.

Z b 1 3 2 dx (22) a x + ax + bx + c

Elliptic curves are cryptographically desirable because it is symmetric around the horizontal axis and that any non vertical line will intersect the curve three times. Elliptic curve digital signature is based on dot operations. The operation can be explained by choosing two points on the curve, A and B for instance, and drawing a line in between them. At the third intersection a second horizontal line can be imagined, see the dashed line in Figure 9, which also shows the solution to A dot B = C.

Figure 9: Dot operation, A dot B = C on an elliptic curve.

17 The trapdoor function is based on the fact that it is hard to estimate how many times an initial point is dotted with itself by only knowing the initial position and the final positions. Hence, to figure out the number of dot operations required one would have to redo the dot process, n number of times until the same final position is reached.

Figure 8 shows a simplified version of the elliptic curve, in practice the range is fixed. All numbers above the maximum are folded in similar fashion as in RSA modular arithmetic. The actual trapdoor function is called elliptic curve discrete logarithm function, which is used to calculate the private key from the public key. Firstly, an elliptic curve system needs to define the range and which curve equation to use. Secondly, a public point on the curve needs to be chosen. The private key is the variable n which denotes how many times the dot operation is used. The public key is the final position after the public point has dotted itself n times.

An article made by Lenstra shows that it takes less energy to boil a teaspoon of water than to break a 228-bit RSA key. The energy needed to boil all water on earth would be required to break a 228-bit elliptic curve key, which would be equivalent in using a 2380-bit RSA key [26]. The conclusion is that a smaller key can be used for the same security when using elliptic curve keys. Large RSA keys increase the security but decrease the cryptographic performance as well as an increase in storage making large scale key management cumbersome, this is discussed more in depth in section 5.3.7 [39].

3.3.3 Lamport Signature Quantum computers threaten conventional encryption methods such as RSA, since they are susceptible of brute force attacks. An alternative would be to use the Lam- port algorithm. These keys are difficult to manage since a key can only sign one message if not combined with hash trees.

The Lamport algorithm starts by producing 256 pairs of 256 bit random numbers for the private key. The second step is to create the public key by using a 256 bit hash function on each number individually, resulting in 512 hashes. The size of each key is 16 KiB.

The signing process starts as usual by hashing the message into a 256 bit hash sum. Each bit is encrypted with one out of the 512 numbers that are the private keys. The pair number is chosen in regards to the bits value and the first or second number in the pair is selected depending on whether the bit is zero or one. The 256 times encryption scheme is hence randomized, and the total size of the signature

18 is 256 · 256 = 8 KiB. The unused 256 random numbers should be destroyed and the private key should not be used again.

The signature can be verified by selecting the right 256 public keys in the same manner as explained previously when signing the message. Subsequently, all of the 256 number in the signature should be hashed. The signature is valid if the public key hashes correspond to the hashes of the signature.

There is a O(2n/2) probability of finding a preimage collision of operations under a quantum computing environment on a single execution of a perfect hash. Variable n denotes the bit size of the hash function. Meaning that it is quantum proof, however, its creation time is high due to all the hash functions [24].

3.3.4 Paillier Cryptosystem The Pallier cryptosystem can be used for voting applications. The system sup- ports additive homomorphic encryption which can be explained as the sum of two ciphertexts is equal to the sum of the corresponding plaintexts. It is mathemati- cally explained in equation (23, where z is the ciphertext of the plaintext m with D(x) denoting the decryption function.

D(z1 + z2) = m1 + m2 (23) A secure electronic voting systems could be constructed using the attribute ex- plained in equation (23). Each voter would encrypt their vote (yes or no would be equal to 0 or 1) with the regulators public key. The regulators would take the product of all received encrypted votes and present the solution without revealing any individual votes [30].

3.4 Future Solutions There is some breakthrough within cryptography that might revolutionize encryp- tion handling. Some of these future solutions are discussed below.

3.4.1 Cryptographic Obfuscation Cryptographically secure obfuscation implies that the logic behind an algorithm is hidden. However, this is proven to be mathematically impossible [4]. On the other hand, the indistinguishability obfuscation is proven in this article [16]. This would enable smart contracts to store private keys without any malicious user being able to retrieve the private key, since the user would not know any of the logic that is

19 behind the smart contract. Although this is not yet a viable solution, since a 2 bit multiplication would take approximately 1, 3 · 108 years [7].

3.4.2 Zero-Knowledge Proof Zero-Knowledge Proof offers privacy for transaction validation [5]. The proof con- sists of a mathematical function which takes a hidden input and outputs a known solution, without revealing any other information. Consequently, a bank could prove that an account has enough balance in order to make a certain transaction. Zcash is based on a zero-proof knowledge consensus mechanism called Succinct Non-interactive Arguments of Knowledge (zk-SNARK). More information can be found on Zcash’s homepage [20] for a more detailed explanation of how the system works.

Zero-proof knowledge could also be used for two-party smart contracts. The amount of money that should be transferred is calculated by either party. The contract would receive the amount to transfer and a zero-proof knowledge ensures that the transfer is valid. This is also called an N-party smart contract which the Hawk project is trying to create [23]. Ethereum is also trying to make zero-proof knowledge work, but have yet to accomplish this.

3.4.3 Bitcoin: Account Linking Problem Bitcoin accounts can be linked together when a transaction has several inputs, this tells us that all of the accounts presented as inputs are somehow connected and possibly owned by the same person. Merge avoidance and the Cojoin protocol tries to solve this issue. The Cojoin protocol makes several accounts work together by requiring each account to fund one coin to newly created accounts in order to make it hard to link the input address of a certain transaction back to the previous old user account. However, the financial market does not require anonymous transaction but rather wants them to be private.

3.4.4 Ring Signature A ring signature consists of a group of public keys. The ring can be signed by anyone in possession of the respective private key. The ring signature does not reveal which of the private key was used. The signature is a list of values which are mathematically linked together, each depending on the previous value. The private key used for signing allows the user to add a seed to the input, in order to let the output be a specific value. This in turn is used to close the list making the last value becoming equal to the first. Ring signatures can be used for voting and identity applications by proving that you belong to a certain group.

20 3.4.5 Homomorphic Encryption Homomorphic encryption allows computations to be carried out on ciphertext without decryption. It could be used in finance in order to update the balance of an account without decrypting the content. Simple operations become slower, for instance a Google search would take approximately 1012 times longer using this process [17].

3.5 Key-Management Having secure channels between nodes is essential for any application in need of encryption for the management and the distribution of keys. The following subsection will look into how secure messaging can be achieved.

3.5.1 Wallet There are different kinds of Wallet applications used by Bitcoin users for storing private keys. Deterministic wallets create private keys from a single secret seed. The private key would be calculated by hashing the seed together with a random number. Another type of wallet is the Hierarchical Deterministic wallet which uses a tree model with different layers.

3.5.2 Flooding Flooding is a fast network messaging method. Messages are not sent directly to the receiver, instead the message is propagated throughout the network, eventually reaching the proper receiver. Basically, the sender sends the message to its closest neighbor which in turn does the same. This way the message will have taken the shortest way to reach the receiver’s node with the trade off of flooding the network. To prevent unlimited message forwarding the sender has to set a maximum number of times the message can be resent. The message is not resent back to the sending node.

3.5.3 Bitmessage The Bitmessage architecture is based on a peer-to-peer network, each forwarding messages on a best effort basis. It is used within the Bitcoin network which uses the flooding technique together with encryption, in order to anonymize messages as well as the sender and receiver. However, this slows down the network due to flooding of the network with messages that are sent in between thousands of nodes that are connected to the network.The Bitmessage protocol prevents spamming by

21 requiring a proof of work depending on the size of the message, which is similar to the hash lottery in the Bitcoin mining process. The sender has to hash the message together with a nonce until it is below a certain threshold.

The first connection is made using the public address, same as in the Bitcoin protocol. The message is encrypted with the corresponding public key and sent throughout the network following the flooding network protocol. The sender of the message will get a notice of when the message is received. Messages which do not trigger any response are rebroadcasted into the network with a two days interval with an exponential backoff. The flooding protocol ensures that the sender and receiver remain anonymous. All the nodes will try to decrypt the message, however, only the node with the corresponding private key will be able to decrypt the cipher message.

3.5.4 Internet Certificate Internet certificates are handed out by trusted authorities. An attribute authority (AA) gives out authorization certificates, also called attribute certificates (AC), meanwhile a certificate authority (CA) gives out public key certificates (PKC). AC are used to entitle the holder, such as a visa. PKC contain the public key of the holder which is used as proof of identity. The certificates should hold the standard cryptographic format X.509.

A PKC should have the following attributes; version, holder, issuer, type of signa- ture algorithm used, serial number (an identification number given by the issuer), validity period, special attributes, public key and the issuer’s signature of the cer- tificate content. An AC contains the same attributes, except that it does not con- tain any public key. Internet certificates enable companies to identify themselves to other parties so that secure channels can be established for private messages and key exchanges. In other words, certificates prove that a signature belongs to a certain entity. Certificates should only be valid for a certain period and then renewed, due to security risks and change in information.

The signature process begins with the document being signed, hashed and en- crypted with the private key. The signature can be validated by decrypting the signed document with the corresponding public key, and the output should be equal to the original documents hash. The private key can be stored together with the certificate in an archive file format such as pem or PKCS#12.

The issuing certificate authority needs to be trusted by other involved parties for its certificates to be of any use to the holder. Certificates can be distributed in a

22 tree structure, like a permissioning system. Leaf certificates (nodes at the bottom of the certificate tree) are dependent on above issuers trustworthiness since each certificate is signed by the issuer, creating a chain of trust. All certificates imme- diately below the root certificate inherit the trustworthiness of the root certificate. The root certificate should therefore be kept safe since it can corrupt the entire certificate hierarchy tree [19].

3.5.5 Secure Sockets Layer & Transport Layer Security Secure Sockets Layer (SSL) and The Transport Layer Security (TLS) are public key infrastructures (PKI). TLS is based on the SSL, but more secure. Their main tasks are to create, manage, distribute, use, store and revoke digital certificates and manage public key encryption. The TLS protocol is widely used on the In- ternet and is the basis for the HTTPS protocol. It is made for establishing secure encrypted channels between a server and a client. The TLS protocol could also be used in a peer-to-peer real time communication network. Some differences between SSL and TSL is that the SSL handshake protocol initiates its connection to a port and the TLS will first connect insecurely, and later on enable encryption.

The protocol can be divided into two sub protocols, the record protocol and the handshake protocol. The initial setup up starts with the validation of the server identity. The client may then create and encrypt a symmetric session key, which is sent back to the server. Information is thereon encrypted with the symmetric session key [11].

4 Literature Review

There are several major blockchain like solutions for the financial market. Some of the larger projects are Quorum, Corda and Ripple (IBM is also developing their own blockchain project called Hyperledger, but it is still in the early development phase) which will be discussed more in depth in the upcoming sections.

Quorum, Corda and Ripple are projects within the financial sector that use blockchain technologies. The Corda project is developed by a consortium of over 70 of the world’s largest financial institution with R3 in the lead. J.P Morgan’s blockchain project is the Quorum project which also aims to hide private information while still utilizing the full potential of the blockchain technology. Ripple’s investors include globally recognized venture capital firms and strategic investors. PwC has estimated that there are 300 startups focusing on blockchains in the US and UK [21].

23 4.1 Ethereum Ethereum enables the user to create and publish applications, so called smart con- tracts, on their platform by using their Turing-complete programming language. The platform comes with a cryptocurrency called Ether, which plays a fundamen- tal part in the Ethereum architecture. The architecture supports smart contract creation and enables developers to build applications on top of Ethereum. Each contract’s code is executed in the Ethereum Virtual Machine, partially isolated from other contracts with no access to the network’s filesystem or other processes.

Ethereum keeps track of accounts’ balances similarly as a normal bank by stor- ing the state, which differs from how Bitcoin records transactions. Bitcoin uses Unspent Transaction Output (UTXO) that can be spent as an input in a new transaction. An account has a 20 byte address, a nonce (a counter used to make sure each transaction can only be processed once), the current ether balance, and it can have a contract code and some storage capacity that is empty by default. There are mainly two types of accounts. The first type are the externally owned accounts which are controlled by private keys and have no code. The second type is a contract account which contains code that an externally owned account can activate by creating a transaction with the receiver set to the public address of the contract account. The contract account is allowed to send messages to other contracts.

A transaction in Ethereum should contain a receiver address, the signature of the sender, an amount of ether to transfer, furthermore, there is an optional data field, a startgas value which represents the maximum number of computational steps the transaction execution is allowed to take, and lastly, the gasprice value which is the rate the sender pays per computational step. The startgas and gasprice prevent contracts from wasting nodes’ resources and create infinite loops. It is basically an extra fee that has to be paid for the code to run.

The Ethereum mining process tries to prevent miners from exploiting application specific integrated circuits for mining blocks (computing hashes), which the Bit- coin protocol uses. Ethereum’s mining algorithm requires miners to fetch random data from the last N blocks in the blockchain, and thereon do some computation on the data and return the hash of the result. This implies that they also have to store the entire blockchain which enforces a larger number of full nodes. The mining algorithm should also be fairly simple for the miners to implement. It is, however, cumbersome to adjust the mining problem so that the block creation becomes constant without any time volatility. The algorithm should not rely on blocks too far back since it would cause memory issues.

24 The Ethereum blockchain shares the same issue of scalability as Bitcoin, but is ameliorated by the fact that Ethereum’s full nodes only need to store the account states and not the entire blockchain history. It will be difficult to manage the Bitcoin blockchain when it reaches volumes of 100 TB, since the number of full nodes is going to decrease [27].

4.2 Quorum J.P. Morgan’s blockchain project is called Quorum, which is built upon Ethereum’s solutions. Quorum is built upon Ethereum’s peer to peer network for communi- cation between nodes. The purpose of Quorum is to be used as a financial service by enabling transactions on the blockchain to be private. The private transaction is only visible to the involved and specified parties.

The transactions process is abstracted and handled by the Constellation mod- ule which is a message transfer system. The module has two sub-modules, the Transaction Manager module and the Enclave module. The Enclave’s purpose is to strengthen privacy and security by managing encryption and decryption in an isolated way, it can be seen as an isolated virtual Hardware Security Mod- ule. Both messages and private transactions are encrypted by using the Enclaves cryptographic functions. Hence, the Enclave handles symmetric key generation and data encryption as well as decryption. Transaction privacy is handled by the Transaction Manager module. The Transaction Manager stores data of pri- vate transactions in the form of ciphertext, and handles access to the different encrypted payloads. Only the private transaction’s hash is stored in a block. The Transaction Manager does not have access to any sensitive private keys.

A transaction can either be public or private within the network. The block val- idation process for public transactions is handled by a common vote between all the nodes within the permissioned blockchain. The majority voting protocol is called QuorumChain. Nodes within the network have the possibility to validate public transactions since they have access to the public account’s state. A Quo- rum transaction contains the recipient, the signature of the sender, the amount to transfer, an optional list of parties to have access to the private transaction’s in- formation, as well as an optional data field. The transaction process starts with a user specifying the transaction’s details and whether it should be public or private. If the transaction is private then the user has to specify who should have access to it by adding the corresponding public keys in the transaction. The transaction is sent to the user’s Quorum node that broadcasts it to the rest of the network. Valid public transactions are recorded on the blockchain in blocks.

25 The process of a private transaction is initiated with the Transaction Manager storing the payload and requesting its associated Enclave, which validates the sender and encrypts the payload. The transaction request becomes a real transac- tion once the sender’s private key is validated. The Enclave encrypts the private transaction’s payload together with a nonce, using a newly created symmetric key and the xsalsa20poly1305 library. As for the encrypted payload, it is hashed using SHA3-512. The symmetric key is encrypted N number of times using public keys of the receiving nodes using curve25519xsalsa20poly1305. N stands for the num- ber of involved parties, such as sender, receiver and other specified accounts. The Enclave returns the encrypted nonce together with the payload, the hash of the en- crypted payload, and the encrypted symmetric keys to the Transaction Manager. The Transaction Manager stores the received data and sends the data securely via HTTPS to the involved parties’ Transaction Managers in an encrypted format. The receiving parties acknowledge when they have received the data. Only the hash of the encrypted private transaction’s payload, which is received from the Constallation module, is propagated throughout the network using Ethereum peer to peer protocol. Only the involved parties will be able to decipher the payload. All nodes within the network are going to try to validate transactions within a block, although private transactions are ignored if the node does not have the symmetric key. In order to make sure that the node is a participant in the private transaction, the node may query the Transaction Manager whether the node has the hash of the encrypted payload or not. If the node has the hash of the en- crypted payload, this implies that the node has the symmetric key. Furthermore, if the node has the symmetric key then the Enclave deciphers the payload and sends the plaintext of the payload to the Transaction Manager, who validates that the sender has enough assets. If the transaction is valid, the involved parties will update their private databases.

The Quorum privacy design uses several properties of sharding techniques, such as dividing the database into two parts, a public and a private state database. The local public state database will be the same for all nodes, meanwhile the private state database will be semi-unique to each node. The blockchain stores all trans- actions in blocks for immutability reasons, and the databases for each node may be reconstructed using the blockchain, with the premise of the node having the right keys [31].

26 4.3 Corda The Corda project is led by R3, a fintech company that heads a consortium of over 70 of the world’s largest financial institutions. R3 does not describe Corda to be a blockchain project, but instead uses blockchain concepts in its database archi- tecture. Corda is made for the financial market with the scope of saving money in administrative work and prevent attacks such as Sybil and double spending attacks.

The Corda database keeps track of the overall picture of the market, so that each actor shares the same view while at the same time being able to keep some infor- mation private and only accessible to certain actors. Corda abstracts Quorum’s Enclave module and calls it Notary. Notary’s purposes are to validate transac- tions privately and securely, as well as give a finality to transactions by signing the accepted transaction. A Notary can reject a transaction if a double spend has occurred. Only involved parties within the transaction are able to see the relevant data. Hence, validation is made by the involved parties Notaries.

Corda uses a UTXO model which makes transactions structurally like Bitcoin’s transactions. Bitcoin addresses are similar to Corda’s states, which are atomic units of information, meaning that they are either current (unspent) or consumed (spent). Each state is associated to a certain Notary. A transaction takes the hash of states as inputs and creates zero or more new states as output. States of differ- ent accounts belong to the Notary cluster that created the account. Transactions are not put into blocks, instead Notaries keep track of transaction ordering by timestamping. The ledger is defined as a set of immutable state objects by using Merkle trees, as within the Bitcoin architecture. A processed transaction turns the input states into consumed states, as well as sets the state output ownership to the receiver. Furthermore, input states are not allowed to be controlled by mul- tiple notaries. If this would happen then a special transaction type would occur which would move the states to the same Notary. The Notary must receive the chain of custody, back to the initial issuance, of the input states from the sender. Validating all dependencies is the responsibility of the ResolveTransactions flow. The flow makes a breadth-first search over the given transaction chains, whereas the chain ends with the issuance transaction. All of the input states need to prove their issuance transaction heritage. Some notaries receive more information than they should, such as information concerning earlier transactions that they have not partaken in, and that is why Corda are trying to integrate a new software called Software Guard Extensions technology (SGX) to their Notaries. Further- more, Corda prevents double spending attacks by using a UTXO model, that is a state that is either spent or unspent. It is not possible to use the same state in different transactions to multiple Notaries, since state’s belong to only one Notary

27 and thereby the state cannot be double spent by another Notary. A UTXO model also increases privacy as one can not say how many states belong to a certain account.

Corda’s primary communication is handled by flows which are small multi-party sub-protocols similar to long lived threads, that may survive node restarts and upgrades. This enables transactions, as mentioned earlier, not to be broadcasted globally instead they are transmitted to the relevant nodes. The partial ledger visibility following having flows together with Notaries is still globally consistent since states belong to a certain Notary. The nodes within the system have long term stable identities which together with the network entry process prevent Sybil attacks. The network is similar to Tor’s concept of directory authorities. Tor is a networking protocol that aims to make the user anonymous by using onion routing, which is when the message is encapsulated in layers of encryption. The encapsulated message is relayed around the network and each time it passes a node it is decrypted. Each node keeps track of all the IP addresses within the network. The node also keeps track of identity certificates of nodes, and what their role is. The network uses Apache Artemis as a message broker together with AMQP/1.0 7 protocol and TLS to secure messages as well as authenticate nodes [18].

In the future Corda aims to replace the current software being used for the No- taries with a hardware solution called SGX INTEL, together with Modern Intel CPUs (Skylake+). The new solution offers an instruction set enabling data to be handled privately without making any private information known to the hardware owner. The hardware takes encrypted input data and returns the output without revealing any sensitive information. The solution becomes similar to a multi-party computation or zero knowledge proof.

4.4 Ripple Ripple aims to be the platform for cross-border payments on a global scale. One of its main features is that it is easy to integrate different actors’ networks into the system. Ripple mainly focuses on the capital market by offering banks fast, as well as completely traceable and data-rich international payment services by coupling banks together. A transaction process uses SWIFT/ISO messaging for managing funds movement, which only takes a couple of seconds (in general three to five sec- onds) even for international payments. The process time is greatly reduced since third parties are cut out, which also lowers the administrative costs that have been calculated in order to save 60 %. Balances of accounts are recorded on ledgers, the ledgers are automatically updated depending on successful transactions that pass through the consensus process. Anyone can join the network and start making

28 transactions, however, only trusted nodes will take part in the consensus mecha- nism. A node can eventually become a trusted node given enough time and after it has proven itself.

Figure 10: A simple overview of the Ripple architecture, source: https://ripple.com/.

Transaction requests are put in an open ledger which will later be called closed when it has passed the consensus process. The last closed ledger is identical for all nodes. The recorded states become unsure when there are open ledgers. Each node has a different Unique Node List (UNL) which is a group of server nodes that participate in the validation process for that node. The consensus of a transaction is reached when the large majority of the node in UNL (trusted nodes) agree that the transaction is valid. The consensus process happens in rounds, so that valid transactions that were rejected have a second chance.

If malicious nodes try to pass invalid transactions, this will be noted since approved transactions are continually re-checked automatically. These malicious nodes will eventually become black listed. Spamming of transactions will be detected and ignored by the system. Double spend attacks are prevented by the Interledger Protocol (ILP) which encrypts and locks down the funds, and subsequently re- leases them simultaneously to the involved parties. One of the major features of Ripple is that it can integrate different ledgers through ”connectors”, see Figure 10 [37][41].

29 5 Design

The scope of the design is to adapt Visigon’s blockchain, in order to meet the stan- dards of the capital market. The design aims to solve the issue regarding how to store both public and private information on the blockchain. Private transactions’ payload should only be visible to the involved parties and at the same time be robust against fraudulent attacks, while still keeping the system as decentralized as possible. The platform would unify banks and reduce administrative costs by surpassing third parties, avoiding costly errors and disputes. The proposed solu- tion ensures that banks have the same overview of the financial market.

5.1 Visigon’s Blockchain Project Visigon’s current architecture is a permissioned blockchain, which only allows ac- cess to specified nodes. However, it does not support private information handling on the blockchain. Visigon’s blockchain project (VBC) was created by Ludvig Backlund and is described in his master thesis [3]. Ludvig built the Java applica- tion from scratch in Eclipse, with the exception of using Ethereum’s library con- cerning cryptography. The current version of the VBC project is mainly developed by Jens Duvaldt, who has developed a new network architecture in collaboration with Carl Joneus. The VBC project is now hosted on the inhouse server Visi- Market, and the RESTful API is built using Spark. Spark is a micro framework for creating web applications in Java 8 released under Apache 2 License. The project integrates Spark through Maven, which sorts out the dependencies using a pom.xml file. The network communication is handled by an asynchronous event- driven framework called Netty. Other nodes can join the peer to peer network if their IP is on the permissioned list. The API for VBC tries to follow best practices when building RESTful Web Services. These frameworks allow the user to become both a client and server. An overview of the blockchain architecture can be seen in Figure 11.

VBC has four major packages, namely Core, Crypto, Network and Start. The Core package manages transaction logic and contains core blockchain classes such as Command Line Interface (CLI), Asset, Block, Blockchain, Miner, Node and Repos- itory. Key creation, signature and validation functions are handled by Ethereum’s Crypto package. The Network package controls the message communication, both server and client wise. The Start package contains the main class to run, which is called Start. The main class starts other runnable objects and sets everything in motion, such as checking whether the blockchain is up to date, mining and synchronization with other users.

30 Figure 11: An overview of the blockchain architecture. The transaction process can be followed from the top to the bottom.

Figure 12: Shows the hierarchy of relationships between Nodes, Accounts and Assets objects within the system.

Some of the more important classes are the following. • Node - has an IP address and directory path attributes. This object repre- sents the network participant. • Account - has a name, an address and a private key which is used for signing transactions. A node can only handle accounts that they have the private key for. • Asset - has a name, an ID and type. The object represents any type of

31 financial asset that can be traded in between accounts on the blockchain.

• CLI - handles user requests, such as emitting new assets, starting a trans- action, viewing assets or showing accounts addresses.

• Transaction - contains the sender address, the receiver address, a sender public key, a timestamp and a hash of the payload. A transaction can be either ordinary, emitting or empty. In general, transactions move assets in between accounts and are validated in the Repository class.

• Repository - purpose is to finalize blocks by validating transactions.

• Block - handles block creation containing a list of transactions, balances of all accounts, previous block hash, a timestamp and the block hash.

• Blockchain - has the current blockchain height, the directory path of the blockchain (where to store the blocks) and a hashmap of which participants are synchronized to the blockchain.

All confirmed transactions by the Repository are broadcasted throughout the net- work. Another new functionality to the blockchain is that it is now possible to make an order. The Order class is an extension of the Transaction class which requires the receiver to confirm that they accept the transaction before it can be executed. Basically, an order is put up on the blockchain and has to be accepted by the receiver to be converted into a real transaction. This is a key functionality regarding the post-trade part of financial applications. Future development will include automatic pairing of buy and sell orders.

5.2 Design Aims & Requirements The aims of the design is to add functionality in the form of private transactions. The payload should only be visible to the involved parties in a private transac- tion. The requirement is that a private transaction hides both the sender and the receiver, as well as which bank that has issued the transaction request, and at the same time keeping the system as decentralized as possible.

The proposed design choices were made in regards to other existing projects such as Bitcoin, Ethereum, Quorum, Corda and Ripple. The architecture is inspired by these project concerning concepts such as the account and state storage sharding from Quorum and TLS for secure messaging. Other concepts are different roles within the network, regulators and flooding protocol. Future aims of VBC would be to develop proper testing and address security issues.

32 5.3 Design Choices The proposed design is an extension of the permissioned blockchain VBC.

5.3.1 Observer, Voter, Creator & Regulating Nodes The nodes within the system would have different roles such as observer, voter, creator and regulator. The roles have different purposes and functions. Observer nodes, as the name suggests, would only be able to view the payload of transactions which they have the privilege to observe. Voter nodes participate in the consensus process and validate transactions. The creator node’s function is to create new blocks, containing the valid transactions. Creator nodes also need the privilege of an observer node, in order to be able to put the transactions on the blockchain. A node could be both a creator and a voter node. An example containing an overview of different roles within the system can be seen in Figure 13. The system would still be decentralized as the roles within the network would be established by negotiations between financial institutions within the network. Thereafter, the roles would be confirmed through certificates handed out by Visigon’s node.

Figure 13: Proposed, roles within the system.

Lastly, the design also introduces a new concept of having regulatory nodes ac- companying all transactions (especially private transactions), with the purpose of validating transactions privately and securely. Regulators to the core are special

33 privileged voting nodes, controlled by trusted institutes. These nodes facilitate institutional access to transaction data, such as certifying that the right amount of taxes is being paid. An account is randomly paired up with a certain regula- tor that keeps track of its balance. There should at least be an equal amount of regulator and maker nodes, in order to ensure scalability. New regulator nodes can successively be introduced into the system. The optimal number of regulator nodes should be empirically decided upon between the major banks.

Eventual disputes between banks, concerning for instance administrative issues such as the distribution of a stock, become easily solvable by querying the regulator nodes. Excessive querying of any regulator node would result in the querying node being ignored for a certain time interval. Regulator nodes make the system more centralized and burden institutions by keeping track of all accounts. However, these administrative issues are not expected to occur frequently since banks should already be used to rigorous bookkeeping. The regulator should only be involved in case of emergency. The final authority is the regulator node. The system would still be decentralized regarding public transactions, while private transactions would be semi-decentralized, due to the fact that different accounts are paired up with different regulator nodes.

5.3.2 Account & Storage Sharding The solution proposes similar sharding techniques as Quorum. Accounts are di- vided into public and private ones. A user may have several public and/or private accounts. This is necessary in order to keep transactions completely private, as explained in the the next section which concerns transaction processes. The vali- dation process is optimized by storing accounts’ balances in two different Patricia Merkle Trie, one public and one private. The public trie is the same for all nodes, meanwhile the private trie is semi-unique to the node. An account’s address is the key value map with the balance stored in the node leaf. All account addresses are available to all nodes without them knowing which bank it belongs to. Banks cre- ate new accounts by generating a private key, and thereby a corresponding public key and account address may be created. The account is randomly paired up with a regulator node, which in turn requests that the account is to be put up on the blockchain and thereby the account becomes globally known. Each node should store valid accounts in a Patricia Merkle Trie, in order to make lookups more ef- fective. It is only possible for an account to be globally invalidated by the node that controls the account, otherwise any node could invalidate valid accounts. For a node to invalidate an account globally it needs to show possession of the private key and store the information regarding which account is being invalidated on the blockchain.

34 5.3.3 Public & Private Transactions The design proposes to divide transactions into public and private ones. Informa- tion concerning public transactions and the consensus process is available to all the nodes within the system that have the right privilege (that is observer, voter or maker). Both public and private transactions are recorded on the blockchain, albeit the payload of a private transaction is encrypted with a symmetric key. The symmetric key is created and shared between the involved parties, thereby the pay- load is only visible to the involved parties. Private transactions are only validated by the involved parties. Banks should in general have the roles of voter and maker, since they handle customers’ private transactions. A customer’s bank handles the key management and hence the access to the customer’s account, which makes it important that banks are entitled to create and validate blocks.

Customers’ private keys are handled by their bank nodes. As customers are prone to lose their passwords, the banks handling private keys is in order to avoid po- tential problems which may occur if the customer loses his/her password. If a customer loses his/her private key, a new account would have to created and the old account would need to be invalidated. Furthermore, a regulator node would have to transfer all assets from the old account to the new account. All these inconveniences are avoided as the customer’s private key is safe with their bank nodes, as the likelihood of a bank losing the private key is significantly smaller. As long as a customer can prove their identity, the customer will gain access to his/her account.

5.3.4 Transaction & Block information A block contains public transactions, as well as the ciphertext of private trans- actions. The block header should contain the hash of the previous block’s hash and all the transaction data from inside the block for cryptographic linkage, public Patricia Merkle trie roots for immutability, as well as a timestamp of when the block was created. Each transaction should contain an individual timestamp as well. The Patricia Merkle trie root accounts for which state the current accounts are in, so that different users may confirm that they are using the same versions of all public accounts.

Transactions contain the sender address, the receiver address, the amount to trans- fer, the hash of the payload, a timestamp, as well as the sender’s signature for the transaction. Additionally, private transactions have an optional data field so that the sender may specify which other parties should receive the symmetric key that is used for encrypting the private transaction.

35 5.3.5 Transaction Process A public transaction is initiated as the client of a bank requests a public transac- tion. The transaction is handled by the bank’s node and it is transmitted through- out the network to the rest of the nodes following the flooding protocol, in order to hide the sender as well as the receiver. Banks have the possibility to deny the user the transaction request, hence only valid transactions are propagated through the network.

All of the voting nodes participate in the consensus process by voting if the public transaction is valid or not. At least 51 % of the voting nodes have to accept the transaction for it to be valid. More than 51 % is not necessary since all of the voting nodes are approved by the system, and closely monitored by the regulator nodes. There is also the risk of a voting node being offline, since then the total received votes could never be 100 %. By not requiring a 100 % acceptance rate, the validation process becomes faster since the node does not have to wait for all the voting messages to arrive before finalization. Nodes have a finite time to vote, in order to ensure finalization of the transaction within a reasonable time limit. Public transactions can be validated through a majority vote, without the regulating nodes confirmation.

To validate a transaction a voter node needs to know the sender address, the re- ceiver address, the amount to send, as well as the balance of the sender. Future updates of the system might include complex financial instruments which might in turn require more information. All nodes update their public account database when a new block is put up on the blockchain. Hence, the public account of the balances is available to all nodes within the system. Transactions that exist on the blockchain can not be withdrawn from the blockchain, however, they might be refunded since it is the banks that ultimately control the nodes.

Now onto private transactions. Information regarding private transactions is only available to the involved parties by requiring the possession of the symmetric session key used to decipher the ciphertext of the transaction’s payload on the blockchain. Private transactions are validated by the involved parties, including a regulator node. The ciphertext of the private transaction is recorded on the blockchain, hiding both the receiver and sender address. A private transaction made by Alice to Bob is to be validated by Alice’s bank and corresponding reg- ulator node. Bob’s bank and regulator node only needs to update Bob’s private account balance, which they are able to do since they already have the symmet- ric key. They can use the key to decrypt the encrypted private payload that is stored on the blockchain, and hence update Bob’s private account. All of the

36 involved voting nodes have to agree for the private transaction to be put up on the blockchain. If the regulator node would discover malicious interference, then it would invalidate the block. Double spending attacks of private transactions are prevented by the fact that each account belongs to a certain regulator node. Thereby, attacks are prevented as the regulator node keeps rigorous bookkeeping of the transaction times as well as having a nonce such that the transaction is only processed once.

A private transaction is propagated through the network in an encrypted format and each node has to check if they have the right key for decrypting it. The cor- responding transaction key is named after the hash of the payload which acts as a unique identifier. The metadata is also encrypted which ensures that the sender and the receiver remain anonymous.

A user can have multiple public and private accounts. To transfer assets from a public account to a private account or vice versa, one has to go through another temporary semi-private account controlled by a bank or a regulatory institution. One can not make a private transaction on a public account directly, since all of the nodes would then need to know how much is taken from that account and thereby it would disrupt the agreed consensus. Moving funds from a private ac- count to a public account can not happen in one step, since the validators need to know how much balance the sender has. To move assets from a public to a private account, first of all, a public transaction needs to be performed to a semi-private account. Thereafter, a private transaction from the semi-private account to the private account may be carried out. When moving assets from a private to a public account, first of all a private transaction needs to be performed to a semi-private account. Thereafter, a public transaction is created, however, it is only validated by the semi-private account’s node and the corresponding regulator node.

Smaller institutions and banks can join the network by selecting voter nodes to represent them and help them regarding private transactions. Consequently, the selected voting node also gains access to the private transaction’s payload and the balance of the private account.

5.3.6 Consensus Valid transactions are picked up by creator nodes and collected into a block. The block is thereon broadcasted to the rest of the network with the creator’s signature. Creator nodes follow a strict order when it comes to which block should create the new block, this procedure is performed with the scope of eliminating forks. In the case of two or more blocks being broadcasted simultaneously, the creating nodes

37 have to wait a random number of seconds before they can retry to add their block to the blockchain. This process is supervised by the rest of the network, and any malicious activity is hence prevented as the rest of the nodes ignore blocks from the abusive node creator. The creator node receives a confirmation from each node that they have approved the block. If no block is received within the approved time interval of block creation, then that node would be deemed to be offline and would hence be ignored. Malicious attacks by creator nodes, that try to get their blocks on the blockchain several times in a row, are ignored after being detected by the rest of the network, especially by the rest of the creator nodes. Nodes have the possibility to ask the network which current version of the blockchain to work on.

5.3.7 Key Management Secure messaging is achieved by using a TLS protocol which is good for near real time usage and distributing symmetric keys used for encrypting the payload of private transactions. Messages should be written to disk until the receiver has acknowledged that they received the message.

Accounts cannot be identified to belong to a certain bank. The bank nodes have to abstract each private account so that it is perceived as a node, otherwise the com- munication channel will be identified as going through a certain bank and not the account. Hence, the anonymity of which bank an account belongs to is achieved. Although, this burdens the system since it requires a lot more session keys.

There should be a secure channel for each account belonging to a node. Trans- actions cannot be handled by a bank to bank secure channel since that would reveal which account belongs to a certain bank. This implies that the bank has to create secure channels dynamically between accounts. This would require a lot of public, private and symmetric keys. However, the key management should be possible given the following example. With 20 million users and an average of two accounts per user, there are a total of 40 million accounts. If there are 10 major banks within the system, then each bank has to create 4 million Elliptic curve keys which are each 256 bit (ECC256) long. The total creation time would be roughly 12 hours by estimating that the creation time is 0.01 s. The total storage for a bank is the sum of the private keys belonging to the bank, and all of the listed account addresses within the system. The total storage needed is therefore 4 · 106 · 32 + 40 · 106 · 32 = 0.2560 GB. The key creation time could potentially be faster by using deterministic key derivation such as BIP 32 Hierarchical Deter- ministic Wallets 13 which Bitcoin Wallet uses.

38 Private transactions are encrypted using symmetric session keys that are dis- tributed through secure channels using TLS. These session keys are only valid until the next key rotation is scheduled. The symmetric keys are created and distributed by the sender’s node and are unique for the sender-receiver pair. The associated nodes keep track of the symmetric keys. The ciphertext of the yet to be validated transaction is sent to all nodes through a flooding protocol so that the sender and the receiver are hidden. It is only the sender’s node and the corre- sponding regulator node that validate the transaction. The receiving node and its corresponding regulator node should also receive the symmetric key used for en- crypting the payload of the private transaction. The following example estimates the creation time and the storage needed to handle large volumes of symmetric keys. With a total of 20 million private accounts, 10 banks and an estimate of 500 different account connections for each account, the average amount of connections required are equal to 20/10 · 500 + (20 − 20/10) · 1/10 = 2 · 109. With 1/10 being the probability of an account connecting to one of the bank’s accounts. Assuming that the creation time for one AES 256 bit key takes 0.1 ms yields a total creation time of 56 hours per key rotation. One key rotation would require 2 · 109 · 32 = 65 TB. Accounts with more than 500 connections would be directly handled by the account’s bank’s nodes, public and private keys, as well as its symmetric session key. Albeit, this implies that the following transactions made can be linked to the bank. Users that have an account with more than 500 connections may pay an extra fee for keeping their account, remaining completely anonymous.

Key rotations should be made as frequently as possible by the bank. Creating and storing keys adds an extra cost to the total system cost, which might be funded by adding a small transaction fee. After a key rotation is made, the keys should be stored away safely and compressed since they are not actively used by the node, and the regulating node should also keep a copy of them.

If a bank loses any symmetric session key then it can be recovered querying the corresponding regulating nodes. If a private key of an account would be lost, then the regulating node would have to step in and transfer the account’s fund into a new account. For this to happen the bank needs to make an official request to the system. On the other hand, a more serious case would be if the bank node would lose its private key. Then the bank would need to make an official request manually to the network, and bring sufficient identification to the system for it to regain its role. This process should not be automated since a bank should not lose one of its most valuable possessions, the private key. A node’s privilege could be revoked by an anonymous vote within the network, however, this would not be automated either, since this event is not expected to occur frequently.

39 5.3.8 Malicious Attacks Hacking attacks such as 51% spending attacks are implausible since it would re- quire the hackers to hack several banks’ security systems. Private transactions are more vulnerable since it would only be necessary to hack one bank and the regulating node, this would still be a difficult endeavor for the hackers. Malicious observers can leak information regarding sensible transactions if they have the right permission, and this would be difficult to detect since it would happen out- side the system. Although, one would know which nodes that could have leaked the information. Hacked nodes could potentially be detected by having validation checks of transactions. If a voting node becomes hacked, then it would be handled by other nodes’ cumulative voting power or the regulating node. Fraudulent voting nodes are detected if they frequently vote against the majority. Maker nodes are valuable targets for hackers since they have the ability of creating invalid blocks, however, this should be prevented by regulators and possibly by other nodes that have the rights to see and hence detect the invalid transactions. If a block would be removed, then the system would need to restart from the previous block, inval- idating subsequent blocks’ transactions.

Malicious regulating nodes would be detected by other banks if they would detect that an invalid transaction is passed as valid. Regulators can only vote, which means that an invalid transaction is only processed if another bank is hacked as well. There are several regulator nodes for making the system more decentralized and also harder to exploit.

Important nodes should have multiple backup nodes connected to the blockchain network, thereby the transactions could still be processed if a node goes offline. A node that comes back after a period of being offline, would get the necessary in- formation from the blockchain. Information regarding private transactions would firstly be retrieved from the banks’ backup nodes and lastly from the correspond- ing regulator nodes. If all nodes belonging to a bank would go offline, then the transactions would be in a pool of pending transactions until any of the banks’ nodes comes online. Regulator nodes should also be backed up frequently

Permissioned users within the system are identified by having Internet certificates handed out by Visigon’s server. A node can hence not be disguised as another node. This can be identified as a single point of failure if Visigon’s server becomes hacked, and hands out certificates while being hacked, and this could be prevented in multiple ways. All nodes within the system know all the possible actors within the network since a new actor is introduced to the system by a majority vote, and should therefore be suspicious of any new actors that have not been officially

40 agreed upon. A countermeasure to prevent Visigon’s server being hacked is to take the server offline.

6 Discussion

A decentralized database system such as blockchain would save banks money by reducing administrative work and giving the participants a unified overview of the financial landscape. It also offers participants the opportunity to reach a con- sensus with limited trust, although they need to have some trust in the system. Blockchains have the potential to change the foundation of how we organize data on a global scale. Whether or not the financial market can exploit the full po- tential of blockchains technologies remains to be seen, blockchains might be more suitable for other purposes. Blockchains are applicable for markets which require shared databases, immutable objects, version handlers and where participants are equally distrusted. You might wonder why one could not simply use a centralized shared relational database? There are several issues that arise from a centralized data storage such as the ownership, which country it should be stored in and the risk of the system being hacked due to it being centralized. Other questions that need to be answered are whether blockchains can handle transactions on a large scale, and who would manage access control.

Blockchain technology in its original context was created by Satoshi Nakamoto when he made Bitcoin [28]. The foundation of blockchain technology is founded on cryptography. One key attributes is public encryption, which allows account owners to sign transactions with their corresponding private key proving that they have explicitly confirmed the transaction request. Another important attribute is the hash function. The hash function enables the possibility of a more robust system by linking blocks together and make transactions immutable by storing them in Merkle trees. Basically, it boils down to having the core foundation built by robust blocks.

6.1 Existing projects The following paragraphs are dedicated to explore how well Bitcoin, Ethereum, Quorum, Corda and Ripple can adapt the capital market. The discussion will focus on whether or not the platforms can handle financial transactions in regards to privacy and anonymization.

41 6.1.1 Bitcoin The scope of Bitcoin is to create a true decentralized system for a global cryptocur- rency. It is possible for any user to join the network, since it is not a permissioned blockchain, and look up any public address’s balance. Hence, it is ill-suited for the capital market since it does not support private transactions. Furthermore, accounts are pseudo-anonymized meaning that transactions are not made from an account, but from different public addresses that represent different number of Bitcoins which cannot be traced to belong to any particular user. This is a trade-off by using pseudo-anonymization and making coin traceability more diffi- cult. Another issue of considerable size is that Bitcoin uses Proof of Work for their consensus algorithm which wastes enormous resources and leaves a huge carbon dioxide footprint. There will also be geopolitical issues due to miners moving their businesses to regions with cheap electricity. The main positive feature of Bitcoin is its robustness gained by deploying immutable linked blocks.

6.1.2 Ethereum Ethereum also uses a variation of Proof of Work similar to Bitcoin, but has man- aged to avoid geopolitical problems by making the Proof of Work that miners have to find more complex, albeit it still wastes resources. Ethereum has been trying to solve this problem by introducing Proof of Stake, but they have yet to achieve this. Smart contracts do not guarantee that the outcome is deterministic which might be problematic, since this is prone to attacks from hackers. Will the code remain valid indefinitely, or will the meaning of the contract change after a few years? Questions like these need to be answered before being applied to the finan- cial market since it could have devastating effects.

Ethereum is a great platform for smart contracts. However, it has to be adapted to suit the financial market by an addition of privacy features, remaking the consensus process and ensuring a higher degree of security. Smart contracts might be common practice in the future since they enable a dynamic and agile development of new functionality, as well as ensuring that the same logic is being executed on all the nodes within the network.

6.1.3 Quorum When J.P Morgans blockchain project Quorum built their application they did not do this from scratch, instead they used Ethereum’s platform as a base. Quorum has its own peer to peer network, meaning that they are not part of the Ethereum network. Thereby, Quorum becomes dependable on Ethereum’s future develop- ment, which has its benefits and drawbacks. By trusting Ethereum’s solution, the

42 developers at J.P Morgan have the possibility to devote more resources in order to build a robust infrastructure. On the other hand, J.P Morgan will not have the same control over the entire platform which is crucial when dealing with financial institutions that are heavily regulated.

Quorum uses a virtual hardware security module to abstract their encryption man- agement of private transactions which they call Enclaves, leading to a more cen- tralized system. A possibility for Quorum could be to create an actual hardware based solution for increased security. The payload of the transaction is stored by the Transaction Manager, and only the hash of private transactions is added to the blockchain. Quorum uses blocks which is advantageous for immutability, this is not a bad design choice, although it becomes harder to access the data. The blocks add a layer of security, as a malicious user would need to hack the En- clave and then start deciphering the payload in order to access private information.

Quorum uses sharding techniques to divide the state database into public and pri- vate states, improving account management by optimizing supervision of states. In conclusion, Quorum has an overall robust architecture enabling private trans- actions, however, more time is needed in order to mature regarding regulations.

6.1.4 Corda R3’s blockchain project Corda is a distributed ledger project that is built for fi- nancial applications, thereby it is a blockchain like project. Corda is designed with the explicit goal of providing consensus compatible with legal notion of settlement finality. Since the application has been built from zero this creates a situation of total control of development, and therefore the application can easily be adapted to financial regulations. Corda does not rely on sharding for privacy, instead the application only enables private transactions, and not public ones, which simplifies the architecture. Relying heavily on Notaries managing the transaction process, and as as all transactions are stored as ciphertext, this makes the system more centralized. The user has to truly believe that the Notaries are handled in the right way. Corda needs to keep backup of all Notaries since it is not possible to rebuild the entire transaction history, if a Notary becomes corrupted.

Corda validate transactions by proving that the states used as input of a transac- tion are unspent. Privacy is improved at the cost of traceability due to the fact that one cannot know the exact balance of an account without the user explicitly showing possession of certain states. A UTXO model makes the architecture be- come more complex and burdens the system since new states with a corresponding private key needs to be created for each transaction.

43 The system uses TLS for secure messaging, and has therefore an identity infras- tructure between participants. Corda’s network setup is similar to the Tor concept of directory authorities, which adds a layer of security to the network. Transactions are not globally broadcasted but only shared with the involved parties, sender and receiving Notary, of the transaction. This design choice was made in regards to Corda aiming to be a global platform and therefore it is important not to slow down the network by sending messages to nodes that cannot read the encrypted payload.

The Corda project does not use blocks in the creation of their distributed ledger technology. Instead, Corda combines the strength of Merkle trees together with rigorous timestamping in order to keep track of their transactions. This design choice is favourable, however, misses out on extra robustness that block hash link- age offers in regards to immutability. Corda’s architecture does not allow using blocks since only Notaries that are involved in a transaction know that the transac- tion exists. Corda uses techniques from blockchain, but does not store transactions within blocks. Furthermore, its system is rather centralized around Notaries which implicates that the application does not fall under the category of a blockchain technology.

Lastly, Corda is backed by a large consortium of the world’s largest financial institution which guides the project on how to solve the problems imposed by the financial market. Thereby, Corda is creating a solution to the problem and not vice versa.

6.1.5 Ripple The Ripple solution offers semi-private transactions by letting the node decide which trusted nodes to add to the Unique Node List (UNL). The UNL is a list of nodes that are used to validate the nodes transactions. As the nodes, and the UNL’s in them, may differ from each other, validation is ultimately in the hands of the network participants. Thereby, validation is the network participant’s re- sponsibility, and not Ripple’s. Hence, an account’s balance is only available to the voting nodes specified in the UNL, and not the entire network. Mentioned accounts have addresses that are pseudo-anonymized.

The main scope of Ripple is not to make transactions private, rather to enable fast intercontinental transactions. The Ripple blockchain is semi-permissioned since anyone can join the network without being approved by anyone. However, new users are initially not trusted. The lack of trust is demonstrated as new users’ nodes only have the right to initiate transaction requests, but not participate in

44 the consensus mechanism. This means that the new users do not have the right to validate transactions in the network. Using a semi-permissioned network as this one, shows advantages as a design choice since it does not give the new nodes any power. Furthermore, the semi-permissioned design also makes it easier for newcomers to join the network. However, this implicates that Ripple faces issues concerning legislations and regulations regarding bank secrecy and customer infor- mation protection, especially when looking at the global market, as hackers could join the network for instance.

Ripple cannot offer complete privacy because of the design choice of UNL lists. The lack of privacy is an issue as some nodes will possess great knowledge of different accounts’ balances. However, Ripple is supported by large financial actors such as Bank of America, Santander and Bank of Tokyo-Mitsubishi UFJ. Furthermore, Ripple has large banks as clients such as SEB, RBC, Reise Bank, BBVA and many more. Ripple’s network of financial actors, including its clients, proves that different actors on the market have accepted the lack of privacy implied by the use of Ripple. The design choice of UNL lists is beneficial financially as administrative work is automated, which in its turn decreases the risk of errors which can lead to costly disputes. A substantial benefit of Ripple is that international transactions are carried out only in a matter of seconds, this benefit seems to be the driving factor of clients choosing Ripple, making them overlook the lack of privacy.

6.1.6 Comparison between Design Choices Now that four existing projects have been discussed separately, the projects will be compared to each other. Firstly, Bitcoin’s architecture is created in order to enable the cryptocurrency bitcoin to become a global fiat currency. Another fea- ture of Bitcoin is that anyone is able to join the peer to peer network, and thereby participate in the consensus mechanism. The current design choices of Bitcoin fail to meet the standards of the financial market. Mentioned standards that Bitcoin has failed to achieve are for instance privacy, traceability (due to account addresses being hard to couple together with account owners), and exclusiveness (as any- one can join the network). Therefore, Bitcoin cannot be used as a platform for the financial market. Moving on to Ethereum, the platform is similar to Bitcoin, however, the addition of smart contracts have worsen the prospects of being used for the financial market, due to the fact that the output of smart contracts are not deterministic. Another negative aspect of Bitcoin and Ethereum is that they both use Proof of Work to reach consensus which lacks transaction finality. In conclusion, neither Bitcoin or Ethereum are suited for the financial market.

45 The fourth mentioned design was Ripple. Ripple offers transparency, especially for cross-border transactions, and as a result also improves traceability which in turn lowers administrative costs. This is at the expense of users’ privacy, as all the nodes that work within the UNL knows the account’s balance. Ripple is suited to handle large volumes of small global transactions which accommodates the needs of relatively new emerging needs of companies such as Amazon. However, Ripple is not suited for the financial market, as it does not meet the strict regulations concerning privacy. To go against mainstream and not feature private transac- tions is a dangerous game to play. Instead, a possibility for Ripple would be to replace Swish, a mobile payment application for micro-transactions, on a global scale. Furthermore, Ripple supports multiple blockchain integrations. The multi- ple integrations could be used to enable private transactions, but that would imply two separate blockchains instead of one, which complicates the architecture and makes it prone to errors. However, it is important to keep the concept of being able to integrate other systems into the blockchain, since banks cannot change their current system overnight. Therefore, the integration needs to be a gradual process.

The projects Bitcoin, Ethereum and Ripple are created with a focus on their respective cryptocurrencies, thereby making their use case narrow. Having a cryp- tocurrency as a central part of the architecture also comes with political and economical challenges which are hard to manage. One of these problems is that when the currency is volatile, the currency value needs to be stable in order to attract investors. Ripple tries to solve this by owning the large majority of Ripple coin which in turn gives the Ripple enterprise a lot of power and influence over their own currency and hence the system.

The blockchains should be permissioned to eliminate the fact that only approved nodes should participate in the consensus process. For blockchains adapted to the financial market, the permission implies that access can be controlled and that is one of the reasons why Bitcoin, Ethereum and Ripple are ill-suited for this task as well.

The remaining projects, that is Quorum, Corda and the proposed design for VBC, use a permissioned blockchain. The next aspect to focus on is how to actually store private information on the blockchain. Three alternatives are discussed in this the- sis; 1. To store the ciphertext of the payload in Transaction Manager module, and the hash of the payload on the blockchain, 2. To dismiss the idea of blockchain and abstract the private transaction process into Notaries, and 3. To store the ciphertext of the payload on the blockchain. The first option has been chosen for Quorum, the second option is the one used by Corda, and the third is used in

46 the VBC. The first two alternatives used by Quorum and Corda, obfuscate the payment process. Thereby, the user has to trust that the technical environment handles transactions correctly.

Furthermore, there are implications with the third mentioned alternative used in the proposed design for the VBC project. When the ciphertext is stored on the blockchain, a malicious user could try to brute force deciphering a private trans- action. However, this would take several years to do, and it would also be difficult for the hacker to find which transaction to decipher since both the sender and the receiver are unknown. The design choice is also motivated due to the fact that VBC aims for a smaller market, such as the Nordic obligation market, as the obli- gations do not have a long life-span. VBC aims for a smaller market because they would not be able to, initially, compete with Quorum and Corda on a global scale since they are well funded. Another reason for the design choice is its simplicity which makes it easy to develop and secure. A disadvantage of having the cipher- text on the blockchain is that it wastes bandwidth for the non-involved nodes since they cannot decipher the encrypted payload. The proposed design enables the user to decide whether they want a more secure private key, which would take an even longer time for the hacker to decipher. This feature could be used to hide transactions involving assets that are kept for a longer period of time. The extra costs that are implied with the more secure key, are due to the management of it, which would be payed by the user. If the transaction process would be abstracted as Quorum and Corda do, then regulators would have to take a more significant role within the system, and store the payloads on a separate ledger. This scenario would make the system even more centralized and regulators would be similar to Enclaves and Notaries.

Corda has an advantage over Quorum, since it is more adapted to the financial market and has support for smart contracts. Smart contracts are favorable since they enable agile development of new financial derivatives, which is something that VBC aims to achieve as they enable any financial assets to be traded on the system. Quorum is still under development and is largely based on Ethereum due to being hurried into the market to gain the first mover advantage. The VBC should try to support smart contracts in the future.

47 6.2 Proposed Design The aim of the VBC project was to evaluate whether it is possible to keep the blockchain concept alive and make slight alterations to adapt the project into the financial market. The proposed design presented in this thesis aims to solve is- sues regarding how to store both public and private information on the blockchain.

The proposed design could not be implemented since that would require a proper functioning network. The current VBC network is under development and it is supposedly to be completed during the summer of 2017. Furthermore, the pro- posed design would take more than six months for a single developer to implement. More obvious limitations are the lack of testing and various difficulties in order to lay out a detailed plan for the implementation of the proposed design. The proposed design serves as a guideline for VBC developers.

6.2.1 Main Design Features There are different concepts that together constitute the proposed design. Firstly, the proposed design has different roles for the nodes within the network, which are handled through certificates. Another main concept in the proposed design is to store transactions into immutable linked blocks and discarding the mining process. If the mining process would have been kept, it would have implied a waste of valuable resources as well as an increase of the carbon dioxide footprint. Thirdly, private transactions are validated and visible only to the involved parties by a shared AES symmetric key. The system in the proposed design uses ECC keys within the TLS protocol together with Internet certificates for secure com- munication and a flooding protocol to hide the sender of the transaction. ECC seems to be gaining support from various projects such as Bitcoin, Ethereum and Ripple. Furthermore, it also takes a longer time to crack an ECC key compared to a RSA key of the same length. The future could be to use Lamport signatures to protect against the threat of quantum computers.

The proposed design keeps track of accounts’ balances together with a nonce to ensure that a transaction is only processed once. Accounts are available to any- one, and are non-linkable to any bank. Assets in the accounts may be transferred between public and private accounts anonymously. Regulators should be present in every transaction with the purpose to facilitate institutional access and govern transaction processes. The regulators also contribute to a more centralized system, although it ensures secure transaction processes.

48 A sharding feature regarding storage is that in the proposed design, accounts are stored in two different Patricia Merkle tries. These two tries are public and private, respectively, which increases the effectiveness of the storage. The trie is O(log(n)) efficient for inserts, look-ups and deletes, as the depth of the tree is bounded. Furthermore, as for the storage, the system could use Bitcoin’s wallet structure in order to store private keys safely together with hardware encryption, to protect against hackers.

As mentioned, Ripple’s traceability is also something to be desired. The proposed design solution is to introduce regulating nodes which purpose is to validate private transactions and at the same time ensure traceability. The design makes the major users and financial institutions become active managers of the system, see regulating nodes, giving them more incentive to make it secure. The proposed design hides the connection between an account and a bank and keeps both public and private information on one ledger, while keeping the system decentralized.

6.2.2 Difficulties & Trade-Offs During the creation of the proposed design, different difficulties arose and trade- offs had to be made in order to add functionality regarding private transactions. First of all, a trade-off between having a centralized and secure system had to be considered. The current design is a permissioned blockchain which is an oligopoly of who controls the blockchain. The proposed design still allows any user to join the blockchain by the extension of a bank node. This makes it easy to couple ac- counts on the network to real identities. The user needs to trust the banks’ nodes to a certain degree, as the blockchain becomes more centralized, although it is beneficial in order to reach a consensus between major financial institutions. Per- missioned blockchains are more susceptible to hacker attacks since there are only a few central nodes of power. Nodes would protect against eventual downtime by having multiple backup nodes. Malicious nodes are handled by other financial institutions, and the corresponding regulating node. Attacks by malicious nodes, such as double spend attacks, are countered by other nodes’ rigorous check-ups. Node should continuously run validation protocols in parallel on existing transac- tions on the blockchain. Malicious nodes should not be removed from the network since that might be exploited by hackers as they might try to discredit true nodes, and getting them removed. This would result in the malicious nodes getting more influence over the system. The malicious nodes should instead be ignored for a period of time and be given an official warning. Presumably, it is implausible for a hacker to have enough resources in order to penetrate several banks’ extensive security protocols.

49 The design does not use Bitcoin’s UTXO model, instead the concept used by the proposed design is that it keeps track of accounts’ balances. The proposed de- sign does not use a UTXO model since it lacks traceability and even tough it increases privacy, due to fact that a transaction can be validated without knowing exactly the account’s balance. Although, The UTXO model does not offer com- plete privacy since the validating nodes needs to know the transaction history of the transaction input to know that it unspent.

The difficulty of handling forks in Bitcoin’s blockchain, have been dealt with by in- troducing a scoring algorithm. This way it was possible to decide which blockchain version to keep working on. Since permissioned nodes are not that many, and there is no reward for them, they could reach an agreement by simply waiting to put their block up on the blockchain after a randomized time interval. As a result that the blockchain cant be forked is that transactions are finalized when they have been added to a block and accepted by the network.

Another difficulty that had to be solved was how to handle public and private ac- counts. One difficulty associated with private transactions, is for instance that the users need to trust the regulating node to validate the transactions. The regulat- ing nodes make the system more centralized, although there are several regulating nodes to make the system less centralized. The system aims to become as decen- tralized as possible since that makes it more safe against hackers. As for public accounts, these are faster, have better traceability, and are more secure compared to private accounts. This is due to the validation process being decided by a majority vote within the permissioned network. Private transactions are slower since they need at least one regulating node to validate the transfer. Transactions in between public and private accounts make it harder to trace the transaction’s origins.

7 Conclusions

The main conclusion of this thesis is that blockchain might not be the most suit- able database system for banks, if the capital market does not accept that payloads from both public and private transactions are recorded on the blockchain. How- ever, blockchain technology has the potential to be the next disruptive technology for general storage. A possible alternative route would be to take the best features of blockchain, such as, for instance, the immutability aspect and abstracting the entire transaction process. Another conclusion is that it is important to take legis- lations into careful consideration while developing the platform. When developing blockchains for the capital market it is also crucial to consider easy integration of

50 the blockchain into the current existing system, in order for a gradual shift when changing transaction platform.

VBC works well for smaller markets which allow that, in the future, private infor- mation might be exposed to the involved participants in the blockchain. Before implementing the proposed design into the VBC project, several aspects need to be improved such as safety, network communications, standardized simulation test- ing, and patching of existing bugs.

The network design could be improved by using a Tor like network in order to enable that communications between nodes could not be traced to a certain bank. The message would be repeatedly encrypted in an onion-like fashion. Albeit, this would be at the cost of higher latencies for the network.

Future solutions for reaching consensus might involve proof of stake or zero-proof knowledge (zpk). Zero-proof consensus is the holy grail for privacy, in a decen- tralized database system. This is due to the fact that a bank can prove that an account has enough balance without revealing any important information. The most known zpk is the zkSNARK algorithm but it has some security issues since the administrators that handles the initialization can exploit a back door problem. Although, there are other algorithm in development such as zkSTARK that reme- dies this issue. A major security risk is that encryption methods might be deemed not secure in the future. One of these threats are quantum computers, which could be countered by using Lamport signatures. Furthermore, smart contracts might be a way forward for banks in order to easily create new financial instruments. How- ever, there might be unforeseen complications with creating new types of smart contracts. Hence, this might be implemented after Ethereum is deemed to be safe. Smart contracts would create a dynamic environment for other sectors to couple their system with the blockchain governed by banks. Another design choice to be tested is to let secure hardware take care of the consensus process (Hyperledger and Corda are looking into this). Blockchain technology is still in its infancy and what it can achieve is remained to be seen in the future.

Acknowledgements

I would like to thank my supervisor Gustav Ekeblad for his guidance and support throughout the project. I also wish to express my gratitude towards Jens Duvaldt for his insight and many workshops in helping me become a better developer. It has been a pleasure working together.

51 References

[1] In: url: https://ethereum.stackexchange.com/questions/268/ethereum- block-architecture. [2] Andreas M. Antonopoulos. Mastering Bitcoin. O’Reilly Media, 2015. [3] Ludvig Backlund. A technical overview of distributed ledger technologies in the Nordic capital market. 2016. [4] Boaz Barak et al. “On the (im) possibility of obfuscating programs”. In: Annual International Cryptology Conference. Springer. 2001, pp. 1–18. [5] Eli Ben-Sasson et al. “SNARKs for C: Verifying program executions suc- cinctly and in zero knowledge”. In: Advances in Cryptology–CRYPTO 2013. Springer, 2013, pp. 90–108. [6] Bitcoinwiki. Proof-of-Stake. url: https://en.bitcoin.it/wiki/Proof_ of_Stake (visited on 03/09/2017). [7] Bitte entschuldigen Sie, leider gibt es diese Seite nicht (mehr)! url: https: / / www22 . in . tum . de / fileadmin / papers / essos15a . pdf (visited on 04/03/2017). [8] Blockchain info. url: https : / / blockchain . info / charts (visited on 01/20/2017). [9] Clemens H. Cap. “A Structural Analysis of Bitcoin”. In: University of Ros- tock, Department of Computer Science (). [10] Kaylash Chaudhary et al. “Modeling and Verification of the Bitcoin Pro- tocol”. In: Proceedings Workshop on Models for Formal Analysis of Real Systems, MARS 2015, Suva, Fiji, November 23, 2015. 2015, pp. 46–60. doi: 10.4204/EPTCS.196.5. url: http://dx.doi.org/10.4204/EPTCS.196.5. [11] Tim Dierks. “The transport layer security (TLS) protocol version 1.2”. In: (2008). [12] W. Diffie and M. Hellman. “New directions in cryptography”. In: IEEE Transactions on Information Theory 22.6 (Nov. 1976), pp. 644–654. issn: 0018-9448. doi: 10.1109/TIT.1976.1055638. [13] Whitfield Diffie and Martin Hellman. “New directions in cryptography”. In: IEEE transactions on Information Theory 22.6 (1976), pp. 644–654. [14] Philip Evans. Thinking outside the BLOCKS: A Strategic Perspective on Blockchain and Digital Tokens. Dec. 2016. url: https://www.bcg.com/ blockchain/thinking-outside-the-blocks.html?utm_source=201612TechDigital& utm_medium=Email&utm_campaign=otr (visited on 01/26/2017).

52 [15] Explainer: Smart Contracts. url: https://monax.io/explainers/smart_ contracts/ (visited on 01/21/2017). [16] Sanjam Garg et al. “Candidate indistinguishability obfuscation and func- tional encryption for all circuits”. In: SIAM Journal on Computing 45.3 (2016), pp. 882–929. [17] Craig Gentry et al. “Fully homomorphic encryption using ideal lattices.” In: STOC. Vol. 9. 2009. 2009, pp. 169–178. [18] Mike Hearn. “Corda: A distributed ledger”. In: (2016). [19] Russell Housley et al. Internet X. 509 public key infrastructure certificate and certificate revocation list (CRL) profile. Tech. rep. 2002. [20] How Zerocash works. url: http://zerocash-project.org/how_zerocash_ works (visited on 04/03/2017). [21] Martin Arnold Jane Wild and Philip Stafford. Technology: Banks seeks the key to Blockchain. Nov. 2015. url: https : / / www . ft . com / content / eb1f8256-7b4b-11e5-a1fe-567b37f80b64 (visited on 02/05/2017). [22] Ghassan O. Karame, Elli Androulaki, and Srdjan Capkun. “Double-spending Fast Payments in Bitcoin”. In: Proceedings of the 2012 ACM Conference on Computer and Communications Security. CCS ’12. Raleigh, North Carolina, USA: ACM, 2012, pp. 906–917. isbn: 978-1-4503-1651-4. doi: 10 . 1145 / 2382196.2382292. url: http://doi.acm.org/10.1145/2382196.2382292. [23] Ahmed Kosba et al. “Hawk: The blockchain model of cryptography and privacy-preserving smart contracts”. In: Security and Privacy (SP), 2016 IEEE Symposium on. IEEE. 2016, pp. 839–858. [24] Leslie Lamport. Constructing Digital Signatures from a One Way Function. Tech. rep. Oct. 1979, pp. 644–654. url: https://www.microsoft.com/en- us/research/publication/constructing- digital- signatures- one- way-function/. [25] Leslie Lamport, Robert Shostak, and Marshall Pease. “The Byzantine Gener- als Problem”. In: ACM Trans. Program. Lang. Syst. 4.3 (July 1982), pp. 382– 401. issn: 0164-0925. doi: 10.1145/357172.357176. url: http://doi.acm. org/10.1145/357172.357176. [26] Arjen K Lenstra, Thorsten Kleinjung, and Emmanuel Thom´e.“Universal security; from bits and mips to pools, lakes-and beyond.” In: Number theory and cryptography. 2013, pp. 121–124. [27] Njagi Mwaniki. Ethereum: White Paper. url: https : / / github . com / ethereum/wiki/wiki/White-Paper (visited on 02/26/2017).

53 [28] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. Oct. 2008. (Visited on 02/01/2017). [29] Karl J. O’Dwyer and David Malone. “New directions in cryptography”. In: IEEE Transactions on Information Theory 22.6 (Nov. 1976), pp. 644–654. issn: 0018-9448. doi: 10.1109/TIT.1976.1055638. [30] Michael O’Keeffe. “The Paillier cryptosystem: a look into the cryptosystem and its potential application”. In: College of New Jersey (2008). [31] Quorum Whitepaper. url: https://github.com/jpmorganchase/quorum- docs/blob/master/Quorum%20Whitepaper%20v0.1.pdf. [32] Benjamin Edelman Rainer B¨ohmeNicolas Christin and Tyler Moore. “Bit- coin: Economics, Technology, and Governance”. In: Journal of Economic Perspectives 29 (2015), pp. 213–238. [33] Adrian Rice and Ezra Brown. “Why Ellipses Are Not Elliptic Curves”. In: Mathematics Magazine 85 (2012), pp. 163–176. [34] Ronald L Rivest, Adi Shamir, and Leonard Adleman. “A method for obtain- ing digital signatures and public-key cryptosystems”. In: Communications of the ACM 21.2 (1978), pp. 120–126. [35] Santander, Oliver Wyman, and anthemis group. “Banking on Blockchain: A Value Analysis for Investment Banks”. In: 2015. url: http://santanderinnoventures. com/fintech2/. [36] R. Schollmeier. “A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications”. In: Proceedings First Inter- national Conference on Peer-to-Peer Computing. Aug. 2001, pp. 101–102. doi: 10.1109/P2P.2001.990434. [37] David Schwartz, Noah Youngs, and Arthur Britto. “The Ripple protocol consensus algorithm”. In: Ripple Labs Inc White Paper 5 (2014). [38] Ken Shirriff. Bitcoins the hard way: Using the raw Bitcoin protocol. 2014. url: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw- bitcoin.html (visited on 02/05/2017). [39] Nick Sullivan. A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography. url: https://blog.cloudflare.com/a-relatively-easy- to-understand-primer-on-elliptic-curve-cryptography/ (visited on 04/02/2017). [40] Melanie Swan. Blockchain: Blueprint for a New Economy. O’Reilly Media, 2015. [41] Stefan Thomas and Evan Schwartz. “A protocol for interledger payments”. In: URL https://interledger. org/interledger. pdf (2015).

54 [42] David Treat et al. “Banking on Blockchain: A Value Analysis for Invest- ment Banks”. In: Accenture and McLagan, 2017. url: https : / / www . accenture.com/t20170120T074124__w__/us-en/_acnmedia/Accenture/ Conversion-Assets/DotCom/Documents/Global/PDF/Consulting/Accenture- Banking-on-Blockchain.pdf#zoom=50. [43] Bj¨ornWilke. Aktie- och fondhandboken: L¨ardig spara i aktier och fonder f¨or en b¨attre privatekonomi. Aktiespararna Kunskap, 2014. [44] Aviv Zohar. “Bitcoin: Under the Hood”. In: Commun. ACM 58.9 (Aug. 2015), pp. 104–113. issn: 0001-0782. doi: 10.1145/2701411. url: http: //doi.acm.org/10.1145/2701411.

55