Vitalik und Yoav haben diesen Beitrag freundlicherweise überprüft, aber Meinungen sind meine eigenen.

Wenn Sie das AA-Drama nicht verfolgt haben, hier eine kurze Zusammenfassung:

• Vor einigen Wochen wurde EIP-3074, ein Vorschlag, der viele der Vorteile von AA für EOA-Benutzer bringen würde, von den Kernentwicklern genehmigt, um in "Pectra", Ethereums nächste harte Aufspaltung, zu gehen.
• Seitdem haben sich viele in der ERC-4337-Community, insbesondere die 4337-Autoren selbst, stark gegen 3074 gewehrt, und zwar auf der Grundlage von @yoav/3074-implications">Zentralisierungsbedenken und seiner Inkompatibilität mit Ethereum s @yoav/AA-roadmap-May-2024">AA-Roadmap, die sich um 4337 und seinen Cousin 7560 (auch bekannt als "native AA") dreht.
• Letzte Woche schlug Vitalik EIP-7702 als Alternative zu 3074 vor. Es erreicht größtenteils das gleiche Ziel – viele Vorteile von AA für EOA-Benutzer zu bringen – aber auf eine Weise, die mit dem heutigen 4337 und dem "AA-Endspiel" 7560 kompatibel ist.
• Zu diesem Zeitpunkt beraten die Kernentwickler über EIP-7702, aber vorläufige Diskussionen und die Stimmung der Community deuten darauf hin, dass EIP-7702 höchstwahrscheinlich EIP-3074 in Pectra ersetzen wird.

Ich persönlich war mit dem Ergebnis sehr zufrieden: EOA-Benutzer werden bald in der Lage sein, die meisten Vorteile von AA zu genießen, indem sie die für ERC-4337 entwickelten Tools und Infrastrukturen verwenden.

Und doch kann ich mich des Eindrucks nicht erwehren, dass die Art und Weise, wie wir dieses Ergebnis erreicht haben, alles andere als optimal war, eine Ansicht, die viele in den letzten Wochen geäußert haben. Ich bin der Meinung, dass wir mit einem besseren Prozess gemeinsam eine enorme Menge an Energie und Kopfschmerzen hätten einsparen und viel früher zum gewünschten Ergebnis hätten kommen können.

In diesem Blogbeitrag möchte ich:

• Ermitteln Sie, was bei dem Prozess schief gelaufen ist.
• Schlagen Sie ein mentales Modell für das Nachdenken über die Governance von Ethereum vor.
• Schlagen Sie Verbesserungen vor, um ähnliche Governancefehler in Zukunft zu vermeiden.

Warum der Prozess die Menschen unglücklich gemacht

hat Diese ganze Saga hat viele Menschen aus mehreren Gründen unglücklich gemacht:

• Es dauerte Jahre, bis 3074 genehmigt wurde.
• Erst nachdem 3074 endlich genehmigt wurde, erhielten die Kernentwickler eine Menge Gegenwind von der 4337-Community.
  • Die 4337-Autoren selbst hatten dagegen wiederholt ihre Bedenken gegenüber den Kernentwicklern von 3074 geäußert, ohne Erfolg.
• Jetzt sind wir auf dem besten Weg, 3074 nicht mehr zu genehmigen und durch eine andere EIP (7702) zu ersetzen.

Nun, es gibt an sich nichts Falsches an einem der oben genannten:

• Es ist in Ordnung, wenn eine Diskussion Jahre dauert.
• Es ist in Ordnung, dass eine EIP Pushbacks erhält, nachdem sie genehmigt wurde.
• Es ist in Ordnung, die Genehmigung einer EIP aufzuheben, nachdem sie genehmigt wurde, wenn neue Probleme identifiziert werden.

Wir können uns jedoch wahrscheinlich darauf einigen, dass die Dinge reibungsloser hätten laufen können. Stellen Sie sich vor, es wäre so gelaufen:

