Ethereum Whitepaper

Diese einleitende Arbeit wurde ursprünglich 2014 von Vitalik Buterin, dem Gründer von Ethereum, vor dem Projektstart im Jahr 2015 veröffentlicht. Es ist erwähnenswert, dass sich Ethereum, wie viele gemeinschaftlich gesteuerte Open-Source-Softwareprojekte, seit seiner anfänglichen Einführung weiterentwickelt hat.

Obwohl diese Arbeit schon einige Jahre alt ist, pflegen wir sie nach wie vor, weil sie weiterhin als nützliche Referenz und präzise Darstellung von Ethereum und seiner Vision dient. Um mehr über die neuesten Entwicklungen von Ethereum und dazu zu erfahren, wie Änderungen am Protokoll vorgenommen werden, empfehlen wir diese Anleitung.

Forscher und Akademiker, die eine historische oder kanonische Version des Whitepapers [vom Dezember 2014] suchen, sollten diese PDF-Datei verwenden.

Eine Plattform der nächsten Generation für Smart Contracts und dezentralisierte Anwendungen

Satoshi Nakamotos Entwicklung von Bitcoin im Jahr 2009 wurde oft als radikale Weiterentwicklung von Geld und Währung gefeiert, da es sich dabei um das erste Beispiel eines digitalen Assets handelt, das weder eine Besicherung noch einen "intrinsischen Wert(opens in a new tab)" oder einen zentralisierten Herausgeber oder Kontrolleur hat. Ein anderer, wohl wichtigerer Teil des Bitcoin-Experiments ist jedoch die zugrunde liegende Blockchain-Technologie als Instrument des verteilten Konsenses, und so verlagert sich die Aufmerksamkeit rasch auf diesen anderen Aspekt von Bitcoin. Zu den häufig zitierten alternativen Anwendungen der Blockchain-Technologie gehören die Verwendung digitaler Assets auf der Blockchain zur Darstellung benutzerdefinierter Währungen und Finanzinstrumente („Colored Coins(opens in a new tab)“), das Eigentum an einem zugrunde liegenden physischen Gerät („Smart Property(opens in a new tab)“), nicht vertretbare Assets wie Domänennamen („Namecoin(opens in a new tab)“) sowie komplexere Anwendungen, bei denen digitale Assets direkt von einem Stück Code kontrolliert und beliebige Regeln ("Smart Contracts(opens in a new tab)") oder sogar Blockchain-basierte „dezentralisierte autonome Organisationen(opens in a new tab)“ (DAOs) implementiert werden. Ethereum beabsichtigt, eine Blockchain mit einer eingebauten, vollwertigen, Turing-kompletten Programmiersprache bereitzustellen, die zur Erstellung von „Verträgen“ verwendet werden kann, mit denen beliebige Statusübergangsfunktionen kodiert werden können, so dass Benutzer jedes der oben beschriebenen Systeme sowie viele andere, die wir uns noch nicht vorstellen können, erstellen können. Dazu muss nur eine entsprechende Logik in ein paar Zeilen Code geschrieben werden.

Einführung in Bitcoin und bestehende Konzepte

Historie

Das Konzept der dezentralisierten digitalen Währung sowie alternativer Anwendungen wie Eigentumsregistern gibt es seit Jahrzehnten. Die anonymen E-Cash-Protokolle der 1980er und 1990er Jahre, die sich hauptsächlich auf ein kryptografisches Primitiv stützten, das als Chaumian Blinding bekannt ist, boten eine Währung mit einem hohen Maß an Datenschutz, aber die Protokolle konnten sich aufgrund ihrer Abhängigkeit von einem zentralisierten Vermittler größtenteils nicht durchsetzen. 1998 war Wei Dais b-money(opens in a new tab) der erste Vorschlag, der die Idee der Geldschöpfung durch das Lösen von Rechenrätseln und einen dezentralen Konsens vorstellte, aber der Vorschlag enthielt nur wenige Details darüber, wie der dezentralisiertee Konsens tatsächlich umgesetzt werden könnte. 2005 stellte Hal Finney das Konzept der „wiederverwendbaren Proofs of Work(opens in a new tab)“ vor, ein System, das Ideen von b-money zusammen mit Adam Backs schwierig zu berechnenden Hashcash-Puzzles verwendet, um ein Konzept für eine Kryptowährung zu schaffen, aber auch hier blieb es hinter dem Ideal zurück, da es sich auf vertrauenswürdige Rechner als Backend stützte. 2009 setzte Satoshi Nakamoto zum ersten Mal eine dezentralisierte Währung durch die Kombination von Kryptografie mit öffentlichem Schlüssel und einem Konsensalgorithmus zur Nachverfolgung der Eigentumsverhältnisse von Coins, dem sogenannten „Proof-of-Work“, in die Praxis umgesetzt.

Der Mechanismus hinter Proof-of-Work war ein Durchbruch in diesem Bereich, da er zwei Probleme gleichzeitig löste. Erstens bot er einen einfachen und einigermaßen effektiven Konsensalgorithmus, der es den Knoten im Netzwerk ermöglichte, sich gemeinsam auf eine Reihe kanonischer Aktualisierungen des Status des Bitcoin-Ledgers zu einigen. Zweitens wurde ein Mechanismus bereitgestellt, der den freien Eintritt in den Konsensprozess ermöglicht und das politische Problem der Entscheidung darüber, wer den Konsens beeinflussen darf, löst, während gleichzeitig Sybil-Angriffe verhindert werden. Dies geschieht, indem eine formale Barriere für die Teilnahme, wie z. B. das Erfordernis, als eindeutige Einheit auf einer bestimmten Liste registriert zu sein, durch eine wirtschaftliche Barriere ersetzt wird – das Gewicht eines einzelnen Knotens im Konsensabstimmungsprozess ist direkt proportional zur Rechenleistung, die der Knoten bereitstellt. Seitdem wurde ein alternativer Ansatz namens Proof-of-Stake vorgeschlagen, bei dem die Gewichtung eines Knotens proportional zu seinen Währungsbeständen und nicht zu seinen Rechenressourcen erfolgt; die Erörterung der relativen Vorzüge der beiden Ansätze würde den Rahmen dieser Arbeit sprengen, aber es sei darauf hingewiesen, dass beide Ansätze als Rückgrat einer Kryptowährung dienen können.

Bitcoin als Statusübergangssystem

Aus technischer Sicht kann man sich das Ledger einer Kryptowährung wie Bitcoin als ein Statusübergangssystem vorstellen, bei dem es einen „Status“ gibt, der aus dem Eigentumsstatus aller vorhandenen Bitcoins besteht, und eine „Statusübergangsfunktion“, die einen Status und eine Transaktion annimmt und einen neuen Status als Ergebnis ausgibt. In einem Standard-Banksystem beispielsweise ist der Status eine Bilanzaufstellung, eine Transaktion ist eine Anforderung, X $ von A nach B zu verschieben, und die Statusübergangsfunktion verringert den Wert auf dem Konto von A um X $ und erhöht den Wert auf dem Konto von B um X $. Wenn das Konto von A von vornherein weniger als X $ aufweist, gibt die Statusfunktion einen Fehler zurück. Daher kann man formell definieren:

APPLY(S,TX) -> S' or ERROR

In dem oben definierten Bankensystem:

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

Aber:

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

Der „Status“ in Bitcoin ist die Sammlung aller Münzen (technisch gesehen „unverbrauchte Transaktionsausgaben“ oder UTXO), die geprägt und noch nicht ausgegeben wurden, wobei jede UTXO einen Nennwert und einen Eigentümer hat (definiert durch eine 20-Byte-Adresse, die im Wesentlichen ein kryptografischer öffentlicher Schlüssel ist^fn1). Eine Transaktion enthält eine oder mehrere Eingaben, wobei jede Eingabe eine Referenz auf einen bestehenden UTXO und eine kryptografische Signatur enthält, die durch den privaten Schlüssel erzeugt wurde, der mit der Adresse des Eigentümers verknüpft ist, sowie eine oder mehrere Ausgaben, wobei jede Ausgabe einen neuen UTXO enthält, der dem Status hinzugefügt werden soll.

Die Statusübergangsfunktion APPLY(S,TX) -> S' kann in etwa wie folgt definiert werden:

Für jede Eingabe in TX:
- Wenn der referenzierte UTXO nicht in S ist, wird ein Fehler zurückgegeben.
- Wenn die angegebene Signatur nicht mit dem Eigentümer des UTXO übereinstimmt, wird ein Fehler zurückgegeben.
Wenn die Summe der Nennwerte aller Eingangs-UTXO kleiner ist als die Summe der Nennwerte aller Ausgangs-UTXO, wird ein Fehler zurückgegeben.
S ausgeben, wobei alle Eingangs-UTXO entfernt und alle Ausgangs-UTXO hinzugefügt wurden.

Die erste Hälfte des ersten Schritts verhindert, dass Transaktionsabsender, Coins auszugeben, die nicht existieren, die zweite Hälfte des ersten Schritts verhindert, dass Transaktionsabsender Coins anderer ausgeben, und der zweite Schritt erzwingt die Erhaltung des Werts. Um dies für die Zahlung zu nutzen, sieht das Protokoll wie folgt aus. Angenommen, Alice möchte 11,7 BTC an Bob senden. Zunächst sucht Alice nach einem Satz verfügbarer UTXO, deren Eigentümer sie ist und die mindestens 11,7 BTC ausmachen. Realistisch betrachtet wird Alice nicht in der Lage sein, genau 11,7 BTC zu erhalten; sagen wir, das Mindeste, das sie erhalten kann, ist 6 + 4 + 2 = 12. Sie erstellt dann eine Transaktion mit diesen drei Eingaben und zwei Ausgaben. Die erste Ausgabe sind 11,7 BTC mit Bobs Adresse als Eigentümer und die zweite Ausgabe sind die restlichen 0,3 BTC „Wechselgeld“, deren Eigentümer Alice selbst ist.

Mining

Wenn wir Zugang zu einem vertrauenswürdigen zentralisierten Dienst hätten, wäre dieses System leicht zu implementieren; es könnte einfach genau wie beschrieben kodiert werden, wobei die Festplatte eines zentralisierten Servers verwendet wird, um den Status zu verfolgen. Da wir jedoch mit Bitcoin versuchen, ein dezentralisiertes Währungssystem aufzubauen, müssen wir das Status-Transaktionssystem mit einem Konsenssystem kombinieren, um sicherzustellen, dass alle über die Reihenfolge der Transaktionen übereinstimmen. Der dezentralisierte Konsensprozess von Bitcoin erfordert, dass die Knoten im Netzwerk kontinuierlich versuchen, Pakete von Transaktionen, sogenannte „Blöcke“, zu erzeugen. Das Netzwerk ist darauf ausgelegt, ungefähr alle zehn Minuten einen Block zu erzeugen, wobei jeder Block einen Zeitstempel, eine Nonce, einen Verweis auf den vorherigen Block (also den entsprechenden Hash) und eine Liste aller Transaktionen enthält, die seit dem vorherigen Block stattgefunden haben. Im Laufe der Zeit entsteht so eine persistente, ständig wachsende „Blockchain“, die sich kontinuierlich aktualisiert, um den neuesten Status des Bitcoin-Ledgers darzustellen.

Der Algorithmus zur Überprüfung der Gültigkeit eines Blocks, ausgedrückt in diesem Paradigma, lautet wie folgt:

Prüfen, ob der vorherige Block, auf den der Block verweist, existiert und gültig ist.
Prüfen, ob der Zeitstempel des Blocks größer ist als der des vorherigen Blocks^fn2 und weniger als 2 Stunden in der Zukunft liegt.
Prüfen, ob der Proof-of-Work des Blocks gültig ist.
Der Status am Ende des vorherigen Blocks soll S[0] lauten.
Annehmen, dass TX die Transaktionsliste des Blocks mit n Transaktionen ist. Für alle i in 0...n-1 S[i+1] = APPLY(S[i],TX[i]) festlegen. Falls eine Anwendung einen Fehler zurückgibt, abbrechen und „false“ zurückgeben.
„true“ zurückgeben und S[n] als den Status am Ende dieses Blocks registrieren.

Im Wesentlichen muss jede Transaktion im Block einen gültigen Statusübergang von dem ursprünglich kanonischen Status vor der Ausführung der Transaktion zu einem neuen Status bereitstellen. Beachten Sie, dass der Status auf keine Weise im Block kodiert ist; er ist eine reine Abstraktion, die sich der validierende Knoten merken muss und die nur (sicher) für einen Block berechnet werden kann, indem man vom Genesis-Status ausgeht und jede Transaktion in jedem Block nacheinander anwendet. Zusätzlich sei darauf hingewiesen, dass die Reihenfolge, in der der Miner Transaktionen in den Block einfügt, wichtig ist; wenn es zwei Transaktionen A und B in einem Block gibt, wobei B einen von A geschaffenen UTXO ausgibt, ist der Block gültig, wenn A vor B kommt, aber nicht umgekehrt.

Die einzige Gültigkeitsbedingung in der obigen Liste, die in anderen Systemen nicht vorkommt, ist die Erfordernis eines „Proof-of-Work“. Die genaue Bedingung ist, dass der Doppel-SHA256-Hash jedes Blocks, der als 256-Bit-Zahl behandelt wird, kleiner sein muss als ein dynamisch angepasstes Ziel, das zum Zeitpunkt der Erstellung dieses Dokuments ungefähr 2¹⁸⁷ beträgt. Damit soll die Erstellung von Blöcken rechnerisch „erschwert“ werden, um zu verhindern, dass Sybill-Angreifer die gesamte Blockchain zu ihren Gunsten umgestalten. Da SHA256 als völlig unvorhersehbare Pseudozufallsfunktion konzipiert ist, besteht die einzige Möglichkeit, einen gültigen Block zu erstellen, darin, durch Versuch und Irrtum vorzugehen, die Nonce wiederholt zu erhöhen und zu prüfen, ob der neue Hash passt.

