Metropolis: Byzantine, der erste Teil der Hardfork, beginnt am 17. Oktober

Der erste Teil der Metropolis-Hardfork von Ethereum ist jüngst im Testnet live gegangen. Am 17. Oktober soll die Hardfork dann auch im echten Ethereum-Netzwerk beginnen. Um Teil des Netzwerks zu bleiben, müssen User ihre Clients updaten. Doch was wird sich mit Metropolis eigentlich ändern? Ist die Hardfork ein großer Streich – oder bleibt sie unter den Erwartungen?

Am 17. Oktober wird Ethereum in die dritte Phase seines Lebenszyklus übergehen. Der erste Teil der Metropolis-Hardfork, Byzantine, wird einige Änderungen einleiten, die zwar nicht so grundsätzlich sind, wie eigentlich erwartet, aber Ethereum dennoch deutlich verändern werden.

Im Ropsten-Testnet hat die Hardfork bereits vor einer Woche begonnen. Im Mainnet wird das Uprade mit Block 4.370.000 aktiviert. Alle Ethereum-Clients, die zu diesem Zeitpunkt noch nicht aktualisiert sind, werden dnan nicht länger in der Lage sein, die neuen Blöcke zu lesen. Das Ethereum-Netzwerk bekommt ein General-Update.

Ursprünglich war geplant, mit der Metropolis-Phase von Proof of Work auf Proof of Stake zu wechseln. Dies hätte die Miner und ihre Grafikkarten aus dem System entfernt und durch Investoren ersetzt, die mit ihren Coins „staken“. Diese radikale Reform des grundsätzlichen Designs von Ethereum wird mit Metroplis nicht stattfinden. Die Ethereum-Entwickler haben sie auf den vierten und letzte Phase von Ethereum, Serenity, verschoben, um mit Metropolis erstmal kleinere Brötchen zu backen.

Um die Metropolis-Hardfork besser zu koordinieren, wurde sie in zwei Teile zerspalten: Byzantine und Constantinople. Der erste Teil, Byzantine, wird bald anstehen. Was aber wird er mit sich bringen? Wir schauen die Änderungen Stück für Stück an und versuchen, sie zu entziffern.

EIP 649: Die Eiszeit geht zu Ende

Der „Eiszeit-Algorithmus“ sorgt derzeit noch dafür, dass die Mining-Schwierigkeit bei Ethereum exponentiell ansteigt. Dies ist derzeit schon deutlich zu spüren, da die Ausschüttung frischer Ether zurückgeht, während die Block-Intervalle immer länger werden (Ethereum: Der Winter naht). Diese Eiszeit hat ausschließlich den Sinn, eine Hardfork zu erzwingen. Das mindeste, was die nun anstehende Byzantine-Hardfork machen muss, ist es, diese „Difficulty Bomb“ zurückzusetzen. Dies geschieht mit EIP 649. Genau gesagt: EIP 649 veschiebt die Eiszeit um 18 Monate und reduziert den Block-Reward gleichzeitig auf 3 anstatt bisher 5 Ether. Dies soll das System darauf vorbereiten, dass der Wechsel auf Proof of Stake die Ausschüttung künfig weiter senken wird.

Aber natürlich ist EIP 649 nicht der wichtigste Teil der Hardfork. Stattdessen haben wir 7 wichtige Änderungen, die das Ergebnis langer Diskussionen der Ethereum-Entwickler sind. Sie sind, ehrlich gesagt, recht technisch, und ich habe ein Weilchen gebraucht, um zu verstehen, was sie meinen. Dabei kann es gut sein, dass ich im Detail falsch liege, weshalb ich über jeden korrektiven Kommentar dankbar bin.

Die Byzantine-Hardfork betrifft 5 Bereiche von Ethereum:

Performance

EIP 98: Mehr Parallelisierung durch weniger State Root Berechnung

Ethereum hat einen sogenannten State Root: Dies ist ein spezieller Merkle-Tree, der eine Art Beweis des gesamten States, also aller aktiver Accounts und Verträge, darstellt. Bisher wird dieser State Root nach jeder Transaktion neu berechnet.

EIP 98 entfernt nun diese Neu-Berechnung der State Root nach jeder Transaktion. Dies macht es möglich, die Berechnung des State Roots stärker zu parallelisieren und allgemein weniger Merkle Roots zu berechnen. Dies wird offensichtlich dazu beitragen, Rechenleistung zu sparen. Zudem kann EIP 98 es in Zukunft ermöglichen, nicht nur die State Roots, sondern auch die Transaktionen selbst parallel zu verarbeiten. Was die notwendige Rechenleistung weiter reduzieren würde.

Die Schattenseite von EIP 98 ist, dass Fraud Proofs, mit denen Light-Clients Transaktionen prüfen können, aus dem gesamten Block bestehen müssen. Da die Blöcke bei Ethereum aber recht klein sind, ist dieses Problem, zumindest jetzt, noch sehr überschaubar.

Light Clients

EIP 658: Light Clients können erkennen, ob ein Contract richtig ausgeführt wurde

EIP 98 macht das State Root Feld in Transaktionen überflüssig. EIP 658 ersetzt es nun durch ein anderes Feld, das Informationen darüber gibt, ob ein Vertrag korrekt ausgeführt wurde. Dies macht es möglich, dass Light Clients, die nicht die Blockchain oder den kompletten State herunterladen, in der Lage sind, zu erkennen, ob ein Contract, den sie abgerufen oder kreiert haben, Erfolg hatte. Dies war bisher nicht möglich bzw. bedurfte der Hilfe zentraler Mittelsmänner.

