Decentralized Application for
E-Commerce Using Blockchain and
Trusted Compute
João Carlos Oliveira Lago
Masters in Informatics and Computing Engineering Supervisor: Pedro Souto
Decentralized Application for E-Commerce Using
Blockchain and Trusted Compute
João Carlos Oliveira Lago
Masters in Informatics and Computing Engineering
De momento, soluções centralizadas para comércio eletrônico são a principal escolha do con-sumidor para efetuar comércio online, o que leva a grandes empresas possuírem enormes porções dos nossos dados privados e a controlarem a forma como realizamos comércio. Isto implica inter-mediários nestas empresas com poder de nos espiar e, potencialmente, vender os nossos dados ou usá-los para ganho de terceiros. Ao dar tanto poder a instituições e governos para nos monitorizar, corremos o risco de uma grande deterioração das nossas liberdades.
Em dar tanto controlo para tão poucas empresas efetuarem o nosso comércio, também pode permitir a que intermediários sem nome manipulem os consumidores, apresentando-lhes com in-formações em favor dos interesses dessas grandes empresas. Também permite a censura de par-ticipantes que usam os tais serviços centralizados e a aplicação de elevadas taxas, entre outros problemas associados à centralização do comércio eletrônico para apenas algumas grandes em-presas.
A descentralização do comércio eletrônico é uma possível solução para o intermediário, sendo que negócios realizados diretamente entre comprador e vendedor resultaria na remoção do inter-mediário e como tal os problemas anteriormente mencionados deixariam de estar presentes.
Este trabalho será benéfico para todos que usem serviços centralizados para efetuar comércio eletrônico, e em longo prazo pode ajudar a evitar tirania por parte de grandes empresas ao possi-bilitar mais liberdades, menos censura e maior controlo sobre os nossos dados pessoais, e tudo a custos acessíveis.
Neste documento é apresentada uma alternativa às plataformas de comércio eletrônico mais usadas atualmente, ao aproveitar os benefícios da descentralização, tentando manter a facilidade de uso crucial das soluções de comércio eletrônico centralizadas.
Através do uso de várias tecnologias, principalmente a blockchain, contratos inteligentes, e trusted compute, o foco do projeto é criar código que combine todas estas tecnologias para criar uma alternativa descentralizada para o comércio eletrônico. Esta deve ser rápida, escalável, e fácil de usar. Numa breve explicação, a blockchain e contratos inteligentes seriam usadas como a ca-mada base da aplicação sendo que esta caca-mada mantém o estado da aplicação de forma fidedigna, enquanto que a trusted compute seria usada para computações que seriam demasiado custosas para correr em contratos inteligentes.
PALAVRAS-CHAVE: e-commerce, blockchain, bitcoin, sistemas distribuídos, contratos inteligentes, criptomoedas, descentralização
Abstract
Currently, centralized e-commerce solutions are the mainstream consumer choice for online trade which leads to large companies owning big portions of our private data and controlling how we conduct business, this entails middleman in these companies with power to spy on us and potentially sell our data or make use of it for third party gain. By giving away such tremendous power to institutions and governments to monitor us, we risk a major deterioration of our freedoms. Handing over this much control to few large entities for conducting our electronic commerce can also enable nameless middleman to manipulate consumers by feeding them information in fa-vor of their interests, allow for censorship of the participants using the centralized services and the application of high fees among other problems associated with the centralization of e-commerce to a few large entities.
The decentralization of e-commerce would provide a solution to the middleman, as business would be performed on a peer-to-peer basis and consequently, with the removal of the middleman, the aforementioned issues would cease to exist.
This work will benefit anyone who uses centralized e-commerce and in the long term it might help everyone avoid tyranny by providing more freedoms, less censorship and more ownership of our own data, at cheaper costs.
In this document it’s presented an alternative to commonly used online commerce which lever-ages the benefits of decentralization while attempting to maintain the crucial ease of use from centralized electronic commerce solutions.
Through the use of several technologies, mainly blockchain and trusted compute, this project aims to create code which glues these all together in an effort to create a scalable, fast and easy to use decentralized alternative to online commerce. Explained very briefly, the blockchain and smart contracts are used as the base layer for trustless state handling and other back-end tasks such as escrow, while trusted compute is used for intensive computations which would be too expensive to run on smart contracts.
KEYWORDS: E-commerce. Blockchain. Bitcoin. Distributed systems. Smart contracts. Cryp-tocurrencies. Decentralization
I am grateful for my supervisor, professor Pedro Souto, for the incredible commitment to help me with this dissertation.
I want to thank my faculty colleagues for moral support and overcoming this task together. And of course, I want to express appreciation for my family and their moral support through the making of this work.
João Lago
“Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road.”
Stewart Brand
1 Introduction 1 1.1 Context . . . 1 1.2 Motivation . . . 1 1.3 Objectives . . . 1 1.4 Dissertation Structure . . . 2 2 Literature review 3 2.1 The Blockchain and Bitcoin . . . 3
2.2 Smart Contracts and Ethereum . . . 5
2.3 Trusted Compute Framework . . . 9
2.4 Oracles . . . 10
2.5 Intel SGX . . . 11
2.6 Scone . . . 12
2.7 InterPlanetary File System . . . 13
2.8 iExec . . . 13
2.8.1 Who Are The Users or Requesters . . . 16
2.8.2 What Are The Accounts . . . 16
2.8.3 What Are The Apps, Datasets and Workerpools . . . 17
2.8.4 What Are The App, Dataset and Workerpool Orders . . . 17
2.8.5 How a Task is Executed . . . 17
2.8.6 How Consensus is Established . . . 18
2.8.7 How Permissioning Works . . . 19
2.8.8 iExec Oracle . . . 20 3 Application 21 3.1 Roles . . . 22 3.2 Actions . . . 22 4 Dapp Design 24 4.1 System’s architecture . . . 24 4.1.1 Ethereum Subsystem . . . 25 4.1.2 Workerpools Subsystem . . . 26 4.1.3 Interface Component . . . 27 4.1.4 Other Components . . . 27 4.2 Use-Cases . . . 28 4.2.1 Logging In . . . 28 4.2.2 Selling a Product . . . 30
4.2.3 Handling Private Information . . . 33
CONTENTS vi 4.2.4 Making a Purchase . . . 37 5 Dapp Implementation 48 5.1 Tools Used . . . 48 5.2 Web Client . . . 48 5.3 Ethereum . . . 52 5.4 iExec . . . 55 6 Dapp Evaluation 57 6.1 Performance . . . 57 6.1.1 Ethereum . . . 57 6.1.2 iExec . . . 58 6.2 Security . . . 59 6.2.1 Ethereum . . . 59 6.2.2 iExec . . . 61 6.3 Cost . . . 61 6.3.1 Ethereum . . . 61 6.3.2 iExec . . . 64 7 Conclusions 65 7.1 Achieved Objectives . . . 65 7.2 Future Work . . . 66 7.2.1 Dispute resolution . . . 66 7.2.2 Sybil Attack . . . 66 7.2.3 Accepting Cryptocurrencies . . . 67
7.2.4 Ethereum Meta Transactions . . . 67
A Setting up the web client 68
B Dispute resolution 69
2.1 Transaction sequence diagram . . . 8
2.2 Remote attestation . . . 16
4.1 Interaction between blockchain and user interface . . . 25
4.2 Decentralized e-commerce component diagram . . . 25
4.3 Infura service interaction with the web client . . . 28
4.4 Logical architecture of Smart Contracts, from the Purchase Side . . . 28
4.5 Logged out web client . . . 29
4.6 Logged in account . . . 30
4.7 Product selling form . . . 31
4.8 Product form marketplace . . . 32
4.9 Component diagram when calling deployProduct . . . 32
4.10 Access to client information from the Dapp@iExec . . . 33
4.11 Client Information displayed on web client . . . 34
4.12 Client Information deployment form . . . 36
4.13 Catalog . . . 37
4.14 Ongoing purchase or order in the first stage . . . 38
4.15 Component diagram when calling ’performorder’ . . . 39
4.16 Component diagram involved in the buying of a product . . . 40
4.17 Ongoing purchases information tables . . . 41
4.18 Order state machine . . . 42
4.19 Balance . . . 42
4.20 Order waiting for confirmations . . . 43
4.21 User allowing the order contract to manage 20 RLC of the user’s balance . . . 43
4.22 Ongoing purchase at the second stage . . . 44
4.23 Ongoing purchase awaiting validation . . . 45
4.24 Interaction with the iExec stack . . . 45
4.25 Encrypting client information with seller’s public key . . . 46
4.26 Last stage of an order . . . 46
5.1 Interaction between blockchain and user interface . . . 49
6.1 Scone-Based SGX PySpark Performance . . . 58
6.2 Mining pools share of hashing power . . . 60
6.3 Ethereum’s fee vs network utilisation chart . . . 62
6.4 Ethereum’s average daily fee in Gwei . . . 63
List of Tables
6.1 Some of the DAPP’s off-chain executions . . . 59
6.2 Transactions’ cost . . . 64
B.1 Nash equilibrium . . . 69
B.2 Dispute resolution payoff matrix . . . 70
B.3 Dispute resolution payoff matrix attack . . . 71
4.1 Dataset contract provided by iExec . . . 33
4.2 Client information in file format . . . 35
4.3 Dataset order object . . . 36
5.1 reloadProducts function from the Web Client . . . 49
5.2 buyThisProduct function from the Web Client . . . 50
5.3 approveAndCall function from RLC.sol [1] . . . 52
5.4 receiveApproval function from Order.sol . . . 52
5.5 runDataValidation function from Order.sol . . . 53
5.6 completePurchase function from Order.sol . . . 54
5.7 entrypoint file app.py of the off-chain application . . . 55
5.8 _sendRequestAPI function from verifyAddress.py . . . 55
5.9 addressApi.json . . . 56
5.10 callback and determinism functions from utils.py . . . 56
C.1 ItemFactoy.sol . . . 72 C.2 Item.sol . . . 72 C.3 Order.sol . . . 73 C.4 app.py . . . 77 C.5 verifyAddress.py . . . 77 C.6 creditcardcheck.py . . . 78 C.7 utils.py . . . 79 C.8 resources.json . . . 80 C.9 exceptions.json . . . 80 C.10 addressApi.json . . . 80 C.11 Dockerfile . . . 80 ix
Symbols Abbreviations
UTXO Unspent Transaction Output
EEA Ethereum Enterprise Alliance
TCF Trusted Compute Framework
SGX Software Guard Extensions
IAS Attestation Service for Intel SGX
DLT Distributed Ledger Technology
API Application programming interface
IPFS InterPlanetary File System
SCONE Secure Container Environment
DAPP Decentralized Application
TEE Trusted Execution Environment
SMS Secret Management Service
ABI Application Binary Interface
EVM Ethereum Virtual Machine
Enclave Private region of memory secured through Intel’s SGX, where data is protected from being read by any outside process, including privileged host processes.. 10–13, 58, 59, 61 ETH Otherwise known as Ether, it’s the digital currency used as fuel in the Ethereum platform..
9, 16, 30
Gwei A denomination of ETH, where 1e−9 Ether equals 1 Gwei. vii, 7, 61–63
IAS Attestation service, hosted by Intel, whose main goal is attesting Intel’s SGX created enclaves to a replying party. Otherwise known as remote attestation.. 11
Task A Task relating to iExec is a computational job that needs computing power to be executed.. 14–19, 44, 45, 59
USD The official currency of the United States of America.. 62–64
Chapter 1
Introduction
This project merges together a wide range of technologies associated with distributed systems, in an effort to provide a scalable but yet decentralized solution to electronic commerce, where there doesn’t need to be one or more entities controlling all the information and processes for all parties involved in digital trade. It takes advantage of the advances in decentralization pro-vided by blockchain and smart contracts while maneuvering around its shortcomings with other technologies, namely trusted compute.
1.1
Context
International electronic commerce is concentrated to a few large companies such as eBay,
Amazon, AliExpress, and Wish [2].
This level of centralization in the way we conduct our trades is unprecedented in human his-tory and gives away immeasurable power to a few large entities, therefore making the general population more controllable and paving the way for the deterioration of our freedoms.
1.2
Motivation
As centralized electronic commerce platforms have middleman expenses and can easily col-laborate when setting fees on goods sold due to being few in number, fees on these platforms are expected to be high. There’s also the issue of the censorship forced on by governments and the platform owner’s ideals and beliefs, and the lack of privacy as we need to provide our name, address, contact and payment methods to these centralized entities.
1.3
Objectives
The main objective of this work is to explore a way to remove the middleman from our online commerce while still retaining the features and characteristics present in centralized e-commerce
platforms that are necessary to achieve mainstream adoption in a private, decentralized and scal-able alternative.
1.4
Dissertation Structure
In addition to this chapter, this document has six more chapters. In the next chapter, we survey the state of the art related to the technological aspects of decentralized e-commerce and relevant concepts that provide detailed technical information on the core technologies used for this project. With a focus on Ethereum and iExec so the reader can more easily understand the following chapters.
The third chapter presents in more detail the problem this work tries to address, by describing the requirements of an application that supports decentralized e-commerce.
Chapters 4 to 6 describe the design, the implementation and the evaluation of a decentralized e-commerce application that satisfies the requirements presented in Chapter 3.
The seventh and last chapter concludes with a summary of the main contributions of the work documented in this report and elaborates on future work that would further flesh out this project.
Chapter 2
Literature review
In this section we review the state of the art of the relevant technologies to this work.
2.1
The Blockchain and Bitcoin
Blockchain technologies were popularized with the emergence of Bitcoin at the start of 2009, brought by an anonymous person or group called Satoshi Nakamoto and their whitepaper entitled
"Bitcoin: A Peer-to-Peer Electronic Cash System" [3]. As the name of the whitepaper suggests,
Bitcoin enables peer-to-peer transfer of a digital money whose scarcity and useful characteristics such as being portable, durable, divisible and fungible give it a perceived value.
Bitcoin is the solution of the double spending problem in digital currencies. This problem arises when a party sends the same digital token, representing some digital currency amount, to multiple different parties and thus creates new tokens, one for each different party, essentially spending the same digital cash more than once.
Bitcoin uses Proof of Work, known before mainly for its implementation in the Hashcash
system to prevent denial-of-service attacks and spam emails [4]. The Proof of Work consensus
algorithm adjusts difficulty to mine new Bitcoins so that it takes miners around 10 minutes to find the winning hash and include the next block to the chain which includes Bitcoin transactions made during those 10 minutes. During this interval of time the whole network can also get in sync with the latest work done for the chain.
Finding the winning hash is a matter of probability, and the more computational power a miner has to compute new hashes per second, the higher the probability that it will find the winning hash. The winning hash is a hash whose number of leftmost zeros is the required length based on current difficulty levels, the higher the difficulty level the lengthier the number of leftmost zeros on the hash needs to be. Difficulty level is managed based on the amount of processing power, or hash rate, available at present on the network and the higher the global hash rate is, the harder the difficulty level needs to be to maintain the 10 minute interval between new blocks added to the chain.
Besides the intervals between blocks, each block has a limited space for which to store
trans-actions. The limit was initially set to 1 Megabyte [5] but as since changed to around double the
size.
Bitcoin manages accounts with public-key cryptography, an account can be thought of as a public-private key pair where transactions are signed with the private keys, and the destination addresses, where Bitcoins are sent, are public keys. Balances are managed through a system of unspent transaction outputs, or UTXO, where an account’s balance is the sum of all UTXOs belonging to it. When an account spends Bitcoins, it aggregates enough of its UTXOs, which were from transactions made to it, and uses them as input for the new transaction, these UTXOs become spent and no longer usable. If the sum of the UTXOs exceeds the amount required for the transfer then a new UTXO is created for the account with the difference minus the transaction fee. Every transaction needs to be accompanied with a fee payed in bitcoins by the sender to the miner which includes it in a block. Otherwise, the miner won’t have any incentive to include a fee-less transaction in a block.
In order to execute a transaction, i.e. include it in the Blockchain, a user sends it to a node in the Bitcoin network, which then spreads it to the other nodes, so that it eventually is received by most nodes. Every node stores the transaction in what is called the mempool, where tentative transactions the node receives get stored. When a node finds the winning hash that warrants it gets to include the next block to the chain and receive the reward in Bitcoins, the transactions it chooses to include in the block are removed from its mempool and if the transactions exceed the limit size of the block, the miner will prioritize the transactions that include the highest fees. Therefore due to the limit in block space, the transactions that pay the higher fees have priority to be included in the blockchain.
When two incompatible transactions that together would place its account’s balance in the negative get included in the tentative transaction mempool, where all transactions exist before getting included in a block, the transaction that first gets added to a block will invalidate the second one. If the two transactions get included in different blocks, and those blocks are concatenated to different chains, then the longest chain will include the transaction that prevails. In the Proof of Work consensus algorithm, miners are economically motivated to mine only for the longest chain since mining for a soon to be dead chain is a waste of resources. Any other shorter chain either doesn’t survive or remains as a fork, or new blockchain, sharing only the same history from the point it first forked from the main chain.
After a transaction gets included in a block and added to the chain, the party in the receiving end of the transaction should wait for at least a few more block to be added to the chain before considering the transaction valid. As for every block added after a transaction is included is a confirmation that the transaction was indeed included on the longest chain. In other words, the higher confirmation number a transaction has, the exponentially higher the probability the trans-action was included on the main chain, and thus not a shorter chain that dies off. Confirmations are important to reduce the chance of being victim to a double spend attack.
2.2 Smart Contracts and Ethereum 5
less prone to attacks due to a higher cost to do so, such as the most famous attack vector for the Bitcoin network, the 51% attack. The 51% attack happens when more than half of the mining hashing power is allocated to one or a few collaborating entities, in this case scenario the entity or collaborating entities are able to perform double spends. This is done by creating two chains, each containing a different incompatible transaction, and the attacker is able to mine concurrently for the two chains, where there isn’t a longest chain for enough time that both incompatible trans-actions get enough confirmations to appear valid.
A few alternatives to the Proof of Work consensus algorithm have been proposed such as the
less resource intensive Proof Of Stake [6], which shares the same principles to Proof Of Work, but
instead of being the amount of hash power that indicates the probability to mine a block, it’s the amount of coins or tokens of the chain a miner, or staker in this case, has that sets the probability of mining a block and getting the reward for it. This raises a concern of having nothing at stake when mining for chain forks, as in the Proof Of Work algorithm miners have economic incentive to not waste resources mining for shorter chains but for the Proof Of Stake algorithm a staker can stake for any chain without the worry of wasting resources doing it and this in turn could lower the percentage of stake in the network needed to perform a double spend attack drastically from its sibling Proof Of Work 51%.
Other alternatives to the Proof Of Work algorithm are mainly variants of the Delegated Proof
of Stake [7] algorithm, which sacrifice decentralization in trade for higher performance and
trans-action throughput by having all stake holders vote for a small group of highly equipped miners or pools, where each vote is weighted by the amount of stake, or tokens staked, of the voter. Blockchains supported by this consensus algorithm are byzantine fault tolerant, in that at least 2/3rds of the small group of miners need to be trusted, or in other words, if 1/3rd or more of the small group of miners are traitorous the blockchain is at risk of attack.
2.2
Smart Contracts and Ethereum
Traditional programs implemented in code stored and executed in computers owned and con-trolled by centralized entities are subject to alteration by the owners of said computers, and thus lack integrity and trust that the correct code is executed with the provided inputs.
By leveraging Blockchain and Smart Contract technology a platform could be created which would allow for the seller to sell any item without having to pay monthly hosting fees or middle-man.
The seller would pay a few cents to interact with the Smart Contract hosted by the Blockchain, allowing the seller to publish the product’s details and terms of purchase to the immutable database which is the Blockchain. The smart contract would implement the value transfer business logic transparently through the blockchain, guaranteeing code integrity for all parties involved.
Bitcoin essentially allows the movement of digital money from one account to other accounts.
allow not only to transfer money from one account to others, but also to execute user-defined programs, which are known as smart contracts.
Smart contract platforms such as Ethereum provide what can be seen as a global world com-puter, with no owner or entities controlling what’s stored and executed on this world comcom-puter, effectively supporting a censorship resistant, immutable storage where programs, known as smart contracts, can manage digital money without the need for trust in a third party.
A smart contract can be viewed as a class of objects on Ethereum, whose programming is based on a state machine where the state can be changed with a call to any of the functions im-plemented in the smart contract. The objects created from said smart contracts can send and receive in the monetary value kept by the DLT, however these transfers of value would have to follow the requirements and logic implemented in whichever function is called from the smart contract instance. All changes to the state of the contract can only be done by the business logic implemented in the smart contract code. For each state change, nodes in the network verify the validity of each and if all requirements, business logic and authorizations from the executed smart contract’s immutable code were followed correctly.
The account system works through the use of public key cryptography. More specifically the ECDSA algorithm is used to generate key pairs where the public key is a string of 64 bytes that can be shared with anyone and the private key is a secret for the owner. The public key is hashed with the keccak-256 algorithm and from the first 20 bytes of the result we get the address. An account in the Ethereum blockchain then is identified by the address.
Just like Bitcoin, Ethereum keeps track with its Blockchain of the balance each account has, however the system used for this is not the UTXO system but a simpler model where each account records a balance and when a transfer is made the amount is simply subtracted from one account and added to the other. This simpler model raises the problem that an attacker can just replay the signed transaction to the network and have it mined all over again, however Ethereum solves this by having each account hold a nonce number which is incremented with every transaction the account makes. This nonce is used for signing a transaction before it is broadcasted to the network, thus preventing replay.
To support Smart Contracts, Ethereum holds in its immutable decentralized ledger, code de-ployed to it which include most importantly the functions, and state variables which can be altered or manipulated with signed transactions to the blockchain with instructions to call the contract’s functions.
Smart contracts are identified by public addresses and can be seen as accounts on the network, just like any other account controlled by humans. However, a Smart Contract account can only do what it’s programmed to do, using the ETH payed to it. Also, a Smart Contract will never execute on its own, as there needs to be a transaction made to it, from a human or an internal transaction made by another smart contract, to trigger any of its functions. A transaction on Ethereum can be one of three types. The first type of transactions are transactions that just move value from one account to another, without calling any other function. The second type of transaction is similar to the first, but calls functions from other contracts that may call functions of other contracts and
2.2 Smart Contracts and Ethereum 7
so on. Finally, the third type, are functions that create new smart contracts; these transactions do not send value to any account and therefore don’t even need the field for a ’to’ or receiving address. After a transaction is included in a block, nodes in the Ethereum network check to see if the contract’ state transitions are correct.
Every transaction made on the network incurs a fee which is given to miners as reward and also works to avoid spamming of transactions. The fee payed for a transaction depends on the amount of computation and is called Gas, the calculation of the total Gas usage is the sum of the cost of the different kinds of opcodes (POP, PUSH1, ADD, SUB, JUMP....) used in the computation. The cost per Gas is expressed in Gwei, a monetary unit that is worth 1e−9 ETH. An Ethereum transaction includes a gas limit which mustn’t be exceeded so as to pay the fee. The execution of every operation subtracts a given amount from this value. If the transaction runs out of gas, the transaction is aborted and all its changes are essentially rolled back. Thus by including the gas limit in a transaction, Ethereum prevents potential bugs in a contract where code executes forever therefore wiping out an account’s balance. Ethereum’s size per block is determined based on gas limit per block which as of the of time writing this is set to 12.5 million total gas limit per block.
Blockchain follows the reactive programming model and transactions share some properties with ACID and BASE databases, mainly the transactions can be thought as having Atomicity since a transaction is either fully completed successfully or it’s completely reverted if something goes wrong, transactions are probabilistically more immutable with each added block and always available. A paper was written on the topic, where Blockchain is described as being neither ACID
nor BASE, but instead SALT [9], where a blockchain is sequential, agreed, "ledgered" and
tamper-resistant.
Once a transaction is sent to the Ethereum network, it goes through the process of being included in a block and interpreted by nodes running the Ethereum virtual machine that verify the its validity and perform the computations encoded in the transaction which creates a new state for the accounts and contracts affected by the transaction. The transaction details such as price, gas limit, and other data are logged on the blockchain, and its effects change the state of all accounts and contracts affected. As an example, if Alice wants to send 1 Ether to Bob, she will assign Bob’s address to the transaction’s ’to’ field, its own address to the transaction’s ’from" field, this way when the transaction is signed and sent to the worldwide network of nodes that make up Ethereum, the 1 Ether will be deducted from Alice’s account and added to Bob’s account.
Through the client-side web3.js library and using the credentials provided, a transaction’s conditions are sent to the Ethereum node containing information on what contract is targeted, what function is being called, with what parameters and other details such as the nonce, and a signature by the user. The function and parameters are encoded into the ABI format and the transaction’s data field is initialized with the result. The ABI format is essentially encoding a function identifier, the parameters and other details to a hexadecimal sequence for the EVM, run by nodes, to decode.
Fig.2.1shows the sequence diagram for all transactions to the blockchain through the gateway
of the Infura service. The Infura service is a free service, with also payed plans, that allows the use of a remote Ethereum node through their gateway, removing the need for a DAPP user to have
to run a node themselves. The ‘sendRawTransaction’ call will include the transaction’s conditions and a data field specifying the function id and its parameters in ABI format, as is shown from the txObject to the left of the sequence diagram. After calling the function, the web client effectively subscribes to be alerted every time a block is added on top of the transaction.
Figure 2.1: Transaction sequence diagram
The changes to Ethereum smart contracts by a transaction become effective only when that transaction is included in the blockchain. The time when this happens is difficult to predict. Each block has a total gas limit, thus the highest bidders for that space are added the quickest. Each block has a Gas limit, as of writing it stands at 12,500,000 Gas for Ethereum, and each transaction spends a certain amount of Gas. When a block is added, the miner profiting from it prioritizes all transactions with the highest Gas price to fill in a block, thus the higher the Gas price set for the transaction, the faster a transaction will be picked up and added to the blockchain.
A transaction can be initiated by a call to a smart contract function from code external to the blockchain. Internal calls to smart contract functions do not initiate new transactions, but are executed in the context of the existing transaction instead, and Ethereum’s state will change to the next stage having the function, called externally, fully finished execution including functions called from other contracts by it.
If something goes wrong with the transaction all the changes done until the point of failure will be reverted. Situations where something goes wrong include insufficient Gas limit provided by the transaction’s issuer, or a requirement not being met due to a wrong function parameter given.
During a contract’s function execution, logs can be emitted which allow for low cost storage of data to be used for future reference by web clients or other such software outside the Ethereum network. These logs can not be read or changed from within a contract’s function execution, and their sole purpose is to document changes to the contract. The contract’s code stores the possible formats these logs can take, these formats are called Events, so when during a function execution
2.3 Trusted Compute Framework 9
an Event is emitted, what really happens is that data is stored and indexed by the Event, so if for example a declared event contains two integers and one boolean then when that event is emitted, two integers and one boolean value will be recorded for the contract. Afterwards, by using the Event’s name, external software can find the values for the two integers and the one boolean. Client-side software can acquire Event names from the contract’s ABI which is generated from it’s source code, granted the source code is published and matched to the bytecode of the contract stored on the blockchain.
As an example of a Smart Contract use case, let’s say Alice wants to make a contract with Bob to buy his used lawnmower without intermediaries or an escrow taking a share of the money. Bob would write a contract in code and deploy it to the blockchain via a transaction which would contain an amount of ETH to pay for the transaction plus a collateral amount for future reference, and the contract would contain a buy with collateral function that would be called by Alice’s transaction to the blockchain which would include the amount in ETH to pay for the lawnmower plus a collateral amount. All collateral would be unlocked and sent back after the trade’s made successfully. Now the contract has both Alice’s and Bob’s ETH, and Bob has incentive to go through with the trade after Alice made the purchase because he has locked ETH in the contract, and Alice will have incentive to confirm the delivery of the lawnmower because Alice has locked additional ETH beyond the price of the lawnmower for that purpose. After Alice receives the lawnmower, she sends a transaction to the blockchain calling a function of the contract that returns both Alice’s and Bob’s collateral. In this example both Alice and Bob have incentive for the trade to go through successfully through the Smart Contract, with the advantage Blockchain and Smart Contract offer of full transparency and trustworthiness.
2.3
Trusted Compute Framework
The trusted compute framework was the original name for the Hyperledger Avalon [10]
pro-posal which aimed to make a blockchain independent implementation of the EEA’s Trusted
Com-pute Specification [11]. Hyperledger is an umbrella project for open source Blockchains and tools
and it is hosted by the Linux Foundation consortium, Hyperledger Avalon is one of the open source proposals by the Hyperledger collaborative effort.
The EEA’s off-chain trusted compute specification and the Hyperledger Avalon proposal’s objectives are to introduce support for confidential contract execution, off-loading algorithms with high time complexity from a blockchain’s smart contracts to an off-chain secure Trusted Compute system.
Trusted off-chain execution comes as a solution to the limited capabilities of blockchain when it comes to complex tasks, confidentiality and improved privacy. Joining together the two tech-nologies combines the immutability and capability to audit all results and transactions publicly on the blockchain with the high throughput and confidentiality of code running on a Trusted Compute system.
The architecture for the TCF is based on a worker pool managed by a worker service which receives work orders, or computational tasks, and workers execute those tasks assuring execution integrity and that no memory from what’s executed can be leaked to anyone including the host. To achieve this, workers execute their tasks using a Trusted Compute system. Trusted Compute can make these guarantees of data confidentiality, execution integrity and data access policies in one of three ways, using trusted execution environments, such as the ones created using Intel’s SGX, using Multi-Party compute or utilizing cryptographic security guarantees like the zero-knowledge protocol.
Workers are registered with an on-chain smart contract where they can be discovered. After the worker is registered, there can be two invocation models used to communicate with the requester. The first model, the direct model has the worker communicate directly with the requester to submit the work order and likewise the worker to send back the work order result to the requester, receipts are stored on the blockchain or another mutually trusted location for future auditing. The second model, the proxy model, utilizes smart contracts running on the blockchain for managing the APIs used for the communication between the requester and the worker, the receipts are stored on the distributed ledger.
One implementation of the EEA’s off-chain trusted compute specification and the TCF is the
Trusted Reward Token [12], developed with Token Taxonomy Initiative [13] specifications by
the EEA, which aims to create a reward system for contributing individuals to the participating organization, e.g. commits to a source code repository. This implementation uses the TCF to off-load business rules to trusted execution environment Enclaves so that the cost of running this logic, which requires frequent updates on-chain, is diminished.
2.4
Oracles
Oracles systems, or data on-chaining systems, in association with blockchain technology refers
to the bridging of off-chain data into the distributed ledger [14]. Oracles are a bridge between the
off-chain data source and the on-chain smart contract. A smart contract may interact with one or more oracles, and the oracles can interact with many data sources. Since data external to a blockchain can be unreliable, malicious or simply wrong, data on-chaining isn’t as simple as transferring data to the blockchain, there has to be security guarantees that the data is truthful and safe to be used for smart contract computations.
The smart contract requiring external data can only receive such data in transactions to the blockchain, since this is the only way to change the state of the smart contract, therefore the oracle must own an account on the blockchain for which to sign the transactions with. Once the data is transferred to the smart contract, the smart contract can be fully trusted to function as intended.
Several solutions have been proposed for reliable, secure and truthful on-chaining of data.
One such solution is the TLS-N [15] protocol which relies on the Transport Layer Security for
authentication and integrity of data between the data source server and the consumer contract while removing the trust factor from the off-chain oracle auditor by generating a non-repudiation
2.5 Intel SGX 11
proof that can be verified by any third party. Another solution is the Town Crier [16] Enclave
based oracle which uses Intel’s SGX to create trusted execution environment Enclaves to remove the trust from the oracle since all critical functionality run by the oracle can be executed inside the trusted Enclaves, however due to the use of Intel’s SGX technology to launch these Enclaves there is still need to trust the centralized Intel Attestation Server, or IAS, to validate the Enclave and the need to trust Intel’s CPU to not leak any data from the Enclave. There’s also the voting based
oracles such as the Astraea [17] proposal where the oracle logic present on-chain does a vote in
which data sources vote on answers and the ones who vote on the majority answer get rewarded while the ones who vote on a different answer get penalized, so it’s in their economic interest to vote correctly on the right answer.
One of the most famous oracle systems, especially for the Ethereum smart contract platform,
is from the ChainLink [18] project.
Chainlink on-chain architecture uses an interfacing contract to communicate with the requester contract before the process can begin. It features a reputation based voting system where data sources are rated by the consumer contracts and the reputation of a data source can affect the weight of its vote and the reward gained. Chainlink tries to achieve full decentralization and diversification by allowing a number of oracle options which in turn communicate with a number of different data sources. The protocol includes an order-matching contract for requesters to filter out the best oracle option for them, and an aggregation system to aggregate oracle responses.
Chainlink, offers privacy-preserving oracles by combining with the trusted compute frame-work and using Town Crier’s approach to trusted execution environment Enclaves where input data sent to the Enclave is encrypted beforehand using a public key matching an inaccessible pri-vate key contained only inside the Enclave and thus the input data can be securely decrypted inside the Enclave and used in its computational task to output a result which can’t be used to deduce the given input data, this also allows for the secure handling of credentials by the oracle.
2.5
Intel SGX
Intel’s Software Guard Extensions help protect code confidentiality and integrity when exe-cuted on an untrusted remote host, by providing a secure Enclave enabled by most Intel’s CPU after 6th generation Skylake processors.
The problem comes when a user has to rely on data remaining private and code being run by a remote untrusted host which is often the case when using web services. To solve this, Intel SGX enabled Enclaves can be leveraged to protect the code run in them from any and all malware, even privileged malware from any layer, be it the OS or kernel of the host’s computer.
When first establishing a channel to the untrusted remote host, attestation needs to occur so that the user can safely be assured that they are communicating with the correct program hosted by trusted hardware. The remote host creates a trusted execution environment, to where the user uploads the program and related data for execution by the Enclave. The remote host can provide proof they run an Enclave by having the data and program uploaded by the user hashed and signed
by the Enclave, this value is called MrEnclave, then sent back for attestation. It should be noted that the user will have to trust the hardware manufacturer, in this case Intel, as the manufacturer’s endorsement certificate will be used to prove that the attestation key used to sign the hash of data from the Enclave is safely stored only by the trusted execution environment. An Enclave need only possess the essentials for running the security critical program with the provided private data. A great use case for this technology is the secure aggregation of sensitive data for use in machine learning algorithms, the data would remain private while a machine learning model would be trained with it and which would then be outputted by the trusted Enclave. To make this happen the Enclave could create a key pair which then would be used between it and the user to send encrypted data in and out of the Enclave, the Enclave would in turn have the tools to use the keys to decrypt the private data sent to the Enclave.
It should be mentioned that a user of an application run by a trusted Enclave not only trusts the hardware manufacturer, but also the hardware itself and the author of the application being run inside the Enclave, since if the author’s code is malicious or even just faulty then output from the Enclave could reveal any of the sensitive data stored inside it or produce unexpected results which might trick the user. Therefore the program’s code which is to be run inside the Enclave should be properly audited by the user itself or a trusted delegate.
The protected memory used by the Enclave for it’s computation is named processor reserved memory or PRM. The CPU itself ensures that no component other than the trusted execution environment has access to it, including from any of the layers which constitute the host computer, including the kernel. The PRM stores the application code and data via the Enclave page cache or EPC. The CPU makes sure that for each 4KB EPC page there is exactly one Enclave which has access to it. This initial process of loading the application data and code into these EPC pages is done by computers untrusted software, so it stands to reason if anything malicious happens during this process the Enclaves contents will have a different hash value from the expected and therefore a user would refuse to interact with the Enclave in this scenario.
After this initialization process the Enclave is set up and ready for attestation and computation. The hash of the Enclave’s code and data is also finished and ready to take part in the attestation process between the Enclave and the user to assure the user the Enclave is legitimate and carries the intended code.
2.6
Scone
The scone platform is built on top of Intel SGX to provide an always encrypted execution, both code and data can be encrypted or otherwise merely have their integrity secured.
Scone allows for the encryption of almost any and all data, including data relating to commu-nications, inputs and outputs, data in persistent storage and the main memory for the execution of the application. The keys for these encryptions are stored in SCONE CAS, or Scone Configuration and Attestation Service which is run inside an Enclave.
2.7 InterPlanetary File System 13
The Scone Configuration and Attestation Service features local attestation which makes sure that an application running in an Enclave has the correct signature, before sensitive data is passed to it.
Scone features a file protection system where each file and directory can be given one of three types of protection: authenticated which checks the file’s integrity from unauthorized change, encrypted which in addition to integrity check it also provides confidentiality to the files, and finally not-protected. As changing every files protection type would be tedious, it’s defined regions as paths in the file where all files under such a region are of a set protection type, and the more specific a path is the higher priority would the protection type of such a path or region be.
Scone provides numerous advantages than just using the Intel SGX SDK, from greater side-channel attack security which is a troublesome issue for Intel SGX, to automation of attestation without need for extra coding.
2.7
InterPlanetary File System
Similar to torrent peer-to-peer technology, IPFS or interPlanetary file system allows for un-censorable websites by having a copy of the website replicated to many peer’s cache to assist in distributing the website instead of relying on only a central server.
This in turn allows for greater resilience against censorship, and higher up-time. It also fa-cilitates, as the name suggests, an interplanetary web as data for a website would need only to travel once the distance between two planets before being distributed between peer caches on the destination planet it traveled to, thus no longer needing high latency to view the website or data in question.
2.8
iExec
A customer in electronic commerce wants to make an order for a used car online, he wants to go through the regular procedure as he would on an intuitive user interface provided by a current top e-commerce platform, however he doesn’t want to give away sensitive information to 3rd parties if he can avoid it.
Towards a scalable utilization of smart contracts for a decentralized electronic trades platform, running large computations on smart contracts would have to be avoided as not only would it be costly for the user to run on the blockchain, smart contract enabled, platform but also wouldn’t be feasible for a large number of users running the same contract on the same blockchain platform as it would easily throttle, quickly rising fees to absurd levels as demand for space inside a block increased. Working on personal data on smart contracts would also compromise the customers data, as calls to smart contracts are public and completely transparent.
A great example where Ethereum suffered from the scalability limitation is when the animal
the application to cross cats and generate new digital cats put Ethereum under heavy load and thus raised fees tremendously.
There needs to be a way to execute the more computationally intensive parts of this DAPP and the parts demanding confidentiality, on an off-chain trusted system and return the result back on-chain. Not only that but during order execution there needs to be access to external world data in a secure as possible manner.
That’s where Trusted Compute comes in, by utilizing a distributed computing architecture where nodes working on the computations leverage trusted execution environments, such a those provided by Intel Software Guard Extensions. Hence, complex computations can be done off-chain on a distributed cloud computing architecture while preserving data privacy and connecting to external data sources to retrieve relevant external data. I found out that such a system is already
being worked on and big advances have been made. IExec [20] provides such a computation
service, and in this section we explain its inner workings.
While iExec is a work in progress, and a lot of development is still being done on it as of the time of writing this, it is the only company providing an open source stack for deployment of a decentralized cloud network, on Ethereum, with an economy entirely powered by a digital decen-tralized currency. Anyone can join iExec and sell their spare computing resources in exchange for a cryptocurrency named RLC, a decentralized non-governmental controlled digital currency. IExec is an Ethereum specific implementation of EEA’s Off-Chain Trusted Compute Specification,
similar to the TCF in Chapter2.3.
The economy of the iExec stack is powered by the cryptocurrency named RLC. This cryp-tocurrency is used in exchange for cash to buy and sell resources such as computing resources and data, these computing resources are what this project buys with RLC to perform off-chain computations.
iExec is a decentralized cloud computing platform and it currently offers a marketplace of worker pools, app and dataset providers on a pay-per-task basis. Payments are automated through the use of smart contracts and are made in the token of the iExec platform, the RLC token. Anyone can become a requester or a worker on the network, requesters must pay in RLC.
The iExec network is made up of workers, worker pools and the schedulers which manage these pools, app providers, dataset providers, requesters, the smart contracts deployed to Ethereum and the off-chain iExec-order marketplace.
The roles in the iExec network are the following:
1. The workers perform Tasks in exchange for the RLC token.
2. The worker pools are aggregations of workers managed by schedulers that compete for workers to join their pool through the efficient management of the pools.
3. App providers are the entities that publish applications for requesters to have run by workers pools. The app provider take a share of revenue from the execution of the application.
2.8 iExec 15
4. Dataset providers are entities that allow for the usage of their dataset in return for RLC. Their dataset/data is kept private through the use of TEEs.
5. Users pay for the execution of Tasks. A smart contract can be a user.
The iExec platform enables the monetisation of datasets like trained AI models, by having workers take inputs to these trained AI models and returning the output to the requester without compromising the trained AI model’s ownership. Since the AI models are used in trusted execution environments they remain private to the owner of the dataset, thus allowing for the monetisation of the dataset to anyone while retaining ownership of the dataset to the original owner.
IExec already has enterprise workers running nodes on their platform like those of Genesis
Cloud [21], a company which provides high performance GPUs, and requesters like the french
company EDF which run on iExec the GPUSPH application that needs high performance GPUs for use in running simulations.
To avoid bad workers publishing wrong results and penalising users, all agents involved in the
network follow what is called the Proof of Contribution [22] protocol. The protocol has the goal of
giving trust to users, of what the consensus algorithm deems to be the correct result. The protocol makes it so multiple workers execute a Task and then aggregates the results. Each worker has a reputation score which is impacted whenever the worker publishes a result, if the result matches the majority consensus then the worker’s score is incremented, otherwise if the result is deemed bad then the workers loses 1/3rd of their score.
The use of a PoCo protocol can be avoided if workers run applications in a Trusted Execution Environment such as Intel SGX, as there is no need for replication nor the PoCo’s consensus layer due to the application being run on an enclave. However, as discussed in an article published by
the iExec company ("Aren’t enclaves and PoCo contradictory?" [23]), the enclave technology is
not perfect as not only does the worker’s CPU need to support it, it also needs to be supported in the BIOS so few computers have it. It’s also important to mention that the Intel SGX technology
has been found to have vulnerabilities in the past [24].
An advantage of running applications in TEEs is that of additional privacy, if data is delivered to the the TEE in a privacy-preserving way, e.g. by encrypting the data with a secret key. This is
implemented using the Secret Management Service which is explain in the below Section2.8.7.
The SMS verifies that the indented program is running on the worker’s enclave before provid-ing a secret. However, to guarantee also that the worker doesn’t return a misleadprovid-ing result even after executing the correct program, a remote attestation is made between scheduler and worker.
Once an enclave is initialized by a worker, it generates a key pair inside it and the worker sends the public key to the scheduler of the worker pool through an authenticated channel. The scheduler verifies that the public key was generated inside the worker’s enclave through the IAS,
as shown in Fig. 2.2, and it registers the public key on the blockchain. When a worker executes
our DAPP’s off-chain component, it will sign the result with it’s private key, generated previously by its enclave, and it will send the result and the corresponding signature to the blockchain.
Figure 2.2: Remote attestation
Requesters can specify what level of trust they need to have that the result coming from the workers is valid. If the level specified is 0 then a worker of any score will deliver the result, otherwise if the level is higher then the reputation level of the workers also needs to be, this means more workers with higher score would need to execute the Task and aggregate results to determine the most agreed upon result.
Workers and schedulers must stake RLC to participate in the network. Bad behaviour from any of these actors results in a loss of stake. Also, to avoid Sybil attacks where any actor could create multiple workers to join a pool and publish bad results, there is a minimum stake of RLC and reputation that a worker must have.
The off-chain component running on workers can integrate information from oracles thus ex-panding greatly the use cases for decentralised applications. Since now developers can run the off-chain component of their decentralized application with full trust that the application runs as expected with encrypted input from the user and input from external off-chain data from oracles.
The following sections go into more detail on aspects of iExec.
2.8.1 Who Are The Users or Requesters
Requesters are whoever requests to run an application on the network. Requesters need to pay in RLC to run applications in the iExec network, the RLC is first locked during the execution. If consensus is achieved, the RLC is then distributed by the parties that contributed with the winning result. Otherwise, the RLC is unlocked and returned to the requester.
2.8.2 What Are The Accounts
Wallets and accounts are different concepts in iExec, as wallets are simply the key pair con-taining ETH or RLC in the Ethereum network, and accounts are what’s used to interact with the iExec network.
Accounts are managed by an escrow which is part of the IexecClerk smart contract running on-chain. Accounts are funded by wallets, and accounts hold RLC as either staked or locked.
When moving RLC from the wallet into an account, the RLC is initially stored as stake to be used in the iExec network. When the RLC in stake is used by a Task, then the RLC becomes locked until it’s either sent back to stake, e.g. if consensus is not reached (see below), or confiscated as payment or punishment.
2.8 iExec 17
2.8.3 What Are The Apps, Datasets and Workerpools
An app in iExec can be either the application code to execute in the platform, or an instance of the App contract on Ethereum provided by iExec for running that application code. The App contract instance has a link to a docker image with the application code that may be published to docker hub, or any other alternative.
Likewise, a dataset in iExec can be either a data to be used by some application, or an instance of the Dataset contract on Ethereum provided by iExec for access to the data set. The Dataset contract instance has a link to a file with the data set as well as a checksum of the data.
Finally, a workerpool in iExec can be either a pool of worker nodes to perform computations, or an instance of the Workerpool contract on Ethereum provided by iExec for the user to choose to run an application and workers.
2.8.4 What Are The App, Dataset and Workerpool Orders
In order to monetize applications, datasets and workerpools, iExec provides a way to publish offers, or otherwise referred to as orders, to an off-chain marketplace. Orders reference the app, dataset or workerpool by the address of their contract instances on Ethereum, and also state their usage conditions and provide a signature of the creator of these resources to prove their authentic-ity.
Order information is picked up by a requester through the use of the iExec SDK, so as to create a request by combination of orders. A request can, for example, use an order for an application, another for a specific dataset, and finally another order for the workerpool which will run the application. If all these orders cost 1 RLC, then the request costs 3 RLC total.
When the requester publishes the request, the orders are matched on the blockchain and the request is picked up by the scheduler of the workerpool specified in the workerpool order.
Each order has a limit for the number of times they can be used, known as volume. Every time an order is used, the volume is decremented by 1.
2.8.5 How a Task is Executed
In this section we describe the sequence of steps both on-chain and off-chain to run a Task whose app, dataset and workerpool orders have been uploaded to the off-chain iExec market.
2.8.5.1 The Deal Is Made
A Deal is a smart contract object, on Ethereum. Its creation is the first step in executing a Task, as a Deal needs to be established for execution of the Task. Deals are created by the IexecClerk smart contract instance.
While the orders for publishing applications, datasets, requests, and workerpool are stored in the off-chain iExec marketplace, they are signed off-chain by the responsible entities and therefore
the security of the off-chain marketplace can be guaranteed as the origin of the orders can be verified cryptographically by the signature of the in them.
The IexecClerk smart contract which is on-chain and has the security guarantees blockchain provides, verifies the origin of the orders from the off-chain iExec marketplace before matching them and creating the Deal object. When matching the orders, an Event, named ’SchedulerNotice’, is emitted from the smart contract which is watched by the scheduler of the corresponding work-erpool of the workwork-erpool order.
2.8.5.2 Workers Are Assigned
When the ’SchedulerNotice’ Event is emitted from the IexecClerk smart contract instance, it is watched by the scheduler of the workerpool mentioned in the Deal. Afterwards the scheduler calls ’initialize()’ from the IexecHub smart contract instance, which creates the Task smart contract object. Then the scheduler randomly assigns workers to work on the Task, the number of workers depending on the trust level designated by the requester. The Scheduler then signs a message containing the addresses of the assigned workers, Task id and the Ethereum address of the worker’s enclave, and sends this message to the workers through an off-chain channel.
2.8.5.3 Computation Is Made
Once the workers verify the signature was made by the scheduler, they begin fetching the data for the application (e.g. docker hub) and the dataset (e.g. IPFS), and begin execution. As input for the application, arguments can be passed to it and the application can also read input files from the previously configured input ’\iexec_in’ directory, and it outputs likewise to the ’\iexec_out’ directory. As output the application stores in stdout.txt the logs printed during the application’s execution, and all other output files are stored in the ’\iexec_out’ folder, these are then bundled in a ’result.zip’ file which can be downloaded once the Task is finished.
2.8.6 How Consensus is Established
Consensus over the result of an application run on the decentralized cloud by multiple workers is done on the blockchain. The results need to be deterministic so as to converse to a single true result.
Consensus is needed in case the requester opts for redundancy of workers executing the ap-plication, since a result needs to be agreed upon to be the correct one out of all results calculated by the different workers. Of course, if all workers act honestly and the application’s code is not erroneous, most if not all workers should reach the same result value.
There is also the case where requesters want workers to execute on TEEs, in which case opting for redundancy is not necessary, but still possible.
If consensus is not achieved, the requester is reimbursed and the locked funds return to the requester’s stake.
2.8 iExec 19
2.8.6.1 Consensus Is Achieved
To achieve consensus on the result, workers call ’contribute()’ from IexecHub contract in-stance, providing as parameters a hash of result and a seal of the result. The hash of the result is the hash of both the Task ID and the result digest. The seal of the result is the hash of the worker’s Ethereum address, the Task ID, and the result digest. The consensus on the correct result is established by the hash of the result, where the majority vote wins.
Once all workers have provided both the hash of result and a seal of the result as described before, the workers now call the ’reveal()’ with the parameter being the digest of the result which is the hash of the ’\iexec_out’ and ’stdout.txt’ files. Now by hashing the digest together with the Task ID and the worker’s Ethereum address, and comparing the resulting hash with the previously given seal hash, the worker can prove to the IexecHub contract instance that it knew of the digest before providing it, and thus did in fact contribute. In case the application is non-deterministic, or in other words doesn’t always reach the same state after execution, then a ’\iexec_out\determinism.iexec’ file must be created by the worker with a deterministic result, this file overrides the digest of the result folder.
Finally, by calling ’finalize()’ from the IexecHub contract instance, the workers can get payed. If it was a contract object that initiated the request then a callback function of said contract is called.
2.8.6.2 Bad behaviour Is Penalized
Workers and schedulers must also stake a minimum amount of RLC to participate, so that bad behaviour, such as returning a false result, is punished by the loss of this stake.
2.8.7 How Permissioning Works
The IExec’s Secret Management Service (SMS) is used to store encryption keys for datasets, and provide said keys to applications which have authorization to read the keys during their exe-cution inside secure Intel SGX enclaves, so that these applications can decrypt the dataset and use it during the execution of the application while maintaining the secrecy of the dataset as the TEE isn’t supposed to leak any memory even to the host executing the application.
Before the user pushes a secret of their encrypted dataset to iExec’s SMS, they verify the SMS’s enclave certificate, as it is attested by the IAS, to know that the SMS is running the correct open-source SMS program. However if the user wishes to, they can run their own Secret Man-agement Service running a modified version of the open-source SMS program that could add an additional layer of security.
When the worker’s TEE needs a secret to decrypt a dataset, it establishes a secure channel with the Secret Management Service, which verifies that the actual software is running inside the enclave of the worker.
2.8.8 iExec Oracle
Oracles are a vital part of this project, since for the validation of client information there needs to be calls to external APIs, and the data returned by these APIs needs then to be exposed to the blockchain smart contracts. Oracles in the cryptocurrency space are essentially systems outside of the blockchain that allow outside data to be fed to the blockchain.
With oracle systems special care needs to be taken for calls to be done in a secure trustworthy manner as they present an attack vector for decentralized applications that use this external data because data from outside a blockchain cannot be trusted in the same manner as the data stored inside the blockchain and the process used to bring data on-chain needs to be secure. If done incorrectly, false data can enter the blockchain and potentially be used in smart contracts thus tricking it to execute using false data, eroding the trust on the smart contract.
Use of Oracles in iExec affects several steps in the execution of an iExec application: 1. Creating a request from a smart contract
Smart contracts live on the blockchain. To initiate the oracle process, the smart contract needs to advertise the need for data external to the blockchain.
2. Workers execute application that makes API calls to data source
Once the scheduler detects a request from the blockchain, it will assign it to workers, from its workerpool, to execute the application which makes API calls to external data sources. 3. Smart contract’s callback function is called with the application’s result, possibly
deter-mined by running consensus.
After consensus on the off-chain application’s execution by the workers is established, the callback of the on-chain contract will be called in a transaction, with the results from the application’s API calls to the external data sources.
Proof of Contribution protocol establishes consensus on the application’s result through the use of blockchain. By running the application on different workers, the system is more resilient to rogue workers.
However, the system is still vulnerable to the rogue data sources. Indeed the use of a single data source requires the application to trust in that data source. So security can be further improved with the help of redundant data sources and the use of some voting mechanism.
Chapter 3
Application
Let’s say a seller wants to sell a used car online, without the hassle of setting up a website, by using one of the e-commerce platforms already available. The seller wants to make the most profit possible. He searches and finds many platforms which pay middlemen to serve as service providers for hosting and providing the infrastructure for payment, shipping, promotions, vouchers and other functionalities. The problem is that the seller will have to pay a minimum of 15% as fee for each product sold on these platforms and this would be especially costly for expensive products. This work presents an application that the seller can use to sell the used car and not have to set up the store website, paying for hosting and services involved or even paying middleman absurd fees to abstract these complexities.
This application provides an e-commerce alternative which doesn’t need to place trust in any central entity to keep private information secure, by leveraging decentralization through blockchain together with Trusted Compute.
The user is met with an interface enabling the user to sell and buy products, much like Amazon or other e-commerce solution, but in decentralized application. The website itself wouldn’t be hosted by a centralized entity but rather have it’s contents hosted in a decentralized way. As the application is meant to be decentralized and not rely on any central authority or single point of failure, the website’s contents for which to access the DAPP, also needs to be stored and hosted in such a decentralized way.
By using IPFS to host the website, each user who downloaded the website and used it would
then have the website cached on their1computer and this cached version potentially shared with
other users as a node in the network if they so wished to, thus users of the platform would them-selves proliferate the website’s interface files among the entirety of the user base of the platform. The website could then be accessed through a URL provided by Unstoppable Domains, a technol-ogy which uses blockchain to store records.
At the back-end there would need to be a database, as we can’t rely on a centralized entity to provide one we would need a sort of decentralized database where peers in the network would all host a record of the database to be incrementally updated with new data and synced with all other
1They/them/their was used as a singular and-or gender-neutral pronoun.