Bei der derzeitigen Zielvorgabe von ca. 2¹⁸⁷ muss das Netz durchschnittlich ca. 2⁶⁹ Versuche unternehmen, bis ein gültiger Block gefunden wird; im Allgemeinen wird die Zielvorgabe vom Netzwerk alle 2016 Blöcke neu kalibriert, sodass im Durchschnitt alle zehn Minuten ein neuer Block von einem Knoten im Netzwerk erzeugt wird. Um die Miner für diese Rechenarbeit zu entschädigen, ist der Miner eines jeden Blocks berechtigt, eine Transaktion hinzuzufügen, die ihm 25 BTC aus dem Nichts zuweist. Außerdem: Wenn bei einer Transaktion der Gesamtnennwert in ihren Eingaben höher ist als in ihren Ausgaben, geht die Differenz als „Transaktionsgebühr“ ebenfalls an den Miner. Übrigens ist dies auch der einzige Mechanismus, mit dem BTC ausgegeben werden; der Genesis-Status enthielt überhaupt keine Coins.

Um den Zweck des Minings besser zu verstehen, wollen wir untersuchen, was im Falle eines böswilligen Angreifers passiert. Da die Bitcoin zugrunde liegende Kryptografie bekanntermaßen sicher ist, wird der Angreifer auf den einen Teil des Bitcoin-Systems abzielen, der nicht direkt durch Kryptografie geschützt ist: die Reihenfolge der Transaktionen. Die Strategie des Angreifers ist einfach:

100 BTC an einen Händler im Austausch für ein Produkt (bevorzugterweise schnell lieferbar und digital) senden
Auf die Lieferung des Produkts warten
Eine weitere Transaktion durchführen, die dieselben 100 BTC an ihn selbst sendet
Versuchen, das Netzwerk davon zu überzeugen, dass seine Transaktion an sich selbst zuerst kam.

Sobald Schritt (1) erfolgt ist, nimmt nach ein paar Minuten ein Miner die Transaktion in einen Block auf, beispielsweise in Block Nummer 270000. Nach etwa einer Stunde werden der Kette nach diesem Block fünf weitere Blöcke hinzugefügt worden sein, wobei jeder dieser Blöcke indirekt auf die Transaktion verweist und sie somit „bestätigt“. An diesem Punkt akzeptiert der Händler die Zahlung als abgeschlossen und liefert das Produkt; da wir davon ausgehen, dass es sich um eine digitale Ware handelt, erfolgt die Lieferung sofort. Nun erstellt der Angreifer eine weitere Transaktion, die die 100 BTC an ihn selbst sendet. Wenn der Angreifer sie einfach in die freie Wildbahn entlässt, wird die Transaktion nicht verarbeitet; Miner werden versuchen, APPLY(S,TX) auszuführen, und feststellen, dass TX ein UTXO verbraucht, das sich nicht mehr im Status befindet. Stattdessen erstellt der Angreifer eine „Abspaltung“ der Blockchain, indem er zu Beginn eine andere Version von Block 270000 mint, die auf denselben Block 269999 als übergeordneten Block verweist, aber mit der neuen Transaktion anstelle der alten. Da die Blockdaten unterschiedlich sind, muss der Proof-of-Work neu erstellt werden. Außerdem hat die neue Version des Blocks 270000 des Angreifers einen anderen Hash, sodass die ursprünglichen Blöcke 270001 bis 270005 nicht auf ihn „verweisen“; somit sind die ursprüngliche Kette und die neue Kette des Angreifers völlig getrennt. Die Regel besagt, dass bei einer Abspaltung die längste Blockchain als Wahrheit angesehen wird, sodass legitime Minder an der Kette 270005 arbeiten, während der Angreifer allein an der Kette 270000 arbeitet. Damit der Angreifer seine Blockchain zur längsten machen kann, müsste er über mehr Rechenleistung verfügen als der Rest des Netzwerks zusammen, um aufholen zu können (daher „51-%-Attacke“).

Merkle Trees

Links: Es reicht aus, nur eine kleine Anzahl von Knoten in einem Merkle Tree zu präsentieren, um die Gültigkeit eines Zweiges zu beweisen.

Rechts: Jeder Versuch, irgendeinen Teil des Merkle Tree zu ändern, führt letztendlich zu einer Inkonsistenz irgendwo in der Kette.

Eine wichtige Eigenschaft der Skalierbarkeit von Bitcoin ist, dass der Block in einer mehrstufigen Datenstruktur gespeichert wird. Der „Hash“ eines Blocks ist eigentlich nur der Hash des Block-Headers, ein etwa 200 Byte großes Datenstück, das den Zeitstempel, die Nonce, den vorherigen Blocks-Hash und den Root-Hash einer Datenstruktur namens Merkle Tree enthält, der alle Transaktionen des Blocks speichert. Ein Merkle Tree ist eine Art Binärbaum, der aus einer Reihe von Knoten besteht. An einem Ende des Baumes befinden sich zahlreiche Blattknoten, die die zugrunde liegenden Daten enthalten. Dazwischen liegt eine Menge von Zwischenknoten, wobei jeder dieser Knoten der Hash seiner beiden untergeordneten Knoten ist. Am anderen Ende des Baumes befindet sich schließlich ein einzelner Wurzelknoten, ebenfalls aus dem Hash seiner beiden untergeordneten Knoten gebildet. Dieser Steht für die „Spitze“ des Baumes. Der Zweck des Merkle Tree besteht darin, dass die Daten eines Blocks stückweise geliefert werden können: Ein Knoten kann nur den Header eines Blocks aus einer Quelle herunterladen, den kleinen Teil des Baums, der für ihn relevant ist, aus einer anderen Quelle und dabei trotzdem sicher sein, dass alle Daten korrekt sind. Der Grund, warum dies funktioniert, ist, dass Hashes nach oben weitergegeben werden: Wenn ein böswilliger Benutzer versucht, eine gefälschte Transaktion am unteren Ende eines Merkle Trees einzutragen, führt diese Änderung zu einer Änderung des darüber liegenden Knotens und dann zu einer Änderung des darüber liegenden Knotens, wodurch schließlich die Wurzel des Baums und damit der Hash des Blocks geändert wird, was dazu führt, dass das Protokoll ihn als einen völlig anderen Block registriert (mit ziemlicher Sicherheit mit einem ungültigen Proof-of-Work).

Das Merkle Tree-Protokoll ist für die langfristige Nachhaltigkeit wohl unerlässlich. Ein „voller Knoten“ im Bitcoin-Netzwerk, also einer, der die Gesamtheit aller Blöcke speichert und verarbeitet, beansprucht im April 2014 etwa 15 GB Speicherplatz im Bitcoin-Netzwerk und wächst jeden Monat um über ein Gigabyte. Derzeit ist dies für einige Desktop-Computer und nicht für Smartphones machbar, und in Zukunft werden nur Unternehmen und Hobbybegeisterte teilnehmen können. Ein Protokoll, das als „vereinfachte Zahlungsverifizierung“ (SPV; Simplified Payment Verification) bekannt ist, ermöglicht die Existenz einer weiteren Klasse von Knoten, den sogenannten „leichten Knoten“, die die Block-Header herunterladen, den Proof-of-Work auf den Block-Headern überprüfen und dann nur die „Zweige“ herunterladen, die mit den für sie relevanten Transaktionen verbunden sind. Dadurch können leichte Knoten mit einer hohen Sicherheitsgarantie den Status jeder Bitcoin-Transaktion und ihren aktuellen Saldo ermitteln, während sie nur einen sehr kleinen Teil der gesamten Blockchain herunterladen.

Alternative Blockchain-Anwendungen

Die Idee, den Grundgedanken der Blockchain auf andere Konzepte zu übertragen, hat ebenfalls eine lange Geschichte. 2005 veröffentlichte Nick Szabo das Konzept von „sicheren Eigentumstiteln mit Eigentümerauthorität(opens in a new tab)“ – ein Dokument, welches beschreibt, wie „neue Fortschritte in der replizierten Datenbanktechnologie“ ein Blockchain-basiertes Sytem für die Speicherung eines Registers darüber, wer der Eigentümer wovon ist, ermöglichen, wobei ein ausgeklügeltes Framework mit Konzepten wie Homesteading, Adverse Possession und georgischer Grundsteuer geschaffen wird. Leider gab es zu dieser Zeit kein effektives repliziertes Datenbanksystem, sodass das Protokoll nie in die Praxis umgesetzt wurde. Nach 2009, nachdem der dezentralisierte Konsens von Bitcoin entwickelt wurde, entstand jedoch schnell eine Reihe von alternativen Anwendungen.

Namecoin – Namecoin(opens in a new tab) wurde 2010 erschaffen und lässt sich am besten als eine dezentralisierte Datenbank zur Namensregistrierung beschrieben. In dezentralisierten Protokollen wie Tor, Bitcoin und BitMessage muss es eine Möglichkeit geben, Konten zu identifizieren, damit andere mit ihnen interagieren können, aber in allen bestehenden Lösungen ist der einzige verfügbare Identifikator ein pseudozufälliger Hash wie 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Im Idealfall möchte man ein Konto mit einem Namen wie „george“ haben können. Das Problem ist jedoch, dass, wenn eine Person ein Konto mit dem Namen „george“ einrichten kann, eine andere Person das gleiche Verfahren nutzen kann, um sich ebenfalls als „george“ zu registrieren und sich als diese Person auszugeben. Die einzige Lösung ist ein First-to-File-Paradigma, bei dem der erste Registrant erfolgreich ist und der zweite scheitert – ein Problem, das sich perfekt für das Bitcoin-Konsensprotokoll eignet. Namecoin ist die älteste und erfolgreichste Implementierung eines Namensregistrierungssystems, das auf einer solchen Idee beruht.
Colored Coins – Colored Coins(opens in a new tab) dienen als Protokoll, das die Möglichkeit bietet, eine eigene digitale Währung zu erschaffen oder – in dem wichtigen trivialen Fall einer Währung mit einer Einheit – digitale Token, auf der Bitcoin-Blockchain. Im Colored-Coins-Protokoll wird eine neue Währung „veröffentlicht“, indem man einem bestimmten Bitcoin-UTXO öffentlich eine Farbe zuweist. Das Protokoll definiert rekursiv die Farbe anderer UTXO als die gleiche wie die der Eingaben, die die Transaktion ausgegeben hat, welche diese erzeugte (bei Eingaben mit gemischten Farben gelten einige spezielle Regeln). Dies ermöglicht es den Benutzern, Wallets zu verwalten, die nur UTXO einer bestimmten Farbe enthalten, und sie wie ähnlich wie reguläre Bitcoins zu versenden und über die Blockchain zurückzuverfolgen, um die Farbe eines UTXO zu ermitteln, den sie erhalten haben.
Metacoins – die Idee hinter Metacoin ist ein Protokoll, das auf Bitcoin aufbaut und Bitcoin-Transaktionen nutzt, um Metacoin-Transaktionen mit einer anderen Statusübergangsfunktion zu speichern: APPLY'. Da das Metacoin-Protokoll nicht verhindern kann, dass ungültige Metacoin-Transaktionen in der Bitcoin-Blockchain auftreten, wird eine Regel hinzugefügt, die besagt, dass, wenn APPLY'(S,TX) einen Fehler zurückgibt, das Protokoll standardmäßig auf APPLY'(S,TX) = S festgelegt wird. Dies bietet einen einfachen Mechanismus zur Erstellung eines willkürlichen Kryptowährungsprotokolls, möglicherweise mit fortgeschrittenen Funktionen, die nicht in Bitcoin selbst implementiert werden können, jedoch mit sehr geringen Entwicklungskosten, da die Komplexität des Minings und der Vernetzung bereits durch das Bitcoin-Protokoll verarbeitet wird. Metacoins wurden verwendet, um einige Klassen von Finanzverträgen, Namensregistrierung und dezentralisierten Austausch zu implementieren.

Im Allgemeinen gibt es also zwei Ansätze für den Aufbau eines Konsensprotokolls: Aufbau eines unabhängigen Netzwerks und Aufbau eines Protokolls auf Bitcoin. Der erste Ansatz, der bei Anwendungen wie Namecoin zwar einigermaßen erfolgreich war, ist schwer umzusetzen; jede einzelne Implementierung muss eine unabhängige Blockchain starten sowie den gesamten notwendigen Code für Statusübergänge und Netzwerkverbindungen entwickeln und testen. Außerdem prognostizieren wir, dass die Menge an Anwendungen für die Technologie des dezentralisierten Konsenses einer Potenzgesetzverteilung folgen wird, bei der die überwiegende Mehrheit der Anwendungen für eine eigene Blockchain zu klein sein wird, und stellen fest, dass es große Klassen von dezentralisierten Anwendungen gibt, insbesondere autonome dezentralisierte Organisationen, die miteinander interagieren müssen.

Der Bitcoin-basierte Ansatz hat hingegen den Nachteil, dass er nicht die vereinfachten Zahlungsüberprüfungsfunktionen von Bitcoin übernimmt. SPV funktioniert für Bitcoin, weil es die Tiefe der Blockchain als Proxy für die Gültigkeit nutzen kann; sobald die Vorgänger einer Transaktion weit genug zurückliegen, kann davon ausgegangen werden, dass sie rechtmäßig Teil des Status waren. Blockchain-basierte Meta-Protokolle hingegen können die Blockchain nicht zwingen, Transaktionen nicht aufzunehmen, die im Kontext ihrer eigenen Protokolle nicht gültig sind. Daher müsste eine vollständig sichere SPV-Meta-Protokoll-Implementierung eine Rückwärtssuche bis zum Anfang der Bitcoin-Blockchain durchführen, um festzustellen, ob bestimmte Transaktionen gültig sind. Derzeit verlassen sich alle „leichten“ Implementierungen von Bitcoin-basierten Meta-Protokollen auf einen vertrauenswürdigen Server, um die Daten bereitzustellen, was insbesondere angesichts des Hauptziels einer Kryptowährung, Vertrauen überflüssig zu machen, als sehr suboptimal anzusehen ist.

Scripting

