Weiterleitung des Originaltitels "Reflexionen über die Ethereum-Governance nach der 3074-Saga"

Zusammenfassung: Der Artikel ist eine Aussage von Derek Chiang, dem CEO von ZeroDev, als Antwort auf Vs Vorschlag von EIP-7702, die Widersprüche zwischen ERC-4337 und EIP-3074 auszugleichen. Geschrieben aus der Perspektive eines Projektgründers innerhalb des AA-Ökosystems, beleuchtet es objektiv das aktuelle Governance-Modell von Ethereum und seine Schwachstellen. Derek weist kurz und bündig darauf hin:

Einer der Governance-Konflikte von Ethereum liegt in den Diskrepanzen zwischen der von Forschern festgelegten Roadmap und den Perspektiven von Kundenentwicklungsteams wie Geth. Vitalik, der in einer CTO-ähnlichen Rolle agiert, wird schließlich zum entscheidenden Faktor.

Nachdem er Vitaliks Rolle bekräftigt hat, skizziert Derek die Verbesserungen, die Ethereum an seinem Governance-Modell vornehmen sollte, und bietet wertvolle Erkenntnisse sowohl für die Ethereum- als auch für die Bitcoin-Community.

Text:

Wenn Sie mit den Ereignissen rund um die Kontoabstraktion (AA) von Ethereum noch nicht vertraut waren, hier eine kurze Zusammenfassung: Vor einigen Wochen wurde der EIP-3074-Vorschlag von den Kernentwicklern von Ethereum genehmigt, um in die nächste Hard Fork "Pectra" aufgenommen zu werden. Dieser Vorschlag führt zwei neue Opcodes für die Ethereum Virtual Machine (EVM) ein, die es Ethereum External Owned Accounts (EOAs) ermöglichen, ein nahezu natives AA-Erlebnis zu haben. Seitdem haben sich viele Mitglieder der ERC-4337-Community, insbesondere ihre Befürworter, stark gegen EIP-3074 ausgesprochen und Bedenken hinsichtlich potenzieller Sicherheitsrisiken und seiner Inkompatibilität mit der AA-Roadmap von Ethereum angeführt. In der vorherigen Roadmap von Ethereum standen ERC-4337 und ähnliche Vorschläge wie 7560 (auch bekannt als "nativeAA") im Mittelpunkt. Anfang Mai schlug Vitalik EIP-7702 als Alternative zu EIP-3074 vor und fand ein Gleichgewicht zwischen 4337 und 3074 – es bietet ein AA-Erlebnis für EOA-Benutzer und behält gleichzeitig die Kompatibilität mit ERC-4337 bis zu einem gewissen Grad sowie die Kompatibilität mit der "endgültigen AA-Lösung" 7560 bei. Derzeit erwägen die Kernentwickler von Ethereum die Auswirkungen von EIP-7702, und vorläufige Diskussionen und die Stimmung in der Community deuten darauf hin, dass EIP-7702 wahrscheinlich das bereits erwähnte EIP-3074 ersetzen wird. Ich bin mit diesem Ergebnis sehr zufrieden: EOA-Benutzer werden bald in der Lage sein, verschiedene Produkte innerhalb des ERC-4337-Ökosystems zu erleben und die meisten Vorteile von AA zu genießen. Ich kann mich jedoch des Eindrucks nicht erwehren, dass es einen besseren Weg hätte geben können, um diese Ergebnisse zu erzielen, wie viele in den letzten Wochen hervorgehoben haben. Ich glaube, dass wir mit einem besseren Governance-Prozess viel Energie hätten sparen und schneller zum gewünschten Ergebnis kommen können. In diesem Artikel möchte ich:

• Identifizieren Sie, was im Governance-Prozess schief gelaufen ist
• Schlagen Sie ein Denkmodell für die Ethereum-Governance vor
• Bieten Sie Verbesserungsvorschläge an, um ähnliche Governance-Unfälle in Zukunft zu vermeiden

Schlussfolgerung und Reflexion zum EIP-3074-Vorfall

Die oben erwähnte Geschichte hat viele Menschen aus mehreren Gründen unglücklich gemacht: EIP-3074 brauchte mehrere Jahre, um zugelassen zu werden. Nachdem 3074 schließlich genehmigt wurde, sahen sich die Kernentwickler von Ethereum mit starkem Widerstand der 4337-Community konfrontiert. Auf der anderen Seite äußerten die Autoren von ERC-4337 wiederholt ihre Bedenken bezüglich EIP-3074 gegenüber dem Ethereum-Kernteam, jedoch ohne Erfolg. Nun plant Ethereum, die Zulassung von 3074 aufzuheben und durch eine andere EIP (7702) zu ersetzen. Es ist an sich nichts falsch an irgendeinem Punkt des oben genannten Prozesses:

