UPTEC F 17041

Examensarbete 30 hpJuli 2017

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

blockchain

Alessandro Piccolo

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Distributed ledger technology in the capital market

Alessandro Piccolo

This master thesis explores how blockchain technologies can be utilized within the financial sector with focus on how to store both private and public information on the blockchain. The capital market is looking into ways of cutting down administrative work through streamlining the financial process by using blockchain technologies. Public key encryption together with hash functions and a consensus mechanism make up the basis for creating a shared trustless database system. The thesis was conducted by extensive 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 design which suggests how to utilize blockchain technologies in order to create private transactions. The design solves issues regarding key management and how to handle both private and public information on the blockchain. The proposed design is an extension of Visigon's existing permissioned blockchain, and it introduces different roles within the peer to peer network as well as a concept of having regulating nodes that 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.

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

Popularvetenskaplig sammanfattning

Detta examensarbete ar gjort i samarbete med Visigon for att battre kunna forstahur man kan lagra bade privat och publik finansiell information med hjalp av block-kedjeteknik. Syftet med blockkedjeteknik for banker ar att revolutionera post-tradedelen av deras system for att minska administrativa kostnader och sakerhetsstallaatt alla banker har samma overblick av det finansiella landskapet.

Examensarbetet fokuserar pa hur banker inom den den nordiska kapitalmarkna-den kan nyttja blockkedjeteknik for att lagra tillgangar i en gemensam databas.Blockkedjeteknik ar en distribuerad databas som garanterar att lagrad data aroforanderlig, vilket innebar att de som delar pa databasen inte behover ta hansyntill att nagon skulle kunna andra pa befintlig information. Blockkedjetekniken kankomma att ersatta beprovade tekniker inom transaktionshantering som for exem-pelvis varde-pappershandel. For att en transaktion ska bli lagrad pa blockkedjansa skall transaktionen forst godkannas av majoriteten av bankkonsortiet som styrblockkedjan.

Andra anvandningsomraden for blockkedjeteknik ar vid lagring av personliga upp-gifter sasom ID, e-Halsa, kontrakt och lan. Det finns aven mojlighet att skotamicro-transaktioner mellan maskiner.

Ett krav som banker har ar mojligheten att dolja innehallet av en transaktionfor andra deltagare i natverket. Detta medfor svarigheter, da blockkedjeteknikenar designad med andamalet att all information skall vara publik for de involve-rade aktorerna. Examensarbetets syfte ar att undersoka alternativa losningar ochforesla en design pa hur detta problem kan losas. Designen grundar sig pa sakerkommunikationsprotokoll och kryptografi.

Avslutningsvis ar slutsatsen att blockkedjeteknik har mojligheten att vara kataly-satorn for att skapa ett nytt paradigm for hur vi hanterar och lagrar information.

Contents

1 Introduction 11.1 Problem Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Objective & Research Questions . . . . . . . . . . . . . . . . . . . . 21.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 42.1 Basic Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Bitcoin Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Bitcoin Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Bitcoin Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6 Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7 Forks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8 Double Spending Attacks . . . . . . . . . . . . . . . . . . . . . . . . 102.9 Permissioned Chains . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Theory 113.1 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Merkle-Patricia Trie . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Advanced Cryptography . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.1 RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.2 Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . . 163.3.3 Lamport Signature . . . . . . . . . . . . . . . . . . . . . . . 183.3.4 Paillier Cryptosystem . . . . . . . . . . . . . . . . . . . . . . 19

3.4 Future Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4.1 Cryptographic Obfuscation . . . . . . . . . . . . . . . . . . . 193.4.2 Zero-Knowledge Proof . . . . . . . . . . . . . . . . . . . . . 203.4.3 Bitcoin: Account Linking Problem . . . . . . . . . . . . . . 203.4.4 Ring Signature . . . . . . . . . . . . . . . . . . . . . . . . . 203.4.5 Homomorphic Encryption . . . . . . . . . . . . . . . . . . . 21

3.5 Key-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.1 Wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.2 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.3 Bitmessage . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.4 Internet Certificate . . . . . . . . . . . . . . . . . . . . . . . 223.5.5 Secure Sockets Layer & Transport Layer Security . . . . . . 23

4 Literature Review 234.1 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Quorum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Corda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Ripple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Design 305.1 Visigon’s Blockchain Project . . . . . . . . . . . . . . . . . . . . . . 305.2 Design Aims & Requirements . . . . . . . . . . . . . . . . . . . . . 325.3 Design Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3.1 Observer, Voter, Creator & Regulating Nodes . . . . . . . . 335.3.2 Account & Storage Sharding . . . . . . . . . . . . . . . . . . 345.3.3 Public & Private Transactions . . . . . . . . . . . . . . . . . 355.3.4 Transaction & Block information . . . . . . . . . . . . . . . 355.3.5 Transaction Process . . . . . . . . . . . . . . . . . . . . . . . 365.3.6 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.3.7 Key Management . . . . . . . . . . . . . . . . . . . . . . . . 385.3.8 Malicious Attacks . . . . . . . . . . . . . . . . . . . . . . . . 40

6 Discussion 416.1 Existing projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1.1 Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.1.2 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.1.3 Quorum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.1.4 Corda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.1.5 Ripple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.1.6 Comparison between Design Choices . . . . . . . . . . . . . 45

6.2 Proposed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.2.1 Main Design Features . . . . . . . . . . . . . . . . . . . . . . 486.2.2 Difficulties & Trade-Offs . . . . . . . . . . . . . . . . . . . . 49

7 Conclusions 50

1 Introduction

The Nordic capital market uses a centralized backend system for keeping track oftransactions and who owns what. This system requires a huge amount of adminis-trative work to function properly. The administrative process can be automated byusing a technology called blockchain, which is a trustless distributed ledger tech-nology. It is estimated that a decentralized database system such as blockchainwould save banks up to 10 billion dollars annually, due to the fact that processeswould be streamlined which in its turn reduce administrative work [42]. This isa conservative estimate and there are those who claim that it can cut costs evenmore [35]. However, the system is not truly trustless since it requires some levelof trust by the user in the system. Blockchain technology has the possibility tobe 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 inFigure 1 for data access and storage. This thesis suggests that the Nordic capitalmarket should use a permissioned blockchain which would imply that only a smallnumber 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 reducingadministarive 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 marketusing a distributed P2P ledger technology. The information flow is displayed bythe connecting lines.

1

1.1 Problem Discussion

Blockchain technology offers a solution to the problem of knowing that differentdatabases are synchronized. The current financial market can be viewed in moredetail in Figure 2 and the same market using an integrated blockchain can be seenin Figure 3. A permissioned blockchain has great potential in cutting down admin-istrative work. Although, there are technical difficulties that needs to be resolvedbefore a revolution in the financial market can occur. One of these problems isthat 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 whatdata should be private, aspects regarding key management and technical methodsfor reporting to authorities.

2

Figure 3: The permissioned blockchain overview system that would replace thecurrent 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 researchabout the subject as well as a literature review to understand current solutions tohow to store both public and private information on the blockchain. This thesisalso 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’sblockchain architecture works. It looks into topics such as the transaction process,consensus mechanism, how to handle forks, double spending attacks, immutabilitythrough hashes and permissioned chains. The following section is about advancedconcepts such as smart contracts, Merkle-Patricia trie, different encryption meth-ods, key-management and Internet certificates. Thereon, a literature review ofexisting 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 ornot blockchains are an appropriate database for the financial sector.

3

2 Background

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

2.1 Basic Cryptography

This section will start by explaining some simple theory about cryptography, whichwill be useful for understanding blockchains better. In cryptography the plaintextrefers to the information in its normal form denoted by variable m, while theciphertext 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 beingeasy to compute but computationally hard to reverse. Public key encryption isbased on one-way functions [12].

