Ethereum Core Governance erklärt

Eine Präsentation von Nixo Rokish von der Ethereum Foundation auf der ETHBoulder, die die Core-Protokoll-Governance von Ethereum erklärt, wie Hard Forks koordiniert werden, häufige Missverständnisse darüber, wer Ethereum kontrolliert, und wie man am Governance-Prozess teilnehmen kann.

Dieses Transkript ist eine barrierefreie Kopie des ursprünglichen Video-Transkripts (opens in a new tab), das von EthBoulder veröffentlicht wurde. Es wurde zur besseren Lesbarkeit leicht bearbeitet.

Einführung (0:12)

Danke an alle sechs meiner Freunde, die aufgetaucht sind. Also gut. Ich spreche heute zu euch über die Ethereum Core Governance. Mein Name ist Nixo. Ich leite das Protokoll-Support-Team bei der EF. Zu unseren Aufgaben gehört es unter anderem, den Governance-Prozess klarer und einfacher navigierbar für alle anderen zu machen, die an diesen Dingen teilnehmen, denn Ethereum umfasst viel mehr als nur seine Core-Entwickler.

Hier ist also ein Überblick über den Vortrag. Wir werden darüber sprechen, was Core Governance ist. Wir werden über Missverständnisse sprechen und darüber, wie die Ethereum-Governance derzeit funktioniert. Wir werden darauf eingehen, wie sie im Vergleich zu anderen dezentralen Governance-Systemen abschneidet, warum Entwickler sich dafür interessieren sollten und welche konkreten Wege es zur Teilnahme gibt.

Also, was ist Core-Protokoll-Governance? Ich betreibe einen Knoten. Das bedeutet, ich habe ein Stück Hardware, einen Computer bei mir zu Hause, auf dem ich Ethereum-Software ausführe. Als ich diese Ethereum-Software eingerichtet habe, musste ich die Clients auswählen, die diese Software ausführen würden. Ethereum ist insofern einzigartig, als es mehrere Clients für die Client-Diversität hat. Der Sinn dahinter ist: Wenn ein Client ausfällt, wenn es einen Fehler in einem Client gibt, fällt nicht das gesamte Netzwerk aus. Es gibt andere Blockchains, die andere Clients haben. Ethereum ist jedoch die einzige, die so eingerichtet ist, dass sie uns tatsächlich vor Fehlern schützt. Wenn man sich zum Beispiel Solana ansieht: Solana hat einen anderen Client, ich glaube, er heißt GTO, aber er hat nur 20–21 % Akzeptanz. Wenn also der Mehrheits-Client ausfällt, fällt die Chain aus. Und wir haben gesehen, wie andere Netzwerke ausgefallen sind. Und das ist der Grund, warum Ethereum die widerstandsfähigste und sicherste Blockchain ist.

Die Frage ist also, wie man Änderungen in Ethereum einbringt, wenn man sich mit so vielen verschiedenen Clients koordinieren muss. Zuerst unterscheiden wir zwischen einem Hard Fork und einem Soft Fork. Ein Soft Fork erfordert nicht die Koordination, die ein Hard Fork benötigt. Ethereum arbeitet hauptsächlich mit Hard Forks. Ein Hard Fork bedeutet im Grunde, dass alle Clients eine neue Version von Ethereum erstellen und beschließen, diese neue Version von Ethereum zu einem vorkonfigurierten Zeitpunkt zu starten. Es ist immer noch Ethereum, aber es hat neue Funktionen. Es hat andere Funktionen. Und alle Knotenbetreiber wie ich, die Knoten zu Hause betreiben, oder professionelle Betreiber müssen diese neue Version von Ethereum akzeptieren. Sie müssen ihren Knoten upgraden oder aktualisieren, um diese neue Software aufzunehmen.

Wie entscheiden sie also, welche Funktionen in diese Hard Forks aufgenommen werden? Sie müssen sich auf Prioritäten einigen, um ihre Zeit und Ressourcen zuzuweisen, da sie nur über begrenzte Zeit und Ressourcen verfügen. Sie priorisieren Dinge wie Sicherheitslücken oder Sicherheitspatches, Dinge wie UX – wenn es eine andere Blockchain gibt, die mit uns konkurriert, müssen wir mit diesen anderen Blockchains wettbewerbsfähig werden. Eines der Dinge, auf die sie achten, ist also, dass jede Funktion, die integriert wird, vorwärtskompatibel mit potenziellen zukünftigen Roadmap-Punkten sein muss.