Auch ohne jegliche Erweiterungen ermöglicht das Bitcoin-Protokoll tatsächlich eine schwache Version des Konzepts der „Smart Contracts“. Das Eigentum an UTXO in Bitcoin kann nicht nur durch einen öffentlichen Schlüssel, sondern auch durch ein kompliziertes Skript, das in einer einfachen Stack-basierten Programmiersprache geschrieben ist, erreicht werden. In diesem Paradigma muss eine Transaktion, die diesen UTXO ausgibt, Daten bereitstellen, die den Anforderungen des Scripts entsprechen. Tatsächlich wird sogar der grundlegende Mechanismus zum Eigentum an öffentlichen Schlüsseln über ein Skript implementiert: Das Skript nimmt eine elliptische Kurvensignatur als Eingabe, verifiziert sie gegen die Transaktion und die Adresse, die Eigentümer des UTXO ist, und gibt 1 zurück, wenn die Verifizierung erfolgreich war, bzw. andernfalls 0. Andere, kompliziertere Skripte gibt es für verschiedene zusätzliche Anwendungsfälle. Zum Beispiel kann man ein Script erstellen, das zur Validierung Signaturen von zwei von drei vorgegebenen privaten Schlüsseln erfordert („Multisig“) – eine Konfiguration, die für Firmenkonten, sichere Sparkonten und einige Treuhandszenarien für Händler nützlich ist. Skripte können auch verwendet werden, um Kopfgelder für Lösungen zu Berechnungsproblemen zu zahlen, und man kann sogar ein Skript erstellen, das so etwas sagt wie „dieser Bitcoin-UTXO gehört Ihnen, wenn Sie einen SPV-Nachweis darüber erbringen können, dass Sie mir eine Dogecoin-Transaktion dieses Nennwerts gesendet haben“, was im Wesentlichen einen dezentralisierten übergreifenden Kryptowährungstausch ermöglicht.

Die Skriptsprache, wie sie in Bitcoin implementiert ist, hat jedoch mehrere wichtige Einschränkungen:

Mangel an Turing-Completeness – das heißt, dass die Bitcoin-Skriptsprache zwar eine große Teilmenge von Berechnungen unterstützt, aber nicht annähernd alle. Die Hauptkategorie, die fehlt, sind Schleifen. Dies geschieht zur Vermeidung von Endlosschleifen während der Transaktionsverifizierung; theoretisch ist dies ein überwindbares Hindernis für Skriptprogrammierer, da jede Schleife simuliert werden kann, indem man den zugrunde liegenden Code einfach mehrmals mit einer if-Aussage wiederholt, aber dies führt zu Skripten, die sehr ineffizient im Platzverbrauch sind. Zum Beispiel würde die Implementierung eines alternativen Signaturalgorithmus für elliptische Kurven wahrscheinlich 256 wiederholte Multiplikationsrunden erfordern, die alle einzeln im Code enthalten sind.
Werteblindheit – es gibt keine Möglichkeit für ein UTXO-Skript, eine feingranulare Kontrolle über den Betrag zu ermöglichen, der abgehoben werden kann. Zum Beispiel wäre ein leistungsfähiges Anwendungsbeispiel für einen Oracle-Vertrag ein Hedging-Vertrag, bei dem A und B BTC im Wert von 1000 $ einbringen und nach 30 Tagen das Skript 1000 $ in BTC an A und den Rest an B sendet. Dafür wäre ein Oracle erforderlich, um den Wert von 1 BTC in USD zu bestimmen, aber selbst dann stellt es eine massive Verbesserung in Bezug auf Vertrauen und Infrastrukturanforderungen gegenüber den vollständig zentralisierten Lösungen dar, die jetzt verfügbar sind. Allerdings ist dies aufgrund der Tatsache, dass UTXO nicht teilbar sind, nur durch einen sehr ineffizienten Kniff möglich. Dabei werden viele UTXO mit unterschiedlichen Nennwerten erstellt (z. B. ein UTXO mit dem Wert 2^k für jedes k bis 30). Der Oracle entscheidet dann, welcher UTXO an A und welcher an B geschickt wird.
Nicht vorhandener Status – UTXO können entweder ausgegeben oder nicht ausgegeben sein; es gibt keine Möglichkeit für mehrstufige Verträge oder Skripte, die einen anderen internen Status als diesen speichern. Dies erschwert die Erstellung von mehrstufigen Optionskontrakten, dezentralisierten Austauschangeboten oder zweistufigen kryptografischen Commitment-Protokollen (notwendig für sichere Berechnungskopfgelder). Es bedeutet auch, dass UTXO nur verwendet werden können, um einfache, einmalige Verträge zu erstellen und keine komplexeren „statusbehafteten“ Verträge wie dezentralisierte Organisationen, und die Implementierung von Meta-Protokollen wird erschwert. Ein binärer Status in Verbindung mit Werteblindheit bedeutet auch, dass eine weitere wichtige Anwendung, nämlich Abhebungslimits, unmöglich ist.
Blockchain-Blindheit – UTXO sind blind für Blockchain-Daten wie die Nonce, den Zeitstempel und den vorherigen Block-Hash. Dies schränkt Anwendungen im Glücksspiel und in mehreren anderen Kategorien erheblich ein, da der Skriptsprache eine potenziell wertvolle Quelle der Zufälligkeit entzogen wird.

Es gibt also drei Ansätze für die Entwicklung fortschrittlicher Anwendungen auf der Grundlage von Kryptowährungen: der Aufbau einer neuen Blockchain, die Verwendung von Skripten auf Bitcoin und der Aufbau eines Meta-Protokolls auf Bitcoin. Der Aufbau einer neuen Blockchain bietet unbegrenzte Freiheit bei der Entwicklung von Funktionssätzen, allerdings auf Kosten von Entwicklungszeit, Bootstrapping-Aufwand und Sicherheit. Scripting ist leicht zu implementieren und zu standardisieren, hat jedoch nur sehr begrenzte Möglichkeiten, und Meta-Protokolle haben trotz ihrer Einfachheit Probleme mit der Skalierbarkeit. Mit Ethereum wollen wir ein alternatives Framework schaffen, das sowohl die Entwicklungsfreundlichkeit erheblich verbessert als auch die Eigenschaften für leichte Clients weiter stärkt, während es Anwendungen gleichzeitig ermöglicht, eine gemeinsame wirtschaftliche Umgebung und die Sicherheit der Blockchain zu nutzen.

Ethereum

Die Absicht von Ethereum besteht darin, ein alternatives Protokoll zur Erstellung dezentralisierter Anwendungen zu entwickeln, das eine andere Reihe von Kompromissen bietet, die unserer Überzeugung nach für eine große Anzahl von dezentralisierten Anwendungen sehr nützlich sein werden. Besonderer Fokus liegt dabei auf Situationen, in denen schnelle Entwicklungszeiten, Sicherheit für kleine und selten genutzte Anwendungen und die Möglichkeit, dass verschiedene Anwendungen sehr effizient interagieren, wichtig sind. Ethereum erreicht dies, indem es im Wesentlichen die ultimative abstrakte Basisschicht aufbaut: eine Blockchain mit einer eingebauten Turing-kompletten Programmiersprache, die es jedem ermöglicht, Smart Contracts und dezentralisierte Anwendungen zu schreiben, in denen man seine eigenen beliebigen Regeln für Eigentumsverhältnisse, Transaktionsformate und Statusübergangsfunktionen festlegen kann. Eine stark vereinfachte Version von Namecoin lässt sich in zwei Codezeilen schreiben, und andere Protokolle wie Währungen und Reputationssysteme können in weniger als zwanzig Zeilen entwickelt werden. Smart Contracts, kryptografische „Boxen“, die einen Wert enthalten und ihn nur freigeben, wenn bestimmte Bedingungen erfüllt sind, können auch auf der Plattform aufgebaut werden – aufgrund der zusätzlichen Leistung von Turing-Completeness, Wertbewusstsein, Blockchain-Bewusstsein und Status mit weitaus mehr Leistung als bei Bitcoin-Skripten.

Ethereum-Konten

In Ethereum wird der Status durch Objekte namens „Konten“ gebildet. Jedes Konto hat eine 20-Byte-Adresse, und Statusübergänge erfolgen durch direkte Übertragungen von Wert und Informationen zwischen den Konten. Ein Ethereum-Konto beinhaltet vier Felder:

Die Nonce – ein Zähler, der sicherstellt, dass jede Transaktion nur einmal verarbeitet werden kann
Der aktuelle Ether-Saldo des Kontos
Der Vertragscode des Kontos, falls vorhanden
Der Speicherplatz des Kontos (standardmäßig leer)

„Ether“ ist der Krypto-Haupttreibstoff von Ethereum und wird verwendet, um Transaktionsgebühren zu bezahlen. Allgemein gibt es zwei Arten von Konten: Konten in externem Eigentum, die durch private Schlüssel kontrolliert werden, und Vertragskonten, die durch deren Vertragscode kontrolliert werden. Ein Konto in externem Eigentum besitzt keinen Code, und man kann Nachrichten von einem solchen Konto aus verschicken, indem man eine Transaktion erschafft und signiert. Jedes Mal, wenn ein Vertragskonto eine Nachricht erhält, wird dessen Code aktiviert, was es erlaubt, den internen Speicher zu lesen und zu bearbeiten und andere Nachrichten zu senden oder Vertragskonten im Gegenzug zu erschaffen.

Beachten Sie, dass „Verträge“ in Ethereum nicht als etwas betrachtet werden sollten, das „erfüllt“ oder „eingehalten“ werden muss; vielmehr ähneln sie eher „autonomen Agenten“, die innerhalb der Ethereum-Ausführungsumgebung existieren, stets ein bestimmtes Stück Code ausführen, wenn sie durch eine Nachricht oder Transaktion „angesprochen“ werden, und die direkte Kontrolle über ihr eigenes Ether-Saldo sowie ihren eigenen Schlüssel-/Wertespeicher haben, um persistente Variablen zu verfolgen.

Nachrichten und Transaktionen

In Ethereum wird der Begriff „Transaktion“ verwendet, um das signierte Datenpaket zu beschreiben, das eine Nachricht enthält, die von einem Konto in externem Eigentum gesendet wird. Transaktionen umfassen:

Den Empfänger der Nachricht
Eine Signatur, die den Absender identifiziert
Den Ether-Betrag, der vom Absender an den Empfänger übertragen werden soll
Ein optionales Datenfeld
Einen STARTGAS-Wert, welcher für die maximale Anzahl an Berechnungsschritten für die Transaktionsausführung steht
Einen GASPRICE-Wert, welcher für die Gebühr steht, die der Absender pro Berechnungsschritt bezahlt

Bei den ersten drei handelt es sich um Standardfelder, die bei jeder Kryptowährung erwartet werden. Das Datenfeld hat standardmäßig keine Funktion, aber die virtuelle Maschine hat einen Opcode, mit dem ein Vertrag auf die Daten zugreifen kann; als Beispielanwendung: Wenn ein Vertrag als On-Blockchain-Domain-Registrierungsdienst fungiert, könnte er die an ihn übermittelten Daten so interpretieren, dass sie zwei „Felder“ enthalten – das erste Feld eine zu registrierende Domain und das zweite Feld die IP-Adresse, auf die sie registriert werden soll. Der Vertrag liest diese Werte aus den Nachrichtendaten und speichert sie in geeigneter Weise ab.

Die Felder STARTGAS und GASPRICE sind entscheidend für das Anti-Denial-of-Service-Modell von Ethereum. Um unbeabsichtigte oder feindselige Endlosschleifen oder andere Datenverschwendung im Code zu verhindern, ist es bei jeder Transaktion erforderlich, ein Limit dazu festzulegen, wie viele Rechenschritte der Codeausführung sie nutzen kann. Die grundlegende Recheneinheit ist „Gas“; normalerweise kostet ein Rechenschritt 1 Gas, aber einige Operationen kosten höhere Mengen an Gas, da sie rechnerisch aufwendiger sind oder die Menge an Daten erhöhen, die als Teil des Status gespeichert werden müssen. Außerdem wird für jedes Byte in den Transaktionsdaten eine Gebühr von 5 Gas erhoben. Die Absicht des Gebührensystems besteht darin, dass ein Angreifer für jede Ressource, die er verbraucht, einschließlich Rechenleistung, Bandbreite und Speicherplatz, proportional bezahlen muss; daher muss für jede Transaktion, die dazu führt, dass das Netzwerk eine größere Menge einer dieser Ressourcen verbraucht, eine Gas-Gebühr erhoben werden, die in etwa proportional zur Steigerung ist.

Nachrichten

Verträge haben die Möglichkeit, „Nachrichten“ an andere Verträge zu senden. Nachrichten sind virtuelle Objekte, die niemals serialisiert werden und nur in der Ethereum-Ausführungsumgebung existieren. Eine Nachricht enthält:

Den Absender der Nachricht (implizit)
Der Empfänger der Nachricht
Die Menge an Ether, die mit der Nachricht übertragen werden soll
Ein optionales Datenfeld
Einen STARTGAS-Wert

Eine Nachricht ist im Grunde genommen wie eine Transaktion, nur dass sie von einem Vertrag und nicht von einem externen Akteur erzeugt wird. Eine Nachricht wird erzeugt, wenn ein Vertrag, der gerade Code ausführt, den Opcode CALL ausführt, der eine Nachricht erzeugt und ausführt. Eine Nachricht führt wie eine Transaktion dazu, dass das Empfängerkonto den Code ausführt. Somit können Verträge auf genau die gleiche Weise wie externe Akteure Beziehungen zu anderen Verträgen haben.

Beachten Sie, dass das Gas-Limit, das einer Transaktion oder einem Vertrag zugewiesen wird, für das gesamte Gas gilt, das von dieser Transaktion und allen Unterausführungen verbraucht wird. Wenn beispielsweise ein externer Akteur A eine Transaktion an B mit 1000 Gas sendet und B 600 Gas verbraucht, bevor er eine Nachricht an C sendet, während die interne Ausführung von C 300 Gas verbraucht, bevor sie zurückkehrt, kann B noch 100 Gas ausgeben, bevor das Gas aufgebraucht ist.

