Ethereum

Ethereum Whitepaper | ethereum.org

page last updated: August 18, 2022

This introductory paper was originally published in 2014 by Vitalik Buterin, the founder of Ethereum, prior to the project’s launch in 2015. It’s worth noting that Ethereum, like many community-driven open source software projects, has evolved since its initial release. start.

Reading: Ethereum white paper

Although several years old, we maintain this document because it continues to serve as a useful reference and accurate representation of ethereum and its vision. To learn about the latest ethereum developments and how changes are made to the protocol, we recommend this guide.

Researchers and scholars looking for a historical or canonical version of the [December 2014] whitepaper should use this pdf.

a state-of-the-art decentralized application platform and smart contract

satoshi nakamoto’s development of bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset that simultaneously has no backing or “intrinsic value” and no real value. issuer or centralized controller. However, another, possibly more important, part of the bitcoin experiment is the underlying blockchain technology as a distributed consensus tool, and attention is rapidly starting to shift to this other aspect of bitcoin. Commonly cited alternative applications of blockchain technology include the use of digital assets on the blockchain to represent custom currencies and financial instruments (“color coins”), ownership of an underlying physical device (“smart property”), non-fungible assets such as domain names (“namecoin”), as well as more complex applications that involve having digital assets directly controlled by code implementing arbitrary rules (“smart contracts”) or even blockchain-based “decentralized autonomous organizations” (daos). what ethereum intends to provide is a blockchain with an integrated turing-complete programming language that can be used to create “contracts” that can be used to code arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others we haven’t yet imagined, simply by writing the logic in a few lines of code.

introduction to bitcoin and existing concepts

story

The concept of decentralized digital currency, as well as alternative applications such as property registries, has been around for decades. Anonymous electronic cash protocols of the 1980s and 1990s, which largely relied on a cryptographic primitive known as Chaumian blinding, provided a currency with a high degree of privacy, but the protocols largely failed to gain traction due to their reliance on a centralized broker. . In 1998, Wei Dai’s b-money became the first proposal to introduce the idea of ​​creating money by solving computational puzzles and decentralized consensus, but the proposal was scant on details of how decentralized consensus could actually be implemented. in 2005, hal finney introduced a concept of “reusable proof-of-work”, a system that uses ideas from b-money along with adam back’s computationally difficult hashcash puzzles to create a concept for a cryptocurrency, but again fell short the ideal by relying on reliable computing as a backend. In 2009, Satoshi Nakamoto first implemented a decentralized currency in practice, combining established primitives for managing ownership through public-key cryptography with a consensus algorithm for keeping track of who owns coins, known as “proof-of-work.” “.

The mechanism behind proof of work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, which allowed network nodes to collectively agree on a set of canonical updates to the state of the bitcoin ledger. Second, it provided a mechanism to allow free entry into the consensus process, solving the political problem of deciding who can influence the consensus while also preventing sybil attacks. it does so by substituting a formal barrier to participation, such as the requirement to be registered as a single entity on a particular list, with an economic barrier: the weight of a single node in the consensus voting process is directly proportional to the computing power . which brings the node. an alternative approach called proof-of-stake has since been proposed, which calculates a node’s weight as proportional to its currency holdings and not computational resources; discussion of the relative merits of the two approaches is beyond the scope of this document, but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.

bitcoin as a state transition system

Ethereum state transition

From a technical point of view, the ledger of a cryptocurrency like bitcoin can be thought of as a state transition system, where there is a “state” consisting of the ownership status of all existing bitcoins and a “function of state transition” that takes a state and a transaction and generates a new state that is the result. In a standard banking system, for example, the state is a balance, a transaction is a request to move $x from a to b, and the state transition function reduces the value in account a by $x and increases the value in account of b. account for $x. if account a has less than $x in the first place, the state transition function returns an error. therefore, it can be formally defined:

in the banking system defined above:

but:

the “state” in bitcoin is the collection of all coins (technically, “unspent transaction outputs” or utxo) that have been minted and not yet spent, and each utxo has a denomination and an owner (defined by a 20-byte address that is essentially a cryptographic public key fn1). a transaction contains one or more inputs, each containing a reference to an existing utxo and a cryptographic signature produced by the private key associated with the owner’s address, and one or more outputs, each containing a new utxo to be added to the state.

