Ethereum: Eine Plattform der nächsten Generation für Smart Contracts und dezentrale Anwendungen
Abstract
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 which simultaneously has no backing or intrinsic value and no centralized issuer or controller. However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments (colored coins), the ownership of an underlying physical device (smart property), non-fungible assets such as domain names (Namecoin), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules (smart contracts) or even blockchain-based decentralized autonomous organizations (DAOs).
What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty lines. Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness, and state.
Abstract
Ethereum ist eine Kryptowaehrungs- und dezentrale Anwendungsplattform der naechsten Generation, die eine Blockchain mit einer integrierten Turing-vollstaendigen Programmiersprache einfuehrt. Dies ermoeglicht es jedem, Smart Contracts und dezentrale Anwendungen zu schreiben, in denen sie ihre eigenen beliebigen Regeln fuer Eigentum, Transaktionsformate und Zustandsuebergangsfunktionen erstellen koennen.
Die grundlegende Innovation von Ethereum besteht darin, die von Bitcoin pionierhaft entwickelte Blockchain-Technologie mit einer universellen Programmierumgebung zu kombinieren. Waehrend Bitcoin ein einfaches Zustandsuebergangssystem zum Verschieben von Waehrung von einem Konto zu einem anderen bereitstellt, bietet Ethereum eine Plattform, auf der Entwickler jede Art von dezentraler Anwendung bauen koennen, die sie sich vorstellen koennen, von alternativen Waehrungen und Finanzinstrumenten bis hin zu Domain-Registrierungssystemen und dezentralen Organisationen.
Ethereum erreicht dies, indem es im Wesentlichen die ultimative abstrakte Grundschicht aufbaut: eine Blockchain mit einer integrierten Turing-vollstaendigen Programmiersprache, die es jedem ermoeglicht, Smart Contracts und dezentrale Anwendungen zu schreiben, in denen sie ihre eigenen beliebigen Regeln fuer Eigentum, Transaktionsformate und Zustandsuebergangsfunktionen erstellen koennen. Eine minimale Version von Namecoin kann in zwei Zeilen Code geschrieben werden, und andere Protokolle wie Waehrungen und Reputationssysteme koennen in weniger als zwanzig erstellt werden.
Introduction and Existing Concepts
The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the 1990s, mostly reliant 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 because of their reliance on a centralized intermediary. In 1998, Wei Dai's b-money became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney introduced a concept of reusable proofs of work, a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend.
In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, 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, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin 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 simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique 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 that the node brings. Since then, an alternative approach has been proposed called proof of stake, calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.
The Bitcoin blockchain has proven remarkably robust in practice over the subsequent years of operation, but it is inherently limited in what it can accomplish beyond simple value transfer. Bitcoin's scripting language is intentionally designed to be restrictive, lacking loops, Turing-completeness, and many other features that would be necessary to build more complex applications. This limitation, while providing safety from certain classes of attacks, severely restricts what can be built on top of Bitcoin. Over the following years, numerous attempts to extend Bitcoin's functionality emerged: colored coins sought to use the Bitcoin blockchain to track ownership of alternative assets, Namecoin attempted to create a decentralized name registration database, and various metacoin protocols aimed to build additional layers on top of Bitcoin's transaction format. While these approaches showed promise, they were ultimately constrained by Bitcoin's scripting capabilities and the inability to access blockchain data from within scripts.
What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.
Introduction and Existing Concepts
Das Konzept der dezentralen digitalen Waehrung sowie alternative Anwendungen wie Eigentumsregister existieren seit Jahrzehnten. Die anonymen E-Cash-Protokolle der 1980er und 1990er Jahre, die hauptsaechlich auf einem kryptographischen Primitiv namens Chaumian Blinding beruhten, boten eine Waehrung mit einem hohen Mass an Privatsphaere, doch die Protokolle konnten sich wegen ihrer Abhaengigkeit von einem zentralisierten Vermittler weitgehend nicht durchsetzen. 1998 wurde Wei Dais b-money zum ersten Vorschlag, der die Idee einfuehrte, Geld durch das Loesen von Rechenaufgaben sowie durch dezentralen Konsens zu schaffen, aber der Vorschlag enthielt nur wenige Details darueber, wie dezentraler Konsens tatsaechlich umgesetzt werden koennte.
Im Jahr 2009 wurde eine dezentrale Waehrung erstmals in der Praxis von Satoshi Nakamoto implementiert, indem etablierte Primitive fuer die Verwaltung von Eigentum durch Public-Key-Kryptographie mit einem Konsensalgorithmus zur Verfolgung des Coin-Besitzes kombiniert wurden, bekannt als "Proof of Work". Der Mechanismus hinter Proof of Work war ein Durchbruch in diesem Bereich, da er gleichzeitig zwei Probleme loeste. Erstens bot er einen einfachen und maessig effektiven Konsensalgorithmus, der es den Knoten im Netzwerk ermoeglichte, sich kollektiv auf eine Reihe kanonischer Aktualisierungen des Zustands des Bitcoin-Hauptbuchs zu einigen. Zweitens bot er einen Mechanismus fuer den freien Eintritt in den Konsensprozess, der das politische Problem loeiste, wer den Konsens beeinflussen darf, waehrend gleichzeitig Sybil-Angriffe verhindert wurden.
Die Bitcoin-Blockchain hat sich ueber ihre Betriebsjahre hinweg als bemerkenswert robust erwiesen, ist aber inhaerent begrenzt. Bitcoins Skriptsprache ist absichtlich so konzipiert, dass sie restriktiv und nicht-Turing-vollstaendig ist, ohne Schleifen und viele andere Funktionen, die fuer den Aufbau komplexerer Anwendungen erforderlich waeren. Diese Einschraenkung existiert, um Endlosschleifen und andere Formen von Rechenangriffen zu verhindern, schraenkt aber stark ein, was auf Bitcoin aufgebaut werden kann.
In den letzten fuenf Jahren gab es eine Reihe von Versuchen, die Funktionalitaet von Bitcoin zu erweitern. Colored Coins versuchten, die Bitcoin-Blockchain zur Verfolgung des Eigentums an alternativen Vermoegenswerten zu nutzen, Namecoin versuchte, eine dezentrale Namensregistrierungsdatenbank zu schaffen, und verschiedene Metacoin-Protokolle zielten darauf ab, zusaetzliche Schichten auf Bitcoin aufzubauen. Obwohl diese Ansaetze vielversprechend waren, waren sie letztlich durch die Skriptfaehigkeiten von Bitcoin und die Unfaehigkeit, auf Blockchain-Daten aus Skripten heraus zuzugreifen, begrenzt.
Was Ethereum bereitstellen will, ist eine Blockchain mit einer integrierten vollwertigen Turing-vollstaendigen Programmiersprache, die verwendet werden kann, um "Vertraege" zu erstellen, die beliebige Zustandsuebergangsfunktionen kodieren koennen, so dass Benutzer jedes der oben beschriebenen Systeme sowie viele andere, die wir uns noch nicht vorgestellt haben, erstellen koennen, indem sie die Logik einfach in wenigen Zeilen Code schreiben.
Bitcoin As A State Transition System
From a technical standpoint, the ledger of a cryptocurrency such as 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 "state transition function" that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move \(X from A to B, and the state transition function reduces the value in A's account by \)X and increases the value in B's account by \(X. If A's account has less than \)X in the first place, the state transition function returns an error. Hence, one can formally define:
APPLY(S,TX) - S' or ERROR
In the banking system defined above:
APPLY({ Alice: \(50, Bob: \)50 },send \(20 from Alice to Bob") = { Alice: \)30, Bob: $70 }
But:
APPLY({ Alice: \(50, Bob: \)50 },send $70 from Alice to Bob) = ERROR
The "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key). A transaction contains one or more inputs, with each input 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, with each output containing a new UTXO to be added to the state.
The state transition function APPLY(S,TX) - S' can be defined roughly as follows:
- For each input in 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.
- If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error.
- Return S with all input UTXO removed and all output UTXO added.
The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value. In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC "change", with the owner being Alice herself.
Bitcoin As A State Transition System
Aus technischer Sicht kann das Hauptbuch einer Kryptowaehrung wie Bitcoin als Zustandsuebergangssystem betrachtet werden, bei dem es einen "Zustand" gibt, der aus dem Eigentumsstatus aller existierenden Bitcoins besteht, und eine "Zustandsuebergangsfunktion", die einen Zustand und eine Transaktion nimmt und einen neuen Zustand als Ergebnis ausgibt. In einem Standard-Bankensystem ist beispielsweise der Zustand eine Bilanz, eine Transaktion ist eine Anforderung, \(X von A nach B zu verschieben, und die Zustandsuebergangsfunktion reduziert den Wert in As Konto um \)X und erhoeht den Wert in Bs Konto um \(X. Wenn As Konto von vornherein weniger als \)X hat, gibt die Zustandsuebergangsfunktion einen Fehler zurueck.
Der "Zustand" in Bitcoin ist die Sammlung aller Coins (technisch "nicht ausgegebene Transaktionsausgaben" oder UTXO), die gepraegt und noch nicht ausgegeben wurden, wobei jedes UTXO eine Denomination und einen Eigentuemer hat (definiert durch eine 20-Byte-Adresse, die im Wesentlichen ein kryptographischer oeffentlicher Schluessel ist). Eine Transaktion enthaelt eine oder mehrere Eingaben, wobei jede Eingabe eine Referenz auf ein existierendes UTXO und eine kryptographische Signatur enthaelt, die durch den mit der Adresse des Eigentuemers verknuepften privaten Schluessel erzeugt wurde, und eine oder mehrere Ausgaben, wobei jede Ausgabe ein neues UTXO enthaelt, das dem Zustand hinzugefuegt werden soll.
Die Zustandsuebergangsfunktion APPLY(S,TX) - S' kann ungefaehr wie folgt definiert werden:
- Fuer jede Eingabe in TX: Wenn das referenzierte UTXO nicht in S enthalten ist, Fehler zurueckgeben.
- Wenn die bereitgestellte Signatur nicht mit dem Eigentuemer des UTXO uebereinstimmt, Fehler zurueckgeben.
- Wenn die Summe der Denominationen aller Eingabe-UTXO kleiner ist als die Summe der Denominationen aller Ausgabe-UTXO, Fehler zurueckgeben.
- S zurueckgeben, wobei alle Eingabe-UTXO entfernt und alle Ausgabe-UTXO hinzugefuegt werden.
Die erste Haelfte des ersten Schritts verhindert, dass Transaktionssender Coins ausgeben, die nicht existieren, die zweite Haelfte des ersten Schritts verhindert, dass Transaktionssender die Coins anderer Leute ausgeben, und der zweite Schritt erzwingt die Werterhaltung. Um dies fuer eine Zahlung zu verwenden, ist das Protokoll wie folgt: Angenommen, Alice moechte 11,7 BTC an Bob senden. Zunaechst sucht Alice nach einem Satz verfuegbarer UTXO, die sie besitzt und die insgesamt mindestens 11,7 BTC ergeben. Realistischerweise wird Alice nicht genau 11,7 BTC bekommen koennen; sagen wir, das Kleinste, was sie bekommen kann, ist 6+4+2=12. Sie erstellt dann eine Transaktion mit diesen drei Eingaben und zwei Ausgaben. Die erste Ausgabe wird 11,7 BTC mit Bobs Adresse als Eigentuemer sein, und die zweite Ausgabe wird das verbleibende Wechselgeld von 0,3 BTC sein, dessen Eigentuemer Alice selbst ist.
Mining
If we had access to a trustworthy 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 the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks." The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e. hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, "blockchain" 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:
- Check if the previous block referenced by the block exists and is valid.
- Check that the timestamp of the block is greater than that of the previous block and less than 2 hours into the future.
- Check that the proof of work on the block is valid.
- Let
S[0]be the state at the end of the previous block. - Suppose TX is the block's transaction list 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. - Return true, and register
S[n]as the state at the end of this block.
Essentially, each transaction in the block must provide a valid state transition from what was 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 validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.
The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work." The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately \(2^{187}\). The purpose of this is to make block creation computationally "hard," thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudorandom 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.
At the current target of \(\sim 2^{187}\), the network must make an average of \(\sim 2^{69}\) tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in 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 contained no coins at all.
In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:
- Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good).
- Wait for the delivery of the product.
- Produce another transaction sending the same 100 BTC to himself.
- 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 a block, say block number 270000. After about one 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 finalized and deliver the product. Since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another 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 APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as 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 attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").
Mining
Haetten wir Zugang zu einem vertrauenswuerdigen zentralisierten Dienst, waere dieses System trivial zu implementieren; es koennte einfach genau wie beschrieben programmiert werden, wobei die Festplatte eines zentralen Servers verwendet wuerde, um den Zustand zu verfolgen. Mit Bitcoin versuchen wir jedoch, ein dezentrales Waehrungssystem aufzubauen, daher muessen wir das Zustandstransaktionssystem mit einem Konsenssystem kombinieren, um sicherzustellen, dass alle sich ueber die Reihenfolge der Transaktionen einig sind. Bitcoins dezentraler Konsensprozess erfordert, dass Knoten im Netzwerk kontinuierlich versuchen, Pakete von Transaktionen zu erstellen, die "Bloecke" genannt werden. Das Netzwerk soll ungefaehr alle zehn Minuten einen Block produzieren, wobei jeder Block einen Zeitstempel, einen Nonce, eine Referenz auf den (d.h. den Hash des) vorherigen Block und eine Liste aller Transaktionen enthaelt, die seit dem vorherigen Block stattgefunden haben.
Im Laufe der Zeit entsteht dadurch eine bestaendige, staendig wachsende "Blockchain", die sich kontinuierlich aktualisiert, um den neuesten Zustand des Bitcoin-Hauptbuchs darzustellen. Der Algorithmus zur Ueberpruefung, ob ein Block gueltig ist, ausdrueckt in diesem Paradigma, lautet wie folgt:
- Pruefen, ob der vom Block referenzierte vorherige Block existiert und gueltig ist.
- Pruefen, dass der Zeitstempel des Blocks groesser ist als der des vorherigen Blocks und weniger als 2 Stunden in der Zukunft liegt.
- Pruefen, dass der Proof of Work des Blocks gueltig ist.
- Sei S der Zustand am Ende des vorherigen Blocks.
- Angenommen, TX ist die Transaktionsliste des Blocks mit n Transaktionen. Fuer alle i in 0...n-1, setze S = APPLY(S,TX[i]). Wenn eine Anwendung einen Fehler zurueckgibt, beenden und falsch zurueckgeben.
- Wahr zurueckgeben und S als Zustand am Ende dieses Blocks registrieren.
Im Wesentlichen muss jede Transaktion im Block einen gueltigen Zustandsuebergang vom kanonischen Zustand vor der Ausfuehrung der Transaktion zu einem neuen Zustand liefern. Beachten Sie, dass der Zustand in keiner Weise im Block kodiert ist; er ist rein eine Abstraktion, die vom validierenden Knoten gespeichert wird und nur (sicher) fuer jeden Block berechnet werden kann, indem man vom Genesis-Zustand ausgeht und sequenziell jede Transaktion in jedem Block anwendet.
Der Miner wird fuer seine Rechenarbeit mit neu erzeugten Bitcoins plus Transaktionsgebuehren belohnt. Der Mining-Prozess funktioniert wie folgt: Miner nehmen den Block-Header und hashen ihn wiederholt mit verschiedenen Nonce-Werten, bis sie einen Hash finden, der unter einem bestimmten Schwierigkeitsziel liegt. Wenn ein Miner einen solchen Hash findet, verbreitet er den Block im Netzwerk, und andere Knoten verifizieren, dass der Hash gueltig ist und dass alle Transaktionen im Block gueltig sind. Das Schwierigkeitsziel wird automatisch vom Protokoll alle 2016 Bloecke (ungefaehr zwei Wochen) angepasst, um sicherzustellen, dass Bloecke mit einer ungefaehr konstanten Rate produziert werden.
Beachten Sie, dass langfristig die Sicherheit der Blockchain davon abhaengt, dass Miner einen finanziellen Anreiz haben, sich ehrlich zu verhalten. Wenn ein Angreifer mehr als 50% der Mining-Leistung des Netzwerks kontrolliert, kann er potenziell einen "51%-Angriff" ausfuehren, indem er eine alternative Blockchain erstellt, die schneller waechst als die ehrliche Kette. Ein solcher Angriff wuerde jedoch enorme Rechenressourcen erfordern und wuerde wahrscheinlich dazu fuehren, dass die Mining-Belohnungen des Angreifers wertlos werden, da das Netzwerk das Vertrauen in die Integritaet der Blockchain verlieren wuerde.
Merkle Trees
Merkle trees are a fundamental data structure used in Bitcoin blocks to enable efficient and secure verification of transaction inclusion. A Merkle tree is a binary tree of hashes where the leaf nodes contain hashes of individual transactions, and each interior node contains the hash of its two children, recursively building up to a single root hash that is stored in the block-header/" class="glossary-link" data-slug="block-header" title="block header">block header. This hierarchical structure allows anyone to verify that a specific transaction is included in a block by downloading only the Merkle branch—the chain of hashes from the transaction up to the root—rather than downloading all transactions in the block.
The efficiency gains are substantial: while a full Bitcoin node must store the entire blockchain (approximately 15GB as of 2013), a simplified payment verification (SPV) node only needs to download block headers containing Merkle roots, requiring just 4MB of data. To verify a transaction, an SPV node requests the Merkle branch from full nodes, which requires only \(O(\log n)\) data where \(n\) is the number of transactions in a block. This logarithmic scaling makes it feasible to run lightweight clients on mobile devices and low-resource environments.
Bitcoin's use of Merkle trees demonstrates a key principle: cryptographic structures can dramatically reduce the trust and resource requirements for participating in a decentralized network. This same principle underlies Ethereum's design, where Merkle trees are used not only for transactions but also for state and receipt storage, enabling even more sophisticated light client protocols.
Merkle Trees
Merkle-Baeume sind eine fundamentale Datenstruktur, die in Bitcoin-Bloecken verwendet wird, um eine effiziente und sichere Verifizierung der Transaktionsinklusion zu ermoeglichen. Ein Merkle-Baum ist ein binaerer Baum von Hashes, bei dem die Blattknoten Hashes einzelner Transaktionen enthalten und jeder innere Knoten den Hash seiner beiden Kinder enthaelt, wobei rekursiv bis zu einem einzigen Wurzel-Hash aufgebaut wird, der im Block-Header gespeichert ist. Diese hierarchische Struktur ermoeglicht es jedem zu verifizieren, dass eine bestimmte Transaktion in einem Block enthalten ist, indem nur der Merkle-Zweig heruntergeladen wird — die Kette von Hashes von der Transaktion bis zur Wurzel — anstatt alle Transaktionen im Block herunterzuladen.
Die Effizienzgewinne sind erheblich: Waehrend ein vollstaendiger Bitcoin-Knoten die gesamte Blockchain speichern muss (etwa 15 GB Stand 2013), muss ein Knoten fuer vereinfachte Zahlungsverifizierung (SPV) nur Block-Header mit Merkle-Wurzeln herunterladen, was lediglich 4 MB Daten erfordert. Um eine Transaktion zu verifizieren, fordert ein SPV-Knoten den Merkle-Zweig von vollstaendigen Knoten an, was nur O(log n) Daten erfordert, wobei n die Anzahl der Transaktionen in einem Block ist. Diese logarithmische Skalierung macht es moeglich, leichtgewichtige Clients auf mobilen Geraeten und in ressourcenarmen Umgebungen auszufuehren.
Bitcoins Verwendung von Merkle-Baeumen demonstriert ein Schluesselprinzip: Kryptographische Strukturen koennen die Vertrauens- und Ressourcenanforderungen fuer die Teilnahme an einem dezentralen Netzwerk drastisch reduzieren. Dasselbe Prinzip liegt dem Design von Ethereum zugrunde, wo Merkle-Baeume nicht nur fuer Transaktionen, sondern auch fuer Zustands- und Quittungsspeicherung verwendet werden, was noch ausgefeiltere Light-Client-Protokolle ermoeglicht.
Alternative Blockchain Applications
The success of Bitcoin's blockchain inspired numerous attempts to extend the concept beyond simple currency. Namecoin, launched in 2010, was one of the earliest examples—a decentralized name registration database built on a blockchain, allowing users to register names in a distributed namespace that no central authority could censor or revoke. Colored coins emerged as a way to represent alternative assets on the Bitcoin blockchain by "tagging" specific transaction outputs to represent ownership of real-world assets, company shares, or other cryptocurrencies. Metacoins and meta-protocols like Mastercoin (later Omni) layered additional functionality on top of Bitcoin by encoding extra data in Bitcoin transactions and building separate protocol rules on top.
However, all these approaches suffered from fundamental limitations imposed by Bitcoin's architecture. The Bitcoin scripting language is intentionally restricted—it cannot access blockchain state, lacks loops and complex control flow, and provides limited introspection into transaction values. Building sophisticated applications required awkward workarounds: encoding metadata in transaction fields never intended for that purpose, relying on off-chain infrastructure for complex logic, or accepting severe limitations on what the protocol could accomplish.
These constraints motivated the search for a more general-purpose blockchain platform. Rather than building yet another special-purpose protocol on top of Bitcoin's limited foundation, Ethereum takes a different approach: providing a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications with arbitrary rules for ownership, transaction formats, and state transition functions.
Alternative Blockchain Applications
Der Erfolg von Bitcoins Blockchain inspirierte zahlreiche Versuche, das Konzept ueber einfache Waehrung hinaus zu erweitern. Namecoin, gestartet 2010, war eines der fruehesten Beispiele — eine dezentrale Namensregistrierungsdatenbank, die auf einer Blockchain aufgebaut ist und es Benutzern ermoeglicht, Namen in einem verteilten Namensraum zu registrieren, den keine zentrale Behoerde zensieren oder widerrufen konnte. Colored Coins entstanden als Moeglichkeit, alternative Vermoegenswerte auf der Bitcoin-Blockchain darzustellen, indem bestimmte Transaktionsausgaben "markiert" wurden, um Eigentum an realen Vermoegenswerten, Unternehmensanteilen oder anderen Kryptowaehrungen zu repraesentieren. Metacoins und Meta-Protokolle wie Mastercoin (spaeter Omni) fueegten zusaetzliche Funktionalitaet ueber Bitcoin hinzu, indem sie zusaetzliche Daten in Bitcoin-Transaktionen kodierten und separate Protokollregeln darauf aufbauten.
Allerdings litten all diese Ansaetze unter fundamentalen Einschraenkungen, die durch Bitcoins Architektur auferlegt wurden. Die Bitcoin-Skriptsprache ist absichtlich eingeschraenkt — sie kann nicht auf den Blockchain-Zustand zugreifen, es fehlen Schleifen und komplexe Kontrollflussstrukturen, und sie bietet begrenzte Introspektion in Transaktionswerte. Der Aufbau anspruchsvoller Anwendungen erforderte unbeholfene Umgehungsloesungen: Kodierung von Metadaten in Transaktionsfeldern, die nie dafuer vorgesehen waren, Abhaengigkeit von Off-Chain-Infrastruktur fuer komplexe Logik oder Akzeptanz schwerwiegender Einschraenkungen dessen, was das Protokoll erreichen konnte.
Diese Einschraenkungen motivierten die Suche nach einer allgemeineren Blockchain-Plattform. Anstatt ein weiteres Spezialprotokoll auf Bitcoins begrenztem Fundament aufzubauen, verfolgt Ethereum einen anderen Ansatz: die Bereitstellung einer Blockchain mit einer integrierten Turing-vollstaendigen Programmiersprache, die es jedem ermoeglicht, Smart Contracts und dezentrale Anwendungen mit beliebigen Regeln fuer Eigentum, Transaktionsformate und Zustandsuebergangsfunktionen zu schreiben.
Scripting
Bitcoin Script, the language used to define spending conditions for Bitcoin transactions, is intentionally designed with severe limitations. It is not Turing-complete—most notably, it lacks loops and complex control flow structures. The language operates as a simple stack-based execution environment where operations push and pop values, evaluate cryptographic conditions, and ultimately return true or false to determine whether a transaction is valid. While this simplicity provides security benefits and makes formal analysis easier, it also makes many types of applications impossible to implement.
These limitations fall into three main categories. First, the lack of Turing-completeness prevents implementing complex state machines, decision trees, or any algorithm requiring iteration. Second, value-blindness means that scripts cannot specify fine-grained control over withdrawal amounts—a UTXO can only be spent in its entirety, with change sent to a new output. A script cannot, for example, limit withdrawals to a maximum of X per day while leaving the remainder locked. Third, the lack of blockchain state awareness means that UTXO are either spent or unspent with no intermediate states, making multi-stage contracts impossible to implement purely on-chain.
These constraints make sophisticated applications like decentralized autonomous organizations, savings wallets with withdrawal limits, decentralized exchanges, or prediction markets either impossible or require awkward off-chain mechanisms. An advanced financial contract might require access to market data, the ability to maintain internal state across multiple transactions, and complex conditional logic—none of which Bitcoin Script can provide. Ethereum removes these limitations by providing a Turing-complete language with full access to blockchain state.
Scripting
Bitcoin Script, die Sprache zur Definition von Ausgabebedingungen fuer Bitcoin-Transaktionen, ist absichtlich mit schwerwiegenden Einschraenkungen entworfen. Sie ist nicht Turing-vollstaendig — am auffaelligsten fehlen Schleifen und komplexe Kontrollflussstrukturen. Die Sprache funktioniert als einfache stapelbasierte Ausfuehrungsumgebung, in der Operationen Werte auf den Stapel legen und entfernen, kryptographische Bedingungen auswerten und letztendlich wahr oder falsch zurueckgeben, um zu bestimmen, ob eine Transaktion gueltig ist. Waehrend diese Einfachheit Sicherheitsvorteile bietet und formale Analyse erleichtert, macht sie auch viele Arten von Anwendungen unmoeglich zu implementieren.
Diese Einschraenkungen fallen in drei Hauptkategorien. Erstens verhindert das Fehlen von Turing-Vollstaendigkeit die Implementierung komplexer Zustandsmaschinen, Entscheidungsbaeume oder jedes Algorithmus, der Iteration erfordert. Zweitens bedeutet Wert-Blindheit, dass Skripte keine feingranulare Kontrolle ueber Abhebungsbetraege festlegen koennen — ein UTXO kann nur in seiner Gesamtheit ausgegeben werden, wobei Wechselgeld an eine neue Ausgabe gesendet wird. Ein Skript kann beispielsweise Abhebungen nicht auf maximal X pro Tag begrenzen, waehrend der Rest gesperrt bleibt. Drittens bedeutet das Fehlen von Blockchain-Zustandsbewusstsein, dass UTXO entweder ausgegeben oder nicht ausgegeben sind, ohne Zwischenzustaende, was mehrstufige Vertraege rein On-Chain unmoeglich macht.
Diese Einschraenkungen machen anspruchsvolle Anwendungen wie dezentrale autonome Organisationen, Sparwallets mit Abhebungslimits, dezentrale Boersen oder Vorhersagemaerkte entweder unmoeglich oder erfordern unbeholfene Off-Chain-Mechanismen. Ein fortgeschrittener Finanzvertrag koennte Zugang zu Marktdaten benoetigen, die Faehigkeit, einen internen Zustand ueber mehrere Transaktionen hinweg aufrechtzuerhalten, und komplexe bedingte Logik — nichts davon kann Bitcoin Script bereitstellen. Ethereum beseitigt diese Einschraenkungen, indem es eine Turing-vollstaendige Sprache mit vollem Zugriff auf den Blockchain-Zustand bereitstellt.
Ethereum
Ethereum's fundamental goal is to provide a blockchain with a built-in Turing-complete programming language that allows anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats, and state transition functions. Rather than designing a protocol for specific applications like currency, name registration, or asset trading, Ethereum provides a foundational layer—a blockchain-based distributed computing platform that developers can use to build any application they can imagine.
The architecture differs fundamentally from Bitcoin's UTXO model. Ethereum uses an account-based system where the blockchain state consists of a mapping from addresses to account objects. Each account has a balance, a transaction counter (nonce), and for contract accounts, associated code and storage. The platform includes a built-in Turing-complete programming language for writing contract code that executes in the Ethereum Virtual Machine (EVM), a stack-based execution environment that processes transactions and state transitions.
This generality enables a vast range of applications: alternative cryptocurrencies with custom issuance rules, financial derivatives and stablecoins, identity and reputation systems, decentralized file storage, decentralized autonomous organizations (DAOs), and much more. The whitepaper emphasizes that Ethereum is not optimized for any particular use case but instead provides the fundamental building blocks—accounts, transactions, a Turing-complete language, and gas-metered execution—that developers can combine to create whatever applications the ecosystem demands.
Ethereum
Das grundlegende Ziel von Ethereum ist die Bereitstellung einer Blockchain mit einer integrierten Turing-vollstaendigen Programmiersprache, die es jedem ermoeglicht, Smart Contracts und dezentrale Anwendungen zu schreiben, in denen sie ihre eigenen beliebigen Regeln fuer Eigentum, Transaktionsformate und Zustandsuebergangsfunktionen erstellen koennen. Anstatt ein Protokoll fuer spezifische Anwendungen wie Waehrung, Namensregistrierung oder Vermoegenswerthandel zu entwerfen, stellt Ethereum eine Grundschicht bereit — eine Blockchain-basierte verteilte Computerplattform, die Entwickler nutzen koennen, um jede Anwendung zu bauen, die sie sich vorstellen koennen.
Die Architektur unterscheidet sich grundlegend von Bitcoins UTXO-Modell. Ethereum verwendet ein kontobasiertes System, bei dem der Blockchain-Zustand aus einer Zuordnung von Adressen zu Kontoobjekten besteht. Jedes Konto hat ein Guthaben, einen Transaktionszaehler (Nonce) und fuer Vertragskonten zugehoerigen Code und Speicher. Die Plattform enthaelt eine integrierte Turing-vollstaendige Programmiersprache zum Schreiben von Vertragscode, der in der Ethereum Virtual Machine (EVM) ausgefuehrt wird, einer stapelbasierten Ausfuehrungsumgebung, die Transaktionen und Zustandsuebergaenge verarbeitet.
Diese Allgemeinheit ermoeglicht eine breite Palette von Anwendungen: alternative Kryptowaehrungen mit benutzerdefinierten Ausgaberegeln, Finanzderivate und Stablecoins, Identitaets- und Reputationssysteme, dezentraler Dateispeicher, dezentrale autonome Organisationen (DAOs) und vieles mehr. Das Whitepaper betont, dass Ethereum nicht fuer einen bestimmten Anwendungsfall optimiert ist, sondern die grundlegenden Bausteine bereitstellt — Konten, Transaktionen, eine Turing-vollstaendige Sprache und Gas-gemessene Ausfuehrung — die Entwickler kombinieren koennen, um die Anwendungen zu erstellen, die das Oekosystem erfordert.
Ethereum Accounts
In Ethereum, the state is made up of accounts, and there are two fundamental types. Externally owned accounts (EOAs) are controlled by private keys and have no associated code—they represent human users or external entities interacting with the blockchain. Contract accounts are controlled by their contract code and are activated when they receive a message or transaction. Both types share a common structure: every account has a nonce (a counter used to ensure each transaction can only be processed once), an ether balance, and for contracts specifically, contract code and persistent storage.
Ether is the primary internal cryptocurrency of Ethereum, serving as both a medium of value transfer and the fundamental unit for paying transaction fees (gas). Unlike Bitcoin's UTXO model where value is distributed across multiple unspent outputs, Ethereum accounts maintain a simple balance that increases when they receive ether and decreases when they send it. This account-based model simplifies many types of applications, particularly those requiring persistent state or complex access control, though it introduces different security considerations compared to Bitcoin's approach.
The distinction between EOAs and contract accounts is crucial to understanding Ethereum's operation. EOAs can initiate transactions by creating and signing messages with their private keys, paying gas fees to have their transactions included in blocks. Contract accounts cannot initiate transactions themselves but can send messages to other contracts in response to receiving a transaction or message, enabling complex chains of execution where a single external transaction triggers multiple contract-to-contract interactions.
Ethereum Accounts
In Ethereum besteht der Zustand aus Konten, und es gibt zwei grundlegende Typen. Extern kontrollierte Konten (EOAs) werden durch private Schluessel kontrolliert und haben keinen zugehoerigen Code — sie repraesentieren menschliche Benutzer oder externe Entitaeten, die mit der Blockchain interagieren. Vertragskonten werden durch ihren Vertragscode kontrolliert und werden aktiviert, wenn sie eine Nachricht oder Transaktion empfangen. Beide Typen teilen eine gemeinsame Struktur: Jedes Konto hat eine Nonce (einen Zaehler, der sicherstellt, dass jede Transaktion nur einmal verarbeitet werden kann), ein Ether-Guthaben und fuer Vertraege speziell Vertragscode und persistenten Speicher.
Ether ist die primaere interne Kryptowaehrung von Ethereum und dient sowohl als Mittel zur Wertuebertragung als auch als grundlegende Einheit zur Zahlung von Transaktionsgebuehren (Gas). Im Gegensatz zu Bitcoins UTXO-Modell, bei dem der Wert ueber mehrere nicht ausgegebene Ausgaben verteilt ist, fuehren Ethereum-Konten ein einfaches Guthaben, das steigt, wenn sie Ether empfangen, und sinkt, wenn sie Ether senden. Dieses kontobasierte Modell vereinfacht viele Arten von Anwendungen, insbesondere solche, die persistenten Zustand oder komplexe Zugriffskontrolle erfordern, obwohl es im Vergleich zu Bitcoins Ansatz andere Sicherheitsueberlegungen einfuehrt.
Die Unterscheidung zwischen EOAs und Vertragskonten ist entscheidend fuer das Verstaendnis der Funktionsweise von Ethereum. EOAs koennen Transaktionen initiieren, indem sie Nachrichten mit ihren privaten Schluesseln erstellen und signieren und Gas-Gebuehren zahlen, damit ihre Transaktionen in Bloecke aufgenommen werden. Vertragskonten koennen selbst keine Transaktionen initiieren, koennen aber Nachrichten an andere Vertraege senden, wenn sie eine Transaktion oder Nachricht empfangen, was komplexe Ausfuehrungsketten ermoeglicht, bei denen eine einzelne externe Transaktion mehrere Vertrag-zu-Vertrag-Interaktionen ausloest.
Messages and Transactions
Transactions in Ethereum are signed data packages created by externally owned accounts and broadcast to the network. A transaction contains the recipient address, a cryptographic signature proving the sender's identity, the amount of ether to transfer, an optional data field (crucial for interacting with contracts), STARTGAS (the maximum number of computational steps the transaction is allowed to take), and GASPRICE (the fee per computational step the sender is willing to pay). Miners collect these transactions, validate them, execute them, and include them in blocks, receiving the gas fees as compensation.
Messages are conceptually similar to transactions but are produced by contracts rather than external actors. When a contract's code executes, it can send messages to other contracts—these internal messages contain the sender (the contract address), recipient, an amount of ether to transfer, an optional data payload, and a STARTGAS limit. Messages enable contract-to-contract communication, allowing complex applications to be built from multiple interacting contracts rather than monolithic programs.
The gas mechanism is crucial for preventing abuse: every computational step, storage operation, and data byte in a transaction consumes gas. If a transaction runs out of gas before completing, all state changes are reverted (except the gas payment to the miner), preventing infinite loops or excessive computation from grinding the network to a halt. The sender specifies both the total gas budget (STARTGAS) and the price they're willing to pay per unit (GASPRICE), and any unused gas is refunded after execution completes.
Messages and Transactions
Transaktionen in Ethereum sind signierte Datenpakete, die von extern kontrollierten Konten erstellt und an das Netzwerk gesendet werden. Eine Transaktion enthaelt die Empfaengeradresse, eine kryptographische Signatur, die die Identitaet des Absenders beweist, die Menge an Ether zur Uebertragung, ein optionales Datenfeld (entscheidend fuer die Interaktion mit Vertraegen), STARTGAS (die maximale Anzahl von Berechnungsschritten, die die Transaktion durchfuehren darf) und GASPRICE (die Gebuehr pro Berechnungsschritt, die der Absender zu zahlen bereit ist). Miner sammeln diese Transaktionen, validieren sie, fuehren sie aus und nehmen sie in Bloecke auf, wobei sie die Gas-Gebuehren als Verguetung erhalten.
Nachrichten sind konzeptionell aehnlich wie Transaktionen, werden aber von Vertraegen statt von externen Akteuren erzeugt. Wenn der Code eines Vertrags ausgefuehrt wird, kann er Nachrichten an andere Vertraege senden — diese internen Nachrichten enthalten den Absender (die Vertragsadresse), den Empfaenger, eine Menge Ether zur Uebertragung, eine optionale Datennutzlast und ein STARTGAS-Limit. Nachrichten ermoeglichen die Vertrag-zu-Vertrag-Kommunikation und erlauben den Aufbau komplexer Anwendungen aus mehreren interagierenden Vertraegen statt aus monolithischen Programmen.
Der Gas-Mechanismus ist entscheidend zur Verhinderung von Missbrauch: Jeder Berechnungsschritt, jede Speicheroperation und jedes Datenbyte in einer Transaktion verbraucht Gas. Wenn einer Transaktion vor der Fertigstellung das Gas ausgeht, werden alle Zustandsaenderungen rueckgaengig gemacht (ausser der Gas-Zahlung an den Miner), was verhindert, dass Endlosschleifen oder uebermassige Berechnungen das Netzwerk lahmlegen. Der Absender gibt sowohl das gesamte Gas-Budget (STARTGAS) als auch den Preis an, den er pro Einheit zu zahlen bereit ist (GASPRICE), und ungenutztes Gas wird nach Abschluss der Ausfuehrung erstattet.
Ethereum State Transition Function
The Ethereum state transition function APPLY(S,TX) - S' defines how a transaction transforms the blockchain state, and it follows a precise sequence of steps. First, the system checks transaction validity: verifying the signature is correct, confirming the nonce matches the sender's account nonce, and ensuring the sender has sufficient balance to pay the upfront cost (STARTGAS × GASPRICE plus the value being sent). If any check fails, the transaction is rejected before execution begins. If valid, the transaction fee is deducted from the sender's account, the sender's nonce is incremented, and an initial gas counter is set to STARTGAS minus a per-byte fee for the transaction data.
Next, the system transfers the specified ether value from the sender to the recipient. If the recipient is an externally owned account, this completes the transaction. If the recipient is a contract account, the contract's code runs in the Ethereum Virtual Machine, consuming gas for each operation until either the code completes successfully, the code explicitly halts, or the gas runs out. During execution, the contract can read and modify its storage, send messages to other contracts, and create new contracts.
Finally, if the value transfer failed (insufficient balance) or code execution failed (running out of gas or hitting an error), all state changes are reverted—except that the sender still pays gas fees to the miner for the computation performed. If execution succeeded, the remaining gas is refunded to the sender, and the gas that was consumed is sent to the miner as a fee. This mechanism ensures that miners are compensated for computation while preventing runaway execution from consuming unbounded resources.
Ethereum State Transition Function
Die Ethereum-Zustandsuebergangsfunktion APPLY(S,TX) - S' definiert, wie eine Transaktion den Blockchain-Zustand transformiert, und folgt einer praezisen Abfolge von Schritten. Zuerst prueft das System die Transaktionsgueltigkeit: Es verifiziert die Korrektheit der Signatur, bestaetigt, dass die Nonce mit der Konto-Nonce des Absenders uebereinstimmt, und stellt sicher, dass der Absender ueber ausreichendes Guthaben verfuegt, um die Vorabkosten zu bezahlen (STARTGAS x GASPRICE plus den gesendeten Wert). Wenn eine Pruefung fehlschlaegt, wird die Transaktion vor Beginn der Ausfuehrung abgelehnt. Bei Gueltigkeit werden die Transaktionsgebuehren vom Konto des Absenders abgezogen, die Nonce des Absenders wird erhoeht, und ein anfaenglicher Gas-Zaehler wird auf STARTGAS minus einer Pro-Byte-Gebuehr fuer die Transaktionsdaten gesetzt.
Als Naechstes uebertraegt das System den angegebenen Ether-Wert vom Absender an den Empfaenger. Wenn der Empfaenger ein extern kontrolliertes Konto ist, wird die Transaktion damit abgeschlossen. Wenn der Empfaenger ein Vertragskonto ist, wird der Code des Vertrags in der Ethereum Virtual Machine ausgefuehrt, wobei fuer jede Operation Gas verbraucht wird, bis entweder der Code erfolgreich abgeschlossen wird, der Code explizit anhaelt oder das Gas aufgebraucht ist. Waehrend der Ausfuehrung kann der Vertrag seinen Speicher lesen und aendern, Nachrichten an andere Vertraege senden und neue Vertraege erstellen.
Schliesslich werden, wenn die Wertuebertragung fehlgeschlagen ist (unzureichendes Guthaben) oder die Code-Ausfuehrung fehlgeschlagen ist (Gas aufgebraucht oder Fehler aufgetreten), alle Zustandsaenderungen rueckgaengig gemacht — mit der Ausnahme, dass der Absender immer noch Gas-Gebuehren an den Miner fuer die durchgefuehrte Berechnung zahlt. Bei erfolgreicher Ausfuehrung wird das verbleibende Gas an den Absender erstattet, und das verbrauchte Gas wird als Gebuehr an den Miner gesendet. Dieser Mechanismus stellt sicher, dass Miner fuer Berechnungen entschaedigt werden, waehrend unkontrollierte Ausfuehrung daran gehindert wird, unbegrenzte Ressourcen zu verbrauchen.
Code Execution
The Ethereum Virtual Machine (EVM) is the runtime environment where contract code executes—a low-level, stack-based virtual machine similar in concept to the Java Virtual Machine or WebAssembly. Contract code is stored as a sequence of bytes, where each byte represents an operation (opcode) that the EVM can execute. The execution model is deliberately simple and deterministic: every node running the EVM with the same input state and transaction must arrive at the same output state, ensuring consensus across the network.
The EVM provides three distinct types of storage for computation. The stack is a last-in-first-out (LIFO) structure limited to 1024 elements, used for immediate operation values. Memory is an infinitely expandable byte array that persists only for the duration of a single message call and is reset between executions. Storage is the persistent key-value store permanently associated with each account/" class="glossary-link" data-slug="contract-account" title="contract account">contract account, where contracts maintain their long-term state across transactions. These storage types are priced differently in gas—stack and memory operations are cheap, while storage operations are expensive to prevent blockchain bloat.
During execution, contract code has access to crucial context: it can read the message sender's address, the amount of ether sent, the data payload provided by the caller, and block-level properties like the current block number, timestamp, and miner address. The code can return an output byte array to the caller and can send messages to other contracts or create new contracts. This execution model is Turing-complete—loops and complex control flow are possible—but the gas mechanism ensures that all computation terminates in bounded time, solving the halting problem economically rather than through language restrictions.
Code Execution
Die Ethereum Virtual Machine (EVM) ist die Laufzeitumgebung, in der Vertragscode ausgefuehrt wird — eine niedrigstufige, stapelbasierte virtuelle Maschine, die konzeptionell der Java Virtual Machine oder WebAssembly aehnelt. Vertragscode wird als Byte-Sequenz gespeichert, wobei jedes Byte eine Operation (Opcode) darstellt, die die EVM ausfuehren kann. Das Ausfuehrungsmodell ist bewusst einfach und deterministisch: Jeder Knoten, der die EVM mit demselben Eingabezustand und derselben Transaktion ausfuehrt, muss zum selben Ausgabezustand gelangen, was Konsens im Netzwerk gewaehrleistet.
Die EVM stellt drei verschiedene Speichertypen fuer Berechnungen bereit. Der Stapel ist eine Last-In-First-Out (LIFO)-Struktur, die auf 1024 Elemente begrenzt ist und fuer unmittelbare Operationswerte verwendet wird. Der Arbeitsspeicher ist ein unendlich erweiterbares Byte-Array, das nur fuer die Dauer eines einzelnen Nachrichtenaufrufs besteht und zwischen Ausfuehrungen zurueckgesetzt wird. Der Speicher ist der persistente Schluessel-Wert-Speicher, der dauerhaft mit jedem Vertragskonto verbunden ist und in dem Vertraege ihren langfristigen Zustand ueber Transaktionen hinweg pflegen. Diese Speichertypen werden unterschiedlich in Gas bepreist — Stapel- und Arbeitsspeicheroperationen sind guenstig, waehrend Speicheroperationen teuer sind, um ein Aufblaehen der Blockchain zu verhindern.
Waehrend der Ausfuehrung hat Vertragscode Zugriff auf entscheidenden Kontext: Er kann die Adresse des Nachrichtenabsenders lesen, die Menge des gesendeten Ethers, die vom Aufrufer bereitgestellte Datennutzlast und Block-Level-Eigenschaften wie die aktuelle Blocknummer, den Zeitstempel und die Miner-Adresse. Der Code kann ein Ausgabe-Byte-Array an den Aufrufer zurueckgeben und kann Nachrichten an andere Vertraege senden oder neue Vertraege erstellen. Dieses Ausfuehrungsmodell ist Turing-vollstaendig — Schleifen und komplexer Kontrollfluss sind moeglich — aber der Gas-Mechanismus stellt sicher, dass alle Berechnungen in begrenzter Zeit terminieren und loest das Halteproblem oekonomisch statt durch Spracheinschraenkungen.
Blockchain and Mining
The Ethereum blockchain is fundamentally similar to Bitcoin's, serving as a database containing every transaction ever executed. However, while Bitcoin stores only a transaction list, Ethereum stores both the transaction list and the most recent state. Each block in Ethereum contains the previous block's hash, a state root (the root hash of the Patricia trie">Merkle Patricia trie representing the entire state), a transaction root, a receipt root (storing data from transaction execution), along with difficulty, timestamp, and nonce values. The state itself is a large Merkle Patricia trie mapping addresses to account objects, where each account has a balance, nonce, code (if present), and storage.
Ethereum uses a modified version of the GHOST (Greedy Heaviest Observed Subtree) protocol to address security issues that arise from fast block times. In traditional longest-chain protocols, fast blocks lead to high stale rates, reducing network security and increasing centralization risks as large miners waste less computation on stales. GHOST includes stale blocks (called "uncles" in Ethereum) in the calculation of which chain is longest, and provides partial rewards to uncle blocks, incentivizing miners to reference them. This allows Ethereum to maintain a target block time of approximately 12 seconds while preserving network security.
The mining algorithm works similarly to Bitcoin's proof-of-work, requiring miners to find a nonce such that the hash of the block is below a certain difficulty target. However, Ethereum's memory-hard mining algorithm (Ethash) is designed to be ASIC-resistant, promoting a more decentralized mining ecosystem. The difficulty adjusts dynamically based on block times to maintain the ~12 second target, ensuring consistent block production while the GHOST protocol provides security guarantees despite the faster block times compared to Bitcoin's 10-minute average.
Blockchain and Mining
Die Ethereum-Blockchain ist grundsaetzlich aehnlich wie die von Bitcoin und dient als Datenbank, die jede jemals ausgefuehrte Transaktion enthaelt. Waehrend Bitcoin jedoch nur eine Transaktionsliste speichert, speichert Ethereum sowohl die Transaktionsliste als auch den aktuellsten Zustand. Jeder Block in Ethereum enthaelt den Hash des vorherigen Blocks, eine Zustandswurzel (den Wurzel-Hash des Merkle-Patricia-Tries, der den gesamten Zustand repraesentiert), eine Transaktionswurzel, eine Quittungswurzel (die Daten aus der Transaktionsausfuehrung speichert) sowie Schwierigkeits-, Zeitstempel- und Nonce-Werte. Der Zustand selbst ist ein grosser Merkle-Patricia-Trie, der Adressen auf Kontoobjekte abbildet, wobei jedes Konto ein Guthaben, eine Nonce, Code (falls vorhanden) und Speicher hat.
Ethereum verwendet eine modifizierte Version des GHOST-Protokolls (Greedy Heaviest Observed Subtree), um Sicherheitsprobleme zu adressieren, die durch schnelle Blockzeiten entstehen. In traditionellen Laengste-Kette-Protokollen fuehren schnelle Bloecke zu hohen Veralterungsraten, was die Netzwerksicherheit verringert und Zentralisierungsrisiken erhoeht, da grosse Miner weniger Berechnung durch veraltete Bloecke verschwenden. GHOST bezieht veraltete Bloecke (in Ethereum "Onkel" genannt) in die Berechnung ein, welche Kette die laengste ist, und bietet teilweise Belohnungen fuer Onkel-Bloecke, was Miner ermutigt, diese zu referenzieren. Dies ermoeglicht es Ethereum, eine Ziel-Blockzeit von etwa 12 Sekunden beizubehalten und gleichzeitig die Netzwerksicherheit zu erhalten.
Der Mining-Algorithmus funktioniert aehnlich wie Bitcoins Proof-of-Work und erfordert, dass Miner eine Nonce finden, bei der der Hash des Blocks unter einem bestimmten Schwierigkeitsziel liegt. Allerdings ist Ethereums speicherintensiver Mining-Algorithmus (Ethash) darauf ausgelegt, ASIC-resistent zu sein und ein staerker dezentralisiertes Mining-Oekosystem zu foerdern. Die Schwierigkeit passt sich dynamisch basierend auf Blockzeiten an, um das Ziel von ~12 Sekunden beizubehalten, was eine konsistente Blockproduktion sicherstellt, waehrend das GHOST-Protokoll Sicherheitsgarantien trotz der schnelleren Blockzeiten im Vergleich zu Bitcoins durchschnittlichen 10 Minuten bietet.
Applications
The applications that can be built on Ethereum fall into three broad categories. The first category is financial applications, providing users with more powerful ways to manage and enter contracts involving their money. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets with withdrawal limits, wills that distribute funds automatically, and even employment contracts that calculate payment based on verified work completion. These applications leverage Ethereum's programmability to create complex financial instruments that would be impossible or extremely difficult to implement in traditional systems or even on Bitcoin.
The second category is semi-financial applications, where money is involved but there is also a substantial non-monetary component to what is being done. A perfect example is self-enforcing bounties for solutions to computational problems. Someone could post a computational problem along with a reward, and the contract could automatically verify submitted solutions and pay out the bounty to the first correct answer. This category bridges pure finance and other domains, using economic incentives to solve problems or coordinate behavior.
The third category is applications that have nothing to do with money at all, such as online voting and decentralized governance systems. These non-financial applications demonstrate Ethereum's flexibility as a general-purpose platform. Examples include decentralized domain name systems like Namecoin, reputation systems, decentralized file storage, and organizational governance tools. Of all these application types, token systems have emerged as the most common and fundamental, serving as building blocks for many other applications.
Applications
Die Anwendungen, die auf Ethereum aufgebaut werden koennen, fallen in drei breite Kategorien. Die erste Kategorie sind Finanzanwendungen, die Benutzern leistungsfaehigere Moeglichkeiten bieten, ihr Geld zu verwalten und Vertraege abzuschliessen. Dazu gehoeren Sub-Waehrungen, Finanzderivate, Absicherungsvertraege, Sparwallets mit Abhebungslimits, Testamente, die Gelder automatisch verteilen, und sogar Arbeitsvertraege, die Zahlungen basierend auf verifizierter Arbeitserfuellung berechnen. Diese Anwendungen nutzen die Programmierbarkeit von Ethereum, um komplexe Finanzinstrumente zu schaffen, die in traditionellen Systemen oder sogar auf Bitcoin unmoeglich oder extrem schwierig zu implementieren waeren.
Die zweite Kategorie sind halbfinanzielle Anwendungen, bei denen Geld involviert ist, aber auch eine wesentliche nicht-monetaere Komponente vorhanden ist. Ein perfektes Beispiel sind selbstdurchsetzende Kopfgelder fuer Loesungen von Berechnungsproblemen. Jemand koennte ein Berechnungsproblem zusammen mit einer Belohnung veroeffentlichen, und der Vertrag koennte eingereichte Loesungen automatisch verifizieren und das Kopfgeld an die erste korrekte Antwort auszahlen. Diese Kategorie verbindet reine Finanzen mit anderen Bereichen und nutzt wirtschaftliche Anreize zur Problemloesung oder Verhaltenskoordination.
Die dritte Kategorie sind Anwendungen, die ueberhaupt nichts mit Geld zu tun haben, wie Online-Abstimmungen und dezentrale Governance-Systeme. Diese nicht-finanziellen Anwendungen demonstrieren Ethereums Flexibilitaet als universelle Plattform. Beispiele umfassen dezentrale Domain-Namen-Systeme wie Namecoin, Reputationssysteme, dezentraler Dateispeicher und organisatorische Governance-Werkzeuge. Von all diesen Anwendungstypen haben sich Token-Systeme als die verbreitetsten und grundlegendsten herausgestellt und dienen als Bausteine fuer viele andere Anwendungen.
Token Systems
Token systems are surprisingly straightforward to implement on Ethereum, despite being one of the most powerful and common applications. At their core, token systems are simply a database with a single operation: subtract X units from account A and add X units to account B, with the condition that A had at least X units before the transaction and the transaction is authorized by A. The implementation requires maintaining a mapping of addresses to balances and providing a transfer function that performs the appropriate checks before moving tokens between accounts.
The contract code for a basic token system is remarkably simple and can be written in just a few lines. It consists of a data structure mapping addresses to balances, an initialization function that assigns initial token supply, and a transfer function that checks the sender's balance and authorization before executing the transfer. This simplicity stands in stark contrast to the complexity required to implement similar systems on Bitcoin, which would require significant workarounds and limitations due to Bitcoin's restricted scripting capabilities.
Tokens on Ethereum can represent virtually anything of value. They might represent sub-currencies with their own monetary policies, financial derivatives tracking external assets, company shares with dividend rights, loyalty points in customer programs, commodities like gold or oil, or even representations of physical property. The programmability of Ethereum allows these tokens to have arbitrary rules governing their behavior, such as transfer restrictions, automatic burning mechanisms, dividend distributions, or governance rights. This flexibility has made token systems the foundational building block for much of the Ethereum ecosystem.
Token Systems
Token-Systeme sind ueberraschend einfach auf Ethereum zu implementieren, obwohl sie eine der leistungsfaehigsten und verbreitetsten Anwendungen darstellen. Im Kern sind Token-Systeme einfach eine Datenbank mit einer einzigen Operation: X Einheiten von Konto A abziehen und X Einheiten zu Konto B hinzufuegen, unter der Bedingung, dass A vor der Transaktion mindestens X Einheiten hatte und die Transaktion von A autorisiert ist. Die Implementierung erfordert die Pflege einer Zuordnung von Adressen zu Guthaben und die Bereitstellung einer Transfer-Funktion, die die entsprechenden Pruefungen durchfuehrt, bevor Token zwischen Konten verschoben werden.
Der Vertragscode fuer ein grundlegendes Token-System ist bemerkenswert einfach und kann in nur wenigen Zeilen geschrieben werden. Er besteht aus einer Datenstruktur, die Adressen auf Guthaben abbildet, einer Initialisierungsfunktion, die den anfaenglichen Token-Vorrat zuweist, und einer Transfer-Funktion, die das Guthaben und die Autorisierung des Absenders prueft, bevor der Transfer ausgefuehrt wird. Diese Einfachheit steht in starkem Kontrast zur Komplexitaet, die fuer die Implementierung aehnlicher Systeme auf Bitcoin erforderlich waere, was erhebliche Umgehungsloesungen und Einschraenkungen aufgrund der begrenzten Skriptfaehigkeiten von Bitcoin erfordern wuerde.
Token auf Ethereum koennen praktisch alles von Wert repraesentieren. Sie koennten Sub-Waehrungen mit eigener Geldpolitik repraesentieren, Finanzderivate, die externe Vermoegenswerte verfolgen, Unternehmensanteile mit Dividendenrechten, Treuepunkte in Kundenprogrammen, Rohstoffe wie Gold oder Oel, oder sogar Darstellungen von physischem Eigentum. Die Programmierbarkeit von Ethereum erlaubt es diesen Token, beliebige Regeln fuer ihr Verhalten zu haben, wie Transferbeschraenkungen, automatische Vernichtungsmechanismen, Dividendenverteilungen oder Governance-Rechte. Diese Flexibilitaet hat Token-Systeme zum grundlegenden Baustein fuer einen Grossteil des Ethereum-Oekosystems gemacht.
Financial Derivatives and Stable-Value Currencies
Financial derivatives represent one of the most fundamental and important applications of Ethereum smart contracts. A simple hedging contract demonstrates the basic mechanism: party A deposits a certain amount of ether worth \(1000, party B deposits an equivalent amount, and the contract records the USD value of ether at that moment using a data feed. After 30 days, the contract recalculates the value and sends ether worth \)1000 to A and the remainder to B. If the price of ether has risen, A receives fewer ether but maintains $1000 value; if it has fallen, A receives more ether to maintain that value. This allows A to hedge against volatility while B speculates on price movements.
The implementation of such contracts requires access to external data through oracle contracts or data feeds. These oracles provide price information, weather data, or other real-world information that contracts need to execute properly. While oracles introduce a trust dependency, they can be designed with redundancy and cryptoeconomic incentives to provide reliable data. The contract itself simply queries the oracle, performs calculations based on that data, and distributes funds according to its programmed logic.
Stablecoins and more complex financial instruments can be built using similar mechanisms. A stablecoin contract might maintain a reserve of ether and issue tokens pegged to a fiat currency, automatically adjusting supply or collateral requirements based on price feeds. Options contracts, futures, swaps, and other derivatives that would normally require complex legal frameworks and trusted intermediaries can instead be encoded as self-executing smart contracts. This programmable finance infrastructure enables sophisticated financial engineering while maintaining the transparency and security guarantees of blockchain technology.
Financial Derivatives and Stable-Value Currencies
Finanzderivate stellen eine der grundlegendsten und wichtigsten Anwendungen von Ethereum Smart Contracts dar. Ein einfacher Absicherungsvertrag demonstriert den grundlegenden Mechanismus: Partei A hinterlegt eine bestimmte Menge Ether im Wert von 1000 \(, Partei B hinterlegt einen aequivalenten Betrag, und der Vertrag zeichnet den USD-Wert von Ether zu diesem Zeitpunkt ueber einen Datenfeed auf. Nach 30 Tagen berechnet der Vertrag den Wert neu und sendet Ether im Wert von 1000 \) an A und den Rest an B. Wenn der Preis von Ether gestiegen ist, erhaelt A weniger Ether, behaelt aber den Wert von 1000 $; wenn er gefallen ist, erhaelt A mehr Ether, um diesen Wert zu erhalten. Dies ermoeglicht es A, sich gegen Volatilitaet abzusichern, waehrend B auf Preisbewegungen spekuliert.
Die Implementierung solcher Vertraege erfordert Zugang zu externen Daten ueber Oracle-Vertraege oder Datenfeeds. Diese Orakel liefern Preisinformationen, Wetterdaten oder andere reale Informationen, die Vertraege fuer die korrekte Ausfuehrung benoetigen. Waehrend Orakel eine Vertrauensabhaengigkeit einfuehren, koennen sie mit Redundanz und kryptooekonomischen Anreizen gestaltet werden, um zuverlaessige Daten bereitzustellen. Der Vertrag selbst fragt einfach das Orakel ab, fuehrt Berechnungen basierend auf diesen Daten durch und verteilt Gelder gemaess seiner programmierten Logik.
Stablecoins und komplexere Finanzinstrumente koennen mit aehnlichen Mechanismen aufgebaut werden. Ein Stablecoin-Vertrag koennte eine Ether-Reserve halten und Token ausgeben, die an eine Fiat-Waehrung gekoppelt sind, wobei Angebot oder Sicherheitenanforderungen automatisch basierend auf Preisfeeds angepasst werden. Optionsvertraege, Futures, Swaps und andere Derivate, die normalerweise komplexe rechtliche Rahmenwerke und vertrauenswuerdige Vermittler erfordern wuerden, koennen stattdessen als selbstausfuehrende Smart Contracts kodiert werden. Diese programmierbare Finanzinfrastruktur ermoeglicht anspruchsvolles Financial Engineering bei gleichzeitiger Aufrechterhaltung der Transparenz- und Sicherheitsgarantien der Blockchain-Technologie.
Identity and Reputation Systems
A name registration system similar to Namecoin is trivially implementable on Ethereum and serves as the simplest example of an identity system. The contract maintains a database with a key-value table mapping names to associated data (such as IP addresses, public keys, or other information). Anyone can register a name by sending a transaction to the contract along with a small registration fee, provided that name is not already taken. The owner can update the associated data at any time, and names can be made transferable or permanent according to the rules encoded in the contract.
More advanced identity systems can be built on this foundation to include reputation scores, web of trust relationships, and decentralized identity verification. For example, a contract could maintain reputation scores based on verified transactions, peer ratings, or completion of tasks. These scores would be publicly visible and cryptographically tied to specific addresses, creating a portable reputation that follows users across applications. Web of trust systems could allow users to vouch for others' identities, building social graphs that help distinguish legitimate users from bad actors.
Such identity and reputation systems become particularly powerful when integrated with other applications. A marketplace could require minimum reputation scores for sellers, a loan platform could adjust interest rates based on borrower reputation, or a social network could use web of trust to filter spam and fraudulent content. By providing a shared infrastructure for identity that any application can query, Ethereum enables a new class of trust-based applications that don't rely on centralized identity providers or proprietary reputation systems.
Identity and Reputation Systems
Ein Namensregistrierungssystem aehnlich wie Namecoin ist trivial auf Ethereum implementierbar und dient als einfachstes Beispiel eines Identitaetssystems. Der Vertrag pflegt eine Datenbank mit einer Schluessel-Wert-Tabelle, die Namen zugehoerigen Daten zuordnet (wie IP-Adressen, oeffentliche Schluessel oder andere Informationen). Jeder kann einen Namen registrieren, indem er eine Transaktion an den Vertrag zusammen mit einer kleinen Registrierungsgebuehr sendet, vorausgesetzt, der Name ist noch nicht vergeben. Der Eigentuemer kann die zugehoerigen Daten jederzeit aktualisieren, und Namen koennen entsprechend den im Vertrag kodierten Regeln uebertragbar oder permanent gemacht werden.
Fortgeschrittenere Identitaetssysteme koennen auf dieser Grundlage aufgebaut werden und Reputationsbewertungen, Vertrauensnetzwerk-Beziehungen und dezentrale Identitaetsverifikation umfassen. Beispielsweise koennte ein Vertrag Reputationsbewertungen basierend auf verifizierten Transaktionen, Peer-Bewertungen oder Aufgabenerfuellung pflegen. Diese Bewertungen waeren oeffentlich sichtbar und kryptographisch an bestimmte Adressen gebunden, wodurch eine portable Reputation entsteht, die Benutzer ueber Anwendungen hinweg begleitet. Vertrauensnetzwerk-Systeme koennten es Benutzern ermoeglichen, fuer die Identitaet anderer zu buergen und soziale Graphen aufzubauen, die helfen, legitime Benutzer von boesartigen Akteuren zu unterscheiden.
Solche Identitaets- und Reputationssysteme werden besonders maechtig, wenn sie mit anderen Anwendungen integriert werden. Ein Marktplatz koennte Mindest-Reputationsbewertungen fuer Verkaeufer verlangen, eine Kreditplattform koennte Zinssaetze basierend auf der Reputation des Kreditnehmers anpassen, oder ein soziales Netzwerk koennte das Vertrauensnetzwerk nutzen, um Spam und betruegerische Inhalte zu filtern. Durch die Bereitstellung einer gemeinsamen Infrastruktur fuer Identitaet, die jede Anwendung abfragen kann, ermoeglicht Ethereum eine neue Klasse vertrauensbasierter Anwendungen, die nicht auf zentralisierte Identitaetsanbieter oder proprietaere Reputationssysteme angewiesen sind.
Decentralized File Storage
Decentralized file storage can be implemented through Ethereum contracts that coordinate between users who need storage and providers who offer it. In a "decentralized Dropbox" model, users would pay a monthly fee to upload files, with the contract distributing payments to storage providers who prove they are actually storing the data. The proof mechanism works through periodic cryptographic challenges: the contract randomly selects portions of files and asks providers to supply Merkle tree proofs demonstrating they possess that data. Providers who fail challenges or go offline would lose their deposits and future payment stream.
This approach offers several advantages over centralized storage. Merkle tree proofs enable efficient verification—users and the contract can confirm file availability without downloading entire files. The system naturally distributes files across multiple independent providers, creating redundancy without requiring explicit replication protocols. Economic incentives align provider behavior with user needs: providers earn money by reliably storing data and lose money if they fail to do so. This eliminates the trust requirement inherent in centralized storage solutions.
Storage costs in such a system can potentially be lower than centralized alternatives for several reasons. The elimination of monopoly pricing allows market competition to drive costs down to near the actual cost of storage. Implicit redundancy from multiple users storing similar files can reduce total storage requirements. There's no need for expensive data center infrastructure or corporate overhead. However, challenges remain around payment mechanisms, ensuring adequate provider participation, and managing the tradeoff between redundancy and cost. Despite these challenges, decentralized storage demonstrates how Ethereum can coordinate complex multi-party interactions through economic incentives alone.
Decentralized File Storage
Dezentraler Dateispeicher kann durch Ethereum-Vertraege implementiert werden, die zwischen Benutzern, die Speicher benoetigen, und Anbietern, die ihn anbieten, koordinieren. In einem Modell einer "dezentralen Dropbox" wuerden Benutzer eine monatliche Gebuehr zahlen, um Dateien hochzuladen, wobei der Vertrag Zahlungen an Speicheranbieter verteilt, die beweisen, dass sie die Daten tatsaechlich speichern. Der Beweismechanismus funktioniert ueber periodische kryptographische Herausforderungen: Der Vertrag waehlt zufaellig Teile von Dateien aus und fordert Anbieter auf, Merkle-Baum-Beweise zu liefern, die belegen, dass sie diese Daten besitzen. Anbieter, die Herausforderungen nicht bestehen oder offline gehen, wuerden ihre Einlagen und zukuenftigen Zahlungsstrom verlieren.
Dieser Ansatz bietet mehrere Vorteile gegenueber zentralisiertem Speicher. Merkle-Baum-Beweise ermoeglichen effiziente Verifizierung — Benutzer und der Vertrag koennen die Dateiverfuegbarkeit bestaetigen, ohne ganze Dateien herunterzuladen. Das System verteilt Dateien natuerlich ueber mehrere unabhaengige Anbieter und schafft Redundanz ohne explizite Replikationsprotokolle. Wirtschaftliche Anreize bringen das Verhalten der Anbieter mit den Beduerfnissen der Benutzer in Einklang: Anbieter verdienen Geld durch zuverlaessige Datenspeicherung und verlieren Geld, wenn sie dies nicht tun. Dies eliminiert die Vertrauensanforderung, die zentralisierten Speicherloesungen inhaeerent ist.
Speicherkosten in einem solchen System koennen potenziell niedriger sein als bei zentralisierten Alternativen aus mehreren Gruenden. Die Beseitigung von Monopolpreisen ermoeglicht es dem Marktwettbewerb, die Kosten nahe an die tatsaechlichen Speicherkosten zu treiben. Implizite Redundanz durch mehrere Benutzer, die aehnliche Dateien speichern, kann den Gesamtspeicherbedarf reduzieren. Es besteht kein Bedarf an teurer Rechenzentrumsinfrastruktur oder Unternehmensgemeinkosten. Allerdings bleiben Herausforderungen bei Zahlungsmechanismen, der Sicherstellung ausreichender Anbieterbeteiligung und dem Management des Kompromisses zwischen Redundanz und Kosten. Trotz dieser Herausforderungen demonstriert dezentraler Speicher, wie Ethereum komplexe Mehparteien-Interaktionen allein durch wirtschaftliche Anreize koordinieren kann.
Decentralized Autonomous Organizations
A Decentralized Autonomous Organization (DAO) is a virtual entity that has a set of members or shareholders who collectively have the right to spend the entity's funds and modify its code. A typical DAO operates with a simple rule: 67% of members are needed to make spending decisions or modify the organization's code. Members can submit proposals, vote on them, and if a proposal receives sufficient support, the contract automatically executes the decision. Membership shares can be transferable, allowing a liquid market for DAO participation, and different classes of shares can have different voting rights or economic claims.
The simplest DAO design is a self-modifying contract that maintains a list of members and requires a 2/3 majority vote to change any aspect of the contract, including its own voting rules. Members would submit code changes as transactions, other members would vote, and upon reaching the threshold, the contract would update itself. More sophisticated designs might include delegated voting systems where members can assign their voting power to representatives, or liquid democracy where votes can be delegated but reclaimed at any time for important decisions.
DAOs can serve various purposes beyond simple fund management. A DAO could function as a decentralized corporation, hiring contractors, purchasing services, and distributing profits to shareholders—all governed by smart contract code rather than traditional legal structures. It could operate as a decentralized investment fund, with members voting on which projects to fund. It could manage a commons resource, with stakeholders voting on allocation rules. The key insight is that by encoding governance rules in transparent, immutable code and tying them to economic stake, DAOs can coordinate group decisions without requiring traditional hierarchical management or legal enforcement.
Decentralized Autonomous Organizations
Eine Dezentrale Autonome Organisation (DAO) ist eine virtuelle Entitaet, die eine Gruppe von Mitgliedern oder Aktionaeren hat, die gemeinsam das Recht haben, die Mittel der Entitaet auszugeben und ihren Code zu aendern. Eine typische DAO funktioniert mit einer einfachen Regel: 67% der Mitglieder werden benoetigt, um Ausgabenentscheidungen zu treffen oder den Code der Organisation zu aendern. Mitglieder koennen Vorschlaege einreichen, darueber abstimmen, und wenn ein Vorschlag ausreichende Unterstuetzung erhaelt, fuehrt der Vertrag die Entscheidung automatisch aus. Mitgliedsanteile koennen uebertragbar sein, was einen liquiden Markt fuer DAO-Beteiligung ermoeglicht, und verschiedene Anteilsklassen koennen unterschiedliche Stimmrechte oder wirtschaftliche Ansprueche haben.
Das einfachste DAO-Design ist ein sich selbst aendernder Vertrag, der eine Mitgliederliste fuehrt und eine 2/3-Mehrheitsabstimmung erfordert, um jeden Aspekt des Vertrags zu aendern, einschliesslich seiner eigenen Abstimmungsregeln. Mitglieder wuerden Codeaenderungen als Transaktionen einreichen, andere Mitglieder wuerden abstimmen, und bei Erreichen der Schwelle wuerde sich der Vertrag selbst aktualisieren. Ausgefeiltere Designs koennten delegierte Abstimmungssysteme umfassen, bei denen Mitglieder ihre Stimmrechte an Vertreter uebertragen koennen, oder eine liquide Demokratie, bei der Stimmen delegiert, aber jederzeit fuer wichtige Entscheidungen zurueckgefordert werden koennen.
DAOs koennen verschiedenen Zwecken ueber die einfache Fondsverwaltung hinaus dienen. Eine DAO koennte als dezentrales Unternehmen fungieren, Auftragnehmer einstellen, Dienstleistungen einkaufen und Gewinne an Aktionaere verteilen — alles gesteuert durch Smart-Contract-Code statt traditionelle Rechtsstrukturen. Sie koennte als dezentraler Investmentfonds operieren, wobei Mitglieder darueber abstimmen, welche Projekte finanziert werden. Sie koennte eine gemeinsame Ressource verwalten, wobei Beteiligte ueber Zuteilungsregeln abstimmen. Die zentrale Erkenntnis ist, dass DAOs durch die Kodierung von Governance-Regeln in transparentem, unveraenderlichem Code und deren Verknuepfung mit wirtschaftlichem Einsatz Gruppenentscheidungen koordinieren koennen, ohne traditionelles hierarchisches Management oder rechtliche Durchsetzung zu benoetigen.
Further Applications
Beyond the major categories already discussed, Ethereum enables numerous other applications. Savings wallets with sophisticated security features can impose daily withdrawal limits while providing emergency keys for recovery, protecting users from theft while maintaining ultimate control. Crop insurance contracts can automatically pay farmers based on weather data feeds, eliminating claims processing and reducing administrative overhead. Peer-to-peer gambling applications can operate without any trusted intermediary, with smart contracts holding stakes and automatically paying winners based on verifiable random numbers or real-world event data.
On-chain prediction markets allow users to bet on future events, creating powerful forecasting mechanisms through the wisdom of crowds. These can be augmented with SchellingCoin-style protocols to create decentralized oracles: participants independently report data (like election results or weather conditions), and those whose reports match the majority receive rewards while outliers are penalized. This cryptoeconomic approach incentivizes honest reporting and can provide reliable real-world data to other contracts without requiring trust in any single oracle provider.
Multi-signature wallets represent another important application, enabling shared control of funds between multiple parties. A 2-of-3 multi-sig wallet might require any two of three designated parties to approve a transaction before funds can be spent, useful for escrow arrangements, corporate treasuries, or personal security. Decentralized marketplaces can combine identity systems, reputation scores, escrow contracts, and dispute resolution mechanisms to enable peer-to-peer commerce without centralized platforms. Each of these applications demonstrates how Ethereum's programmability enables new trust models and organizational structures.
Further Applications
Ueber die bereits besprochenen Hauptkategorien hinaus ermoeglicht Ethereum zahlreiche weitere Anwendungen. Sparwallets mit ausgefeilten Sicherheitsfunktionen koennen taegliche Abhebungslimits auferlegen und gleichzeitig Notfallschluessel fuer die Wiederherstellung bereitstellen, um Benutzer vor Diebstahl zu schuetzen und dabei die ultimative Kontrolle zu bewahren. Ernteversicherungsvertraege koennen Landwirten automatisch basierend auf Wetterdatenfeeds auszahlen, wodurch die Schadensbearbeitung eliminiert und der Verwaltungsaufwand reduziert wird. Peer-to-Peer-Gluecksspielanwendungen koennen ohne jeden vertrauenswuerdigen Vermittler betrieben werden, wobei Smart Contracts Einsaetze halten und Gewinner automatisch basierend auf verifizierbaren Zufallszahlen oder realen Ereignisdaten auszahlen.
On-Chain-Vorhersagemaerkte ermoegllichen es Benutzern, auf zukuenftige Ereignisse zu wetten und schaffen leistungsfaehige Prognosemechanismen durch die Weisheit der Masse. Diese koennen mit SchellingCoin-artigen Protokollen erweitert werden, um dezentrale Orakel zu schaffen: Teilnehmer berichten unabhaengig Daten (wie Wahlergebnisse oder Wetterbedingungen), und diejenigen, deren Berichte mit der Mehrheit uebereinstimmen, erhalten Belohnungen, waehrend Ausreisser bestraft werden. Dieser kryptooekonomische Ansatz schafft Anreize fuer ehrliche Berichterstattung und kann anderen Vertraegen zuverlaessige reale Daten liefern, ohne Vertrauen in einen einzelnen Orakel-Anbieter zu erfordern.
Multi-Signatur-Wallets stellen eine weitere wichtige Anwendung dar und ermoeglichen die gemeinsame Kontrolle von Geldern zwischen mehreren Parteien. Ein 2-von-3 Multi-Sig-Wallet koennte erfordern, dass zwei von drei bestimmten Parteien eine Transaktion genehmigen, bevor Gelder ausgegeben werden koennen, nuetzlich fuer Treuhandvereinbarungen, Unternehmensschatzkammern oder persoenliche Sicherheit. Dezentrale Marktplaetze koennen Identitaetssysteme, Reputationsbewertungen, Treuhandvertraege und Streitbeilegungsmechanismen kombinieren, um Peer-to-Peer-Handel ohne zentralisierte Plattformen zu ermoeglichen. Jede dieser Anwendungen demonstriert, wie die Programmierbarkeit von Ethereum neue Vertrauensmodelle und Organisationsstrukturen ermoeglicht.
Miscellanea And Concerns
Ethereum's implementation of the modified GHOST protocol includes specific rules for uncle inclusion and rewards. Uncles must be direct children of the current block's ancestor (between 2 and 7 generations back), must be valid block headers, must be distinct from previous uncles, and must not be direct ancestors of the current block. Uncle blocks receive 87.5% of the standard block reward, while the including block receives an additional 3.125% per uncle included (up to two uncles). This incentive structure encourages miners to reference stale blocks they observe, strengthening network security while rewarding miners who experienced temporary bad luck with network propagation.
The transaction-fee/" class="glossary-link" data-slug="transaction-fee" title="fee">fee system is based on the concept of "gas," where every computational operation has a fixed gas cost. For example, a multiplication operation costs 5 gas, a SHA256 hash costs 20 gas, and every transaction has a base cost of 21,000 gas. Users specify both a gas limit (maximum gas they're willing to consume) and a gas price (how much ether they'll pay per unit of gas). This system serves multiple purposes: it prevents infinite loops and denial-of-service attacks by ensuring all computation is paid for, it creates a market for block space where users bid via gas prices, and it allows miners to set a minimum gas price they're willing to accept, protecting network resources.
Scalability remains a significant concern, as every node/" class="glossary-link" data-slug="full-node" title="full node">full node must process every transaction to verify the state. Current blockchain architectures struggle to match centralized systems' transaction throughput. Potential solutions include state sharding, where different nodes process different subsets of transactions, and a transition from proof-of-work to proof-of-stake consensus, which could enable more efficient block production. Light clients using Merkle proofs can verify transactions without processing all blocks, but someone must still process everything. These scalability challenges represent active areas of research and development critical to Ethereum's long-term viability.
Miscellanea And Concerns
Ethereums Implementierung des modifizierten GHOST-Protokolls umfasst spezifische Regeln fuer die Einbeziehung und Belohnung von Onkeln. Onkel muessen direkte Kinder eines Vorfahren des aktuellen Blocks sein (zwischen 2 und 7 Generationen zurueck), muessen gueltige Block-Header sein, muessen sich von vorherigen Onkeln unterscheiden und duerfen keine direkten Vorfahren des aktuellen Blocks sein. Onkel-Bloecke erhalten 87,5% der Standard-Blockbelohnung, waehrend der einschliessende Block zusaetzliche 3,125% pro eingeschlossenem Onkel erhaelt (bis zu zwei Onkel). Diese Anreizstruktur ermutigt Miner, veraltete Bloecke zu referenzieren, die sie beobachten, was die Netzwerksicherheit staerkt und gleichzeitig Miner belohnt, die voruebergehend Pech mit der Netzwerkpropagation hatten.
Das Gebuehrensystem basiert auf dem Konzept von "Gas", wobei jede Berechnungsoperation einen festen Gas-Preis hat. Beispielsweise kostet eine Multiplikationsoperation 5 Gas, ein SHA256-Hash kostet 20 Gas, und jede Transaktion hat Grundkosten von 21.000 Gas. Benutzer geben sowohl ein Gas-Limit (maximales Gas, das sie zu verbrauchen bereit sind) als auch einen Gas-Preis (wie viel Ether sie pro Gas-Einheit zahlen) an. Dieses System dient mehreren Zwecken: Es verhindert Endlosschleifen und Denial-of-Service-Angriffe, indem sichergestellt wird, dass alle Berechnungen bezahlt werden, es schafft einen Markt fuer Blockraum, auf dem Benutzer ueber Gas-Preise bieten, und es ermoeglicht Minern, einen Mindest-Gas-Preis festzulegen, den sie zu akzeptieren bereit sind, um Netzwerkressourcen zu schuetzen.
Skalierbarkeit bleibt ein bedeutendes Anliegen, da jeder vollstaendige Knoten jede Transaktion verarbeiten muss, um den Zustand zu verifizieren. Aktuelle Blockchain-Architekturen haben Schwierigkeiten, den Transaktionsdurchsatz zentralisierter Systeme zu erreichen. Moegliche Loesungen umfassen Zustandssharding, bei dem verschiedene Knoten verschiedene Teilmengen von Transaktionen verarbeiten, und einen Uebergang von Proof-of-Work zu Proof-of-Stake-Konsens, der eine effizientere Blockproduktion ermoeglichen koennte. Light Clients, die Merkle-Beweise verwenden, koennen Transaktionen verifizieren, ohne alle Bloecke zu verarbeiten, aber jemand muss trotzdem alles verarbeiten. Diese Skalierbarkeitsprobleme stellen aktive Forschungs- und Entwicklungsbereiche dar, die fuer die langfristige Lebensfaehigkeit von Ethereum entscheidend sind.
Conclusion
The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features like on-blockchain escrow, withdrawal limits, and financial contracts through a highly generalized programming language. However, the Ethereum protocol moves far beyond just currency. Protocols around decentralized file storage, decentralized computation, and decentralized prediction markets, among dozens of other concepts, have the potential to substantially increase the efficiency of the computational industry and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer.
Rather than providing a limited set of operations designed for specific use cases, Ethereum provides a Turing-complete programming language that enables developers to build any application they can design. Want to invent your own financial derivative? Create your own currency? Establish a government on the blockchain? These are all trivially implementable with Ethereum's scripting system. The platform's power lies not in predicting what applications will be built, but in providing the foundational infrastructure that makes building them easy.
The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides a platform with unique potential. Rather than being a closed-ended, single-purpose protocol intended for specific applications in data storage, gambling, or finance, Ethereum is open-ended by design, and we believe it is extremely well-suited to serving as a foundational layer for a large number of both financial and non-financial protocols in the years to come. The applications that will be built on Ethereum in the future may be ones we cannot even imagine today, and that open-ended possibility represents the true promise of the platform.
Conclusion
Das Ethereum-Protokoll wurde urspruenglich als verbesserte Version einer Kryptowaehrung konzipiert, die fortgeschrittene Funktionen wie On-Blockchain-Treuhand, Abhebungslimits und Finanzvertraege durch eine hochgradig verallgemeinerte Programmiersprache bereitstellt. Allerdings geht das Ethereum-Protokoll weit ueber blosse Waehrung hinaus. Protokolle rund um dezentralen Dateispeicher, dezentrale Berechnung und dezentrale Vorhersagemaerkte, neben Dutzenden anderer Konzepte, haben das Potenzial, die Effizienz der Computerindustrie erheblich zu steigern und anderen Peer-to-Peer-Protokollen einen massiven Schub zu geben, indem erstmals eine wirtschaftliche Schicht hinzugefuegt wird.
Anstatt einen begrenzten Satz von Operationen bereitzustellen, die fuer bestimmte Anwendungsfaelle konzipiert sind, stellt Ethereum eine Turing-vollstaendige Programmiersprache bereit, die es Entwicklern ermoeglicht, jede Anwendung zu bauen, die sie entwerfen koennen. Moechten Sie Ihr eigenes Finanzderivat erfinden? Ihre eigene Waehrung schaffen? Eine Regierung auf der Blockchain etablieren? All dies ist trivial mit Ethereums Skripting-System implementierbar. Die Staerke der Plattform liegt nicht in der Vorhersage, welche Anwendungen gebaut werden, sondern in der Bereitstellung der fundamentalen Infrastruktur, die deren Erstellung einfach macht.
Das Konzept einer beliebigen Zustandsuebergangsfunktion, wie vom Ethereum-Protokoll implementiert, bietet eine Plattform mit einzigartigem Potenzial. Anstatt ein geschlossenes Einzelzweck-Protokoll fuer spezifische Anwendungen in Datenspeicherung, Gluecksspiel oder Finanzen zu sein, ist Ethereum von Grund auf offen gestaltet, und wir glauben, dass es ausserordentlich gut geeignet ist, in den kommenden Jahren als Grundschicht fuer eine grosse Anzahl sowohl finanzieller als auch nicht-finanzieller Protokolle zu dienen. Die Anwendungen, die in Zukunft auf Ethereum aufgebaut werden, koennten solche sein, die wir uns heute noch nicht einmal vorstellen koennen, und diese offene Moeglichkeit repraesentiert das wahre Versprechen der Plattform.
References and Further Reading
The Ethereum whitepaper builds upon extensive prior work in cryptocurrency and distributed systems research. The foundational Bitcoin protocol is described in Satoshi Nakamoto's original 2008 paper "Bitcoin: A Peer-to-Peer Electronic Cash System," which introduced the concept of blockchain-based digital currency. Early attempts to extend Bitcoin's functionality include Namecoin, a decentralized name registration system demonstrating blockchain applications beyond currency, though limited by Bitcoin's restricted scripting capabilities.
The colored coins whitepaper proposed a method for representing alternative assets on the Bitcoin blockchain by "coloring" specific bitcoins to represent other assets, while Mastercoin attempted to create a protocol layer on top of Bitcoin for more complex financial instruments. Both highlighted the limitations of building on Bitcoin and motivated the need for a more flexible platform. The concept of decentralized autonomous corporations, explored in Bitcoin Magazine, provided theoretical foundations for organizational governance through smart contracts.
Key technical components include simplified payment verification (SPV) for light clients, Merkle trees for efficient data verification, and Patricia tries for Ethereum's state representation. The GHOST (Greedy Heaviest Observed Subtree) protocol, described in a 2013 cryptography paper, addresses security issues arising from fast block times and forms the basis for Ethereum's consensus mechanism. These references represent the intellectual foundations upon which Ethereum was built, combining insights from cryptocurrency, distributed systems, cryptography, and game theory to create a general-purpose blockchain platform.
References and Further Reading
Das Ethereum-Whitepaper baut auf umfangreichen frueheren Arbeiten in der Kryptowaehrungs- und verteilten Systemforschung auf. Das grundlegende Bitcoin-Protokoll wird in Satoshi Nakamotos originalem Paper von 2008 "Bitcoin: A Peer-to-Peer Electronic Cash System" beschrieben, das das Konzept einer Blockchain-basierten digitalen Waehrung einfuehrte. Fruehe Versuche, die Funktionalitaet von Bitcoin zu erweitern, umfassen Namecoin, ein dezentrales Namensregistrierungssystem, das Blockchain-Anwendungen jenseits von Waehrung demonstrierte, wenn auch durch Bitcoins eingeschraenkte Skripting-Faehigkeiten begrenzt.
Das Colored-Coins-Whitepaper schlug eine Methode vor, alternative Vermoegenswerte auf der Bitcoin-Blockchain darzustellen, indem bestimmte Bitcoins "eingefaerbt" werden, um andere Vermoegenswerte zu repraesentieren, waehrend Mastercoin versuchte, eine Protokollschicht ueber Bitcoin fuer komplexere Finanzinstrumente zu schaffen. Beide hoben die Einschraenkungen des Aufbaus auf Bitcoin hervor und motivierten die Notwendigkeit einer flexibleren Plattform. Das Konzept dezentraler autonomer Unternehmen, das im Bitcoin Magazine untersucht wurde, lieferte theoretische Grundlagen fuer organisatorische Governance durch Smart Contracts.
Wichtige technische Komponenten umfassen die vereinfachte Zahlungsverifizierung (SPV) fuer Light Clients, Merkle-Baeume fuer effiziente Datenverifizierung und Patricia-Tries fuer Ethereums Zustandsdarstellung. Das GHOST-Protokoll (Greedy Heaviest Observed Subtree), beschrieben in einem Kryptographie-Paper von 2013, adressiert Sicherheitsprobleme, die durch schnelle Blockzeiten entstehen, und bildet die Grundlage fuer Ethereums Konsensmechanismus. Diese Referenzen repraesentieren die intellektuellen Grundlagen, auf denen Ethereum aufgebaut wurde, und kombinieren Erkenntnisse aus Kryptowaehrung, verteilten Systemen, Kryptographie und Spieltheorie, um eine universelle Blockchain-Plattform zu schaffen.
Related Whitepapers
$USDT
Tether
Tether: Fiat currencies on the Bitcoin blockchain
30 shared concepts · 2016
$BCH
Bitcoin Cash
Bitcoin Cash: Peer-to-Peer Electronic Cash for the World
33 shared concepts · 2017
$DOGE
Dogecoin
Dogecoin: A Community-Driven Cryptocurrency
28 shared concepts · 2013
$USDC
USD Coin
USD Coin (USDC): A Stablecoin by Circle and Coinbase
20 shared concepts · 2018
$BTC
Bitcoin
Bitcoin: A Peer-to-Peer Electronic Cash System
20 shared concepts · 2008