A hash function, h(m), is a one-way function that generates a unique output givena random sized input. The output is deterministic for a given input since it followsa certain algorithm. The hash function’s output should be unique for each uniquegiven input, this implies that two different messages should not have the sameoutput. Given m1 6= m2 then equation (1) should not uphold or it should at leastbe hard to find such an example. Such examples are called collisions. Variable xin 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 withthe hash of a plaintext and a private key. The signature is denoted by variables and the private key is represented by kprivate. The hash is encrypted with theprivate key.

S(kprivate, z) = s (2)

The receiver can verify the signature by using a verification function which dependson the signature and the public key kpublic. Basically, the receiver can validate thesignature 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 thatone 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 timestamp and data regarding the different transactions such as the sender, the re-ceiver, the amount of Bitcoins to transfer and a transaction time stamp. Thecurrent Bitcoin’s blockchain is 100 GB with a total of 5 · 105 blocks with a newblock added to the chain every 8 minutes (2016-01-28) [8]. Each block is linkedto the previous block through cryptography using a hash function called SHA256.The hash-linkage outputs a unique sequence of hashes which means that a smallalteration within a block will propagate through the subsequent blocks modifyingthe successive hash sequence. This in turn makes it easy to keep track of differentversions and identify fraudulent blockchains [32]. More details about the differentcryptographic 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 calledminer, in the Bitcoin network selecting a number of valid transactions into a block.Valid transactions are where the sender controls enough assets. The sender needsto prove that he possesses these assets by creating a cryptographic signature usingthe corresponding private key of the asset. The miner validates the transactionsagainst his own local version of the blockchain [28]. The miner needs to win themining process to put up the newly created block on the blockchain. The miningprocess is a part of the Proof of Work consensus algorithm that Bitcoin uses. Thewinner 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 blockson the blockchain [10].

The miner enters the mining process by hashing the transaction data together withthe previous block’s hash and by adding a random integer called nonce (numberused 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 hisodds by changing the nonce value and recomputing the hash. The probability ofwinning 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 alsoprevents Sybil attacks. The Sybil attack tries to overtake a reputation system suchas 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 theblockchain [14]. The required average number of hash operations will increase sincehardware become more efficient at computing the hash of the block. The thresholdis adjusted so that the creation of a block takes roughly ten minutes, the difficultybecomes harder with a lower threshold. The winner will get all transactions feeswithin the block as well as some newly created Bitcoins. The amount of newlycreated Bitcoin is going down and the creation of new Bitcoins will cease to exist in2140 [2]. The blocks also store a timestamp for each transaction which enforces astrict chronological order. This means that transactions can not be removed fromthe blockchain and that each Bitcoin in the transaction is only spent once. Themain purpose of the mining process is to prevent double spending attacks whichis explain in further detail in section 2.8 [44].

Data that is on the blockchain can not be removed or altered since it would changethe block’s hash which would then invalidate all following blocks’ hashes. This link-ing system makes the blockchain robust against changes in the blockchain. Thissystem 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 leastfive additional blocks have been put on the longest fork. Forks are explained insection 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 transactionsto put in their block, and validate them against their own blockchain. Each minertries to solve a difficult mathematical problem for its block. The winning blockis 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 theblockchain. The recently approved block’s hash is going to be used by the minersin the following mining process.

2.3 Bitcoin Cryptography

Bitcoin uses a one-way hash function called SHA256 which stands for Secure HashAlgorithm 256 bit during the mining process. Computing the plaintext of the hashis 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 anunique identifier. The private key is generated from a large random number. Theprivate key is normally a 256 bit in hexadecimal which is 32 bytes or 64 charactersin range from 0-9 or A-F. The public key is generated by using a method calledElliptic Curve Digital Signature algorithm (ECDSA) from the private key (whichis a large random number). The Bitcoin address is then generated by hashing thepublic key using SHA256 or RIPEMD160 and then using a custom Base58Checkencoding. 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 theBitcoin address.

Each bitcoin (the coin) is represented by a Bitcoin address. The ownership of abitcoin is confirmed by the owner creating a signature using ECDSA which useselliptic curve arithmetic on the message, the corresponding private key, and arandom number. The signature can be validated by any user using elliptic curvearithmetic together with the public key. The private key is essential in keepingtrack of Bitcoin ownership and is therefore important to be kept secret to avoidtheft. The signature depends on the unique transactions plaintext which makes itimpossible 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 inFigure 5. All the supplied Bitcoins in a transaction need to be unspent. UnspentBitcoins can be looked up by searching through the blockchain for references toyour 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 hasa 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 alsoinclude 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, 0BTC.

Complete anonymity cannot be achieved even if new key pairs are generated foreach transaction, since there will be linkage in transactions as seen in Figure 5which would reveal that the transaction sender owns certain Bitcoin addresses.There are storage and key-management programs called wallet, used for storingmultiple Bitcoin addresses and respective private and public keys. The private keyis stored in a Wallet Import Format by using a custom Base58Check encoding inorder to make it easier to copy [28]. Base58Check stands for Base 58 binary-to-textencoding 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 deterministicprotocol does not produce any forks, since it has a fast block finalization. Thereare 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 deterministicvoting system [6][28].

Different kinds of consensus models require different degrees of computationalwork. Proof-of-Work protocol impacts the climate negatively due to it requiringa lot of electricity. A conservative estimated power consumption average of theBitcoin mining network in October 2013 was 1 MW [29]. By 2020 it is estimatedthat it will consume as much as Denmark [14]. The carbon dioxide footprint willeventually become too large to be economically and environmentally sustainable.It is therefore important to reach consensus in an environmentally friendly way. Anadditional complication with the mining process is that mining companies move toplaces 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 blockis hashed, which serves as the transaction ID. All of the transactions will be pairedup 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 wehave created a Merkle tree. Now, if you would try to tamper with a transactionit would change the transaction ID and the ripple effect would successively alsoalter 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 solvethe hash problem at the same time. Both miners will put their winning blockon 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 canbe resolved. Miners will receive either one of the versions and continue workingas usual. The subsequent block that is put up on the blockchain will determinewhich version to keep. If the next block that is put up on the blockchain belongsto version A, then version B will be discarded. Transactions in blocks that wereput on the invalidated blockchain, and do not exist in version A, will be returnedto the pool of pending transactions.

9

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

The blockchain has a scoring algorithm such that users can keep track of whichblockchain version to work on. In general, the blockchain with the most numberof 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 lessdue to the scoring algorithm. The probability of a block being superseded goesdown exponentially as more blocks are put up on the blockchain. A miner thatreceives 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 ina block that use the same Bitcoins. However, this is easily detected by otherusers. Another attack is for Eve (malicious user), in order to send two transactionsthat use the same Bitcoins to different miners. This attack is prevented sincethe transactions will have different timestamps. Alice could also try to send outa payment to Bob, and simultaneously send the same amount back to anotheraccount controlled by her. She could then try to fork the blockchain and minefaster than the main blockchain. This is computationally costly since she has tomine 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 rowis 0.55 ≈ 3 % which is a low chance of success for Alice [22]. The Blockchainrobustness, due to the hash linkage in combination with time-stamping, makes itdifficult to do double spend attacks.

2.9 Permissioned Chains

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

Permissioned blockchains are more susceptible to hacker attacks since there areonly 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 extensivesecurity 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 largernumber of nodes which in its turn implies a more rigorous block validation. Fur-thermore, the scalability would be improved for a permissioned blockchain, sincefeatures such as Proof-of-Work could be replaced by simply stating that a blockwill be created with an even interval [14]. Nodes within the network could follow acertain protocol stating which node’s turn it is. This approach, in comparison withthe Proof-of-Work consensus used in Bitcoin mining, would also be less harmfulto the environment, see section 2.5.

3 Theory

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

11

3.1 Smart Contracts

Smart contracts, also called Blockchain 2.0, are enforced trustless contracts whicheliminates any ambiguities by enforcing certain rules by coding it into the blockchainarchitecture. 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 evenfurther. Some areas of application are financial derivatives such as options, differ-ent kinds of stock emission, automated tax collection, intellectual property, legalcontracts (also called smart legal contracts), handle access control to shared ac-counts, machine-to-machine commerce such as a washer buying its own detergentand so on [27].

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

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

Information that smart contracts use should be deterministic, such as that allnodes within the system use the same data. For example it is problematic ifone were to create an insurance contract that depends on the weather, since theweather is not deterministic. A way around this issue would be to use a trustedsource, an oracle which would store the right information on the blockchain. Thenagain 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 anentryway contract that forwards the call to the most recent contract version.

The most widespread smart contract platform out on the market, is the Ethereumblockchain which is discussed more in depth in section 4.1, but there are alsosmaller 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 isalso called a digital tree, radix tree or prefix tree), in order to store the balance ofaccounts (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 explainingthe 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 isused for the root hash so that the trie gets a cryptographic fingerprint, meanwhilethe storage structure resembles a Patrice tire [27]. The hash sum is not dependenton the order of updates but on the actual data. The trie is O(log(n)) efficient forinserts, lookups and deletes as the depth of the tree is bounded.

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

13

3.3 Advanced Cryptography

One of the main problems with cryptography is secure key distribution, whichwas partially solved by Martin Edward Hellman in cooperation with WhitfieldDiffie. 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 introducedshortly 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 turnuses a one-way function (easy in one direction and hard to reverse) and modulararithmetic.

3x mod 17 (4)

Will yield a number in between [0, 16]. This is also a trap-door function, sinceit is easy to compute the solution knowing x but hard to find x knowing thesolution. Hence, 315 mod 17 ≡ 6 is easy to compute meanwhile finding x from3x mod 17 ≡ 6 is difficult. Example, Alice chooses a private number x = 15and calculates 315 mod 17 ≡ 6 and sends it to Bob. Bob goes through the sameprocedure, x = 13 and sends the solution 313 mod 17 ≡ 12 to Alice. Alice andBob 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 mathbehind this is explained in section 3.3.1. Equations (6) triple equal sign standsfor a congruence relation which is explained as A ≡ B mod C is equal to Amod C = B mod C.

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

14

3.3.1 RSA

RSA public key encryption is based on modular arithmetics. The first thing to doin order to create a key pair is to select a maximum large number as arithmeticmodulo. Any calculation that results in a number larger than the maximum getswrapped around to a number in the valid range, this also prevents truncation er-rors. In RSA encryption the maximum number is derived from multiplying tworandom prime numbers. The private key is derived from the two prime numberstogether with the public key. The public key is chosen at random in the positiveinterval.

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 themodular base set to the maximum number n. The private key equation can bederived 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 usingbrute 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 functionof the RSA algorithm. Euler’s totient function calculates the integer k, which isalso called totatives of n, in the range 1 ≤ k ≤ n for which the greatest commondivisor gcd(n, k) equals to 1. Euler’s totient function of primes is easily calculatedby 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 primefactorization 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’stheorem 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 commondivisor is 1. A modified version of the equation (13) is used to derive the privatekey 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)