• Es ist normal, dass Diskussionen über eine EIP mehrere Jahre dauern.
• Es ist normal, dass eine genehmigte EIP danach abgelehnt wird.
• Wenn neue Probleme entdeckt werden, kann die Genehmigung einer EIP nach der Genehmigung widerrufen werden.

Es hätte jedoch reibungsloser laufen können. Stellen wir uns vor, die Dinge hätten sich so entwickelt: Während der Diskussion über 3074 hat sich die 4337-Community aktiv mit den Kernentwicklern von Ethereum auseinandergesetzt. Wenn diese Prämisse zutrifft, dann gibt es nur zwei mögliche Ergebnisse:

• Nach Berücksichtigung des Feedbacks der 4337-Community wird der 3074-Vorschlag genehmigt (und möglicherweise geändert). In diesem Fall würde die 4337-Community 3074 akzeptieren, und das Kernteam von Ethereum müsste 3074 nicht widerrufen.
• Alternativ wird 3074 nie genehmigt, aber die 4337-Community und das Kernteam von Ethereum schlagen gemeinsam eine Lösung vor, die alle zufriedenstellt, ähnlich wie 7702. Alle Stimmen werden gehört, und es gibt keine dramatische Umkehrung. Das wäre ideal gewesen – warum ist es also nicht passiert?

Was ist schief gelaufen?

Wenn man auf den gesamten Prozess zurückblickt, geben sich beide Seiten gegenseitig die Schuld. Die Ethereum-Kernentwickler (sowie die Autoren von EIP-3074) glauben, dass es die Schuld der "4337-Unterstützer" ist, weil sie nicht aktiv am Diskussionsprozess der All Core Developers (ACD) teilgenommen haben. In diesem Prozess müssen EIPs langwierige Überlegungen durchlaufen und schließlich von Ethereum-Client-Entwicklungsteams wie Geth akzeptiert und implementiert werden. Einige argumentieren, dass während des Zeitraums, in dem EIP-3074 in Betracht gezogen wurde, "4337-Unterstützer" hätten teilnehmen und ihre Ansichten äußern können, anstatt es zu kritisieren, nachdem es bereits genehmigt worden war. Schließlich ist der gesamte ACD-Prozess transparent, die Sitzungen sind für alle offen und Personen wie Tim Beiko veröffentlichen nach jedem ACD-Treffen regelmäßig zusammenfassende Tweets. Wenn sich also "4337-Unterstützer" so sehr für das Thema interessierten, warum haben sie dann nicht aktiv und zeitnah an den entsprechenden Treffen teilgenommen?

Auf der anderen Seite geben die Kernmitglieder von 4337 an, dass sie an ACD-Sitzungen teilgenommen und sich so weit wie möglich gegen 3074 ausgesprochen haben, aber die Ethereum-Kernentwickler hören nicht zu. Was die 4337-Gemeindemitglieder betrifft, so fühlten sich viele überrumpelt – viele dachten, 3074 sei bereits tot, und einige wussten nicht einmal, dass 3074 wahrscheinlich genehmigt werden würde. Viele weisen darauf hin, dass der gesamte Prozess der ACD-Meetings undurchsichtig und nicht freundlich zu denjenigen ist, die in der Ethereum-Community "seriös" sind, aber nicht in Echtzeit mit ACD-Updates Schritt halten können. Einige sind auch der Meinung, dass ACD aktiv Feedback von Interessengruppen einholen sollte (hier bezogen auf die 4337-Community).

Ich glaube jedoch, dass keine der beiden Seiten den Nagel auf den Kopf getroffen hat. Dahinter stecken tiefere Probleme, und wenn wir dieses Problem nicht angehen oder zumindest anerkennen, werden wir weiterhin in Governance-Unfälle verfallen, gefolgt von widersprüchlichen Anschuldigungen von beiden Seiten, die letztlich bedeutungslos sind.

Die Ursache von Governance-Unfällen: die Roadmap

