Mitbegründer von Ethereum Vitalik Buterin glaubt, dass die langfristige Widerstandsfähigkeit und Skalierbarkeit der Blockchain darauf abhängt, sie einfach zu machen, wie Bitcoin. In einem Blog Post Am 3. Mai beschrieb er, wie „Ethereum in 5 Jahren so einfach werden kann wie Bitcoin“. Buterin schrieb:
“Eines der besten Dinge an Bitcoin ist, wie schön das Protokoll ist.”
Laut Buterin macht es Bitcoins minimalistisches Design und Einfachheit zugänglich, so dass selbst ein Schüler das Konzept und die Architektur des Protokolls erfassen kann. Simplicity, argumentierte Buterin, bringt auch andere Vorteile mit, z.
Jüngste Upgrades wie Proof-of-STake (POS) und Zero-Knowledge, das präzise nicht-interaktives Argument für Wissen (ZK-Snark) integriert ist, haben Ethereum robuster gemacht. Die Vernachlässigung der Einfachheit des Designs hat jedoch die Kosten von Ethereum beigetragen. Buterin erklärte:
“Historisch gesehen hat Ethereum dies oft nicht getan (manchmal aufgrund meiner eigenen Entscheidungen), und dies hat zu einem Großteil unserer übermäßigen Entwicklungsausgaben, aller Arten von Sicherheitsrisiken und der Insularität der F & E -Kultur beigetragen, die sich häufig als illusorisch erwiesen haben.”
Vereinfachung der Ethereum -Konsensschicht
Im November der Forscher der Ethereum Foundation, Justin Drake vorgeschlagen Ein Konsensschicht -Upgrade namens “Strahlkette”. Buterin glaubt, dass die Strahlkette „gut positioniert ist, um viel einfacher zu sein“ als ihr veralteter Vorgänger, die aktuelle Beacon-Kette.
Dies liegt daran, dass die Strahlkette 3-Slot-Endgüter-Neugestaltung ermöglicht, wodurch komplexe Konzepte wie separate Slots, Epochen und Synchronisierungsausschüsse beseitigt werden, bemerkte Buterin. Er betonte auch, dass eine grundlegende Implementierung von 3-Slot-Endgültigkeit durch etwa 200 Codezeilen erreicht werden kann, was es viel einfacher macht.
Die Strahlkette reduziert auch die Anzahl der aktiven Validatoren gleichzeitig, was es „sicherer macht, einfachere Implementierungen der Fork Choice -Regel zu verwenden“, schrieb Buterin.
Die Strahlkette wird auch Stark-basierte Aggregationsprotokolle enthalten, was bedeutet, dass jeder ein Aggregator sein kann. Buterin bemerkte:
“Die Komplexität der Aggregationskryptographie selbst ist signifikant, aber zumindest stark eingekapselte Komplexität, was ein viel geringeres systemisches Risiko für das Protokoll aufweist.”
Buterin fügte hinzu, dass die Reduzierung aktiver Validatoren und die Einbeziehung von Stark-basierten Aggregatoren wahrscheinlich eine einfachere und robustere P2P-Architektur ermöglichen werden. Er fuhr fort, dass es eine Gelegenheit gibt, mehrere Facetten zu überdenken und zu vereinfachen, vom Validatoreintritt und dem Ausgang bis zum Inaktivitätsleck. Dies kann sowohl durch Reduzieren der Code-Zählung (Line-of-Code) als auch durch Erstellen von „lesbareren Garantien“ erreicht werden.
Buterin betonte, dass die Konsensschicht „relativ getrennt“ von der EVM -Ausführungen (Virtual Machine) von Ethereum ist, die einen „relativ breiten Breitengrad“ bietet, um Verbesserungen im Vergleich zur Ausführungsschicht vorzunehmen.
Vereinfachung der Ethereum -Ausführungsschicht
Letzten Monat Buterin vorgeschlagen Ersetzen Sie die EVM-Vertragssprache durch RISC-V, um die Effizienz um bis zu 100x zu steigern. Buterin argumentierte, dass die Einführung von RISC-V auch die Einfachheit erhöhen wird, da die „RISC-V-Spezifikation im Vergleich zum EVM absurd einfach ist“.
Dies würde jedoch bedeuten, dass die Abwärtskompatibilität für bestehende Anwendungen erhalten bleibt. Buterin schrieb:
“Das erste, was wichtig zu verstehen ist, ist: Es gibt keine einzige Möglichkeit, die” Ethereum -Codebasis “(sogar innerhalb eines einzelnen Clients) abzugrenzen.”
Laut Buterin kann der orangefarbene Bereich nicht verringert werden. Das Ziel, behauptete Buterin, sei es, den Grünbereich zu minimieren, den Code in den gelben Bereich zu verschieben, der angibt, dass „Code, der für das Verständnis und die Interpretation der Kette heute sehr wertvoll ist, oder für ein optimales Blockgebäude, aber nicht Teil des Konsens ist“. Buterin verglich diesen Prozess damit, wie Apple durch Übersetzungsschichten eine langfristige Rückwärtskompatibilität erzielt. Er schrieb:
“Wichtig ist, dass die orange und gelben Bereiche die Komplexität verkörpert, jeder, der das Protokoll verstehen möchte, kann sie überspringen, die Implementierungen von Ethereum können sie frei überspringen, und alle Fehler in diesen Bereichen stellen keine Konsensrisiken dar.”
Aus diesem Grund haben die Codekomplexität in den orange und gelben Bereichen „weit weniger Nachteile“ im Vergleich zur Codekomplexität im grünen Bereich.
Um den Grünbereich zu reduzieren, schlug Buterin die folgenden Schritte vor:
Phase 1: Neue Präkompilien werden in RISC-V geschrieben.
Phase 2: Entwickler haben die Möglichkeit, Verträge in RISC-V zu schreiben.
Phase 3: Alle Präkompilien werden durch eine Hardgabelung durch RISC-V-Implementierungen ersetzt.
Phase 4: Implementieren Sie einen EVM-Dolmetscher in RISC-V und schieben Sie ihn als intelligenten Vertrag auf.
Die obigen Schritte würden sicherstellen, dass der Konsens des Ethereum „nativ“ nur RISC-V verstehen würde, erklärte Buterin.
Protokollweite Standards zur Vereinfachung
Buterin schlug vor, „einen Standard über verschiedene Teile des Stapels“ als Weg zur Vereinfachung zu teilen.
Zum Beispiel schlug Buterin vor, einen einzelnen Löschcode für die Datenverfügbarkeitsabtastung, P2P -Rundfunk und den Speicher verteilter Historien zu verwenden. Dies würde die Gesamtleitungen des Code minimieren, die Effizienz erhöhen und die Überprüfbarkeit sicherstellen, argumentierte er.
In ähnlicher Weise schlug er vor, ein einzelnes gemeinsames Serialisierungsformat in den drei Ethereum -Ebenen zu haben: Ausführungsschicht, Konsensschicht und Smart Contract Calling Application Binary Interface (ABI). Buterin schlug vor, SSZ zu verwenden, das leicht zu dekodieren und weit verbreitet ist.
Sobald das EVM durch RISC-V oder eine andere einfache Sprache ersetzt wurde, schlägt Buterin vor, aus dem Hexary Merkle Patricia-Baum auf einen binären Baum zu wechseln, sowohl für den Konsens- als auch für die Ausführungsschichten. Dieser Übergang könnte die Effizienz verbessern und die Kosten senken und gleichzeitig sicherstellen, dass auf alle Ethereum -Schichten mit demselben Code zugegriffen und interpretiert werden können, schrieb Buterin.
Eine Änderung des Ethos
Buterin schloss mit dem Schluss, dass Ethereum nach dem Beispiel von Tinygrad eine explizite maximale Codezielziele angewendet hat. Das Ziel, Buterin, wiederholte, ist es, „den Konsens-Kritischen Code von Ethereum nahe wie Bitcoin“ zu machen.
Noch wichtiger ist jedoch, dass Ethereum ein Ethos übernehmen muss, bei dem die einfachere Option nach Möglichkeit ausgewählt wird. Dies würde bedeuten, die eingekapselte Komplexität gegenüber der systemischen Komplexität zu bevorzugen.
Buterin versicherte, dass der Code, der sich mit der Verarbeitung von Ethereums historischen Regeln befasst, mit seinem neuesten Vorschlag weiterhin existieren wird. Ein solcher Code sollte jedoch außerhalb des Konsens-Kritischen Code oder dem grünen Bereich gehalten werden.