y =k · φ(n) + 1

e(20)

The public key x has to be a small odd number that does not share the samefactor as φ(n). The private key y and the prime numbers p1 and p2 should behidden. Only the public key and prime product n should be public, since theyare used for encryption. Although, RSA encryption might not be the ideal sys-tem for cryptography in the future since there are specialized algorithms that aremoderately successful in solving prime factorization, such as the Quadratic Sieveand the General Number Field Sieve. This leads to that the size of the keys needsto become rather large, which is not sustainable for mobile phones and other lowpowered devices, since they have limited computational power. The conclusion isthat 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 versionof the curve is displayed in Figure 8. Bitcoin uses a specific elliptic curve calledsecp256k1, with equation y2 = x3 + 7.

y2 = x3 + ax2 + bx+ c (21)

The solutions are not ellipses, instead the names comes from the integral usedwhen calculating arc length in ellipses. With a, b, c ∈ R equation (22) gives theintegral to solve.

16

Figure 8: Elliptic curve representation.

∫ b

a

1

x3 + ax2 + bx+ cdx (22)

Elliptic curves are cryptographically desirable because it is symmetric around thehorizontal 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 beexplained by choosing two points on the curve, A and B for instance, and drawinga line in between them. At the third intersection a second horizontal line canbe imagined, see the dashed line in Figure 9, which also shows the solution toA 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 manytimes an initial point is dotted with itself by only knowing the initial position andthe final positions. Hence, to figure out the number of dot operations requiredone would have to redo the dot process, n number of times until the same finalposition is reached.

Figure 8 shows a simplified version of the elliptic curve, in practice the range isfixed. All numbers above the maximum are folded in similar fashion as in RSAmodular arithmetic. The actual trapdoor function is called elliptic curve discretelogarithm 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 equationto use. Secondly, a public point on the curve needs to be chosen. The private keyis the variable n which denotes how many times the dot operation is used. Thepublic 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 teaspoonof water than to break a 228-bit RSA key. The energy needed to boil all wateron earth would be required to break a 228-bit elliptic curve key, which would beequivalent in using a 2380-bit RSA key [26]. The conclusion is that a smallerkey can be used for the same security when using elliptic curve keys. Large RSAkeys increase the security but decrease the cryptographic performance as well asan increase in storage making large scale key management cumbersome, this isdiscussed more in depth in section 5.3.7 [39].

3.3.3 Lamport Signature

Quantum computers threaten conventional encryption methods such as RSA, sincethey 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 onemessage if not combined with hash trees.

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

The signing process starts as usual by hashing the message into a 256 bit hashsum. Each bit is encrypted with one out of the 512 numbers that are the privatekeys. The pair number is chosen in regards to the bits value and the first or secondnumber in the pair is selected depending on whether the bit is zero or one. The 256times 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 andthe private key should not be used again.

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

There is a O(2n/2) probability of finding a preimage collision of operations under aquantum computing environment on a single execution of a perfect hash. Variablen 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 twociphertexts 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 withD(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 wouldbe equal to 0 or 1) with the regulators public key. The regulators would take theproduct of all received encrypted votes and present the solution without revealingany 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 ishidden. However, this is proven to be mathematically impossible [4]. On the otherhand, the indistinguishability obfuscation is proven in this article [16]. This wouldenable smart contracts to store private keys without any malicious user being ableto 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 bitmultiplication 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 knownsolution, without revealing any other information. Consequently, a bank couldprove that an account has enough balance in order to make a certain transaction.Zcash is based on a zero-proof knowledge consensus mechanism called SuccinctNon-interactive Arguments of Knowledge (zk-SNARK). More information can befound on Zcash’s homepage [20] for a more detailed explanation of how the systemworks.