• Die 4337-Community hat die Kernentwickler aktiv einbezogen, als sie über 3074 debattierten. Jetzt ist nur noch eines von zwei Ergebnissen möglich:
  • Entweder wurde 3074 genehmigt (und möglicherweise geändert), nachdem wir das Feedback der 4337-Community in Konto aufgenommen hatten, in diesem Fall wäre die 4337-Community mit 3074 an Bord gewesen und wir hätten 3074 nicht rückgängig gemacht.
  • Oder 3074 wurde nie genehmigt, aber die 4337-Community und die Kernentwickler arbeiteten gemeinsam an einem Vorschlag, mit dem alle zufrieden sind, à la 7702.

Die Stimme jedes Einzelnen wird gehört, und es gibt keine dramatischen Umkehrungen. Das wäre schön gewesen – warum ist es dann nicht passiert?

Was ist schief gelaufen?

Im Rückblick auf den Prozess haben beide Seiten der Debatte mit dem Finger aufeinander gezeigt.

Die Kernentwickler (und Autoren von EIP-3074) waren der Meinung, dass es die Schuld der "4337-Leute" war, dass sie sich nicht aktiv mit dem All Core Devs (ACD)-Prozess befasst haben, bei dem EIPs Long Zeit lang beraten werden, bevor sie schließlich von den Kundenteams akzeptiert und damit in die Protokoll implementiert werden.

Zu jedem Zeitpunkt dieser Beratung, so das Argument, hätten die "4337 Leute" hereinkommen und ihre Bedenken äußern können, anstatt zu warten, bis 3074 bereits genehmigt worden waren. Schließlich ist der ACD-Prozess gut dokumentiert, die Treffen sind offen für alle, und es gibt Leute wie Tim Beiko, die nach jedem ACD-Meeting aktiv Zusammenfassungen twittern. Wenn sich also die 4337 Menschen so sehr für dieses Thema interessierten, warum haben sie sich dann nicht die Zeit genommen, sich zu engagieren?

Auf der anderen Seite wies das AA-Team (4337 Autoren) darauf hin, dass sie an ACD-Meetings teilgenommen und 3074 bei jeder Gelegenheit zurückgedrängt hatten, aber die Kernentwickler hörten nicht zu. Was die 4337-Community betrifft, so fühlten sie sich größtenteils überrumpelt – die meisten Menschen hatten den Eindruck, dass 3074 tot war, und waren sich nicht einmal bewusst, dass 3074 aktiv für die Aufnahme in Betracht gezogen wurde.

Viele Leute waren auch der Meinung, dass der ACD-Prozess zu undurchsichtig und nicht freundlich für die Teilnahme von Menschen war, die "echte Jobs" haben und es sich nicht leisten konnten, mit all den ACD-Updates Schritt zu halten. Einige waren auch der Meinung, dass es in der Verantwortung der ACD liegen sollte, aktiv Feedback von relevanten Interessengruppen, in diesem Fall der 4337-Community, einzuholen.

Ich bin aber der Meinung, dass beide Seiten das Ziel verfehlt haben. Es ist ein viel tieferes Problem am Werk, und solange wir das Problem nicht beheben oder zumindest anerkennen, werden wir immer wieder auf Governance-Fehler stoßen, gefolgt von unproduktiven Schuldzuweisungen.

Die Grundursache

Die wahre Ursache für das Versagen der Governance war, dass die ACD entgegen der landläufigen Meinung NICHT die einzige Governance-Macht für Protokoll-Updates ist, und in diesem Fall wurde sie von einer anderen Governance-Macht außer Kraft gesetzt.

Problematisch ist, dass die andere Governance-Macht selten anerkannt wird, obwohl sie einen noch größeren Einfluss als ACD auf die wichtigsten Angelegenheiten von Ethereum wie AA und Skalierung hat.

In diesem Artikel werde ich diese Macht als "Roadmaps" bezeichnen.