Letztes Jahr ist also eine wirklich umstrittene Sache passiert. Vielleicht habt ihr davon gehört. Es hieß EOF. Das steht für EVM Object Format. Das war eine Reihe von Funktionen, die in den Fusaka Hard Fork aufgenommen werden sollten – Pectra, Fusaka, ich glaube beide –, aber es wurde aufgeteilt. Und ein Auslöser unter vielen, warum es aus diesem Fork geworfen wurde, war, dass Vitalik einen Beitrag über das Potenzial von Ethereum veröffentlichte, RISC-V zu übernehmen. Viele Leute, die das lasen, dachten sich: Okay, wenn wir RISC-V übernehmen, sind die Funktionen, die wir in EOF betrachten, nativ in RISC-V enthalten. Warum sollten wir dem Protokoll also diese Komplexität hinzufügen? Warum sollten wir all diese Ressourcen der Client-Entwickler in diese Sache stecken? Es wäre hinfällig, wenn wir letztendlich zu RISC-V wechseln würden.

Das war also sozusagen der Tropfen, der das Fass bei EOF zum Überlaufen brachte, und es wurde schließlich aus dem Fork geworfen. Eine weitere Sache, die sie berücksichtigen müssen, ist, dass es in sechs verschiedenen Sprachen geschrieben und streng getestet werden muss, da diese Clients in sechs verschiedenen Sprachen geschrieben sind. Das ist also eine wirklich große Testmatrix, mit der sie arbeiten müssen. Und aus diesem Grund wird jede noch so kleine Designentscheidung debattiert, ohne dass es eine Autorität gibt, die Meinungsverschiedenheiten beilegt. Die Frage, die sich daraus ergibt, ist also, wer entscheidet – was der Kern der Governance ist.

Missverständnisse (5:23)

Das bringt uns zu den Missverständnissen, und wir werden einige davon ansprechen. Eines ist, dass Vitalik entscheidet, was in das Ethereum-Protokoll aufgenommen wird. Eine Erweiterung davon ist, dass die EF alles kontrolliert. Und ein drittes ist, dass alles in Hinterzimmern abläuft – Insider, OGs, die diese Entscheidungen treffen.

Also zum ersten: Vitalik entscheidet. Ich habe einfach eine Teilmenge stagnierender EIPs ausgewählt, die von Vitalik verfasst wurden. Das bedeutet, dass Vitalik sich hingesetzt hat, einen Vorschlag geschrieben hat und sagte: Ich möchte, dass diese Dinge in Ethereum aufgenommen werden, und niemand hat zugestimmt – diese Dinge liegen einfach nur da. Er konnte sie nicht in das Protokoll einbringen. Es wird also nicht alles, was er vorschlägt, automatisch aufgenommen.

Eine Erweiterung davon ist, dass die Ethereum Foundation alles kontrolliert. Ich werde ein spezifisches Beispiel für eine Zeit auswählen, die dem meiner Meinung nach widerspricht. Im Jahr 2024 wurde viel über das Gaslimit gesprochen. Der Grund dafür ist, dass wir 2022 während des Merges das Gaslimit auf 30 Millionen angehoben haben. Das ist die maximale Berechnung, die in einem Block zulässig ist. Und dann haben wir es eine Weile lang nicht angerührt, weil es nicht wirklich ein Engpass war, bei dem die Leute sagten: „Deshalb wechsle ich nicht zu Ethereum“ oder „Das schränkt meinen aktuellen Anwendungsfall von Ethereum ein.“

Und Ende 2023, Anfang 2024 gab es dieses Narrativ, dass Solana im Kommen sei. Es würde Ethereum den Rang ablaufen. Und so dachten die Leute darüber nach, was Ethereum tun kann, um zu beschleunigen. Und eines der Dinge war: Lasst uns diese Gas-Metrik nach oben treiben. Und zu der Zeit dachten sich die EF und die Client-Entwickler eher: „Wir haben andere Dinge, um die wir uns kümmern müssen. Trotzdem danke.“ Aber diese beiden Leute, Eric Connor und Mariano Conti, kamen und sagten: „Nein, wir erhöhen das Gaslimit.“ Das Gaslimit ist ein vom Validator kontrollierter Parameter. Und so konnten sie einfach anfangen, mit Validatoren, professionellen Betreibern, zu sprechen und zu sagen: „Hey, erhöht euer Gaslimit.“