Zero-proof knowledge could also be used for two-party smart contracts. Theamount of money that should be transferred is calculated by either party. Thecontract would receive the amount to transfer and a zero-proof knowledge ensuresthat the transfer is valid. This is also called an N-party smart contract which theHawk project is trying to create [23]. Ethereum is also trying to make zero-proofknowledge 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 connectedand possibly owned by the same person. Merge avoidance and the Cojoin protocoltries to solve this issue. The Cojoin protocol makes several accounts work togetherby requiring each account to fund one coin to newly created accounts in order tomake it hard to link the input address of a certain transaction back to the previousold user account. However, the financial market does not require anonymoustransaction 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 byanyone in possession of the respective private key. The ring signature does notreveal which of the private key was used. The signature is a list of values whichare mathematically linked together, each depending on the previous value. Theprivate key used for signing allows the user to add a seed to the input, in order tolet the output be a specific value. This in turn is used to close the list making thelast value becoming equal to the first. Ring signatures can be used for voting andidentity 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 ciphertextwithout decryption. It could be used in finance in order to update the balance ofan account without decrypting the content. Simple operations become slower, forinstance a Google search would take approximately 1012 times longer using thisprocess [17].

3.5 Key-Management

Having secure channels between nodes is essential for any application in needof encryption for the management and the distribution of keys. The followingsubsection 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 storingprivate keys. Deterministic wallets create private keys from a single secret seed.The private key would be calculated by hashing the seed together with a randomnumber. Another type of wallet is the Hierarchical Deterministic wallet which usesa tree model with different layers.

3.5.2 Flooding

Flooding is a fast network messaging method. Messages are not sent directly tothe receiver, instead the message is propagated throughout the network, eventuallyreaching the proper receiver. Basically, the sender sends the message to its closestneighbor which in turn does the same. This way the message will have taken theshortest 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 numberof times the message can be resent. The message is not resent back to the sendingnode.

3.5.3 Bitmessage

The Bitmessage architecture is based on a peer-to-peer network, each forwardingmessages on a best effort basis. It is used within the Bitcoin network which usesthe flooding technique together with encryption, in order to anonymize messagesas well as the sender and receiver. However, this slows down the network due toflooding of the network with messages that are sent in between thousands of nodesthat 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 similarto the hash lottery in the Bitcoin mining process. The sender has to hash themessage together with a nonce until it is below a certain threshold.

The first connection is made using the public address, same as in the Bitcoinprotocol. The message is encrypted with the corresponding public key and sentthroughout the network following the flooding network protocol. The sender ofthe message will get a notice of when the message is received. Messages whichdo not trigger any response are rebroadcasted into the network with a two daysinterval with an exponential backoff. The flooding protocol ensures that the senderand 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 decryptthe 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). ACare used to entitle the holder, such as a visa. PKC contain the public key of theholder which is used as proof of identity. The certificates should hold the standardcryptographic 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 themselvesto other parties so that secure channels can be established for private messagesand key exchanges. In other words, certificates prove that a signature belongs toa certain entity. Certificates should only be valid for a certain period and thenrenewed, 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 thesigned document with the corresponding public key, and the output should beequal to the original documents hash. The private key can be stored together withthe certificate in an archive file format such as pem or PKCS#12.

The issuing certificate authority needs to be trusted by other involved parties forits 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 bottomof the certificate tree) are dependent on above issuers trustworthiness since eachcertificate 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 entirecertificate hierarchy tree [19].

3.5.5 Secure Sockets Layer & Transport Layer Security

Secure Sockets Layer (SSL) and The Transport Layer Security (TLS) are publickey infrastructures (PKI). TLS is based on the SSL, but more secure. Their maintasks are to create, manage, distribute, use, store and revoke digital certificatesand 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 secureencrypted channels between a server and a client. The TLS protocol could also beused in a peer-to-peer real time communication network. Some differences betweenSSL and TSL is that the SSL handshake protocol initiates its connection to a portand the TLS will first connect insecurely, and later on enable encryption.

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

4 Literature Review

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

Quorum, Corda and Ripple are projects within the financial sector that use blockchaintechnologies. The Corda project is developed by a consortium of over 70 of theworld’s largest financial institution with R3 in the lead. J.P Morgan’s blockchainproject is the Quorum project which also aims to hide private information whilestill utilizing the full potential of the blockchain technology. Ripple’s investorsinclude globally recognized venture capital firms and strategic investors. PwC hasestimated 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 contractcreation and enables developers to build applications on top of Ethereum. Eachcontract’s code is executed in the Ethereum Virtual Machine, partially isolatedfrom 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 usesUnspent Transaction Output (UTXO) that can be spent as an input in a newtransaction. An account has a 20 byte address, a nonce (a counter used to makesure each transaction can only be processed once), the current ether balance, andit 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 ownedaccounts which are controlled by private keys and have no code. The second typeis a contract account which contains code that an externally owned account canactivate by creating a transaction with the receiver set to the public address ofthe contract account. The contract account is allowed to send messages to othercontracts.

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

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

24

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

4.2 Quorum

J.P. Morgan’s blockchain project is called Quorum, which is built upon Ethereum’ssolutions. 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 serviceby enabling transactions on the blockchain to be private. The private transactionis 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, theTransaction Manager module and the Enclave module. The Enclave’s purposeis to strengthen privacy and security by managing encryption and decryption inan isolated way, it can be seen as an isolated virtual Hardware Security Mod-ule. Both messages and private transactions are encrypted by using the Enclavescryptographic functions. Hence, the Enclave handles symmetric key generationand data encryption as well as decryption. Transaction privacy is handled bythe Transaction Manager module. The Transaction Manager stores data of pri-vate transactions in the form of ciphertext, and handles access to the differentencrypted payloads. Only the private transaction’s hash is stored in a block. TheTransaction 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 allthe nodes within the permissioned blockchain. The majority voting protocol iscalled QuorumChain. Nodes within the network have the possibility to validatepublic 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 totransfer, 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 auser 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 accessto it by adding the corresponding public keys in the transaction. The transactionis 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 Managerstoring the payload and requesting its associated Enclave, which validates thesender and encrypts the payload. The transaction request becomes a real transac-tion once the sender’s private key is validated. The Enclave encrypts the privatetransaction’s payload together with a nonce, using a newly created symmetric keyand the xsalsa20poly1305 library. As for the encrypted payload, it is hashed usingSHA3-512. The symmetric key is encrypted N number of times using public keysof the receiving nodes using curve25519xsalsa20poly1305. N stands for the num-ber of involved parties, such as sender, receiver and other specified accounts. TheEnclave 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 viaHTTPS to the involved parties’ Transaction Managers in an encrypted format.The receiving parties acknowledge when they have received the data. Only thehash of the encrypted private transaction’s payload, which is received from theConstallation module, is propagated throughout the network using Ethereum peerto 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 ablock, although private transactions are ignored if the node does not have thesymmetric key. In order to make sure that the node is a participant in the privatetransaction, the node may query the Transaction Manager whether the node hasthe 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 andsends the plaintext of the payload to the Transaction Manager, who validates thatthe sender has enough assets. If the transaction is valid, the involved parties willupdate their private databases.

The Quorum privacy design uses several properties of sharding techniques, such asdividing the database into two parts, a public and a private state database. Thelocal public state database will be the same for all nodes, meanwhile the privatestate 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 maybe reconstructed using the blockchain, with the premise of the node having theright keys [31].

26

4.3 Corda

The Corda project is led by R3, a fintech company that heads a consortium of over70 of the world’s largest financial institutions. R3 does not describe Corda to bea 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 inadministrative 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 eachactor 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’sEnclave 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 signingthe accepted transaction. A Notary can reject a transaction if a double spend hasoccurred. Only involved parties within the transaction are able to see the relevantdata. Hence, validation is made by the involved parties Notaries.