Entgegen der landläufigen Meinung liegt die Hauptursache für Governance-Unfälle in der Tatsache, dass ACD nicht die einzige Governance-Behörde für Ethereum-Protokoll-Updates ist; sie wurde durch eine andere Governance-Behörde ersetzt. Das Problem dabei ist, dass diese andere Governance-Autorität, obwohl sie mehr Einfluss als ACD auf Ethereum-Kernfragen (wie AA und Skalierbarkeit) hat, selten anerkannt wird. In diesem Artikel werde ich diese Art von Macht als "Roadmap" bezeichnen. Wie ich weiter unten erläutern werde, ist das gesamte Governance-Ausfallereignis "3074-4337-7702" ein Fall, in dem die bestehende Roadmap-Macht von Ethereum die ACD-Macht außer Kraft setzt. Wenn wir über Governance sprechen, wenn wir feststellen, dass eine immaterielle Kraft eine greifbare überwältigt, sollten wir äußerst besorgt sein, denn immaterielle Dinge sind oft schwer zu erklären und können von vielen Menschen nicht leicht wahrgenommen werden, also müssen sie aufgedeckt werden.

Was ist eine Roadmap?

Jeder in der Ethereum-Community muss den Begriff "Roadmap" schon oft gehört haben, sei es in der "ETH2.0-Roadmap" oder im Zusammenhang mit der "AA-Roadmap" im Zusammenhang mit diesem Ereignis.

Um meinen Standpunkt zu veranschaulichen, stellen wir uns eine Szene bei einem ACD-Treffen vor, in der Kernentwickler darüber diskutieren, wie Ethereum skaliert werden kann:

• Kernentwickler Bob: Ich unterstütze EIP-1234, das vorschlägt, die Blockgeschwindigkeit um das 10-fache zu erhöhen, die Blockgröße um das 10-fache zu erhöhen und die Gebühren um das 100-fache zu senken.
• Andere Core-Entwickler: ... Bist du verrückt?

Denken wir darüber nach. Warum sollte das Ethereum-Kernteam den Vorschlag von Bob ablehnen? Er schlägt nur einen scheinbar vernünftigen Weg zur Skalierung vor, etwas, das viele öffentliche Ketten wie Solana, Aptos, Sui und andere getan haben, um einen hohen TPS zu erreichen. Der Grund dafür ist, dass diese fiktive EIP-1234 der "Rollup-zentrierten" Skalierungs-Roadmap von Ethereum widerspricht. Diese Roadmap betont, dass normale Benutzer für die Dezentralisierung in der Lage sein müssen, Knoten zu geringen Kosten zu betreiben. Daher ist es unwahrscheinlich, dass der fiktive EIP-1234 akzeptiert wird, da er die Kosten für den Betrieb von Ethereum-Knoten erheblich erhöhen würde. Ich möchte dieses Beispiel verwenden, um zu veranschaulichen, dass Kernentwickler, die am ACD-Governance-Prozess teilnehmen und über Protokollaktualisierungen entscheiden, von einer übergeordneten Kraft geleitet werden, die ich als "Roadmap" bezeichne. Derzeit gibt es rund um die Ethereum-Roadmap "Skalierungs-Roadmaps", "AA-Roadmaps", "MEV-Roadmaps" und so weiter. Sie bilden zusammen die Gesamt-Roadmap von Ethereum, und die Kernentwickler müssen Entscheidungen auf dieser Grundlage treffen.

Wenn die Ansichten der Kernentwickler nicht mit der Roadmap übereinstimmen

Da die Roadmap kein formaler Teil des Ethereum-Governance-Prozesses ist, gibt es oft keine Garantie dafür, dass sich das Kernteam daran hält. Darüber hinaus gibt es keinen formellen Prozess zur "Genehmigung" der Roadmap, so dass nicht alle Roadmaps das gleiche Maß an "Orthodoxie" haben. Die Forscher hinter der Ethereum-Roadmap müssen hart daran arbeiten, ihre Roadmap bei den Kernentwicklern und der Community zu bewerben, um "Orthodoxie" und Unterstützung vom Ethereum-Kernentwicklungsteam zu erhalten. In Bezug auf AA und Account-Abstraktion hat sich Vitalik selbst wiederholt für die 4337-zentrierte AA-Roadmap ausgesprochen, aber insgesamt ist es hauptsächlich das Team hinter 4337, insbesondere Yoav und Dror, die sich in Foren und in ACD-Meetings für die 4337-zentrierte AA-Roadmap einsetzen.