Diese ganze 3074/7702-Saga ist, wie ich argumentieren werde, nicht mehr und nicht weniger als ein Beispiel dafür, wie die Macht der Roadmaps die Macht der ACD überwältigt. Und wenn wir über Regierungsführung sprechen, dann sollten wir jedes Mal, wenn wir bemerken, dass eine unsichtbare Macht eine sichtbare Macht überwältigt, sehr besorgt sein, denn was unsichtbar ist, ist nicht rechenschaftspflichtig und muss daher ans Licht gebracht werden.

Was ist eine Roadmap?

Jeder in der Ethereum-Community muss schon oft auf den Begriff "Roadmap" gestoßen sein, z. B. in der "Rollup-zentrierten Roadmap", "ETH 2.0 Roadmap" oder in dieser Debatte "@yoav/AA-roadmap-May-2024">die AA-Roadmap".

Eine Suche nach "Roadmap" auf Ethereum Magicians

Um meinen Standpunkt zu veranschaulichen, stellen wir uns ein ACD-Meeting vor, bei dem die Kernentwickler diskutieren, wie Ethereum skaliert werden kann:

• Core Dev Bob: Ich Unterstützung EIP 1234, der vorschlägt, dass wir beschleunigen Blockzeit 10-fache, die Blockgröße um das 10-fache erhöhen und Drop Gebühr 100X.
• Andere Kernentwickler: ... bist du von Sinnen?

Lassen Sie uns hier eine Sekunde nachdenken. Warum haben die Kernentwickler das, was Bob gesagt hat, einfach abgeschossen? Er schlug gerade eine sehr legitime Form der Skalierung vor. Solana und viele andere L1s tun es, mit großen Skalierungseffekten.

Der Grund dafür ist natürlich, dass diese imaginäre EIP gegen Ethereum eigene "Rollup-zentrierte" Skalierungs-Roadmap verstößt, die unter anderem besagt, dass es für die Blockchain-Dezentralisierung entscheidend ist, dass normale Benutzer in der Lage sind, einen Node zu betreibenDaher kommt die imaginäre EIP nicht in Frage, da sie die Hürde für den Betrieb eines Knotens erheblich erhöhen würde.

Was ich mit diesem Beispiel veranschaulichen wollte, ist, dass die Kernentwickler, die am ACD-Prozess teilnehmen und über Protokoll entscheiden, von einer höheren Kraft geleitet werden, die ich die Roadmaps nenne. Es gibt die Skalierungs-Roadmap, die AA-Roadmap, die MEV-Roadmap, was auch immer - und zusammen bilden sie die Ethereum-Roadmap, auf der die Kernentwickler ihre Entscheidungen basieren.

Wenn Kernentwickler nicht auf eine Roadmap abgestimmt sind

Da Roadmaps kein formaler Bestandteil der Governance sind, gibt es keine Garantie dafür, dass die Kernentwickler mit ihnen übereinstimmen. Insbesondere, da es keinen formalen Prozess für die "Genehmigung" einer Roadmap gibt, werden nicht alle Roadmaps als gleichwertig angesehen. Es liegt an den Forschern hinter den Roadmaps, ihre Roadmaps gewissenhaft für die Kernentwickler und die größere Community einzusetzen, um Legitimität und damit Order von den Kernentwicklern zu erhalten.

Im Fall von AA hat Vitalik selbst auf eine 4337-zentrierte AA-Roadmap gedrängt @vbuterin/Konto_abstraction_roadmap">multiple Gelegenheiten, aber insgesamt war es hauptsächlich das 4337-Team, insbesondere Yoav und Dror, die sich auf Konferenzen, Online-Foren und ACD-Treffen für die 4337-zentrierte AA-Roadmap einsetzten.

Trotz dieser Bemühungen gab es jedoch starken Widerstand von einigen Kernentwicklern gegen die 4337-zentrierte AA-Roadmap. Sie waren der Meinung, dass 7560, die native Version von 4337, die Kunden schließlich implementieren müssten, zu komplex und nicht der einzige brauchbare Kandidat für das "AA-Endspiel" ist. Schließlich entschied sich die ACD, 3074 zu genehmigen, trotz der Einwände des 4337-Teams, dass es das AA-Ökosystem fragmentieren würde, indem es einen alternativen und @yoav/3074-implications">weniger dezentralen AA-Tech-Stack schaffen würde.