the state transition function apply(s,tx) -> s’ can be roughly defined as follows:

  1. for each entry in tx:
    • if the referenced utxo is not in s, return an error.
    • if the supplied signature does not match the owner of the utxo , returns an error.

    The first half of the first step prevents transaction issuers from spending coins that don’t exist, the second half of the first step prevents transaction issuers from spending other people’s coins, and the second step enforces conservation of value. to use this for payment, the protocol is as follows. suppose alice wants to send 11.7 btc to bob. First, Alice will search for a set of available Utxos that she owns that total at least 11.7 BTC. Realistically Alice won’t be able to get exactly 11.7 BTC; say the smallest you can get is 6+4+2=12. then create a transaction with those three inputs and two outputs. the first output will be 11.7 btc owned by bob’s address, and the second output will be the remaining 0.3 btc “change” owned by alice.

    mining

    Ethereum blocks

    If we had access to a reliable centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server’s hard drive to keep track of state. however, with bitcoin we are trying to build a decentralized monetary system, so we will need to combine the state transaction system with a consensus system to ensure that everyone agrees on the order of transactions. Bitcoin’s decentralized consensus process requires nodes in the network to continually try to produce transaction packets called “blocks.” the network is intended to produce approximately one block every ten minutes, with each block containing a timestamp, a nonce, a reference (i.e., a hash) to the previous block, and a list of all transactions that have taken place since the block. previous lock. Over time, this creates a persistent and ever-growing “blockchain” that is constantly updated to represent the latest state of the bitcoin ledger.

    The algorithm to verify if a block is valid, expressed in this paradigm, is the following:

    1. verify if the previous block referenced by the block exists and is valid.
    2. verify that the timestamp of the block is greater than that of the previous block fn2 and less than 2 hours in the future
    3. verify that the proof of work in the block is valid.
    4. let s[0] be the state at the end of the previous block.
    5. suppose where tx is the transaction list of the block with n transactions. for all i in 0…n-1, set s[i+1] = apply(s[i],tx[i]) if any application returns an error, exit and return false.
    6. returns true and records s[n] as the state at the end of this block.

    Basically, each transaction in the block must provide a valid state transition from the canonical state before the transaction was executed to some new state. note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validator node and can only be calculated (safely) for any block starting from the genesis state and sequentially applying each transaction on each block. Also, keep in mind that the order in which the miner includes transactions in the block is important; if there are two transactions a and b in a block such that b spends an utxo created by a, then the block will be valid if a comes before b but not otherwise.

    The only validity condition present in the list above that is not found in other systems is the “proof of work” requirement. the precise condition is that the double-sha256 hash of each block, treated as a 256-bit number, must be less than a dynamically adjusted target, which at the time of writing is about 2187. the purpose of this is to do computationally “difficult” block creation, thus preventing sybil attackers from remaking the entire blockchain in their favor. because sha256 is designed to be a completely unpredictable pseudo-random function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.

    with the current target of ~2187, the network must average ~269 attempts before finding a valid block; in general, the network recalibrates the target every 2016 blocks, so that, on average, some node in the network produces a new block every ten minutes. To compensate miners for this computation work, the miner of each block has the right to include a transaction that brings them 25 BTC out of thin air. additionally, if any transaction has a higher total denomination on its inputs than its outputs, the difference also goes to the miner as a “transaction fee”. Incidentally, this is also the only mechanism by which btc are issued; the genesis state did not contain any coins.

    To better understand the purpose of mining, let’s examine what happens in the event of a malicious attacker. Since bitcoin’s underlying cryptography is known to be secure, the attacker will directly target the part of the bitcoin system that is not cryptographically protected: the order of transactions. the attacker’s strategy is simple:

    1. send 100 btc to a merchant in exchange for some product (preferably a fast-delivery digital good)
    2. wait for the product to be delivered
    3. produce another transaction by sending the same 100 btc to yourself
    4. try to convince the network that the transaction you made to yourself was the first one.

    once step (1) is done, after a few minutes, some miner will include the transaction in a block, say block number 270000. after about an hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus “confirming” it. at this point, the merchant will accept the payment as complete and deliver the product; since we assume that it is a digital good, the delivery is instant. now the attacker creates another transaction sending the 100 btc to himself. if the attacker just releases it, the transaction will not be processed; miners will try to run apply(s,tx) and notice that tx consumes an utxo that is no longer in the state. so instead, the attacker creates a “fork” of the blockchain, starting by mining another version of block 270000 that points to the same block 269999 as the parent but with the new transaction instead of the old one. because the data in the block is different, this requires redoing the proof of work. furthermore, the attacker’s new version of block 270000 has a different hash, so the original blocks 270001 to 270005 don’t “point” to it; therefore, the original string and the attacker’s new string are completely separate. the rule is that in a fork, the longest blockchain is taken as the truth, so the legitimate miners will work on the 270005 chain while the attacker only works on the 270000 chain. of blocks is the longest, it would need to have more computing power than the rest of the network combined to catch up (hence “51% attack”).

    merkle trees

    left: it suffices to present only a small number of nodes in a merkle tree to give a proof of the validity of a branch.

    correct: any attempt to change any part of the merkle tree will eventually lead to an inconsistency somewhere in the chain.

    an important scalability feature of bitcoin is that the block is stored in a multi-level data structure. the “hash” of a block is really just the hash of the block header, a roughly 200-byte piece of data containing the timestamp, the nonce, the hash of the previous block, and the root hash of a data structure called a tree merkle that stores all the transactions in the block a merkle tree is a type of binary tree, made up of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, which represents the “top” of the tree. the purpose of the merkle tree is to allow the data in a block to be delivered piecemeal: a node can download just the header of a block from one source, the small part of the tree relevant to them from another source, and still be sure that all data is correct. the reason this works is that hashes propagate upwards: if a malicious user attempts to swap a bogus transaction at the bottom of a merkle tree, this change will cause a change to the top node, and then a change to the top node. higher. , ultimately changing the root of the tree and thus the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof-of-work).

    arguably the merkle tree protocol is essential for long-term sustainability. a “full node” on the bitcoin network, which stores and processes the entirety of each block, occupies about 15gb of disk space on the bitcoin network as of april 2014 and is growing by more than a gigabyte per month . currently this is feasible for some desktops and not for phones, and later in the future only businesses and hobbyists will be able to participate. a protocol known as “simplified payment verification” (spv) allows for another class of nodes, called “light nodes,” to exist that download block headers, verify proof-of-work on block headers, and then download only the “branches” associated with transactions that are relevant to them. this allows light nodes to determine with strong security the status of any bitcoin transaction and its current balance while downloading only a very small portion of the entire blockchain.

    alternative blockchain applications

    The idea of ​​taking the underlying idea of ​​blockchain and applying it to other concepts also has a long history. In 2005, Nick Szabo introduced the concept of “secure title deeds with owner authority,” a document outlining how “new advances in replicated database technology” will enable a blockchain-based system to store a record of who owns what land, creating an elaborate framework that includes concepts such as occupation, adverse possession, and Georgian land tax. however, unfortunately there was no effective replicated database system available at the time, so the protocol was never implemented in practice. however, after 2009, once bitcoin’s decentralized consensus was developed, a number of alternative applications quickly began to emerge.

    • namecoin – Created in 2010, namecoin is best described as a decentralized name registration database. In decentralized protocols like tor, bitcoin, and bitmessage, there must be some way to identify accounts so that others can interact with them, but in all existing solutions, the only type of identifier available is a pseudo-random hash like 1lw79wp5zbqahw1jl5tcibcrhqythaguwy. Ideally, one would like to be able to have an account with a name like “george”. however, the problem is that if one person can create an account named “george”, another person can use the same process to register “george” and impersonate him. the only solution is a first record paradigm, where the first recorder succeeds and the second recorder fails, a problem perfectly suited to the bitcoin consensus protocol. namecoin is the oldest and most successful implementation of a name registry system that uses such an idea.
    • colored coins: the purpose of colored coins is to serve as a protocol to allow people to create their own digital currencies, or, in the important trivial case of a currency with a unit, digital tokens, on the bitcoin block chain. in the colored coin protocol, one “issues” a new coin by publicly assigning a color to a specific bitcoin utxo, and the protocol recursively defines the color of another utxo to be the same color as the inputs spent by the transaction that created them (some special rules apply in the case of mixed-color entries). this allows users to hold wallets containing only utxo of a specific color and send them out as regular bitcoins, going back through the blockchain to determine the color of any utxo they receive.
    • metacoins – the idea behind a metacoin is to have a protocol that lives on top of bitcoin, using bitcoin transactions to store metacoin transactions but with a different state transition function, apply’. Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing on the bitcoin block chain, a rule is added that states that if apply'(s,tx) returns an error, the protocol is applied automatically. defaults to apply'(s,tx) = s. this provides a simple mechanism to create an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented within bitcoin itself, but with very low development cost, since the bitcoin protocol already handles the complexities of mining and networks. metacoins have been used to implement some kinds of financial contracts, name registration, and decentralized exchange.

    Therefore, in general, there are two approaches to building a consensus protocol: building a stand-alone network and building a protocol on top of bitcoin. The first approach, while reasonably successful for applications like namecoin, is difficult to implement; each individual implementation needs to start an independent blockchain, as well as build and test all the necessary network and state transition code. Furthermore, we predict that the set of applications for decentralized consensus technology will follow a power-law distribution where the vast majority of applications would be too small to secure their own blockchain, and note that there are large classes of decentralized applications, particularly decentralized autonomous. organizations, which need to interact with each other.

    The bitcoin-based approach, on the other hand, suffers from the flaw that it does not inherit the simplified payment verification functions of bitcoin. spv works for bitcoin because it can use the depth of the blockchain as a proxy for validity; at some point, once the ancestors of a transaction go back far enough, it’s safe to say that they were rightfully part of the state. blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of its own protocols. therefore, a completely secure spv meta-protocol implementation would need to scan back to the beginning of the bitcoin blockchain to determine whether or not certain transactions are valid. currently all “lightweight” implementations of bitcoin-based meta-protocols rely on a trusted server to provide the data, possibly a far less than optimal result, especially when one of the primary purposes of a cryptocurrency is to eliminate the need for confidence.

    scripts

    Even without any extensions, the bitcoin protocol actually facilitates a weak version of a “smart contract” concept. utxo in bitcoin can be owned not only by a public key, but also by a more complicated script expressed in a simple stack-based programming language. in this paradigm, a transaction expense that utxo must provide data that satisfies the script. in fact, even the basic mechanism of public key ownership is implemented via a script: the script takes an elliptic curve signature as input, checks it against the transaction and the address that the utxo owns, and returns 1 if the check is successful and 0 otherwise. other more complicated scripts exist for various additional use cases. for example, a script can be built that requires signatures from two of the three given private keys to validate (“multisig”), a useful setup for corporate accounts, secure savings accounts, and some merchant escrow situations. scripts can also be used to pay bounties for solutions to computational problems, and you can even build a script that says something like “this bitcoin utxo is yours if you can provide spv proof that you sent me a transaction of dogecoin of this denomination”. , essentially enabling decentralized cross-cryptocurrency trading.

    However, the scripting language implemented in bitcoin has several important limitations:

      the main missing category is loops. this is done to avoid infinite loops during transaction verification; In theory, this is an insurmountable hurdle for scripters, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it leads to scripts that are very space-inefficient. for example, implementing an alternative elliptic curve signature algorithm would likely require 256 rounds of repeated multiplication, all included individually in the code.
    • value blindness: there is no way of a utxo script to provide fine-grained control over the amount that can be withdrawn. For example, a powerful use case of an oracle contract would be a hedge contract, where a and b contribute $1000 in btc and after 30 days the script sends $1000 in btc to a and the rest to b. this would require an oracle to determine the value of 1 btc in usd, but it’s still a massive improvement in terms of trust and infrastructure requirements over the fully centralized solutions that are available now. however, because utxos are all or nothing, the only way to achieve this is through the very inefficient trick of having many utxos of different denominations (for example, a 2k utxo for every k up to 30) and having to choose which utxo to send to a and which to b.
    • lack of status – utxo can be spent or unspent; there is no opportunity for multi-stage contracts or scripts that hold any other internal state beyond that. this makes it difficult to perform multi-stage options contracts, decentralized exchange offerings, or two-stage crypto commitment protocols (necessary for secure computational rewards). it also means that utxo can only be used to build simple, single contracts and not more complex “stateful” contracts, like decentralized organizations, and makes meta-protocols difficult to implement. the binary state combined with value blindness also means that another important application, withdrawal limits, is impossible. timestamp and previous block hash. this severely limits applications in gaming and several other categories, by depriving the scripting language of a potentially valuable source of randomness.

    Therefore, we see three approaches to building advanced cryptocurrency applications: building a new blockchain, scripting over bitcoin, and building a meta-protocol over bitcoin. creating a new blockchain allows unlimited freedom in creating a set of functions, but at the cost of development time, startup effort, and security. scripting is easy to implement and standardize, but its capabilities are very limited, and metaprotocols, while easy, suffer from scalability flaws. with ethereum, we intend to build an alternative framework that provides even greater gains in ease of development, as well as even stronger thin client properties, while at the same time allowing applications to share an economic environment and the security of the blockchain.

    ethereal

    Ethereum’s intent is to create an alternative protocol for building decentralized applications, providing a different set of trade-offs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and seldom used applications, and the ability of different applications to interact very efficiently, are important. ethereum does this by building what is essentially the last abstract foundational layer: a blockchain with a turing-complete programming language built in, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules of ownership, formats transaction and state transition functions. a basic version of namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in less than twenty. Smart contracts, cryptographic “boxes” that hold value and only unlock it if certain conditions are met, can also be built on top of the platform, with far more power than bitcoin scripts offer due to additional turing powers. -completeness, value awareness, blockchain awareness, and status.

    ethereum accounts

    In ethereum, state is made up of objects called “accounts”, each account has a 20-byte address, and state transitions are direct transfers of value and information between accounts. an ethereum account contains four fields:

    • the nonce, a counter used to ensure that each transaction can only be processed once
    • the current ether balance of the account
    • the contract code of the account, if present
    • the storage of the account ( empty by default)

    “ether” is ethereum’s main internal crypto fuel and is used to pay transaction fees. In general, there are two types of accounts: external property accounts, controlled by private keys, and contract accounts, controlled by your contract code. an externally owned account has no code and messages can be sent from an externally owned account by creating and signing a transaction; In a contract account, each time the contract account receives a message, its code is activated, allowing it to read and write to internal storage and send other messages or create contracts in turn.

    note that “contracts” on ethereum should not be seen as something to be “fulfilled” or “fulfilled”; rather, they are more like “autonomous agents” that live within the ethereum runtime environment, always executing a specific piece of code when a message or transaction “pushes” them, and have direct control over their own ether balance and key. . store of values ​​to keep track of persistent variables.

    messages and transactions

    The term “transaction” is used in ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. transactions contain:

    • the recipient of the message
    • a signature identifying the sender
    • the amount of ether to be transferred from the sender to the recipient
    • a field of data optional
    • an initial gas value, representing the maximum number of computational steps the transaction execution can take
    • a gas price value, representing the fee that sender pays per computational step

    See also: When Will Ethereum 2.0 Launch? • Benzinga Crypto

    The first three are standard fields expected in any cryptocurrency. the data field has no function by default, but the virtual machine has an opcode by which a contract can access the data; As an example use case, if a contract works as a blockchain domain registration service, you might want to interpret the data passed to it as containing two “fields”, the first field is a domain to register and the second field being the ip address to register it. the contract would read these values ​​from the message data and store them appropriately.

    The startgas and gasprice fields are crucial to ethereum’s anti-denial of service model. To avoid accidental or hostile infinite loops or other computational waste in the code, each transaction is required to set a limit on the number of computational steps of code execution that it can use. the fundamental unit of computation is “gas”; typically a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive or increase the amount of data that needs to be stored as part of the state. there is also a 5 gas fee for each byte in the transaction data. the intent of the fee system is to require an attacker to pay proportionally for each resource they consume, including compute, bandwidth, and storage; therefore, any transaction that results in the network consuming a greater amount of any of these resources should have a gas fee roughly proportional to the increase.

    messages

    Contracts have the ability to send “messages” to other contracts. messages are virtual objects that are never serialized and exist only in the ethereum runtime environment. a message contains:

    • the sender of the message (implied)
    • the recipient of the message
    • the amount of ether to be transferred along with the message
    • a field optional dataset
    • a starting gas value

    Essentially, a message is like a transaction, except that it is produced by a contract and not by an external actor. a message is produced when a current executing code of the contract executes the calling opcode, which produces and executes a message. Like a transaction, a message leads to the recipient’s account by executing the recipient’s code. therefore, contracts can have relationships with other contracts in exactly the same way as external actors.

    Note that the gas allocation allocated by a transaction or contract applies to the total gas consumed by that transaction and all sub-runs. For example, if an external actor a sends a transaction to b with 1000 gas, and b consumes 600 gas before sending a message to c, and c’s internal execution consumes 300 gas before returning, then b can spend another 100 gas before executing without gasoline.

    ethereum state transition function

    Ether state transition

    the ethereum state transition function, apply(s,tx) -> s’ can be defined as follows:

    1. check if the transaction is well formed (ie has the correct number of values), the signature is valid, and the nonce matches the nonce in the sender’s account. if not, return an error.
    2. calculate the transaction fee as startgas * gasprice, and determine the shipping address from the signature. Subtract the fee from the sender’s account balance and increment the sender’s nonce. if there is not enough balance to spend, return an error.
    3. initialize gas = startgas, and remove a certain amount of gas per byte to pay for the bytes in the transaction.
    4. transfer the value of the transaction from the sender’s account to the receiving account. if the receiving account does not already exist, create it. if the receiving account is a contract, run the contract code to completion or execution times out.
    5. if the transfer of value failed because the sender did not have enough money or the code execution ran out of gas, reverse all state changes except payment of fees, and add fees to the miner’s account.
    6. otherwise, refund fees for all remaining gas to sender and send the fees paid gas consumed to the miner.

    for example, suppose the contract code is:

    Note that the contract code is actually written in low-level evm code; this example is written in snake, one of our high-level languages, for clarity, and can be compiled down to evm code. Suppose the contract store starts empty and a transaction is sent with 10 ether values, 2000 gas, 0.001 ether gas price, and 64 bytes of data, with bytes 0-31 representing the number 2 and bytes 32-63 representing the charlie chain. the process for the state transition function in this case is as follows:

    1. verify that the transaction is valid and well formed.
    2. verify that the sender of the transaction has at least 2000 * 0.001 = 2 ether. if so, subtract 2 ether from the sender’s account.
    3. initialize gas = 2000; assuming the transaction is 170 bytes long and the byte fee is 5, subtract 850 to leave 1150 gas left.
    4. subtract 10 more ether from sender account and add to sender account contract.
    5. run the code. In this case, this is simple: it checks if the contract store at index 2 is used, warns that it is not, and therefore sets the store at index 2 to the value charlie. suppose this requires 187 gas, so the remaining amount of gas is 1150 – 187 = 963
    6. add 963 * 0.001 = 0.963 ether to the sender’s account and return the resulting statement.
    7. If there were no contract at the receiving end of the transaction, the total transaction fee would simply be equal to the price of gas provided multiplied by the length of the transaction in bytes, and the data sent along with the transaction would be irrelevant .

      Note that messages work equivalently to transactions in terms of rollbacks: if a message’s execution runs out of gas, then that message’s execution, and all other executions triggered by that execution, are rolled back , but the main executions do not need to be rolled back. this means that it is “safe” for a contract to call another contract, as if a calls b with g gas, then the execution of a is guaranteed to lose at most g gas. Finally, note that there is an opcode, create, that creates a contract; its execution mechanics are generally similar to the call, with the exception that the execution output determines the code of a newly created contract.

      code execution

      The code in ethereum contracts is written in a low-level stack-based bytecode language, called “ethereum virtual machine code” or “evm code”. the code consists of a series of bytes, where each byte represents an operation. In general, code execution is an infinite loop that consists of repeatedly performing the operation on the current program counter (which starts at zero), and then incrementing the program counter by one, until either the end of the code is reached or throws an error or stops. or a return instruction is detected. operations have access to three types of space in which to store data:

      • the stack, a last-in, first-out container that values ​​can be pushed to and fetched from
      • memory, an infinitely expandable byte array
      • the long-term storage of the contract, a key/value store. Unlike stack and memory, which reset after computation completes, storage persists long-term.

      The code can also access the value, sender, and data of the incoming message, as well as the block header data, and the code can also return a byte array of data as output.

      the formal execution model of evm code is surprisingly simple. while the ethereum virtual machine is running, its entire computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state that contains all accounts and includes balances and storage. at the beginning of each round of execution, the current statement is found by taking the eighth byte of code (or 0 if pc >= len(code)), and each statement has its own definition in terms of how it affects the tuple . for example, add pops two items from the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and sstore pushes the top two items from the stack and inserts the second item into the contract store at the specified index for the first element. Although there are many ways to optimize the execution of the ethereum virtual machine through just-in-time compilation, a basic ethereum implementation can be done in a few hundred lines of code.

      blockchain and mining

      Ethereum apply block diagram

      The ethereum blockchain is similar in many ways to the bitcoin blockchain, although it has some differences. The main difference between Ethereum and Bitcoin with respect to blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the list of transactions and the most recent state. Apart from that, two other values, the block number and the difficulty, are also stored in the block. the basic block validation algorithm in ethereum is as follows:

      1. check if the previous referenced block exists and is valid.
      2. check that the timestamp of the block is greater than that of the previous referenced block and less 15 minutes into the future
      3. verify that the block number, difficulty, transaction root, uncle root, and gas limit (several low-level ethereum-specific concepts) are valid .
      4. verify that the proof of work in the block is valid.
      5. let s[0] be the state at the end of the previous block.
      6. let tx be the list of block transactions, with n transactions. for all i in 0…n-1, set s[i+1] = apply(s[i],tx[i]). if any application returns an error, or if the total gas consumed in the block up to this point exceeds the gas limit, return an error.
      7. let s_final be s[n], but add the reward of the block paid to the miner.
      8. check if the root of the merkle tree of the s_final state is equal to the root of the final state given in the block header. if it is, the lock is valid; otherwise, it is invalid.

      The approach may seem very inefficient at first glance, because you need to store the full state with each block, but in reality the efficiency should be comparable to that of bitcoin. the reason is that the state is stored in the tree structure, and after each block only a small part of the tree needs to be changed. thus, in general, between two adjacent blocks, the vast majority of the tree must be the same, and thus data can be stored once and referenced twice by pointers (i.e. hashes of subtrees). A special type of tree known as a “patricia tree” is used to accomplish this, including a modification to the merkle tree concept that allows nodes to be inserted and removed, and not just changed, efficiently. furthermore, because all state information is part of the last block, there is no need to store the entire history of the block chain, a strategy that, if applied to bitcoin, can be computed to provide space savings from 5 to 20 times.

      A frequently asked question is “where” does the contract code run, in terms of physical hardware. this has a simple answer: the contract code execution process is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added to block b, the execution of the code generated by that transaction will be executed by all nodes, now and in the future, that download and validate block b.

      applications

      In general, there are three types of applications besides ethereum. The first category is financial apps, which provide users with more powerful ways to manage and enter into contracts using their money. this includes sub-currencies, financial derivatives, hedging contracts, savings portfolios, wills, and ultimately even some kinds of large-scale employment contracts. the second category is semi-financial applications, where there is money involved but there is also an important non-monetary side to what is being done; a perfect example is self-executing rewards for solutions to computational problems. finally, there are applications like online voting and decentralized governance that are not financial at all.

      token systems

      Blockchain token systems have many applications ranging from sub-currencies representing assets such as dollars or gold to company shares, individual tokens representing smart properties, secure and unforgeable coupons, and even token systems with no link to value conventional. used as point systems for incentives. token systems are surprisingly easy to implement on ethereum. The key point to understand is that everything that is a currency, or token system, is fundamentally a database with one operation: subtract x units from a and give x units to b, provided that (i) a has at minus x units before the transaction and (2) the transaction is approved by a. all that is needed to implement a token system is to implement this logic in a contract.

      The basic code to implement a serpent token system is as follows:

      Essentially, this is a literal implementation of the “banking system” state transition function described earlier in this document. some extra lines of code should be added to provide the initial step of distributing the currency units in the first place and some other edge cases, and ideally a function would be added to allow other contracts to query the balance of an address. but that’s all there is to it. In theory, ethereum-based token systems that act as subcurrencies can potentially include another important feature that on-chain bitcoin-based metacurrencies lack: the ability to pay transaction fees directly in that currency. the way this would be implemented is that the contract would hold an ether balance with which it would repay the ether used to pay fees to the sender, and top up this balance by collecting the internal currency units it takes in fees and reselling them in a constant auction . so users would have to “activate” their accounts with ether, but once the ether is there, it would be reusable because the contract would refund it every time.

      financial derivatives and stable value currencies

      financial derivatives are the most common application of a “smart contract” and one of the easiest to implement in code. the main challenge in the implementation of financial contracts is that most of them require reference to an external price indicator; For example, a highly desirable application is a smart contract that hedges against the volatility of ether (or other cryptocurrency) against the US dollar, but doing this requires the contract to know what the value of eth/usd is. the easiest way to do this is through a “data feed” contract held by a specific party (eg nasdaq) designed so that party has the ability to update the contract as needed, and provides an interface which allows other contracts to send a message to that contract and get a response that provides the price.

      Given that critical ingredient, the coverage contract would look like this:

      1. wait for party a to enter 1000 ether.
      2. wait for party b to enter 1000 ether.
      3. record the usd value of 1000 ether, calculated by querying the datasource contract, in storage, let’s say this is $x.
      4. after 30 days, let a or b “reactivate” the contract to send $x worth of ether (calculated by looking at the data source contract again to get the new price) to a and the rest to b.

      Such a contract would have significant potential in crypto trading. One of the main problems cited about cryptocurrency is the fact that it is volatile; While many users and traders want the security and convenience of trading crypto assets, many do not want to face the prospect of losing 23% of the value of their funds in a single day. Until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a secondary currency in which they have the right to issue and revoke units, and provide a unit of the currency to anyone who provides them (offline) with a unit of a specific underlying asset (for example, gold, US dollar). the issuer then promises to provide a unit of the underlying asset to anyone who returns a unit of the crypto asset. this mechanism allows any non-crypto asset to be “elevated” to a crypto asset, as long as the issuer can be trusted.

      In practice, however, issuers are not always trustworthy and, in some cases, the banking infrastructure is too weak or too hostile for such services to exist. financial derivatives offer an alternative. Here, instead of a single issuer providing the funds to back an asset, a decentralized market of speculators, who bet that the price of a benchmark crypto asset (eg, eth) will rise, plays that role. Unlike issuers, speculators have no option to default on their end of the bargain because the hedge contract holds their funds on deposit. note that this approach is not completely decentralized, because a trusted source is still needed to provide the price indicator, although it is arguably still a massive improvement in terms of reducing infrastructure requirements (as opposed to being a issuer, issuing a price feed does not require licenses and can probably be classified as free speech) and reduce the potential for fraud.

      identity and reputation systems

      The first alternative cryptocurrency of all, namecoin, attempted to use a blockchain similar to bitcoin to provide a name registration system, where users can register their names in a public database along with other data. The main use case cited is for a DNS system, mapping domain names like “bitcoin.org” (or, in the case of namecoin, “bitcoin.bit”) to an IP address. other use cases include email authentication and potentially more advanced reputation systems. here is the basic contract to provide a name coin-like name registration system on ethereum:

      the contract is very simple; all it is is a database within the ethereum network that can be added, but not modified or deleted. anyone can register a name with some value, and that registration is kept forever. a more sophisticated name registration contract will also have a “role clause” that allows it to be queried by other contracts, as well as a mechanism for the “owner” (i.e., the first registrar) of a name to change data or transfer the property. one can even add reputation and trusted web functionality on top.

      decentralized file storage

      In recent years, a number of popular online file storage startups have emerged, most prominently dropbox, which seeks to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee. however, at this point, the file storage market is sometimes relatively inefficient; A cursory look at various existing solutions shows that, particularly at the 20-200gb level of the “uncanny valley” where free quotas and enterprise-level discounts are not triggered, monthly prices for file storage costs standard are such that you are paying for more than the cost of the entire hard drive in a single month. Ethereum contracts can enable the development of a decentralized file storage ecosystem, where individual users can earn small amounts of money by renting their own hard drives and unused space can be used to further reduce file storage costs.

      The fundamental piece of such a device would be what we have called “decentralized dropbox contract”. This contract works as follows. First, one divides the desired data into blocks, encrypting each block for privacy, and builds a merkle tree from it. then a contract is made with the rule that, every n blocks, the contract would choose a random index in the merkle tree (using the previous block’s hash, accessible from the contract code, as the source of randomness), and give it x ether to the first entity to provide a transaction with a simplified payment verification, as proof of ownership of the block at that particular index in the tree. when a user wants to download his file again, he can use a micropayment channel protocol (for example, pay 1 szabo for 32 kilobytes) to retrieve the file; the most profitable approach is for the payer not to post the transaction to completion, but instead replace the transaction with a slightly more profitable one with the same nonce after every 32 kilobytes.

      an important feature of the protocol is that although it may seem that one is trusting many random nodes not to decide to forget the file, one can reduce that risk to almost zero by splitting the file into many parts through secret sharing and observing contracts to see that each piece is still in the possession of some node. if a contract is still paying money, that provides cryptographic proof that someone is still storing the file.

      decentralized autonomous bodies

      The general concept of a “decentralized autonomous organization” is that of a virtual entity that has a certain set of members or shareholders who, perhaps with a majority of 67%, have the right to spend the funds of the entity and modify its code. members would collectively decide how the organization should allocate its funds. The methods of allocating the funds of a dao can range from rewards, salaries, to even more exotic mechanisms, such as an internal currency to reward work. this essentially replicates the legal trappings of a traditional business or non-profit organization, but uses only cryptographic blockchain technology for its application. Until now, much of the conversation about DAOS has focused on the “capitalist” model of a “decentralized autonomous corporation” (DAC) with shareholders receiving dividends and tradable shares; an alternative, perhaps described as a “decentralized autonomous community”, would give all members an equal share in decision-making and require 67% of existing members to agree to add or remove a member. the requirement that a person can only have one membership would have to be enforced collectively by the group.

      A general outline of how to encode a dao is as follows. the simplest design is simply a self-modifying piece of code that changes if two-thirds of the members agree to a change. although the code is theoretically immutable, one can easily avoid this and have de facto mutability by having code fragments in separate contracts and having the address of the contracts to call stored in writable storage. In a simple implementation of such a dao contract, there would be three types of transactions, distinguished by the data provided in the transaction:

      • [0,i,k,v] to register a proposal with index i to change the address at storage index k to the value v
      • [1,i] to register a vote in favor of proposal i
      • [2,i] to finalize proposal i if enough votes have been obtained

      the contract would have clauses for each of these. would keep a record of all open storage changes, along with a list of who voted for them. it would also have a list of all members. when any storage change reaches two-thirds of the members voting on it, a finalize transaction could execute the change. a more sophisticated skeleton would also have built-in voting capability for functions like submitting a transaction, adding and removing members, and may even provide liquid democracy-style proxy voting (i.e. anyone can assign someone to vote for he and the assignment is transitive, so if a assigns b and b assigns c, then c determines the vote of a). this design would allow the dao to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering who is a member to specialists, though unlike the “current system”, specialists can easily come and go over time. as individual members of the community change their alignments.

      An alternative model is for a decentralized corporation, where any account can have zero or more shares, and two-thirds of the shares are required to make a decision. a full skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order matching mechanism within the contract). there would also be a delegation in the style of liquid democracy, generalizing the concept of “board of directors”.

      other applications

      1. savings portfolios. Let’s say Alice wants to keep his funds safe, but she’s worried about losing or someone hacking his private key. she puts ether in a contract with bob, a bank, as follows:

      • Alice alone can withdraw a maximum of 1% of funds per day.
      • Bob can only withdraw a maximum of 1% of funds per day, but Alice has the ability to do a transaction with her key turns off this ability.
      • alice and bob together can withdraw anything.

      normally 1% per day is enough for alice, and if alice wants to withdraw more, she can contact bob for help. If Alice’s key is hacked, run to Bob to transfer the funds to a new contract. If she loses her key, Bob will eventually get the funds out. if bob turns out to be malicious, she can disable her ability to retreat.

      2. crop insurance. one can easily make a financial derivatives contract but using a weather data source instead of any price index. if a farmer in iowa buys a derivative that is paid inversely based on rainfall in iowa, then if there is a drought, the farmer will automatically receive money and if it rains enough, the farmer will be happy because his crops will do well. this can be extended to insurance against natural disasters in general.

      See also: Mark Cuban: Here&x27s why I&x27m &x27very bullish&x27 on the Ethereum merge upgrade | Fortune

      3. a decentralized data feed. For financial contracts for difference, it may actually be possible to decentralize the data feed through a protocol called “schellingcoin”. schellingcoin basically works like this: n parties enter a given data value (for example, the eth/usd price) into the system, the values ​​are sorted, and everyone between the 25th and 75th percentile gets a token as a reward. everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: truth. this creates a decentralized protocol that can theoretically provide any number of values, including the eth/usd price, the temperature in berlin, or even the result of a particular hard calculation.

      4. smart escrow with multiple signatures. bitcoin allows multi-signature transaction contracts where, for example, three out of five given keys can spend the funds. ethereum allows more granularity; for example, four out of five can spend all, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day. furthermore, ethereum multisig is asynchronous: two parties can register their signatures on the blockchain at different times, and the last signature will automatically send the transaction.

      5. cloud computing. evm technology can also be used to create a verifiable computing environment, allowing users to ask others to perform calculations, and optionally request proof that calculations at certain randomly selected checkpoints were successful. this allows for the creation of a cloud computing marketplace in which any user can participate with their desktop, laptop, or specialized server, and spot checks can be used in conjunction with security repositories to ensure that the system is trustworthy ( i.e. nodes cannot profitably cheat). although such a system may not be suitable for all tasks; tasks that require a high level of communication between processes, for example, cannot be easily performed in a large cloud of nodes. other tasks, however, are much easier to parallelize; projects like seti@home, folding@home and genetic algorithms can be easily implemented on such a platform.

      6. games of chance between pairs. Any number of peer-to-peer gaming protocols, such as Frank Stajano and Richard Clayton’s Cyberdice, can be implemented on the Ethereum blockchain. the simplest gaming protocol is actually simply a contract for difference at the next block hash, and more advanced protocols can be built from there, creating near-zero fee gaming services that do not have the ability to cheat .

      7. prediction markets. As long as there is an oracle or schellingcoin, prediction markets are also easy to implement, and prediction markets together with schellingcoin may become the first mainstream application of futarchy as a governance protocol for decentralized organizations.

      8. decentralized chain markets, using the identity and reputation system as a basis.

      miscellaneous and concerns

      modified ghost implementation

      the “greedy heaviest observed subtree” (ghost) protocol is an innovation first introduced by yonatan sompolinsky and aviv zohar in december 2013. the motivation behind ghost is that blockchains with fast confirmation times currently suffer from reduced security due to high rate: because blocks take some time to propagate through the network, if miner a mines a block and then miner b mines another block before miner a’s block is propagate to b, miner b’s block will end up wasted and will not contribute to network security. In addition, there is a centralization problem: if miner a is a mining pool with 30% hashpower and miner b has 10% hashpower, then a will risk producing a stale block 70% of the time (since the another 30% of the time a produced the last block and thus will get mining data right away), while b will risk producing a stale block 90% of the time. thus, if the block interval is short enough that the stale rate is high, a will be substantially more efficient simply by virtue of its size. With these two effects combined, it is very likely that blockchains that produce blocks quickly will lead to a mining pool having a large enough percentage of the network’s hashing power to have de facto control over the mining process. /p>

      as sompolinsky and zohar describe it, ghost solves the first network security leak problem by including stale blocks in the calculation of which chain is the “longest”; that is, they don’t just add to the calculation of which block has the most proof of working supporting it. to solve the second problem of centralization bias, we go beyond the protocol described by sompolinsky and zohar, and also provide block rewards to stales: a stale block receives 87.5% of its base reward, and the nephew that includes the obsolete block receives the rest 12.5%. however, transaction fees are not given to the guys.

      ethereum implements a stripped down version of ghost that only drops seven levels. specifically, it is defined as follows:

      • a block must specify a parent, and must specify 0 or more uncles
      • an uncle included in block b must have the following properties:
        • must be a child direct from the kth generation ancestor of b, where 2 <= k <= 7.
        • cannot be an ancestor of b
        • an uncle must be a header of valid block , but does not need to be a previously verified or even valid block
        • an uncle must be different from all uncles included in previous blocks and all other uncles included in the same block (no double inclusion)

        This limited version of ghost, with guys included only up to 7 generations, was used for two reasons. first, unlimited phantom would include too many complications in calculating which dudes for a given block are valid. second, unlimited ghost with compensation as used in ethereum removes the incentive for a miner to mine on the mainchain and not on a public attacker’s chain.

        fees

        Because each transaction posted on the blockchain imposes on the network the cost of having to download and verify it, there is a need for some regulatory mechanism, usually including transaction fees, to prevent abuse. The default approach, used in bitcoin, is to have purely voluntary fees, relying on miners to act as gatekeepers and set rolling lows. This approach has been received very favorably in the bitcoin community, particularly because it is “market-based,” allowing supply and demand between miners and transaction senders to determine the price. however, the problem with this line of reasoning is that transaction processing is not a market; Although it is intuitively appealing to interpret transaction processing as a service that the miner offers to the sender, in reality every transaction involving a miner will need to be processed by every node in the network, so the vast majority of the cost of the transaction is processing. it is the responsibility of third parties and not the miner who is making the decision to include it or not. therefore, tragedy of the commons issues are very likely to occur.

        However, it turns out that this flaw in the market-based mechanism, when given a particular inaccurate simplifying assumption, magically cancels itself out. the argument is as follows. suppose that:

        1. a transaction leads to k trades, offering the reward kr to any miner who includes it, where the sender sets r and k and r are (approximately) visible to the miner beforehand.
        2. a trade has a processing cost of c for any node (i.e. all nodes have the same efficiency)
        3. there are n mining nodes, each with exactly the same processing power (i.e. 1/n of the total)
        4. No full non-mining nodes exist.

        A miner would be willing to process a transaction if the expected reward is greater than the cost. therefore, the expected reward is kr/n since the miner has a 1/n probability of processing the next block, and the processing cost to the miner is simply kc. therefore miners will include transactions where kr/n > kc, or r > North Carolina. note that r is the fee per transaction provided by the sender and is therefore a lower bound on the profit the sender makes from the transaction, and nc is the cost to the entire network of processing a transaction. therefore, miners have an incentive to include only those transactions where the total utility benefit exceeds the cost.

        however, there are several major deviations from those assumptions in reality:

        1. the miner pays a higher cost to process the transaction than the other verification nodes, as the additional verification time delays the propagation of the block and thus increases the chance that the block will be become obsolete.
        2. there are non-mining full nodes.
        3. the distribution of mining power can end up being radically unequal in practice.
        4. there are speculators, political enemies and madmen whose utility function includes causing damage to the network. , and they can intelligently establish contracts where their cost is much lower than the cost paid by other verification nodes.

        (1) provides a trend for the miner to include fewer transactions, and (2) increases nc; therefore, these two effects cancel each other out at least partially. What? (3) and (4) are the main problem; to solve them we simply institute a floating cap: no block can have more trades than blk_limit_factor multiplied by the long-term exponential moving average. specifically:

        blk_limit_factor and ema_factor are constants that will be set to 65536 and 1.5 for now, but will likely be changed after further analysis.

        There is another factor that discourages large block sizes in bitcoin: blocks that are large will take longer to propagate and therefore have a higher chance of becoming stale. on ethereum, gas-hungry blocks can also take longer to propagate because they are physically larger and because they take longer to process transaction state transitions to validate. this delay disincentive is a major consideration in bitcoin, but less so in ethereum due to the ghost protocol; therefore, relying on regulated block limits provides a more stable baseline.

        computation and turing-completeness

        an important note is that the ethereum virtual machine is complete; this means that the evm code can code any calculation that can be performed, including infinite loops. the evm code allows looping in two ways. First, there is a jump statement that allows the program to return to an earlier point in the code, and a jumpi statement to perform conditional jumps, allowing statements like while x < 27: x = x * 2. Second, contracts can call other contracts, potentially allowing a recursive loop. this naturally leads to a problem: can malicious users shut down miners and full nodes by forcing them into an infinite loop? the problem arises because of a problem in computing known as the halting problem: there is no way of knowing, in the general case, whether a given program will halt or not.

        As described in the state transition section, our solution works by requiring a transaction to set a maximum number of computational steps it is allowed to take, and if the execution takes longer, the computation is rolled back but still paying the fees. messages work the same way. To show the motivation behind our solution, consider the following examples:

        • an attacker creates a contract that executes an infinite loop and then sends a transaction that triggers that loop to the miner. the miner will process the transaction, run the infinite loop and wait for it to run out of gas. even though the execution runs out of fuel and stops midway, the transaction is still valid and the miner still claims the attacker’s fee for each computational step.
        • an attacker creates a very long infinite loop with the The intention is to force the miner to continue computing for so long that, when the calculation is finished, a few more blocks will have come out and it will not be possible for the miner to include the transaction to claim the fee. however, the attacker will need to send a value for startgas that limits the number of computational steps the execution can take, so the miner will know in advance that the computation will take an excessively large number of steps.
        • An attacker sees a contract with code in some form like send(to,contract.store[to]); contract.storage[a] = 0, and sends a transaction with enough gas to execute the first step but not the second (i.e. make a withdrawal but not let the balance go down). the contract author need not worry about protecting against such attacks, because if execution stops midway, the changes are rolled back.
        • a financial contract works by taking the median of nine proprietary data sources to minimize risk. an attacker seizes one of the data sources, which is designed to be writable via the variable address call mechanism described in the section on data, and converts it to run an infinite loop, thereby attempting to force any attempt to claim funds from the financial contract to run out of gasoline. however, the financial contract may set a gas limit in the message to avoid this problem.

        The alternative to turing-completeness is turing-incompleteness, where jump and jumpi do not exist and only one copy of each contract is allowed to exist on the call stack at any given time. with this system, the fee system described and the uncertainties around the effectiveness of our solution might not be necessary, since the cost of executing a contract would be limited by its size. furthermore, turing incompleteness isn’t even that big of a limitation; Of all the contract examples we’ve devised internally, so far only one required a loop, and even that loop could be eliminated by doing 26 iterations of a one-line piece of code. given the serious implications of turing completeness and limited benefit, why not just have an incomplete turing language? In reality, however, Turing incompleteness is far from a neat solution to the problem. To see why, consider the following contracts:

        now send a transaction to a. thus, in 51 transactions, we have a contract that takes 250 computational steps. miners could try to detect such logic bombs ahead of time by keeping a value along with each contract that specifies the maximum number of computational steps it can take, and calculating this for contracts that call other contracts recursively, but that would require miners to ban contracts that create other contracts (since the creation and execution of the previous 26 contracts could easily be integrated into a single contract). another sticking point is that the address field of a message is a variable, so in general it may not even be possible to know what other contracts a given contract will call in advance. so, in general, we have a surprising conclusion: turing completeness is surprisingly easy to handle, and turing non-integrity is equally surprisingly hard to handle unless exactly the same checks are set, but in that case, why not just let the protocol be turing-complete?

        currency and issue

        The ethereum network includes its own integrated currency, ether, which has the dual purpose of providing a primary liquidity layer to enable efficient exchange between various types of digital assets, and more importantly, providing a mechanism to pay fee transactions. For convenience and to avoid future discussions (see the current debate on mbtc/ubtc/satoshi in bitcoin), the denominations will be pre-labeled:

        • 1: wei
        • 1012: szabo
        • 1015: finney
        • 1018: ether

        this should be taken as an expanded version of the concept of “dollars” and “cents” or “btc” and “satoshi”. in the near future, we expect “ether” to be used for ordinary transactions, “finney” for microtransactions, and “szabo” and “wei” for technical discussions on fees and protocol implementation; the remaining denominations may become useful later and should not be included in clients at this time.

        the issuance model will be as follows:

          early buyers will benefit from greater discounts. the btc received from the sale will be used in its entirety to pay salaries and rewards to developers and will be invested in various for-profit and non-profit projects in the ethereum and cryptocurrency ecosystem.
        • 0.099x the amount total amount sold ( 60102216 eth) will be allocated to the organization to compensate early contributors and pay for eth-denominated expenses before the genesis block.
        • 0.099x of the total amount sold will be held as a long-term reserve .</li
        • 0.26 times the total amount sold will be allocated to miners per year forever after that point.

        long-run supply growth rate (percent)

        despite linear currency issuance, as with bitcoin, over time the growth rate of supply tends to zero.

        The two main options in the model above are (1) the existence and size of an endowment fund and (2) the existence of a linear, ever-growing supply, as opposed to a limited supply as in bitcoin. The justification for the endowment fund is as follows. if the endowment fund did not exist and the linear issue were reduced to 0.217x to provide the same rate of inflation, then the total amount of ether would be 16.5% less and therefore each unit would be 19.8 % most valuable. therefore, in equilibrium, 19.8% more ether would be purchased in the sale, so each unit would again be exactly as valuable as before. the organization would also have 1.198x as much btc, which can be thought of as split into two parts: the original btc and the additional 0.198x. therefore, this situation is exactly equivalent to endowment, but with one important difference: the organization owns only btc and is therefore not incentivized to back the value of the ether unit.

        permanent linear supply growth model reduces the risk of what some see as an excessive concentration of wealth in bitcoin, and gives people living in the present and future a fair opportunity to acquire units while retaining a strong incentive to obtain and hold ether because the “supply growth rate” as a percentage still tends to zero over time. We also theorize that because coins are always lost over time due to carelessness, death, etc., and coin loss can be modeled as a percentage of the total supply per year, that the total circulating coin supply will in fact eventually will stabilize at a value equal to the annual emission divided by the loss rate (e.g. at a loss rate of 1%, once supply reaches 26x, 0.26x will be mined and 0.26x will be lost each year, creating a balance).

        Please note that in the future Ethereum will likely switch to a proof-of-stake model for security, reducing the issuance requirement by between zero and 0.05x per year. in the event that the ethereum organization loses funds or disappears for any other reason, we leave open a “social contract”: anyone has the right to create a future version candidate of ethereum, with the only condition that the amount of ether must be as maximum equal to 60102216 * (1.198 + 0.26 * n) where n is the number of years after the genesis block. Creators are free to crowd-sell or otherwise allocate some or all of the difference between the POS-driven bid expansion and the maximum allowable bid expansion to pay for development. candidate updates that do not comply with the social contract can be justifiably forked into compatible versions.

        mining centralization

        bitcoin’s mining algorithm works by having miners compute sha256 on slightly modified versions of the block header millions of times over and over again, until eventually a node submits a version whose hash is less than the target (currently around of 2192). however, this mining algorithm is vulnerable to two forms of centralization. First of all, the mining ecosystem has come to be dominated by ASICS (application-specific integrated circuits), computer chips designed for the specific task of bitcoin mining and thus thousands of times more efficient. This means that bitcoin mining is no longer a highly decentralized and egalitarian activity, requiring millions of dollars of capital to participate effectively. second, most bitcoin miners don’t actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers. This problem is arguably worse: at the time of writing, the top three mining pools indirectly control roughly 50% of the processing power on the bitcoin network, although this is mitigated by the fact that Miners can switch to other mining pools if one pool or coalition attempts a 51% attack.

        The current intention in ethereum is to use a mining algorithm where miners must get random data from the state, calculate some randomly selected transactions from the last n blocks in the blockchain, and return the hash of the result. this has two important benefits. first, ethereum contracts can include any type of calculation, so an ethereum asic would essentially be an asic for general calculation, ie. a better CPU. Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be able to verify each transaction. this eliminates the need for centralized mining pools; Although mining pools can still perform the legitimate function of equalizing the randomness of reward distribution, peer-to-peer pools without central control can perform this function just as well.

        This model has not been tested and there may be pitfalls in the way of avoiding certain smart optimizations when using contract execution as a mining algorithm. however, a remarkably interesting feature of this algorithm is that it allows anyone to “poison the well”, by introducing a large number of contracts on the blockchain specifically designed to hinder certain asics. there are economic incentives for asic manufacturers to use that trick to attack each other. therefore, the solution we are developing is ultimately an adaptive economic human solution rather than a purely technical solution.

        scalability

        A common concern about ethereum is the issue of scalability. Like bitcoin, ethereum has the flaw that each transaction must be processed by each node on the network. With bitcoin, the current block chain size is about 15GB, growing at about 1MB per hour. If the bitcoin network processed all 2,000 visa transactions per second, it would grow by 1MB per three seconds (1GB per hour, 8TB per year). Ethereum is likely to undergo a similar growth pattern, made worse by the fact that there will be many applications in addition to the ethereum blockchain rather than just one currency as is the case with bitcoin, but enhanced by the fact that nodes Ethereum full stacks need to store only the state instead of the entire history of the blockchain.

        The problem with such a large blockchain size is the risk of centralization. If the size of the blockchain increases to, say, 100TB, then the likely scenario would be that only a very small number of large companies would run full nodes, with all regular users running light spv nodes. In such a situation, there is a potential concern that full nodes may join together and all agree to cheat in some profitable way (e.g. change block reward, give each other btc). the light nodes would have no way of detecting this immediately. Of course, at least one honest full node is likely to exist, and after a few hours, information about the fraud will leak through channels like reddit, but by then it would be too late: it would be up to ordinary users to organize. an effort to blacklist given blocks, a massive and likely infeasible coordination problem on a scale similar to that of performing a successful 51% attack. In the case of bitcoin, this is currently a problem, but there is a blockchain modification suggested by peter todd that will alleviate this problem.

        In the short term, ethereum will use two additional strategies to deal with this problem. First, due to blockchain-based mining algorithms, at least every miner will be forced to be a full node, which creates a lower limit on the number of full nodes. second and more importantly, however, we will include an intermediate state tree root in the blockchain after each transaction is processed. even if block validation is centralized, as long as there is an honest verification node, the centralization problem can be avoided by a verification protocol. if a miner publishes an invalid block, that block must be badly formatted or the s[n] state is wrong. since s[0] is known to be correct, there must be some first state s[i] that is incorrect where s[i-1] is correct. the check node would provide the index i, along with an “invalidity test” consisting of the subset of nodes of the patricia tree that need to process apply(s[i-1],tx[i]) -> Yes]. nodes could use those nodes to run that part of the computation and see that the generated s[i] does not match the supplied s[i].

        Another more sophisticated attack would involve malicious miners posting incomplete blocks, so complete information doesn’t even exist to determine if the blocks are valid or not. the solution to this is a challenge-response protocol: verification nodes issue “challenges” in the form of target transaction indices, and upon receiving a node, a light node treats the block as untrusted until another node, either be it the miner or another verifier, it provides a subset of patrician nodes as proof of validity.

        conclusion

        the ethereum protocol was originally conceived as an enhanced version of a cryptocurrency, providing advanced features such as blockchain escrow, withdrawal limits, financial contracts, betting markets and the like through a programming language very widespread. the ethereum protocol would not “support” any of the applications directly, but the existence of a turing complete programming language means that arbitrary contracts can theoretically be created for any type of transaction or application. However, the most interesting thing about ethereum is that the ethereum protocol goes far beyond simple currency. protocols around decentralized file storage, decentralized computing, and decentralized prediction markets, among dozens of other similar concepts, have the potential to substantially increase the efficiency of the computing industry and provide a massive boost to other peer-to-peer protocols -peer when adding for the first time an economic layer. finally, there is also a wide variety of applications that have nothing to do with money.

        the concept of an arbitrary state transition function implemented by the ethereum protocol provides a platform with unique potential; Rather than being a single-purpose, closed protocol intended for a specific variety of applications in data storage, gaming, or finance, ethereum is open by design and we believe it is extremely well-suited to serving as a base layer for a large number of applications. financial and non-financial protocols in the coming years.

        notes and further reading

        notes

        1. A sophisticated reader may note that a bitcoin address is in fact the hash of the elliptic curve public key, and not the public key itself. however, in fact, it is perfectly legitimate cryptographic terminology to refer to the public key hash as a public key itself. this is because bitcoin cryptography can be thought of as a custom digital signature algorithm, where the public key consists of the hash of the ecc public key, the signature consists of the ecc public key concatenated with the ecc signature, and the verification algorithm involves verifying the ecc pubkey in the signature against the hash of the ecc public key provided as the public key and then verifying the ecc signature against the ecc public key.
        2. technically, the median of the 11 blocks above.
        3. internally, 2 and “charlie” are both fn3 numbers, with the latter in base-256 big-endian representation. the numbers can be at least 0 and at most 2256-1.

        further reading

        1. intrinsic value
        2. smart property
        3. smart contracts
        4. b-money
        5. reusable proofs of work</li
        6. secure property titles with the authority of the owner
        7. bitcoin whitepaper
        8. namecoin
        9. zooko triangle
        10. whitepaper of colored coins
        11. mastercoin white paper
        12. decentralized autonomous corporations, bitcoin magazine
        13. simplified payment verification
        14. merkle trees
        15. patricia trees
        16. ghost
        17. storj and autonomous agents, jeff garzik
        18. mike hearn on smart property at turing festival
        19. ethereum rlp
        20. ethereum merkle patricia trees
        21. peter todd at merkle sum trees

        For the history of the whitepaper, see this wiki.

        Ethereum, like many community-driven open source software projects, has evolved since its initial creation. To learn about the latest ethereum developments and how changes are made to the protocol, we recommend this guide.

        See also: 5 Best Use Cases of Ethereum Smart Contracts | Blockchain Council

Related Articles

Leave a Reply

Your email address will not be published.

Back to top button