Trotz dieser Bemühungen lehnen einige Ethereum-Kernentwickler die 4337-zentrierte AA-Roadmap jedoch immer noch stark ab. Sie glauben, dass 7560 (die native Version 4337, die in Zukunft von Ethereum-Clients implementiert werden soll) zu komplex und nicht die einzige praktikable Lösung für das "AA-Endspiel" ist. Letztendlich entschied sich die ACD, den 3074-Vorschlag zu genehmigen, trotz des Widerstands des 4337-Teams, das der Meinung war, dass 3074 das gesamte AA-Ökosystem zerbrechen würde. Nachdem 3074 genehmigt wurde, reagierte die gesamte 4337-Community heftig und zwang die Ethereum-Kernentwickler, sich erneut an Diskussionen über 3074 zu beteiligen. Die Diskussion geriet dann in eine Pattsituation, da die Autoren von 4337 und 3074 sich nicht gegenseitig überzeugen konnten. Vitalik schlug EIP-7702 in letzter Minute als Alternative zu 3074 vor, die explizit das 4337-zentrierte "AA-Endspiel" berücksichtigt, wodurch der Konflikt gelöst und das Endergebnis mit der AA-Roadmap in Einklang gebracht wird.

Die Rolle von Vitalik: Der De-facto-CTO von Ethereum

Obwohl Vitalik sich selbst als Forscher bezeichnet, zeigt die obige Geschichte deutlich, dass Vitalik andere Governance-Befugnisse als andere Forscher innehat. Es stellt sich also die Frage: Welche Rolle spielt Vitalik in der Ethereum-Governance? Persönlich glaube ich, dass es nicht unangemessen ist, Vitalik als De-facto-CTO eines sehr großen Unternehmens zu betrachten (übrigens unter der Annahme, dass Ethereum ein "Unternehmen" ohne CEO ist, um sich an der Realität auszurichten). Wenn Sie jemals in einem Technologieunternehmen mit über 50 Mitarbeitern gearbeitet haben, wissen Sie, dass der CTO nicht an jeder technischen Entscheidung beteiligt sein kann. Wenn das Unternehmen wächst, werden die Entscheidungsprozesse für verschiedene technische Lösungen unweigerlich dezentralisiert – in der Regel hat jeder Bereich des Produkts/Geschäfts des Unternehmens ein eigenes Team, das oft die Autonomie hat, über Lösungsdetails zu entscheiden. Darüber hinaus ist der CTO möglicherweise nicht der Top-Experte in allen (oder irgendeinen) Themen. Es kann Ingenieure im Unternehmen geben, die in bestimmten Bereichen besser sind als der CTO, so dass bei Diskussionen über technische Details von Lösungen oft einzelne Ingenieure die endgültigen Entscheidungen treffen. Der CTO legt jedoch die technische Vision des Unternehmens fest. Die Umsetzung der Vision bleibt den Entwicklern überlassen. Dies ist zwar keine perfekte Analogie, aber ich glaube, dass sie die Rolle von Vitalik im Ethereum-Ökosystem sinnvoll zusammenfasst. Vitalik ist nicht an jeder technischen Entscheidung beteiligt – er könnte es vielleicht auch nicht. Er ist auch nicht in jedem Bereich der Top-Experte. Aber er hat einen überwältigenden Einfluss auf die Festlegung der Roadmap für alle wichtigen Ethereum-Lösungen (Skalierung, AA, POS...), nicht nur wegen seines technischen Fachwissens, sondern auch, weil er der ultimative Richter darüber ist, ob die Roadmap mit der Ethereum-Vision (seiner Vision) übereinstimmt.

Jedes erfolgreiche Produkt beginnt mit einer Vision