Nachdem 3074 genehmigt wurde, gab es jedoch eine heftige Reaktion der gesamten 4337-Community, die die Kernentwickler dazu zwang, sich erneut an der 3074-Debatte zu beteiligen. Die Debatte wurde dann zu einer Pattsituation, in der sich weder die 4337-Autoren noch die 3074-Autoren gegenseitig überzeugen konnten, bis Vitalik in der elften Stunde kam und EIP-7702 als Alternative zu 3074 vorschlug, die explizit mit dem 4337-zentrierten "AA-Endspiel" kompatibel ist, und damit den Konflikt zugunsten der AA-Roadmap forcierte.

Die Rolle von Vitalik

Auch wenn Vitalik sich selbst als Forscher trägt, zeigt diese Saga deutlich, dass Vitalik eine qualitativ andere Governance-Macht mitbringt als andere Forscher. Es stellt sich also die Frage: Welche Rolle spielt Vitalik in der Governance von Ethereum?

Ich persönlich finde es hilfreich, mir Vitalik als CTO eines sehr, sehr großen Unternehmens vorzustellen.

(Für die Zwecke dieser Analogie gibt es übrigens keinen CEO in diesem Unternehmen.)

Wenn Sie in einem Technologieunternehmen mit mehr als, sagen wir, 50 Mitarbeitern gearbeitet haben, wissen Sie, dass der CTO unmöglich in jede technische Entscheidung einbezogen werden kann. Ab einem bestimmten Maßstab werden technische Entscheidungen notwendigerweise dezentralisiert – es gibt in der Regel ein Unterteam für jeden Bereich des Produkts des Unternehmens, und das Unterteam ist weitgehend frei, seine eigenen Entscheidungen über bestimmte Implementierungsdetails zu treffen.

Darüber hinaus ist der CTO auch nicht unbedingt der führende Experte in jedem (oder jedem) Thema. Es könnte sehr gut Ingenieure in einem Unternehmen geben, die in bestimmten Bereichen besser sind als der CTO. In technischen Debatten sind es daher häufig die Ingenieure, die die letztendlichen Entscheidungen treffen.

Der CTO legt jedoch die technische Vision des Unternehmens fest. Die Umsetzung der Vision bleibt den Entwicklern überlassen.

Das ist zwar keine perfekte Analogie, aber ich denke, sie fasst Vitaliks Rolle im Ökosystem gut zusammen. Vitalik ist nicht an jeder technischen Entscheidung beteiligt – das kann er auch gar nicht. Er ist auch nicht in jedem Bereich der Top-Experte. Aber er hat einen überwältigenden Einfluss auf die Festlegung der Roadmaps für alle kritischen Aspekte von Ethereum (Skalierung, AA, Proof-of-Stake...), nicht nur wegen seiner technischen Expertise, sondern auch, weil er der ultimative Richter darüber ist, ob eine Roadmap mit der Vision von Ethereum übereinstimmt - seiner Vision.

Jedes erfolgreiche Produkt beginnt mit einer Vision

Wenn meine Meinung, dass Vitalik der CTO von Ethereum ist, für Sie nicht kontrovers genug ist, kommt hier der kontroverseste Teil: Wir sollten Vitalik als CTO annehmen.

Als Startup-Gründer bin ich der Meinung, dass hinter jedem erfolgreichen Produkt – und ja, Ethereum ist ein "Produkt" in dem Sinne, dass es echte Probleme für echte Menschen löst – eine kohärente Vision stehen muss. Und eine kohärente Vision muss notwendigerweise von einer kleinen Anzahl von Personen gesetzt werden, wie z. B. den Gründern eines Startups, und oft nur von einem Gründer.

