Reenvía el título original 'Reflexiones sobre la gobernanza de Ethereum después de la saga 3074'

Resumen: El artículo es una declaración de Derek Chiang, CEO de ZeroDev, en respuesta a la propuesta de V de EIP-7702 para equilibrar las contradicciones entre ERC-4337 y EIP-3074. Escrito desde la perspectiva de un fundador de proyecto dentro del ecosistema AA, destaca objetivamente el modelo de gobernanza actual de Ethereum y sus puntos débiles. Derek señala sucintamente:

Uno de los conflictos de gobernanza de Ethereum radica en las discrepancias entre la hoja de ruta determinada por los investigadores y las perspectivas de los equipos de desarrollo de clientes como Geth. Vitalik, actuando en un papel similar al de un CTO, se convierte en última instancia en el factor decisivo.

Después de afirmar el papel de Vitalik, Derek describe las mejoras que Ethereum debería realizar en su modelo de gobernanza, ofreciendo información valiosa tanto para las comunidades de Ethereum como para las de Bitcoin.

Mensaje de texto:

Si no estabas familiarizado con los eventos que rodean la abstracción de cuentas (AA) de Ethereum anteriormente, aquí tienes un breve resumen: Hace varias semanas, la propuesta EIP-3074 fue aprobada por los desarrolladores principales de Ethereum para ser incluida en la próxima bifurcación dura, "Pectra". Esta propuesta introduce dos nuevos códigos de operación en la máquina virtual de Ethereum (EVM), lo que permite a las cuentas de propiedad externa (EOA) de Ethereum tener una experiencia AA casi nativa. Desde entonces, muchos miembros de la comunidad ERC-4337, en particular sus defensores, se han opuesto firmemente a EIP-3074, citando preocupaciones sobre posibles riesgos de seguridad y su incompatibilidad con la hoja de ruta AA de Ethereum. En la hoja de ruta anterior de Ethereum, ERC-4337 y propuestas similares como la 7560 (también conocida como "nativaAA") eran centrales. A principios de mayo, Vitalik propuso EIP-7702 como una alternativa a EIP-3074, logrando un equilibrio entre 4337 y 3074, proporcionando una experiencia AA para los usuarios de EOA mientras mantenía la compatibilidad con ERC-4337 hasta cierto punto, así como la compatibilidad con la "solución AA final" 7560. Actualmente, los desarrolladores principales de Ethereum están considerando las implicaciones de EIP-7702, y las discusiones preliminares y el sentimiento de la comunidad indican que es probable que EIP-7702 reemplace a EIP-3074 mencionado anteriormente. Estoy muy satisfecho con este resultado: los usuarios de EOA pronto podrán experimentar varios productos dentro del ecosistema ERC-4337 y disfrutar de la mayoría de los beneficios de AA. Sin embargo, no puedo evitar sentir que podría haber habido una mejor manera de lograr estos resultados, como muchos han señalado en las últimas semanas. Creo que con un mejor proceso de gobernanza, podríamos haber ahorrado mucha energía y lograr el resultado deseado más rápidamente. En este artículo, me gustaría:

• Identificar lo que salió mal en el proceso de gobernanza
• Proponer un modelo de pensamiento para la gobernanza de Ethereum
• Ofrecer sugerencias de mejora para evitar accidentes de gobernanza similares en el futuro

Conclusión y reflexión sobre el incidente EIP-3074

La historia mencionada anteriormente ha dejado a muchas personas descontentas por varias razones: EIP-3074 tardó varios años en ser aprobada. Después de que finalmente se aprobara el 3074, los desarrolladores principales de Ethereum se enfrentaron a una fuerte oposición de la comunidad 4337. Por otro lado, los autores de ERC-4337 expresaron repetidamente sus preocupaciones sobre EIP-3074 al equipo central de Ethereum, pero fue en vano. Ahora Ethereum planea cancelar la aprobación de 3074 y reemplazarla con otro EIP (7702). No hay nada inherentemente malo en ningún punto del proceso mencionado anteriormente:

• Es normal que las discusiones sobre un EIP tomen varios años.
• Es normal que un EIP aprobado sea rechazado después.
• Si se descubren nuevos problemas, la aprobación de un EIP se puede revocar después de la aprobación.