Corda uses a UTXO model which makes transactions structurally like Bitcoin’stransactions. Bitcoin addresses are similar to Corda’s states, which are atomicunits of information, meaning that they are either current (unspent) or consumed(spent). Each state is associated to a certain Notary. A transaction takes the hashof 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. Transactionsare not put into blocks, instead Notaries keep track of transaction ordering bytimestamping. The ledger is defined as a set of immutable state objects by usingMerkle trees, as within the Bitcoin architecture. A processed transaction turnsthe input states into consumed states, as well as sets the state output ownershipto 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 occurwhich would move the states to the same Notary. The Notary must receive thechain 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, whereasthe chain ends with the issuance transaction. All of the input states need to provetheir issuance transaction heritage. Some notaries receive more information thanthey should, such as information concerning earlier transactions that they havenot partaken in, and that is why Corda are trying to integrate a new softwarecalled Software Guard Extensions technology (SGX) to their Notaries. Further-more, Corda prevents double spending attacks by using a UTXO model, that is astate that is either spent or unspent. It is not possible to use the same state indifferent 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 modelalso increases privacy as one can not say how many states belong to a certainaccount.

Corda’s primary communication is handled by flows which are small multi-partysub-protocols similar to long lived threads, that may survive node restarts andupgrades. This enables transactions, as mentioned earlier, not to be broadcastedglobally instead they are transmitted to the relevant nodes. The partial ledgervisibility following having flows together with Notaries is still globally consistentsince states belong to a certain Notary. The nodes within the system have longterm stable identities which together with the network entry process prevent Sybilattacks. The network is similar to Tor’s concept of directory authorities. Toris a networking protocol that aims to make the user anonymous by using onionrouting, which is when the message is encapsulated in layers of encryption. Theencapsulated message is relayed around the network and each time it passes a nodeit 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.07 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 IntelCPUs (Skylake+). The new solution offers an instruction set enabling data to behandled privately without making any private information known to the hardwareowner. The hardware takes encrypted input data and returns the output withoutrevealing any sensitive information. The solution becomes similar to a multi-partycomputation or zero knowledge proof.

4.4 Ripple

Ripple aims to be the platform for cross-border payments on a global scale. Oneof its main features is that it is easy to integrate different actors’ networks into thesystem. Ripple mainly focuses on the capital market by offering banks fast, as wellas completely traceable and data-rich international payment services by couplingbanks together. A transaction process uses SWIFT/ISO messaging for managingfunds 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 sincethird parties are cut out, which also lowers the administrative costs that have beencalculated in order to save 60 %. Balances of accounts are recorded on ledgers, theledgers are automatically updated depending on successful transactions that passthrough 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 afterit 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 closedwhen it has passed the consensus process. The last closed ledger is identical forall nodes. The recorded states become unsure when there are open ledgers. Eachnode has a different Unique Node List (UNL) which is a group of server nodes thatparticipate in the validation process for that node. The consensus of a transactionis reached when the large majority of the node in UNL (trusted nodes) agree thatthe transaction is valid. The consensus process happens in rounds, so that validtransactions that were rejected have a second chance.