Und irgendwann gab es genug Akzeptanz, sodass die EF und die Clients sagten: „Oh, wir müssen darauf achten. Wir müssen sicherstellen, dass das, was sie tun, sicher ist und dass der Wert, auf den sie es letztendlich erhöhen, eine sichere Sache für das Netzwerk sein wird.“ Sie mussten also ihre Ressourcen neu zuweisen. Nethermind entwickelte dieses Test-Framework. Die EF leistete in Berlin eine Menge Arbeit. Alle Client-Entwickler führten Benchmarks dafür durch. Und deshalb gefällt mir das, weil es die EF dazu zwang, zu entscheiden, was priorisiert wurde.

Und ich mag diesen dummen Tweet, den ich hier als Screenshot eingefügt habe, weil es so ist, als würde irgendein zufälliges Nachrichtenportal Eric Connor und Mariano Conti als Core-Entwickler bezeichnen. Sie sind keine Core-Entwickler. Eric Connor war ein Staker und ein Community-Mitglied. Mariano Conti war ein ehemaliger MakerDAO-App-Entwickler. Aber sie wurden einfach Core-Entwickler genannt, weil die Ethereum-Entwicklung wirklich außerhalb der Welt der traditionellen Softwareentwicklung liegt, und so sahen sie, dass ein Kernparameter geändert wurde, und dachten: „Oh, das müssen Core-Entwickler sein.“ Das waren sie nicht. Das ist also nur ein Beispiel dafür, wie Community-Mitglieder kommen und sagen, wir wollen diese Änderung sehen, und sie in die Tat umsetzen.

Es sind alles Hinterzimmer-Deals, Insider, OGs – ich verstehe ein bisschen besser, warum das ein Missverständnis ist, denn man kommt im Grunde zu diesen Governance-Calls, da sind hundert Leute in diesen Governance-Calls. Es scheint, als wären sie alle sehr vertraut mit dem, was vor sich geht. Man ist verloren. Man hat keine Ahnung, wie diese Entscheidungen getroffen werden. Man denkt sich: „Bin ich schon dran mit Reden?“ Und es fühlt sich an, als würden die Leute immer denselben 10 Personen zuhören, um diese Entscheidungen zu treffen.

Leistungsprinzip und Teilnahme-Statistiken (10:18)

Aber die Wahrheit ist, dass die Ethereum-Entwicklung mehr eine Leistungsgesellschaft (Meritokratie) ist, als ich es je in der meisten Softwareentwicklung gesehen habe. All diese Leute auf diesem Screenshot – das ist einer von dreien in diesem zufälligen ACD-Call, den ich als Screenshot aufgenommen habe – niemand von diesen Leuten wurde ernannt, um hier zu sein. Jeder ist einfach nur jemand, der aufgetaucht ist. Es sind die Entwickler, die viel Zeit mit diesem Protokoll verbracht haben. Sie sind diejenigen, die von den Leuten als talentierte Entwickler in diesem Bereich anerkannt wurden, die beständig gute Entscheidungen treffen, und niemand hier ist ernannt worden, um hier zu sein.

Ich bin also erst vor etwas mehr als einem Jahr zur EF gekommen. Ich habe mir diese Statistiken geschnappt. Sie gehen nur bis März 2025 zurück. Also weniger als ein Jahr. Die durchschnittliche Anzahl der Teilnehmer an den All Core Devs – das sind die Governance-Calls – beträgt 98. Im Durchschnitt sind also 98 Personen in diesen Calls. Die maximale Teilnehmerzahl in einem Call seitdem lag bei 153. Ich glaube, das war der Tag, an dem wir das Datum für das Pectra Mainnet festgelegt haben. Und die Gesamtzahl der eindeutigen Teilnehmer beträgt 567 allein im letzten Jahr. Ich mag diese Metrik wirklich, weil sie zeigt, dass nicht jedes Mal dieselben 100 Leute an diesen Calls teilnehmen. Diese App-Entwickler, Forscher, jemand hört von einer Funktion, die diskutiert wird, sie tauchen auf, um ihren Widerstand dagegen oder ihre Unterstützung dafür zu äußern, und dann kommen sie zu keinem weiteren Call mehr.