Ethereum-Statusübergangfunktion

Die Ethereum-Statusübergangsfunktion APPLY(S,TX) -> S' kann wie folgt definiert werden:

Prüfen, ob die Transaktion korrekt aufgebaut ist (sprich, die richtige Anzahl von Werten enthält), ob die Signatur gültig ist und ob die Nonce mit der im Konto des Absenders übereinstimmt. Falls nicht, einen Fehler zurückgeben.
Die Transaktionsgebühr als STARTGAS * GASPRICE berechnen und die Absenderadresse aus der Signatur bestimmen. Die Gebühr vom Saldo des Absenders abziehen und die Nonce des Absenders erhöhen. Wenn nicht genügend zu verbrauchender Saldo vorhanden ist, einen Fehler zurückgeben.
GAS = STARTGAS initialisieren und eine bestimmte Gas-Menge pro Byte abziehen, um für die Bytes in der Transaktion zu bezahlen.
Den Transaktionswert vom Konto des Absenders auf das Konto des Empfängers übertragen. Falls das Empfängerkonto noch nicht existiert, dieses erstellen. Wenn das Empfängerkonto ein Vertrag ist, den Code des Vertrags entweder bis zum Abschluss oder bis zur Gas-Erschöpfung ausführen.
Wenn die Wertübertragung fehlgeschlagen ist, weil der Absender nicht genügend Geld hatte oder die Codeausführung das Gas aufgebraucht hat, alle Statusänderungen zurücksetzen, mit Ausnahme der Zahlung der Gebühren, und die Gebühren dem Konto des Miners hinzufügen.
Andernfalls die Gebühren für das verbleibende Gas an den Absender erstatten und die Gebühren für das verbrauchte Gas an den Miner senden.

Nehmen wir zum Beispiel an, dass der Code des Vertrags wie folgt lautet:

if !self.storage[calldataload(0)]:
  self.storage[calldataload(0)] = calldataload(32)

Beachten Sie, dass der tatsächliche Vertragscode als Low-Level-EVM-Code geschrieben ist; dieses Beispiel ist zur Klarheit in Serpent, einer unserer High-Level-Sprachen, verfasst und kann in EVM-Code kompiliert werden. Angenommen, der Speicher des Vertrags beginnt leer und eine Transaktion wird mit einem Wert von 10 Ether, 2000 Gas, einem Gas-Preis von 0,001 Ether und 64 Byte Daten gesendet, wobei die Bytes 0–31 für die Zahl 2 und die Bytes 32–63 für den String CHARLIE stehen. In diesem Fall ist der Prozess der Statusübergangsfunktion wie folgt:

Sicherstellen, dass die Transaktion gültig und korrekt aufgebaut ist.
Überprüfen Sie, ob der Absender der Transaktion mindestens 2000 * 0,001 = 2 Ether besitzt. Wenn ja, dann 2 Ether vom Konto des Absenders abziehen.
Gas = 2000 initialisieren; vorausgesetzt, die Transaktion ist 170 Byte lang und die Gebühren pro Byte betragen 5, 850 abziehen, sodass noch 1150 Gas verbleibt.
10 weitere Ether vom Konto des Absenders abziehen und sie dem Konto des Vertrags hinzufügen.
Den Code ausführen. In diesem Fall ist es einfach: Es wird überprüft, ob der Speicher des Vertrags an Index 2 verwendet wird, und festgestellt, dass dies nicht der Fall ist, und daher wird der Speicher an Index 2 auf den Wert CHARLIE gesetzt. Angenommen, dies verbraucht 187 Gas – dann beträgt der verbleibende Gasbetrag 1150 - 187 = 963.
963 * 0,001 = 0,963 Ether zurück auf das Konto des Senders hinzufügen und den dadurch entstandenen Status zurückgeben.

Wenn am empfangenden Ende der Transaktion kein Vertrag vorhanden war, wäre die gesamte Transaktionsgebühr einfach das Produkt aus dem angegebenen GASPRICE und der Länge der Transaktion in Bytes, wobei die bei der Transaktion gesendeten Daten irrelevant wären.

Beachten Sie, dass Nachrichten in Bezug auf Zurücksetzungen wie Transaktionen funktionieren: Wenn eine Nachrichtenausführung das Gas-Limit erreicht, wird die Ausführung dieser Nachricht sowie aller anderen durch diese Ausführung ausgelösten Ausführungen zurückgesetzt, jedoch müssen übergeordnete Ausführungen nicht zurückgesetzt werden. Das bedeutet, dass es für einen Vertrag „sicher“ ist, einen anderen Vertrag aufzurufen; wenn A B mit G Gas aufruft, ist garantiert, dass As Ausführung höchstens G Gas verliert. Schließlich sei darauf hingewiesen, dass es einen Opcode CREATE gibt, der einen Vertrag erstellt; seine Ausführungsmechanik ist grundsätzlich ähnlich wie bei CALL, mit dem Unterschied, dass die Ausgabe der Ausführung den Code eines neu erstellten Vertrags bestimmt.

Codeausführung

Der Code in Ethereum-Verträgen ist in einer Low-Level-, Stack-basierten Bytecode-Sprache geschrieben, die als „Code der virtuellen Maschine von Ethereum“ oder „EVM-Code“ bezeichnet wird. Der Code besteht aus einer Reihe von Bytes, wobei jedes Byte für eine Operation steht. Im Allgemeinen ist die Codeausführung eine Endlosschleife, die darin besteht, wiederholt die Operation am aktuellen Programmzähler (der bei null beginnt) auszuführen und anschließend den Programmzähler um eins zu erhöhen, bis das Ende des Codes erreicht ist oder ein Fehler bzw. ein STOP- oder RETURN-Befehl erkannt wird. Die Operationen haben Zugang zu drei Arten von Speicher, in denen Daten gespeichert werden können:

Der Stack, ein Last-in-First-out-Container, in den Werte gepusht und aus dem Werte gepoppt werden können
Gedächtnis, ein unendlich erweiterbares Byte-Array
Der langfristige Speicher des Vertrags, ein Schlüssel-/Wertespeicher. Anders als bei Stack und Gedächtnis, die nach Beendigung der Berechnung zurückgesetzt werden, bleibt der Speicher auf lange Sicht bestehen.

Der Code kann auch auf den Wert, Absender und die Daten der eingehenden Nachricht sowie auf Block-Header-Daten zugreifen, und der Code kann auch ein Byte-Array von Daten als Ausgabe zurückgeben.

Das formale Ausführungsmodell von EVM-Codes ist erstaunlich einfach. Während die virtuelle Maschine von Ethereum läuft, kann ihr vollständiger Berechnungsstatus durch das Tupel (block_state, transaction, message, code, memory, stack, pc, gas) definiert werden, wobei block_state den globalen Status darstellt, der alle Konten mit Salden und Speicher enthält. Zu Beginn jeder Ausführungsrunde wird die aktuelle Anweisung bestimmt, indem man das pc-te Byte des code nimmt (oder 0, wenn pc >= len(code)), und jede Anweisung hat ihre eigene Definition, wie sie das Tupel beeinflusst. Zum Beispiel entfernt ADD zwei Elemente vom Stack und pusht ihre Summe, reduziert gas um 1 und erhöht pc um 1, während SSTORE die obersten zwei Elemente vom Stack entfernt und das zweite Element im Speicher des Vertrags am durch das erste Element angegebenen Index einfügt. Obwohl es viele Möglichkeiten gibt, die Ausführung der virtuellen Maschine von Ethereum durch Just-in-Time-Kompilierung zu optimieren, kann eine grundlegende Implementierung von Ethereum in einigen Hundert Zeilen Code umgesetzt werden.

Blockchain und Mining

Die Ethereum-Blockchain ähnelt in vielerlei Hinsicht der Bitcoin-Blockchain, obwohl sie auch einige Unterschiede aufweist. Der Hauptunterschied zwischen Ethereum und Bitcoin in Bezug auf die Blockchain-Architektur besteht darin, dass Ethereum-Blöcke im Gegensatz zu Bitcoin eine Kopie der Transaktionsliste und des aktuellen Status enthalten. Darüber hinaus werden zwei weitere Werte, Blocknummer und Schwierigkeit, ebenfalls im Block gespeichert. Der grundlegende Blockvalidierungsalgorithmus in Ethereum gestaltet sich wie folgt:

Prüfen, ob der vorherige Block, auf den verwiesen wird, existiert und gültig ist.
Sicherstellen, dass der Zeitstempel des Blocks größer ist als der des referenzierten vorherigen Blocks und weniger als 15 Minuten in der Zukunft liegt.
Sicherstellen, dass Blocknummer, Schwierigkeit, Transaktionswurzel, Onkelwurzel und Gas-Limit (verschiedene Ethereum-spezifische Low-Level-Konzepte) gültig sind.
Prüfe, ob der Proof-of-Work des Blocks gültig ist.
Sei S[0] der Zustand am Ende des vorherigen Blocks.
TX die Transaktionsliste des Blocks, die n Transaktionen umfasst, sein lassen. Für alle i in 0...n-1 S[i+1] = APPLY(S[i],TX[i]) festlegen. Wenn irgendeine Anwendung einen Fehler zurückgibt oder wenn das insgesamt im Block verbrauchte Gas bis zu diesem Zeitpunkt das GASLIMIT überschreitet, einen Fehler zurückgeben.
S_FINAL gleich S[n] sein lassen, jedoch unter Hinzufügung der Blockbelohnung, die an den Miner gezahlt wird.
Prüfen, ob die Merkle-Tree-Wurzel des Status S_FINAL der im Block-Header angegebenen endgültigen Statuswurzel gleicht. Wenn dies der Fall ist, ist der Block gültig; andernfalls ist er nicht gültig.

Auf den ersten Blick könnte der Ansatz äußerst ineffizient erscheinen, weil er den gesamten Status mit jedem Block speichern muss – tatsächlich sollte die Effizienz jedoch mit der von Bitcoin vergleichbar sein. Der Grund dafür ist, dass der Status in der Baumstruktur gespeichert wird und nach jedem Block nur ein kleiner Teil des Baums geändert werden muss. Daher sollte im Allgemeinen zwischen zwei benachbarten Blöcken der Großteil des Baums identisch sein, und die Daten können somit einmal gespeichert und zweimal über Verweiser (also Hashes von Teilbäumen) referenziert werden. Um dies zu erreichen, wird eine spezielle Art von Baum, bekannt als „Patricia-Baum“, verwendet. Er beinhaltet eine Modifikation des Merkle-Tree-Konzepts, die es ermöglicht, Knoten effizient einzufügen und zu löschen, und nicht nur zu ändern. Darüber hinaus ist es, weil alle Statusinformationen Teil des letzten Blocks sind, nicht notwendig, die gesamte Blockchain-Historie zu speichern – eine Strategie, die, sofern sie auf Bitcoin angewendet werden kann, kalkulierte 5- bis 20-fache Einsparungen im Speicher bieten könnte.

Es wird häufig danach gefragt, „wo“ der Vertragscode in Bezug auf physische Hardware ausgeführt wird. Die Antwort darauf ist einfach: Der Vorgang der Ausführung des Vertragcodes ist Teil der Definition der Statusübergangsfunktion, die Teil des Blockvalidierungsalgorithmus ist. Wenn eine Transaktion also in Block B hinzugefügt wird, wird die durch diese Transaktion ausgelöste Codeausführung von allen Knoten, die Block B herunterladen und validieren, jetzt und in Zukunft ausgeführt.

Anwendungen

Im Allgemeinen gibt es drei Arten von Anwendungen, die auf Ethereum aufbauen. Die erste Kategorie sind Finanzanwendungen, die den Benutzern leistungsstärkere Möglichkeiten zur Verwaltung und zum Abschluss von Verträgen mit ihrem Geld bieten. Dazu gehören Unterwährungen, Finanzderivate, Hedging-Verträge, Spar-Wallets, Testamente und letztendlich sogar einige Klassen von vollwertigen Arbeitsverträgen. Die zweite Kategorie sind semi-finanzielle Anwendungen, bei denen Geld eine Rolle spielt, aber auch eine starke nicht-monetäre Komponente vorhanden ist; ein perfektes Beispiel sind selbstdurchsetzende Kopfgelder für Lösungen von Rechenproblemen. Schließlich gibt es Anwendungen wie Online-Abstimmungen und dezentralisierte Verwaltung, die überhaupt nicht finanzieller Natur sind.

Token-Systeme

Blockchain-basierte Token-Systeme finden zahlreiche Anwendungen – von Unterwährungen, die Assets wie USD oder Gold repräsentieren, bis hin zu Unternehmensaktien, individuellen Token für Smart Property, sicheren, unverfälschbaren Gutscheinen und sogar Token-Systemen ohne Verbindung zu konventionellem Wert, die als Punktesysteme zur Anreizsetzung genutzt werden. Token-Systeme sind auf Ethereum überraschend einfach zu implementieren. Der entscheidende Punkt, den es zu verstehen gilt, ist, dass eine Währung oder ein Token-System grundsätzlich eine Datenbank ist, die nur eine Operation beinhaltet: Ziehe X Einheiten von A ab und übertrage X Einheiten an B, wobei die Bedingung gilt, dass (i) A vor der Transaktion mindestens X Einheiten hatte und (ii) die Transaktion von A genehmigt wird. Um ein Token-System zu implementieren, genügt es, diese Logik in einen Vertrag einzufügen.

Der grundlegende Code für die Implementierung eines Token-Systems in Serpent sieht folgendermaßen aus:

def send(to, value):
  if self.storage[msg.sender] >= value:
    self.storage[msg.sender] = self.storage[msg.sender] - value
    self.storage[to] = self.storage[to] + value