If malicious nodes try to pass invalid transactions, this will be noted since approvedtransactions are continually re-checked automatically. These malicious nodes willeventually become black listed. Spamming of transactions will be detected andignored by the system. Double spend attacks are prevented by the InterledgerProtocol (ILP) which encrypts and locks down the funds, and subsequently re-leases them simultaneously to the involved parties. One of the major features ofRipple is that it can integrate different ledgers through ”connectors”, see Figure10 [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 tostore both public and private information on the blockchain. Private transactions’payload should only be visible to the involved parties and at the same time berobust against fraudulent attacks, while still keeping the system as decentralizedas possible. The platform would unify banks and reduce administrative costs bysurpassing 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 handlingon the blockchain. Visigon’s blockchain project (VBC) was created by LudvigBacklund 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 developedby Jens Duvaldt, who has developed a new network architecture in collaborationwith 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 frameworkfor creating web applications in Java 8 released under Apache 2 License. Theproject integrates Spark through Maven, which sorts out the dependencies using apom.xml file. The network communication is handled by an asynchronous event-driven framework called Netty. Other nodes can join the peer to peer network iftheir IP is on the permissioned list. The API for VBC tries to follow best practiceswhen building RESTful Web Services. These frameworks allow the user to becomeboth a client and server. An overview of the blockchain architecture can be seenin Figure 11.

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

30

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

Figure 12: Shows the hierarchy of relationships between Nodes, Accounts andAssets 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 signingtransactions. A node can only handle accounts that they have the privatekey 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 senderpublic key, a timestamp and a hash of the payload. A transaction can beeither ordinary, emitting or empty. In general, transactions move assets inbetween 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 ofall accounts, previous block hash, a timestamp and the block hash.

• Blockchain - has the current blockchain height, the directory path of theblockchain (where to store the blocks) and a hashmap of which participantsare 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 tomake an order. The Order class is an extension of the Transaction class whichrequires the receiver to confirm that they accept the transaction before it can beexecuted. Basically, an order is put up on the blockchain and has to be acceptedby the receiver to be converted into a real transaction. This is a key functionalityregarding the post-trade part of financial applications. Future development willinclude 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 thereceiver, as well as which bank that has issued the transaction request, and at thesame time keeping the system as decentralized as possible.

The proposed design choices were made in regards to other existing projects suchas Bitcoin, Ethereum, Quorum, Corda and Ripple. The architecture is inspired bythese project concerning concepts such as the account and state storage shardingfrom Quorum and TLS for secure messaging. Other concepts are different roleswithin the network, regulators and flooding protocol. Future aims of VBC wouldbe 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. Observernodes, as the name suggests, would only be able to view the payload of transactionswhich they have the privilege to observe. Voter nodes participate in the consensusprocess and validate transactions. The creator node’s function is to create newblocks, containing the valid transactions. Creator nodes also need the privilege ofan 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 anoverview of different roles within the system can be seen in Figure 13. The systemwould still be decentralized as the roles within the network would be establishedby negotiations between financial institutions within the network. Thereafter, theroles 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 ofvalidating transactions privately and securely. Regulators to the core are special

33

privileged voting nodes, controlled by trusted institutes. These nodes facilitateinstitutional access to transaction data, such as certifying that the right amountof 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 ofregulator and maker nodes, in order to ensure scalability. New regulator nodescan successively be introduced into the system. The optimal number of regulatornodes should be empirically decided upon between the major banks.

Eventual disputes between banks, concerning for instance administrative issuessuch as the distribution of a stock, become easily solvable by querying the regulatornodes. Excessive querying of any regulator node would result in the querying nodebeing ignored for a certain time interval. Regulator nodes make the system morecentralized and burden institutions by keeping track of all accounts. However,these administrative issues are not expected to occur frequently since banks shouldalready be used to rigorous bookkeeping. The regulator should only be involved incase of emergency. The final authority is the regulator node. The system would stillbe decentralized regarding public transactions, while private transactions wouldbe semi-decentralized, due to the fact that different accounts are paired up withdifferent 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 privateaccounts. This is necessary in order to keep transactions completely private, asexplained in the the next section which concerns transaction processes. The vali-dation process is optimized by storing accounts’ balances in two different PatriciaMerkle 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 thekey value map with the balance stored in the node leaf. All account addresses areavailable 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 publickey and account address may be created. The account is randomly paired up witha regulator node, which in turn requests that the account is to be put up on theblockchain and thereby the account becomes globally known. Each node shouldstore 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 nodethat controls the account, otherwise any node could invalidate valid accounts. Fora node to invalidate an account globally it needs to show possession of the privatekey and store the information regarding which account is being invalidated on theblockchain.

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 allthe nodes within the system that have the right privilege (that is observer, voteror maker). Both public and private transactions are recorded on the blockchain,albeit the payload of a private transaction is encrypted with a symmetric key. Thesymmetric key is created and shared between the involved parties, thereby the pay-load is only visible to the involved parties. Private transactions are only validatedby 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 thekey management and hence the access to the customer’s account, which makes itimportant that banks are entitled to create and validate blocks.

Customers’ private keys are handled by their bank nodes. As customers are proneto 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 acustomer loses his/her private key, a new account would have to created and theold account would need to be invalidated. Furthermore, a regulator node wouldhave to transfer all assets from the old account to the new account. All theseinconveniences are avoided as the customer’s private key is safe with their banknodes, 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 tohis/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 hashand all the transaction data from inside the block for cryptographic linkage, publicPatricia Merkle trie roots for immutability, as well as a timestamp of when theblock was created. Each transaction should contain an individual timestamp aswell. The Patricia Merkle trie root accounts for which state the current accountsare in, so that different users may confirm that they are using the same versionsof 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 thetransaction. Additionally, private transactions have an optional data field so thatthe sender may specify which other parties should receive the symmetric key thatis 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 orderto hide the sender as well as the receiver. Banks have the possibility to deny theuser the transaction request, hence only valid transactions are propagated throughthe network.

All of the voting nodes participate in the consensus process by voting if the publictransaction is valid or not. At least 51 % of the voting nodes have to accept thetransaction for it to be valid. More than 51 % is not necessary since all of thevoting nodes are approved by the system, and closely monitored by the regulatornodes. There is also the risk of a voting node being offline, since then the totalreceived 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 forall the voting messages to arrive before finalization. Nodes have a finite time tovote, in order to ensure finalization of the transaction within a reasonable timelimit. Public transactions can be validated through a majority vote, without theregulating 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. Futureupdates of the system might include complex financial instruments which mightin turn require more information. All nodes update their public account databasewhen a new block is put up on the blockchain. Hence, the public account of thebalances is available to all nodes within the system. Transactions that exist onthe blockchain can not be withdrawn from the blockchain, however, they might berefunded since it is the banks that ultimately control the nodes.

Now onto private transactions. Information regarding private transactions is onlyavailable to the involved parties by requiring the possession of the symmetricsession key used to decipher the ciphertext of the transaction’s payload on theblockchain. Private transactions are validated by the involved parties, includinga regulator node. The ciphertext of the private transaction is recorded on theblockchain, hiding both the receiver and sender address. A private transactionmade 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 privateaccount 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 isstored 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 onthe blockchain. If the regulator node would discover malicious interference, thenit would invalidate the block. Double spending attacks of private transactionsare prevented by the fact that each account belongs to a certain regulator node.Thereby, attacks are prevented as the regulator node keeps rigorous bookkeepingof the transaction times as well as having a nonce such that the transaction is onlyprocessed once.

A private transaction is propagated through the network in an encrypted formatand 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 asa unique identifier. The metadata is also encrypted which ensures that the senderand the receiver remain anonymous.

A user can have multiple public and private accounts. To transfer assets from apublic account to a private account or vice versa, one has to go through anothertemporary 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 ofthe nodes would then need to know how much is taken from that account andthereby 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 toknow how much balance the sender has. To move assets from a public to a privateaccount, first of all, a public transaction needs to be performed to a semi-privateaccount. Thereafter, a private transaction from the semi-private account to theprivate account may be carried out. When moving assets from a private to a publicaccount, first of all a private transaction needs to be performed to a semi-privateaccount. Thereafter, a public transaction is created, however, it is only validatedby the semi-private account’s node and the corresponding regulator node.

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

5.3.6 Consensus

Valid transactions are picked up by creator nodes and collected into a block. Theblock 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 thenew block, this procedure is performed with the scope of eliminating forks. In thecase 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 blockto the blockchain. This process is supervised by the rest of the network, and anymalicious activity is hence prevented as the rest of the nodes ignore blocks fromthe abusive node creator. The creator node receives a confirmation from each nodethat they have approved the block. If no block is received within the approvedtime interval of block creation, then that node would be deemed to be offline andwould hence be ignored. Malicious attacks by creator nodes, that try to get theirblocks on the blockchain several times in a row, are ignored after being detectedby the rest of the network, especially by the rest of the creator nodes. Nodes havethe possibility to ask the network which current version of the blockchain to workon.

5.3.7 Key Management

Secure messaging is achieved by using a TLS protocol which is good for near realtime usage and distributing symmetric keys used for encrypting the payload ofprivate transactions. Messages should be written to disk until the receiver hasacknowledged that they received the message.

Accounts cannot be identified to belong to a certain bank. The bank nodes have toabstract 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 theaccount. 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 wouldreveal which account belongs to a certain bank. This implies that the bank hasto create secure channels dynamically between accounts. This would require a lotof public, private and symmetric keys. However, the key management should bepossible given the following example. With 20 million users and an average of twoaccounts per user, there are a total of 40 million accounts. If there are 10 majorbanks within the system, then each bank has to create 4 million Elliptic curvekeys which are each 256 bit (ECC256) long. The total creation time would beroughly 12 hours by estimating that the creation time is 0.01 s. The total storagefor a bank is the sum of the private keys belonging to the bank, and all of thelisted account addresses within the system. The total storage needed is therefore4 · 106 · 32 + 40 · 106 · 32 = 0.2560 GB. The key creation time could potentiallybe 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 validuntil the next key rotation is scheduled. The symmetric keys are created anddistributed by the sender’s node and are unique for the sender-receiver pair. Theassociated nodes keep track of the symmetric keys. The ciphertext of the yet tobe validated transaction is sent to all nodes through a flooding protocol so thatthe 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 itscorresponding regulator node should also receive the symmetric key used for en-crypting the payload of the private transaction. The following example estimatesthe creation time and the storage needed to handle large volumes of symmetrickeys. With a total of 20 million private accounts, 10 banks and an estimate of 500different account connections for each account, the average amount of connectionsrequired are equal to 20/10 · 500 + (20− 20/10) · 1/10 = 2 · 109. With 1/10 beingthe probability of an account connecting to one of the bank’s accounts. Assumingthat the creation time for one AES 256 bit key takes 0.1 ms yields a total creationtime of 56 hours per key rotation. One key rotation would require 2 · 109 · 32 = 65TB. Accounts with more than 500 connections would be directly handled by theaccount’s bank’s nodes, public and private keys, as well as its symmetric sessionkey. Albeit, this implies that the following transactions made can be linked to thebank. Users that have an account with more than 500 connections may pay anextra fee for keeping their account, remaining completely anonymous.

Key rotations should be made as frequently as possible by the bank. Creating andstoring keys adds an extra cost to the total system cost, which might be funded byadding a small transaction fee. After a key rotation is made, the keys should bestored 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 thecorresponding regulating nodes. If a private key of an account would be lost, thenthe regulating node would have to step in and transfer the account’s fund into anew account. For this to happen the bank needs to make an official request tothe system. On the other hand, a more serious case would be if the bank nodewould lose its private key. Then the bank would need to make an official requestmanually to the network, and bring sufficient identification to the system for itto regain its role. This process should not be automated since a bank should notlose one of its most valuable possessions, the private key. A node’s privilege couldbe revoked by an anonymous vote within the network, however, this would not beautomated 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 transactionsare more vulnerable since it would only be necessary to hack one bank and theregulating node, this would still be a difficult endeavor for the hackers. Maliciousobservers can leak information regarding sensible transactions if they have theright 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 leakedthe information. Hacked nodes could potentially be detected by having validationchecks of transactions. If a voting node becomes hacked, then it would be handledby other nodes’ cumulative voting power or the regulating node. Fraudulent votingnodes are detected if they frequently vote against the majority. Maker nodes arevaluable targets for hackers since they have the ability of creating invalid blocks,however, this should be prevented by regulators and possibly by other nodes thathave the rights to see and hence detect the invalid transactions. If a block wouldbe 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 detectthat an invalid transaction is passed as valid. Regulators can only vote, whichmeans that an invalid transaction is only processed if another bank is hacked aswell. There are several regulator nodes for making the system more decentralizedand also harder to exploit.

Important nodes should have multiple backup nodes connected to the blockchainnetwork, thereby the transactions could still be processed if a node goes offline. Anode that comes back after a period of being offline, would get the necessary in-formation from the blockchain. Information regarding private transactions wouldfirstly 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 thetransactions 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 certificateshanded out by Visigon’s server. A node can hence not be disguised as anothernode. This can be identified as a single point of failure if Visigon’s server becomeshacked, and hands out certificates while being hacked, and this could be preventedin multiple ways. All nodes within the system know all the possible actors withinthe 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 takethe server offline.

6 Discussion

A decentralized database system such as blockchain would save banks money byreducing administrative work and giving the participants a unified overview of thefinancial 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 dataon 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 moresuitable for other purposes. Blockchains are applicable for markets which requireshared databases, immutable objects, version handlers and where participants areequally distrusted. You might wonder why one could not simply use a centralizedshared relational database? There are several issues that arise from a centralizeddata storage such as the ownership, which country it should be stored in and therisk of the system being hacked due to it being centralized. Other questions thatneed to be answered are whether blockchains can handle transactions on a largescale, and who would manage access control.

Blockchain technology in its original context was created by Satoshi Nakamotowhen he made Bitcoin [28]. The foundation of blockchain technology is foundedon cryptography. One key attributes is public encryption, which allows accountowners to sign transactions with their corresponding private key proving that theyhave explicitly confirmed the transaction request. Another important attributeis the hash function. The hash function enables the possibility of a more robustsystem by linking blocks together and make transactions immutable by storingthem in Merkle trees. Basically, it boils down to having the core foundation builtby 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 willfocus on whether or not the platforms can handle financial transactions in regardsto 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 permissionedblockchain, and look up any public address’s balance. Hence, it is ill-suited forthe capital market since it does not support private transactions. Furthermore,accounts are pseudo-anonymized meaning that transactions are not made froman account, but from different public addresses that represent different numberof Bitcoins which cannot be traced to belong to any particular user. This is atrade-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 theirconsensus algorithm which wastes enormous resources and leaves a huge carbondioxide footprint. There will also be geopolitical issues due to miners moving theirbusinesses to regions with cheap electricity. The main positive feature of Bitcoinis 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 haveto find more complex, albeit it still wastes resources. Ethereum has been tryingto solve this problem by introducing Proof of Stake, but they have yet to achievethis. Smart contracts do not guarantee that the outcome is deterministic whichmight be problematic, since this is prone to attacks from hackers. Will the coderemain valid indefinitely, or will the meaning of the contract change after a fewyears? 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 tosuit the financial market by an addition of privacy features, remaking the consensusprocess and ensuring a higher degree of security. Smart contracts might be commonpractice in the future since they enable a dynamic and agile development of newfunctionality, as well as ensuring that the same logic is being executed on all thenodes within the network.

6.1.3 Quorum

When J.P Morgans blockchain project Quorum built their application they did notdo this from scratch, instead they used Ethereum’s platform as a base. Quorumhas its own peer to peer network, meaning that they are not part of the Ethereumnetwork. 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 orderto build a robust infrastructure. On the other hand, J.P Morgan will not have thesame control over the entire platform which is crucial when dealing with financialinstitutions 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 hardwarebased solution for increased security. The payload of the transaction is storedby the Transaction Manager, and only the hash of private transactions is addedto 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 withthe explicit goal of providing consensus compatible with legal notion of settlementfinality. Since the application has been built from zero this creates a situation oftotal control of development, and therefore the application can easily be adaptedto financial regulations. Corda does not rely on sharding for privacy, instead theapplication only enables private transactions, and not public ones, which simplifiesthe architecture. Relying heavily on Notaries managing the transaction process,and as as all transactions are stored as ciphertext, this makes the system morecentralized. The user has to truly believe that the Notaries are handled in theright way. Corda needs to keep backup of all Notaries since it is not possible torebuild 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 factthat one cannot know the exact balance of an account without the user explicitlyshowing possession of certain states. A UTXO model makes the architecture be-come more complex and burdens the system since new states with a correspondingprivate 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 conceptof directory authorities, which adds a layer of security to the network. Transactionsare not globally broadcasted but only shared with the involved parties, sender andreceiving Notary, of the transaction. This design choice was made in regards toCorda aiming to be a global platform and therefore it is important not to slow downthe 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 ledgertechnology. Instead, Corda combines the strength of Merkle trees together withrigorous timestamping in order to keep track of their transactions. This designchoice is favourable, however, misses out on extra robustness that block hash link-age offers in regards to immutability. Corda’s architecture does not allow usingblocks since only Notaries that are involved in a transaction know that the transac-tion exists. Corda uses techniques from blockchain, but does not store transactionswithin blocks. Furthermore, its system is rather centralized around Notaries whichimplicates that the application does not fall under the category of a blockchaintechnology.

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

6.1.5 Ripple

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

The main scope of Ripple is not to make transactions private, rather to enablefast intercontinental transactions. The Ripple blockchain is semi-permissionedsince 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 rightto validate transactions in the network. Using a semi-permissioned network asthis one, shows advantages as a design choice since it does not give the new nodesany power. Furthermore, the semi-permissioned design also makes it easier fornewcomers to join the network. However, this implicates that Ripple faces issuesconcerning legislations and regulations regarding bank secrecy and customer infor-mation protection, especially when looking at the global market, as hackers couldjoin the network for instance.

Ripple cannot offer complete privacy because of the design choice of UNL lists. Thelack of privacy is an issue as some nodes will possess great knowledge of differentaccounts’ balances. However, Ripple is supported by large financial actors suchas Bank of America, Santander and Bank of Tokyo-Mitsubishi UFJ. Furthermore,Ripple has large banks as clients such as SEB, RBC, Reise Bank, BBVA andmany more. Ripple’s network of financial actors, including its clients, proves thatdifferent actors on the market have accepted the lack of privacy implied by the useof Ripple. The design choice of UNL lists is beneficial financially as administrativework is automated, which in its turn decreases the risk of errors which can lead tocostly disputes. A substantial benefit of Ripple is that international transactionsare carried out only in a matter of seconds, this benefit seems to be the drivingfactor 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 willbe compared to each other. Firstly, Bitcoin’s architecture is created in order toenable 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 therebyparticipate in the consensus mechanism. The current design choices of Bitcoin failto meet the standards of the financial market. Mentioned standards that Bitcoinhas failed to achieve are for instance privacy, traceability (due to account addressesbeing hard to couple together with account owners), and exclusiveness (as any-one can join the network). Therefore, Bitcoin cannot be used as a platform forthe financial market. Moving on to Ethereum, the platform is similar to Bitcoin,however, the addition of smart contracts have worsen the prospects of being usedfor the financial market, due to the fact that the output of smart contracts arenot deterministic. Another negative aspect of Bitcoin and Ethereum is that theyboth use Proof of Work to reach consensus which lacks transaction finality. Inconclusion, neither Bitcoin or Ethereum are suited for the financial market.

45

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

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

The blockchains should be permissioned to eliminate the fact that only approvednodes should participate in the consensus process. For blockchains adapted to thefinancial market, the permission implies that access can be controlled and that isone of the reasons why Bitcoin, Ethereum and Ripple are ill-suited for this taskas 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 storeprivate information on the blockchain. Three alternatives are discussed in this the-sis; 1. To store the ciphertext of the payload in Transaction Manager module, andthe hash of the payload on the blockchain, 2. To dismiss the idea of blockchainand abstract the private transaction process into Notaries, and 3. To store theciphertext of the payload on the blockchain. The first option has been chosen forQuorum, 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 thepayment process. Thereby, the user has to trust that the technical environmenthandles transactions correctly.

Furthermore, there are implications with the third mentioned alternative used inthe proposed design for the VBC project. When the ciphertext is stored on theblockchain, 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 difficultfor the hacker to find which transaction to decipher since both the sender and thereceiver are unknown. The design choice is also motivated due to the fact thatVBC 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 theywould not be able to, initially, compete with Quorum and Corda on a global scalesince they are well funded. Another reason for the design choice is its simplicitywhich 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 nodessince they cannot decipher the encrypted payload. The proposed design enablesthe user to decide whether they want a more secure private key, which would takean even longer time for the hacker to decipher. This feature could be used to hidetransactions involving assets that are kept for a longer period of time. The extracosts 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 abstractedas Quorum and Corda do, then regulators would have to take a more significantrole within the system, and store the payloads on a separate ledger. This scenariowould make the system even more centralized and regulators would be similar toEnclaves and Notaries.

Corda has an advantage over Quorum, since it is more adapted to the financialmarket and has support for smart contracts. Smart contracts are favorable sincethey enable agile development of new financial derivatives, which is somethingthat VBC aims to achieve as they enable any financial assets to be traded on thesystem. Quorum is still under development and is largely based on Ethereum dueto being hurried into the market to gain the first mover advantage. The VBCshould 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 theblockchain concept alive and make slight alterations to adapt the project into thefinancial 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 properfunctioning network. The current VBC network is under development and it issupposedly 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 orderto lay out a detailed plan for the implementation of the proposed design. Theproposed 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, whichare handled through certificates. Another main concept in the proposed designis to store transactions into immutable linked blocks and discarding the miningprocess. If the mining process would have been kept, it would have implied awaste of valuable resources as well as an increase of the carbon dioxide footprint.Thirdly, private transactions are validated and visible only to the involved partiesby a shared AES symmetric key. The system in the proposed design uses ECCkeys within the TLS protocol together with Internet certificates for secure com-munication and a flooding protocol to hide the sender of the transaction. ECCseems to be gaining support from various projects such as Bitcoin, Ethereum andRipple. Furthermore, it also takes a longer time to crack an ECC key comparedto a RSA key of the same length. The future could be to use Lamport signaturesto protect against the threat of quantum computers.

The proposed design keeps track of accounts’ balances together with a nonce toensure 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 transferredbetween public and private accounts anonymously. Regulators should be presentin every transaction with the purpose to facilitate institutional access and governtransaction 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 arestored 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 inorder to store private keys safely together with hardware encryption, to protectagainst hackers.

As mentioned, Ripple’s traceability is also something to be desired. The proposeddesign solution is to introduce regulating nodes which purpose is to validate privatetransactions and at the same time ensure traceability. The design makes themajor users and financial institutions become active managers of the system, seeregulating nodes, giving them more incentive to make it secure. The proposeddesign hides the connection between an account and a bank and keeps both publicand 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 beconsidered. The current design is a permissioned blockchain which is an oligopolyof who controls the blockchain. The proposed design still allows any user to jointhe 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’ nodesto a certain degree, as the blockchain becomes more centralized, although it isbeneficial in order to reach a consensus between major financial institutions. Per-missioned blockchains are more susceptible to hacker attacks since there are onlya few central nodes of power. Nodes would protect against eventual downtimeby having multiple backup nodes. Malicious nodes are handled by other financialinstitutions, 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 networksince 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 moreinfluence over the system. The malicious nodes should instead be ignored for aperiod of time and be given an official warning. Presumably, it is implausible fora hacker to have enough resources in order to penetrate several banks’ extensivesecurity protocols.

49

The design does not use Bitcoin’s UTXO model, instead the concept used by theproposed 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 itincreases privacy, due to fact that a transaction can be validated without knowingexactly the account’s balance. Although, The UTXO model does not offer com-plete privacy since the validating nodes needs to know the transaction history ofthe 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 blockchainversion to keep working on. Since permissioned nodes are not that many, and thereis no reward for them, they could reach an agreement by simply waiting to puttheir block up on the blockchain after a randomized time interval. As a result thatthe blockchain cant be forked is that transactions are finalized when they havebeen 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 theusers need to trust the regulating node to validate the transactions. The regulat-ing nodes make the system more centralized, although there are several regulatingnodes 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 publicaccounts, these are faster, have better traceability, and are more secure comparedto private accounts. This is due to the validation process being decided by amajority vote within the permissioned network. Private transactions are slowersince they need at least one regulating node to validate the transfer. Transactionsin between public and private accounts make it harder to trace the transaction’sorigins.

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 payloadsfrom both public and private transactions are recorded on the blockchain. How-ever, blockchain technology has the potential to be the next disruptive technologyfor general storage. A possible alternative route would be to take the best featuresof blockchain, such as, for instance, the immutability aspect and abstracting theentire transaction process. Another conclusion is that it is important to take legis-lations into careful consideration while developing the platform. When developingblockchains 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 whenchanging 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. Beforeimplementing the proposed design into the VBC project, several aspects need to beimproved 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 toenable that communications between nodes could not be traced to a certain bank.The message would be repeatedly encrypted in an onion-like fashion. Albeit, thiswould be at the cost of higher latencies for the network.

Future solutions for reaching consensus might involve proof of stake or zero-proofknowledge (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 anaccount has enough balance without revealing any important information. Themost known zpk is the zkSNARK algorithm but it has some security issues sincethe 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 deemednot secure in the future. One of these threats are quantum computers, which couldbe countered by using Lamport signatures. Furthermore, smart contracts might bea way forward for banks in order to easily create new financial instruments. How-ever, there might be unforeseen complications with creating new types of smartcontracts. Hence, this might be implemented after Ethereum is deemed to be safe.Smart contracts would create a dynamic environment for other sectors to coupletheir system with the blockchain governed by banks. Another design choice to betested is to let secure hardware take care of the consensus process (Hyperledgerand Corda are looking into this). Blockchain technology is still in its infancy andwhat 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 supportthroughout the project. I also wish to express my gratitude towards Jens Duvaldtfor his insight and many workshops in helping me become a better developer. Ithas 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 inthe 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 on04/03/2017).

[8] Blockchain info. url: https : / / blockchain . info / charts (visited on01/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 RealSystems, 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: IEEETransactions 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 onBlockchain 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 certificateand 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 thekey 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-spendingFast Payments in Bitcoin”. In: Proceedings of the 2012 ACM Conference onComputer 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 andprivacy-preserving smart contracts”. In: Security and Privacy (SP), 2016IEEE 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 Thome. “Universalsecurity; from bits and mips to pools, lakes-and beyond.” In: Number theoryand 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 cryptosystemand 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 Bohme Nicolas Christin and Tyler Moore. “Bit-coin: Economics, Technology, and Governance”. In: Journal of EconomicPerspectives 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: Communicationsof the ACM 21.2 (1978), pp. 120–126.

[35] Santander, Oliver Wyman, and anthemis group. “Banking on Blockchain: AValue Analysis for Investment Banks”. In: 2015. url: http://santanderinnoventures.com/fintech2/.

[36] R. Schollmeier. “A definition of peer-to-peer networking for the classificationof 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 protocolconsensus 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 CurveCryptography. url: https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ (visited on04/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] Bjorn Wilke. Aktie- och fondhandboken: Lar dig spara i aktier och fonder foren battre 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