Wenn es nicht kontrovers genug ist, Vitalik als CTO von Ethereum zu betrachten, ist hier der umstrittenste Teil: Wir sollten Vitalik als CTO begrüßen. Als Gründer eines Startups glaube ich, dass jedes erfolgreiche Produkt eine kohärente langfristige Vision haben muss – ja, Ethereum ist auch ein "Produkt", weil es echte Probleme für echte Nutzer löst. Eine kohärente Vision muss von wenigen Personen ausgearbeitet werden, z. B. von den Gründern eines Startups, und normalerweise gibt es nur einen Gründer. Das Schöne an Ethereum ist, dass, obwohl es sich um ein extrem komplexes System mit so vielen Komponenten handelt, all diese Komponenten nahtlos zu einem gut funktionierenden dezentralen Computer zusammenkommen, der jeden Tag Transaktionen im Wert von Milliarden von Dollar abwickelt. Wir sind nicht durch die Designschemata eines Komitees so weit gekommen, sondern weil Vitalik mit seiner Weitsicht und Einsicht aktiv eine Führungsrolle übernommen hat, die es uns ermöglicht hat, das heutige kohärente und anmutige Ethereum aufzubauen. Ethereum ist die Idee, die Vitalik 2015 vorgeschlagen hat, und das ist auch heute noch so. Natürlich soll dies nicht die Beiträge anderer Forscher und Ingenieure schmälern, denn sie haben den Großteil der heutigen Errungenschaften von Ethereum erzielt. Dies ist jedoch kein Widerspruch, denn Ethereum ist die Verwirklichung von Vitaliks Vision, die größer ist als die Vision aller anderen. Ehrlich, können Sie sich darüber beschweren? Wenn Sie sich von der Offenheit, Zensurresistenz und Innovationsgeschwindigkeit des Ethereum-Ökosystems angezogen fühlen, haben Sie sich jemals darüber beschwert, dass dies auf Vitaliks Vision zurückzuführen ist? Vielleicht haben Sie sich nicht beschwert, weil Sie nicht so darüber nachgedacht haben – aber jetzt, wo Sie es sind, stört Sie dieses Thema?

Wie geht man mit der Dezentralisierung um?

Aber Sie fragen sich vielleicht, was ist mit der Dezentralisierung? Wenn eine Person eine so überwältigende Macht über Ethereum hat, wie können wir dann sagen, dass es dezentralisiert ist? Um diese Frage zu beantworten, müssen wir uns Vitaliks klassischen Artikel über die Bedeutung der Dezentralisierung noch einmal ansehen. Die wichtigsten Erkenntnisse des Artikels sind, dass es drei Arten von Dezentralisierung gibt:

• Architektonische Dezentralisierung: Wie viele Knoten können ausfallen, bevor das System nicht mehr läuft?
• Logische Dezentralisierung: Können sich die verschiedenen Teilsysteme des Systems unabhängig voneinander entwickeln und dennoch zusammenhängend zusammenarbeiten?
• Politische Dezentralisierung: Wie viele Einzelpersonen oder Organisationen kontrollieren letztendlich das System?

Nach diesen Definitionen ist Ethereum architektonisch eindeutig dezentralisiert, und man könnte argumentieren, dass es logisch dezentralisiert ist, weil seinen Komponenten eine starke Kopplung fehlt (z. B. zwischen der Konsensschicht und der Ausführungsschicht). Was die politische Dezentralisierung betrifft, so ist die gute Nachricht, dass keine Person oder Organisation Ethereum abschalten kann, nicht einmal Vitalik. Einige könnten jedoch argumentieren, dass der Grad der politischen Dezentralisierung von Ethereum nicht so hoch ist wie angenommen, da Vitalik eine wichtige Rolle bei der Gestaltung der Vision und Roadmap von Ethereum spielt.

Ich glaube jedoch, dass wir, wenn wir wollen, dass Ethereum weiterhin innovativ ist, Vitalik als De-facto-CTO akzeptieren müssen, auch wenn dies bedeutet, dass wir einen Teil der politischen Dezentralisierung opfern müssen. Wenn Ethereum so "stagnieren" würde wie Bitcoin, eine nahezu unveränderliche Blockchain, dann könnte Vitalik genauso gut in den Ruhestand gehen. Aber bevor wir diesen letzten Schritt erreichen, ist es entscheidend, eine Autorität zu haben, die von allen Parteien respektiert wird, jemanden, der vertrauenswürdig ist, um technische Entscheidungen zu treffen, die nicht nur auf der Überlegenheit der vorgeschlagenen technischen Lösungen basieren, sondern auch darauf, ob diese Entscheidungen mit der Vision von Ethereum übereinstimmen.

Ohne jemanden wie Vitalik sind nur zwei Ergebnisse wahrscheinlich, was durch die Geschichte um EIP-3074 anschaulich veranschaulicht wird:

Der Ethereum-Governance-Prozess könnte in eine endlose Sackgasse geraten, in der Konfliktparteien nicht zu Kompromissen bereit sind und niemand Fortschritte macht, wie die Sackgasse in der 3074-Debatte zeigte, bevor Vitalik intervenierte.