Wie der Governance-Prozess funktioniert (11:52)

Das ist also eine etwas trockene Folie, aber ich denke, es ist wichtig, sie durchzugehen – so funktioniert die Governance von Ethereum derzeit. Wenn also einer dieser Forks diskutiert wird, ist das Erste, was passiert, dass die Leute während dieses zugewiesenen Zeitfensters ihren Headliner-Vorschlag einreichen können. Der Headliner-Vorschlag ist die Hauptfunktion, um die sich die Leute für diesen Fork versammeln sollen. Das kann ein Community-Mitglied, ein Forscher, ein Core-Entwickler sein – wirklich jeder, der einen dieser Headliner-Vorschläge einreicht. Dann endet das Zeitfenster und in den Governance-Calls diskutieren wir sozusagen, welcher davon Sinn macht. Die Leute bringen ihre Argumente vor, die Leute diskutieren und es gibt einen Konsens darüber, welchen wir für den kommenden Fork auswählen sollten.

Danach wählen sie die kleineren Funktionen aus. Also die kleineren Dinge, die nicht unbedingt diese großen, den Fork antreibenden Funktionen sein müssen. Und während dieser ganzen Zeit haben wir funktionsspezifische Devnets. Ein Devnet ist wie ein Testnetz – ein privates Testnetzwerk für die Entwickler, um diese Funktionen zu testen und sicherzustellen, dass sie tatsächlich auf Ethereum funktionieren. Und dann gibt es irgendwann einen Feature Freeze (Funktionsstopp). Wir haben also die Hauptfunktionen diskutiert, wir haben die kleineren Funktionen diskutiert, wir haben diese funktionsspezifischen Devnets betrieben, die normalerweise die Fork-Headliner sind. Und das ist ein Feature Freeze mit einem Sternchen, denn zu diesem Zeitpunkt haben wir entschieden, dass wir diesem Fork keine weiteren Funktionen mehr hinzufügen werden. Wir werden alle Funktionen zusammen ausführen, sicherstellen, dass alles gut ist, sicherstellen, dass nichts kaputt geht. Aber wenn etwas anfängt, die Dinge zu verlangsamen, wenn sich der Fork verzögert, wenn es zu komplex ist, können Dinge zu diesem Zeitpunkt immer noch rausgeworfen werden.

Nach einer Reihe von Devnets – es könnten zwei sein, es könnten 10 sein – entscheiden die Clients also irgendwann alle, dass dies stabil ist. Wir vertrauen dem, was gerade vor sich geht. Wir sind an einem guten Punkt. Lasst uns anfangen darüber nachzudenken, dies auf das Ethereum Mainnet zu bringen. Sie veröffentlichen Client-Releases und dann gibt es eine 30-tägige Frist, in der das EF-Sicherheitsteam ein Bug-Bounty ausschreibt. Sie beauftragen Sicherheitsaudits. Und am Ende dieser 30-tägigen Frist starten wir den Fork auf Testnetzen. Das sind Testnetze, von denen ihr vielleicht schon gehört habt – wie Holesky. Hier können App-Entwickler ihre Sachen testen, bevor der Fork live geht. Und diese dauern in der Regel jeweils mindestens 14 Tage, nur um sicherzustellen, dass alles in Ordnung ist. Wir erwarten keine großen Probleme, da es zuvor funktionsspezifische Devnets und verallgemeinerte Devnets durchlaufen hat, aber in der Vergangenheit hat es einige dieser Testnetze lahmgelegt. Und so ist dies sozusagen der letzte Aufruf, all diese Fehler zu finden und zu beheben.

Und sobald das erlaubnisfreie Testnetz stabil ist, wird das Mainnet-Datum gewählt. Danach gibt es einen 30-tägigen Puffer. Dieser 30-tägige Puffer existiert, weil L2s und Protokolle dies angefordert haben, um sich auf den Fork vorzubereiten. Das sind also mindestens 30 Tage und dann findet der Fork statt.

Call-Struktur und Koordination (15:01)