Dies ist im Wesentlichen eine buchstäbliche Implementierung der Statussübergangsfunktion des „Bankensystems“, die weiter oben in diesem Dokument beschrieben wurde. Ein paar zusätzliche Zeilen Code sind nötig, um die anfängliche Verteilung der Währungseinheiten und einige Grenzfälle zu behandeln. Idealerweise wird außerdem eine Funktion hinzugefügt, die es anderen Verträgen ermöglicht, den Saldo einer Adresse abzufragen. Aber das ist auch schon alles. Theoretisch können Ethereum-basierte Token-Systeme, die als Unterwährungen fungieren, eine weitere wichtige Funktion bieten, die den Bitcoin-basierten Meta-Währungen auf der Blockchain fehlt: die Möglichkeit, Transaktionsgebühren direkt in dieser Währung zu bezahlen. So würde das implementiert werden: Der Vertrag würde einen Ether-Saldo führen, mit dem er Ether zurückerstatten kann, der zur Bezahlung von Gebühren an den Absender verwendet wird, und er würde diesen Saldo auffüllen, indem er die internen Währungseinheiten, die er als Gebühren erhebt, einsammelt und in einer kontinuierlichen Auktion weiterverkauft. Benutzer müssten so zunächst ihre Konten mit Ether „aktivieren“, aber der eingesetzte Ether wäre dann wiederverwendbar, da der Vertrag ihn bei jeder Transaktion zurückerstattet.

Finanzderivate und wertstabile Währungen

Finanzderivate sind die häufigste Anwendung von „Smart Contracts“ und eine der am einfachsten in Code umzusetzenden. Die größte Herausforderung bei der Implementierung von Finanzverträgen besteht darin, dass die Mehrheit von ihnen auf einen externen Preisticker angewiesen ist; ein sehr begehrenswerter Anwendungsfall ist beispielsweise ein Smart Contract, der gegen die Volatilität von Ether (oder einer anderen Kryptowährung) im Verhältnis zum US-Dollar absichert. Dafür muss der Vertrag jedoch den Wert von ETH/USD kennen. Der einfachste Weg, dies zu erreichen, ist über einen „Datenfeed“-Vertrag, der von einer bestimmten Partei (z. B. NASDAQ) betrieben wird. Er ist so konzipiert, dass diese Partei in der Lage ist, den Vertrag nach Bedarf zu aktualisieren, und stellt eine Schnittstelle bereit, die es anderen Verträgen ermöglicht, eine Nachricht an diesen Vertrag zu senden und eine Rückmeldung zu erhalten, die den Preis enthält.

Unter dieser Voraussetzung würde der Hedging-Vertrag wie folgt aussehen:

Warten, bis Partei A 1000 Ether eingibt.
Warten, bis Partei B 1000 Ether eingibt.
Den USD-Wert von 1000 Ether, der durch das Abfragen des Datenfeed-Vertrags ermittelt wurde, im Speicher festhalten. Sagen wir, es sind x $.
Nach 30 Tagen A oder B erlauben, den Vertrag zu „ reaktivieren“, um x $ wertäquivalente Ether (berechnet durch erneutes Abfragen des Datenfeed-Vertrags, um den neuen Preis zu erhalten) an A und den Rest an B zu senden.

Ein solcher Vertrag hätte ein erhebliches Potenzial im Kryptohandel. Eines der Hauptprobleme, die im Zusammenhang mit Kryptowährungen angeführt werden, ist die Tatsache, dass sie volatil sind; obwohl viele Benutzer und Händler die Sicherheit und Bequemlichkeit im Umgang mit kryptografischen Assets wünschen, möchten sie möglicherweise nicht riskieren, innerhalb eines einzigen Tages 23 % des Wertes ihrer Mittel zu verlieren. Bis jetzt war die häufigste vorgeschlagene Lösung durch Herausgeber unterstützte Assets; die Idee ist, dass ein Herausgeber eine Unterwährung schafft, in der er das Recht hat, Einheiten auszugeben und zurückzuziehen, und einem beliebigen Benutzer eine Einheit der Währung bereitstellt, der ihm (offline) eine Einheit eines bestimmten zugrunde liegenden Assets (z. B. Gold oder USD) gibt. Der Herausgeber verspricht dann, eine Einheit des zugrunde liegenden Assets an jeden zu liefern, der ihm eine Einheit des Krypto-Assets zurücksendet. Dieser Mechanismus ermöglicht es, jedes nicht-kryptografische Asset in ein kryptografisches Asset „aufzuwerten“, vorausgesetzt, dem Herausgeber kann vertraut werden.

In der Praxis sind Herausgeber jedoch nicht immer vertrauenswürdig, und in einigen Fällen ist die Bankinfrastruktur zu schwach oder zu feindlich, als dass solche Dienstleistungen existieren könnten. Finanzderivate bieten eine Alternative. Hier spielt anstelle eines einzelnen Herausgebers, der die Mittel zur Deckung eines Assets bereitstellt, ein dezentraler Markt von Spekulanten diese Rolle, die darauf wetten, dass der Preis eines kryptografischen Referenz-Assets (z. B. ETH) steigen wird. Anders als Herausgeber haben Spekulanten keine Option, ihren Verpflichtungen nicht nachzukommen, da der Hedging-Vertrag ihre Mittel in einem Treuhandkonto hält. Beachten Sie, dass dieser Ansatz nicht vollständig dezentralisiert ist, da eine vertrauenswürdige Quelle weiterhin benötigt wird, um den Preisticker bereitzustellen. Dennoch ist dies in Bezug auf die Reduzierung der Infrastrukturanforderungen (im Gegensatz zum Herausgeber, der für die Ausgabe der Preisfeeds keine Lizenzen benötigt und wahrscheinlich als freie Meinungsäußerung eingestuft werden kann) und die Verringerung des Betrugsrisikos eine erhebliche Verbesserung.

Identitäts- und Reputationssysteme

Die früheste alternative Kryptowährung, Namecoin(opens in a new tab), versuchte, eine Bitcoin-ähnliche Blockchain zu nutzen, um ein Namensregistrierungssystem bereitzustellen, in dem Benutzer ihre Namen in einer öffentlichen Datenbank zusammen mit anderen Daten registrieren können. Ein häufig zitierter Anwendungsfall ist ein DNS(opens in a new tab)-System, das einen Domänennamen wie „bitcoin.org“ (oder „bitcoin.bit“ bei Namecoin) mit einer IP-Adresse verknüpft. Weitere Anwendungsfälle umfassen die E-Mail-Authentifizierung und potenziell fortschrittlichere Reputationssysteme. Hier ist der grundlegende Vertrag, um ein Namecoin-ähnliches Namensregistrierungssystem auf Ethereum bereitzustellen:

def register(name, value):
  if !self.storage[name]:
    self.storage[name] = value

Der Vertrag ist sehr einfach; er ist lediglich eine Datenbank innerhalb des Ethereum-Netzwerks, die ergänzt, aber nicht verändert oder entfernt werden kann. Jeder kann einen Namen mit einem gewissen Wert registrieren, und diese Registrierung bleibt dann für immer bestehen. Ein ausgeklügelterer Namensregistrierungsvertrag besitzt auch eine „Funktionsklausel“, die es anderen Verträgen ermöglicht, Abfragen vorzunehmen, sowie einen Mechanismus für den „Eigentümer“ (d. h. den ersten Registrierer) eines Namens, um die Daten zu ändern oder das Eigentum zu übertragen. Darüber hinaus kann man sogar noch Reputations- und Web-of-Trust-Funktionalitäten hinzufügen.

Dezentralisierter Dateispeicher

In den letzten Jahren sind eine Reihe beliebter Online-Dateispeicher-Startups entstanden, wobei das bekannteste Dropbox ist. Diese Dienste erlauben es dem Benutzer, ein Backup seiner Festplatte hochzuladen, das dann gespeichert wird, sodass der Benutzer gegen eine monatliche Gebühr darauf zugreifen kann. Derzeit ist der Dateispeichermarkt jedoch manchmal relativ ineffizient; ein oberflächlicher Blick auf verschiedene vorhandene Lösungen zeigt, dass insbesondere im „uncanny valley“-Bereich von 20–200 GB, in dem weder kostenlose Quoten noch Rabatte für Unternehmen greifen, die monatlichen Preise für gängige Dateispeicherlösungen so hoch sind, dass man mehr für einen Monat bezahlt als für die gesamte Festplatte. Ethereum-Verträge können die Entwicklung eines dezentralisierten Dateispeicher-Ökosystems ermöglichen, in dem einzelne Benutzer kleine Beträge verdienen können, indem sie ihre eigenen Festplatten vermieten. Ungenutzter Speicherplatz kann dazu verwendet werden, die Kosten für den Dateispeicher weiter zu senken.

Das zentrale Element eines solchen Systems wäre das, was wir als den „dezentralisierten Dropbox-Vertrag“ nennen. Dieser Vertrag funktioniert wie folgt. Zuerst wird die gewünschte Datenmenge in Blöcke aufgeteilt, wobei jeder Block im Sinne des Datenschutzes verschlüsselt wird, und daraus wird ein Merkle Tree erstellt. Anschließend wird ein Vertrag erstellt, der die Regel enthält, dass der Vertrag alle N Blöcke einen zufälligen Index im Merkle Tree auswählt (unter Verwendung des Hashes des vorherigen Blocks, der im Vertragscode zugänglich ist, als Zufallsquelle) und X Ether an die erste Entität vergibt, die eine Transaktion mit einem vereinfachten Nachweis über das Eigentum am Block an diesem bestimmten Index im Baum vorlegt. Wenn ein Benutzer seine Datei erneut herunterladen möchte, kann er ein Mikrozahlungsprotokoll verwenden (z. B. 1 Szabo pro 32 Kilobyte zahlen), um die Datei wiederherzustellen. Der gebühreneffizienteste Ansatz besteht darin, dass der Zahler die Transaktion bis zum Ende nicht veröffentlicht, sondern die Transaktion nach jeweils 32 Kilobyte durch eine etwas lukrativere mit demselben Nonce ersetzt.

Eine wichtige Eigenschaft des Protokolls ist, dass man, obwohl es scheinen mag, als vertraue man zahlreichen zufälligen Knoten dabei, die Datei nicht zu vergessen, dieses Risiko auf nahezu null reduzieren kann, indem man die Datei durch geheimes Teilen in viele Stücke aufteilt und die Verträge überwacht, um sicherzustellen, dass jedes Stück noch im Besitz eines Knotens ist. Wenn ein Vertrag weiterhin Geld auszahlt, ist dies ein kryptografischer Beweis dafür, dass jemand da draußen die Datei noch speichert.

Dezentralisierte autonome Organisationen

Das allgemeine Konzept einer „dezentralisierten autonomen Organisation“ bezieht sich auf eine virtuelle Entität, die eine bestimmte Gruppe von Mitgliedern oder Aktionären hat, die möglicherweise mit einer 67-%-Mehrheit das Recht haben, die Mittel der Entität auszugeben und ihren Code zu ändern. Die Mitglieder entscheiden gemeinsam, wie die Organisation ihre Mittel einsetzen sollte. Methoden zur Zuteilung der Mittel einer DAO könnten von Kopfgeldern und Gehältern bis hin zu exotischeren Mechanismen wie einer internen Währung reichen, um Arbeit zu belohnen. Dies stellt im Grunde die rechtlichen Rahmenbedingungen eines herkömmlichen Unternehmens oder einer Nonprofit-Organisation nach, nutzt dabei jedoch ausschließlich kryptografische Blockchain-Technologie zur Durchsetzung. Bisher hat sich viel von der Diskussion über DAOs um das „kapitalistische“ Modell einer „dezentralisierten autonomen Corporation“ (DAC) gedreht, mit dividendenberechtigten Aktionären und handelbaren Anteilen; eine Alternative, die vielleicht als „dezentralisierte autonome Community“ beschrieben werden kann, würde vorsehen, dass alle Mitglieder ein gleiches Mitspracherecht bei Entscheidungen haben und 67 % der bestehenden Mitglieder zustimmen müssen, um ein Mitglied hinzuzufügen oder zu entfernen. Die Anforderung, dass eine Person nur eine Mitgliedschaft haben kann, müsste dann kollektiv von der Gruppe durchgesetzt werden.

Ein allgemeiner Überblick über die Codierung einer DAO sieht folgendermaßen aus. Das einfachste Design besteht aus einem Stück selbstmodifizierendem Code, der sich ändert, wenn zwei Drittel der Mitglieder einer Änderung zustimmen. Obwohl Code theoretisch unveränderlich ist, kann man dies leicht umgehen und de facto Veränderlichkeit erreichen, indem man Teile des Codes in separaten Verträgen speichert und die Adressen der aufzurufenden Verträge im veränderbaren Speicher ablegt. In einer einfachen Implementierung eines solchen DAO-Vertrags gibt es drei Transaktionsarten, die anhand der in der Transaktion bereitgestellten Daten unterschieden werden:

[0,i,K,V], um einen Vorschlag mit Index i zu registrieren, um die Adresse am Speicherindex K auf den Wert V zu ändern
[1,i], um eine Stimme für den Vorschlag i zu registrieren
[2,i], um den Vorschlag i abzuschließen, wenn genügend Stimmen abgegeben worden sind

Der Vertrag hätte dann Klauseln für jeden Fall. Es würde eine Aufzeichnung aller offenen Änderungen am Speicher sowie eine Liste der entsprechenden Abstimmenden führen. Er würde auch eine Liste aller Mitglieder enthalten. Wenn eine Speicheränderung von zwei Dritteln der Mitglieder unterstützt wird, könnte eine abschließende Transaktion die Änderung ausführen. Ein ausgeklügelteres Gerüst würde auch eine integrierte Abstimmung für Funktionen wie das Senden einer Transaktion und das Hinzufügen und Entfernen von Mitgliedern beinhalten und könnte sogar eine Liquid Democracy(opens in a new tab)-ähnliche Stimmdelegation ermöglichen (d. h., jeder kann jemanden ernennen, der für ihn abstimmt, und die Ernennung ist transitiv, sodass, wenn A B ernennt und B C ernennt, C über As Stimme entscheidet). Dieses Design würde es der DAO ermöglichen, organisch als dezentralisierte Community zu wachsen, wodurch die Menschen letztendlich die Aufgabe an Spezialisten delegieren können, herauszufiltern, wer ein Mitglied ist. Anders als im „aktuellen System“ können Spezialisten jedoch im Laufe der Zeit leicht ein- und ausgehen, während sich die Ausrichtungen einzelner Community-Mitglieder ändern.