Sin embargo, las cosas podrían haber sido más fáciles. Imaginemos si las cosas se hubieran desarrollado así: durante la discusión de 3074, la comunidad de 4337 se involucró activamente con los desarrolladores principales de Ethereum. Si esta premisa es cierta, entonces solo hay dos resultados posibles:

• Después de considerar los comentarios de la comunidad 4337, la propuesta 3074 se aprueba (y posiblemente se modifica). En este caso, la comunidad 4337 aceptaría 3074, y el equipo central de Ethereum no necesitaría revocar 3074.
• Por otro lado, el 3074 nunca se aprueba, pero la comunidad del 4337 y el equipo central de Ethereum proponen conjuntamente una solución que satisface a todos, similar a la del 7702. Se escuchan las voces de todos y no hay un cambio drástico. Esto habría sido ideal, entonces, ¿por qué no sucedió?

¿Qué salió mal?

Mirando hacia atrás en todo el proceso, ambos lados del evento se culpan mutuamente. Los desarrolladores principales de Ethereum (así como los autores de EIP-3074) creen que es culpa de los "partidarios de 4337" porque no participaron activamente en el proceso de discusión de todos los desarrolladores principales (ACD). En este proceso, los EIP deben someterse a largas deliberaciones y, en última instancia, ser aceptados e implementados por equipos de desarrollo de clientes de Ethereum como Geth. Algunos argumentan que durante el período en que se estaba considerando la EIP-3074, "4337 partidarios" podrían haber participado y expresado sus puntos de vista, en lugar de criticarla después de que ya había sido aprobada. Al fin y al cabo, todo el proceso de ACD es transparente, las reuniones están abiertas a todo el mundo y personas como Tim Beiko publican constantemente tweets de resumen después de cada reunión de ACD. Entonces, si los "partidarios del 4337" se preocuparon tanto por el tema, ¿por qué no participaron activa y rápidamente en las reuniones relevantes?

Por otro lado, los miembros principales de 4337 indican que han estado participando en las reuniones de ACD y oponiéndose a 3074 tanto como sea posible, pero los desarrolladores principales de Ethereum no escuchan. En cuanto a los 4337 miembros de la comunidad, muchos se sintieron sorprendidos: muchos pensaron que el 3074 ya estaba muerto, y algunos ni siquiera sabían que era probable que el 3074 fuera aprobado. Muchos señalan que todo el proceso de reuniones de ACD es opaco y no es amigable para aquellos que son "serios" en la comunidad de Ethereum pero no pueden mantenerse al día con las actualizaciones de ACD en tiempo real. Algunos también creen que ACD debería buscar activamente la retroalimentación de las partes interesadas (aquí se refiere a la comunidad 4337).

Sin embargo, creo que ninguna de las partes ha dado en el clavo. Hay cuestiones más profundas detrás de esto, y a menos que abordemos o al menos reconozcamos este problema, seguiremos cayendo en accidentes de gobernanza, seguidos de acusaciones contradictorias de ambos lados, que en última instancia carecen de sentido.

La causa fundamental de los accidentes de gobernanza: la hoja de ruta

Contrariamente a la creencia popular, la causa principal de los accidentes de gobernanza radica en el hecho de que ACD no es la única autoridad de gobernanza para las actualizaciones del protocolo Ethereum; ha sido sustituida por otra autoridad de gobierno. El problema aquí es que, a pesar de tener más influencia que ACD en cuestiones centrales de Ethereum (como AA y escalabilidad), esta otra autoridad de gobernanza rara vez se reconoce. En este artículo, me referiré a este tipo de poder como la "hoja de ruta". Como señalaré a continuación, todo el evento de falla de gobernanza "3074-4337-7702" es un caso en el que el poder de la hoja de ruta existente de Ethereum anula el poder de ACD. Si hablamos de gobernanza, cuando notamos que una fuerza intangible está superando a otra tangible, deberíamos estar extremadamente preocupados porque las cosas intangibles a menudo son difíciles de explicar y no pueden ser fácilmente notadas por muchas personas, por lo que deben ser expuestas.

¿Qué es una hoja de ruta?

Cualquier miembro de la comunidad Ethereum debe haber escuchado a menudo el término "hoja de ruta", ya sea en la "hoja de ruta de ETH2.0" o en el contexto de la "hoja de ruta de AA" relacionada con este evento.

Para ilustrar mi punto, imaginemos una escena en una reunión de ACD en la que los desarrolladores principales están discutiendo cómo escalar Ethereum:

• Desarrollador principal Bob: Apoyo EIP-1234, que propone aumentar la velocidad de los bloques en 10 veces, aumentar el tamaño de los bloques en 10 veces y reducir las tarifas en 100 veces.
• Otros desarrolladores principales: ... ¿Estás loco?

Pensemos en esto. ¿Por qué el equipo central de Ethereum rechazaría lo que propone Bob? Solo está sugiriendo una forma aparentemente razonable de escalar, algo que muchas cadenas públicas como Solana, Aptos, Sui y otras han hecho, logrando un alto TPS. La razón es que este EIP-1234 ficticio contradice la hoja de ruta de escalado "centrada en el rollup" de Ethereum. Esta hoja de ruta enfatiza que, para la descentralización, los usuarios comunes deben poder ejecutar nodos a bajo costo. Por lo tanto, es poco probable que se acepte el EIP-1234 ficticio porque aumentaría significativamente el costo de ejecutar los nodos de Ethereum. Quiero usar este ejemplo para ilustrar que los desarrolladores principales que participan en el proceso de gobernanza de ACD y deciden sobre las actualizaciones del protocolo están guiados por una fuerza de nivel superior, a la que llamo la "hoja de ruta". Actualmente, en torno a la hoja de ruta de Ethereum, hay "hojas de ruta de escalado", "hojas de ruta AA", "hojas de ruta MEV", etc. Colectivamente forman la hoja de ruta general de Ethereum, y los desarrolladores principales deben tomar decisiones basadas en esta base.

Cuando las opiniones de los desarrolladores principales no se alinean con la hoja de ruta

Dado que la hoja de ruta no es una parte formal del proceso de gobernanza de Ethereum, a menudo no hay garantía de que el equipo central se adhiera a ella. Además, no existe un proceso formal para "aprobar" la hoja de ruta, por lo que no todas las hojas de ruta tienen el mismo nivel de "ortodoxia". Los investigadores detrás de la hoja de ruta de Ethereum deben trabajar arduamente para promover su hoja de ruta entre los desarrolladores principales y la comunidad para obtener la "ortodoxia" y el apoyo del equipo de desarrollo central de Ethereum. Con respecto a AA y la abstracción de cuentas, el propio Vitalik ha abogado repetidamente por la hoja de ruta de AA centrada en 4337, pero en general, es principalmente el equipo detrás de 4337, especialmente Yoav y Dror, quienes abogan por la hoja de ruta de AA centrada en 4337 en foros y en reuniones de ACD.

Sin embargo, a pesar de estos esfuerzos, algunos desarrolladores del núcleo de Ethereum todavía se oponen firmemente a la hoja de ruta AA centrada en 4337. Creen que 7560 (la versión nativa 4337 que implementarán los clientes de Ethereum en el futuro) es demasiado compleja y no es la única solución viable para el "final del juego AA". Finalmente, la ACD decidió aprobar la propuesta 3074, a pesar de la oposición del equipo 4337, que creía que 3074 fracturaría todo el ecosistema AA. Después de que se aprobara el 3074, toda la comunidad del 4337 reaccionó con fuerza, lo que obligó a los desarrolladores del núcleo de Ethereum a volver a participar en las discusiones sobre el 3074. La discusión llegó entonces a un punto muerto, con los autores de 4337 y 3074 incapaces de persuadirse mutuamente. Vitalik propuso EIP-7702 como una alternativa a la 3074 en el último minuto, que se adapta explícitamente al "final del juego de AA" centrado en 4337, resolviendo así el conflicto y alineando el resultado final con la hoja de ruta de AA.

El papel de Vitalik: el CTO de facto de Ethereum