Diese Änderung kann helfen, dass Light-Clients besser mit Verträgen interagieren können, während sie unabhängig von Mittelsmännern bleiben.

Mining

EIP 100: Anpassung des Rewards an die Uncles

Neben der Reduktion des Rewards durch EIP 649 greift auch EIP 100 in den Mining-Reward ein. Und zwar geht es um die sogenannten „Uncles.“ Wie bei Bitcoin kann es bei Ethereum vorkommen, dass ein Miner kurz davor ist, einen Block zu finden, aber dann von einem anderen Miner ausgestochen wird. Bei Bitcoin existieren solche Blöcke für eine kurze Zeit als „Waisen“, bevor die Chain, zu der sie gehören, abstirbt. Bei Ethereum werden diese Blöcke „Uncles“ genannt. Anders als bei Bitcoin werden sie ebenfalls belohnt. Dies soll das Mining fairer halten.

Bisher hat die Belohnung für Uncles dazu geführt, dass, unbeabsichtigt, der Reward je Block in manchen Situationen ein wenig höher war als die geplanten 5 Ether. Mit einer neuen Formel der Difficulty-Anpassung, die auch Uncles berücksichtigt, wird dieser Fehler ausgemerzt.

Privacy

EIP 198, 212, 213: Bahn frei für zk-Snarks

Die drei EIPs 198, 212 und 213 erlauben komplexere kryptographische Operationen innerhalb von Contracts, etwa RSA, sowie den Einsatz vorkompilierter Contracts auf einer bestimmten elliptischen Kurve. Diese Änderungen ermöglichen vor allem eines: den Einsatz der seit langem gewünschten zk-Snark Zero-Knowledge-Proofs, die die Entwickler von Zcash erfunden haben.

Diese zk-Snarks sind vermutlich das populärste und für den User wichtigste Feature der Byzantine-Hardfork. Sie ermöglichen es, Transaktion und weitere State-Änderungen in einem Zero-Knowledge-Proof zu verstecken. Dies erlaubt es dem Empfänger, zu prüfen, ob eine Transaktion korrekt ist – ohne dass der Sender diese unverschlüsselt veröffentlicht.

Eine Transaktion mit zk-Snark Proof dürfte zwar erheblich mehr Gas kosten als gewöhnliche Transaktionen. Aber es bringt die seit langem benötigte Privacy zu Ethereum.

Auf dem Ropsten Testnet wurde bereits die erste Transaktion mit einem zk-Snark Contract gebildet.

Contracts

Die meisten Änderungen der Byzantine-Hardfork betreffen die Contracts. Es sind erneut sehr unscheinbare Upgrades, die aber einen großen Effekt haben können.

EIP 214 Sicheres Aufrufen anderer Contracts in einem Contract

Es kann Fälle geben, in denen Smart Contracts andere Contracts aufrufen, während sie einen Prozess abarbeiten. Bisher gibt es das Problem, dass der innere Contract, also der, der aufgerufen wird, Priorität hat. Es ist ihm sogar möglich, den äußeren Contract, also den, der ihn aufgerufen hat, zu ändern. Dies verkompliziert die Interaktion zwischen Smart Contracts und hat etwa zum DAO-Bug geführt.

Durch die Einführung des Codes STATICCALL mit EIP 214 kann dies verhindert werden, indem Änderungen am State während eines Aufrufs eines Contracts nicht erlaubt sind. Dies macht die Konstruktion komplexer Smart Contracts sicherer.

EIP 211 Besseres Zurückgeben von Daten in einem Contract

Ein Problem in den bisherigen Contracts von Ethereum ist die Zurückgabe von Daten. Der Contract macht eine Operation, diese Operation hat ein Ergebnis, und der Contract gibt dieses zurück. Das Problem ist, dass man vorher wissen muss, wie groß diese Daten sind. Wenn nicht, wird es problematisch und verursachte chaotische oder äußerst hohe Gaspreise. Durch die Einführung der beiden neuen Codes RETURNDATASIZE und RETURNDATACOPY mit EIP 211 kann die Größe der zu empfangenden Daten flexibel neu berechnet werden.

EIP 206 Günstige Zurücknahme eines States

Mit dem durch EIP 206 eingeführen op-code REVERT kann die Ausführung einer Änderung des States gestoppt und diese zurückgenommen werden, ohne dass das gesamte Gas verbraucht wird. Bisher ist dies nur über komplexe und teure Umwege möglich. Mit den neuen Codes ist es nicht nur günstiger, sondern es ist auch möglich, einen Grund für die Zurücknahme zurückzugeben.

—

Die Änderungen, die der erste Teil der Metropolis-Hardfork mit sich bringt, sind sehr technisch und schwer einzuschätzen. Es geht um die Details.

Abgesehen von zk-Snarks scheint sich für den User nicht so viel zu ändern. Eventuell wird es möglich sein, mit Light-Wallets besser mit Contracts zu interagieren, eventuell wird der Aufbau des States in Zukunft schneller gehen, und eventuell werden die neuen op-codes für Smart Contracts eine bessere, unkomplizierere und sicherere Interaktion von Smart Contracts erlauben.

Eine schmutzige Hardfork, bei der es zur dauerhaften Spaltung der Chains kommt, ist nicht zu erwarten. Anders als bei der DAO-Hardfork, die zur Entstehung von Ethereum Classic geführt hat, scheint es in der Ethereum-Community einen vollständigen Konsens für Metropolis zu geben. Schließlich macht diese Hardfork keine Ereignisse ungeschehen und war ja auch schon lange angekündigt. Die Eiszeit, die derzeit weiter droht, macht eine Hardfork zudem sowieso unausweichlich.