Die Sache mit dem schnelleren Ethereum: Sie hängt seit jeher in einem gordischen Knoten fest. Wenn man möchte, dass die Kette schneller läuft, muss man oft entweder Dezentralisierung oder Zensurresistenz opfern.
Der von Autor #Ethlabs vorgeschlagene EIP-8198 (Quick Slots) versucht, diesen Knoten zu umgehen – die Idee ist ziemlich clever.
Der Ansatz geht in zwei Schritten vor: Zunächst wird die Blockzeit schrittweise von 12 Sekunden auf 10 Sekunden gedrückt, aber nicht auf einmal „auf den Punkt“ geändert. Stattdessen wird daraus ein „kontrollierbares, stufenweise testbares Geschwindigkeits-Upgrade“; parallel werden außerdem Kapazitäts-, Gas- und Blob-Parameter angepasst.
Der Knackpunkt liegt in den Worten „stufenweise“. In der Vergangenheit hatte Ethereum-Upgrade-Entscheidungen vor allem Angst vor einem Alles-oder-Nichts: Wenn man die Parameter auf einen Schlag ändert und danach etwas schiefgeht, leidet das gesamte Netzwerk gleichzeitig darunter. Das Design mit variabler Rate zerlegt das Risiko in kleine Portionen: Man verändert jedes Mal nur ein bisschen, beobachtet die Ergebnisse – und geht erst weiter, wenn alles unproblematisch ist.
Das erklärt auch, warum sich die Weiterentwicklung von Ethereum oft so langsam anfühlt: Es will nicht die allerbeste Geschwindigkeit um jeden Preis, sondern „schneller werden, ohne die Kontrolle zu verlieren“. Die Geschwindigkeit kann man nach und nach erhöhen – aber wenn die Dezentralisierung erst einmal verloren ist, bekommt man sie nicht zurück.
Die eigentlichen technischen Schwierigkeiten bestehen nie darin, ob man es schnell machen kann, sondern ob es nach der Beschleunigung noch dieselbe Kette ist.
Der von Autor #Ethlabs vorgeschlagene EIP-8198 (Quick Slots) versucht, diesen Knoten zu umgehen – die Idee ist ziemlich clever.
Der Ansatz geht in zwei Schritten vor: Zunächst wird die Blockzeit schrittweise von 12 Sekunden auf 10 Sekunden gedrückt, aber nicht auf einmal „auf den Punkt“ geändert. Stattdessen wird daraus ein „kontrollierbares, stufenweise testbares Geschwindigkeits-Upgrade“; parallel werden außerdem Kapazitäts-, Gas- und Blob-Parameter angepasst.
Der Knackpunkt liegt in den Worten „stufenweise“. In der Vergangenheit hatte Ethereum-Upgrade-Entscheidungen vor allem Angst vor einem Alles-oder-Nichts: Wenn man die Parameter auf einen Schlag ändert und danach etwas schiefgeht, leidet das gesamte Netzwerk gleichzeitig darunter. Das Design mit variabler Rate zerlegt das Risiko in kleine Portionen: Man verändert jedes Mal nur ein bisschen, beobachtet die Ergebnisse – und geht erst weiter, wenn alles unproblematisch ist.
Das erklärt auch, warum sich die Weiterentwicklung von Ethereum oft so langsam anfühlt: Es will nicht die allerbeste Geschwindigkeit um jeden Preis, sondern „schneller werden, ohne die Kontrolle zu verlieren“. Die Geschwindigkeit kann man nach und nach erhöhen – aber wenn die Dezentralisierung erst einmal verloren ist, bekommt man sie nicht zurück.
Die eigentlichen technischen Schwierigkeiten bestehen nie darin, ob man es schnell machen kann, sondern ob es nach der Beschleunigung noch dieselbe Kette ist.