Oder Ethereum könnte zu einem designinkohärenten "Frankenstein" werden, bei dem 3074 und 4337 möglicherweise nicht nachgeben, was letztendlich zum vollständigen Bruch des AA-Ökosystems in zwei inkompatible parallele Räume führt.

Die Rolle der Gemeinschaft

Nach den obigen Überlegungen skizzieren wir fast eine vollständige Ethereum-Governance-Mentalität, aber es gibt eine offensichtliche Auslassung in unserer bisherigen Diskussion – die Community. Wenn Vitalik die Vision von Ethereum definiert, Forscher die Roadmap definieren und Kernentwickler die Roadmap umsetzen, welche Rolle spielt dann die Community? Sicherlich ist es nicht nur untätig, oder? Glücklicherweise spielt die Gemeinschaft die wichtigste Rolle. Der Grund dafür ist, dass es Werte gibt, bevor es eine Vision gibt. Wir kommen als Gemeinschaft zusammen, weil wir uns um bestimmte Werte versammeln, und Vitaliks Vision muss letztendlich mit diesen Werten übereinstimmen, um die Unterstützung der Gemeinschaft zu erhalten. Jeder in der Ethereum-Community glaubt, dass ein dezentraler Computer, der für alle zugänglich ist, unzensiert und vertrauensneutral ist, für die Welt von Vorteil ist. Wir halten diese Werte jeden Tag durch die Arbeit an Ethereum aufrecht und bekräftigen sie und legitimieren damit die Vision, die Roadmap und den Code, die von Vitalik, Forschern und Kernentwicklern festgelegt wurden.

Das VVRC-Modell der Ethereum-Governance

Daher hier die vollständige Denkweise der Ethereum-Governance, abgekürzt als VVRC:

• V==Werte==Gemeinschaft;
• V==Vision==Vitalik;
• R==Roadmap==Forscher;
• C==Client==Kernentwickler;

Zusammen spielen sie folgende Rollen:

• Die Gemeinschaft versammelt sich um bestimmte Werte.
• Vitalik artikuliert eine Vision, die mit diesen Werten übereinstimmt.
• Die Forscher formulieren eine Roadmap auf der Grundlage der Vision.
• Kernentwickler implementieren Clients basierend auf der Roadmap.

Natürlich ist die Realität weitaus komplexer, als jedes einfache Modell erfassen kann. Die Ethereum-Kernentwickler sind die einzigen, die wirklich über jeden Vorschlag "abstimmen" können, indem sie den Client-Code ändern. Vitalik und andere Forscher fungieren als Berater, und manchmal werden ihre Meinungen von den Kernentwicklern nicht akzeptiert, was genau der Grund ist, warum EIP-3074 zugelassen wurde. Nichtsdestotrotz glaube ich, dass das VVRC-Modell den Betriebsmodus der Ethereum-Governance unter normalen Umständen vernünftig erfasst, und wir müssen diesen Prozess "debuggen", um zu verhindern, dass sich Unfälle wie EIP-3074 wiederholen.

Wie man das Governance-Modell von Ethereum verbessert

Nachdem wir nun ein mentales Modell dafür haben, wie der Ethereum-Governance-Prozess funktioniert, sind hier einige Ideen zur Verbesserung der Governance-Prozesse:

Die Sichtbarkeit des Diskussionsfortschritts für die zu überprüfenden EIP muss erhöht werden. Die gesamte Gemeinschaft sollte nicht von der Annahme einer EIP "überrascht" werden, und unerwartete Zulassungen wie EIP-3074 sollten sich nicht wiederholen. Der aktuelle "Status" der EIPs auf der EIP-Website spiegelt nicht ihren Status im ACD-Prozess wider. Aus diesem Grund heißt es immer noch, dass EIP-3074 "in Prüfung" ist, obwohl die Kernentwickler für die Zulassung gestimmt haben, ohne dass es einen Hinweis darauf gibt, dass es jemals von Anfang an für eine Zulassung in Betracht gezogen wurde. Im Idealfall sollte die Ethereum Foundation, wenn eine EIP kurz vor der Annahme steht, eine endgültige öffentliche Ankündigung in den sozialen Medien machen, um das Bewusstsein innerhalb der Community zu schärfen.