A pesar de que Vitalik se identifica a sí mismo como un investigador, la historia anterior indica claramente que Vitalik tiene poderes de gobierno distintos a los de otros investigadores. Entonces, surge la pregunta: ¿Qué papel juega Vitalik en la gobernanza de Ethereum? Personalmente, creo que no sería inapropiado considerar a Vitalik como el CTO de facto de una empresa muy grande (por cierto, asumiendo a Ethereum como una "empresa" sin un CEO que se alinee con la realidad). Si alguna vez has trabajado en una empresa de tecnología con más de 50 empleados, sabrás que el CTO no puede participar en todas las decisiones técnicas. A medida que la empresa crece, los procesos de toma de decisiones para diversas soluciones técnicas se descentralizan inevitablemente: por lo general, cada área del producto/negocio de la empresa tiene un equipo dedicado, que a menudo tiene la autonomía para decidir sobre los detalles de la solución. Además, es posible que el CTO no sea el principal experto en todos (o ninguno) de los temas. Puede haber ingenieros dentro de la empresa que sean mejores en áreas específicas que el CTO, por lo que en las discusiones sobre los detalles técnicos de las soluciones, a menudo son los ingenieros individuales los que toman las decisiones finales. Sin embargo, el CTO establece la visión técnica de la empresa. La ejecución de la visión se deja en manos de los desarrolladores. Si bien esta no es una analogía perfecta, creo que encapsula razonablemente el papel de Vitalik en el ecosistema Ethereum. Vitalik no participa en todas las decisiones técnicas, posiblemente no podría. Tampoco es el mejor experto en todos los dominios. Pero tiene una influencia abrumadora en el establecimiento de la hoja de ruta para todas las soluciones cruciales de Ethereum (escalado, AA, POS...), no solo por su experiencia técnica, sino también porque es el juez final de si la hoja de ruta se alinea con la visión de Ethereum (su visión).

Todo producto exitoso comienza con una visión

Si considerar a Vitalik como CTO de Ethereum no es lo suficientemente controvertido, aquí está la parte más controvertida: deberíamos aceptar a Vitalik como CTO. Como fundador de una startup, creo que todo producto exitoso debe tener una visión coherente a largo plazo: sí, Ethereum también es un "producto" porque resuelve problemas reales para usuarios reales. Una visión coherente debe ser elaborada por unas pocas personas, como los fundadores de una startup, y por lo general, solo hay un fundador. La belleza de Ethereum es que, a pesar de ser un sistema extremadamente complejo con tantos componentes, todos estos componentes se unen a la perfección para formar una computadora descentralizada que funciona bien, liquidando transacciones por valor de miles de millones de dólares todos los días. Hemos llegado hasta aquí no a través de los esquemas de diseño de algún comité, sino porque Vitalik, con su previsión y perspicacia, ha proporcionado activamente el liderazgo, lo que nos ha permitido construir el Ethereum coherente y elegante de hoy. Ethereum es la idea que Vitalik propuso en 2015, y lo sigue siendo. Por supuesto, esto no es para disminuir las contribuciones de otros investigadores e ingenieros, ya que han logrado la mayor parte de los logros de Ethereum en la actualidad. Sin embargo, esto no es contradictorio, porque Ethereum es la realización de la visión de Vitalik, magnitudes más grandes que la visión de cualquier otra persona. Honestamente, ¿puedes quejarte de esto? Cuando te sientes atraído por la apertura, la resistencia a la censura y la velocidad de innovación del ecosistema Ethereum, ¿alguna vez te has quejado de que se deriva de la visión de Vitalik? Tal vez no te has quejado porque no lo has pensado de esta manera, pero ahora que lo haces, ¿te importa este tema?

¿Cómo abordar la descentralización?

Pero te preguntarás, ¿qué pasa con la descentralización? Si una persona tiene un poder tan abrumador sobre Ethereum, ¿cómo podemos decir que está descentralizado? Para responder a esta pregunta, debemos revisar el artículo clásico de Vitalik sobre el significado de la descentralización. Las ideas clave del artículo son que la descentralización se presenta en tres tipos:

• Descentralización arquitectónica: ¿Cuántos nodos pueden fallar antes de que el sistema deje de funcionar?
• Descentralización lógica: ¿Pueden los distintos subsistemas del sistema desarrollarse de forma independiente sin dejar de trabajar juntos de forma cohesiva?
• Descentralización política: En última instancia, ¿cuántas personas u organizaciones controlan el sistema?

De acuerdo con estas definiciones, Ethereum está claramente descentralizado desde el punto de vista arquitectónico, y se podría argumentar que está lógicamente descentralizado porque sus componentes carecen de un fuerte acoplamiento (por ejemplo, entre la capa de consenso y la capa de ejecución). En cuanto a la descentralización política, la buena noticia es que ningún individuo u organización puede cerrar Ethereum, ni siquiera Vitalik. Sin embargo, algunos podrían argumentar que el nivel de descentralización política de Ethereum no es tan alto como se imagina porque Vitalik desempeña un papel importante en la configuración de la visión y la hoja de ruta de Ethereum.