Ein alternatives Modell ist das einer dezentralisierten Corporation, bei der jedes Konto null oder mehr Anteile haben kann und zwei Drittel der Anteile erforderlich sind, um eine Entscheidung zu treffen. Ein vollständiges Gerüst würde Funktionen für das Asset-Management beinhalten, die Möglichkeit, ein Angebot zum Kauf oder Verkauf von Aktien zu machen, sowie die Fähigkeit, Angebote zu akzeptieren (idealerweise mit einem Ordermatching-Mechanismus im Vertrag). Es würde auch eine Delegation im Stil der Liquid Democracy geben, die das Konzept eines „Vorstands“ verallgemeinert.

Weitere Anwendungen

‌1. Spar-Wallets. Nehmen wir an, Alice möchte ihre Mittel schützen, ist jedoch besorgt, dass sie ihren privaten Schlüssel verlieren oder jemand ihn hacken könnte. Sie schließt mit Bob, einer Bank, einen Vertrag über Ether ab, und zwar wie folgt:

Alice allein kann maximal 1 % der Mittel pro Tag abheben.
Bob allein kann maximal 1 % der Mittel pro Tag abheben, aber Alice hat die Möglichkeit, eine Transaktion mit ihrem Schlüssel durchzuführen, die diese Möglichkeit ausschaltet.
Alice und Bob können gemeinsam einen beliebigen Betrag.

Normalerweise ist 1 % pro Tag genug für Alice, und wenn sie mehr abheben möchte, kann sie Bob um Hilfe bitten. Wenn Alices Schlüssel gehackt wird, wendet sie sich an Bob, um die Mittel auf einen neuen Vertrag zu übertragen. Wenn sie ihren Schlüssel verliert, wird Bob die Mittel trotzdem herausbekommen. Wenn sich Bob als böswillig erweist, kann sie ihm die Möglichkeit zum Abheben nehmen.

2. Ernteversicherung. Man kann leicht einen Vertrag für Finanzderivate erstellen, indem man anstelle eines Preisindexes einen Datenfeed über das Wetter verwendet. Wenn ein Landwirt in Iowa ein Derivat kauft, das umgekehrt auf die Niederschläge in Iowa basiert, erhält der Landwirt im Falle einer Dürre automatisch Geld, und wenn es genug regnet, wird der Landwirt glücklich sein, weil die Ernte gut gedeiht. Dies kann auf die Naturkatastrophenversicherung im Allgemeinen ausgeweitet werden.

3. Ein dezentralisierter Datenfeed. Bei Finanzverträgen über Differenzen könnte es tatsächlich möglich sein, den Datenfeed über ein Protokoll namens „SchellingCoin(opens in a new tab)“ zu dezentralisieren. SchellingCoin funktioniert im Wesentlichen wie folgt: N Parteien geben alle den Wert eines bestimmten Datums in das System ein (z. B. den ETH-USD-Preis), die Werte werden sortiert, und jeder, der zwischen dem 25. und dem 75. Perzentil liegt, erhält als Belohnung ein Token. Jeder hat den Anreiz, die Antwort zu geben, die auch alle anderen geben werden, und der einzige Wert, auf den sich eine große Anzahl von Spielern realistisch einigen kann, ist der offensichtliche Standard: die Wahrheit. Dies schafft ein dezentralisiertes Protokoll, das theoretisch beliebig viele Werte liefern kann, einschließlich des ETH-USD-Preises, der Temperatur in Berlin oder sogar des Ergebnisses einer bestimmten rechenintensiven Berechnung.

4. Intelligentes Mehrfachsignatur-Treuhandkonto. Bitcoin ermöglicht Mehrfachsignatur-Transaktionsverträge, bei denen beispielsweise drei von fünf Schlüsseln die Mittel ausgeben können. Ethereum erlaubt eine genauere Granularität; zum Beispiel können vier von fünf alles ausgeben, drei von fünf können bis zu 10 % pro Tag ausgeben, und zwei von fünf können bis zu 0,5 % pro Tag ausgeben. Zusätzlich ist die Ethereum-Mehrfachsignatur asynchron – zwei Parteien können ihre Signaturen zu unterschiedlichen Zeiten auf der Blockchain registrieren, und die letzte Signatur sendet automatisch die Transaktion.

5. Cloud-Computing. Die EVM-Technologie kann auch genutzt werden, um eine verifizierbare Rechenumgebung zu schaffen, die es Benutzern ermöglicht, andere zu bitten, Berechnungen durchzuführen, und dann optional nach Beweisen zu fragen, dass Berechnungen an bestimmten zufällig ausgewählten Kontrollpunkten korrekt durchgeführt wurden. Dies erlaubt die Einrichtung eines Marktes für Cloud-Computing, in dem jeder Benutzer mit seinem Desktop, Laptop oder spezialisierten Server teilnehmen kann, und Stichprobenkontrollen sowie Sicherheitsanforderungen können verwendet werden, um sicherzustellen, dass das System vertrauenswürdig ist (d. h., Knoten können nicht profitabel betrügen). Obwohl ein solches System möglicherweise nicht für alle Aufgaben geeignet ist, können Aufgaben, die ein hohes Maß an Zwischenprozesskommunikation erfordern, beispielsweise nicht leicht in einer großen Cloud von Knoten durchgeführt werden. Andere Aufgaben lassen sich jedoch viel leichter parallelisieren; Projekte wie SETI@home, folding@home und genetische Algorithmen können leicht auf einer solchen Plattform implementiert werden.

6. Peer-to-Peer-Glücksspiel. Eine beliebige Anzahl von Peer-to-Peer-Glücksspielprotokollen, wie zum Beispiel Frank Stajano und Richard Claytons Cyberdice(opens in a new tab), kann auf der Ethereum-Blockchain implementiert werden. Das einfachste Glücksspielprotokoll ist tatsächlich einfach ein Differenzvertrag auf den nächsten Block-Hash, und fortgeschrittenere Protokolle können darauf aufbauen, um Glücksspieldienste mit nahezu null Gebühren zu schaffen, die keine Betrugsmöglichkeiten bieten.

7. Prognosemärkte. Wenn ein Oracle oder SchellingCoin vorhanden ist, lassen sich Prognosemärkte ebenfalls leicht implementieren, und in Kombination mit SchellingCoin könnten Prognosemärkte die erste gängige Anwendung von Futarchie(opens in a new tab) als Governance-Protokoll für dezentralisierte Organisationen darstellen.

8. Dezentralisierte Marktplätze auf der Blockchain, welche das Identitäts- und Reputationssystem als Basis nutzen.

Verschiedenes und Bedenken

Modifizierte GHOST-Implementierung

Das „Greedy Heaviest Observed Subtree“(GHOST)-Protokoll ist eine Innovation, die erstmals von Yonatan Sompolinsky und Aviv Zohar im Dezember 2013(opens in a new tab) vorgestellt wurde. Die Motivation hinter GHOST ist, dass Blockchains mit schnellen Bestätigungszeiten derzeit unter einer verringerten Sicherheit leiden, aufgrund einer hohen Veralterungsrate – weil Blöcke eine bestimmte Zeit benötigen, um sich im Netzwerk auszubreiten. Wenn Miner A einen Block mint und dann Miner B zufällig einen weiteren Block mint, bevor der Block von Miner A zu B propagiert, wird der Block von Miner B letztlich verschwendet und trägt nicht zur Netzwerksicherheit bei. Darüber hinaus gibt es ein Zentralisierungsproblem: Wenn Miner A ein Mining-Pool mit 30 % Hash-Power ist und B 10 % Hash-Power hat, hat A ein Risiko von 70 %, einen veralteten Block zu erzeugen (da A die letzten 30 % der Zeit den letzten Block produziert hat und somit die Mining-Daten sofort erhält), während B ein Risiko von 90 % hat, einen veralteten Block zu erzeugen. Wenn das Blockintervall also kurz genug ist, um die Veralterungsrate hoch zu halten, wird A folglich allein aufgrund seiner Größe wesentlich effizienter sein. Durch die Kombination dieser beiden Effekte ist es sehr wahrscheinlich, dass Blockchains, die schnell Blöcke produzieren, dazu führen, dass ein Mining-Pool einen ausreichend großen Anteil der Netzwerk-Hash-Power hat, um de facto die Kontrolle über den Mining-Prozess zu übernehmen.

Wie von Sompolinsky und Zohar beschrieben, löst GHOST das erste Problem des Verlusts an Netzwerksicherheit, indem er veraltete Blöcke in die Berechnung einbezieht, welche Kette die „längste“ ist; das heißt, nicht nur die übergeordneten und noch früheren Vorgänger eines Blocks, sondern auch die veralteten Nachfolger der Vorgänger des Blocks (in der Ethereum-Sprache „Uncles“) werden in die Berechnung einbezogen, welcher Block die größte Gesamtmenge an Proof-of-Work unterstützt. Um das zweite Problem des Zentralisierungs-Bias zu lösen, gehen wir über das von Sompolinsky und Zohar beschriebene Protokoll hinaus und bieten auch Blockbelohnungen für veraltete Blöcke an: Ein veralteter Block erhält 87,5 % seiner Grundbelohnung, und der Neffe, der den veralteten Block enthält, erhält die verbleibenden 12,5 %. Die Transaktionsgebühren werden jedoch nicht an die Onkel vergeben.

Ethereum implementiert eine vereinfachte Version von GHOST, die nur sieben Ebenen benötigt. Konkret ist sie wie folgt definiert:

Ein Block muss einen übergeordneten Block sowie 0 oder mehr Onkel angeben
Ein Onkel, der im Block B enthalten ist, muss die folgenden Eigenschaften haben:
- Es muss ein direkter Nachfahre des Vorfahren der k. Generation von B sein, wobei 2 <= k <= 7.
- Er kann kein Vorfahre von B sein
- Ein Onkel muss ein gültiger Block-Header sein, muss aber kein zuvor verifizierter oder gar gültiger Block sein
- Ein Onkel muss sich von allen Onkeln unterscheiden, die in früheren Blöcken enthalten waren, sowie von allen anderen Onkeln, die im selben Block enthalten sind (keine doppelte Aufnahme)
Für jeden Onkel U in Block B erhält der Miner von B zusätzlich 3,125 % zur Coinbase-Belohnung und der Miner von U erhält 93,75 % der Standard-Coinbase-Belohnung.

Diese eingeschränkte Version von GHOST, bei der Onkel nur bis zu 7 Generationen einbezogen werden können, wurde aus zwei Gründen verwendet. Erstens würde unbegrenztes GHOST zu vielen Komplikationen in die Berechnung einfließen, welche Onkel für einen bestimmten Block gültig sind. Zweitens entfällt bei unbegrenztem GHOST mit Kompensation, wie es in Ethereum verwendet wird, der Anreiz für einen Miner, auf der Hauptkette und nicht auf der Kette eines öffentlichen Angreifers zu minen.

Gebühren

Da jede Transaktion, die in die Blockchain veröffentlicht wird, Kosten für das Herunterladen und Verifizieren beim Netzwerk verursacht, besteht die Notwendigkeit eines regulierenden Mechanismus, typischerweise in Form von Transaktionsgebühren, um Missbrauch zu verhindern. Der Standardansatz, der in Bitcoin verfolgt wird, besteht darin, rein freiwillige Gebühren zu erheben, wobei auf die Miner als Torwächter vertraut wird, die dynamische Mindestgebühren festlegen. Dieser Ansatz wurde in der Bitcoin-Community sehr positiv aufgenommen, insbesondere weil er „marktgesteuert“ ist und Angebot sowie Nachfrage zwischen Minern und Transaktionsabsendern den Preis bestimmen. Das Problem mit dieser Argumentation besteht jedoch darin, dass die Transaktionsverarbeitung kein Markt ist; obwohl es intuitiv verlockend ist, die Transaktionsverarbeitung als einen Service zu betrachten, den der Miner dem Absender anbietet, muss in der Realität jede Transaktion, die ein Miner einfügt, von jedem Knoten im Netzwerk verarbeitet werden, sodass die überwiegende Mehrheit der Kosten der Transaktionsverarbeitung von Dritten getragen wird und nicht von dem Miner, der entscheidet, ob er sie einfügt oder nicht. Deshalb ist es sehr wahrscheinlich, dass Probleme auftreten, die durch die Nutzung gemeinschaftlicher Ressourcen entstehen.

Wie sich jedoch herausstellt, hebt dieser Mangel im marktgestützten Mechanismus, bei einer bestimmten ungenauen vereinfachenden Annahme, sich selbst magisch auf. Das Argument lautet wie folgt. Nehmen wir an:

Eine Transaktion führt zu k Operationen und bietet eine Belohnung von kR für jeden Miner, der sie einfügt, wobei R vom Absender festgelegt wird und k und R (grob gesagt) im Voraus für den Miner sichtbar sind.
Eine Operation hat für jeden Knoten Verarbeitungskosten von C (d. h., alle Knoten haben die gleiche Effizienz).
Es gibt N Mining-Knoten, die jeweils genau die gleiche Verarbeitungsleistung besitzen (d. h. 1/N der Gesamtzahl).
Es gibt keine Vollknoten ohne Mining.

Ein Miner wäre bereit, eine Transaktion zu verarbeiten, wenn die erwartete Belohnung höher ist als die Kosten. Somit beträgt die erwartete Belohnung kR/N, da der Miner eine 1/N-Chance hat, den nächsten Block zu verarbeiten, und die Verarbeitungskosten für den Miner einfach kC betragen. Folglich schließen Miner Transaktionen ein, bei denen kR/N > kC oder R > NC ist. Beachten Sie, dass R die Gebühr pro Operation ist, die vom Absender bereitgestellt wird, und somit eine untere Grenze für den Nutzen darstellt, den der Absender aus der Transaktion zieht, während NC die Gesamtkosten für das gesamte Netzwerk zur Verarbeitung einer Operation sind. Daher haben Miner den Anreiz, nur diejenigen Transaktionen einzuschließen, deren gesamter utilitaristischer Nutzen die Kosten übersteigt.

