Graduado en Matemáticas e Informática
Universidad Politécnica de Madrid Escuela Técnica Superior de
Ingenieros Informáticos
TRABAJO FIN DE GRADO
A Comprehensive Survey on Blockchain’s Technology
Autor: Alejandro Esquivias Cañadas Director: Dr. Kashif Sharif
BEIJING, JUNIO 2019
Acknowledgments This thesis was done in collaboration with Beijing Institute of Technology, with Dr. Kashif Sharif as the supervisor and with the help of Biswas Sujit. I would like to thank my family for all the support, Andrea for the help with the cryptography part as well as the constant support she gave me. Last but not least I would like to thank all the friends (Dani and Omar particularly) I have shared good memories with and have helped me during these years.
CONTENTS I- INTRODUCTION ............................................................................................................... 1
1. Overview of Thesis ............................................................................................................ 1
2. Motivation ......................................................................................................................... 2
3. Contributions ..................................................................................................................... 2
II- BLOCKCHAIN TECHNOLOGY INTRODUCTION ................................................ 5
1. Blockchain overview .......................................................................................................... 5
1.1- Difference between symmetric and asymmetric encryption ..................................... 6
1.2- Overview of Blockchain’s mechanism ...................................................................... 7
1.3- Public and Private Blockchain .................................................................................. 8
2- Transaction structure ............................................................................................................ 9
2.1- Transaction Structure in Bitcoin .................................................................................... 9
2.2- Transaction structure in Ethereum ............................................................................... 10
2.3- Transaction Structure in Hyperledger .......................................................................... 10
3. Block Structure ............................................................................................................... 10
3.1- Block Structure in Bitcoin ........................................................................................... 10
3.2- Block Structure in Ethereum ........................................................................................ 12
3.3- Block structure in Hyperledger .................................................................................... 13
4- Example of transaction processes....................................................................................... 14
4.1- Transaction in Bitcoin .................................................................................................. 14
4.1.1 Types of transaction ................................................................................................... 17
4.2- Transactions in Ethereum ............................................................................................ 19
4.2.1- Transfer from one EOA to another EOA: ................................................................. 19
4.2.2- Deploy a contract on Ethereum Network .................................................................. 19
4.2.3- Execute a Function on a Deployed Contract ............................................................. 20
4.3- Transactions in Hyperledger ........................................................................................ 21
III- SECURITY IN BLOCKCHAIN AND ITS APPLICATIONS .................................. 23
1- Hash functions ................................................................................................................. 23
1.1 - Hash Codes ........................................................................................................... 23
1.2- Compression Functions ................................................................................................ 24
1.3- Collisions ..................................................................................................................... 24
2. Standard use of hash functions in cryptography ............................................................ 25
2.1- SHA 256 in Bitcoin and Hyperledger Fabric ............................................................... 25
2.2- Attacks on SHA 256 .................................................................................................... 27
2.3- Keccak 256 in Ethereum .............................................................................................. 28
2.4- Attacks on sponge functions ........................................................................................ 29
3. Elliptic Curve Cryptography ............................................................................................. 31
3.1. Basic Overview of Elliptic Curve Cryptography .................................................... 31
3.1.1- Elliptic curves over Fp ............................................................................................... 32
3.1.2- Elliptic curves over F2m ............................................................................................. 33
4. ECDSA (Elliptic Curve Digital Signature Algorithm) ......................................................... 33
5. Blockchain Applications................................................................................................... 34
5.1- Blockchain in IoT ........................................................................................................ 35
5.1.1- IOTA ......................................................................................................................... 35
5.2- Atonomi ....................................................................................................................... 36
5.3- Blockchain in government Services ............................................................................. 36
IV- CONSENSUS ALGORITHMS ......................................................................................... 38
1. Bitcoin’s Proof Of Work ................................................................................................... 38
1.1. History ..................................................................................................................... 38
1.2. Dwork’s and Naor’s Pricing Functions ................................................................... 38
1.3. Adam Back’s work .................................................................................................. 39
1.4. The Hashcash cost function ..................................................................................... 40
1.5. Critiques and Limitations ........................................................................................ 41
2. Ethereum: From Proof of Work to Proof of Stake .......................................................... 42
2.1. Ethereum’s terminology .......................................................................................... 42
2.2. Proof Of Stake (PoS) ............................................................................................... 43
2.3. The Byzantine Generals Problem ............................................................................ 44
2.4. Ethereum Casper ..................................................................................................... 47
2.4.1. The CBC Protocol ................................................................................................... 47
2.4.2. Casper FFG ............................................................................................................. 49
3. Hyperledger’s Kafka ........................................................................................................ 51
3.1. Hyperledger Fabric .................................................................................................. 51
3.2. Kafka in general ...................................................................................................... 52
3.3. Kafka in Fabric ........................................................................................................ 53
4. Conclusions on consensus algorithms ............................................................................. 54
V- APPLICATION .................................................................................................................... 56
VI. FINAL CONCLUSIONS .................................................................................................... 59
VII- BIBLIOGRAPHY ............................................................................................................. 60
1
I- INTRODUCTION
1. Overview of Thesis
Index terms: Proof of Work, Proof of Stake, Byzantine Generals Problem, Bitcoin, Ethereum, Hyperledger Fabric, Hash Functions, Hash Collisions, Sponge Functions, Elliptic Curve Cryptography, Consensus, IoT. Blockchain is a technology that has been gaining attention lately. When this was written there were over 1600 different cryptocurrencies and 33 % of the bankers [45] expect commercial blockchain adoption by next year. It is imperative that we understand this technology, which is sure to be in our near future. In this work, we will focus on Bitcoin, Ethereum and Hyperledger Fabric, because they are respectively: a blockchain based purely on Proof of Work, a blockchain that is on the verge of transitioning from Proof of Work to Proof of Stake, with two main projects and a private blockchain. This thesis is organized as follows: In Chapter II, we present Blockchain technology on a general level. This is done by first explaining key concepts such as symmetric and asymmetric encryption and then explaining blockchain’s general mechanism. Secondly, the internal structure of a block and the internal structure of a transaction are presented for the Bitcoin, Ethereum and Hyperledger Fabric respectively. We conclude this section by showing specifically how a transaction works step by step in these three technologies. In Chapter III, we look into the cryptographic component of blockchain and its potential for application. We start by discussing hash functions, which are a fundamental concept and from where part of blockchain’s security is derived. Once, we have introduced hash functions, we move on to hash functions in cryptography. SHA-256 and Keccak-256 with sponge functions are treated in this section. The cryptographic section is concluded by talking about Elliptic Curve Cryptography. Lastly, we explain three key applications, relating the application to current projects or research. Chapter IV describes consensus algorithms. The division of this section is straight-forward. Firstly, we explain Bitcoin’s consensus, by giving a historical background introducing previous work (1.1, 1.2 and 1.3) and then analyzing the proof of work function Bitcoin is based upon. This first part ends with a critique to the previous work and to the current proof of work function. Secondly, we analyze Ethereum’s consensus algorithms, by introducing the Proof of Stake scheme, speaking about a key problem in
2
computer science known as “The Generals Problem” both from a theoretical and practical point of view. Finally, Ethereum Casper and its two main projects are analyzed. Logically, the third part of this chapter focuses on Fabric’s consensus. The chapter is concluded with a small conclusion on consensus algorithms. The fifth chapter is the implementation of a simple blockchain program we have created. This blockchain program provides a better insight on blockchain technology. The challenge here was to understand the implementation and then build a user-friendly interface. We also had to solve the challenge of concurrently firing up the server and starting the interface. This was done with a client-server structure that uses threads. The last Chapter is the conclusion to this thesis, containing a summary of the work, highlighting the important parts and suggesting future directions or uses. Blockchain has an incredible potential and that is the reason why we should have professionals with a solid theoretical base.
2. Motivation
People always wonder how blockchain works and the excessive amount of information in the internet (sometimes incorrect) or the far too technical papers make it difficult for a novel blockchain student to understand the basis of this fascinating technology. This work aspires to make this information accessible, by starting from a basic point and slowly but surely introducing more advanced topics. In conclusion, the objective is to provide someone with no experience in blockchain with the fundamentals. This work serves as a starting point. At the end, we briefly talk about an application. The reader can go over over the code to understand its functioning.
3. Contributions
As stated previously this work constitutes a summary of blockchain’s three main (arguably) technologies. The objective is not only to give theoretical information, but also to explain some key algorithms practically, step by step. Specifically: -It gives an overview of blockchain, allowing the reader to develop an understanding from the start. -It introduces the structures of blocks and transactions comparing them. -It provides a well-developed part on consensus algorithms, explaining everything to great depth and analyzing them from a theoretical perspective with the help of published papers and dedicated blogs run by blockchain specialists. -We have created a user-friendly interface, associated with a blockchain, that ‘lives’ in our localhost.
3
1. Visión General del Trabajo
Blockchain es una tecnología a la que cada vez se la presta más atención. Cuando se hizo este trabajo exisitían más de 1600 criptomonedas y un 33 % de los banqueros espera que el blockcahin comercial sea adoptado el año próximo. Necesitamos entender esta tecnología, que en un futuro formará sin ninguna duda parte de nuestra vida. En este trabajo nos enfocaremos en Bitcoin, Ethereum y Hyperledger Fabric, ya que respectivamente representan un blockchain que usa la prueba de trabajo (Proof of Work), un blockchain que pretende transicionar de prueba de trabajo a prueba de participación (Proof of Stake, en inglés), que cuenta además con dos grandes proyectos actualmente en desarrollo y finalmente un blockchain privado. El trabajo está organizado de la siguiente manera: En el segundo capítulo presentamos el funcionamiento de la tecnología blockchain de forma general. Para empezar, se explican conceptos básicos, cómo el cifrado simétrico y asimétrico y luego se explica el mecanismo general de blockchain. En segundo lugar, en este capítulo se analiza la estructura de bloque y de transacción en Bitcoin, Ethereum y Hyperledger Fabric. Concluimos esta sección mostrando específicamente cómo funciona una transacción en estas tres tecnologías. En el tercer capítulo, nos adentramos en los conceptos criptográficos y sus aplicaciones en blockchain. Empezamos hablando de las funciones hash, que son el eje principal de esta tecnología y de dónde emanan las propiedades de seguridad asociadas al blockchain. Seguimos nuestro estudio hablando de las funciones hash criptográficas. Tratamos las funciones de SHA-256 y del Keccak-256, dando una explicación general sobre el funcionamiento de las funciones esponja. Finalizamos esta sección hablando brevemente de la criptografía de curva elíptica y hablando de aplicaciones concretas, relacionadas con investigación y noticias de actualidad. El cuarto capítulo trata sobre los algoritmos de consenso. Primeramente, hablamos del consenso en Bitcoin, analizando los antecedentes históricos y por lo tanto todo el trabajo previo (1.1, 1.2, 1.3) a la función de coste en Bitcoin. Luego, analizamos la función de coste del algoritmo de Prueba de Trabajo. Finalizamos esta parte con una crítica tanto a las funciones anteriores, cómo al esquema utilizado actualmente. En segundo lugar, analizamos los algoritmos de consenso de Ethereum, introduciendo el concepto de Prueba de Participación (Proof of Stake). Se explica el Problema de los Generales Bizantinos, clave en computación distribuida, desde un punto de vista tanto teórico, cómo práctico. Finalmente, se analiza Ethereum Casper y sus dos proyectos principales. Cómo no podía ser de otra manera la tercera parte de este capítulo trata sobre el consenso en Hyperledger Fabric. El capítulo termina con una breve conclusión sobre los algoritmos de consenso. El quinto capítulo trata sobre una implementación de una aplicación de blockchain simple que hemos creado. Gracias a esta aplicación es posible entender mejor el funcionamiento de blockchain. El reto estuvo en entender la implementación y desarrollar una interfaz gráfica sencilla para el usuario. También se tuvo que resolver el
4
problema de iniciar el servidor a la vez que la aplicación. Se consiguió mediante una estructura cliente-servidor y usando threads. El último capítulo es la conclusión a todo el trabajo, subrayando las partes importantes y sugiriendo nuevas direcciones de investigación o usos. Blockchain tiene un gran potencial y por ello deberíamos contar con profesionales que posean una base sólida teórica.
2. Motivación Hay un desconcierto general sobre cómo funciona el blockchain, debido al volumen de información en internet (a veces incorrecta) o a “papers” demasiado técnicos, que dificultan la comprensión de esta tecnología fascinante. Este trabajo aspira a hacer accesible esta información, empezando desde lo básico y gradualmente introduciendo conceptos más avanzados. El objetivo es, por lo tanto, proporcionar a una persona sin experiencia en este tema los conceptos fundamentales. El lector puede mediante la implementación del final tener una mejor comprensión.
3. Contribuciones
Tal y cómo hemos dicho este trabajo es un resumen sobre las tres tecnologías principales de blockchain. No sólo se da información teórica, también se explican algunos algoritmos de forma práctica. Específicamente: -Da una visión general del blockchain, permitiendo una comprensión desde el principio. - Introducimos y comparamos las estructuras internas de las tres tecnologías sobre las que nos centramos. - Se desarrolla un tema tan importante cómo el de algoritmos consensuales, explicando en profundidad mediante “papers” y otras publicaciones mantenidas por especialistas en el tema. -Creación de una interfaz amigable para el usuario, asociada a un blockchain que “reside” en nuestro localhost.
5
II- BLOCKCHAIN TECHNOLOGY INTRODUCTION
Abstract—With over 2000 blockchain technologies Blockchain has many applications currently, thanks to the safety (due to the block’s interconnections) and efficiency (the transaction is recorded once and only verified parties can access the information) it provides, and we should aspire to evolve into a more block chain friendly society. However, if this our final objective we should make sure that this technology is safe enough, for us to trust it. To what extent is this true? Is blockchain really safe? It is critical to understand the logic and structure behind these three technologies. Consensus is what guarantees blockchain’s current safety. In this paper we explore the consensus algorithms, discussing the safety of each one, basing our study on Ethereum, Hyperledger and Bitcoin, focusing on business blockchains but having bitcoin (public blockchain) as a reference.
Blockchain is an immutable ledger, used to record transactions, in a network of untrusted peers. The peers can interact with the ledger and thanks to consensus protocols validate transactions. These transactions are then grouped into blocks and a chain is built connecting those blocks. Tampering with one block would impact the whole chain. There are two main types of blockchain technologies: public and private blockchain. In a public blockchain (also known as permissionless), anyone can interact. As its name suggests the participants do not need an identity. In a private blockchain (also known as permissioned blockchain), the blockchain is run among a set of known participants. Every transaction in a blockchain network is secure and verified, but how is this done? First, the transaction is verified and then the block is secured. This is where consensus algorithms come into play. Formally speaking, a consensus algorithm is a process thanks to which the users of a network (in this case the blockchain network) agree on a transaction, just like consensus within a group of people. When this transaction is agreed upon the transaction is broadcasted in the network. In blockchain, consensus algorithms do two things: ensuring the next block in the blockchain is the correct one and preventing an attacker from manipulating the chain incorrectly. Therefore, consensus algorithms are crucial in blockchain. In this paper we focus on three consensus algorithms in Bitcoin, Ethereum and Hyperledger Fabric. For each algorithm we describe how it works and then discuss its limitations.
1. Blockchain overview
6
Figure 1: Blockchain’s Basic architecture
This section gives a short overview on blockchain’s fundamental architecture and defines three properties of blockchain [18]. Here is a scheme of blockchain’s block architecture. As Figure 1. Blockchain’s basic architecture we can appreciate in the figure these blocks hold a complete list of transaction records. In the header of the block is the previous block’s hash. It is thanks to this hash that tampering with the blocks is impossible, since a change in one block would have consequences in the rest of the chain. Blockchain has three main characteristics:
• Decentralization: Whereas traditional centralized transaction systems need a central authority to validate transactions, Blockchain does not. Thanks to the consensus algorithms covered in this paper, validating and agreeing upon transactions is made possible.
• Persistency: Transactions can be validated computationally efficiently. A validated block cannot be rolled back.
• Anonymity: Each user that interacts with the Blockchain will not have to reveal its real identity. Having in mind the fundamental architecture of Blockchain will help us understand the rest of the paper.
A digital signature has the objective of proving that an entity is who they say they are using cryptography.
1.1- Difference between symmetric and asymmetric encryption
Symmetric encryption: There is only one secret key to encrypt and decrypt data. This key is blended in the message, so as to change the content in a concrete way. For this technique to work both the sender and the receiver must know this key. The main disadvantage over asymmetric encryption is that users need to share this key to be able to communicate safely.
7
Asymmetric encryption systems: Users generate a key pair composed of a public key and a private key, using some known algorithm. These two values are associated, through some mathematical relationship. As its name suggests the public key is distributed among the users. On the contrary, the private key is used to sign messages sent to other users. This signature is included in the message and thanks to the public key other users can verify the source of the message. In other words, a message encrypted with a private key is decrypted using a public key. In comparison with symmetric encryption asymmetric encryption takes more time.
1.2- Overview of Blockchain’s mechanism
Instead of trusting a third party, blockchain uses cryptographic proof, to execute a transaction. The transactions are protected with a digital signature, sent to the public key of the receiver and signed using the private key of the sender. The owner of the cryptocurrency must prove his/her identity through this scheme. In every transaction we must make sure that the owner has enough money in his/her balance. Every transaction is broadcasted to every node in the blockchain network and recorded once it is verified. To verify a transaction, we need to check that the sender owns the cryptocurrency, and that the spender has enough cryptocurrency in his balance. There is however the problem of double spending, since the transactions do not come in order and so the money could be easily spent twice or more times, and the generating time and the order
8
in which they are received does not forcefully match. The mechanism developed to solve this problem is the placing the transactions in groups known as blocks and then linking these blocks. They are linked to each other since a block contains the hash of the previous block. Lastly, we need to make sure that a node that collects unconfirmed transactions and broadcasts them in the system should not be able to create a block. The network needs to be able to decide which block is the next one in the chain. In this context is where the Proof of Work (PoW) algorithms come into play. The Proof of Work algorithms are cryptographic or mathematical puzzles. We will talk more extensively about Proof of Work schemes in chapter 3. Thanks to Proof of Work it is improbable that two blocks are generated in the network at a given time. Once a node solves the problem it broadcasts the block. In the unlikely event that two nodes solved the puzzle at exactly the same time it will create more than one branch (this is known as a fork). The operations will keep on going and finally the longest chain (known as the canonical chain) is accepted as the largest one. If an attacker wanted to introduce a fraudulent transaction it would have to apply the Proof of Work algorithm to solve the requested puzzle and be quicker in the generation of the nodes so that the network would accept his branch as the correct one. This is even harder since blocks in the blockchain are linked cryptographically.
Fig. Summary of Blockchain’s steps
In this figure we can see how when A wants to send money to B, the transaction is created in the form of a block and then broadcasted among the nodes, that validate the transaction. Once this is done the transaction is added in the blockchain and the cryptocurrency is sent.
1.3- Public and Private Blockchain
A permissionless blockchain means that anyone can read, write or participate in the blockchain, whereas private blockchains are permissioned, meaning that there are restrictions on who is allowed to participate in the network and in what transactions.
9
Consensus is reached by Proof of Work, in public blockchains and by selective endorsement, in private blockchains. Selective endorsement is being able to control who verifies transactions. Public blockchains have lower transaction speed because computationally it takes more time to run Proof of Work algorithms. On the contrary private blockchains rely on selective endorsement, which does not require the same time as Proof of Work, and therefore is faster. Scalability is closely related to transaction’s speeds. When implementing a blockchain solution for a business, we are going to prefer a private one. This is because businesses need to know: who they are interacting with, that unauthorized participants do not have access to the data.
Private Blockchain Public Blockchain Participation Permissionless with
known identities Permissioned with unknown identities
Performance Fast transaction speed Slow transaction speed Consensus Selective Endorsement Prof of Work/Proof of
Stake Scalability Easier to maintain at a
larger scale. Harder to maintain at a larger scale.
Examples Hyperledger Fabric Bitcoin, Ethereum Figure: Table showing the key differences between public and private blockchain
2- Transaction structure
2.1- Transaction Structure in Bitcoin
-Version (4 bytes): Number that represents the software protocol followed by the transaction
-Input counter: (1-9 bytes): Number of inputs that are included.
-List of inputs (variable size): The transactions inputs.
-Output counter (1-9 bytes): Number of outputs that are included.
-List of outputs: The transactions outputs.
-Lock Time: UNIX encoded timestamp. It corresponds to the earliest time that a transaction can be added to the blockchain. It is usually set to zero in most transactions, which indicates immediate execution. If it is between zero and 500 million it is interpreted as a number that indicates the number of blocks that precede the current block. If the number is above 500 million it is interpreted as a UNIX time and the transaction is included after the specified time.
10
2.2- Transaction structure in Ethereum
In Ethereum transaction can be of two types: message calls (to transfer ether, for example) or the creation of a new account.
-Nonce (up to 32 bytes): Number of transactions sent by the sender.
-Gas Price (up to 32 bytes): Value in wei to be paid for gas, for the computation of the current transaction. -Gas Limit(up to 32 bytes): Number equal to the maximum amount of gas that should be used to compute this transaction.
-To (20 bytes): The destination address.
-Value (up to 32 bytes): A numerical value that indicates the number of Wei, to be transferred to the destination address.
-v (1 byte usually),r(32 bytes),s (32 bytes) : Grouped together they form the signature of the transaction. For a contract creation transaction, we find additionally an init field. This field is of variable size (unlimited byte array) and has a code that specifies the account initialization procedure. For a message call transaction there is a data field. This field varies in size (unlimited byte array) and specifies the input data of the message.
2.3- Transaction Structure in Hyperledger
-Header: Contains the transactions metadata (the version, for example).
-Signature: Contains a cryptographic signature, created by the client. This is a fundamental part and allows the miners to verify that the transaction is correct.
-Proposal: This field is responsible for encoding the input and creates the proposed (until verified) ledger update. -Response: This field provides the before and after values of the world state (database that contains the current values for a set of ledger states). If the transaction is validated the world state will be updated. -Endorsements: List of verified transaction responses from each required organization that satisfy the endorsement policies. (these policies define which peers need to agree on the result of a transaction, before the world state can be updated).
3. Block Structure
3.1- Block Structure in Bitcoin
Magic number: Serves for the Blockchain Network for identification purposes. The magic number is always: 0xD9B4BEF9 and indicates the start of the block. Its size is 4 Bytes.
11
Block size: Indicates how large the block is in size. Since the start and thanks to consensus the size of the block is 1 MB, but it could be scaled up until 2GB.
Version (4 Bytes): Each node in the network should have the same version. Previous block hash: Hash of the lastly added block in the blockchain. It is calculated by applying a cryptographic function (such as SHA-256).
Block header: Composed of Transaction Counter and Transaction List. The transaction counter is the number of transactions included in the block. The transaction list provides every transaction (each transaction has its own structure). Timestamp: 4 Byte UNIX Epoch encoded timestamp (based on the number of seconds passed since January 1, 1970). For a timestamp to be valid it must be greater than the median timestamp of the previous eleven blocks and less than the networks-adjusted time (median of all blocks that are connected to you) plus 2 hours. This means that if the networks adjusted time is 2 PM, the 3 Items details Size (bytes) Comments Block Size 4 Header Version 4 Number that represents the software protocol Previous Block hash 32 The previous block’s header hash Merkel root 32 Hash of the current merkle tree’s root Timestamp 4 UNIX encoded Epoch timestamp Difficulty Target 4 Numerical difficulty for the block Nonce 4 Counter used to generate a correct hash Transaction counter 1-9 Positive integer Transactions List of transactions n varies
Merkle root: The transactions appear as binary hash trees. Like in a usual binary tree, the root is the topmost node (from which every other node derives). A node represents a cryptographic hash of a transaction. Therefore, this tree represents the cryptographic hashes of every transaction and the merkle root represents its root.
Difficulty bits: A numeric representation of the difficulty for obtaining the correct result.
Nonce: A counter that increments itself until the puzzle is solved or another node solves it. Below we present the block’s structure in the form of a table, to summarize.
Items Details Size (in Bytes)
Comments
Block Size 4 Header Version
Previous Block Hash Merkel Root Timestamp Difficulty Target Nonce
4 32 32 4 4 4
Number that represents the software protocol. The previous block’s header hash. Hash of the current merkle tree’s root. Unix Encoded Epoch Timestamp. Numerical difficulty for the block. Counter used to generate a correct hash.
12
Transaction Counter
1 to 9 Positive integer
Transactions n It is variable in size Table I- Bitcoin’s Block Structure
3.2- Block Structure in Ethereum
In every block header there are three tries: state trie (known as state Root), transactions trie (known as transactions Root) and receipts trie (known as receipts Root). These are the sections that are in the block header:
-Parent Hash: The hash of the parent blocks header. Concretely we are talking about the Keccak 256 bit hash. Keccak is a family of hash functions based on the sponge construction. According to Dr. Wood (co-founder of Ethereum) this is denoted as Hp.
-Ommers Hash: Formally speaking a block in Ethereum is a collection of information that include: a block header (denoted by H), information regarding the transactions (denoted as T) and a set of other block headers U that have a parent equal to the present blocks parents parent (such blocks are known as ommers). Ommers are sometimes known as uncle blocks and the analogy is trivial. Therefore, the ommers Hash is the Keccak 256 hash of the ommers list from the current block.
-Beneficiary(20 byte): Address to which all the fees from successful mining of the current block are transferred.
-State Root: The Keccak 256 bit hash of the root node of the state trie, after all transactions are finished. A trie is a tree-like structure where each node has a key that is usually a String.
-Transactions Root: The Keccak 256 bit hash of the root node where of the trie, containing every transaction.
-Receipts Root: The Keccak 256-bit hash of the tries root, containing the transaction receipts. -Logs Bloom: A bloom filter function is a function that reduces a single log entry into a 256 bit hash. Therefore the logs bloom is the bloom filter from the information contained in each log entry (address and topics), derived from each transaction.
-Difficulty: As in bitcoin, this is a numerical value that indicates the difficulty of the current block.
-Number: Numerical value that accounts for the number of previous blocks. The root would have number=0, as there are no previous blocks.
13
-Gas Limit: A numerical value that accounts for the maximum of gas that can be consumed per block.
-Gas Used: A numerical value that accounts for the total of gas that has been consumed in the current block.
-Timestamp: As in bitcoin, this is a UNIX encoded timestamp.
-Extra Data: Arbitrary byte array (however 32 bytes, at most) containing data relevant to this block.
-Mix Hash and Nonce: We need to combine these two to know whether enough computation has been carried out. The other two components of an Ethereum block are the ommer headers (with the same structure as above) and the list of transactions.
Items Details Size (in Bytes)
Comments
Header -Parent Hash -Ommer Hash -Beneficiary -State Root -Transactions Root -Receipts Root -Logs Bloom -Difficulty -Number -Gas Limit -Gas Used -Timestamp -Extra data -Mix Hash -Nonce
32 32 20 32 32 32 1 1 1 1 1 1 32 32 8
List of ommer block headers
Has the same format as our block header and so has the same fields.
Variable Here, all the transactions with all their fields are stored.
Series of the transactions
Variable List of all the transactions.
Table II- Structure of an Ethereum block
3.3- Block structure in Hyperledger
In Hyperledger a block has three parts: block header, block data and block metadata. Block header
14
-Block number: A numerical value (integer), that accounts for the number of ancestors that block has. The first block would therefore have number equal to zero.
- Current block hash: Hash of the blocks’ transactions.
-Previous block hash: Hash from the blockchains previous blocks transactions. Block data: List of the transactions contained in the current block.
Block metadata:
-Timestamp: As in bitcoin and Ethereum this corresponds to a UNIX encoded timestamp.
-Creator identity: Contains certificate, signature and public key from the orderer.
Items Details Size (in Bytes)
Comments
Header -Number -Previous Hash -Data Hash
72 The block number is always unique. The first block is known as the genesis block. SHA256 is used to calculate the block header of the previous block.
Data List of Transaction
Variable Here, all the transactions with all their fields are stored.
Metadata -Creator Identity (Certificate, Public Key) and Signature -Last Configuration Block, Creator Identity and Signature -Flag for each transaction -Last offset persisted, creator identity and signature
Variable All the metadata related to the block is stored here.
Table III- Structure of a Hyperledger block
4- Example of transaction processes
In this section we will look at concrete transactions and show the processes behind them.
4.1- Transaction in Bitcoin
15
A transaction in Bitcoin is a transfer of Bitcoin cryptocurrency, broadcasted to the network and stored in blocks. When a transaction has been confirmed multiple times, it is said to be irreversible. Transactions are not encrypted, and anyone can view them.
Now we will define some terms, necessary to understand Bitcoin transactions.
-Script: Bitcoin uses a scripting for transactions, written in Script. A script is a list of instructions recorded with each transaction, describing how the next person wanting to spend the Bitcoins being transferred can gain access to them. The spender must provide the public key (ScriptPubKey) and a signature to prove ownership of the public key (ScriptSig). We will define some script words:
-OP_DUP: Duplicates the top stack item.
-OP_HASH160: The element to which this operation is applied is hashed twice. First, with SHA-256 and then with RIPEMD-160.
-OP_EQUALVERIFY: Returns 1, when the inputs are exactly equal, 0 if they are not (this is what OP_EQUAL does). It runs but runs OP_VERIFY afterward. OP_VERIFY marks the transaction as invalid if the top stack value is false and the top stack value is removed.
-OP_CHECKSIG: Function that returns 1 if when the entire transaction’s outputs are hashed, the signature is valid for the hash and public key. If it is not it returns 0.
-Input: Reference to an output from a previous transaction. Generally, there are multiple inputs listed in one transaction. It contains ScriptSig. The public key must match the hash given in the script of the redeemed output. With the public key, the redeemers ECDSA signature (ScriptSig) is verified. By doing so, we know whether the transaction was created by the owner of BTC.
-Output: Contains the instructions for sending the cryptocurrency. In value the number of Satoshi (1 BTC = 100,000,000 Satoshi) that the output will be worth when claimed. There can be more than one output. It contains ScriptPubKey. An output can only be referenced once by an input. This means that the entire combined input value needs to be sent in an output or it will be lost. If the input is worth 10 BTC and you only want to send 3 BTC, two transactions will be created. One to the destination address and another one, back to you.
-Verification: It is imperative to verify that inputs are authorized to collect the values of referenced outputs. ScriptSig and ScriptPubKey from the input are evaluated and the input is authorized if ScriptPubKey returns True, meaning that we have the private key necessary to claim the solicited BTC. To summarize all this let’s have a look at the following abstract scheme:
16
Figure Bitcoin Transaction, illustrating the input and output.
This diagram shows how the Bitcoins of a certain person can come from many different sources (different inputs) and they are added (illustrated by the symbol ). Transaction TX4 might be the value we send to a friend and TX 5, the return value we send to ourselves. Then two transactions (for example) are produced as outputs. An analogy might be paying in a store. When you have to pay often times you will not have the exact amount of money. So, you gather coins and/or bills and hand it to the cashier. Bitcoin is like that except that you have to explicitly say where that money came from. In the example we should know where TX 1, TX 2, TX 3 came from (they must be accounted for). We will use the outputs of a given transaction as inputs of a different transaction. When this happens, we need to spend the complete amount from that TX.
For this transaction to be valid we need TX1 + TX2 + TX3 ≥ TX4+ TX5. Therefore, there are two possibilities:
Possibility 1: TX1 + TX2 + TX3 > TX4+ TX5
If this happens a transaction fee is generated. The transaction fee is equal to (TX1 + TX2 + TX3) - (TX4+ TX5). Every bitcoin that is not explicitly accounted for in the transaction becomes a transaction fee. The transaction fees are then collected by the miner that successfully mines the block. In conclusion, the miner that correctly mines the block will get a reward for mining the block and the transaction fees from all transactions in that block.
Possibility 2: TX1 + TX2 + TX3 = TX4+ TX5
When this happens and assuming that TX 4 is the value of BTC we want to transfer to a peer, TX 5 is the “change” we talked about in the analogy with a real-life shop. It will be a transaction destined to ourselves.
Finally, we will call the whole transaction a message M, and the name of the transaction will be a double hash of the message (M= SHA256(SHA256(M))).
17
Example of transaction, from:
Bitcoin transaction, extracted from: https://en.bitcoin.it/wiki/Transaction#Explanation
In this transaction we can observe that the transaction imports 50 BTC from output #0 (index) in transaction “f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6”. Then the output sends 50 BTC to a Bitcoin address (expressed here in hexadecimal “404371705fa9bd789a2fcd52d2c580b65d35549d”). When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction, and that way that cryptocurrency can be traced back to where it came from. 4.1.1 Types of transaction Pay-to-PubkeyHash: This the most common method. By supplying the signature and the public key, the recipient redeems coins that have been sent to a bitcoin address. The scriptPubKey pattern is as follows: OP_DUP OP_HASH160 hashed public
key OP_EQUALVERIFY OP_CHECKSIG
The scriptSig is as follows: Sig PubKey
When we run this script we go through the following steps: Step 1: We start off with an empty stack and a script, which is the result of concatenating scriptPubKey and scriptSig.
18
Step 2: We introduce Sig and PubKey in that order. Step3: We encounter OP_DUP, so we duplicate whatever is at the top of the stack (PubKey). Script Step 4: Now, we encounter OP_HASH160 on the top of the stack, so we hash the PubKey. Script Step 5: We push the hashed public key on the top of the stack. Script Step 6: We verify that the first and second element of the stack match each other, with OP_EQUALVERIFY. Script Step 7:
Script
Empty
19
Pay-to-Script-Hash: The redeemer is the one responsible for supplying the conditions to redeem a transaction (instead of being the sender of the funds). This is used when we are dealing with complicated transactions. The transactions are sent to an address., known as a script hash and the recipient might need signatures from several people or some unique requirements. 4.2- Transactions in Ethereum We will introduce the types of transactions, present in Ethereum and explain how they work. We will firstly introduce some vocabulary: EOA (Externally Owned Account): This is an individual user (represented by a 160-bit address) in the external world. Contract: Capability in Ethereum where the business logic is implemented. Then the bytecode is deployed in the Ethereum network. 4.2.1- Transfer from one EOA to another EOA: 5 ethers
4.2.2- Deploy a contract on Ethereum Network In this part we will deploy the bytecode (in machine understandable language), using a transaction.
From EOA 1 20-byte address.
To EOA 2 20-byte address.
Value 5 ethers. Data Empty. Gas Limit Large enough for
transaction. Gas Price To be determined
by transaction initiator.
EOA 1
EOA 2
ETHEREUM NETWORK
20
Transaction (Deploy Contract)
4.2.3- Execute a Function on a Deployed Contract
After deploying the contract an EOA can execute functions defined in this contract. The functions are executed thanks to an Ethereum transaction.
Transaction
Function Execution
From Contract deployer (EOA 20-byte address). To Empty. Value Amount in weis, if required by contract
constructor. Data Bytecode of the contract and required
arguments. Gas Limit Large enough for contract deployment. Gas Price To be determined by transaction initiator.
From Function Executor (EOA 20-byte address) To Contract Account Address (20 byte) Value Amount in weis, if required by contract
function. Data Function Selector and the arguments required
by the function, if necessary. Gas Limit Large enough for contract function Execution. Gas Price To be determined by transaction initiator.
EOA ETHEREUM NETWORK CONTRACT ACCOUNT
EOA ETHEREUM NETWORK CONTRACT ACCOUNT
21
4.3- Transactions in Hyperledger
First, we will define some necessary vocabulary.
Endorsement Policy: Definition of the set of required responses by the peers to validate a transaction.
Transaction Proposal: When a user invokes a transaction using the SDK, it transfers the transaction proposal (data) and simulates the transaction inside a peer.
Channels: Private subnet of communication between two or more specific network members, for the purpose of conducting transactions in a private and secure manner.
MSP: Peer component that allows peers to verify transaction requests arriving from clients and sign endorsements.
Step 1
Client A sends a request to purchase a good to peerA and peerB, who are respectively represent Client A and Client B. Thanks to the endorsement policy, the request goes from peerA to peerB.
The transaction proposal is then constructed. This proposal is a request to invoke a chaincode function with certain input parameters, to read or update the ledger.
Step 2
22
The endorsing peers verify that:
-The transaction proposal is well formed.
-The transaction proposal has not been submitted in the past.
-The signature is valid, thanks to the MSP.
-The submitter (Client A) in our example is able to perform the operation on the channel.
The endorsing peers take the transaction proposal inputs as arguments to the invoked chaincode’s function, denoted as f(x) in the diagram. The chaincode is then executed against the current state database to produce transaction results. The ledger is not updated at this point. Instead the set of values and the endorsing peer’s signature is passed as a “proposal” response to the SDK, for the application to consume
Step 3:
Proposal responses are inspected in this step. This is done by comparing the proposal response to determine if they are the same. If the client application intends to submit the transaction to update the ledger, through the Ordering Service, the application determines whether the endorsement has been fully fulfilled (did both peers endorse?).
Step 4:
In this step the client assembles endorsements into a transaction.
The app broadcasts the proposal and response to the ordering service. The Ordering Service receives transactions from all channels in the network, orders them chronologically by channel and creates blocks of transactions per channel.
Step 5:
In this step the transaction is validated and committed. The transactions’ blocks are sent to all the peers on the channel. The transactions within the block are validated to ensure endorsement policy is fulfilled, and they are tagged as valid or invalid.
Step 6:
In this step the ledger is finally updated. Each peer appends the block to the channel’s chain and for every valid transaction in the block the set is committed to the database.
23
III- SECURITY IN BLOCKCHAIN AND ITS APPLICATIONS
1- Hash functions
A hash function is a function that maps data of any size onto data of a fixed size. The returned values are known as hash values or hash codes. These functions are used in hash tables, cryptography. We will go through some common uses of hash functions, to finally introduce the topic of hash functions in cryptography, of great importance for blockchain to work properly.
Hash functions in hash tables:
The objective of hash functions is to distribute some entries, usually consisting of key and value into an array. Usually given a key we can find where the value is stored. An element known as the key is hashed into an integer. This integer can be used to insert that element into an array containing all the hashes. When implementing a map using a hash table the goal is to store item (key, value) such that at index i we have h(k), where h is a hash function. Usually a hash function consists of a composition of two functions:
-First a mapping between the keys and the integers: keys -> integers. This first function is known as the hash code.
-Second a mapping between the integers and an interval equal to [0, N-1], where N is the total number of elements in the vector, since our objective is to map the keys to an N-dimensional vector. This second function is known as the compression function.
We will have a look at some common hash codes and compression functions.
1.1 - Hash Codes
-Memory address:
The key address can be interpreted as a memory address. This in turn can be interpreted as an integer.
-Integer Cast: Interpreting the bits of the key as an integer.
-Polynomial accumulation:
We partition the bits of the key, into a sequence of components of fixed length, such as: a0,a1…an-1.
We choose a random z (z=33 gives good results) and compute p(z)= a0+a1z1+a2z2+…+an-1zn-1
24
1.2- Compression Functions
Let’s have a look at some common compression functions:
- Division: h1(y)= y mod N, where N is the hash table where the elements will be inserted, and y is the element we are trying to compress. Due to the basic properties of the mod function: 0 ≤ h(y) ≤ N-1, which is perfect for this purpose.
- Multiply, Add and Divide:
h2(y)= (ay + b) mod N, where a and b are integers, such that a ≥ 0, b ≥ 0, and a mod N ≠ 0.
1.3- Collisions In hash tables, collisions occur when elements are mapped to the same index. Collisions can be handled using some of these methods:
- Separate chaining: Each cell in the hash table points to a linked list of entries that map there. For this linked list we need additional memory.
- Linear Probing: It handles collisions by placing the colliding item in the next available table cell. We will consider the table is circular.
-Double hashing: With a second hash function, denoted as d(k) it places an item in the first available cell of the series (i+ jd(k)) mod N, where i is the location in the hash table and for j=0…N-1.
Applications: Hash functions in bloom filters
A bloom filter is a probabilistic data structure used to check if an element belongs to a set. It answers: “definitely not in the set” or “maybe in the set”. This means that we can have false positives, but never false negatives. Let’s take a look at how this works:
An empty bloom filter of m bits (m=14 in this case), all set to zero.
Now, suppose we want to introduce an element in the set: hash(elem1) = 2 3 10, where 2, 3 and 10 are the positions in the array.
Now suppose, we introduce hash(elem2) = 0 1 5
25
Now, to the interesting part: Suppose we want to check if elem3 is in the set, and hash(elem3) = 5 6 14. The set would answer “definitely not in the set”. However, if we wanted to check the same thing with elem4 and hash(elem4) = 2 5 10, the buckets are set to “1”, but elem4 is not in the set. The bloom filter will answer “maybe in the set”.
2. Standard use of hash functions in cryptography
Properties of hash functions:
-Fixed length output: Converts data of an arbitrary size into data of fixed size.
-Efficiency of operation: Given an input, hash(input) is computed quickly.
-Pre-image resistance: Reversing a hash function is a computationally expensive. Therefore, a hash function is generally a one-way function. This means that an attacker with the hash value cannot retrieve the original value.
-Second Pre-image resistance: Given an input and its hash, it should be hard to find another input with the same hash. This means that when an attacker has x and produces output h(x), it should not be possible to find y, such that it produces output h(y) and h(y)=h(x). This property is used to prevent an attacker with an input value an its hash from substituting a legitimate value with their value.
-Collision Resistance: As its name indicates, this means that it should be hard or impossible even with inputs x and y to find h(x)=h(y), resulting in the same hash.
2.1- SHA 256 in Bitcoin and Hyperledger Fabric
SHA (Secure Hashing Algorithm, published by the National Institute of Standards and Technology) 256 is a cryptographic hash function, belonging to the family of SHA 2. SHA 256 outputs a value of 256 bits.
Any given message is processed by blocks of 512 bits. Since a message is not always (and will not be in most of the cases a multiple of 512 bits) padding has to take place to correctly apply the algorithm.
Operations, Functions and Constants in SHA 256
In this section we will define the basic operations, functions and constant to understand SHA 256.
, , denotes AND, OR and XOR respectively.
¯ is the bitwise complement.
26
A + B is the integer addition modulo 232
Rot(A,n) is the circular right shift of n bits in word A. Sh(A, n) is the right shift of n bits in word A. A||B denotes the concatenation of A and B. Ch(X, Y, Z) = (X Y) ( X Z). Maj(X, Y, Z)= (X Y ) (X Z) (Y Z). Σ0(X) = Rot(X, 2) Rot(X, 13) Rot(X, 22). Σ1(X) = Rot(X, 6) Rot(X, 11) Rot(X, 25). σ0(X) = Rot(X, 7) Rot(X, 18) Sh(X, 3). σ1(X) = Rot(X, 17) Rot(X, 19) Sh(X, 10).
Step 1: Padding the message
As we have explained this is done to ensure the message has a length of a multiple of 512 bits. We will explain how to do this:
1-) Append a 1.
2-) k zero bits are appended, with k = mink {l+1+k ≡ 448 mod 512, where l= length of the message.}
3-) The length of the message l is represented with 64 bits and they are added at the end of the message.
Step 2: Block decomposition
Each block, containing only zeroes and ones (M {0,1}), 64 words of 32 bits are constructed as follows:
The first 16 words
Splitting M in 16 32 bit blocks: W1||W2||…||W16
The 48 words remaining
Obtained with the formula: Wi=σ1(Wi−2) + Wi−7 + σ0(Wi−15) + Wi−16, 17 ≤ i ≤ 64.
Step 3: Hash Computation
We set up eight variables, that represent the 32 first bits of the fractional part of the first eight primes (2,3,5,7, 11,13,17,19). For example, 2 in hexadecimal is 1.6A09E667 F3BCC908B2F. Since 1 hexadecimal digit represents 4 binary digits (4 bits that is), the first 8 digits from the fractional part would be H1
0= 0x 6A09E667. Repeating the same process for the seven other prime number we get: H2
0 = 0xbb67ae85; H30 = 0x3c6ef372;
27
H40 = 0xa54ff53a; H0
5= 0x510e527f; H60 = 0x9b05688c; H7
0= 0x1f83d9ab; H80=
0x5be0cd19.
for t from 1 to N:
Construct the first 64 Wi, for a given t.
Set (a, b, c, d, e, f, g, h) = (H1 (t−1), H2 (t−1), H3 (t−1), H4 (t−1), H5 (t−1), , H6 (t−1), H7 (t−1), H8 (t−1))
Perform 64 rounds of:
T1= h + Σ1(e) + Ch(e, f, g) + Ki + Wi T2= Σ0(a) + Maj(a, b, c)
h = g g = f f = e
e = d + T1 d = c c = b b = a
a = T1 + T2
End of 64 rounds computation
Now, the new values of Htj are:
H 1t= H1 (t−1) + a H 2t = H2 (t−1) + b H3
t = H3 (t−1) + c H 4t = H4 (t−1) + d H 5t = H5 (t−1) + e H 6t = H6 (t−1) + f H 7t = H7 (t−1) + g H 8t = H8 (t−1) + h
End for t from 1 to N
return H 1N|| H 2N || H 3N || H 4N || H 5N || H 6N || H 7N || H 8N
2.2- Attacks on SHA 256
According to the three main properties of a hash function breaking or attacking a hash function can correspond to three attacks:
Pre-image attacks: Given H(m), we get to know m.
Second pre-image attacks: Find some m’ ≠ m, knowing m, so that H(m)=H(m’).
Collision attacks: Find m1 and m2, so that m1≠m2 and H(m1) = H(m2).
28
First, let’s take a look at the Birthday Problem:
This problem refers to the probability that within a group of people, some people share a birthday date. Let’s consider Q(n, d), the probability that out of n people, no two people in that group will have matching birthdays out of d equally possible birthdays. Supposing we only have two persons: The probability that the second person’s birthday is different is . Adding another person, the probability would be . Rearranging this equation in terms of factorials:
Therefore P(n, d) being the probability that two people share the same birthday is: 1 – , and so:
In a group with 23 people, this probability is of 0.50, not considering leap years.
The birthday problem is relevant when considering attacks on the SHA functions, because theoretically speaking as the number of hashes grows it becomes more likely that some pairs of data create the same hash. This attack is known as a collision attack. SHA1 has recently been broken thanks to a method discovered by Marc Stevens and his team. To find a solution we would need operations.
2.3- Keccak 256 in Ethereum
Keccak 256 is a sponge function. Sponge functions are a generalization of hash functions. A sponge function receives as the input a bit stream of any length and return as the output a bit stream of desired length, thanks by padding. A sponge function is developed according to the sponge construction.
Sponge construction: The sponge construction is divided in two phases: the absorbing phase and the squeezing phase. Below is a diagram to illustrate this construction. The sponge construction operates on a state of b= r + c bits (State Memory).
29
Figure :Sponge functions diagram
Let’s explain how it works, using the diagram and paying attention to the fact that there are two distinct phases.
Absorbing phase:
In the absorbing phase the message is padded and divided into r-bit blocks. In the diagram r=2, because we have the M0 and the M1 blocks. M0 is operated with the r bits of the state memory, first initialized to zero (in yellow in the figure) with the XOR function and the result is passed to a compressing function f, which stores this value in the state memory (in yellow). Then f is operated with the second r-bit block with the XOR function, and f is updated once again. This has to be done for every block.
Squeezing phase:
The first r bits to be outputted are the ones to be outputted and compressed last in the absorbing phase. If we needed more bits, we would pass that result to f and so on, until we reached the number of desired bits.
So, what about function f?
f is a transformation or permutation function. If it is a permutation function then it has to belong to the Keccak- f permutations, denoted by Keccak-f[b], where b
{25,50,100,200,400,800,1600} and b is the number of bits it will be operated on (known as the width of the permutation).
2.4- Attacks on sponge functions
30
A sponge function can be represented as a graph with 2b nodes and 2b edges. The nodes correspond to the state values and for every couple (s, t), where s and t are both state values and f(s)=t, there is a directed edge from s to t. There is one edge per node exactly (we have the same number of edges as nodes). We will give some definitions concerning the graph for a better understanding of the following sections:
- Supernode: Subset of all nodes with the same inner state. - Absorption of an input string: It is possible to absorb an input string P, by
following the following edges, starting from the root (supernode 0).
Model of the adversary:
In the beginning the adversary has no information on f. f is a blackbox and so the only way he/she can gain information on f is to make calls to f (and f-1 if it is a permutation). An adversary could generate a table containing x and f(x). The adversary’s objective is to draw the graph (adversary graph). In the adversary graph a node s is reachable from t if there is a sequence of directed edges from t to s, in the right direction. The adversary will query for edges he/she has no information about. Querying for f corresponds to adding to the adversary an edge starting from a given node and querying for f-1
corresponds to adding an edge that arrives at a given node. It is possible to obtain the optimal probability of success as a function of the number of calls the adversary has made (N). Obviously, a high N means the attacker needs to call many times f to obtain a concrete probability of succeeding. A success probability of 5% means that 95% of the possible choices for the attack do not work. The cost function of an attack is defined as: cp(success)= -log(1-P(success), where P(success) is the probability of success.
Some primary attacks:
Inner Collisions: We say that an adversary has inner collisions if he/she finds two paths from the root to some supernode.
Finding a path to an inner state: An adversary must find a path from a given node to an internal state.
Output cycle: The goal is to find cycles in the output.
This table sums up the cost functions for a given attack, distinguishing between f being a random transformation or a permutation.
Function f Inner Collision Finding a path to an Inner state
Output cycle
Random Transformation
31
Random Permutation
3. Elliptic Curve Cryptography
Bitcoin, Ethereum and Hyperledger use ECDSA (Elliptic Curve Digital Signature Algorithm) as the algorithm for signing transactions. We will give a brief overview of Elliptic Curve algorithms and what they do.
3.1. Basic Overview of Elliptic Curve Cryptography
Fields: Fundamental algebraic structure widely used in mathematics. Formally, a field is a set F with the addition (denoted by a + b, with a and b, two elements of the field) and multiplication operation (denoted by a . b, with a and b, two elements of the field). These two operations are required to satisfy the following properties:
1- Associativity of addition and multiplication: a +(b+c) = (a+b) + c and a · (b · c) = (a · b) · c.
2- Commutativity of addition and multiplication: a + b = b + a and a · b = b · a. 3- Identity element: There exists an element e and an element e’, such that a+e=a
(this e would play the role of the zero in standard addition) and a · e’= a (this e’ would play the role of 1 in the multiplication).
4- Additive and multiplicative inverses: a ≠ e and a Ꞓ F, a’, such that a + a’= e. Equivalently, b ≠ e’ and b Ꞓ F, b’, such that b + b’= e’.
5- Distributivity of multiplication over addition: a · (b + c) = (a · b) + (a · c).
Suppose K is any field
, such that:
X=λX1 Y=λY1
Z=λZ1
In with elements {0, 1, 2, 3, 4, 5, 6, 7} the points (4, 1, 1) and (5, 3, 3) are equivalent for λ= 12, since the operations are to be done modulo 7. (4, 1, 1) and (5, 3, 3) and in general any triple of the sort are called projective points. An elliptic curve over K is defined as the sets of solutions in of a homogenous Weierstrass equation of the form:
32
E : Y2 · Z + a1 · X · Y · Z + a3 · Y · Z2 = X3 + a2 · X2 · Z + a4 · X · Z2 + a6 · Z3, where ai
}. In cryptography, a base point G is chosen to be used with a good elliptic curve E(q). As our private key, we choose a random k, such that k . The public key is the result of multiplying k and G (k × G). If two users (we will call them Alice and Bob, for instance) have kA and kB and PA and PB as the public keys, they are able to calculate kA×PB = (kA×kB)×G. The difficulty of inversing this calculation relies on the Discrete Logarithm Problem, where the calculation of the discrete logarithm is very hard in some groups. The Discrete Logarithm Problem for elliptic curves can be defined as Johnson and Menezes described it in their work: “Given an elliptic curve E defined over a finite field
a point P E( ) of order n, and a point Q = l P where 0 ≤ l ≤ n-1 determine l”.
3.1.1- Elliptic curves over Fp Let p > 3, an elliptic curve E over Fp is defined by: , (1) where a, b (2) The set of points x Fp, satisfying equation (1) together with a point O, known as point at infinity, is known as the set E(Fp). These points form a group and O is the identity of the group. Addition Formula: Let’s suppose we want to add P and Q. We would draw a line between them and the reflection on the x-axis of the third intersection point in the curve is that sum, denoted as point R, here.
From the previous definitions, the diagram and the equations we can understand why O is called point at infinity. Suppose P=(x,y) and the inverse of P is (x,-y), denoted as -P. Then P+ (-P)=O. Let’s see this in a diagram. If we wanted to do 2P, this is equivalent as adding P+P, and so we perform the same operation as before. The only difference is that now we draw a tangent instead of a line between two points. This can be seen in the following figure:
33
The red point is -P and the two curves would intersect at infinity. In other words R would be at infinity . The point O takes its name from there.
3.1.2- Elliptic curves over F2
m
An elliptic curve E over this field is defined as: y2 +xy = x3+ ax2+b (3) where a and b 0. Equivalently as before E(F2
m) is the set of points such that: x F2
m, satisfying equation (1) together with a point O. These points form a group and O is the identity of the group. As in the the field Fp, the rule for adding points is the chord and tangent rule.
4. ECDSA (Elliptic Curve Digital Signature Algorithm)
34
Bitcoin, Ethereum and Hyperledger use ECDSA. ECDSA is a modification of the DSA algorithm. It requires smaller numbers in comparison to DSA and even with smaller numbers is as safe as DSA or RSA. We will give the pseudocode for the Signature Generation and the Signature Verification: Signature Generation: m is the message to be signed, n is the integer order of G We require a message m to be signed and domain parameters (q, FR, a, b, G, n, h), where q is the field size, where q=p or q= 2m FR is the field representation, or the representation used for the elements of . a and b are field elements, which define the equation of E. G is a base point, such that G=(xG,yG) is a point of prime order in Fq. n is the order of the point G. This means that n is the smallest n such that nG=O h is the cofactor, where h= , where n is the size of point G. According to the definition of the algorithm in
1.) Select a random integer k [1,n-1] 2.) Compute k*G=(x1,y1) and r= x1 mod n. If r = 0 choose another k. 3.) Compute k-1 mod n. 4.) Compute e = SHA-1(m) 5.) Compute s= k-1 (e + dr) mod n. If s =0, restart. 6.) Return signature= (r, s)
Signature Validation: To verify a signature (r, s), we must follow the following steps:
1.) Verify that r and s belong to the interval [1, n-1]. 2.) Compute e = SHA-1 (m). 3.) Compute w=s-1 mod n. 4.) Compute u1=ew mod(n) and u2=rw mod (n) 5.) Compute X= u1G + u2Q. If X= O reject the signature. Otherwise v= x1 mod (n),
where X= (x1, y1). 6.) Accept the signature if and only if v=r.
Not finished yet
5. Blockchain Applications
In this section we will talk about some of the many applications that blockchain can have.
35
5.1- Blockchain in IoT
The Internet of Things (IoT) is the interconnection of everyday devices thanks to the Internet.IoT is a combination of many techniques ranging from machine learning to control systems and automation. As early as in 1990, John Romkey invented a toaster that could be turned on via the Internet. This is considered the first IoT device. In 1999, the term “Internet of Things” is coined by Kevin Ashton. In 2008, there were already more devices connected to the Internet than people, and the First European IoT Conference was held. IoT has many applications, such as: enabling home appliances to be connected, often referred as “smart-home”, provide elder care by using voice control, medical and healthcare applications by monitoring the global health of a patient… We will concentrate on using blockchain in an IoT context.
5.1.1- IOTA
IOTA is the first Open source distributed ledger. Thanks to Blockchain technologies IOTA distributes and synchronizes ledgers of data and money in a permissionless environment. IOTA is based on “the Tangle” technology. It is called like that because transactions are not grouped together in blocks. Instead they are entangled together, as seen in this picture:
Figure “The Tangle”, a DAG
To make a transaction in this “tangled” network, two previous transactions need to be validated. IOTA has the following features: - Highly scalable - Low resource requirements - Zero-fee transactions - Secure data transfer - Offline transactions (devices do not always need a connection)
36
- Quantum immune (resilient to quantum attacks). The Tangle is a Directed Acyclic Graph, where the vertices are transactions and the edges are approvals. One transaction is connected to two previous approved transactions. As in
regular blockchain there is consensus in the Tangle. Once a transaction has enough cumulative weight (proof of work to validate a particular transaction) it is added.
5.2- Atonomi
According to their own description, Atonomi provides a “security protocol and infrastructure to enable billions of IoT devices to have trusted interoperability for data and commerce.”-Atonomi, “The secure ledger of things”. Atonomi is different from other solutions because it provides:
-Security between IoT devices and makes possible the identification of each device.
-Trust and reputation: The Atonomi network is capable of identifying and responding to untrusted devices.
-A fully extensible architecture
Atonomi can be used in a variety of different environments. Let’s take a look at some of them, as suggested in the Atonomi white paper:
Atonomi in Healthcare: Let’s suppose a hospital possesses an IoT system, that allowed to monitor products, track patients and other things. A sensor inside a hospital room could autonomously re-order stocks of blood, medicine and other things based on existing inventory, health records, scheduled surgeries and other parameters. Atonomi could provide the security for this network.
Atonomi in Industrial IoT, Smart Cities and Home Devices: In general, all these three are tasks that could be automated by integrating different devices. For instance, in a smart city the power consumption and traffic could be reduced thanks to these devices. If as a society, we want to rely on these systems, there is a need for trusted identity and the appropriate security needs to be provided.
5.3- Blockchain in government Services
Blockchain could be the mechanism to have more transparent governments. Some obvious applications include fraud prevention and reduce bureaucracy in general. Blockchain is perfect because it eliminates the necessity for a third party. Many people dread government operations because of long queues and bureaucracy in general.
37
Most of the times, the operations seem opaque and official information is not available or if it is available it is only updated after a period of time. With blockchain, we could see in real time where our money is, and how the tax money has been spent, for example. The second problem is that every operation is slow and inefficient, or at least it could be sped up and done more efficiently. Generally, most operations require time because the documents have to be sent by mail or submitted online. Then comes a human-verification phase, where officials have to verify and audit or documents. The third problem is that the government collects and stores our personal, private data, when we pay our taxes, for example. We give up some of our privacy in the name of security because there is currently no alternative. Finally, one of the biggest problems is the corruption. Not just from politicians, but in general. Corruption includes tax fraud, identity theft, falsified data of any sort …etc. To focus on a specific problem: elections. By implanting a blockchain based system, no one could argue that a result has been falsified. European Union (EU) Blockchain is a pilot project, created by the European Parliament “that aims to accelerate blockchain innovation and the development of the blockchain ecosystem, within the EU”, as stated in their page. The EU Blockchain publishes reports to provide an overview of a topic. Specifically, they have redacted a report named: “Blockchain for government and public services”. In this report they talk about blockchain in government services. They conclude that blockchain has multiple applications in government- related operations (some of them explained earlier), by using specific cases, but they also conclude that for some applications it might be possible to obtain similar results without using blockchain at all. For the EU blockchain experimentation needs to continue and has made a call for research proposal in the Horizon 2020 research and innovation programme, to reach the objective of delivering public goods and inclusive public services.
38
IV- CONSENSUS ALGORITHMS
1. Bitcoin’s Proof Of Work
Satoshi Nakamoto created Bitcoin and released it as opensource software in 2009. As a decentralized technology it does not rely on a central issuer and so a peer to peer network manages Bitcoin and its transactions in accordance to consensus in network software. The transactions are verified by the network nodes and then recorded in the ledger. In this section we firstly introduce some previous work, on which bitcoin’s consensus algorithm is based (Dwork’s and Naor’s Pricing functions) and then we discuss Adam Back’s work. Finally, we show some limitations of both Hashcash and Dwork and Naor’s pricing functions.
1.1. History
In 1977 Adam Back invented this algorithm for the purposes of combatting junk mail. SpamAssasin, Microsoft, Hotmail and others used hashcash. In the algorithm arriving at a solution is hard (the work or CPU time needs to be invested), but verifying the solution is trivial. When it comes to sending junk email the idea is for a legitimate email to arrive successfully at a destination, but a spammer should not be able to suceed due to the high amount of computations that would need to be carried out when sending many e-mails. Sataoshi Nakamoto then used this idea to generate a block in the blockchain.
1.2. Dwork’s and Naor’s Pricing Functions
This is an early stage of a Proof of Work (PoW) algorithm, where the sender must do some work, to prove that an email is worth sending. Similarly to Adam Back Dwork and Naor proposed a CPU cost function for combating spam emails. Let’s examine their work. Dwork and Naor propose a cost on transaction and call the function pricing function [2]. This function can have a trap door, which is a shortcut in the computation of the function. By providing additional information it would be possible to arrive at the solution more rapidly. Below are listed the properties of the pricing function (which can be easy, moderate and hard in difficulty) Functions use a difference parameter, which does an analogous job to that of a security parameter in cryptography. A security parameter is a variable that measures the input size of the computational problem. A function/ relation f is said to be a pricing function if:
1) f is moderately easy to compute.
2) Given l values: m1, m2. . . , ml, the amortized cost of computing f(m1), f(m2) is comparable to computing f(mi), i {1, ...l}. This means that computing a given value is not easier or harder than computing any other value.
39
3) It is easy to verify whether y= f(x), given x and y. Doing the calculations has to be hard but the verification needs to be easy.
Note: We must not choose a function that can be computed easily after having preprocessed it.
Now let’s define a shortcut properly. Let’s recall that a pricing function with a shortcut is easy to compute, when given the shortcut. For the reader to understand let’s give some definitions: Let S {0,1}* be a set where there is an efficient algorithm for selecting s S. F = flis such that s S, is a family of pricing functions, if given s fs is a pricing function. A collection F of families of families is said to have the shortcut property if there exists an efficient algorithm that generates a pair (s, c), where: 1-) s is uniformly distributed in S. This means that all outcomes are equally likely. 2-) Given only s, fs is a function in F. 3-) Given s and c, computing fs is easy, then c is said to be a shortcut. Note: When only given s, finding c or an equivalent shortcut should be hard. In the context of junk messages, the pricing functions is applied to the hash of the message (and never to the message itself). The hash function should be very easy to compute. Suitable hash functions include and/or are based on: DES, subset sum, MD4, MD5, Snefru. Types of Pricing functions:
1-)Basing the difficulty of sending on the difficulty of extracting square roots modulo a prime p. fp(x) = p(x) mod p. To verify this we do : y = x mod p.
2-)Fiat-Shamir based scheme: Based on the difficulty of factoring large numbers. This technique is used to prove that an entity knows a fact without explicitly revealing the fact. It is used o create a digital signature based on it.
3-) An Ong-Schnorr-Shamir based scheme, which is a signature scheme based on quadratic equations modulo a composite. Definition: fs(x) = (x1, x2), where x2 1 + lx2 2 = x mod N. In 2 and 3 there are shortcuts to speed up the calculation, and so they could not be used in Bitcoin.
1.3. Adam Back’s work
Adam Back devised a protocol where the client refers to the user who must compute a token (denoted T), using a cost function, which he calls MINT(). This function is used to create tokens and participate in a protocol, with a server. The server is the responsible for checking the value of the token, using a VALUE() function. It executes the protocol if and only the token had the right value. As we said in the introduction Hashcash was originally designed to prevent spammers from sending their unsolicited emails. The sender must pay with CPU time for his message to be sent. In the functions there is a parameter ω used, that parameterizes the amount of work the user will have to put in to mint (with the MINT function), the token. Interactive and non-interactive cost functions: With interactive cost functions, the server issues a challenge C to the client, using
40
CHAL() function, parameterized by ω as well, s is the service name. This is done so that a minted token can only be used for a particular service name. According to [1] and [4]:
C = CHAL(s, ω) T = MINT(C) V = VALUE(T) In non-interactive cost functions the client chooses its own challenge in the MINT function, and there is no need for CHAL.
T = MINT(s, ω) V = V ALUE(T)
1.4. The Hashcash cost function
According to [4] publicly auditable cost-function is a cost function that can be efficiently verified by a third party without the need to use a trapdoor. Trapdoor free cost function is one where the server does not have any advantages when creating the tokens, as opposed to known solution cost function. A probabilistic cost function is one where the cost of the client minting the token has a predictable, expected time. Within the probabilistic cost-functions, we can distinguish between: unbounded probabilistic cost and bounded probabilistic cost. An unbounded probabilistic cost function can take forever to compute (in theory). An example would be the cost function of ending up with a six when rolling a perfect dice. In theory, it is possible to throw the dice many times and never obtain a six, but the probability of not throwing a six for k throws, where k Z+, and p =
. When k is very big (we have thrown the dice many times), the probability is close to zero. With a bounded probabilistic cost function there is an upper bound with how unlucky the client can get. For example, if a client needs to search for a key in the list, the upper bound would be the length of the list and he would never have to look for more iterations than this. Having introduced all of this, Hashcash is a non-interactive, publicly auditable, trapdoor free with unbounded probabilistic cost cost-function. Hashback’s cost function We define H as a hash function with output size k bits. We define a binary infix comparison operator left =b where b is the length of the common left-substring from the two bit-strings. s={0,1}* and s||x denotes the concatenation of s and x. From Adam Back’s definition [1]:
41
The hashcash cost-function finds partial hash collisions on the all 0 bits k-bit string 0k,
since we are trying to find an x to satisfy that the hashing of the concatenation of s and x has w left of the common left substring. This means that we require the sender to produce a string whose cryptographic hash starts with a k zero. The fastest algorithm for computing hash collisions is brute force. Also, one of the main drawbacks of non-interactive functions is that an attacker could precompute all the tokens for a day and overload the system for that day. In 1997, Bitcoin used SHA1 as the hash function but it started to become weak and so SHA 256 is used currently. Bitcoin uses the described protocol and the hash function H is a double hash from SHA 256.
1.5. Critiques and Limitations According to Ben Laurie and Richard Clayton [3] when used to prevent spam emails Proof Of Work systems such as the ones designed by Dwork and Naor are not enough and are inefficient most of the time. As they say carrying out the required computations varies from machine to machine. Dwork however proposed in another of her works puzzles that would rely on RAM, rather than CPU to get comparable results in speed. Hashcash is slower on normal computers but fast using dedicated hardware known as ASICs. Their second objection has to do with the fact that the calculation done in the PoW is not useful. This only applies to Dwork’s and Naor’s work, since this computation is used to verify the validity of a bitcoin block. Dwork’s and Naor’s work is clearly oriented towards a prof of work when it comes to spam combatting while Adam Back’s work refers to bitcoin’s cost function. However, would it be possible to use the Fiat-Shamir (which is used for designing digital signatures) based scheme by adapting how bitcoin works? First of all, an appropriate hash function should be used. We want a hash function where every letter or digit is identified clearly. For the letters we create an isomorphism between letters and digits. When doing this with SHA256 we will produce an output that exceeds 256 bits, so a concise definition of the new customized function is needed. Assuming this we would use the Fiat-Shamir based scheme to prove that a user in the blockchain has correctly hashed the block’s header, without explicitly giving the hash and let the server verify whether the given value that we have not explicitly revealed is lower than the target. Even if we used this method since in the block header we need the previous block’s hash it seems like we would be wasting too much computational power. Besides if someone found a fault in the Fiat-Shamir based scheme, they would be able to generate illegal blocks. Obviously, when checking the hash of their result the other users in the blockchain would deem the result invalid, but again we would have wasted valuable resources and so it is much easier to check the result directly. Also trap doors in bitcoin would make this technology undemocratic, since a user could have access to a trap door and compute a solution
42
faster than the rest. For the time being there is no easy way of calculating hash collisions other than by brute force, if the hash function is chosen appropriately. In conclusion, Bitcoin’s consensus is based upon the difficulty of solving hash collisions, making the verification of the solution a trivial and fast process. The pricing functions proposed by Dwork and Naor [2] were oriented towards combating spam email and since their article was written there have been several attacks on keys that were thought to be safe. Both of these methods are PoW algorithms, which have the inconvenient of being centralized around the users with the most computing power. In the next section, we will explain how Ethereum deals with this issue.
2. Ethereum: From Proof of Work to Proof of Stake
We have seen that PoW in bitcoin rewards participants who solve a cryptographic puzzle by finding the zero k bits collisions in the hash function and thanks to that a new block is created. In the Proof of Stake (PoS) some validators propose and vote on the next block democratically, and the weight of each validator’s vote depends on the size of its deposit (called the stake). Currently Ethereum is using PoW but it is expected to transition to PoS. Ethereum’s PoW is similar to Bitcoin’s for the moment. The miners run the block’s header through a hash function and their objective is to obtain a hash lower than the specified target. Ethash is Ethereum’s 1.0 mining algorithm and the latest version of the Dagger-Hashimoto algorithm (which has suffered many changes so it does not correspond to its initial version).
2.1. Ethereum’s terminology
Seed: A number in a block that accounts for that block’s date. Concretely an Etash calculation is 30000 blocks long and the seeds are calculated recursively provided the first seed. This means that for epoch N the seed will be seed of (epoch N-1).
Full and light nodes [9]: Ethereum is a peer to peer network, where there are nodes (computer that participates in the Ethereum network) that interact with each other. A node does not have more privilege than another but their functions and degree of participation differs. The nodes have three functions essentially, which are: keeping a shallow-copy of the block chain (done by Light Clients), keeping a full copy of the blockchain (done by full nodes) and verifying the transactions or what is known as mining. Why would light nodes be used then? As it turns out light nodes are extremely important [8]. Downloading and maintaining the full blockchain is expensive from a computational point of view, so when one wants to take part in the network one might choose to become a light node. They help users access and interact with the blockchain without directly accessing the blockchain, since they use full nodes as intermediaries. A full node, on the contrary, is any computer that is connected to the Ethereum network
43
and enforces all the consensus rules. Needless to say full nodes provide Ethereum’s backbone. Specifically, full nodes are responsible for verifying that:
• The correct block reward is given out for each mined block and there is no double spending going on and the data structure is correct.
• Transactions have the correct signatures, and their data structure are correct.
Note: A miner is always a full node but a full node might not be a miner.
The nodes do the calculations and when they come to a consensus the transaction is agreed upon, by the whole network. As a result of the increase the number of calculations that the network has to go through has significantly increased. This in turn means that it is not able to handle as many transactions as traditional currency (PayPal or Visa). Here is an image from Ethash showing how much calculations have increased in this past year. Between May and June 2017 Ethereum’s transactions doubled in volume and this trend was maintained up until January 2018, where it reached its highest point with a total of 1,349,890 transactions on Thursday, January 4, 2018. Scalability is a basic need and currently is a big issue in Ethereum and replacing the Proof Of Work algorithm with a Proof Of Stake algorithm will solve it.
Figure. Ethereum Transaction Chart [19]
In the next section we will introduce in detail Proof of Stake.
2.2. Proof Of Stake (PoS)
In this section we will introduce some limitations of PoW and why it is necessary to switch to PoS. When using PoW, the block’s size (1 Mb) makes it hard to process many transactions. Increasing the block’s size would work for a finite amount of time, since it depends on the volume of transactions. Secondly, PoW is unfair. The miners that posess the best resources (ASICs or similar dedicated hardware) are able to mine more. Associated with this comes the power consumption that PoW needs to run. Formally
44
speaking a PoS algorithm replaces miners with validators. Each miner must lock some currency as stake. When they think a block must get appended to the chain they vote on it. If the block is finally appended they get a reward PoS presents numerous advantages in comparison to PoW. PoS achieves better latency with less computation and requires minimal storage space. It also validates transactions using a stake that every node has. A block is created by a node according to the stake that a node has and other parameters used to randomize the process of block creation.
2.3. The Byzantine Generals Problem
This problem was introduced by Lamport, Shostak and Marshall Pease in [12]. It is the problem of coping with the failure of one or more components in a computer. This failure can cause the computer to send conflicting information to different parts of the system. The name comes from the fact that we imagine the Byzantine army camped outside an enemy city. As any army it is divided into various parts, with each part having one general and the generals of the different parts being able to communicate by messenger. They must observe the enemy and come up with a plan of action, but what happens if some of the generals are traitors (faulty part in a computer)? It is possible to prove that when more than two thirds of the generals are loyal, there is a solution to the problem and the generals will reach consensus. The Ethereum protocol is based on this problem, so it is of critical importance to be familiar with it.
It is possible to prove that when more than two thirds of the generals are loyal, there is a solution to the problem and the generals will reach consensus.
A commander must send an order to the n-1 lieutenants, following these rules:
IC1: All loyal lieutenants agree on the same value.
IC2: If the commander is loyal then all loyal generals agree on the commander’s value.
We will give a definition of the algorithm for the Byzantine Generals Problem, according to the algorithm that Lamport et. al defined in their original paper. We inductively define OM(m), Oral Message algorithm. To define the OM algorithm, we first define the function majority. That is if a majority of the values vi equals v, then majority(v1,…,vn-1)=v. For the majority function we can choose the majority of the values(the greater number of a given value) or the median assuming that we are dealing with an ordered set of values.
Algorithm OM(0):
1.) The commander sends his value to every lieutenant. 2.) Each lieutenant uses the value she/he receives from the commander or uses the
value RETREAT if he/she received no value.
45
Algorithm OM(m), :
1.) The commander sends his value to every lieutenant. 2.) , let vi be the value Lieutenant i receives from the commander or RETREAT
if the lieutenant receives no value. Then Lieutenant i will act as the commander in OM(m-1)to send the value vi to the n-2 remaining lieutenants.
3.) , let vj the value be the value lieutenant i received from lieutenant j, in step 2, using OM(m-1) or RETREAT if no value was received. Lieutenant i uses the value majority (v1,…,vn-1).
Let’s take a look at would happen with one commander and two lieutenants if one (either the commander or the lieutenant) is not loyal and see that there is no solution.
Case 1: One of the lieutenants is not loyal, represented with a red “L”:
Case 2: The commander is not loyal, represented with a red “C”:
From L1’s perspective both of these scenarios look the same, but if the commander is loyal L1 must attack and otherwise it should probably RETREAT. So, with three generals and one traitor there is no solution. Lamport, Shostak and Pease prove in their paper that no solution exits with the Oral Messages algorithm k traitors, if there are fewer than 3k+1 generals in total.
46
Let’s do an example with one traitor and 4 generals, assuming that one of the lieutenants is the traitor. v, x and y are the values sent by the nodes. In this case the commander is loyal and sends v as the value.
OM(1), Step 1:
OM(1), Step(2):
Now every general acts as the commander in OM(0):
L1 as the commander:
L2 as the commander:
L3 as the commander:
47
OM(1), Step (3):
Now we must use the majority function for every loyal lieutenant. Assuming the first definition of majority, we talked about in the introduction to this problem this corresponds to the value that has been received the most for each general.
majority(L1) = majority (vc, vL2, yL3) = v
majority(L2) = majority (vc, vL1, xL3) = v
So, consensus has been reached in this case, for four generals with one traitor being a particular lieutenant.
2.4. Ethereum Casper
Casper is a family of protocols. There are two concrete projects in development right now: Casper FFG (Friendly Finality Gadget) and Casper CBC (Correct by construction). Casper differs from other PoS protocols because it punishes malicious elements. Notion of finality, as defined in [9]: The fact that a block is firmly established in the blockchain. If this was block was to be overtaken by a competing block a very large portion of validators (staking nodes) must act in a way that is clearly malicious from a cryptographical point of view. If the validators act maliciously to revert the established block, the chain would detect this malicious activity and the validators’ deposits would be taken away and the reversion of the block would be very expensive.
2.4.1. The CBC Protocol
First, let’s have a look at the parameters in this protocol, according to the formal definition [5] and [7]:
-Validator set V: The identification of the nodes that are responsible for coming to consensus. In reality, this set can be the set of public keys of nodes participating in the consensus algorithm.
48
-Validator weight map: The validator weight map is a function that takes any validator and returns their “weight” in the consensus protocol. This weight will determine how much their vote is worth when coming to consensus. CBC Casper allows different nodes to have different amounts of weight. Nodes are weighted proportionally to the value they have staked.
-Fault tolerance threshold t: Number of faults that the protocol can tolerate. Now, we will explain what the CBC Casper Consensus Safety Proof is. The consensus safety proof is what assures the protocol’s safety. We will describe the proof, which is shared by every single protocol derived from CBC Casper.
1) Every validator maintains a set of messages they have seen (known as “protocol state”). A message is composed of the triple: consensus value, validator name, protocol state.
2) A validator can use an “estimator” (decision making mechanism) to make an estimate about the current value of the consensus, based on the set of estimates they’ve seen. In binary consensus (deciding between two values), the estimator would return either a ”0” or ”1”, for example. In blockchain consensus, the estimator would say “the canonical blockchain (the longest chain) is made up of blocks 0xbc2d...” and cite all the blocks in the chain.
3) An estimate is said to be safe in a protocol state if it will be the estimate for any future protocol state always. For example, in binary consensus, if a validator can output 1 as his estimate and no matter what messages he receives from other validators his estimate remains 1, the estimate is said to be safe. It should be impossible to detect safety on 1, while another validator detects safety on 0. All of this works if there are no faulty validators or nodes, but what happens when a node tries to tamper with the safety of the chain? Nodes acting maliciously could impede other nodes on making a decision. Let’s have a look at the type of faults that can occur:
-Crash faults: They occur when a node stops making messages.
-Invalid messages: Messages that output an unexpected value. For example, suppose we are running a binary consensus protocol, that outputs 0 or 1 and a node generates a 2. This message in obviously invalid.
-Equivocation: A node is equivocating if it is running two copies of the consensus protocol that are unaware of each other. For example, when running a binary consensus protocol, a node is equivocating if it makes two messages that are different (one outputs a 0, while the other outputs a 1). To handle faults in the safety proof, a set of messages is no longer a valid protocol if it contains a number of invalid messages or equivocations. Nodes will make the same decisions if the common feature that they share contains less than some number of faults. How to detect estimate safety? Validators must have a technique for detecting when their estimates are safe, which are vital when making decisions. This is done by specifying “safety oracles” (usually a web service), that the validators use. Some oracles can calculate the minimum amount of safety an estimate has.
49
Types of safety oracles: [6]
Adversary Oracle
Input: Protocol state and some estimate.
Computation: The adversary oracle creates a model of all the validators in the network and simulates a conspiration to change his estimate. Output: If in the simulation there is a change in his estimate return False (potential attack has succeeded). Otherwise True (the estimate is safe).
Note: This oracle will never say an estimate is safe when it is not safe, but it may say an estimate is not safe when it is safe, since it deals with a potential attack.
Clique Oracle
Tries to decide whether an attack on an adversary would be beneficial. To do this, a graph is constructed, as explained below:
1. Create a node for each validator in the graph.
2. For each pair of validators, if each validator has a latest message and cannot see a message from each other in the future that is not on the given estimate, create an edge between them. The estimator functions are determined by validator weight, if the majority of validator weight is locked into seeing a single estimate, this estimate is safe. Seeing a single estimate corresponds to finding the clique number of the constructed graph and comparing this number with the validators’ weight.
It considers edges between validators in graph, but instead of searching for the largest clique in the graph, the oracle uses Turan’s Theorem to find the minimum size of a clique that must exist in this graph. With this result, it uses the same process as above to detect if the estimate is safe as well as calculate the minimum amount of safety that must exists on this estimate.
2.4.2. Casper FFG
The network comes to consensus as to which blocks can be finalized. Casper selects the proposed blocks and the canonical chain in the ledger. Using the definitions presented in [10] Casper FFG is designed to be a hybrid PoW/PoS consensus mechanism. It implements a Proof of Stake mechanism on top of Proof of Work. There is a fixed set of validators and a Proof of Work function. As in a normal blockchain this is how children blocks are produced in the blockchain. However, a malicious attacker could cause one same parent to have various children, and one parent must only produce one child. Casper’s job is to select correctly the right child for each parent. In doing so, Casper will subsequently select the right canonical (longest) chain. In Casper if a validator violates a rule, that validator can be localized and punished. The validators change overtime, for
50
security reasons. For efficiency purposes Casper does not deal with the whole block tree, but rather deals with the checkpoint’s subtree. There is a checkpoint at any height which is a multiple of 100 and the genesis block is a checkpoint as well. A checkpoint is just a point where finality is assessed via a network of validators. Finality is assessed every 100 blocks and the genesis block is always a checkpoint. Each validator has a deposit and they broadcast vote messages (containing the hash of any justified checkpoint, called the source s; any checkpoint hash that is a descendant of s and that is known as “the target” t; the height of s and the height of t. The public key of a particular validator needs to be in the validator set for a vote to be valid. Casper FFG differs from previous Byzantine Fault Tolerant (BFT) algorithms, because it has the following:
-Accountability: If a validator violates a rule, that validator can be localized and punished. The validators change overtime, for security reasons. This solves a major problem known as “Nothing at stake problem”. This problem occurs when there is a fork and the network has to agree on one of the two chains. When voting on an incorrect chain does not have a negative repercussion, we are facing the nothing at stake problem.
• Dynamic validators: Entities that carry out validation. This means that they make sure every full node agrees that a certain node in the network can create the next block, to receive the reward. As we said in the previous point the validators change overtime. This means that new validators must be able to join and existing validators must be able to leave. We will try to understand how the validator set changes over time.
• Dynasty: The dynasty of a block is a number accounting for the number of finalized checkpoints in the chain from root to the parent of block b. When a potential validator’s deposit message is included in a block with a given dynasty that validator will join the validator set. Whenever a validator wants to leave it sends a “withdraw message”. Once a validator leaves the validator set it cannot rejoin it. When a validator leaves the set its deposit is locked for a long period of time known as the withdrawal delay. If the validator acts incorrectly its deposit is slashed. This removes the need to handle multiple start/end dynasties for a single identifier. At the start of the end dynasty, the validator’s deposit is locked for a long period of time, called the withdrawal delay (approximately “four months’ worth of blocks”), before the deposit is withdrawn. If, during the withdrawal delay, the validator violates any commandment, the deposit is slashed.
• Defenses: We should consider two common attacks: long range revisions and catastrophic crashes. We will introduce both of these attacks: Long range revisions: What would happen if a coalition of former validators formed and tried to attack the chain? If this is done after their withdrawal time, they could attack it without the fear of their deposit getting slashed. These attacks are prevented by a fork-choice that makes reverting an already finalized block impossible.
• Catastrophic crashes: We have talked about the Byzantine Generals Problem and we have assumed (there is a formal demonstration in [12]) that as long as one third or less of the validators are treacherous the consensus will work. What would happen when more
51
than a third of the validators fail at the same time? Buterin et. al introduce the concept of “inactivity leak”. This is a coefficient that makes the deposit of a given validator grow smaller and smaller in relation to the amount of time it stays inactive. The more time it is inactive the smaller deposit it will have. Eventually, the validators that are active and voting will constitute the majority of the votes and the inactive validators will be negligible. The ether lost by a validator can be lost or returned to that validator after some days. In conclusion, Casper FFG is a hybrid PoW/PoS consensus mechanism. It focuses more on a multi-step transition to introducing PoS for Ethereum [11]. Therefore, this is the first mechanism that Ethereum will implement to transition to a PoS system. CBC is a protocol that focuses on formal methods by proving that the nodes in their system will share common protocol states and the decisions made by these nodes are consistent, because they share protocol states. When Casper is fully developed it will most likely take parts from Casper FFG and CBC.
3. Hyperledger’s Kafka
Hyperledger is an open source collaborative platform to build blockchain by the Linux Foundation. The objective is for companies and software developers to meet and build blockchain frameworks. We will be focusing on Hyperledger Fabric, which is one of their projects among other (Caliper, Cello, Composer. . . etc) and is a private BC. I this section we will give an overview of how Hyperledger Fabric works, followed by a general explanation on how Kafka works. Finally, we will explain how Kafka is implemented in Fabric’s particular case.
3.1. Hyperledger Fabric
It is a business permissioned blockchain and is the first blockchain technology that runs applications written in general purpose languages without depending on a particular cryptocurrency and supports modular consensus protocols. As all permissioned blockchains it runs the blockchain among a set of identified participants that do not fully trust each other. Hyperledger Fabric is able to overcome the following problems, that previous permissioned blockchains encountered [13]:
• Consensus is hard coded within the platform, which impedes the development of tailored solutions.
• The trust model of transaction validation is determined by the consensus protocol and cannot be adapted to the requirements of the smart contract (a computer program that directly controls the transfer of digital currencies or assets between parties under certain conditions).
52
• Smart contracts must be written in a non-standard language, which makes difficult the programming.
• The sequential execution of all transactions by all peers limits performance, and complex measures are needed to prevent attacks.
• There is a confidentiality issue, since every smart contract runs on all peers.
Figure 3. A brief explanation of how fabric works [13]
Fig. 3 explains Fabric’s architecture. As we can see a Fabric blockchain consists of a set of nodes. Since Fabric is permissioned all participating nodes have an identity, provided by the Modular Service Provider (MSP). OSNs are the Ordering Service Nodes and form the ordering service, responsible for establishing the total order of all transactions. The different shades and colors in the diagram correspond to chaincode (smart contract). Clients submit transaction proposals for execution and broadcast transactions for ordering. Peers execute transactions proposals and validate transactions. They are also responsible for maintaining the blockchain ledger. Not all peers execute transactions proposals, only endorsing peers.
3.2. Kafka in general
Kafka is a distributed system running in a cluster and a general purpose publish subscribe messaging system [14] and [15]. Consensus in Fabric occurs because the nodes provide a guaranteed ordering of the transaction. However, in its initial version consensus in Fabric [16] was achieved thanks to a native implementation of PBFT (Practical Byzantine Fault Tolerant), which is an optimization of the original Byzantine problem. Consumers subscribe to a topic (data stream) to receive new messages, that are published by the producer, pushing the message in a topic. When topics are too big, they are split up into partitions. All messages inside a partition are sequentially ordered. Consumers poll Kafka’s server and ask to read a particular record, by reading from the topic. The same message is never red twice. The consumer is subscribed to a topic and knows which
53
partition leader to grab the messages from thanks to the zookeeper service. Zookeeper is a software developed by Apache, that stores metadata and allows the clients of the service (Kafka brokers) to subscribe and have changes sent to them once they happen. Fabric inherits its resilience against crashes from Zookeeper. There is another version of the ordering service to make Kafka Byzantine Fault Tolerant, as it is only Fault Tolerant. In Kafka, each broker holds a number of partitions (either a leader or a replica for a topic). It is used to maintain naming, configuration data and provide flexible and robust synchronization within distributed systems, allowing clients to perform simultaneous reads and writes. It divides the data across multiple nodes, achieving high availability and consistency and allows the brokers to know who the partition leader is. It is essential because it has the following features:
• Controller election: The controller is a broker responsible for maintaining the leader-follower relationship across all partitions. There must only be one controller and the follower nodes must agree on who the controller is.
• Configuration of Topics: This includes: the list of existing topics, the number of partitions for each topic, location of all replicas, and who the leader is.
• Access control lists: Contains the brokers that can access a given topic.
• Membership of the cluster: List of all the brokers that are functioning and are part of the cluster.
• It coordinates the brokers in case of a crash.
3.3. Kafka in Fabric
Kafka in Fabric is implemented differently but following the main idea that we explained previously. We will define some vocabulary first [20]:
• Chain: Log that a group of clients has access to (it is the channel). A channel is like a topic that permissioned peers may subscribe to. Only members can transact in that channel.
• RPC: Stands for Remote Procedure Call and is a protocol used to request a service from a program located in another computer on a different network.
• Broadcast RPC: The transaction submission call, from a node to the orderers.
• Deliver RPC: The Deliver request is what happens after the transaction is processed via the clients of the service and is served to the clients on the receiving side. Every chain has a separate partition and each chain maps to a single partition topic, since a partition is a subdivision of only one topic. The OSNs confirm the permissions in the chain and send forth the client’s transaction, received by Boadcast RPC, to the chain’s corresponding partition. The OSNs consume that partition and get back an ordered list of
54
trans-actions. The transactions in a chain are arranged in sets, with a timer that is set when the first transaction arrives. The block (which contains the ordered set of transactions) is cut, when that timer expires or when the maximum number of transactions is reached. Every OSN maintains a local log for each chain. The transaction blocks are sent to the clients via Deliver RPC. Let’s see this in an example:
Figure 4 Kafka at work
In Fig. 4 there are three transactions (“foo”, “bar” and “baz”). The names are not significant, and they only serve to identify each transaction. OSN 0 has transaction “foo”, relayed to the Kafka Cluster. At this same time OSN 2 relays transaction “ baz” to the cluster. After that transaction “bar” is sent to the cluster. Considering this exact order the cluster now has three transactions. The client then sends a delivery request and the OSN 1 has a block with the three transactions, sequentially ordered according to what we have described. It will serve the client with Block 4 completing the process. In conclusion, Kafka provides great throughput, message distribution and ordering thanks to the OSNs. However, according to [17] Hyperledger Fabric has some fundamental safety issues, that could be resolved with a better consensus protocol. Fabric sets up point to point interactions between nodes that do not trust each other. By doing that the smart contract is shared among the parties and so if a node goes down the other organizations can modify the data. Maybe a solution similar to the inactive Byzantine Generals could be adopted in this case.
4. Conclusions on consensus algorithms
55
In this section we have provided a comprehensive survey of three consensus mechanisms, used by three of the main blockchain technologies. This was done by firstly giving an overview of the particular blockchain technology, analyzing previous work in detail and then explaining where the current research is at by explaining the current consensus mechanisms that are used and the general problems faced by consensus algorithms (Byzantine Generals Problem, for instance). Every consensus mechanism is susceptible to attacks and so we can hope that future research focuses on a hybrid approach, like Ethereum is doing with Casper FFG, to incorporate the advantages from each consensus protocol, and achieve a greater level of scalability and decentralization, as suggested by [14].
56
V- APPLICATION
I have developed a simple blockchain application, in Python, that runs on the computer’s localhost. The code was taken from [47] and the interface is of our own creation. We will explain how all parts work (even the ones that we have created ourselves).
Files and their main methods
File main.py
It is from this class that the program is called and the execution starts. This file has the objective of running two threads (the interface one) and the server one, in charge of starting our local server, where the blockchain will exist.
testWrite.py:
Contains auxiliary methods used to modify the list of ports in an auxiliary file, to read from that file and to add a port automatically to that file.
bc_ui.py:
This is the interface of the application. It uses PyQt’s designer files for each window and executes the methods so that they are easier for a user to see. The logic behind it is implemented in blockchain.py.
File blockchain.py
This is the backbone of the program and was taken from [47]. Let’s explain some of the most relevant methods in this file:
class Blockchain:
__init__(self): Method that initializes our class with the class arguments. Concretely, the transactions, chain and nodes are initialized.
new_block(): creates a new block. The proof is the result of mining.
register_node(self, address): Used to register a node, where address is the address of the node.
proof_of_work(self, last_proof): As in traditional blockchain, we need to find a number that when hashed with the previous block’s solution produces another number with 4 leading zeroes. If we wanted a harder proof-of-work algorithm it would be sufficient to modify the number of leading zeroes. We would need to modify this line: return guess_hash[:4] == "0000", and write return guess_hash[:k] == "0000…0", where k is the number of zeroes and “00..0” contains exactly k zeroes.
valid_chain(self, chain): This is where the consensus algorithm is implemented.
57
We interact with our blockchain as an API. This means that we need GET and POST requests to interact with it. To provide the data for the POST requests we have designed the interface. To make the output more readable, we have done the same thing with the GET requests.
58
The following picture is a summary of how the program works and its interactions with all of its modules.
First, main.py is executed. This creates two threads. One that fires up the localhost server and the other one with the graphical interface. For the graphical interface to work, we need the .ui files and in the file ‘portList.csv’ we store the ports that have been used for the connection. The green arrows represent the creation of a thread, the orange arrows represent an interaction between modules, the blue rectangles are .py files and the green rectangles are .ui files.
Figure 5: Summary of the structure of our program
Future improvements
A more user-friendly interface could be developed. This was not done due to the time, but it could be a future improvement. In this case, it was more important for the program to correctly work and do exactly what was described in [47].
We could implement a synchronized mechanism to access portList.csv, if we wanted to scale this app, to run it on a real server. In this case synchronization is not needed because only a user at a time accesses the file.
59
VI. FINAL CONCLUSIONS
In this work, we have gone over the fundamentals of blockchain. Blockchain relies on asymmetric encryption. Satoshi Nakamoto (whose real identity is still unknown) is the inventor of Bitcoin and the creator of the first blockchain in 2008. Ever since, the publication of the Bitcoin white paper numerous other Blockchain technologies and cryptocurrencies have emerged. Bitcoin and Ethereum are public blockchains and Hyperledger Fabric, developed by IBM is a private blockchain. As a result, Bitcoin and Ethereum share some of the block’s and transaction’s structure, while Fabric has a completely different design.
Hash functions are key in Blockchain. Thanks to SHA-256 the blocks can be linked cryptographically, making the blockchain a secure ledger. Bitcoin uses double SHA-256 (SHA-256(SHA-256(Block_Header))) and Fabric uses SHA256(Block_Header). We have shown how different types of transactions work for these three technologies, making a distinction when it was required. On the other hand, we have Ethereum that uses Keccak256, a sponge function. We have explained in detail how this function works, and we have given an idea of the most famous attacks on sponge functions. ECDSA, a variant of the DSA algorithm, is responsible for Blockchain’s security, when signing a transaction. We have given the steps for the signature generation and verification.
Consensus is the mechanism responsible for making decisions in a blockchain and thus creating new blocks. In this chapter we have reviewed the Byzantine Generals Problem, explaining theoretically the algorithm and then illustrating step by step how it would work with one traitor. We have explained the consensus algorithms used in Bitcoin, Ethereum and Fabric, by first giving an overview of past work when the current consensus is based on previous work.
A technology that started as a substitute for money has evolved and currently has a wide variety of applications. We might see blockchain in a future be used by government as a form of currency (cyptocurrency), because of its traceability mainly. Governments should experiment more with cryptocurrencies, to adopt them in a near future. Concretely they should face the challenges of scalability and privacy. Another possible future direction is blockchain identity. These systems will provide a source of verification for individuals. Currently there exists a vast number of people that lack proof of identity. Blockchain based identity systems will be secure and provide privacy. We have talked how governments could adopt this type of technology to keep track of official records, for example. Could one cryptocurrency be the basis of tomorrow’s global economy?
60
VII- BIBLIOGRAPHY
[1] Adam Back, “A denial of service counter measure”, August 2002.
[2] Cynthia Dwork and Moni Naor, “Pricing via processing or combating junk mail”, Proceedings of Crypto, 1992.
[3] Ben Laurie and Richard Clayton, “Proof-of-Work Proves Not to Work” Available HTTP: https://www.cl.cam.ac.uk/ rnc1/proofwork.pdf.
[4] Adam Back, “Hashcash-amortizable publicly auditable cost-functions” Available HTTP: http://www.hashcash.org/papers/amortizable.pdf
[5] Vlad Zamfir, Nate Rush, Aditya Asgaonkar, Georgios Piliouras,“Introducing the “Minimal CBC Casper Family of Consensus Protocols”,in Github November 2018.
[6] Correct by Construction Casper Developers, “Correct by Construction Wiki ” Available HTTP: https://github.com/ethereum/cbc-casper/wiki/.
[7] Blockgeeks Team, “What are Ethereum Nodes and sharding?” Available HTTP: https://blockgeeks.com/guides/what-are-ethereum-nodes-andsharding/
[8] Thibaut Sardan, “What is a light client and why you should care?” Available HTTP: https://www.parity.io/what-is-a-light-client/
[9] Blockgeeks Team, “What is Ethereum Casper Protocol?” Available HTTP: https://blockgeeks.com/guides/ethereum-casper/
[10] Vitalik Buterin and Virgil Griffith “Casper the friendly finality gadget”, in Ethereum Foundation, January 2019.
[11] Jon Choi, “Ethereum Casper 101” Available HTTP: https://medium.com/@jonchoi/ethereum-casper-101-7a851a4f1eb0
[12] Leslie Lamport, Robert Shostak and Marshall Pease “The Byzantine Generals Problem”, in SRI International, 1982.
[13] Elli Androulaki et. al, “Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains”, in ArXiv April 2018
[14] Blockgeeks Team, “What is Hyperledger? The most Comprehensive guide ever” Available HTTP: https://blockgeeks.com/guides/hyperledger/
[15] Hyperledger Fabric Team, “ Hyperledger Fabric” Available HTTP: https://hyperledger-fabric.readthedocs.io/en/release-1.4/whatis.html
61
[16] Christian Cachin and Marko Vukolic , “ Blockchain Consensus Protocols ´ in the wild”, in ArXiv July 2017.
[17] 10XTS Team, “Hyperledger Fabric – The Good, The Bad, and The Opportunity” Available HTTP: https://10xts.com/hyperledger-fabric-thegood-the-bad-and-the-opportunity/
[18] Zibin Zheng et.al “An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends” in 2017 IEEE 6th International Congress on Big Data.
[19] Etherscan Team, “Ethereum Transaction Scan” Available HTTP: https://etherscan.io/chart/tx
[20] Priyansh Jain, “The ABCs of Kafka in Hyperledger Fabric” Available HTTP: https://codeburst.io/the-abcs-of-kafka-in-hyperledger-fabric- 81e6dc18da56 vL2
[21]Ethereum Research Blog Available HTTP: https://ethresear.ch
[22] Ethereum News Blog Available HTTP: https://www.ethnews.com
[23] Jamie Talbot, “What are bloom filters?” Available HTTP: https://blog.medium.com/what-are-bloom-filters-1ec2a50c68ff
[24] Tutorials Point Team, “Cryptography Hash Functions” Available HTTP: https://www.tutorialspoint.com/cryptography/cryptography_hash_functions.htm
[25] The Information Warfare Team, “Descriptions of SHA-256, SHA-384 and SHA-5212” Available HTTP: http://www.iwar.org.uk/comsec/resources/cipher/sha256-384-512.pdf
[26] Keccak Team, “The sponge and duplex constructions” Available HTTP: https://keccak.team/sponge_duplex.html
[27] Guido Bertoni, Joan Daemen, Michael Peeters and Gilles Van Assche, “ Cryptographic sponge functions” Available HTTP: https://keccak.team/files/CSF-0.1.pdf
[28] “Cryptographic requirements for breaking SHA-256”, Available HTTP: https://crypto.stackexchange.com/questions/52571/computational-requirements-for-breaking-sha-256
[29] Bitcoin Wiki team, “Block”, Available HTTP: https://en.bitcoin.it/wiki/Block
[30] Kiran Vaidya, “bitcoin’s implementation of Blockchain”, Available HTTP: https://medium.com/all-things-ledger/bitcoins-implementation-of-blockchain-2be713f662c2
[31] Coin Bundle Team, “Consensus algorithms: Securing blockchain transactions” Available HTTP: https://medium.com/coinbundle/consensus-algorithms-dfa4f355259d
62
[32] “What exactly is a security parameter?”, Available HTTP: https://crypto.stackexchange.com/questions/52309/what-exactly-is-a-security-parameter
[33] KC Tam, “Transactions in Ethereum”, Available HTTP: https://medium.com/coinmonks/transactions-in-ethereum-e85a73068f74
[34] Alyssa Hertig, “How do Ethereum contracts work?” Available HTTP: https://www.coindesk.com/information/ethereum-smart-contracts-work
[35] Bitcoin Wiki Team, “Pay-to-Pubkey-Hash” Available HTTP: https://en.bitcoinwiki.org/wiki/Pay-to-Pubkey_Hash
[36] Bitcoin Wiki Team, “Pay to script Hash” Available HTTP: https://en.bitcoin.it/wiki/Pay_to_script_hash
[37] Bitcoin Wiki Team, “Transaction” Available HTTP: https://en.bitcoin.it/wiki/Transaction
[38] Naveen Honest Raj, “Hyperledger Fabric Transactions. What is it? And how does it happen” Available HTTP: https://www.skcript.com/svr/hyperledger-fabric-transactions-what-is-it-and-how-does-it-happen/
[39] Hyperledger Fabric Team, “Transaction Flow” Available HTTP: https://hyperledger-fabric.readthedocs.io/en/release-1.4/txflow.html
[40] Postcapes Team, “Internet of Things(IoT) History”, Available HTTP: https://www.postscapes.com/internet-of-things-history/
[41] Atonomi Team, “Bringing Trust and Security to IoT” Available HTTP: https://atonomi.io/#
[42] EU Blockchain Observatory and Forum Team, “Blockchain for government and public services”. Available HTTP: https://www.eublockchainforum.eu/reports
[43] Don Johnson and Alfred Mendoza, “The Elliptic Curve Digital Signature Algorithm (ECDSA)”, August 1999.
[44] Laura Gargolinski Jaeger, “Public versus Private: What to know before getting started with blockchain”. Available HTTP: https://www.ibm.com/blogs/blockchain/2018/10/public-versus-private-what-to-know-before-getting-started-with-blockchain/
[45] Raja, “Blockchain Infographic: Growth, Use Cases & Facts”. Available HTTP: https://www.dotcominfoway.com/blog/growth-and-facts-of-blockchain-technology
[46] Kate Mitselmakher, “The Future of Blockchain Technology: Top Five Predictions for 2030”. Available HTTP: https://www.blockchain-expo.com/2018/10/blockchain/future-of-blockchain-technology/
63
[47] Daniel Van Flymen, “Learn Blockchain by building one”. Available HTTP: https://hackernoon.com/learn-blockchains-by-building-one-117428612f46
[48] Nigel P. Smart, “Cryptography made simple”, London: Springer 2016, pp. 67-78.
[49] Shweta Lamba and Monika Sharma, “An Efficient Elliptic Curve Digital Signature Algorithm (ECDSA)”, in 2013 International Conference on Machine Intelligence Research and Advancement.
[50] Penny Pritzker and William E. May “Secure Hash Standard (SHS)”, in Federal information processing standards Publication, 2015.
[51] Senthil Nathan, “Hyperledger Fabric V1.0: Block Structure”, Available HTTP: https://blockchain-fabric.blogspot.com/2017/04/hyperledger-fabric-v10-block-structure.html [52] Michael Crosby et. al “Blockchain Technology: Beyond Bitcoin” in Applied Innovation Review Issue No. 2, June 2016.
![The Bitcoin Lightning Network · 1 The Bitcoin Blockchain Scalability Problem The Bitcoin[1] blockchain holds great promise for distributed ledgers, but the blockchain as a payment](https://static.documents.pub/doc/80x56/5ec46d6f06c97871f958caa3/the-bitcoin-lightning-network-1-the-bitcoin-blockchain-scalability-problem-the-bitcoin1.jpg)
