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

Ethereum Brand Logo. Erstellt von der Ethereum Foundation, Lizenz: Creative Commons 3.0

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.

About Christoph Bergmann (1147 Articles)
Das Bitcoinblog wird von bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder. Wenn Ihnen das Blog gefällt, freuen wir uns über Spenden an 1BvayiASVCmGmg4WUJmyRHoNevWWo5snqC. Wir akzeptiere mit dieser Adresse sowohl Bitcoin als auch Bitcoin Cash. Weitere Infos, wie Sie uns unterstützen können, finden Sie HIER. Gastbeiträge sind ebenfalls willkommen. Meinen öffentlichen PGP-Schlüssel sowie den Bitmessage-Schlüssel finden Sie HIER

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

  1. Hallo Christoph,

    was du vergessen hast: Welche Version von den bekannten Clients ist denn notwendig, damit man nach der Fork noch im Netzwerk bleibt?

    Grüße,
    Jeanette.

  2. Der Artikel macht mir vor allem deutlich, wieviel ich am Ethereum noch immer nicht verstehe. Darum sah ich schon das Ende des Ethereums kommen, aber dann fiel mir doch noch ein, daß es den meisten Investoren völlig schnuppe ist, wenn sie nichts von dem verstehen, worin sie investieren.

    Mir war beispielsweise nichtmal klar, daß Smart Contracts kostenmäßig völlig aus dem Ruder laufen können. Ich bin davon ausgegangen, daß man sich wie bei einem herkömmlichen Vertrag über den Preis einigt und nicht einfach davon überraschen läßt.

    Die Kritik aus dem Artikel über ZCash wird wohl in Zukunft auch für Ethereum gelten, wo es dann gleichermaßen transparente und anonyme Transaktionen geben wird. Wieso braucht ausgerechnet Ethereum, das seine Stärke auf einem ganz anderem Gebiet hat, mehr Privacy? Die neuen Light Clients bleiben dann bei den zk-Snarks außen vor? Wie funktioniert überhaupt ein zk-Snark?

    Die Light Clients sind offenbar ein Resultat daraus, daß man sich der Tatsache bewußt wurde, daß die Konzentration einer Blockchain auf immer weniger Computer, weil die leistungsfähiger sein müssen, ein Konstruktionsfehler der Blockchain-Kryptowährungen ist.

    Auch hätte ich es einem innerem Smart Contract, also einem Unterprogramm, nicht zugetraut, einen äußeren Smart Contract, also das aufrufende Programm, zu ändern. Das gibt es sonst bei Computerprogrammen nicht. Schon weil man dafür das aufrufende Programm kennen müßte, während ein Unterprogramm vielseitig sein sollte, damit man es in anderen Programmen wiederverwenden kann.

    Auf der Ethereum-Blockchain existieren bereits einige Token und Smart Contracts. Wie wirken sich die Änderungen auf diese aus? Wenn alte Clients die neuen Blöcke nicht mehr lesen können, dann müssen die neuen Blöcke schließlich anders sein als die alten Blöcke. Kann es also sein, daß dadurch manche Smart Contracts nicht mehr ausgeführt werden können?
    らんま

    • Das ist ein etwas egozentrisches Weltbild. Nur weil man eine Sache nicht versteht, heisst das nicht dass
      a) alle anderen die Sache auch nicht verstehen
      b) eine Sache deshalb scheitert

      Die von Dir gestellten Fragen (oder soll das Kritik sein) drehen sich entweder um Nebensächlichkeiten oder Maßnahmen, die aktuell nur über Umwege zu erreichen sind und so vereinfacht werden, oder können bei wirklichem Interesse im Internet gegoogelt werden.

      Das aktuelle Update ist eigentlich nur Finetuning und Vorbereitung für den nachsten Schritt. Grosses Ah und Oh ist nicht zu erwarten und war wohl auch nicht Ziel.

      Ja, Ethereum ist komplex und man muss sich da reinarbeiten. Wenn es nicht so wäre würden die Leute wieder meckern, dass das ja keine tolle Erfindung sei….passiert ja jetzt schon.
      Also entweder reinarbeiten und fundiert kritisieren oder halt nehmen wie es ist und damit traden…
      Ich muss auch nicht wissen, wie genau das mit der Airodynamik beim Flugzeug funktioniert, die Passagiere müssen nur dran glauben (nach Neil Gaiman / Wednesday in American Gods)

      • „Ja, Ethereum ist komplex und man muss sich da reinarbeiten.“

        Nach wie vor der Grund, warum ich bitcoinblog.de lese und hier Fragen stelle. Wieso scheint das so schwer zu verstehen zu sein?
        らんま

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s