Allerdings gibt es in Wirklichkeit mehrere wichtige Abweichungen von diesen Annahmen:

Der Miner hat höhere Kosten für die Verarbeitung der Transaktion als die anderen verifizierenden Knoten, da die zusätzliche Verifizierungszeit die Blockpropagation verzögert und somit die Wahrscheinlichkeit erhöht, dass der Block veraltet.
Es existieren vollständige Knoten ohne Mining.
Die Verteilung der Mining-Power könnte sich in der Praxis als radikal ungleichheitsfördernd erweisen.
Es gibt Spekulanten, politische Widersacher und Irre, deren Hilfsfunktion darin besteht, dem Netzwerk zu schaden, und sie können geschickt Verträge aufbauen, bei denen ihre Kosten deutlich unter denen der anderen prüfenden Knoten liegen.

(1) führt dazu, dass Miner weniger Transaktionen einfügen, und (2) erhöht NC; daher heben sich diese beiden Effekte zumindest teilweise auf.^{Wie?(opens in a new tab)} (3) und (4) sind das Hauptproblem; um sie zu lösen, setzen wir einfach eine dynamische Obergrenze fest: kein Block darf mehr Operationen enthalten als BLK_LIMIT_FACTOR-mal den langfristigen exponentiellen gleitenden Durchschnitt. Konkret:

blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)

BLK_LIMIT_FACTOR und EMA_FACTOR sind Konstanten, die vorläufig auf 65536 und 1,5 gesetzt werden, aber wahrscheinlich nach weiteren Analysen geändert werden.

Ein weiterer Faktor, der große Blockgrößen in Bitcoin unattraktiv macht, ist, dass größere Blöcke länger zur Propagation benötigen und somit eine höhere Wahrscheinlichkeit haben, zu veralten. In Ethereum benötigen Blöcke, die viel Gas verbrauchen, auch länger zur Propagation, weil sie größer sind und weil die Verarbeitung der Statusübergänge der Transaktionen zur Validierung mehr Zeit in Anspruch nimmt. Diese Verzögerungsabschreckung ist ein bedeutender Aspekt in Bitcoin, jedoch aufgrund des GHOST-Protokolls weniger ausgeprägt in Ethereum; daher bietet das Verlassen auf regulierte Blockgrenzen eine stabilere Basis.

Berechnungen und Turing-Completeness

Ein wichtiger Hinweis ist, dass die virtuelle Maschine von Ethereum Turing-komplett ist; das bedeutet, dass der EVM-Code jede Berechnung, die möglicherweise ausgeführt werden kann, einschließlich Endlosschleifen, codieren kann. Der EVM-Code ermöglicht das Looping auf zwei Arten. Erstens gibt es eine JUMP-Anweisung, die das Programm an einen früheren Punkt im Code springen lässt, und eine JUMPI-Anweisung für bedingtes Springen, die solche Aussagen wie while x < 27: x = x * 2 zulässt. Zweitens können Verträge andere Verträge aufrufen, was potenziell die Ausführung von Schleifen durch Rekursion ermöglicht. Dies führt zwangsläufig zu einem Problem: Können böswillige Benutzer Miner und vollständige Knoten im Grunde genommen ausschalten, indem sie sie in eine Endlosschleife zwingen? Das Problem ergibt sich aus einer Thematik in der Informatik, die als Halteproblem bekannt ist: Es gibt keine allgemeine Methode, um zu erkennen, ob ein bestimmtes Programm jemals zum Stillstand kommt oder nicht.

Wie im Abschnitt zu den Statusübergängen beschrieben funktioniert unsere Lösung, indem eine Transaktion die maximale Anzahl an Rechenschritten festlegt, die sie ausführen darf. Wenn die Ausführung länger dauert, wird die Berechnung zurückgesetzt, aber die Gebühren werden dennoch bezahlt. Nachrichten funktionieren auf die gleiche Weise. Um die Motivation hinter unserer Lösung zu verdeutlichen, betrachten Sie die folgenden Beispiele:

Ein Angreifer erstellt einen Vertrag, der eine Endlosschleife ausführt, und sendet dann eine Transaktion, die diese Schleife beim Miner aktiviert. Der Miner verarbeitet die Transaktion, führt die Endlosschleife aus und wartet darauf, dass das Gas ausgeht. Auch wenn die Ausführung kein Gas mehr hat und mitten im Vorgang stoppt, ist die Transaktion weiterhin gültig, und der Miner erhält von dem Angreifer die Gebühr für jeden Rechenschritt.
Ein Angreifer erstellt eine sehr lange Endlosschleife mit der Absicht, den Miner dazu zu bringen, so lange zu rechnen, dass, wenn die Berechnung abgeschlossen ist, bereits einige weitere Blöcke erstellt wurden und es dem Miner nicht möglich ist, die Transaktion zur Einforderung der Gebühr einzuschließen. Allerdings muss der Angreifer einen Wert für STARTGAS angeben, der die Anzahl der Rechenschritte begrenzt, die die Ausführung benötigen kann. Dadurch weiß der Miner bereits im Voraus, dass die Berechnung eine übermäßig große Anzahl von Schritten benötigen wird.
Ein Angreifer entdeckt einen Vertrag mit Code in der Form send(A,contract.storage[A]); contract.storage[A] = 0 und sendet eine Transaktion mit gerade genug Gas, um den ersten Schritt auszuführen, aber nicht den zweiten (d. h., eine Abhebung vorzunehmen, ohne den Saldo zu senken). Der Vertragsautor muss sich keine Sorgen um den Schutz vor solchen Angriffen machen, denn die Änderungen werden rückgängig gemacht, wenn die Ausführung im Änderungsprozess stoppt.
Eine finanzielle Vereinbarung funktioniert, indem der Median von neun proprietären Datenfeeds genommen wird, um das Risiko zu minimieren. Ein Angreifer übernimmt einen der Datenfeeds, der so gestaltet ist, dass er über den variablen Adressaufruf-Mechanismus, der im Abschnitt über DAOs beschrieben ist, modifiziert werden kann, und wandelt ihn so um, dass er in einer Endlosschleife läuft, um damit zu versuchen, alle Unternehmungen, Mittel aus dem Finanzvertrag zu beanspruchen, an den Gas-Limit scheitern zu lassen. Jedoch kann der Finanzvertrag ein Gas-Limit für die Nachricht festlegen, um dieses Problem zu verhindern.

Die Alternative zur Turing-Completeness ist Turing-Incompleteness, bei der JUMP und JUMPI nicht existieren und nur eine Kopie jedes Vertrags zu einem beliebigen Zeitpunkt im Aufrufstack existieren darf. Mit diesem System könnten das beschriebene Gebührensystem sowie die Unsicherheiten bezüglich der Wirksamkeit unserer Lösung möglicherweise entfallen, da die Kosten für die Ausführung eines Vertrags durch dessen Größe nach oben beschränkt wären. Zusätzlich ist Turing-Incompleteness nicht einmal eine allzu große Einschränkung; von allen Vertragsbeispielen, die wir intern konzipiert haben, benötigte bisher nur eines eine Schleife, und selbst diese Schleife konnte durch 26 Wiederholungen einer einzeiligen Codezeile entfernt werden. Angesichts der schwerwiegenden Folgen von Turing-Completeness und des begrenzten Nutzens – warum nicht einfach eine Turing-inkomplette Sprache verwenden? Tatsächlich ist Turing-Incompleteness jedoch alles andere als eine saubere Lösung für das Problem. Um den Grund zu verstehen, betrachten Sie die folgenden Verträge:

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (einen Schritt eines Programms ausführen und die Änderung im Speicher aufzeichnen)

Nun soll eine Transaktion an A gedendet werden. Damit haben wir in 51 Transaktionen einen Vertrag, der 2⁵⁰ Rechenschritte benötigt. Miner könnten versuchen, solche „Logikbomben“ im Voraus zu erkennen, indem sie einen Wert neben jedem Vertrag beibehalten, der die maximale Anzahl an Rechenschritten angibt, die er ausführen kann. Dies müsste auch für Verträge gelten, die andere Verträge rekursiv aufrufen, was jedoch erfordert, dass Miner Verträge verbieten, die andere Verträge erstellen (da die Erstellung und Ausführung aller oben genannten 26 Verträge leicht zu einem einzigen Vertrag zusammengefasst werden könnte). Ein weiterer problematischer Aspekt besteht darin, dass das Adressfeld einer Nachricht variabel ist, weshalb es im Allgemeinen nicht einmal möglich sein könnte, im Voraus zu erkennen, welche anderen Verträge ein bestimmter Vertrag aufrufen könnte. Daher kommen wir unterm Strich zu einem überraschenden Schluss: Turing-Completeness ist überraschend einfach zu verwalten, und das Fehlen von Turing-Completeness ist ebenso überraschend schwierig zu verwalten, es sei denn, genau dieselben Kontrollmechanismen sind vorhanden – aber warum sollte man in diesem Fall das Protokoll nicht einfach Turing-komplett sein lassen?

Währung und Ausgabe

Das Ethereum-Netzwerk beinhaltet seine eigene integrierte Währung, Ether, die zwei Zwecke erfüllt: Zum einen dient sie als primäre Liquiditätsebene, um einen effizienten Austausch zwischen verschiedenen Arten von digitalen Assets zu ermöglichen, und zum anderen, wichtiger noch, stellt sie einen Mechanismus zur Bezahlung von Transaktionsgebühren bereit. Zur Vereinfachung und um zukünftige Streitigkeiten zu vermeiden (siehe die aktuelle Diskussion über mBTC/uBTC/Satoshi in Bitcoin), werden die Nennwerte vorab gekennzeichnet:

1: Wei
10¹²: Szabo
10¹⁵: Finney
10¹⁸: Ether

Dies sollte als eine erweiterte Version des Konzepts von „Dollar“ und „Cent“ oder „BTC“ und „Satoshi“ betrachtet werden. In naher Zukunft erwarten wir, dass „Ether“ für alltägliche Transaktionen, „Finney“ für Mikrotransaktionen und „Szabo“ sowie „Wei“ für technische Diskussionen über Gebühren und Protokollimplementierungen verwendet werden; die verbleibenden Nennwerte könnten später nützlich werden und sollten zu diesem Zeitpunkt nicht in Clients enthalten sein.

Das Ausgabemodell wird wie folgt aussehen:

Ether wird in einem Währungsverkauf zum Preis von 1000–2000 Ether pro BTC angeboten – ein Mechanismus, der dazu dient, die Ethereum-Organisation zu finanzieren und die Entwicklung zu bezahlen, und der bereits erfolgreich von anderen Plattformen wie Mastercoin und NXT eingesetzt wurde. Frühere Käufer werden von größeren Rabatten profitieren. Die aus dem Verkauf erhaltenen BTC werden vollständig verwendet, um Gehälter und Prämien an Entwickler zu zahlen und in unterschiedliche gewinnorientierte sowie gemeinnützige Projekte innerhalb des Ethereum- und Kryptowährungs-Ökosystems zu investieren.
0,099-mal des insgesamt verkauften Betrags (60102216 ETH) werden der Organisation zugewiesen, um frühe Mitwirkende zu entschädigen und ETH-denominierte Ausgaben vor dem Genesis-Block zu begleichen.
0,099-mal des insgesamt verkauften Betrags werden als langfristige Reserve gehalten.
0,26-mal des insgesamt verkauften Betrags werden ab diesem Zeitpunkt dauerhaft jährlich an die Miner verteilt.

Gruppe	Beim Start	Nach 1 Jahr	Nach 5 Jahren
Währungseinheiten	1,198-mal	1,458-mal	2,498-mal
Käufer	83,5 %	68,6 %	40,0 %
Vor dem Verkauf ausgegebene Reserve	8,26 %	6,79 %	3,96 %
Nach dem Verkauf verwendete Reserve	8.26%	6.79%	3.96%
Miner	0 %	17,8 %	52,0 %

Langfristige Versorgungswachstumsrate (Prozent)

Trotz der linearen Währungsherausgabe tendiert, ähnlich wie bei Bitcoin, die Wachstumsrate des Angebots über die Zeit dennoch gegen null.

Die zwei Hauptentscheidungen im obigen Modell sind (1) die Existenz und Größe eines Endowment-Pools sowie (2) die Existenz einer dauerhaft wachsenden linearen Versorgung im Gegensatz zu einer begrenzten Versorgung wie bei Bitcoin. Die Rechtfertigung des Endowment-Pools ist wie folgt. Wenn es keinen Endowment-Pool gäbe und die lineare Ausgabe auf 0,217-mal verringert würde, um die gleiche Inflationsrate zu erreichen, würde die Gesamtmenge an Ether um 16,5 % niedriger sein, was bedeutet, dass jede Einheit 19,8 % mehr wert wäre. Daher würden im Gleichgewicht 19,8 % mehr Ether im Verkauf gekauft werden, sodass jede Einheit wieder genau so viel Wert hätte wie zuvor. Die Organisation hätte dann auch 1,198-mal so viel BTC, das als in zwei Segmente unterteilt betrachtet werden kann: das ursprüngliche BTC und die zusätzlichen 0,198-mal. Folglich ist diese Situation genau äquivalent zum Endowment, aber mit einem entscheidenden Unterschied: Die Organisation hält nur BTC und hat daher keinen Anreiz, den Wert der Ether-Einheit zu fördern.