Während dieser ganzen Zeit finden einige wichtige Call-Serien statt. Dies sind alles öffentliche Calls, die live auf YouTube gestreamt werden. Die wichtigsten sind ACDE und ACDC. E steht für Ausführungsschicht (Execution Layer) – das sind Dinge wie Transaktionen, Smart Contract-Bereitstellungen, Mempool-Management. ACDC ist die Konsensschicht (Consensus Layer) – das sind also Validator-Dinge wie Validator-Management, Slashing. Und diese wechseln sich donnerstags ab. Es gibt also jeden einzelnen Donnerstag einen ACD und einer davon ist ACDE und dann der nächste ist ACDC, und so geht es weiter.

Die ACDE- und ACDC-Calls konzentrieren sich auf den Fork, den wir gerade durchführen, und auf Forks, die wir für die Zukunft ins Auge fassen. Die ACDT-Calls gehen mehr ins Detail. Es sind die Clients, die über Fehler sprechen, an denen sie nicht vorbeikommen, oder über Implementierungsdetails, die für den Fork, an dem sie gerade arbeiten, gelöst werden müssen. Im Moment ist der nächste Fork, der ansteht, Glamsterdam. Diese ACDT-Calls werden also von Gesprächen über ePBS und Zugriffslisten auf Blockebene dominiert, was die Dinge sind, die in Glamsterdam einfließen. Und das sind die hochtechnischen Calls.

Und dann gibt es Breakout-Calls. Breakout-Calls sind Community-Mitglieder, Forscher, Entwickler, die sagen: „Hey, ich habe eine Funktion, die ich in zwei Forks in Ethereum einbringen möchte.“ Und so veranstalten sie diese wöchentlichen, monatlichen oder zweimonatlichen Calls, in denen sie die Implementierungsdetails ausarbeiten, die Spezifikation ändern und iterieren und im Allgemeinen alle Fragen ansprechen, die die Leute haben, alle bekannten Unbekannten, um sicherzustellen, dass sie sich in der bestmöglichen Position befindet, um in den übernächsten Fork aufgenommen zu werden. Und diese können angesetzt werden, wann immer der Moderator (Facilitator) es entscheidet.

Ein sich entwickelnder Prozess (15:29)

Eine Sache, die ich jedem ans Herz legen möchte, ist, dass dieser Prozess alles andere als statisch ist. Dieser Prozess, den ich euch gerade beschrieben habe, ist seit weniger als einem Jahr live. Ethereum ist seit 10 Jahren live. Aber er ändert sich ständig, und der Grund dafür ist, dass niemand das Sagen hat. Und dieser Prozess entwickelt sich sozusagen weiter, um die effizienteste Arbeitsweise herauszufinden. Und ich sage zwar effizient, aber der Ruf, den die Ethereum-Governance hat, ist, dass sie wirklich stagniert, dass es schwer ist, Dinge durchzusetzen, dass sie verwirrend ist – und das liegt daran, dass ich ehrlich gesagt beeindruckt bin, dass das überhaupt funktioniert, wenn 100 bis 500 Leute Entscheidungen treffen.

Tim hat also im April 2025 einen Beitrag mit dem Titel „Reconfiguring All Core Devs“ verfasst, der letztendlich der Vorschlag dafür war, wie die Dinge jetzt funktionieren. Und der Grund dafür ist, dass wir davor sozusagen dieses zusammenhängende Narrativ darüber hatten, worauf wir uns bei Ethereum konzentrieren sollten. Es gab den Merge, was ein riesiges Unterfangen war. Alle waren sehr aufgeregt. Die meisten Leute waren sehr aufgeregt. Die Miner waren es nicht. Und dann folgten auf den Merge die Auszahlungen (Withdrawals). Wir wollten also nicht, dass die Leute ihre ETH in einem Smart Contract gesperrt haben und dieser FUD entsteht, dass sie die ETH da nie wieder herausbekommen. Also mussten wir das so schnell wie möglich ausliefern. Und dann gab es Proto-Danksharding und dann kam Pectra, und Pectra war eine Art Sammelsurium verschiedener, nicht zusammenhängender EIPs und hatte nicht wirklich ein zusammenhängendes Narrativ. Und es wurde so groß, weil die Leute aufgrund des Mangels an Zusammenhalt einfach Dinge hineinschoben, dass es in zwei verschiedene Forks aufgeteilt werden musste, weil die Testteams meinten: „Der Umfang ist viel zu groß. Wir können das nicht alles testen.“

