5 Technology on Ethereum
The simplest way to describe Bitcoin is to say that it is cryptocurrency or digital money. Bitcoin was released in January 2009, so for approximately nine years it has been used to transfer money in a peer-to-peer blockchain network. There is no central or world bank entity that controls the flow or functionality of Bitcoin; it is a decentralized digital currency. When compared to Bitcoin, Ethereum differs mainly in that it adds the functionality of the smart contract to its base cryptocurrency, known as ether. What does smart contract mean? Well, think of it as digital money that has logic associated with it. A smart contract can be set up to transfer value from one entity or account to another, and to do this if—and only if—certain conditions are met. Here’s an example. Suppose you want to purchase a piece of real estate from someone. For those of you who have had the privilege of doing this, you know that there are almost too many third parties involved in the purchase, including real estate agents and brokers, lawyers, title searchers, home inspectors, surveyors, mortgage banks, and escrow agents. These external parties are what typically make the process incredibly slow and, of course, add cost. An Ethereum solution would have logic (or code) that could automatically transfer the ownership (title) from seller to buyer and the funds from buyer to seller after a deal is agreed upon in a far simpler way without needing as many third parties involved. See Table 5-1 for more Ethereum to Bitcoin comparison items.
TABLE 5-1 Comparison of Ethereum to Bitcoin (Source: bitinfocharts.com)
Ethereum was created to serve as a platform for building blockchain-based, or decentralized, applications. It is developed by the Ethereum Foundation, a Swiss nonprofit, with contributions from great minds around the globe. Ethereum is well positioned for applications that need to be built quickly and that interact efficiently and securely in a blockchain ecosystem.
Ethereum uses blockchain technology, which is a transaction record that is independently verified by others and held on a distributed ledger. The same technology underpins Bitcoin. However, the Bitcoin blockchain is predominantly designed to do one thing: facilitate Bitcoin transactions. Ethereum, on the other hand, is designed to act as a programmable infrastructure. This means that Ethereum is a more adaptable and flexible development platform.
The Ethereum platform is often referred to as a Turing-complete virtual machine built upon the foundational functionality of blockchain. Ethereum allows one to construct smart contracts and applications with their own arbitrary rules for ownership, transaction formats, and state transition logic. A bare-bones version of a value application can be written in two lines of code, and other protocols such as currencies and reputation systems can be built in under twenty.
Ethereum has its own token, called ether, which provides the primary form of liquidity allowing for exchange of value across the network. Ether also provides the mechanism for paying and earning transaction fees that arise from supporting and using the network. Ether has been the subject of speculation, and, as with Bitcoin, the price of ether has seen wide fluctuations. In the past two years, the price per ether ranged from US$10 to over US$400. It’s now back to around US$300, but it has shown classic speculative characteristics. It is worth noting that ether is the financial incentive that pushes and fosters decentralization (and attracting miners), which makes the platform more secure.
Ethereum contains smart contracts. A smart contract is simply any agreement that can execute certain functions without human intervention. A smart contract in Ethereum is a cryptographically secured box containing logic and value. The logic has specific conditions that have to be met in order to release the value. It is the addition of logic and state that makes Ethereum a more powerful platform than what is available with other cryptocurrencies, including Bitcoin (and its scripting functionality). An example of a smart contract for insurance could automatically pay out to the insured entity based on a data feed showing that a payable event had occurred.
Smart contracts enable decentralized applications (dapps). Centralized applications are really centralized services. For example, when we interact with a third-party app on our smartphone, the app will communicate with centralized servers and services. A dapp can look exactly the same in terms of the user interface, but the backend services are replaced with smart contracts that run on the decentralized Ethereum network.
Ethereum also has decentralized autonomous organizations (DAOs). A DAO is a new form of entity or organization that can, for example, replace articles of incorporation and shareholder agreements with smart contracts.
Dapps and DAOs can also have their own digital tokens that serve a variety of functionality by acting as an internal currency. The development of dapps and DAOs is now being funded by selling these digital tokens in what is known as a token sale or an initial coin offering (ICO).
Ethereum Accounts
Within Ethereum, the current state is made up of objects that are commonly called accounts. The internal fuel on Ethereum is ether, and it is used to pay transaction fees (more on this later in the chapter). Ethereum can be viewed as a transaction-based state machine, starting with the genesis state and incrementally executing transactions that morph the state into a final state. The final state is what is considered the canonical “version” of the world of Ethereum. The state includes anything that can currently be represented by a computer, such as account balances, reputations, trust arrangements, and data representing information in the physical world. Transactions therefore represent a valid transition between two states. Each account within Ethereum has a 20-byte address (or identity) and the object is made up of four attributes or fields, which are:
• Nonce Counter that is used to ensure each and every transaction can be processed once and once only
• Ether balance The account’s current value
• Contract code An optional container for logic
• Storage Empty by default
There are two types of accounts, externally owned accounts (EOAs) and contract accounts. EOAs, also known as normal accounts, have an ether balance, contain no logic, and are controlled by private keys. Contract accounts also have an ether balance but are controlled by their accompanying contract code (logic). All action on the Ethereum platform is set in motion by transactions fired from externally owned (normal) accounts. An externally owned account sends messages by creating, signing, and submitting a transaction. When a contract account receives a message, its code activates and executes as instructed by the input parameters of the transaction. The code (or logic) can read and write to the internal storage and send additional messages or create contracts. The use of the term contract in Ethereum should not be confused with its typical everyday use such as needing fulfillment, completion, or compliance per se. It is used to indicate logic bound inside the Ethereum execution environment that is executed in a defined way (by contract) when “poked” by a message or transaction (more on transactions later in this chapter), and that controls its internal state (variables), which includes its ether value.
Ether the Cryptocurrency
Ether (ETH) is the name of the cryptocurrency that fuels the distributed application Ethereum platform. It is used as the form of payment made by the clients of the network to the actual machines that execute the requested tasks. As we mentioned earlier, ether is the financial incentive that pushes and fosters decentralization and therefore attracts miners. Additional miners make the platform more secure and viable. Ether is also the incentive ensuring that quality applications are created, because inefficient code will usually cost more, and that the network remains highly available and functional, because owners are compensated for their contributed resources (computing power and storage).
As with a fiat currency, ether comes in size denominations that have their own name, shown in Table 5-2.
TABLE 5-2 Ether Denominations
In short, ether has two purposes: it is used to pay the fees associated with a transaction, and it provides the Ethereum platform with the liquidity to exchange value between the types of digital assets housed on the platform.
Genesis Block
Ether (ETH) was first issued in order to get the Ethereum project and platform launched and off the ground. The launch of the platform used the crowdfunding approach and took bitcoin in exchange for ether. The fundraising started in mid-2014 and approximately 60 million (actually 60,102,216 ETH) ether units were issued at the price of 1,000–2,000 ether per bitcoin (BTC). Of the total amount sold, 9.9 percent were allocated to the organization to compensate early contributors and pay ETH-denominated expenses before the genesis block on July 30, 2015. Another 9.9 percent of the total amount sold will be maintained as a long-term reserve. This means that the total amount released prior to the launch was close to 72 million. The bitcoin received from the sale was used to pay salaries/bounties to developers and invested into various for-profit and nonprofit projects in the blockchain ecosystem.
Post-Genesis Block
Once the Ethereum platform was launched, the way to issue ether was defined and set in order to secure the future success and health of the platform. It was defined that the ether units to be released per year will be 26 percent of the initial 60 million raised during the fundraising phase. Ether is issued at a rate of 5 ETH per block on a blocktime target of 12 seconds. This means that the amount of ether released per year will be a constant 15.6 million ether units, and so by July 2020 around 52 percent of the total currency issued will have been mined. See Figure 5-1 for a depiction of the issuance model (at launch) at per year for the first five years.
FIGURE 5-1 Ether (ETH) issuance model
The issuance model for ether is similar to bitcoin, where the inflation is front loaded into the first few years and deflation occurs down the road. The big difference is that bitcoin is capped and no further issuance will occur. This may not matter as much given the Bitcoin Cash (BCC) spinoff, but with ether there will continue to be an issuance of 15.6 million units each and every year, which is marginal but nonetheless an increase in the fuel supply.
Obtaining Ether
There are multiple options to obtain ether, the fuel that drives transactions in Ethereum. You can
1. Buy it
2. Mine it
3. Accept it as payment
In terms of mining, this can be done within a private environment or on the public test network (testnet). This is simple enough, but to mine within the production live environment (mainnet) requires significant dedicated GPU time and horsepower set up locally and connected to the Internet or to similarly powerful infrastructure available in the cloud (e.g., AWS, GCP, Azure, etc.). To purchase ether you will need to get it via an exchange. As different regions have different exchanges, you will need to perform a search in order to find the latest and greatest information on the best exchange for you.
Mining in Ethereum
The Ethereum blockchain is similar to the blockchain for Bitcoin. The main differences are in the design of the blocks. The Ethereum blocks contain a copy of both the transaction list and the most recent state (see Figure 5-2). The Ethereum blocks also contain values for the block number and the difficulty.
FIGURE 5-2 Ethereum blockchain transaction list and state
In its basic form, the Ethereum validation algorithm is as follows:
1. Check the following:
• Prior block reference exists and is valid.
• Timestamp of the current block is later than the prior block referenced and also less than 15 minutes later than the prior block timestamp.
• The block number, difficulty, transaction root, uncle root, and gas limit are valid.
• The proof-of-work on the block is valid.
• If any of the above is not true, then return an error.
2. Set the zero-index state (i.e., S[0])equal to the state at the end of the previously referenced block.
3. Set TX list equal to the block’s list ofn transactions. Loop through the transaction list and apply the transaction to the appropriate state, i.e., for all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). If any call to APPLY returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error.
4. Set S_FINAL equal toS[n], but adding the block reward paid to the miner.
5. Verify that the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.
It is important to note that while it looks like the entire state is stored with each block—an inefficient use of storage—this isn’t so in reality. The states are stored in a tree structure, and after every block only a minority of the tree needs to be changed. Typically between two adjacent blocks the majority of the tree will be the same, and an optimization opportunity and technique is utilized. The data can be stored once and referenced twice using pointers (i.e., hashes of subtrees). This concept and approach with a tree is known as a Patricia tree. This combined with a modified Merkle tree allows for nodes to be inserted, deleted, and changed very efficiently. On the storage front, because all of the state information is part of the last block, there is no need to store the entire blockchain history, which results in a 5–20x savings in space when compared to the approach that Bitcoin uses.
A frequently asked question is where or when the code contained in a contract gets executed. The answer is that the execution of contract code is part of the definition of the state transition function (see later in this chapter), which is part of the block validation algorithm. Therefore when a transaction is added into a block, the code execution spawned by that very transaction will be executed by all nodes when they download and validate that same block.
GHOST Implementation
The Greedy Heaviest Observed SubTree (or GHOST) protocol was introduced in 2013 to blockchain platforms to combat the way that quick-blocktime blockchains, like Ethereum, suffer from a high frequency of stale blocks. Stale blocks are those that were propagated to the network and verified by some nodes as being correct but are eventually discarded because later, chronologically speaking, blocks get mined and propagated before the earlier ones do.
The GHOST protocol also combats the issue known as centralization bias—an example of which is, if miner X is a mining pool with 35 percent hash power and miner Y has 15 percent hash power, miner X will have a risk of producing a stale block 65 percent of the time and miner Y will have a risk of producing a stale block 85 percent of the time. So, if the block interval is short enough for the stale rate to be high, miner X will be substantially more efficient than miner Y simply by virtue of their pool size. In other words, the larger the pool and the smaller the block interval, the more often they are going to get a head start on other miners by producing the block themselves and then immediately starting the race for the next block.
With these two effects combined, blockchains producing blocks very quickly are highly likely to lead to a consolidated mining pool with a large enough percentage of the network hash power to take over the mining process. In Bitcoin, the probability of finding a block at the same time is more likely because the blocktime is 10 minutes and propagating a block to 50 percent of the network takes approximately 12 seconds. But in Ethereum, which has a much shorter blocktime (the target being 12 seconds), there is a need to reduce the incentive for pooled mining. This is where GHOST comes in.
GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the “longest.” So the longest chain does not just take into account the parent and further ancestors of a block, but also the stale descendants of the block’s ancestors (“uncles”) are added to the calculation of which block has the largest total proof-of-work backing it.
GHOST solves the second issue of centralization bias by providing block rewards to stales. In Ethereum a stale block receives 87.5 percent of its base reward, and the nephew (child of the uncle) that includes the stale block receives the remaining 12.5 percent. Transaction fees, however, are not awarded to uncles.
The Ethereum version of GHOST is a simplified version that only goes down (or back) seven levels of the block chain.
• A block must specify a parent and its number of uncles (zero or more).
• An uncle included in a block must have the following properties:
• It must be a direct child of the new block and less than seven blocks below it in terms of height.
• It cannot be the direct ancestor of the block being formed.
• It must be a valid block header; it does not have to be a pre-verified or even a valid block.
• It must be different from all uncles included in previous blocks and all other uncles included in the same block (non-double-inclusion).
• For every uncle included in the block, the miner gets an additional 3.125 percent and the miner of the uncle receives 93.75 percent of a standard block reward.
This restricted version of GHOST (uncles includable only back seven generations) is used in Ethereum for two reasons. First, having an unlimited number of levels would include too many complications into the calculation of which uncles for a given block are valid. Second, unlimited levels with compensation removes the incentive for a miner to mine on the main chain as opposed to the chain of a malicious actor.
How Fees Protect
Every transaction that is published to the blockchain needs to be downloaded and verified by the network nodes. This feature (or burden) needs to be regulated in some way to prevent waste and abuse. In Bitcoin, the default approach is to have voluntary fees, where the miners set minimum fees and act as the gatekeepers. This market-driven approach uses the supply of miners and demand of transaction senders to make a market for the fee. But the issue here is that transaction processing on a blockchain is not a true market because it is not as simple as a single miner providing a transaction-processing service to a single sender. In actuality, every transaction that the miner includes in a validated and committed block needs to be processed by every node in the blockchain network. This means that the majority of the cost of processing a transaction is spread to the whole network, while it is the miner that makes the decision to include it or not that gets the reward.
Mining Issues
The mining algorithm in the Bitcoin network has the verifying nodes (miners) compute a SHA256 calculation on slightly modified versions of the block header. Simultaneously repeating this calculation millions of times over and over again, eventually one miner comes up with a version whose hash is less than the target. This presents a vulnerability to two forms of centralization. Let’s examine this further.
Centralization The first issue is that the hardware that the miners used became dominated by ASICs (application-specific integrated circuits). These are computer chips designed to be much more efficient at Bitcoin mining. By definition this stopped making mining a level playing field and meant that it became necessary to invest higher amounts in order to buy these specialized chips in order to compete. The second issue is that most Bitcoin miners do not actually perform block validation locally; they use a centralized mining pool to provide them with the block headers. The word “centralized” in the mining pool name should give it away, but in any case there is potentially a much worse problem than the specialized chip issue. The top three mining pools are all in China, and they indirectly control roughly 50 percent of processing power in the Bitcoin network. The miners still have the ability to switch mining pools, and this does present a mitigation strategy in the event of collusion when a pool or coalition attempts a 51 percent attack.
Ethereum Handles Centralization Ethereum is set up to use an algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the prior N blocks in the blockchain, and return the hash of the result. This has a couple of benefits. First, smart contracts can include any kind of computation, so an Ethereum ASIC would essentially be a CPU for general computation, or GPU. Second, mining in Ethereum requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction. This more importantly removes the need for centralized mining pools and the risk and issue of centralization.
Ethereum Work
Ethereum has essentially one way for work to begin and that is via a transaction. A transaction in Ethereum is a cryptographically signed data packet that contains a message sent from an externally owned account. Let’s take a closer look at the transaction and message objects.
Transactions
There are essentially three types of transactions that can be found on Ethereum:
• A transfer of value from one entity to another
• The creation of a smart contract
• The invocation of a smart contract
A transaction is made up of attributes, or fields, which are:
• From A signed address for the sending account. It is signed in order to prove that the sender intended to send the transaction to the recipient.
• To The destination address of the transaction, this is left undefined for a transaction that creates a contract.
• Value The amount of value to be transferred (always expressed in wei). For a transaction that creates a contract this field will typically hold the endowment.
• Gas This is sometimes referred to as the Start Gas field. It is the amount of fuel to use for the transaction and represents the maximum number of computational steps for the transaction. Any unused fuel will be refunded to the sender. See more on this field below.
• Gas Price The price of gas for this transaction (specified in wei—more on this later in the chapter). This defaults to the mean network fuel price and represents the fee the sender pays per computational step. See more on this field below.
• Data This can be omitted or defined as a byte string containing data for the message. For a transaction that creates a contract, this may contain the initialization logic.
• Nonce This can be used to overwrite pending transactions that use the same nonce.
As you can see, the first three fields are those that are needed for any financial transaction that transfers value. The Data field has many purposes depending on the type of transaction—as we’ve already mentioned this can be initialization logic or data. It all depends on what is needed to fulfill the transaction.
Network Fuel (Gas)
In order to process transactions there needs to be sufficient fuel (ether) in the account from which the transactions are being sent. Ether is needed to pay the execution cost for the Ethereum client that performs the transaction work on behalf of the sender, committing the result to the Ethereum blockchain.
Interestingly, it is the Gas and Gas Price attributes on the transaction that are key components to the denial-of-service (DoS) prevention design built into the Ethereum network. To combat infinite loops or computational waste (whether intentional or not), each transaction is required to specify a limit to the number of computational steps a transaction can take to complete. The unit of computation in Ethereum is known as gas, and each operation in Ethereum has an associated gas cost that depends on how intensive it is from a computing power perspective (see Table 5-3 for the gas cost associated with the majority of Ethereum’s opcodes/instructions).
TABLE 5-3 Ethereum Opcode (Instruction) Cost
Some operations cost higher amounts of gas simply because they are computationally resource intensive. In addition to compute power fee, there is also a fee of 5 gas for every byte in the transaction data. As we’ve stated earlier, the intent of the fee structure in this model is to ensure that senders pay proportionately for every resource consumed, be it computation, bandwidth, and/or storage. So it stands to reason that resource-intensive contracts and messages must have an appropriately proportionate gas fee.
Messages
An Ethereum contract has the ability to send a message to another contract (it can do this multiple times). A transaction initiated by an externally owned account can contain values in the Data field that will go into a message. Within Ethereum a message is a virtual object that is never serialized per se and exists within the execution environment only. It is made up of the following fields:
• Sender The sender of the message (implicit)
• Recipient The recipient of the message
• Amount The amount of ether to transfer alongside the message
• Data (optional) An optional data field
• Start Gas A value
As you can see, essentially a message is very similar to a transaction. The difference is that it is produced by a contract and not an external actor (although it can be caused by one). When the code inside a contract executes and calls the CALLopcode function, it creates and executes a message. Similar to a transaction, the message is sent to the recipient account running its code. So you can see that contracts can interact with other contracts the same way that external actors accounts can. An important thing to note is that the gas allowance specified by a contract or transaction is the governing amount for the transaction and any and all dependent executions. So, for example, if account A sends (commits) a transaction to account B with 100 gas, B performs operations that consume 70 gas and then sends a message to C. C then performs operations that consume 25 gas before returning. Then B can use another 5 gas before running out of fuel (Out-of-Gas exception).
The Ethereum Block
The block in Ethereum is the collection of relevant pieces of information (known as the block header), H, together with information corresponding to the comprised transactions, T, and a set of other block headers, U, that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
Below are the fields that exist in the block header:
• parentHash The Keccak 256-bit hash of the parent block’s header, in its entirety; formally Hp.
• ommersHash The Keccak 256-bit hash of the ommers list portion of this block; formally Ho.
• beneficiary The 160-bit address to which all fees collected from the successful mining of this block are transferred; formally Hc.
• stateRoot The Keccak 256-bit hash of the root node of the state trie (Merkle Patricia Tree or radix tree), after all transactions are executed and finalizations applied; formally Hr.
• 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; formally Ht.
• 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; formally He.
• logsBloom The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally Hb.
• difficulty A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block’s difficulty level and the timestamp; formally Hd.
• number A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally Hi.
• gasLimit A scalar value equal to the current limit of gas expenditure per block; formally Hl.
• gasUsed A scalar value equal to the total gas used in transactions in this block; formally Hg.
• timestamp A scalar value equal to the reasonable output of Unix’s time() at this block’s inception; formally Hs.
• extraData An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally Hx.
• mixHash A 256-bit hash that proves, combined with the nonce, that a sufficient amount of computation has been carried out on this block; formally Hm.
• nonce A 64-bit hash that proves, combined with the mix-hash, that a sufficient amount of computation has been carried out on this block; formally Hn.
The other two components in the block are simply a list of block headers (of the same format as above) and a series of the transactions.
State Transition Function (STF)
As with Bitcoin and other cryptocurrencies, the ledger of Ethereum is essentially the result of a state transition function (STF), which takes the state of the network prior to a transaction and, upon executing the transaction, produces a new state as the result. See Figure 5-3 for a graphical depiction of Ethereum state transition function.
FIGURE 5-3 Ethereum state transition function (STF)
The specifics of the Ethereum STF (i.e., APPLY(S,TX) -> S’) are as follows:
1. Check the following, and if any are not true, then return an error:
• Transaction is well-formed and has the correct number of values.
• Signature is valid.
• Nonce matches the nonce in the sender’s account.
• If any of the above is not true, return an error.
2. Calculate the fee for the transaction as Start Gas * Gas Price, and derive the sender’s account address from the signature. Subtract the calculated transaction fee from the sender’s account balance and increment the sender’s nonce. In the event that there is an insufficient amount in the sender’s account, return an error.
3. Initially set Gas equal to Start Gas, and take off a certain quantity of gas per byte to pay for the bytes in the transaction (this is the storage fee).
4. Transfer the transaction value from the sender’s account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract’s code either to completion or until the execution runs out of gas (Out-of-Gas exception).
5. If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner’s account. Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.
Now let’s work through an example. Suppose that a contract’s storage starts off empty, and a transaction is sent with 10 ether value, 4,000 gas, 0.001 ether gas price, and 32 bytes of data, with bytes 0–15 representing the number 4 and bytes 16–31 representing the string “KITTEN-AND-WOLF”. The process for the state transition function in this particular example is as follows:
1. Check that the transaction is valid and well formed.
2. Check that the transaction sender has at least (4,000 * 0.001) 4 ether. If it does, then subtract 4 ether from the sender’s account.
3. Initialize gas = 4,000; assuming the transaction is 120 bytes long and the byte fee is 5, subtract 600 from the gas, and that will leave 3,400 gas remaining.
4. Subtract 10 more ether from the sender’s account, and add it to the contract’s account.
5. Run the code. The code checks if the contract’s storage at index 4is used; if it is available, it sets the value to KITTEN-AND-WOLF. Imagine this takes 1,177 gas, so the remaining amount of gas is 3,400 – 1,177 = 2,223.
6. Refund (2,223 * 0.001) 2.223 ether back to the sender’s account, and return the resulting state.
If there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided Gas Price multiplied by the length of the transaction in bytes, and the data sent with the transaction would be irrelevant. It is important to note that messages work the same way as transactions in terms of reverting—that is, if a message execution runs out of gas, the message’s execution and all dependent executions triggered by the execution will revert, but the parent executions do not need to. This makes it okay for a contract to call another contract, so if X calls Y with F gas then X’s execution is guaranteed to lose at most F gas. For the CREATE opcode, which is used to create a contract, its execution process is similar to the CALL opcode, except that the output of the execution determines the code (logic) of a newly created contract.
Code Execution
The EVM code that is contained in Ethereum contracts is a low-level, stack-based bytecode language. The code is a series of bytes that represent operations. Typically, code execution inside the EVM is an infinite loop of carrying out the operation at the current program counter (i.e., index beginning at zero) and incrementing this counter by 1 until one of three things happens: end of code, an exception, a STOP or RETURN instruction is encountered. While the operation is executing, it has access to four areas for reading and in most cases storing of data:
• Stack This utilizes the LIFO (last-in-first-out) principle. Data is pushed to the top of the stack or data is popped from the top of the stack. This is reset when computation ends.
• Memory This is an infinitely expandable byte array. This is reset when computation ends.
• Storage This is the contract’s key/value store. This persists when computation ends.
• Other The executing code can read the value, sender, and data of the message. It can also access the block header data and optionally return a byte array.
The EVM execution model is straightforward. While EVM is running, its complete computational state can be defined by the following tuple (collection or row) of data:
block_state, transaction, message, code, memory, stack, pc, gas
where block_state is the top-level or global state containing all accounts, including balances and the storage. At the beginning of every step of execution, the current instruction is found by taking the pc (Program Counter) byte of code(or 0 if pc is set to a value greater than the length of the code item), and each opcode (or instruction) has its own definition in terms of how it operates on the tuple. For example, the ADDoperation pops two items off the top of the stack, adds them together, and pushes their sum value to the top of the stack. It then reduces gasby 3 and increments pcby 1, and SSTORE(save word to storage) pops the top two items off the top of the stack and inserts the second item into the contract’s storage at the index specified by the first item. It then reduces gasby 20,000 and increments pcby 1.
Turing Complete
The Ethereum virtual machine (EVM) is said to be Turing complete. What does that mean? It means that the EVM code can encode any conceivable computation and this includes looping. There are two ways that the EVM code can loop. The first way the EVM can loop is via two direct instructions: JUMP, which allows the execution to jump back to a previous location in the code, and JUMPI, which allows the execution to carry out conditional jumping (using if/then/else or while statements). The second way the EVM can loop is through recursive calls. For example, contract A can call contract B, which in turn calls contract A, and so on. This presents a problem whereby a malicious actor on the network can effectively shut down nodes and the network’s associated mining by deploying contracts that contain logic that executes infinite loops. This issue is known in computer science as the halting problem, which is the inability to determine whether the program will finish running or continue to run forever. Ethereum deals with this issue using simple economics. When a transaction is committed to the blockchain, it contains a field, Gas (or Start Gas), that specifies the maximum number of computational steps that the transaction is allowed to take. Once this threshold is exceeded the computation is reverted, but the fees are still paid to the miner. The same mechanism is in place for messages. Let’s work through some malicious actor scenarios to see how the design of the Ethereum platform handles them.
• The malicious actor builds and deploys a contract that contains an infinite loop. They send a transaction that activates the loop. The miner processes the transaction, which kicks off the infinite loop. Even though it runs out of gas and stops before completing fully, the transaction is still considered valid from the miner’s perspective, and they claim the fee from the attacker for each computational step.
• The malicious actor again tries to create a very long infinite loop forcing the miner to keep computing for a long time. By the time computation finishes, more blocks will have come out, and it will not be possible for the miner to include the transaction in the block they are processing in order to claim the fee. This is where the Start Gas field, which limits the number of computational steps an execution can take, will be need to be set sufficiently and unusually high, giving the miner sufficient clues to the malicious intent of the transaction and a chance to reject it.
• The malicious actor reviews contract code that is something like:
send(A, contract.storage[A]); contract.storage[A] = 0;
The malicious actor sends a transaction with enough gas to run the first step only—in other words, to withdraw an amount. But the part that sets the amount to zero does not execute. The network (and specifically the contract author) does not need to be concerned about handling and protecting against such assaults, because when the transaction runs out of gas, the changes will be reverted. Note that the miner will still get paid the gas that was used to process the first instruction, so the malicious actor still pays.
• A contract is created and deployed to work in the following way. It references seven data feeds and takes the average data value of the seven as a way to calculate a risk factor. A malicious actor finds a way to compromise one of the seven data feeds and changes its functionality so that it runs an infinite loop instead, the idea being to force any attempts to calculate a risk factor from the contract to run out of gas. However, the Ethereum feature of being able to set a gas limit on the message will prevent this scenario from causing a problem. Note that the function that combines the seven values into an average will still need to deal with one or more feeds from failing to respond and act appropriately.
In short, the halting problem and associated Turing completeness are surprisingly easy to manage with the Ethereum design and architecture.
Scalability
There is a concern about the scalability of the Ethereum platform. After all, it is based on blockchain, and the design is such that it has to replicate transactions and blocks to every node in the network, so just how scalable can it be? Let’s recap on what scalability is. It’s the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth. At the time of writing, the Bitcoin blockchain size is around 159 GB and can grow by 1 MB approximately every 10 minutes. If the Bitcoin network had to process one of the major credit card companies’ number of transactions it would potentially grow by 1 MB every 3 seconds or approximately 1 GB per hour or 8 TB per year. Each node would need to have some serious resource capabilities in order to process that amount of data at the speed necessary to handle the requests. The Ethereum blockchain size is 57 GB and would also suffer from the same growth pattern. It would be even more complicated by the fact that Ethereum is an application platform containing applications and code and not solely a cryptocurrency. Ethereum has some relief in that the full nodes only need to store the state and not the complete history. However, this relief is combined with a huge increase in blockchain size, so you will start to see fewer and fewer full nodes and more and more simplified payment verification (SPV) nodes, increasing the risk of centralization. The risk is that the full nodes could collude and cheat the platform by adjusting the reward in their favor. The SPV (or light) nodes would not detect the issue immediately. Aside from the spinoff of Bitcoin Cash (BCC), there are a few suggestions on how to alleviate the future scaling issue for Bitcoin. For the Ethereum platform, there are two strategies in place to help deal with the issue of scaling. First, because of the mining algorithm every miner is forced to be a full node. Second, after processing each transaction, an intermediate state tree root is saved to the blockchain. In the event of a centralization event, as long as there is a single honest miner on the network the issue can be addressed via a verification process. So if a malicious miner publishes an invalid block, the verifying node would run the same computation and see that the state generated does not match the state provided and reject the transaction.
The switch to Casper, a proof-of-stake (PoS) consensus algorithm, is also said to improve, among other things, the scalability issues that are associated with the current proof-of-work (PoW) consensus approach. In PoW-based blockchains, the consensus algorithm rewards nodes that solve cryptographic puzzles. The winning miners validate transactions and create new blocks. In PoS-based blockchains, a set of validators take turns proposing and voting on the next block, and the weight of each validator’s vote depends on the size of their stake (or deposit). This PoS approach is said to be advantageous over PoW in terms of security, a reduced risk of centralization, and energy efficiency.
Infrastructure: Storage and Communication
At their core, all successful computer platforms need to calculate, persist, and communicate data in the most efficient and secure manner. The Ethereum Virtual Machine (EVM) covers the calculate (or compute) aspect, so let’s take a look at what is used for persistence and communication.
• Decentralized file storage (persistence) Swarm is peer-to-peer (p2p) file sharing that is paid for with micropayments of ETH. Within Swarm, data files are broken down into chunks, distributed, and stored across the network participating nodes. The applications and smart contracts that need to store and retrieve data compensate the nodes that persist and serve the data.
• Communication Whisper is an encrypted messaging protocol allowing nodes to send messages directly to each other while hiding the sender and receiver and the message from third-party snoopers.
INFURA
INFURA is a scalable, standards-based, globally distributed cluster and API endpoint for Ethereum, IPFS (InterPlanetary File System), and other emerging decentralization infrastructures. Its mission is to provide secure, stable, robust, balanced, fault tolerant, and easily scalable Ethereum and IPFS nodes. In essence, INFURA is a shared infrastructure layer acting as a bridge to the blockchain. For Ethereum dapp developers, INFURA eliminates the requirement to install, configure, and maintain Ethereum nodes. Specifically for IPFS, which enables distributed storage, this can be accessed seamlessly without the hassle of managing the infrastructure. Figure 5-4 shows the high-level architecture for INFURA.
FIGURE 5-4 INFURA
Here are highlights of INFURA capabilities:
• Exposes TLS (Transport Layer Security)-enabled endpoints to seamlessly access IPFS from decentralized applications running software locally.
• Presents TLS-enabled endpoints for Ethereum that support CORS (Cross-Origin Resource Sharing) and provides capabilities that available in the JSON-RPC API (including web3 and eth methods).
• Broadcasts signed raw transactions to Ethereum blockchain.
• Provides Ferryman, a reverse proxy that helps with caching, throttling, logging, scaling, and reliability, and provides intelligent request routing to a number of specialized backend clients such as EthereumH, Geth, Nethereum, Parity, Strato, or any other client that performs certain operations in an optimized way.
• Works on Ethereum Main Net (ETH), Ethereum Testnet (Morden), and the Ethereum ConsenSysNet.
Below are the steps necessary to start using INFURA:
1. Sign up for an INFURA access token at https://infura.io/register.html. Though the service is free, requests do need to be identified to the RPC provider endpoints.
2. Choose a network. This can be production or one of the many test networks.
3. Issue requests to INFURA. A list of available requests can be found at https://infura.io/docs/#supported-json-rpc-methods. (Note that if you omit the access token, calls will probably still work, but they are subject to more restrictive throttling and filtering of available JSON-RPC API calls.)
4. Or you can use the REST(ish) API that is documented at http://docs.infura.apiary.io/.
Decentralized Applications
A decentralized application (dapp) is like any other modern web-architected application, typically consisting of a user interface (UI) whose functionality is supported by backend services (reading and writing to persistent storage, processing, complex logic). These backend services typically make use of the Ethereum platform and in particular the smart contracts that are deployed to it. See Figure 5-5 for an example dapp.
FIGURE 5-5 Ethereum dapp
Profile of a Dapp
While it is still early days in the lifetime of Ethereum and the decentralized applications that are built upon it, it is nonetheless becoming clear that applications that are popping up appear to fit the following profile:
• Decentralized The complete record of the operation must be stored on a public blockchain that is designed to prevent pitfalls of centralization (see earlier in the chapter for more on Ethereum’s approach to this).
• Incentivized The validating miners of the blockchain are incentivized with rewards of cryptographic tokens or value.
• Open source Ideally, it should be governed by autonomy and all changes must be decided by the consensus, or a majority, of its users. Its code base should be available for scrutiny.
• Protocol The application community must agree on a cryptographic algorithm to show proof of value (either via proof-of-work or proof-of-stake, or a combination thereof).
In retrospect, the very first dapp was Bitcoin. We think of Bitcoin as a cryptocurrency only, but it is a distributed ledger that provides the transfer of value without intermediaries or governing authorities and satisfies all of the above profile entries.
There are now many examples of Ethereum-based dapps. If you navigate to the State of the Dapps website (https://dapps.ethercasts.com/) you will see there are more than 700 dapps in various states of development. Some of the most successful in terms of market cap are Augur (prediction market), Golem (distributed computation), and Melonport (asset management portal).
Decentralized Autonomous Organizations
A decentralized autonomous organization (DAO) uses the same or similar thought processes applied to Bitcoin where it did away with central governing middlemen, and extends that to the corporate structure. The idea is that companies and other organizations can exist and operate without hierarchical management. A DAO attempts to codify (put into code) the rules that a company operates under. These rules include what projects are to be funded, how to accept investment, how to pay back investors, and how to amend and extend the governing rules (which most likely would be to fork the DAO code or make a new DAO and transfer value from old to new). Figure 5-6 shows an example DAO topology. Basically, a DAO works the same way as a typical company, but its rules are digitally encoded and automatically enforced and executed.
FIGURE 5-6 Decentralized autonomous organization (DAO)
The biggest issue with a DAO is that when something unforeseen is encountered, its structure and current code base may not facilitate a fix or change to overcome or address the situation. It is still something worthwhile to keep an eye on and even participate in, so the kinks can be worked out and iterated on.
Summary
With its state transition function, Ethereum provides an open-ended platform by design, and is well suited to serve as a framework for financial and nonfinancial decentralized applications. Regulation is still up in the air on this. How it may even apply to a global decentralized platform is unclear. Current laws and regulations will catch up and apply to these platforms. However, it is still important to work through any legal and regulatory impacts of particular applications. Businesses operating in regulated industries should seek guidance from their regulators before integrating critical, customer-facing, or data-handling processes with platforms like Ethereum. Large strides have been made in the financial services arena with private and consortium varieties of blockchain, and clearly this is an indication that financial institutions are playing in and watching the space very closely.