Das Modell des permanenten linearen Angebotswachstums verringert das Risiko dessen, was einige als übermäßige Vermögenskonzentration in Bitcoin ansehen, und bietet jetzt und in Zukunft eine faire Chance, Währungseinheiten zu erwerben, während gleichzeitig ein starker Anreiz besteht, Ether zu erwerben und zu halten, da die „Angebotswachstumsrate“ prozentual betrachtet im Laufe der Zeit dennoch gegen null tendiert. Außerdem vermuten wir, dass Münzen aufgrund von Nachlässigkeit, Tod usw. im Laufe der Zeit immer verloren gehen und dass der Münzverlust als Prozentsatz des Gesamtangebots pro Jahr modelliert werden kann. Infolgedessen wird sich das gesamte im Umlauf befindliche Währungsangebot tatsächlich irgendwann auf einen Wert stabilisieren, der der jährlichen Ausgabe geteilt durch die Verlustquote entspricht (z. B. bei einer Verlustquote von 1 % wird, sobald für das Angebot das 26-Fache erreicht ist, jährlich das 0,26-Fache gemint und das 0,26-Fache geht verloren, was ein Gleichgewicht erzeugt).

Beachten Sie, dass Ethereum in Zukunft wahrscheinlich zu einem Proof-of-Stake-Modell für Sicherheit wechseln wird, wodurch die Ausgaberate auf irgendwo zwischen null und 0,05-mal pro Jahr gesenkt wird. Für den Fall, dass die Ethereum-Organisation ihre Finanzierung verliert oder aus irgendeinem anderen Grund verschwindet, lassen wir einen „Gesellschaftsvertrag“ offen: Jeder hat das Recht, eine zukünftige Kandidat-Version von Ethereum zu erstellen, wobei die einzige Bedingung ist, dass die Menge an Ether höchstens gleich 60102216 * (1.198 + 0.26 * n) sein darf, wobei n die Anzahl der Jahre nach dem Genesis-Block ist. Die Ersteller können frei entscheiden, einen Crowdsale durchzuführen oder auf andere Weise einen Teil oder die gesamte Differenz zwischen der von PoS angetriebenen Angebotsausweitung und der maximal erlaubten Angebotsausweitung zuzuweisen, um die Entwicklung zu bezahlen. Kandidaten-Upgrades, die nicht dem sozialen Vertrag entsprechen, dürfen berechtigterweise in konforme Versionen abgespalten werden.

Mining-Zentralisierung

Der Bitcoin-Mining-Algorithmus funktioniert, indem Miner SHA256 auf leicht modifizierte Versionen des Block-Headers Millionen von Malen berechnen, bis schließlich ein Knoten eine Version findet, deren Hash kleiner ist als das Ziel (derzeit etwa 2¹⁹²). Allerdings ist dieser Mining-Algorithmus anfällig für zwei Formen der Zentralisierung. Erstens wird das Mining-Ökosystem von ASICs (Application-Specific Integrated Circuits) dominiert, also von Computerchips, die speziell für das Bitcoin-Mining entwickelt wurden und daher tausendmal effizienter in dieser spezifischen Aufgabe sind. Das bedeutet, dass Bitcoin-Mining nicht mehr eine stark dezentralisierte und egalitäre Aktivität ist, die Millionen von Dollar an Kapital erfordert, um effektiv teilzunehmen. Zweitens führen die meisten Bitcoin-Miner die Blockvalidierung nicht tatsächlich lokal durch; stattdessen verlassen sie sich auf einen zentralisierten Mining-Pool, um die Block-Header bereitzustellen. Dieses Problem ist wohl schlimmer: Zum Zeitpunkt der Erstellung dieses Textes kontrollieren die drei größten Mining-Pools indirekt etwa 50 % der Rechenleistung im Bitcoin-Netzwerk, obwohl dies dadurch gemildert wird, dass Miner zu anderen Mining-Pools wechseln können, wenn ein Pool oder ein Bündnis sich einen 51-%-Angriff vornimmt.

Die aktuelle Absicht von Ethereum besteht darin, einen Mining-Algorithmus zu verwenden, bei dem Miner zufällige Daten aus dem Status abrufen, einige zufällig ausgewählte Transaktionen aus den letzten N Blöcken der Blockchain berechnen und den Hash des Ergebnisses zurückgeben müssen. Dies hat zwei wichtige Vorteile. Erstens können Ethereum-Verträge jede Art von Berechnung enthalten, sodass ein Ethereum-ASIC im Grunde genommen ein ASIC für allgemeine Berechnungen wäre – also ein besserer CPU. Zweitens erfordert das Mining Zugang zur gesamten Blockchain, was die Miner zwingt, die gesamte Blockchain zu speichern und mindestens in der Lage zu sein, jede Transaktion zu verifizieren. Dies macht zentralisierte Mining-Pools überflüssig; obwohl Mining-Pools immer noch die legitime Rolle haben können, die Zufälligkeit der Gewinnverteilung auszugleichen, kann diese Funktion ebenso gut von Peer-to-Peer-Pools ohne zentrale Kontrolle erfüllt werden.

Dieses Modell ist noch nicht getestet, und es könnte Schwierigkeiten dabei geben, bestimmte clevere Optimierungen zu vermeiden, wenn die Vertragsausführung als Mining-Algorithmus verwendet wird. Eine besonders interessante Eigenschaft dieses Algorithmus ist jedoch, dass er jedem ermöglicht, „den Brunnen zu vergiften“, indem er eine große Anzahl von Verträgen in die Blockchain einführt, die speziell dazu entwickelt wurden, bestimmte ASICs auszubremsen. Es bestehen wirtschaftliche Anreize für ASIC-Hersteller, einen solchen Trick zu verwenden, um gegeneinander vorzugehen. Daher ist die Lösung, die wir entwickeln, letztendlich eine adaptive wirtschaftlich-menschliche Lösung und nicht nur eine rein technische.

Skalierbarkeit

Eine häufige Sorge im Zusammenhang mit Ethereum ist die Frage der Skalierbarkeit. Wie Bitcoin leidet auch Ethereum unter dem Nachteil, dass jede Transaktion von jedem Knoten im Netzwerk verarbeitet werden muss. Derzeit beläuft sich die Größe der Bitcoin-Blockchain auf etwa 15 GB und wächst um etwa 1 MB pro Stunde. Wenn das Bitcoin-Netzwerk die 2000 Transaktionen pro Sekunde von Visa verarbeiten würde, würde es alle drei Sekunden um 1 MB wachsen (1 GB pro Stunde, 8 TB pro Jahr). Ethereum wird voraussichtlich ein ähnliches Wachstumsverhalten aufweisen, verschärft durch die Tatsache, dass es viele Anwendungen auf der Ethereum-Blockchain geben wird, anstatt nur eine Währung wie bei Bitcoin. Positiv zu vermerken ist jedoch, dass Ethereum-Vollknoten nur den Status und nicht die gesamte Historie der Blockchain speichern müssen.

Das Problem bei einer so großen Blockchain ist das Zentralisierungsrisiko. Wenn die Größe der Blockchain auf beispielsweise 100 TB ansteigt, wäre das wahrscheinlichste Szenario, dass nur eine sehr kleine Anzahl großer Unternehmen Vollknoten betreibt, während alle regulären Benutzer leichte SPV-Knoten verwenden. In einer solchen Situation entsteht die potenzielle Sorge, dass die Vollknoten sich zusammenschließen und alle einvernehmlich auf betrügerische Weise (z. B. die Blockbelohnung ändern oder sich selbst BTC geben) handeln könnten. Leichte Knoten hätten keine Möglichkeit, dies sofort zu erkennen. Natürlich würde wahrscheinlich mindestens ein ehrlicher Vollknoten existieren, und nach ein paar Stunden würden Informationen über den Betrug über Kanäle wie Reddit verbreitet werden. Aber zu diesem Zeitpunkt wäre es zu spät: Es wäre an den gewöhnlichen Benutzern, eine Initiative zu organisieren, um die betreffenden Blöcke auf die schwarze Liste zu setzen, was ein massives und vermutlich unpraktikables Koordinationsproblem darstellt – ähnlich dem einer erfolgreichen 51-%-Attacke. Im Fall von Bitcoin ist dies derzeit ein Problem, aber es gibt eine von Peter Todd(opens in a new tab) vorgeschlagene Modifikation der Blockchain, die dieses Problem lindern wird.

Kurzfristig wird Ethereum zwei zusätzliche Strategien nutzen, um mit diesem Problem umzugehen. Erstens werden alle Miner aufgrund der Blockchain-basierten Mining-Algorithmen gezwungen, Vollknoten zu sein, wodurch eine Untergrenze für die Anzahl der Vollknoten geschaffen wird. Zweitens, und das ist noch wichtiger, werden wir nach der Verarbeitung jeder Transaktion einen Wurzelknoten eines Zwischenspeicherbaums in die Blockchain einfügen. Selbst wenn die Blockvalidierung zentralisiert ist, kann das Zentralisierungsproblem durch ein Verifizierungsprotokoll umgangen werden, solange mindestens ein ehrlicher verifizierender Knoten existiert. Wenn ein Miner einen ungültigen Block veröffentlicht, muss dieser Block schlecht formatiert sein, oder der Status S[n] ist falsch. Da S[0] bekanntlich korrekt ist, muss es einen ersten Status S[i] geben, der inkorrekt ist, wobei S[i-1] korrekt ist. Der verifizierende Knoten würde den Index i zusammen mit einem „Beweis der Ungültigkeit“ bereitstellen, der aus der Teilmenge der Patricia Tree-Knoten besteht, die benötigt wird, um APPLY(S[i-1],TX[i]) -> S[i] zu verarbeiten. Knoten würden in der Lage sein, diese Knoten zu verwenden, um diesen Teil der Berechnung auszuführen und festzustellen, dass das erzeugte S[i] nicht mit dem bereitgestellten S[i] übereinstimmt.

Ein weiterer, ausgeklügelterer Angriff würde darin bestehen, dass böswillige Miner unvollständige Blöcke veröffentlichen, sodass die vollständigen Informationen überhaupt nicht vorhanden sind, um zu bestimmen, ob die Blöcke gültig sind oder nicht. Die Lösung dafür ist ein Challenge-Response-Protokoll: Verifizierungsknoten geben „Herausforderungen“ in Form von Zieltransaktionsindizes aus, und beim Empfang behandelt ein leichter Knoten den Block als vertrauensunwürdig, bis ein anderer Knoten, sei es der Miner oder ein anderer Verifizierer, eine Teilmenge der Patricia-Knoten als Beweis der Gültigkeit bereitstellt.

Fazit

Das Ethereum-Protokoll wurde ursprünglich als eine erweiterte Version einer Kryptowährung konzipiert, die fortschrittliche Funktionen wie Treuhand auf der Blockchain, Auszahlungsgrenzen, Finanzverträge, Glücksspielmärkte und ähnliche Dienste über eine stark verallgemeinerte Programmiersprache bereitstellt. Das Ethereum-Protokoll „unterstützt“ keine der Anwendungen direkt, aber das Vorhandensein einer Turing-kompletten Programmiersprache bedeutet, dass theoretisch willkürliche Verträge für jeden Transaktionstyp oder jede Anwendung erstellt werden können. Was jedoch an Ethereum besonders interessant ist, ist, dass das Ethereum-Protokoll weit über eine bloße Währung hinausgeht. Protokolle für dezentralisierte Dateispeicherung, dezentralisierte Berechnungen und dezentralisierte Prognosemärkte sowie Dutzende anderer ähnlicher Konzepte haben das Potenzial, die Effizienz der Computerindustrie erheblich zu steigern und andere Peer-to-Peer-Protokolle erstmals um eine wirtschaftliche Ebene zu erweitern. Schließlich gibt es auch eine beträchtliche Anzahl von Anwendungen, die überhaupt nichts mit Geld zu tun haben.

Das Konzept einer beliebigen Statusübergangsfunktion, wie es im Ethereum-Protokoll umgesetzt ist, bietet eine Plattform mit einzigartigem Potenzial; Ethereum ist kein geschlossenes, einzweckiges Protokoll, das für einen spezifischen Anwendungsbereich in der Datenspeicherung, im Glücksspiel oder in Finanzen gedacht ist, sondern von Natur aus offen gestaltet. Wir glauben, dass es äußerst gut geeignet ist, als grundlegende Ebene für eine sehr große Anzahl sowohl finanzieller als auch nicht-finanzieller Protokolle in den kommenden Jahren zu dienen.

Anmerkungen und weiterführende Literatur

Anmerkungen

Ein aufmerksamer Leser wird vielleicht feststellen, dass eine Bitcoin-Adresse in Wirklichkeit der Hash des öffentlichen Schlüssels der elliptischen Kurve und nicht der öffentliche Schlüssel selbst ist. In der Terminologie der Kryptografie ist es jedoch durchaus legitim, den Pubkey-Hash selbst als öffentlichen Schlüssel zu bezeichnen. Dies liegt daran, dass die Kryptografie von Bitcoin als ein spezifischer Algorithmus für digitale Signaturen betrachtet werden kann, bei dem der öffentliche Schlüssel aus dem Hash des ECC-Pubkeys besteht. Die Signatur besteht aus dem ECC-Pubkey verkettet mit der ECC-Signatur. Der Verifizierungsalgorithmus umfasst die Überprüfung des ECC-Pubkeys in der Signatur gegenüber dem ECC-Pubkey-Hash, der als öffentlicher Schlüssel bereitgestellt wird, und dann die Überprüfung der ECC-Signatur gegenüber dem ECC-Pubkey.
Technisch gesehen handelt es sich um den Median der 11 vorherigen Blöcke.
Intern sind sowohl 2 als auch „CHARLIE“ Zahlen^fn3, wobei „CHARLIE“ in Big-Endian zur Basis 256 dargestellt ist. Die Zahlen können mindestens 0 und höchstens 2²⁵⁶-1 sein.

Weiterführende Informationen

Informationen zur Geschichte des Whitepapers finden Sie in diesem Wiki(opens in a new tab).

Ethereum hat sich, wie viele durch die Community unterstützte Open-Source-Softwareprojekte, seit seinen Ursprüngen weiterentwickelt. Um mehr über die neuesten Entwicklungen von Ethereum zu erfahren und wie Änderungen am Protokoll vorgenommen werden, empfehlen wir diese Anleitung.