Sin embargo, creo que si queremos que Ethereum siga innovando, debemos aceptar a Vitalik como CTO de facto, incluso si eso significa sacrificar cierta descentralización política. Si Ethereum se volviera tan "estancado" como Bitcoin, una cadena de bloques casi inmutable, entonces Vitalik también podría retirarse. Pero antes de llegar a ese paso final, es crucial tener una autoridad respetada por todas las partes, alguien de confianza que tome decisiones técnicas basadas no solo en la superioridad de las soluciones técnicas propuestas, sino también en si estas decisiones se alinean con la visión de Ethereum.

Sin alguien como Vitalik, solo dos resultados son probables, ilustrados vívidamente por la historia en torno a EIP-3074:

El proceso de gobernanza de Ethereum podría caer en un punto muerto sin fin, con partes en conflicto que no estén dispuestas a comprometerse y nadie progrese, como lo demuestra el punto muerto en el debate 3074 antes de que Vitalik interviniera.

O Ethereum podría convertirse en un "Frankenstein" incoherente con el diseño, con 3074 y 4337 posiblemente no cediendo el uno al otro, lo que en última instancia resultaría en la ruptura completa del ecosistema AA en dos espacios paralelos incompatibles.

El papel de la comunidad

Después de las consideraciones anteriores, casi estamos esbozando una mentalidad completa de gobernanza de Ethereum, pero hay una omisión obvia en nuestra discusión hasta ahora: la comunidad. Si Vitalik define la visión de Ethereum, los investigadores definen la hoja de ruta y los desarrolladores principales implementan la hoja de ruta, entonces, ¿qué papel juega la comunidad? Seguramente, no es solo quedarse inactivo, ¿verdad? Afortunadamente, la comunidad juega el papel más crucial. La razón es que, antes de que haya una visión, hay valores. Nos unimos como comunidad porque nos unimos en torno a ciertos valores, y la visión de Vitalik debe alinearse en última instancia con estos valores para conservar el apoyo de la comunidad. Todos en la comunidad Ethereum creen que tener una computadora descentralizada accesible para todos, sin censura y neutral en cuanto a la confianza es beneficioso para el mundo. Defendemos y afirmamos estos valores todos los días a través del trabajo que hacemos en Ethereum, legitimando así la visión, la hoja de ruta y el código establecidos por Vitalik, los investigadores y los desarrolladores principales.

El modelo VVRC de gobernanza de Ethereum

Por lo tanto, aquí está la mentalidad completa de la gobernanza de Ethereum, abreviada como VVRC:

• V==Valores==Comunidad;
• V==Visión==Vitalik;
• R==Hoja de ruta==Investigadores;
• C==Cliente==Desarrollador principal;

Juntos desempeñan las siguientes funciones:

• La comunidad se reúne en torno a valores específicos.
• Vitalik articula una visión coherente con estos valores.
• Los investigadores formulan una hoja de ruta basada en la visión.
• Los desarrolladores principales implementan clientes en función de la hoja de ruta.

Por supuesto, la realidad es mucho más compleja de lo que cualquier modelo simple puede capturar. Los desarrolladores principales de Ethereum son los únicos que realmente pueden "votar" sobre cualquier propuesta alterando el código del cliente. Vitalik y otros investigadores sirven como asesores, y a veces sus opiniones no son aceptadas por los desarrolladores principales, que es precisamente la razón por la que se aprobó EIP-3074. Sin embargo, creo que el modelo VVRC captura razonablemente el modo operativo de la gobernanza de Ethereum en circunstancias normales, y necesitamos "depurar" este proceso para evitar que accidentes como el EIP-3074 vuelvan a ocurrir.

Cómo mejorar el modelo de gobernanza de Ethereum

Ahora que tenemos un modelo mental de cómo funciona el proceso de gobernanza de Ethereum, aquí hay algunas ideas para mejorar los procesos de gobernanza:

Debe aumentarse la visibilidad de los avances en el debate sobre las EIP que se están examinando. Toda la comunidad no debería estar "sorprendida" por la aceptación de un EIP, y las aprobaciones inesperadas como EIP-3074 no deberían repetirse. El "estado" actual de los EIP en el sitio web de EIP no refleja su estado en el proceso de ACD. Esta es la razón por la que todavía dice que EIP-3074 está "bajo revisión", a pesar de que los desarrolladores principales han votado para aprobarlo, sin ninguna indicación de que alguna vez se haya considerado para su aprobación desde el principio. Idealmente, cuando un EIP está a punto de ser aceptado, la Fundación Ethereum debería hacer un anuncio público definitivo en las redes sociales para crear conciencia dentro de la comunidad.