Manchmal unterschätzen Kernentwickler die Auswirkungen bestimmter EIPs auf nachgelagerte Projekte und Nutzer, wie es bei den Communities 3074 und 4337 der Fall war. Aufgrund der begrenzten Zeit der ACD-Sitzungen und der Notwendigkeit der Koordination über Zeitzonen hinweg können bei den Sitzungen oft nur "relevantes Personal" sprechen. Dennoch wäre es sinnvoll, den Gemeindemitgliedern gelegentlich etwas Redezeit einzuräumen, um die Auswirkungen bestimmter EIP-Vorschläge auf nachgelagerte Projekte nach ihrer Genehmigung zu kommentieren. Wenn Forscher das Gefühl haben, dass ihre Meinungen von den Kernentwicklern nicht akzeptiert wurden, wie es bei 4337 der Fall war, können sie Community-Mitglieder einladen, ihre Argumente zu untermauern.

Es ist wichtig, dass Kernentwickler und Forscher gegenseitig anerkennen, dass sie trotz der Machtunterschiede beide Teil der Governance-Autorität von Ethereum sind. Core-Entwickler haben die Macht, Ethereum-Clients zu ändern und zu aktualisieren, was die einzige Möglichkeit ist, Änderungen am Protokoll selbst vorzunehmen und "abzustimmen". Forscher haben in der Regel mehr öffentliche Unterstützung für Änderungen und Interpretationen der Roadmap, dank ihrer aktiven Diskussion und des Schreibens ihrer Ideen.

Wenn diese beiden Kräfte aufeinanderprallen, können Kernentwickler dazu neigen, die Meinungen der Forscher direkt umzukehren, wie es beim 4337-Team der Fall war. Ein solches Umkippen kann jedoch zu Konflikten führen, da Instabilität entsteht, wenn die beiden Kräfte aufeinanderprallen, wie die dramatischen Ereignisse nach der Zulassung von EIP-3074 zeigen.

Ebenso können Forscher bei Widerstand dazu neigen, die Zusammenarbeit mit Kernentwicklern aufzugeben. Meiner Meinung nach ist dies auch einer der Gründe für die Schaffung des RIP-Prozesses und warum das native AA (7560) jetzt in erster Linie als RIP und nicht als EIP beworben wird.

Das Experimentieren mit Protokollaktualisierungen auf L2, die für L1 umstritten sind, hat zwar seine Vorteile, aber wir können RIP nicht als Ersatz für die Teilnahme am EIP-Governance-Prozess betrachten. Die Forscher müssen weiterhin mit den Kernentwicklern zusammenarbeiten, bis die Werte beider Seiten vollständig mit der Roadmap übereinstimmen.

Schlussfolgerung

Der Vorfall 3074/7702 enthüllte die wahre Funktionsweise der Ethereum-Governance – abgesehen von der expliziten Governance-Macht, die von EIP/ACD-Prozessen der Kernentwickler angetrieben wird, gibt es auch implizite Governance-Macht, die durch die von Forschern vorangetriebene Roadmap angetrieben wird. Wenn diese Kräfte nicht aufeinander abgestimmt sind, sehen wir Sackgasse und Schubs, und eine andere Kraft – Vitalik – muss möglicherweise in irgendeiner Weise eingreifen, um das Gleichgewicht zu stören.

Als nächstes schlagen wir vor, dass Vitalik eine einzigartige Kraft darstellt, nämlich die "Vision" von Ethereum, die die Grundlage für die Legitimität jeder Roadmap bildet. Wir vergleichen Vitalik mit einem CTO eines großen Unternehmens und erkennen an, dass seine Rolle als Pseudo-CTO notwendig ist, damit Ethereum sein Innovationstempo aufrechterhalten und verhindern kann, dass Ethereum zu einem "Frankenstein" wird – wie ein zusammengeflicktes Monster.

Schließlich stellen wir das VVRC-Modell vor und beschreiben das Ethereum-Governance-Modell: Werte (Community) ⇒ Vision (Vitalik) ⇒ Roadmap (Forscher) ⇒ Client (Core-Entwickler). Dann schlagen wir verschiedene Methoden vor, um die "Fehler" dieses Modells zu "debuggen".

Die Ethereum-Governance ist eine "maschinelle Maschine" – damit Ethereum korrekt läuft, müssen wir es richtig steuern.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [极客 Web3]. Weiterleiten des Originaltitels "Reflections on Ethereum Governance Following the 3074 Saga". Alle Urheberrechte liegen beim ursprünglichen Autor [Derek Chiang, CEO von ZeroDev]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Gate Learn-Team , das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.