Und so war Tims Anstoß dafür: Okay, wir müssen uns einen Weg überlegen, um diese Forks so fokussiert und zusammenhängend wie möglich zu halten. Und der Headliner war sozusagen die Antwort darauf. Der Sinn dahinter war, auf eine Weise auszuliefern, die es priorisiert, dass jeder das Gefühl hat zu wissen, worum es bei dem Fork geht, damit sie nicht 25 verschiedene EIPs hineinschieben müssen.

Der andere Screenshot oben zeigt also, wie Tim Definitionen für die Phasen der Aufnahme dieser EIPs vorschlägt. Und der Punkt, den ich damit machen möchte, ist, dass man manchmal Leute sagen hört, dieser Prozess sei zu bürokratisch. Aber was wirklich passiert, ist, dass Leute in diesen Governance-Prozess kommen und fragen: „Wie bekomme ich ein EIP rein?“ und Leute, die schon seit 10 Jahren dabei sind, sagen: „Man macht es einfach irgendwie.“ Und die Leute denken sich: „Das ist schrecklich.“ Und was diese Dinge also tun, ist, dass sie beschreiben, was passiert, um es Außenstehenden zu erleichtern, an diesem Prozess teilzunehmen. Denn wenn man einfach hierherkommt und sagt: „Ich habe ein EIP, mir ist die Ethereum-Governance egal, ich möchte nur dieses eine EIP reinbekommen“ – dann möchte man eine Rubrik, man möchte eine Checkliste, man möchte eine sehr klare Schritt-für-Schritt-Anleitung, wie man dieses EIP reinbekommt. Bei den meisten dieser Dinge geht es also mehr darum, zu beschreiben, wie der Prozess funktioniert, als bürokratische Regeln zu schaffen, die die Leute befolgen müssen, um es schwer zu machen, EIPs reinzubekommen.

Die dritte Sache sind Commits im Laufe der Zeit auf Forkcast. Forkcast ist ein Produkt meines Teams, von Wolfram Mark, einem Typen in meinem Team, der dies Mitte letzten Jahres entwickelt hat, als mein Team in seiner jetzigen Form gegründet wurde. Und es ist zu einer so kanonischen Ressource für die Leute geworden, um mit einem Fork zu interagieren, um zu sehen, was in einen Fork einfließt und wie es sie betrifft. All diese Dinge sind weniger als zwei Jahre alt. Der Punkt, den ich also machen möchte, ist, dass sich dieser Prozess stark verändert. Er ist überhaupt nicht statisch. Es ist keine eingefrorene Bürokratie, bei der es schwer ist, einen Fuß in die Tür zu bekommen.

Vergleichbare Governance-Systeme (20:21)

Ich wollte also nur kurz auf die ähnlichsten dezentralen Governance-Systeme eingehen, die ich im Vergleich zur Ethereum-Governance sehe. Und der Punkt, den ich hier irgendwie machen möchte, ist, dass dies nachhaltig ist – auch wenn es erstaunlich ist, dass 100 bis 500 Leute Entscheidungen treffen können, ist es in der realen Welt nachhaltig. Wir sehen Beispiele dafür, dass dies funktioniert.

Die IETF ist die Internet Engineering Task Force. Es ist das ehrenamtlich geführte Standardisierungsgremium, das TCP/IP und HTTP entwickelt hat. Es ist die Organisation, die am meisten dafür verantwortlich ist, dass wir heute das freie Internet haben. Der Linux-Kernel – er ist der Kern des Linux-Betriebssystems. Das ist also Open-Source-Software, die Internet-Server, Android-Telefone und Supercomputer antreibt. Der Unterschied dort ist, dass sie mit Linus Torvalds eine Art wohlwollendes Diktator-Modell haben. Aber selbst dann haben sie über 17.000 Mitwirkende, was atemberaubend ist.

Dinge, denen dies nicht ähnlich ist: andere Blockchains, die Onchain-Token-Abstimmungen haben. Ethereum vermeidet ausdrücklich jede Art von Abstimmungsmechanismus, weil das meiner Meinung nach zu Möglichkeiten der Vereinnahmung führt und sozusagen den Anreiz beseitigt, die Dinge zu einer Leistungsgesellschaft zu machen, in der die Leute einfach denjenigen vertrauen, die den besten Code schreiben. Und dann gibt es L2s. Sie haben Multi-Sigs. Sie haben Sicherheitsräte. Das sind eher ernannte Positionen, die diese Entscheidungen treffen. Und das hat seine Kompromisse. Es ist zentralisierter. Es bewegt sich jedoch schneller.