Das Schöne an Ethereum ist, dass, obwohl es ein so komplexes System mit so vielen beweglichen Teilen ist, die Teile wunderbar zu einem funktionierenden dezentralen Computer passen, der jeden Tag Werte im Wert von Milliarden von Dollar bewegt. Und die Art und Weise, wie wir hierher gekommen sind, war nicht durch die Planung von Komitees. Gerade wegen Vitaliks aktiver Führung durch seine Vision sind wir in der Lage, zu einem kohärenten und schönen Produkt zu gelangen, das heute Ethereum ist. Ethereum war eine Idee von Vitalik im Jahr 2015 und ist es auch heute noch.

Dies soll natürlich nicht die Beiträge anderer Forscher und Ingenieure herunterspielen, die die meisten Verdienste dafür verdienen, Ethereum dorthin gebracht zu haben, wo es heute ist. Das ist jedoch nicht unvereinbar mit der Tatsache, dass Ethereum eine Verwirklichung von Vitaliks Vision ist, um Größenordnungen mehr als die aller anderen.

Und mal ehrlich, kann man sich beschweren? Als Sie sich von der Offenheit, dem Zensur-Widerstand und dem Innovationstempo des Ethereum Ökosystems angezogen fühlten – haben Sie sich darüber beschwert, dass es mit Vitaliks Vision begann? Vielleicht hast du es nicht getan, weil du es nicht so gesehen hast – aber jetzt, wo du es tust, macht es dir wirklich etwas aus?

Wie sieht es mit der Dezentralisierung aus?

Aber aber, sagen Sie, was ist mit der Dezentralisierung? Wenn eine Person eine so überwältigende Macht über Ethereum hat, wie können wir dann behaupten, dass es dezentralisiert ist?

Um diese Frage zu beantworten, müssen wir zu @VitalikButerin/the-meaning-of-decentralization-a0c92b76a274">diesem klassischen Artikel über die Bedeutung von Dezentralisierung, geschrieben von, hust, hust, Vitalik. Die wichtigste Erkenntnis des Artikels ist, dass es drei Arten der Dezentralisierung gibt:

• Architektonische Dezentralisierung: Wie viele Knoten können kompromittiert werden, bevor das System nicht mehr funktioniert?
• Logische Dezentralisierung: Können sich die Subsysteme des Systems unabhängig voneinander weiterentwickeln und gleichzeitig das System funktionsfähig halten? Oder müssen sie eng aufeinander abgestimmt werden?
• Politische Dezentralisierung: Wie viele Menschen oder Organisationen kontrollieren dieses System letztendlich?

Angesichts dieser Definitionen ist Ethereum eindeutig architektonisch dezentralisiert, und es ist wahrscheinlich fair zu sagen, dass es auch logisch dezentralisiert ist, da es keine starke Kopplung zwischen seinen verschiedenen Komponenten gibt (z. B. Konsens vs. Ausführung).

In Bezug auf die politische Dezentralisierung ist die gute Nachricht, dass keine Einzelperson oder Organisation Ethereum abschalten kann, nicht einmal Vitalik. Man könnte jedoch argumentieren, dass Ethereum nicht so politisch dezentralisiert ist, wie man denken könnte, angesichts der herausragenden Rolle, die Vitalik bei der Festlegung seiner Vision und damit bei der Festlegung seiner Roadmaps spielt.

Ich bin jedoch der Meinung, dass wir, wenn wir wollen, dass Ethereum weiterhin innovativ ist, Vitalik als De-facto-CTO annehmen müssen, auch wenn dies bedeutet, dass wir etwas politische Dezentralisierung opfern müssen.

Wenn Ethereum jemals in eine weitgehend unveränderliche Blockchain wie Bitcoin "verknöchert", dann könnte Vitalik in den Ruhestand gehen. Aber bevor wir dieses Endspiel erreichen, ist es entscheidend, dass es eine Autorität gibt, die alle Seiten respektieren, der vertraut wird, dass sie technische Entscheidungen nicht nur auf der Grundlage technischer Vorzüge beurteilt, sondern auch darauf, ob sie mit der Vision von Ethereum übereinstimmen.

Ohne eine Figur wie Vitalik sind nur zwei Ergebnisse möglich, die beide durch diese Saga aus dem Jahr 3074 anschaulich illustriert werden:

• Die Governance von Ethereum könnte sich in endlose Stillstände auflösen, in denen keine Seite zu Kompromissen bereit ist und niemand Fortschritte machen kann, wie die 3074-Debatte in einer Sackgasse war, bis Vitalik hereinkam.
• Oder Ethereum könnte zu einem Frankenstein-Monster mit inkohärenten Designs werden, wie wir daran waren, 3074 und 4337 als zwei parallele AA-Stacks zu haben, die weitgehend inkompatibel sind.

Die Rolle der Community

Wir sind sehr nahe daran, ein vollständiges mentales Modell der Ethereum Governance zu haben, aber es gibt eine eklatante Lücke in unserer bisherigen Diskussion – die Community.

Wenn Vitalik die Vision definiert, denen von Forschern definierte Roadmaps folgen, die wiederum von Kernentwicklern umgesetzt werden – welche Rolle spielt dann die Community? Sicher nicht nichts??

Glücklicherweise spielt die Community tatsächlich die wichtigste Rolle von allen. Der Grund dafür ist, dass es Werte gibt, bevor es überhaupt eine Vision gibt. Wir sind alle als Gemeinschaft zusammengekommen, weil wir uns um bestimmte Werte versammelt haben, mit denen Vitaliks Vision letztendlich übereinstimmen muss, sonst würde sie die Gemeinschaft verlieren.

Vielleicht lag es an deiner Erziehung. Vielleicht war es etwas, das in Ihrem letzten Job passiert ist. Aber irgendwann haben wir alle in der Ethereum Community beschlossen, dass es gut für die Welt wäre, einen dezentralen Computer zu haben, der für alle zugänglich ist, der nicht zensiert werden kann, der glaubwürdig neutral ist. Wir bekräftigen und bekräftigen diese Werte jeden Tag mit der Arbeit, die wir zusätzlich zu Ethereum leisten, und indem wir dies tun, verleihen wir der Vision, den Roadmaps und dem Code, die von Vitalik, Forschern und Kernentwicklern erstellt wurden, Legitimität.

• Es muss mehr Sichtbarkeit für EIPs geben, die aktiv für die Aufnahme in Betracht gezogen werden. Die Gemeinschaft als Ganzes sollte niemals "überrascht" werden, dass eine EIP akzeptiert wird, wie es bei 3074 der Fall war.
  • Im Gegensatz zu dem, was Sie vielleicht erwarten, spiegelt der "Status" eines EIP auf der EIP-Website nicht seinen Status im ACD-Prozess wider. Das ist der Grund, warum es immer noch heißt, dass 3074 in "Review" ist, obwohl die Kernentwickler bereits dafür gestimmt hatten, es zu genehmigen, und es gab noch weniger Anzeichen dafür, dass es jemals für die Aufnahme in Betracht gezogen wurde.
  • Im Idealfall würde EF in den sozialen Medien laut und deutlich machen, wenn eine EIP angenommen werden soll, um das Bewusstsein der Community zu erhöhen.
• Manchmal unterschätzen die Kernentwickler die Auswirkungen, die eine bestimmte EIP auf nachgelagerte Projekte und Benutzer hat, was bei 3074 und der 4337-Community der Fall ist. Da ACD-Meetings zeitlich begrenzt sind und über Zeitzonen hinweg koordiniert werden müssen, wird verständlicherweise betont, dass nur "relevante Personen" bei den Meetings sprechen sollten. Es könnte jedoch sinnvoll sein, den Community-Mitgliedern von Zeit zu Zeit etwas Zeit einzuräumen, um sich zu den nachgelagerten Auswirkungen bestimmter EIPs zu äußern.
  • Wenn Forscher das Gefühl haben, dass ihr Input von den Kernentwicklern nicht ankommt, wie es beim 4337-Team der Fall war, könnten sie Community-Mitglieder in den Aufruf einbeziehen, um ihre Argumente zu stärken.
