Ein wichtiger und immer wieder unterschätzter Aspekt von "Vertrauenslosigkeit", "den Walkaway-Test bestehen" und "Selbstsouveränität" ist die Einfachheit des Protokolls. Selbst wenn ein Protokoll super dezentralisiert ist mit Hunderttausenden von Knoten und es 49 % byzantinische Fehlertoleranz hat und die Knoten alles mit quantensicheren Peerdas und Starks vollständig verifizieren, wenn das Protokoll ein unhandliches Durcheinander aus Hunderttausenden von Codezeilen und fünf Formen von PhD-niveau Kryptographie ist, dann besteht dieses Protokoll letztendlich alle drei Tests nicht: * Es ist nicht vertrauenslos, weil man einer kleinen Gruppe von Hochpriestern vertrauen muss, die einem sagen, welche Eigenschaften das Protokoll hat. * Es besteht den Walkaway-Test nicht, weil es extrem schwierig ist, für neue Teams auf das gleiche Qualitätsniveau zu kommen, wenn bestehende Client-Teams wegfallen. * Es ist nicht selbstsouverän, weil, wenn selbst die technisch versiertesten Personen das Ding nicht inspizieren und verstehen können, es nicht vollständig deins ist. Es ist auch weniger sicher, denn jeder Teil des Protokolls, insbesondere wenn er auf komplizierte Weise mit anderen Teilen interagieren kann, birgt das Risiko, dass das Protokoll kaputtgeht. Eine meiner Ängste bei der Entwicklung des Ethereum-Protokolls ist, dass wir zu begierig sind, neue Funktionen hinzuzufügen, um sehr spezifische Bedürfnisse zu erfüllen, selbst wenn diese Funktionen das Protokoll aufblähen oder ganze neue Arten von interagierenden Komponenten oder komplizierte Kryptographie als kritische Abhängigkeiten hinzufügen. Das kann kurzfristig für funktionale Gewinne schön sein, aber es ist äußerst destruktiv für die Erhaltung langfristiger Selbstsouveränität und die Schaffung einer hundertjährigen dezentralen Hyperstruktur, die den Aufstieg und Fall von Reichen und Ideologien überdauert. Das Kernproblem ist, dass, wenn Protokolländerungen aus der Perspektive "wie groß sind sie als Änderungen am bestehenden Protokoll" beurteilt werden, der Wunsch, die Rückwärtskompatibilität zu bewahren, bedeutet, dass Ergänzungen viel häufiger stattfinden als Streichungen, und das Protokoll im Laufe der Zeit unvermeidlich aufbläht. Um dem entgegenzuwirken, benötigt der Entwicklungsprozess von Ethereum eine explizite Funktion zur "Vereinfachung" / "Müllabfuhr". "Vereinfachung" hat drei Metriken: * Minimierung der gesamten Codezeilen im Protokoll. Ein ideales Protokoll passt auf eine einzige Seite - oder zumindest auf ein paar Seiten. * Vermeidung unnötiger Abhängigkeiten von grundsätzlich komplexen technischen Komponenten. Zum Beispiel ist ein Protokoll, dessen Sicherheit ausschließlich von Hashes abhängt (noch besser: von genau einer Hash-Funktion), besser als eines, das von Hashes und Gittern abhängt. Isogenien einzuführen, ist das Schlimmste, denn (entschuldigung an die wirklich brillanten, hart arbeitenden Nerds, die das herausgefunden haben) niemand versteht Isogenien. * Hinzufügen von mehr _Invarianten_: Kern-Eigenschaften, auf die das Protokoll sich verlassen kann, zum Beispiel hat EIP-6780 (Entfernung der Selbstzerstörung) die Eigenschaft hinzugefügt, dass maximal N Speicherplätze pro Slot geändert werden können, was die Client-Entwicklung erheblich vereinfacht, und EIP-7825 (Gasobergrenze pro Transaktion) hat eine Obergrenze für die Kosten der Verarbeitung einer Transaktion hinzugefügt, was ZK-EVMs und paralleler Ausführung erheblich hilft. Die Müllabfuhr kann stückweise oder im großen Maßstab erfolgen. Der stückweise Ansatz versucht, bestehende Funktionen zu nehmen und sie so zu straffen, dass sie einfacher sind und mehr Sinn machen. Ein Beispiel sind die Gaspreisreformen in Glamsterdam, die viele Gaspreise, die zuvor willkürlich waren, stattdessen von einer kleinen Anzahl von Parametern abhängig machen, die klar mit dem Ressourcenverbrauch verbunden sind. Eine großangelegte Müllabfuhr war der Austausch von PoW durch PoS. Eine weitere wird wahrscheinlich als Teil des Lean-Konsenses stattfinden, was den Raum eröffnet, eine große Anzahl von Fehlern gleichzeitig zu beheben ( ). Ein weiterer Ansatz ist die "Rosetta-Stil Rückwärtskompatibilität", bei der Funktionen, die komplex, aber wenig genutzt werden, weiterhin nutzbar bleiben, aber von der Pflicht des Protokolls "herabgestuft" werden und stattdessen Smart-Contract-Code werden, sodass neue Client-Entwickler sich nicht damit beschäftigen müssen. Beispiele: * Nachdem wir auf vollständige native Kontenabstraktion umgestiegen sind, können alle alten Transaktionstypen zurückgezogen werden, und EOAs können in Smart-Contract-Wallets umgewandelt werden, deren Code alle diese Transaktionstypen verarbeiten kann. * Wir können bestehende Precompiles (außer denen, die _wirklich_ benötigt werden) durch EVM- oder später RISC-V-Code ersetzen. * Wir können schließlich die VM von EVM auf RISC-V (oder eine andere einfachere VM) ändern; EVM könnte in einen Smart-Contract in der neuen VM umgewandelt werden. Schließlich wollen wir weg von dem Gefühl der Client-Entwickler, dass sie alle älteren Versionen des Ethereum-Protokolls handhaben müssen. Das kann älteren Client-Versionen überlassen werden, die in Docker-Containern laufen. Langfristig hoffe ich, dass die Änderungsrate von Ethereum langsamer werden kann. Ich denke aus verschiedenen Gründen, dass das letztendlich _passieren muss_. Diese ersten fünfzehn Jahre sollten teilweise als eine Adoleszenzphase betrachtet werden, in der wir viele Ideen erkundet haben und gesehen haben, was funktioniert und was nützlich ist und was nicht. Wir sollten uns bemühen, die Teile zu vermeiden, die nicht nützlich sind, die eine permanente Belastung für das Ethereum-Protokoll darstellen.