pExplore Features Enterprise PricingBasicsHomeEthereum WhitepaperDesign RationaleEthereum Yellow PaperFAQEthereum ClientsWebthree CGeth Gopyeth Pythonapp Developmentapp Developer ResourcesJavaScript APIJSON RPC APISoliditySolidity FeaturesUseful app PatternsStandardized Contract APIsapp using MeteorEthereum development tutorialMix TutorialMix FeaturesSerpentLLLMutanΞV TechnologiesRLP EncodingRLPx Node Discovery ProtocolΞVp2p Wire ProtocolΞVp2p Whitepaper WiPWeb3 Secret StorageEthereum TechnologiesPatricia TreeWire protocolLight client protocolSubtletiesSolidity, Docs amp; ABINatSpec atContract ABIBad Block ReportingBad Chain CanaryExtra DataBrain WalletEthash/DashimotoEthashEthash C APIWhite PaperLefteris Karapetsas edited this page 21 days ago 15 revisionsA Next-Generation Smart Contract and DecentralizedApplication PlatSatoshi Nakamoto39;s development of Bitcoin in 2009 has often been hailed as a radicaldevelopment in money and currency, being the first example of a digital asset whichsimultaneously has no backing or quot;intrinsic valuequot; and no centralized issuer or controller. However,another, arguably more important, part of the Bitcoin experiment is the underlying blockchaintechnology as a tool of distributed consensus, and attention is rapidly starting to shift to this otheraspect of Bitcoin. Commonly cited alternative applications of blockchain technology include usingon-blockchain digital assets to represent custom currencies and financial instruments quot;coloredcoinsquot;, the ownership of an underlying physical device quot;smart propertyquot;, non-fungible assetssuch as domain names quot;Namecoinquot;, as well as more complex applications involving havingdigital assets being directly controlled by a piece of code implementing arbitrary rules quot;smartcontractsquot; or even blockchain-based quot;decentralized autonomous organizationsquot; DAOs. WhatEthereum intends to provide is a blockchain with a built-in fully fledged Turing-completeprogramming language that can be used to create quot;contractsquot; that can be used to encode arbitrarystate transition functions, allowing users to create any of the systems described above, as well asmany others that we have not yet imagined, simply by writing up the logic in a few lines of code.Table of ContentsHistoryBitcoin As A State Transition SystemMiningMerkle TreesAlternative Blockchain ApplicationsScriptingEthereumEthereum AccountsMessages and TransactionsEthereum State Transition FunctionCode cutionBlockchain and MiningApplicationsToken SystemsFinancial derivativesIdentity and Reputation SystemsDecentralized File StorageDecentralized Autonomous OrganizationsFurther ApplicationsMiscellanea And ConcernsModified GHOST ImplementationFeesComputation And Turing-CompletenessCurrency And IssuanceMining CentralizationScalability Sign up Sign inThis repository Search305 1,014 151 Watch  Star  Forkethereum/wiki Code  Issues 16  Pull requests 0  Wiki  Pulse  Graphs Pages 133Ethash DAGInfrastructure DevelopmentMordenInter-exchange Client AddressProtocolURL Hint ProtocolNatSpec DeterminationExchange IntegrationMiningLicensingNetwork StatusRaspberry PiConcerning WhisperWhisper ProposalWhisper OverviewPoC-1 Wire protocolPoC-2 Wire protocolPoC-2 WhitepaperMiscHard Problems ofCryptocurrencyChain FibersGlossaryClone this wiki locallyConclusionNotes and Further ReadingIntroduction to Bitcoin and Existing ConceptsHistoryThe concept of decentralized digital currency, as well as alternative applications like propertyregistries, has been around for decades. The anonymous e-cash protocols of the 1980s and the1990s, mostly reliant on a cryptographic primitive known as Chaumian blinding, provided acurrency with a high degree of privacy, but the protocols largely failed to gain traction because oftheir reliance on a centralized intermediary. In 1998, Wei Dai39;s b-money became the first proposalto introduce the idea of creating money through solving computational puzzles as well asdecentralized consensus, but the proposal was scant on details as to how decentralized consensuscould actually be implemented. In 2005, Hal Finney introduced a concept of quot;reusable proofs ofworkquot;, a system which uses ideas from b-money together with Adam Back39;s computationallydifficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of theideal by relying on trusted computing as a backend. In 2009, a decentralized currency was for thefirst time implemented in practice by Satoshi Nakamoto, combining established primitives anaging ownership through public key cryptography with a consensus algorithm for keeping trackof who owns coins, known as quot;proof of workquot;.The mechanism behind proof of work was a breakthrough in the space because it simultaneouslysolved two problems. First, it provided a simple and moderately effective consensus algorithm,allowing nodes in the network to collectively agree on a set of canonical updates to the state of theBitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process,solving the political problem of deciding who gets to influence the consensus, while simultaneouslypreventing sybil attacks. It does this by substituting a al barrier to participation, such as therequirement to be registered as a unique entity on a particular list, with an economic barrier - theweight of a single node in the consensus voting process is directly proportional to the computingpower that the node brings. Since then, an alternative approach has been proposed called proof ofstake, calculating the weight of a node as being proportional to its currency holdings and notcomputational resources; the discussion of the relative merits of the two approaches is beyond thescope of this paper but it should be noted that both approaches can be used to serve as thebackbone of a cryptocurrency.Bitcoin As A State Transition SystemFrom a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as astate transition system, where there is a quot;statequot; consisting of the ownership status of all existingbitcoins and a quot;state transition functionquot; that takes a state and a transaction and outputs a new statewhich is the result. In a standard banking system, for example, the state is a balance sheet, atransaction is a request to move X from A to B, and the state transition function reduces the valuein A39;s account by X and increases the value in B39;s account by X. If A39;s account has less than Xin the first place, the state transition function returns an error. Hence, one can ally defineAPPLYS,TX -gt; S39; or ERRORIn the banking system defined abovehttps// Alice 50, Bob 50 },quot;send 20 from Alice to Bobquot; { Alice 30, Bob 70 }ButAPPLY{ Alice 50, Bob 50 },quot;send 70 from Alice to Bobquot; ERRORThe quot;statequot; in Bitcoin is the collection of all coins technically, quot;unspent transaction outputsquot; orUTXO that have been minted and not yet spent, with each UTXO having a denomination and anowner defined by a 20-byte address which is essentially a cryptographic public key . Atransaction contains one or more s, with each containing a reference to an existingUTXO and a cryptographic signature produced by the private key associated with the owner39;saddress, and one or more outputs, with each output containing a new UTXO to be added to thestate.The state transition function nbsp;APPLYS,TX -gt; S39; nbsp;can be defined roughly as follows1. For each in nbsp;TX If the referenced UTXO is not in S , return an error.If the provided signature does not match the owner of the UTXO, return an error.2. If the sum of the denominations of all UTXO is less than the sum of the denominations ofall output UTXO, return an error.3. Return nbsp;S nbsp;with all UTXO removed and all output UTXO added.The first half of the first step prevents transaction senders from spending coins that do not exist, thesecond half of the first step prevents transaction senders from spending other people39;s coins, andthe second step enforces conservation of value. In order to use this for payment, the protocol is asfollows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of availableUTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to getexactly 11.7 BTC; say that the smallest she can get is 64212. She then creates a transactionwith those three s and two outputs. The first output will be 11.7 BTC with Bob39;s address as itsowner, and the second output will be the remaining 0.3 BTC quot;changequot;, with the owner being Aliceherself.MiningIf we had access to a trustworthy centralized service, this system would be trivial to implement; itcould simply be coded exactly as described, using a centralized server39;s hard drive to keep track ofthe state. However, with Bitcoin we are trying to build a decentralized currency system, so we willneed to combine the state transaction system with a consensus system in order to ensure thateveryone agrees on the order of transactions. Bitcoin39;s decentralized consensus process requiresnodes in the network to continuously attempt to produce packages of transactions called quot;blocksquot;.The network is intended to produce roughly one block every ten minutes, with each blockcontaining a timestamp, a nonce, a reference to ie. hash of the previous block and a list of all ofthe transactions that have taken place since the previous block. Over time, this creates a persistent,ever-growing, quot;blockchainquot; that constantly updates to represent the latest state of the Bitcoin ledger.The algorithm for checking if a block is valid, expressed in this paradigm, is as follows[1]1. Check if the previous block referenced by the block exists and is valid.2. Check that the timestamp of the block is greater than that of the previous block nbsp;and less than2 hours into the future3. Check that the proof of work on the block is valid.4. Let nbsp;S[0] nbsp;be the state at the end of the previous block.5. Suppose TX nbsp;is the block39;s transaction list with nbsp;n nbsp;transactions. For all nbsp;i nbsp;in nbsp;0...n-1 , setS[i1] APPLYS[i],TX[i] nbsp;If any application returns an error, exit and return false.6. Return true, and register S[n] nbsp;as the state at the end of this block.Essentially, each transaction in the block must provide a valid state transition from what was thecanonical state before the transaction was cuted to some new state. Note that the state is notencoded in the block in any way; it is purely an abstraction to be remembered by the validatingnode and can only be securely computed for any block by starting from the genesis state andsequentially applying every transaction in every block. Additionally, note that the order in which theminer includes transactions into the block matters; if there are two transactions A and B in a blocksuch that B spends a UTXO created by A, then the block will be valid if A comes before B but nototherwise.The one validity condition present in the above list that is not found in other systems is therequirement for quot;proof of workquot;. The precise condition is that the double-SHA256 hash of everyblock, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of thetime of this writing is approximately 2 . The purpose of this is to make block creationcomputationally quot;hardquot;, thereby preventing sybil attackers from remaking the entire blockchain intheir favor. Because SHA256 is designed to be a completely unpredictable pseudorandomfunction, the only way to create a valid block is simply trial and error, repeatedly incrementing thenonce and seeing if the new hash matches.At the current target of 2 , the network must make an average of 2 nbsp;tries before a valid block isfound; in general, the target is recalibrated by the network every 2016 blocks so that on average anew block is produced by some node in the network every ten minutes. In order to compensateminers for this computational work, the miner of every block is entitled to include a transactiongiving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher totaldenomination in its s than in its outputs, the difference also goes to the miner as a quot;transactionfeequot;. Incidentally, this is also the only mechanism by which BTC are issued; the genesis statecontained no coins at all.In order to better understand the purpose of mining, let us examine what happens in the event of amalicious attacker. Since Bitcoin39;s underlying cryptography is known to be secure, the attacker willtarget the one part of the Bitcoin system that is not protected by cryptography directly the order oftransactions. The attacker39;s strategy is simple1. Send 100 BTC to a merchant in exchange for some product preferably a rapid-delivery digitalgood2. Wait for the delivery of the product3. Produce another transaction sending the same 100 BTC to himself4. Try to convince the network that his transaction to himself was the one that came first.Once step 1 has taken place, after a few minutes some miner will include the transaction in ablock, say block number 270000. After about one hour, five more blocks will have been added tothe chain after that block, with each of those blocks indirectly pointing to the transaction and thusquot;confirmingquot; it. At this point, the merchant will accept the payment as finalized and deliver theproduct; since we are assuming this is a digital good, delivery is instant. Now, the attacker createsanother transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild,the transaction will not be processed; miners will attempt to run nbsp;APPLYS,TX nbsp;and notice that nbsp;TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a quot;forkquot; of theblockchain, starting by mining another version of block 270000 pointing to the same block 269999as a parent but with the new transaction in place of the old one. Because the block data is different,this requires redoing the proof of work. Furthermore, the attacker39;s new version of block 270000 hasa different hash, so the original blocks 270001 to 270005 do not quot;pointquot; to it; thus, the original chainand the attacker39;s new chain are completely separate. The rule is that in a fork the longest[2]187187 69blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while theattacker alone is working on the 270000 chain. In order for the attacker to make his blockchain thelongest, he would need to have more computational power than the rest of the network combined inorder to catch up hence, quot;51 attackquot;.Merkle TreesLeft it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validityof a branch.Right any attempt to change any part of the Merkle tree will eventually lead to an inconsistencysomewhere up the chain.An important scalability feature of Bitcoin is that the bl/p