Desarrollo de plataforma en Ethereum para gestión de competiciones de Machine Learning

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Desarrollo de plataforma en Ethereum para gestión de competiciones de Machine Learning Dpto. Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Autor: Pedro Alberto González Castro Tutor: Juan José Murillo Fuentes José Carlos Aradillas Jaramillo Sevilla, 2022 iii Proyecto Fin de Carrera Ingeniería de Telecomunicación Desarrollo de plataforma en Ethereum para gestión de competiciones de Machine Learning Autor: Pedro Alberto González Castro Tutor: Juan José Murillo Fuentes José Carlos Aradillas Jaramillo Dpto. de Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2022 v Proyecto Fin de Carrera: Desarrollo de plataforma en Ethereum para gestión de competiciones de Machine Learning Autor: Pedro Alberto González Castro Tutor: Juan José Murillo Fuentes José Carlos Aradillas Jaramillo El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2022 El Secretario del Tribunal vii A mi familia A mis maestros ix Agradecimientos Por una parte, quisiera agradecer a mis padres, pareja y amigos por su constante apoyo, comprensión, ánimo y mano izquierda durante todo el tiempo que ha durado este proyecto (que no ha sido poco, precisamente). Por otra parte, agradecer a José Carlos Aradillas todas las aportaciones en forma de consejos, correcciones y comentarios sin los cuales la realización de este trabajo no habría sido posible. Pedro Alberto González Castro Autor del proyecto Sevilla, 2022 FIGURE INDEX Figure 2-1: Physical Wallet 25 Figure 2-2: Hardware Wallet 25 Figure 2-3: Software Wallets Examples – Exodus, MetaMask and ZenGo 25 Figure 2-4: Bitcoin Block Example 26 Figure 2-5: Bitcoin Transaction Example 27 Figure 3-1: Patricia Trie Example Diagram 31 Figure 3-2: Merkle Trie Example Diagram 31 Figure 3-3: Merkle Patricia Trie Example Diagram 32 Figure 3-4: Ethereum Virtual Machine Components Diagram [64] 37 Figure 3-5: Ethereum Virtual Machine Components Interactions Diagram [61] 38 Figure 4-1 Data Science Branches Diagram [87] 43 Figure 4-2: Classical Programming vs Machine Learning Diagram 44 Figure 4-3: Examples of classification approach graphs [96] 45 Figure 4-4: Example of a regression approach graph [96] 45 Figure 4-5: Measures of ML model performance 46 Figure 4-6: Accuracy formula 47 Figure 4-7: Error formula 47 Figure 4-8: Negative Predictive Value formula 47 Figure 4-9: Precision formula 47 Figure 4-10: Recall formula 47 Figure 4-11: Specificity formula 48 Figure 4-12: Kaggle – Contest overview tab 49 Figure 4-13: Kaggle – Contest Data tab 49 Figure 4-14: Kaggle – Contest Leaderboard tab 50 Figure 4-15: Kaggle – Competition detailed description tab 50 Figure 5-1: Authentication Window 53 Figure 5-2: Info prompted in console after authentication 53 Figure 5-3: Main Window: User’s App (left) and Admin’s App (right) 54 Figure 5-4: Main Window: User’s App (left) and Admin’s App (right) 54 Figure 5-5: Only Admin notification message 54 Figure 5-6: Obtained info in User app (left) and in Admin windows (center and right) 55 Figure 5-7: Reverted transaction (notification and transaction scan) 55 Figure 5-8: User menu 56 Figure 5-9: Contest info – Not active (left) and active (right) 56 Figure 5-10: Sending solution – Direct input (left) and through text file (right) 57 Figure 5-11: Waiting for transaction to be mined notification 57 xvii Figure 5-12: Solution has been sent notification 57 Figure 5-13: Printed information in console 57 Figure 5-14: Checking contesters address information 57 Figure 5-15: Bad transaction – Application notification 58 Figure 5-16: Bad transaction – failure reason 58 Figure 5-17: Admin’s App – Main menu 59 Figure 5-18: Contest Info 59 Figure 5-19: Setting contest solution: Direct input (left) and through a text file (right) 60 Figure 5-20: Waiting for transaction to be mined notification 60 Figure 5-21: Transaction mined correctly notification 60 Figure 5-22: Useful information displayed in console 60 Figure 5-23: Info Button 61 Figure 5-24: Calculating winner/s sequence 61 Figure 5-25: Info Button check 62 Figure 5-26: Sending the prize sequence 62 Figure 5-27: Info Button check 63 Figure 5-28: Resetting Contest sequence 63 Figure 5-29: Info button check 64 Figure 5-30: Setting new admin sequence 64 Figure 5-31: Info button check 65 Figure 5-32: Previous info button information 65 Figure 5-33: Bad transaction – Application notification 66 Figure 5-34: Application Structure 66 Figure 5-35: DogsOrCats.sol: variables and constructor 68 Figure 5-36: require condition not met 69 Figure 5-37: Modifier example 69 Figure 5-38: Transaction logs example 69 Figure 5-39: DogsOrCats.sol – Getters and Setters 70 Figure 5-40: DogsOrCats.sol – createContest, calculateWinners and sendPrizeToWinners methods 71 Figure 5-41: DogsOrCats.sol – contest, obtainScore and isFirstAttempt methods 72 Figure 5-42: TextOrImage.sol – obtainScore method 73 Figure 5-43: TextOrImage.sol – minimum and max methods 73 Figure 5-44: Pyhton Files diagram 74 Figure 5-45: TextImageContract.py – Global variables 74 Figure 5-46: TextImageContract.py – Connection to the contract 74 Figure 5-47: TextImageContract.py – Functions that do not need a transaction 75 Figure 5-48: TextImageContract.py – Functions that need a transaction 75 Figure 5-49: TextImageContract.py – Creating a transaction 75 Figure 5-50: TextImageContract.py – Signing a transaction 75 Figure 5-51: DogsOrCatsContract.py file 76 Figure 5-52: Notifications Examples 76 Figure 5-53: Notifications.py – Notification class 77 Figure 5-54: Notifications.py – ErrorNotification class 78 Figure 5-55: Sending notification example 78 Figure 5-56: Setting contests prize and solution 78 Figure 5-57: Checking price and solutions are correct after transaction has been mined 79 Figure 5-58: Price on transaction 79 Figure 5-59: Gas information 79 Figure 5-60: Solution on transaction 79 Figure 5-61: Notification from contract 79 Figure 5-62: Contest status before sending solution 80 Figure 5-63: Checking participant address has been added to the ‘Contesters’ section 80 Figure 5-64: Transaction cost 80 Figure 5-65: Solution in transaction 81 Figure 5-66: Notification from contract 81 Figure 5-67: Checking participants addresses in ‘Contesters’ section 81 Figure 5-68: Checking winners addresses 82 Figure 5-69: Prize transfer to winners 82 Figure 5-70: Average gas price 82 Figure 5-71: Historical ETH Price (€) 83 Figure 5-72: deploy_contract.js file 84 Figure 5-73: truffle-config.js file 84 Figure 5-74: Contracts compilation 84 Figure 5-75: Section of the ABI_JSON of DogsOrCats contract 85 Figure 5-76: Placing contracts in Ropsten Network 85 xix Notation AI Artificial Intelligence BFT Byzantine Fault Tolerance EBL Explanation Based Learning EVM Ethereum Virtual Machine FBA Federated Byzantine Agreement FN False Negative FP False Positive ML Machine Learning MPT Merkle Patricia Trie P2P Peer To Peer PoS Proof of Stake PoW Proof of Work RLP Recursive Length Prefix SSZ Simple Serialize TN True Negative TP True Positive TPS Transactions Per Second 1 INTRODUCTION he rise of Machine Learning in recent decades has caused the number of developers and researchers in this field to increase considerably. Therefore, a wide variety of problems and tasks have appeared that can be solved by applying Artificial Intelligence or Machine Learning models, and for each of these tasks a large number of solutions are proposed over time. Generally, to evaluate the performance of a Machine Learning model, a set of test data that have not been used in any case for the design and training of the model is used. The evaluation of the model on this test data provides essential information for researchers or developers when choosing the best model to implement and deploy in production. When the number of stakeholders interested in solving a problem is large, the number of proposed models grows considerably and the evaluation of the models for benchmarking becomes more complicated. In order to manage the comparison of models as objectively as possible, several competitions have been developed for this purpose. The best known at present are the competitions managed by Kaggle, which is a platform dedicated to solving the above-mentioned problem. In this type of competition, the organizers provide a set of labeled data, i.e., with the solution for the participants to design and train their models. Subsequently, unlabeled data (without the solution) are provided for the participants to find the solution and send it to the organizers. The organizers will then evaluate the solution and publish a ranking of the best models. Some of these contests are free of charge, i.e., participants do not have to pay any kind of fee to participate. The participation consists of submitting the solution of a model, and you can participate as many times as you want. This type of free contests has some disadvantages since there are authors who send a high number of entries adjusting the parameters of the model to obtain a better result in the test set. With the aim of preventing participants from submitting too many solutions of this type, there are more serious contests where each submission has a cost. This makes the organization of a contest of this type more complex because, in addition to managing the evaluation of the models, there is also a monetary management of the models. Normally, this type of non-free contest has a monetary prize for the model or models that achieve the best result. Currently, the monetary management of this type of contests is done through online payments and transfers using the different options that technology offers us, similar to the realization of an online purchase. The objective of this work is to unify both the evaluation of the models and the monetary management of the contests using cryptocurrencies. The system on which cryptocurrencies are based allows us to perform both the computations and the transparent management of payments and collections. For this purpose, an application has been designed and developed in Ethereum in which contestants are charged each time they send a solution, the performance of the solution is computed in the Ethereum system itself and once the contest is finished, the monetary prize is automatically sent to the contestant who has sent the best solution. The rest of the paper is organized as follows: in Chapter 2 there is an introduction to cryptocurrencies and blockchain; in Chapter 3 there is an introduction to Ethereum, which is the cryptocurrency used in the work; in Chapter 4 there is an introduction to Machine Learning; in Chapter 5 the proposed solution and the whole T Introduction 22 22 implementation of the ML contest management system are detailed; and in Chapter 6 the conclusions of the work are shown. 23 2 INTRODUCTION TO CRYPTOCURRENCIES s this work is based on concepts like blockchain, Bitcoin and cryptocurrency, a good starting point can be to briefly describe them. We could say -in a few wordsthat blockchain is the technology that enables the existence of cryptocurrency. Then, a cryptocurrency is a medium of exchange (such as dollar or Euro) but is digital. For example, it uses encryption techniques to control the creation of monetary units and to verify the transfer of funds. Lastly, Bitcoin is the name of the best-known cryptocurrency and the first real-world application of the blockchain technology. 2.1 Blockchain, cryptocurrencies and Ethereum 2.1.1 Cryptocurrency Cryptocurrency is a form of payment that can be exchanged online for goods and services. Many companies have created their own currencies (also known as tokens), and these can be traded specifically for the good/service that the company provides. We can use the analogy of casino coins: you will have to exchange “real” currency for the cryptocurrency in order to access the good/service. Usually, each cryptocurrency has its own blockchain network (blockchain is a database with all the data of the cryptocurrency, see section 2.1.2 for more information). It is not possible to send any amount of X cryptocurrency to an address of a different cryptocurrency. 2.1.1.1 Cryptocurrencies examples Here are some examples of different cryptocurrencies. The key points that differentiate them from each other are mining algorithms (section 2.1.3), the block generation time, the total number of coins, transaction speed, market capitalization, and price. Bitcoin is the world’s first cryptocurrency and the most popular one. Launched in 2009, it was the first real-life use of the blockchain technology. It was created by Satoshi Nakamoto, which is the pseudonym of the person (or people) who developed Bitcoin, authored the white paper and deployed the original implementation. At the time of writing, the price of one Bitcoin is near to 42.000$, and the market capitalization is about 800 billion dollars (more than companies like Toyota or Netflix) [1] [2]. Regarding mining (section 2.1.3), it uses a Proof of Work (PoW) consensus mechanism and the SHA-256 algorithm so, the bigger the network gets, the harder it is for standalone miners to obtain benefits. A Right now, Bitcoin feels like the Internet before the browser. - Wences Casares - Introduction To Cryptocurrencies 24 24 Bitcoin has one of the slowest transaction speeds, with an average of 4-6 transactions per second (TPS) and it takes about 10 minutes to create a new block. One of the biggest problems of this cryptocurrency is scalability. The more users trying to transfer funds, the more congested the network gets; this is causing high periods for transfer confirmation and also high bids for each transaction. Litecoin is an altcoin (“spin-off”) of Bitcoin, launched in 2011. At the time of preparation of this document, it has a market capitalization of 8.6 billion dollars, and one Litecoin costs 125$. The main differences between Litecoin and Bitcoin are [3] [4]: • Time to confirm a transaction: Litecoin processes a block every 2.5 minutes, on average its speed is 56 transactions per second. • Regarding mining (section 2.1.3), Litecoin uses the Scrypt algorithm (instead of SHA-256) in order to allow anyone with an average personal computer to mine and be able to be a standalone. Ethereum was conceived in 2013 by the programmer Vitalik Buterin. Development started in 2014 and it was crowdfunded; the deployment was in 2015. The platform offers to anyone the possibility of creating decentralized applications so the rest of the users can interact with them. Currently, it is the second highest market capitalization cryptocurrency, with a value of 360 billion dollars. The price of one Ethereum is about 3.000$ [5]. Regarding mining (section 2.1.3), Ethereum has recently moved from PoW to Proof of Stake (PoS) in order to avoid the issues with the miners. All participants have a fair chance to get a reward. This cryptocurrency has a higher average of transactions per second than Bitcoin, about 15; it is planned to increase it in the future. Dragonchain was originally developed by The Walt Disney Company in 201, became open-source in 2016 and the beta was released in 2018. As of this writing, it has a market capitalization of 30 million dollars, and the price of one Dragonchain is 0.080$ [6] [7]. It is a cryptocurrency designed for a quick development and deployment of blockchain based applications. It offers different consensus mechanisms to allow users to choose the level of verification needed for their transaction. 2.1.1.2 Wallets Crypto wallets store the public and/or private keys needed for cryptocurrencies transactions, keeping the cryptocurrency safe and accessible (note that wallets do not store the cryptocurrency itself). Sometimes, in addition to this function, a wallet can offer the possibility of signing and/or encrypting information. In most of the cases, the public key allows others to send transactions to the address derived from it, while the private key is for spending the related cryptocurrency. We can divide wallets into two types: physical wallets (to store the keys offline) and software wallets (to store the keys online). 25 Physical wallets Probably the simplest kind of wallet are the paper wallets. It is just a piece of material with the private and public keys printed. They can also have a QR code scannable by an app. As they are not reachable by Internet, they are considered one of the most secure wallets. Figure 2-1: Physical Wallet There are also hardware wallets. They are an encrypted USB containing public and private keys. Some of them allow the use of a two-factor authentication service or sending transactions to a different account. Figure 2-2: Hardware Wallet Software Wallets A software wallet is a computer program or mobile app that holds private and public keys online. There are three main types: Web-based wallets (like MetaMask), Desktop wallets (like Exodus) and Mobile wallets (like blockchain.com wallet) 2.1.2 Blockchain A blockchain is a database, mostly used in a decentralized way. Different types of information can be stored in it, but the most common use so far has been as a ledger for transactions. By the use of this technology, transactions can be confirmed without a need for a central clearing authority (i.e. a bank). It differs from a typical database in the way it stores information. Blockchains store data in blocks that are chained together. Then, as new data comes in it, is saved into a fresh block. Once the block is filled with data it is chained onto the previous block, which makes the data chained together in chronological order. This system also inherently makes an irreversible timeline of data. When a block is filled it is set in stone and becomes a part of this timeline [8]. 2.1.2.1 Decentralization As with any database, computers are necessary to store and process the blockchain information. Taking as example the case of Bitcoin that stores every Bitcoin transaction ever made (uses its blockchain as a ledger), Figure 2-3: Software Wallets Examples – Exodus, MetaMask and ZenGo Ethereum 32 32 3.2.3 Merkle Patricia Tries The ‘Merkle side’ of the Merkle Patricia Trie (MPT) is that the key of each node is a hash of the value. To be more precise, the ‘keccak256’ function is being used to hash, while the value itself is prior serialized with Recursive Length Prefix (RLP) [30] serialization currently (it is going to be replaced with Simple Serialize (SSZ) [31] after The Merge). Patricia tries have one important limitation: they are not efficient. To store just one (key, value) binding where the path is 64 characters long (number of nibbles produced by keccak256 function), around one kilobyte of space to store one level per character would be needed, and each deletion or lookup will take the full 64 steps. To improve its efficiency, some kind of nodes have been created. With 64-character paths, after traversing the first nodes, a node where no divergent path exists will be reached (at least for part of the way down). There are 4 types of nodes (encodedPath contains the partial path to skip): • Null: Represented as the empty string • Branch: A 17-item node [i0 ... i15, value] • Leaf: A 2-item node [encodedPath, value]. Their usage is to store the rest of the path and the value. • Extension: A 2-item node [encodedPath, key]. Their usage is to store the rest of the path and the key to point to the next branch. To differentiate Leaf and Extention nodes and to indicate if the remaining partial path is even or odd, the first nibble will be used as a flag: • 0: Extension node, even partial path (a padding ‘0’ will be added). • 1: Extension node, odd partial path. • 2: Leaf node, even partial path (a padding ‘0’ will be added). • 3: Leaf node, odd partial path. For better understanding, we can use a simplified example. We observe a MPT containing the next (key:values): (‘do’:‘Verb’), (‘dog’:‘Puppy’), (‘doge’:‘Coin’) and (‘horse’:‘Stallion’). For an easier comprehension, values will be represented as strings (keys are represented in bytes): Figure 3-3: Merkle Patricia Trie Example Diagram Please note that values would be stored with RLP or SSZ serialization and that we are not able to choose the key of those values, they would be the ‘keccak256’ hash of their own value. Ethereum uses four Merkle Patricia Tries, three of them are stored (the root hash) on the blocks: • State Trie: For storing account-related information. There is one global state trie, and it updates over time. The key is ‘keccack256’ hash of the Ethereum address, and the value is the elements of 33 an Ethereum account (nonce, balance, codeHash, storageRoot) serialized with RLP or SSZ. Note that storageRoot is the root hash of another MPT, the Storage Trie. o Storage Trie: Where Smart Contracts data lives (its variables and their content). • Transactions Trie: There is a separate transactions trie for every block, storing (key, value) pairs. The key is the RLP serialization of the transactionIndex, where the transaction sits in the block (The order of the transactions in a block is decided by the miner who assembles the block). Mined blocks are never updated; the position of the transaction in a block is never changed. • Receipts Trie: Similar to the transactions trie; there is a separate receipts trie for every block. The key is the same as transactions trie (the serialization of the transaction index) and the value would be the content of the receipt. All transactions generate receipts (any interaction with the blockchain that modifies its content will generate one). The receipt will provide information such as the amount of consumed gas, the gas price, logs (they can be generated by a Smart Contract) or the transaction status (failure, successful). 3.3 Accounts An Ethereum account is an entity with an ether (ETH) balance that can send transactions on Ethereum. There are two types of accounts: • Externally owned: They are controlled by anyone with the private keys. • Contract: The associated account of a Smart Contract. It is controlled by the code of the Smart Contract. Both account types can manage ETH (receive, send and hold) and interact with Smart Contracts. The creation of an account is costless, but here a nuance should be clarified; in case of contract account a payment is required to develop the contract (as it requires computation and storage of the EVM), but not for the contract account itself [32] [33] [34] [35]. 3.3.1 Elements Each Ethereum account has four elements: • Nonce: A counter that indicates the number of transactions sent from the account. The purpose of this field is to assure that transactions are only processed once. The value of this field will only increase when a transaction is processed (if someone tries to send two transactions with the same nonce, the first one will be the processed one). In a contract account, this number represents the number of contracts created by the account. • Balance: The amount of ETH owned by the address. It is stored in Wei, the smallest denomination of ETH (there are 1e+18 Wei per ETH). • CodeHash: This field is for contract accounts (this hash identifies the code of an account on the EVM). Contract accounts have code fragments that can perform different operations. It cannot be changed unlike the other account fields. All such code fragments are contained in the state database under their corresponding hashes (codeHash) for later retrieval. For externally owned accounts, the codeHash field is the hash of an empty string. • StorageRoot: Also known as storage hash. A 256-bit hash of the root node of a Merkle Patricia trie that encodes the storage contents of the account. 3.4 Transactions We could say that transferring ETH from one account to another is the simplest transaction, but in general a transaction is a cryptographically signed instruction from an account. This instruction will update the state of the Ethereum network [36] [37] [38] [39]. Ethereum 34 34 3.4.1 Caveat: Gas The concepts of transactions, blocks and gas are closely related. There is a later section (section 3.6) for gas, hence here are some key concepts for the better understanding of transactions and block sections: • Gas if for paying transaction fees. • Units of gas represent computational steps. Each transaction requires computational effort. • Gas fees are payed in ETH but, as they are “small” amounts of ETH, there are two main denominations used: o GWei: 1 GWei is equal to 10-9 ETH. o Wei: 1 Wei is equal to 10-18 ETH. 3.4.2 Elements A submitted transaction includes the following information: • Recipient: The receiving address. If it is an externally owned account, the transaction will transfer a certain amount of ETH. If it is a contract account, the transaction will execute the contract code (but it can also transfer ETH to the contract address). • Signature: The identifier of the sender. This is generated when the sender's private key signs the transaction and confirms the sender has authorised this transaction. • Value: Amount of ETH to transfer from sender to recipient (in Wei). • Data: Optional field to include arbitrary data (for example, a Smart Contract reply with previously requested information). • Gas Limit: The maximum amount of gas units that can be consumed by the transaction. • Maximum Fee per Gas: The maximum amount of gas willing to be paid for the transaction. • Max Priority Fee per Gas: the maximum amount of gas to be included as a tip to the miner. 3.5 Blocks Blocks are groups of transactions with a hash of the previous block. This links blocks together in an ordered way, like a chain. There are two main reasons on why it was decided this specific usage of blocks [40] [41] [42]: - Fraud prevention: As hashes are -cryptographically- derived from the block content, one change in any block in history would invalidate all the following blocks. The rest of the subsequent hashes would be modified too and everyone running the blockchain would notice. - Synchronization: Transaction requests occur dozens of times per seconds. If a new commit to the chain was required for every -valid- transaction, it would be almost impossible to spread the new EVM state on the rest of the nodes before a new valid transaction is committed. Blocks are meant to be generated every 15 seconds (approximately), providing enough time for the status synchronization all over the Ethereum net. 3.5.1 Elements • Timestamp: The time when the block was mined. • BlockNumber: The length of the blockchain in blocks. • BaseFeePerGas: The minimum fee per gas required for a transaction to be included in the block. • Difficulty: The effort required to mine the block. The expected block time is set as a constant and is used to protect the network's security when the miners add more computational power. The 35 average block time gets compared with the expected block time, and if the average block time is higher, then the difficulty is decreased in the block header. If the average block time is smaller, then the difficulty in the block header will be increased • MixHash: A unique identifier for that block. • ParentHash: The unique identifier for the block that came before (this is how blocks are linked in a chain). • Transactions: The transactions included in the block. • StateRoot: The entire state of the system: account balances, contract storage, contract code and account nonces are inside. • TransactionsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block. • ReceiptsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block • Nonce: A hash that, when combined with the mixHash, proves that the block has gone through proof of work. 3.5.2 Block Size An important note is that blocks are bounded in size. This is because it ensures that blocks can’t be arbitrarily large. If blocks could be arbitrarily large, then less performant full nodes would gradually stop being able to keep up with the network due to space and speed requirements. Each block has a target size of 15 million gas, but the size of blocks will increase or decrease depending on network demands. The upper limit is the double of the target size (30 milion gas). The total amount of gas expended by all transactions in the block must be less than the block gas limit. Please note that block size is measured in gas instead of transactions because not all transactions need the same computational effort. A transaction can range from a "simple" transfer of money from one account to another to a heavy execution of a Smart Contract. 3.6 Gas Gas refers to the unit that measures the amount of computational effort required to execute specific operations on the Ethereum network. Since each Ethereum transaction requires computational resources to execute, each transaction requires a fee. Gas refers to the fee required to successfully conduct a transaction on Ethereum [43] [44] [45]. Gas fees are paid in Ethereum's native currency, ether (ETH). Gas prices are denoted in GWei, which itself is a denomination of ETH - each GWei is equal to 10-9 ETH. For example, instead of saying that your gas costs 0.000000001 ether, you can say your gas costs 1 gwei. The word 'GWei' itself means 'giga-wei', and it is equal to 1,000,000,000 Wei (wei is the smallest unit of ETH, 1 Wei = 10-18 ETH). Every block has a base fee, the minimum price per unit of gas for inclusion in this block, calculated by the network based on demand for block space. As the base fee of the transaction fee is burnt, users are also expected to set a tip (priority fee) in their transactions (this is usually automatically done by wallets). The tip compensates miners for executing and propagating user transactions in blocks. To calculate the total fee on a transaction: Gas units (limit) * (Base fee + Tip). We can see it better with an example: A is going to pay B 1 ETH. The gas limit is 21,000 units, the base fee is 100 GWei and A includes a tip of 10 GWei. We can calculate this as 21,000 * (100 + 10) = 2,310,000 GWei or 0.00231 ETH. When A sends the money, 1.00231 ETH will be deducted from A’s account; B will receive 1 ETH and the miner receives the tip of 0.00021 ETH. Base fee of 0.0021 ETH is burned. Ethereum 36 36 3.7 Ethereum Virtual Machine The analogy of a 'distributed ledger' is usually used to describe blockchains like Bitcoin, which enable a decentralised currency using fundamental tools of cryptography. A cryptocurrency behaves like a 'normal' currency because of the rules which govern what one can and cannot do to modify the ledger (like, for example, a Bitcoin address cannot spend more Bitcoin than it has previously received). These rules are under all transactions on Bitcoin and many other similar blockchains [46] [47] [48] [49]. Ethereum has Ether -its own cryptocurrencyso almost the same rules are applied on transactions in Ethereum blockchain. However, Ethereum has another powerful feature, Smart Contracts. Therefore, the proper analogy to describe Ethereum’s blockchain would be a ‘distributed state machine’. 3.7.1 EVM Properties 3.7.1.1 Determinism A program is deterministic when it provides the same output to the same set of inputs. It doesn’t matter how many times the code is executed. This is important because decentralised apps or dApps on Ethereum may handle financial transactions involving large amounts of money at any given time. Therefore, it is crucial to know how the code will react in every stage of execution. Determinism is essential to the foundations of the Ethereum Virtual Machine. 3.7.1.2 Terminability EVM is Turing-complete (its smart contracts should be able to solve any computational problem). But there is no way to tell whether such smart contracts can finish all the given operations within a specific time frame. Therefore, it is essential to put in a terminating mechanism to create exact limits. In Ethereum, the concept of “gas” is used to facilitate traffic. Gas limits are set at the beginning. When these limits are used up, the machine simply stops operations or halts its processing. 3.7.1.3 Isolation Isolation is important so that the system can contain hacks or bugs within a smart contract. The bug will not spread to the whole computer (the code running on it has no access to other processes on the computer where the EVM node is running). The feature is in place so that such issues or incidents do not affect the underlying protocol. 37 3.7.2 Elements of the EVM Figure 3-4: Ethereum Virtual Machine Components Diagram [64] • EVM Code: The instructions/operations of the Smart Contracts. Ethereum provides high level programming languages (Solidity, Vyper) to facilitate the creation of Smart Contracts. Then, the code is transformed into Operation Codes (OP_CODES) and finally into bytecode (which is executed by the EVM when an account makes a message call to the contract). Regarding the Operation Codes, there are currently 140 which allows the Turing-completeness. For example, there are usual stack operations (XOR, AND, ADD, SUB), and blockchain specific operations (ADDRESS, BALANCE, KECCAK256, BLOCKHASH). o Complete list of OPCODES: https://www.ethervm.io/#opcodes • Account Storage: It is located inside each account and stores the contract state variables. Storage is assigned during the process of creating a contract. You can only modify the content of those variables with a transaction. • Memory: It holds temporary variables. As they only exist in the calling function, memory gets erased between calls. You can address memory at byte level. However, the limit of one reading is 256 bits, and writes can be of 8 or 256 bits in width. You need to pay in gas to expand memory. It scales quadratically, and the more it grows, the more it costs. • Stack: Ethereum virtual machine specification defines it as a stack machine. The stack is where the computations happen. This can include Smarts Contracts, Ethereum nodes, client APIs and endusers applications. • Available Gas: When a transaction is requested, a gas limit is set. Gas is going to be spent in each computational operation. If, eventually, there is no more gas, the rest of the operations will be cancelled. • Program Counter: The register that contains the location of the instruction that is being executed. When the instruction is executed, it will point to the next instruction. Ethereum 38 38 Figure 3-5: Ethereum Virtual Machine Components Interactions Diagram [61] 3.8 Nodes and Clients "Node" refers to a running piece of client software. The client is a piece of software capable of establishing a p2p communication channel with other clients, signing and broadcasting transactions, mining, deploying and interacting with smart contracts [50] [51] [52] [53] [54]. There are three different types of nodes - light, full and archive. There are also options of different sync strategies which enables faster synchronisation time (Synchronisation refers to how quickly it can get the most up-to-date information on Ethereum's state). The formal definition of the functionality an Ethereum node must follow is defined in the ethereum yellow paper. The yellow paper defines the required functions of nodes on the network, the mining algorithm, private/public key ECDSA parameters. It defines the entirety of features which make nodes fully compatible Ethereum clients. Many Ethereum clients exist, in a variety of programming languages such as Go, Rust, JavaScript, Python, C# .NET and Java. 3.8.1 Full Node Full nodes store full blockchain data. They participate in block validation, verifying blocks that are broadcasted onto the network. That is, they ensure that the transactions contained in the blocks (and the blocks themselves) follow the rules defined in the Ethereum specifications. They maintain the current state of the network (as defined according to the Ethereum specifications). For example, if A tries to send 100 Ether to B but A has 0 ethers and a block includes this transaction, the full nodes will realise this does not follow the rules of Ethereum and reject that block as invalid. All states can be derived from a full node (except very old ones, that are requested to archive nodes). They serve the network and provide data on request (mostly to light nodes). 3.8.2 Light node They only store the header chain (not the whole blockchain) and request what they need to Full or Archive nodes. That means they can verify the validity of the data against the state roots in the block headers, but they do not participate in the consensus (they can not be miners nor validators). 39 Light nodes are useful for low-capacity devices, such as embedded devices or mobile phones, which can't afford to store gigabytes of blockchain data. 3.8.3 Archive node Archive nodes store everything kept in the full node and build an archive of historical states. They are needed when querying an account balance at block #4,000,000. They can also be useful to reliably test your own transactions set without mining them using OpenEthereum. These data represent units of terabytes which makes archive nodes less attractive for average users but can be handy for services such as block explorers, wallet vendors, and chain analytics. Syncing clients in any mode other than archive will result in pruned blockchain data. This means, there is no archive of all historical states, but the full node can build them on demand. 3.9 Network Networks are different Ethereum environments you can access for development, testing, or production use cases. They do not interact with each other [55] [56] [57]. 3.9.1 Public Networks Public networks are accessible to anyone in the world with an internet connection. Anyone can read or create transactions on a public blockchain and validate the transactions being executed. 3.9.1.1 Mainnet Mainnet is the primary public Ethereum production blockchain, where actual-value transactions occur on the distributed ledger. For example, when people and exchanges discuss ETH prices, they're talking about Mainnet ETH. 3.9.1.2 Testnets In addition to Mainnet, there are public testnets. These are networks used by protocol developers or smart contract developers to test both protocol upgrades as well as potential smart contracts in a production-like environment before deployment to Mainnet. Most testnets use a Proof of Authority consensus mechanism. This means a small number of nodes are chosen to validate transactions and create new blocks – staking their identity in the process. It is hard to incentivise mining on a Proof of Work testnet which can leave it vulnerable. • Görli: A Proof of Authority testnet that works across clients. • Kovan: A Proof of Authority testnet for those running OpenEthereum clients. • Rinkeby: A Proof of Authority testnet for those running Geth client. It is deprecated as of today. • Ropsten: A Proof of Work testnet. This means it's the best like-for-like representation of Ethereum. Traditionally has been the “main” testnet; it seems that it will be deprecated during summer 2023, as The Merge will be completed. Regarding Proof of Stake testnets there are a few (Pyrmont, Prater) but, as of today, you can only register as Staker. There is nothing open for testing Smart Contracts. Ethereum 40 40 3.10 Consensus Mechanism Consensus mechanisms are protocols to make sure the blockchain nodes are synchronized and agree on which transactions are legitimate. A transaction is added to the blockchain only after it has been validated, which ensures it is the only version of the truth [58] [59] [60] [61] [62] [63] [64]. For Ethereum there are two consensus protocols that are worth understanding: Proof of Work (the current one) and Proof of Stake (the protocol Ethereum is moving to). 3.10.1 Proof of Work Protocol The Proof of Work protocol -Ethash, for Ethereum specificallyrequires miners to go through a race of trial and error to find the nonce for a block, as introduced in section 2.1.3. A miner will repeatedly put a dataset (the block header and the transactions included in it) through a mathematical function to obtain its hash. The key aspect is that not all hashes are valid, they must be under a certain threshold so the block is mined; the higher the block difficulty, the more restrictive the set of valid hashes. The only parameter that the miner is able to change on a block (for a specific set of transactions) is the nonce; it will have to find a nonce that provokes a valid hash. The objective of PoW is to extend the chain; the longest chain is most believable as the valid one because it has the most computational work done. It is almost impossible to create new blocks that erase transactions, create fake ones, or maintain a second chain, a malicious miner would need to always solve the block nonce faster than everyone else. To consistently create malicious yet valid blocks, over 51% of the network mining power would be required to beat everyone else. A major criticism of PoW is the amount of energy required to keep the network safe. To maintain security and decentralization, Ethereum on Proof of Work consumes an average of 73.2 TWh annually, (the energy equivalent of a country like Austria). 3.10.2 Proof of Stake Protocol In Proof of Stake, validators explicitly stake capital in the form of ether into a smart contract on Ethereum. The validator is responsible for checking that new blocks propagated over the network are valid and occasionally creating and propagating new blocks themselves. This staked ether then acts as collateral that can be destroyed if the validator behaves dishonestly or lazily. To become a validator, a user must deposit 32 ETH into the deposit contract and run three separate pieces of software: an execution client, a consensus client, and a validator. Validators receive new blocks from peers on the Ethereum network, and the validator has to re-execute all of its transactions to check them. The validator then sends a vote in favour of that block across the network. Whereas under PoW the timing of blocks is determined by the mining difficulty, in PoS the tempo is fixed. Time in Proof of Stake Ethereum is divided into slots (12 seconds) and epochs (32 slots). One validator is randomly selected to be a block proposer in every slot. This validator is responsible for creating a new block and sending it out to other nodes on the network. Also in every slot, a committee of validators is randomly chosen, whose votes are used to determine the validity of the block being proposed. 3.11 Token Standards Ethereum tokens are digital assets that can be built on top of the Ethereum blockchain. They can be -potentially- anything: skills of a character in a game, a new cryptocurrency, reputation points in an online platform, lottery tickets or some collectible item. You can see a full list of them on https://etherscan.io/tokens [65] [66] [67] [68]. There is a symbiotic relationship between Ethereum and its tokens: tokens benefit from Ethereum’s existing infrastructure instead having to build an entirely new blockchain. Ethereum’s benefit is that tokens strengthen the ecosystem by driving demand for ETH, needed to power the smart contracts. 41 Depending on the token’s nature, there are different standards. 3.11.1 ERC-20: Fungible Tokens Fungible tokens they have a property that makes each token be the same in type and value as another token. Some examples can be currencies or reputation points. ERC-20 was proposed by developer Fabin Vogelstellar in 2015 as a way to standardize the tokens within smart contracts on the Ethereum blockchain. It contains several functions and events that a token must implement: • TotalSupply: The total number of tokens that will ever be issued • BalanceOf: The account balance of a token owner's account • Transfer: Automatically executes transfers of a specified number of tokens to a specified address for transactions using the token • TransferFrom: Automatically executes transfers of a specified number of tokens from a specified address using the token • Approve: Allows a spender to withdraw a set number of tokens from a specified account, up to a specific amount • Allowance: Returns a set number of tokens from a spender to the owner • Transfer: An event triggered when a transfer is successful (an event) • Approval: A log of an approved event (an event) 3.11.2 ERC-721: Non-Fungible Tokens Non-fungible tokens are used to identify something or someone in a unique way. They can only have one official owner at a time and they are secured by the Ethereum blockchain; the record of ownership can not be modified or or copy/paste a new NFT into existence. These tokens are not interchangeable for other tokens because they have unique properties. The ERC-721 introduces a standard for NFT, all NFTs have a ‘uint256’ variable called ‘tokenId’. For any ERC- 721 Contract, the pair ‘contract address’, ‘uint256 tokenId’ must be globally unique. Machine Learning 48 48 4.3.5 Specificity Percentage of negative instances out of the total actual negative instances: Figure 4-11: Specificity formula It is similar to recall, but the focus is on the negative instances (‘how many extra negative ones missed the model when it showed the negative ones’). If the score is near 1 will mean that the model did not miss any true negative and it is able to classify well between correctly and incorrectly labelling. The difference with the recall metric is when a low score (<0.5) is obtained. It would mean that the model has a high number of false positives. 4.4 Machine Learning competitions Machine Learning competitions have become very popular. Participating in machine learning competitions (whether as a beginner or as an advanced practitioner) can provide interesting benefits. One of the main reasons for their popularity is allowing people to practise what they have learnt; outside formal education or work experience it is complicated. They can also be used for building a portfolio to expose your skills and, of course, to earn money in case of winning a prize. There are several sites that host machine learning competitions and most of them follow the same structure. Usually, they provide a wide variety of competitions ranging in skill level, including problems for practising (non-rewarded) and rewarded competitions problems. Normally, the competitions consist of a statement to resolve, and they provide a dataset. The majority of them allow unlimited entries which means that it is possible to keep refining the model and improving the score. 4.4.1 Kaggle Kaggle is probably the most widely known machine learning competition website. The types of data science problems posted on Kaggle can be anything from attempting to predict cancer occurrence by examining patient records to analysing sentiment to evoke by movie reviews and how this affects audience reaction [100]. The host of the competition is responsible for preparing the data and a detailed description of the problem. The participants submit their models and all the work is shared on the platform with the intention of inspiring new ideas to achieve better benchmarks. Before the deadline expires, the competitors are allowed to make revisions on their submissions as they deem fit (allowing for revisions elevates the level of accuracy and precision). When the deadline for a competition expires, the host pays the prize money to the winner. Hosts have the sole ownership and royalty-free license to use the winning entry with all intellectual property [100]. Lets see an example of a real competition - ‘Toxic Comment Classification Challenge’: https://www.kaggle.com/c/jigsaw-toxic-comment-classification-challenge In the Overview tab we can see the total amount of prizes offered, a detailed description of the issue to resolve and the timeline (when was it launched, the acceptance deadline and the closure): 49 Figure 4-12: Kaggle – Contest overview tab In the Data tab we can read a brief description of the objective and of the necessary files: Figure 4-13: Kaggle – Contest Data tab Machine Learning 50 50 In the Leaderboard tab appears all the participants ordered by score: Figure 4-14: Kaggle – Contest Leaderboard tab Lastly, in the Rules tab we can see a detailed description of the competitions terms, acceptance criteria, prizes and legal basis: Figure 4-15: Kaggle – Competition detailed description tab 51 4.4.1.1 Types of Kaggle competitions Kaggle Competitions are designed to provide challenges for competitors at all different stages of their machine learning careers. As a result, they are very diverse, with a range of broad types [101]. 4.4.1.1.1 Getting Started Getting Started competitions are the easiest, most approachable competitions on Kaggle. These are semipermanent competitions that are meant to be used by new users just getting their foot in the door in the field of machine learning. They offer no prizes or points. Once a submission is more than two months old, it will be invalidated and no longer count towards the leaderboard. This gives new Kagglers the opportunity to see how their scores stack up against a cohort of competitors rather than many tens of thousands of users. Some examples of this contests are: • Digit Recognizer: The goal is to correctly identify digits from a dataset of tens of thousands of handwritten images. • Titanic: The objective is to use machine learning to create a model that predicts which passengers survived the Titanic shipwreck. 4.4.1.1.2 Playground Playground competitions are a “for fun” type of competition. They are similar to the ‘Getting Started’ ones but with one step above in difficulty and some of them can have a small cash prize. These are competitions which often provide relatively simple machine learning tasks and are similarly targeted at newcomers. Some examples are: • Dogs versus Cats: Create an algorithm to distinguish dogs from cats. • New York taxi trip duration: Share code and data to improve ride time predictions. 4.4.1.1.3 Featured These are the competitions that Kaggle is probably best known for. These are full-scale machine learning challenges which pose difficult, generally commercially-purposed prediction problems. For example, the offer prize pools are currently going as high as a million dollars. Some examples of these kind of competition: • Allstate Claim Prediction Challenge: Use customers’ shopping history to predict which insurance policy they have purchased. • Jigsaw Toxic Comment Classification Challenge: Predict the existence and type of toxic comments on Wikipedia 4.4.1.1.4 Research Research competitions feature problems which are more experimental than featured competition problems. Due to their experimental nature, these competitions do not usually offer prizes or points. However, they offer an opportunity to work on problems which may not have a clean or easy solution and which are integral to a specific domain or area in a slightly less competitive environment. Some examples of research competitions are: • Large Scale Hierarchical Text Classification: Classify Wikipedia documents into one of ~300,000 categories • Google Landmark Retrieval Challenge: Given an image, the objective is to find all the same landmarks in a dataset. Project Description 52 52 5 PROJECT DESCRIPTION he current procedure on most of the Machine Learning competitions is: Participants upload their results to the competition’s site and those results are internally reviewed. Ethereum’s Smart Contracts could play a useful role to make transparent the review of the results. Ethereum transactions will remain registered and any person can check them; Smarts Contracts are public and they can automate when and how to review the results of the participants. 5.1 Project objective/goal The objective of this project is to test if Smart Contracts can be a good alternative for the reviewing process on Machine Learning contests. This would imply the next benefits and drawbacks: - On the user side: o Full transparency o Sureness on receiving the prize. o Fees should be payed for sending results - On the administrator’s side: o It would allow them to manage the contest without maintaining a -potentially powerfulserver for the storage and review of the results. o Fees should be payed for storing results and for the computational cost of the reviewing. The administrator would be in charge of creating (defining solution and prize) and closing (calculate a winner and sending the prize) the contests, and the user would only need to send their results. To test this, we have thought in a Proof of Concept. We have developed an Ethereum Dapp that allows us to manage two mock Machine Learning contests as administrators and to participate in them as contesters. The first of them is Text from Image, where the contesters will receive an image and the objective is to obtain the text as accurate as possible. The second contest is Dog or Cat, where the contesters will receive a set of cats and dogs images and they will have to determine if the image contains a cat or a dog (on each image). In order to guarantee the proper functioning, contests will have to follow these steps: T The thing that I often ask startups on top of Ethereum is, 'Can you please tell me why using the Ethereum blockchain is better than using Excel?' And if they can come up with a good answer, that's when you know you've got something really interesting. - Vitalik Buterin - - El autor de la cita - 53 1. Creation → Setting the solution and the prize and marking the contest as active. 2. User participation → During a certain amount of time, users will be allowed to send their results. We have decided that the Admin will end the period manually, but it would have been possible to use a different criteria (like finishing on a specific date, or when there are a chosen number of contesters) 3. Winner/s calculation → That implies no more user participation. There is also the ability of expelling a winner in exceptional cases (f.e. fraud) 4. Sending prize to winner/s → Due to the nature of these contests -the winner is the contester with the biggest score, if there is more than one winner is because they obtained the same score-, the prize will be equally divided among the winners. 5. Reset/Delete contest → It will delete all stored information and mark the contest as inactive. These phases need to be in that order. That means that, for example, it is not allowed to reset a contest before sending the prize to the winner/s, nor user participation after the winner/s calculation. The own Smart Contract will check all cases and will reject improper transactions. 5.2 Tutorial/Explanation of the App 5.2.1 Application download and Start-Up The app is stored in this github repository: https://github.com/pedgc/challenge You will only need to clone the repository and then execute (with python3) the file: • ChallengeApp.py → If you are an user • ChallengeAppAdmin.py → If you are the administrator of the contests Example of the commands for a Linux environment: git clone [email protected]m:pedgc/challenge.git cd challenge/Main python3 ChallengeApp.py Then, the App will request the secret key of your account and you will be able to use it: Figure 5-1: Authentication Window As soon as you provide your private key, you will be able to see in the terminal useful information like the Web3 and Client versions used, and a link to your ethereum account: Figure 5-2: Info prompted in console after authentication Project Description 54 54 Also, a window will pop-up. Depending on if you decided to open the user or de admin app, you will see something like this: 5.2.1.1 Actions that consume gas Like with any other Smart Contract, all actions that modify the status of the Contract will require a gas fee. In this case, the only action that requires no gas is Info - that will provide the current status of the contest - for both Apps, User and Admin. Gas-consuming actions: • User App o Send Result • Admin App o Set Contest o Reset Contest o Calculate Winner/s o Send Prize o Expel Winner o Set New Admin 5.2.1.2 Security Note A hacker mind could think of taking advantage of the possibility of using the Admin App to see the solution or to modify something in the contest. This is not possible unless the hacker has the private key of the administrator’s account; this Smart Contract checks (in sensitive functions) that the requester’s address is the admin address. If, for example, the hacker tries to see the solution by clicking the Info button, an error message will appear: Figure 5-5: Only Admin notification message Figure 5-4: Main Window: User’s App (left) and Admin’s App (right) Figure 5-3: Main Window: User’s App (left) and Admin’s App (right) 55 It would not obtain more info than using the User App: Figure 5-6: Obtained info in User app (left) and in Admin windows (center and right) Something similar would happen if the hacker tries to modify something in the contract: https://ropsten.etherscan.io/tx/0x8d738cc94546da0b21a2df1f09f4ad98508720e39a2385499de083ac78cb3 f13 5.2.2 Application Usage 5.2.2.1 As a User – Participating in contests This is the menu of the User App. It allows the user to fully participate in both contests (Text from Image and Dog or Cat): Figure 5-7: Reverted transaction (notification and transaction scan) Project Description 56 56 Figure 5-8: User menu See contest Info To see the current status of the contest, the user just needs to click on the Info button and relevant contest information (like if the contest is active, the prize, how many contesters are etc.) will be displayed. Send Result To send the solution, the user has to click on the Send Result button and then, there are two options: • To directly write the solution in the box • To import a txt file (the whole content of the file will be considered as the result) Figure 5-9: Contest info – Not active (left) and active (right) 57 Once the solution is sent, you will receive a notification saying that the transaction needs to be mined: Figure 5-11: Waiting for transaction to be mined notification And once the transaction is mined, you will receive a notification saying that your solution is stored in the Smart Contract: Figure 5-12: Solution has been sent notification https://ropsten.etherscan.io/tx/0x30ec940260676579d20be979e9c01dbe1cb9c34c7fb091f50e974dd61f6cc cf2 In the console we have useful information like the Gas Price that we are using, how long is it taking to mine the transaction and a link to the transaction itself. Figure 5-13: Printed information in console Finally, we can check that our public address has been included into contesters: Figure 5-14: Checking contesters address information 5.2.2.1.1 Bad transaction case example Here is an example of a bad transaction: Somebody has tried to participate after the winners have been selected. Once the transaction is mined, the application would prompt a notification: Figure 5-10: Sending solution – Direct input (left) and through text file (right) Project Description 64 64 Figure 5-29: Info button check Setting New Admin To set a new administrator of a contest, the admin must click on Set New Admin button. It is similar as setting the contest, calculating winners or sending the prize: Figure 5-30: Setting new admin sequence https://ropsten.etherscan.io/tx/0xc8f144ed402f3a56336cfadc0ff9a2050d2ccb96d20a4d5b5bf47ac1e4889f fe 65 By clicking on Info button we can check that everything is ok: Figure 5-31: Info button check Remember that initially we had: Figure 5-32: Previous info button information 5.2.2.2.1 Bad case example Here is an example of a bad transaction on the admin’s side: he tried to send the prize without having elected the winners. Once the transaction is mined, the application would prompt a notification: Project Description 66 66 Figure 5-33: Bad transaction – Application notification To see more details, the user can inspect the provided URL: https://ropsten.etherscan.io/tx/0x83a530c020cc4766cdf8cade549b54af2fdf359e97fbd1bc644cd9decf70bb 89 5.3 Project Design and Programming 5.3.1 Project Architecture/Design We can divide the application structure in two different sides, local (Python) and remote (Smart Contract, Solidity). Figure 5-34: Application Structure 67 5.3.1.1 Local side It is the Python code. Its purpose is to offer a graphical user interface to interact with the Smart Contract. It uses two main libraries: • Web3.py: Library for interacting with Ethereum (sending transactions, interacting with smart contracts, reading block data, and a variety of other use cases). Here is the link for its documentation: https://web3py.readthedocs.io/en/stable/ • Tkinter: Library for the design and generation of the graphical user interface (different windows, buttons etc.). Here is the link for its documentation: https://docs.python.org/3/library/tkinter.html#module-tkinter 5.3.1.2 Remote side It is the Ethereum Smart Contract. It contains both contests (Text From Image and Dog or Cat) and it is deployed in Ropsten, one of the test nets for Ethereum blockchain. 5.3.2 File Structure 5.3.2.1 Solidity Files Solidity files are for defining Smart Contracts. This language is similar to Java, contracts are like classes. They both can have constructors, private and public methods, global and local variables, and can be instantiated. However, Solidity contracts also have public addresses in the blockchain (after being deployed) and can store and send value. There is also a special variable, msg. It contains properties which allow access to the blockchain’s contracts, their functions, and their values. For example, msg.sender is always the address where a current function call came from, and msg.value is the amount of Ethereum sent in the transaction. I have developed two Solidity files on this Ethereum Dapp: DogsOrCats.sol and TextImage.sol. Both of them follow a similar structure: 1. Global variables & constructor are defined 2. OnlyAdmin modifier and Notification event are defined 3. Public Getters & Setters are defined 4. Functions used by the Administrator of the contract 5. Functions used by contesters Project Description 68 68 5.3.2.1.1 DogsOrCats.sol This file is for defining the Dogs or Cats Smart Contract. If we have a look at the first part of the file: Figure 5-35: DogsOrCats.sol: variables and constructor The first line (pragma solidity) is to specify the valid version/s of the compiler. Solidity is a new language and it is continuously being improved. Whenever a new feature or improvement is introduced, it comes out with a new version. Then we have the variables and the constructor. The constructor is executed just once, during the deployment of the contract. We have used it for initialising some variables like the admin’s address (with msg.sender in the constructor we set that the admin’s address is the address that deploys the contract) or the name of the contract. Regarding variables there are two aspects that are peculiar to this language. One is the payable modifier, which is required for addresses that are likely to receive money from the contract. The other aspect is the mapping kind of variable that associates two kinds of variables. For example, we use the users variable for storing all contesters and their scores. Before describing the purpose of the onlyAdmin modifier, it is needed to explain the use of the require method. Sometimes you need a function to be executed only under specific conditions; require will check if a condition is true and will allow code to flow only if the condition is true. If the condition is false, require will throw an error, the rest of the code will not be executed, and the transaction will revert. This will keep gas costs to a minimum (the rest of the function will not be executed) and the user will be able to receive a message with the cause of the error (in this case the message is ‘Only admin can call this function’). Please note that this message will be stored in the transaction summary. Here is one example, https://ropsten.etherscan.io/tx/0x8d738cc94546da0b21a2df1f09f4ad98508720e39a2385499de083ac78cb3 f13 : 69 Figure 5-36: require condition not met If we detect that we have a certain condition/s that we want to check in many functions, we can create a modifier to make the code shorter. These two functions are equivalent: Figure 5-37: Modifier example Events are for storing the arguments passed in the transaction or, in other words, for logging. This information is usually helpful for the user that initiated the transaction. The Notification event will store a string and the address of the user. Here is an example, https://ropsten.etherscan.io/tx/0x64f0b9d70b94888fb4dd3e0fcc243dbd9ee99aab9a7ec42c989d1964a3ffb 917#eventlog : Figure 5-38: Transaction logs example Project Description 70 70 Now, let’s look at the Getters and Setters: Figure 5-39: DogsOrCats.sol – Getters and Setters You can see how to emit events (setAdmin method) and how some of the methods have the onlyAdmin modifier (setAdmin and getSolution). 71 Regarding the Admin methods, we are not going to cover them all, but we can see the most interesting ones. The method createContest requires (besides being the admin and that there is not an ongoing contest) the transaction to contain some Ether, which is going to be the prize of the contest. Please note that the prize variable is just to store the amount of the prize, not the prize itself. The prize will pass from the Admin’s Ethereum account to the Smart Contract account. To send the prize to the winner/s the Admin will use the method sendPrizeToWinners, which will equally divide the prize for all the winners and will transfer it to them. With the method calculateWinners we will obtain the contester/s with the best (lowest) result. The result of each contester is calculated when they send their result. Figure 5-40: DogsOrCats.sol – createContest, calculateWinners and sendPrizeToWinners methods Project Description 72 72 Regarding participants functions they will participate with the contest function: Figure 5-41: DogsOrCats.sol – contest, obtainScore and isFirstAttempt methods This function is: 1. Mapping the user (its address) with the obtained score (line 153) 2. Storing the user address in a list of the participants (lines 154 and 155). As any user can participate as many times as desired (the valid score will be the last one), it is only required to store its address in the list just the first time. There is one more thing to explain, the view modificator (in methods obtainScore and isFirstAttempt). It is related to gas consumption. If we see the contest method, it is: • Having computational cost • Reading the state of the blockchain • Modifying the state of the blockchain Each one of those items consume gas and, by default, Solidity will assume that all functions are potentially capable of doing all of them. However, obtainScore and isFirstAttempt methods do not modify the state of the blockchain. Using the view modifier we let the compiler know that the function is not going to modify the state of the blockchain and it will make it more efficient in terms of gas consumption or, in case it is also a public method (like the getters), it will not require a transaction (no gas to be paid). 5.3.2.1.2 TextOrImage.sol This file is for defining the Text from Image Smart Contract. As the structure is very similar to DogsOrCats.sol, we will only focus on its main difference which is the obtainScore method: 73 Figure 5-42: TextOrImage.sol – obtainScore method We want to compare the obtained string of the contester with the string of the real solution. For that we are using the Levenshtein distance algorithm, which counts the minimum number of modifications that must be made to a string to make it equal to the other string. A relevant aspect of Solidity is that there are no libraries available. I had to code the max and minimum methods: Figure 5-43: TextOrImage.sol – minimum and max methods The last comment about this is the pure modificator (it is being used in the three methods; obtainScore, minimum and max). If the view modificator is for letting the compiler know that the function will only have computational cost and will need to read the status of the blockchain, the pure modificator is to indicate that the function will not need to read the status of the blockchain and, therefore, make it more efficient in terms of gas consumption. 5.3.2.2 Python Files There are eight Python files in this project. Nevertheless, we are not going to focus on all of them but the ones related with the communication with the Smarts Contracts (TextImageContract.py, Notifications.py and DogsOrCatsContract.py). Here is a diagram about the relation of these files: Project Description 80 80 5.3.2.3.2 Participating in the contest There will be four participants and their respectives solutions will be: • Participant 1: ThisIsTheSolutionn • Participant 2: ThisIsTheSolution • Participant 3: ThisIsTheSolution • Participant 4: asdf We expect to have the prize half-splitted between Participant 2 and Participant 3. For Participant 1 we can see that the contest is active and there are no contesters yet: Figure 5-62: Contest status before sending solution After sending the solution, we can check that the info has been updated: Figure 5-63: Checking participant address has been added to the ‘Contesters’ section If we analyze the transaction: https://ropsten.etherscan.io/tx/0x347f0cde6742717a4a4284291c841cf834b899ba01452b64c0936999de5a e8d1 • We can see that the only spent ether is for covering the gas cost: Figure 5-64: Transaction cost 81 • The solution is “attached” in the input data: Figure 5-65: Solution in transaction • In the ‘Logs’ section we can see the notification from the contract: Figure 5-66: Notification from contract The details from the rest of contesters transactions can be checked here: • Participant 2: https://ropsten.etherscan.io/tx/0xdc47ce30af0c2b6a6d183808fbae38062943251984b01365c5a86d 824bbff17a • Participant 3: https://ropsten.etherscan.io/tx/0x6037a0607eadf3fd416aec0b0a193f0985672350a8db8e0b3af700f 8e5180aa5 • Participant 4: https://ropsten.etherscan.io/tx/0x44e55b54b1d244a944b1be127e125b194759c358ff07a6b7b47ec 16d3a2ba155 5.3.2.3.3 Contest resolution We can see that all participants have sent their solutions by clicking in the ‘Info’ button: Figure 5-67: Checking participants addresses in ‘Contesters’ section To obtain the winners, we click in the ‘Calculate Winner/s’ button: Once the transaction (https://ropsten.etherscan.io/tx/0x5075f7c5ad746713f090ab7fba8680a6d0b7a560f7825d718d887eedb6c6 9bef) has been mined, we can see that the winners have been selected (but the prize has not being sent yet): Project Description 82 82 Figure 5-68: Checking winners addresses Please note that the addresses match with the addresses of the Participants 2 and 3. To send the prize to the winners we click on the button ‘Send Prize’. Once the transaction is mined, the winners will obtain the prize. If we analyze the transaction: https://ropsten.etherscan.io/tx/0x333a379f0f2b0543fad3a3224b08dad38f39d5886c4a714023a84e5e9a02b 85a Figure 5-69: Prize transfer to winners We can see that 0.3 ETH were transferred to each winner. 5.3.2.3.4 Gas consumption and cost analysis There are 3 main parameters for calculating how much are we going to spend in the fees for the transaction: • Gas Usage: Required gas for mining the transaction. It can not be modified. • Gas Price: The amount of Gwei for each unit of gas. It can be set; the higher the gas price, the sooner the transaction is going to be mined. If the gas price is too low, the transaction will (potentially) never get mined. It fluctuates widely; for this analysis we are going to consider it as 50Gwei. You can consult the historical gas price here: https://ycharts.com/indicators/ethereum_average_gas_price Figure 5-70: Average gas price Please note that the previous contest example was done in a testnet, not the real network of Ethereum (much less people using the testnet, gas price is much lower). o You can also choose the maximum amount of gas you are willing to spend, with the Gas Limit parameter. The maximum allowed Gas Limit is approximately 30.000.000 Gwei. • ETH Price: To be fair, the ETH price has no influence on the cost (in ETH) of the fee. However, it is good to have an idea on how much would be in Euro. Again, ETH price fluctuates widely; for this analysis we are going to consider it as 1ETH = 1000€. You can consult the historical ETH 83 price here: https://coinmarketcap.com/es/currencies/ethereum/eth/eur/ Figure 5-71: Historical ETH Price (€) In these contests, the transaction that will require more gas is obtaining the score as it is where the biggest computational effort is. Continuing with the ‘Text from Image’ contest, the larger the solution, the more computational effort is required. Now, we are going to estimate how much would cost to create and participate in the example contest if it was deployed in the Ethereum main network: • Contest creation: 93484 gas * 50 Gwei/gas = 0’010788 ETH → 10’788€ • Contest participation: 409331 gas * 50 Gwei/gas = 0’047218 ETH → 47’218€ If we decide the solution to be larger, we will see how the fees cost is incremented. In fact, we have seen that there is a limitation on the number of characters of the solution (185 characters). To obtain the score of a 185 character string needs more than the maximum amount of gas consumption allowed per transaction. 5.3.2.3.4.1 175 character solution • Contest creation: 229115 gas * 50 Gwei/gas = 0’026338 ETH → 26’338€ https://ropsten.etherscan.io/tx/0xc8b73876ab0c1c29204eff3baf4475e655597050df5706b5de5a50 3b783a6214 • Participation: 27857652 gas * 50 Gwei/gas = 3’1963 ETH → 3196’3€ https://ropsten.etherscan.io/tx/0xfe80de17e4b8a626068ceb5dd48d99cefb11a84e2e480159921c2e d7ab027532 5.3.2.3.4.2 185 character solution • Creation: 229235 gas * 50 Gwei/gas = 0’026294 ETH → 26’294€ https://ropsten.etherscan.io/tx/0xbe3b059a64ac6f8770eddb592ce7a22b8da9c0fe224a7061067077 5506bb501f • Participation: 30000000 * 50 Gwei/gas = 3’4377 ETH → 3437’7€ Note that, as the transaction has been reverted, the contester was not able to submit its solution to the contest (and the fee has been paid). https://ropsten.etherscan.io/tx/0x4da6bf1c566ce2f83b20026ee0b489bd174bbbd7828f16c9ed9aea 8dc04c1b4b Project Description 84 84 5.3.2.4 Contract Deployment To deploy the Smart Contract in Ropsten I am using two tools: • Infura: Infura defines itself as “Infura provides the tools and infrastructure that allow developers to easily take their blockchain application from testing to scaled deployment - with simple, reliable access to Ethereum and IPFS”. Basically it provides access to the Ropsten network (and other Ethereum networks). It will give you an endpoint (https or wss) to be used as an API for managing your contract or contracts. • Truffle: The tool that will deploy the Smart Contracts. 5.3.2.5 Setting the deployment: Configuration files The configuration for contract deployment is really simple with Truffle (and Infura), it uses JavaScript. It is only needed a file defining which contracts to deploy (deploy_contract in this case) and a file to define the network (truffle-config.js in this case): Figure 5-72: deploy_contract.js file Figure 5-73: truffle-config.js file 5.3.2.6 Deployment Example First we have to compile the contracts Figure 5-74: Contracts compilation With this, besides obtaining the compilation, we have obtained the ABI_JSON of the contracts: 85 Figure 5-75: Section of the ABI_JSON of DogsOrCats contract Then we run truffle migrate --network ropsten Figure 5-76: Placing contracts in Ropsten Network 5.3.3 Problems and limitations during the development 5.3.3.1 Coding the Levenshtein distance algorithm in Solidity Language One of the limitations is that Solidity can not compare strings nor characters. The workaround was to compare bytes in sets of 32B; it will work for alphanumeric characters (they are encoded in sets of 32B). It will not work for characters that need more than 32B to be encoded. The other limitation is that the maximum length of the solution can not be variable. To implement this algorithm, a two dimensional matrix (distance variable, line 168 in TextImage.sol) is needed. Solidity does Project Description 86 86 not allow this kind of variable to be fully variable and one of the dimensions must be fixed. In this case the decision was to set the maximum length of 200 characters. In case of a future modification, it would be needed to modify the line 168 and deploy a new contract. 5.3.3.2 Moving from local testing environment to real network testing Local testing was done with Ganache, a software that creates a personal Ethereum blockchain. It is very useful for the initial tests and learning how a blockchain works. I faced 3 main issues when moving to a real network (Ropsten): • Building transactions: Ganache simplifies the transactions, it is configured by default to accept any transaction. In Ropsten (like in MainNet), transactions need to be signed. I had to divide the transaction generation into two functions, createTx and signTxAndWaitNotif for adding the signing feature with the private key of the user address on every transaction. • Notification Handler: Ganache is configured by default to mine a block for each transaction so transactions are instantly added to the blockchain. In Ropsten transactions take some time to be included in the blockchain. I had to add the feature of checking if a transaction has been included in a mined block or it is still pending. • Web3py community: It is not the most popular library for interacting with Ethereum. Most people prefer to use Javascript as most Dapps use a website as GUI. Most of the time, error descriptions are not very clear, and it is complicated to find information about this error on the Internet as the Web3py community is a small one. 87 6 FINAL CONCLUSIONS fter surveying the Ethereum environment, it can be stated that there is a solid technology at the background. The possibility of using a blockchain as the backbone of an application can derive into useful tools. Ethereum has one of the biggest communities of developers and the -increasing- interest from private companies, all indications are that it will continue improving its performance. Currently, the most popular Ethereum DApps are for exchanges (to swap ETH and tokens), marketplaces (to buy goods or services with ETH) and games. These games are usually focused on having certain assets and use them to obtain better assets from other players. The most popular is Axie Infinity, a game where you can collect and raise fantasy creatures. Besides collecting and raising, you can make a team consisting of 3 Axie's to battle in arena or adventure. Regarding this project we can conclude that, currently, Ethereum blockchain is not a good solution for calculating the winner/s of Machine Learning contests. This kind of task requires computational power that is a far cry from what the ethereum blockchain can offer (remember the limitation of around 185 characters for the contest, or the high cost of calculating the score of a solution around 175 characters). 6.1 Future Work Ethereum DApps have high potential, but they have certain limitations as well. As per what we have seen in this project, their main limitation is the computational power. As of today, they are not a good option for applications that require high computational performance. On this scenario gas cost is expensive and unpredictable; although with the change from Proof of Work to Proof of Stake the gas cost will be predictable, it will probably remain expensive. There are also coding limitations for the ‘Text from Image’ contest, it is not possible to have a fully dynamic solution length. That being said, if we are still decided to implement a solution for Machine Learning competitions with Ethereum bockchain, the best option would be to move the backend from being fully decentralized to semidecentralized. The idea would be to have a “standard” server in charge of obtaining the score of each participant and providing them to the Smart Contract (for example with a REST API). A The main advantage of blockchain technology is supposed to be that it’s more secure, but new technologies are generally hard for people to trust, and this paradox can’t really be avoided. - Vitalik Buterin - References 88 88 7 REFERENCES [1] «Bitcoin Whitepaper,» [En línea]. Available: https://bitcoin.org/bitcoin.pdf. [2] «CoinMarketCap - Bitcoin,» [En línea]. Available: https://coinmarketcap.com/currencies/bitcoin/. [3] «CoinMarketCap - Litecoin,» [En línea]. Available: https://coinmarketcap.com/currencies/litecoin/. [4] «LiteCoin Whitepaper,» [En línea]. Available: https://whitepaper.io/document/683/litecoin-whitepaper. [5] «CoinMarketCap - Ethereum,» [En línea]. Available: https://coinmarketcap.com/currencies/ethereum/. [6] «CoinMarketCap - Dragonchain,» [En línea]. Available: https://coinmarketcap.com/currencies/dragonchain/. [7] «DragonChain Whitepaper,» [En línea]. Available: https://whitepaper.io/document/58/dragonchainwhitepaper. [8] «Blockchain introduction - medium,» [En línea]. Available: https://medium.com/@4pelumite/blockchain-23d88d1e5832. [9] «Bitcoin blockchain decentralization - Investopedia,» [En línea]. Available: https://www.investopedia.com/terms/b/blockchain.asp. [10] «Ripple - Consensus Whitepaper,» [En línea]. Available: https://ripple.com/files/ripple_consensus_whitepaper.pdf. [11] «Stellar Consensus Protocol,» [En línea]. Available: https://www.stellar.org/papers/stellar-consensus- protocol. [12] «Federated Byzantine Agreement,» [En línea]. Available: https://cryptorobin.com/what-is-federated- byzantine-agreement/. [13] «Ethereum Whitepaper,» [En línea]. Available: https://ethereum.org/en/whitepaper/. [14] «Ethereum Yellowpaper,» [En línea]. Available: https://ethereum.github.io/yellowpaper/paper.pdf. [15] «Ethereum Official Documentation,» [En línea]. Available: https://ethereum.org/en/developers/docs/. [16] «Ethereum Official Documentation - DApps,» [En línea]. Available: https://ethereum.org/en/developers/docs/dapps/. [17] «Ethereum DApps 2,» [En línea]. Available: https://www.investopedia.com/terms/d/decentralizedapplications-dapps.asp. [18] «Ethereum Dapps 3,» [En línea]. Available: https://ciberninjas.com/cripto-ethereum-dapps/. 89 [19] «Ethereum DApps 4,» [En línea]. Available: https://www.miethereum.com/smart-contracts/dapps/. [20] [En línea]. Available: https://www.iebschool.com/blog/dapps-o-aplicaciones-descentralizadas-que-son- y-como-funcionan-finanzas/. [21] «Ethereum Official Documentation - Data Structures,» [En línea]. Available: https://ethereum.org/en/developers/docs/data-structures-and-encoding/. [22] «Ethereum Official Documentation - Patricia Merkle Tries,» [En línea]. Available: https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie. [23] «Merkle Patricia Trie,» [En línea]. Available: https://medium.com/codechain/modified-merkle-patricia- trie-how-ethereum-saves-a-state-e6d7555078dd. [24] «Merkle in Ethereum,» [En línea]. Available: https://blog.ethereum.org/2015/11/15/merkling-in- ethereum/. [25] «Etherum Trie,» [En línea]. Available: https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/. [26] «Ethereum Data Structure 1,» [En línea]. Available: https://medium.com/hackernoon/getting-deep-into- ethereum-how-data-is-stored-in-ethereum-e3f669d96033. [27] «Ethereum Data Structure 2,» [En línea]. Available: https://medium.com/codechain/modified-merkle- patricia-trie-how-ethereum-saves-a-state-e6d7555078dd. [28] «Ethereum Data Structure 3,» [En línea]. Available: https://ethereum.stackexchange.com/questions/55461/how-to-store-storage-trie-in-leveldb. [29] «Ethereum Data Structure 4,» [En línea]. Available: https://ethereum.stackexchange.com/questions/46068/what-are-the-storage-and-state-tries. [30] «Ethereum Official Documentation - RLP,» [En línea]. Available: https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp. [31] «Ethereum Official Documentation - SSZ,» [En línea]. Available: https://ethereum.org/en/developers/docs/data-structures-and-encoding/ssz/. [32] «Ethereum Official Documentation - Accounts,» [En línea]. Available: https://ethereum.org/en/developers/docs/accounts/. [33] «Ethereum Accounts - 1,» [En línea]. Available: https://info.etherscan.com/understanding-ethereum- accounts/. [34] «Ethereum Accounts - 2,» [En línea]. Available: https://medium.com/coinmonks/ethereum-account- 212feb9c4154. [35] «Ethereum Accounts - 3,» [En línea]. Available: https://www.theengineeringprojects.com/2021/06/ethereum-accounts-definition-types-and-fields.html. [36] «Ethereum Official Documentation - Transactions,» [En línea]. Available: https://ethereum.org/en/developers/docs/transactions/.