A veces, los desarrolladores principales pueden subestimar el impacto de EIP específicos en proyectos y usuarios posteriores, como fue el caso de las comunidades 3074 y 4337. Debido al tiempo limitado de las reuniones del ACD y a la necesidad de coordinación entre zonas horarias, a menudo sólo el "personal pertinente" puede hacer uso de la palabra en las reuniones. No obstante, de vez en cuando tendría sentido dedicar un tiempo de intervención a los miembros de la comunidad para que comenten el impacto de determinadas propuestas de EIP en los proyectos posteriores a su aprobación. Si los investigadores sienten que sus opiniones no han sido aceptadas por los desarrolladores principales, como fue el caso de 4337, pueden invitar a los miembros de la comunidad a reforzar sus argumentos.

Es crucial que los desarrolladores e investigadores principales reconozcan mutuamente que, a pesar de las diferencias de poder, ambos forman parte de la autoridad de gobernanza de Ethereum. Los desarrolladores principales tienen el poder de cambiar y actualizar los clientes de Ethereum, que es la única forma de realizar cambios en el protocolo en sí y "votar". Los investigadores suelen tener más apoyo público para los cambios e interpretaciones de la hoja de ruta, gracias a su discusión activa y a la redacción de sus ideas.

Cuando estas dos fuerzas chocan, los desarrolladores principales pueden tender a anular directamente las opiniones de los investigadores, como fue el caso del equipo 4337. Sin embargo, tal vuelco puede conducir a conflictos, ya que la inestabilidad surge cuando las dos fuerzas chocan, como lo demuestran los dramáticos acontecimientos que siguieron a la aprobación de la EIP-3074.

Del mismo modo, cuando se enfrentan a la resistencia, los investigadores pueden tender a renunciar a la colaboración con los desarrolladores principales. En mi opinión, esta es también una de las razones para crear el proceso RIP y por qué el AA nativo (7560) ahora se promueve principalmente como RIP en lugar de EIP.

Si bien experimentar con actualizaciones de protocolo en L2 que son controvertidas para L1 tiene sus beneficios, no podemos ver RIP como un sustituto de la participación en el proceso de gobernanza de EIP. Los investigadores deben continuar colaborando con los desarrolladores principales hasta que los valores de ambas partes se alineen completamente con la hoja de ruta.

Conclusión

El incidente 3074/7702 reveló el verdadero funcionamiento de la gobernanza de Ethereum: además del poder de gobernanza explícito impulsado por los procesos EIP/ACD de los desarrolladores principales, también hay un poder de gobernanza implícito impulsado por la hoja de ruta impulsada por los investigadores. Cuando estos poderes están desalineados, vemos un punto muerto y una insistencia, y otra fuerza, Vitalik, puede necesitar intervenir de alguna manera para alterar el equilibrio.

A continuación, proponemos que Vitalik representa una fuerza única, a saber, la "visión" de Ethereum, que forma la base de la legitimidad de cualquier hoja de ruta. Comparamos a Vitalik con un CTO de una gran empresa y reconocemos que su papel como pseudo-CTO es necesario para que Ethereum mantenga su ritmo de innovación, evitando que Ethereum se convierta en un "Frankenstein", como un monstruo remendado.

Por último, presentamos el modelo VVRC, describiendo el modelo de gobernanza de Ethereum: Valores (Comunidad) ⇒ Visión (Vitalik) ⇒ Hoja de Ruta (Investigadores) ⇒ Cliente (Desarrolladores principales). A continuación, proponemos varios métodos para "depurar" los "fallos" de este modelo.

La gobernanza de Ethereum es una "máquina de fabricación de máquinas": para que Ethereum funcione correctamente, debemos gobernarla correctamente.

Renuncia:

1. Este artículo es una reimpresión de [极客 Web3]. Reenvíe el título original 'Reflexiones sobre la gobernanza de Ethereum después de la saga 3074'. Todos los derechos de autor pertenecen al autor original [Derek Chiang, CEO de ZeroDev]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.