Warum Entwickler sich dafür interessieren (22:38)

Warum interessieren sich Entwickler also für Governance? Weil Entwickler buchstäblich diejenigen sind, für die Ethereum geschaffen wurde. Ethereum wurde nicht für Core-Entwickler geschaffen. Es wurde nicht für Validatoren geschaffen. Manchmal sind diese Leute darüber verwirrt. Ethereum-Core-Entwickler und Validatoren dienen Ethereum, das wiederum Entwicklern und Nutzern dient.

Und jeder hatte schon mal diesen Moment mit einer KI, in dem man sich viel zu sehr in Details verliert und sie versucht, diese kleine Sache zu reparieren, und es versäumt, herauszuzoomen und den gesamten Zweck des Projekts zu betrachten. Und Core-Entwickler können so sein, wenn sie versuchen, den Core-Entwicklungsprozess zu perfektionieren. Und in diesem Fall ist es sehr wichtig, dass Entwickler hinzukommen, denn die Core-Entwicklung ist so allumfassend, dass sie die meiste Zeit nicht auch noch auf Ethereum aufbauen. Sie sind sehr in die Core-Entwicklung involviert. Es nimmt ihre ganze Zeit in Anspruch. Und so müssen sich App-Entwickler wirklich bemühen, zu kommen und zu sagen: „Hey, wir brauchen das. Das ist entscheidend für Ethereum.“ Nur um sicherzustellen, dass die Perspektive vorhanden ist und dass sie nicht einfach in die Schublade gesteckt werden, nur für Core-Entwickler zu arbeiten.

Wie man teilnehmen kann (24:40)

Wie kann man also teilnehmen oder seine Funktion einbringen? Das ist ein eher allgemeiner Ratschlag, aber ich denke, es ist der beste. Sprecht laut über eure Schmerzpunkte. Geht auf Twitter, schreibt Blogbeiträge, identifiziert Lösungen für eure Schmerzpunkte. Spekuliert über die Dinge, die euch helfen könnten. Wenn ihr andere Leute findet, die dieselben Schmerzpunkte haben, könnt ihr in der Regel ein EIP finden, das existiert, um diesen Schmerzpunkt anzugehen, oder jemanden finden, der euch hilft, ein EIP zu schreiben, das dies tut.

Eine Sache, die ich an Open-Source-Software mag, ist, dass gut kapitalisierte Unternehmen in der Regel ihre Entwicklungszeit und Ressourcen für die Pflege von Open-Source-Tools aufwenden, die sie verwenden. Und am Ende arbeiten viele verschiedene Unternehmen zusammen, um diese Sache zu pflegen, und so kann es auch bei Ethereum funktionieren. Wenn ihr also einen Schmerzpunkt identifiziert habt, könnt ihr einen Base-Entwickler finden, der einen ähnlichen Schmerzpunkt hat, und Base ist eine gut kapitalisierte Organisation, und so wären sie wahrscheinlich bereit, einige Ressourcen bereitzustellen, um eine Funktion auszuliefern oder eine Funktion durch einen Ethereum Hard Fork zu begleiten.

Ich hinterlasse euch einfach einige Ressourcen. Forkcast.org – dort könnt ihr nachsehen, was in einen Fork einfließt und wie es bestimmte Stakeholder betrifft. Wenn ihr also ein App-Entwickler seid, gibt es einen Abschnitt für App-Entwickler. Wenn ihr ein Wallet-Entwickler oder ein Konsensschicht-Client-Entwickler seid, gibt es Abschnitte darüber, wie sich das alles auf euch auswirkt. Auf YouTube werden all diese Call-Videos hochgeladen. Sie sind auch auf der Seite forkcast.org/calls eingebettet, wo es Zusammenfassungen und Sprecherzuordnungen gibt, sodass es einfacher ist, durch diese Calls zu navigieren. Das EIP-Verzeichnis, das Ethereum Magicians-Forum, wo ihr mit anderen Leuten über mögliche Lösungen oder EIPs sprechen könnt, die ihr schreiben möchtet. Und sehr bald wird mein Team eine Protokoll-Support-Seite haben. Sie sieht fantastisch aus. Sie ist noch nicht bereit zum Teilen. Meine E-Mail-Adresse steht auch dort – nixo@ethereum.org (opens email client). Das war's.