• Entscheidend ist, dass es eine gegenseitige Anerkennung zwischen Kernentwicklern und Forschern gibt, dass sie beide Governance-Kräfte sind, wenn auch mit unterschiedlichen Stärken. Die "Client-Macht" der Kernentwickler ist die einzige Macht, die tatsächlich durch die Implementierung von Clients "abstimmen" kann. Die "Roadmap-Macht" von Forschern genießt in der Regel mehr öffentliche Unterstützung, da die Forscher aktiv über ihre Roadmaps sprechen und schreiben.
  • Wenn die beiden Mächte uneins sind, kann es für die Kernentwickler verlockend sein, sich einfach über die Forscher hinwegzusetzen, z. B. wenn die Kernentwickler die Einwände des 4337-Teams außer Kraft setzen. Eine solche Außerkraftsetzung kann jedoch zu einem Schleudertrauma führen, da die Mächte instabil sind, wenn sie sich in einem Konflikt befinden, wie das folgende Drama nach der Verabschiedung von 3074 zeigt.
  • In ähnlicher Weise kann es für Forscher angesichts von Widerstand verlockend sein, die Zusammenarbeit mit den Kernentwicklern einfach aufzugeben, was meiner Meinung nach ein Grund dafür ist, dass der RIP-Prozess erstellt wurde und warum natives AA (7560) jetzt in erster Linie als RIP und nicht als EIP gepusht wird. Obwohl es echte Vorteile hat, L2s beim Experimentieren mit Protokoll zu unterstützen, die für L1 zu umstritten sind, können wir RIPs nicht als Ersatz für die Beteiligung am EIP-Governance-Prozess betrachten. Die Forscher müssen so lange mit den Kernentwicklern zusammenarbeiten, bis sie vollständig mit den Roadmaps übereinstimmen.

Schlussfolgerung

Die 3074/7702-Saga wirft ein Licht darauf, wie Ethereum Governance wirklich funktioniert – dass es neben der expliziten Governance-Macht, die der EIP/ACD-Prozess ist, der von den Kernentwicklern vorangetrieben wird, auch die implizite Governance-Macht von Roadmaps gibt, die von Forschern vorangetrieben werden. Wenn diese Kräfte nicht aufeinander abgestimmt sind, sehen wir Stillstand und Schleudertrauma, und es könnte eine andere Macht – Vitalik – brauchen, um das Gleichgewicht in die eine oder andere Richtung zu kippen.

Wir argumentieren dann, dass Vitalik eine bestimmte Macht darstellt, die die "Vision" von Ethereum ist, die die Grundlage für die Legitimität aller Roadmaps ist. Wir vergleichen Vitalik mit dem CTO eines großen Unternehmens und erkennen an, dass seine Rolle als Pseudo-CTO notwendig ist, damit Ethereum sein Innovationstempo aufrechterhalten kann, ohne in ein Frankenstein-System inkohärenter Designs zu verkommen.

Abschließend stellen wir ein mentales Modell vor, um Ethereum Governance als VVRC zu betrachten: Werte (Community) ⇒ Vision (Vitalik) ⇒ Roadmaps (Forscher) ⇒ Kunden (Core Devs). Wir schlagen dann verschiedene Möglichkeiten vor, um die "Fehler" zu beheben, die manchmal dazu führen, dass der Prozess in der Praxis von diesem Modell abweicht.

Ethereum Governance ist "die Maschine, die die Maschine baut" – um Ethereum richtig zu machen, müssen wir die Governance richtig machen. Als solches lieferte 3074 eine unschätzbare Fallstudie dafür, wann die Governance schief gelaufen ist, und ich hoffe, dass ich einige hilfreiche Lehren daraus ziehen konnte, damit wir die Ethereum Governance für die Zukunft verbessern können.

Haftungsausschluss:

1. Dieser Artikel ist abgedruckt von [zerodev]. Alle Urheberrechte liegen beim ursprünglichen Autor [derek]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Team von Gate Learn, 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, Verbreiten oder Plagiieren der übersetzten Artikel verboten.