Vitalik y Yoav amablemente revisaron esta publicación, pero las opiniones son mías.

Si no has estado siguiendo el drama de AA, aquí hay un resumen rápido:

• Hace varias semanas, EIP-3074, una propuesta que traería muchos de los beneficios de AA a los usuarios de EOA, fue aprobada por los desarrolladores principales para entrar en "Pectra", el próximo fork duro de Ethereum.
• Desde entonces, muchos en la comunidad ERC-4337, especialmente los propios autores de 4337, han estado fuertemente rechazando 3074, sobre la base de @yoav/3074-implications"> preocupaciones de centralización y su incompatibilidad con las preocupaciones de Ethereum @yoav/AA-roadmap-May-2024">AA roadmap, que se centra en 4337 y su primo 7560 (también conocido como "AA nativo").
• La semana pasada, Vitalik propuso EIP-7702 como alternativa a 3074. En su mayoría, logra el mismo objetivo: brindar muchos beneficios de AA a los usuarios de EOA, pero de una manera que es más compatible con 4337 hoy en día y compatible con el "final de AA" que es 7560.
• En este momento, los desarrolladores centrales están deliberando sobre EIP-7702, pero las discusiones preliminares y los sentimientos de la comunidad sugieren que EIP-7702 probablemente reemplazará a EIP-3074 en Pectra.

Personalmente, quedé muy contento con el resultado: los usuarios de EOA pronto podrán disfrutar de la mayoría de los beneficios de AA, utilizando las herramientas y la infraestructura construidas para ERC-4337.

Y, sin embargo, no puedo dejar de sentir que la forma en que logramos este resultado distó mucho de ser óptima, una opinión que muchos habían expresado en las últimas semanas. Creo que con un mejor proceso, podríamos haber ahorrado colectivamente una enorme cantidad de energía y dolor de cabeza, y haber llegado al resultado deseado mucho antes.

En esta entrada del blog, quiero:

• Identifique lo que salió mal con el proceso.
• Proponer un modelo mental para pensar en la gobernanza de Ethereum.
• Sugerir mejoras para evitar fallos de gobernanza similares en el futuro.

Por qué el proceso hizo infeliz a la gente

Toda esta saga hizo infeliz a mucha gente por varias razones:

• Tuvieron que pasar años para que se aprobara la 3074.
• Solo después de que 3074 fuera finalmente aprobado, los desarrolladores principales recibieron una gran cantidad de rechazos de la comunidad 4337.
  • Los propios autores de 4337, por otro lado, habían expresado repetidamente sus preocupaciones con 3074 a los desarrolladores principales, sin éxito.
• Ahora estamos en camino de anular la aprobación 3074 y reemplazarla con otra EIP (7702).

Ahora, no hay nada inherentemente malo con nada de lo anterior:

• Está bien que una discusión dure años.
• Está bien que un EIP reciba devoluciones después de que se apruebe.
• Está bien anular la aprobación de un EIP después de su aprobación, si se identifican nuevos problemas.

Sin embargo, probablemente estemos de acuerdo en que las cosas podrían haber ido mejor. Imagínate si así fue:

• La comunidad de 4337 involucró activamente a los desarrolladores principales mientras debatían sobre 3074. Ahora, solo uno de dos resultados es posible:
  • O 3074 fue aprobado (y posiblemente modificado) después de tomar en cuentas los comentarios de la comunidad 4337, en cuyo caso la comunidad 4337 habría estado a bordo con 3074 y no estaríamos revirtiendo 3074.
  • O bien, 3074 nunca se aprobó, pero la comunidad 4337 y los desarrolladores principales trabajaron juntos hacia una propuesta con la que todos están contentos, al estilo 7702.

Se escucha la voz de todos y no hay cambios dramáticos. Eso habría sido bueno, entonces, ¿por qué no sucedió?

Qué salió mal?

Reflexionando sobre el proceso, ambos lados del debate se han señalado mutuamente.

Los desarrolladores principales (y autores de EIP-3074) sintieron que era culpa de las "4337 personas" que no se involucraran activamente con el proceso de todos los desarrolladores principales (ACD), donde los EIP se deliberan durante un largo tiempo antes de que finalmente sean aceptados por los equipos del cliente y, por lo tanto, implementados en el protocolo.

En cualquier momento durante esta deliberación, dice el argumento, las "4337 personas" podrían haber entrado y expresado sus preocupaciones, en lugar de esperar hasta después de que la 3074 ya hubiera sido aprobada. Después de todo, el proceso de ACD está bien documentado, las reuniones están abiertas a todos, y hay personas como Tim Beiko que tuitean activamente resúmenes después de cada reunión de ACD. Entonces, si las personas 4337 se preocuparon tanto por este tema, ¿por qué no dedicaron tiempo a participar?

Por otro lado, el equipo de AA (4337 autores) señaló que habían estado asistiendo a las reuniones de ACD y rechazaron 3074 cada vez que pudieron, pero los desarrolladores principales no escucharon. En cuanto a la comunidad 4337, en su mayoría se sintieron sorprendidos: la mayoría de las personas tenían la impresión de que 3074 estaba muerto, y ni siquiera sabían que 3074 estaba siendo considerado activamente para su inclusión.

Muchas personas también sintieron que el proceso de ACD era demasiado opaco y poco amigable para las participaciones de personas que tienen "trabajos reales" y no podían permitirse mantenerse al día con todas las actualizaciones de ACD. Algunos también consideraron que debería ser responsabilidad del ACD buscar activamente la retroalimentación de las partes interesadas relevantes, en este caso la comunidad 4337.

Sin embargo, en mi opinión, ambas partes no dieron en el blanco. Hay un problema mucho más profundo en juego, y hasta que no solucionemos o al menos reconozcamos el problema, seguiremos encontrándonos con fallas de gobernanza seguidas de acusaciones improductivas.

The Root Cause

La verdadera causa del fracaso de la gobernanza fue que, contrariamente a las creencias populares, el ACD NO es el único poder de gobierno para protocolo actualizaciones, y en este caso fue anulado por otro poder de gobierno.

Problemáticamente, el otro poder de gobierno rara vez se reconoce, a pesar del hecho de que tiene una influencia aún mayor que ACD en los asuntos más importantes de Ethereum, como AA y escalado.

En este artículo, voy a llamar a este poder "hojas de ruta".

Toda esta saga 3074/7702, como argumentaré, es ni más ni menos que un ejemplo del poder de las hojas de ruta que superan el poder de ACD. Y si estamos hablando de gobernanza, entonces cada vez que notamos que un poder invisible abruma a un poder visible, deberíamos estar muy preocupados, porque lo que es invisible no tiene que rendir cuentas y, por lo tanto, debe salir a la luz.

¿Qué es una hoja de ruta?

Cualquiera en la comunidad Ethereum debe haberse encontrado mucho con el término "hoja de ruta", como en la "hoja de ruta centrada en el rollup", "ETH 2.0 hoja de ruta" o en este debate "@yoav/AA-roadmap-May-2024">la hoja de ruta de AA".

Una búsqueda de "hoja de ruta" en Ethereum Magicians

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

• Core Dev Bob: Me soporte EIP 1234 que propone que aceleremos tiempo del bloque 10 veces, aumentemos el tamaño del bloque 10 veces y Soltar tarifa 100X.
• Otros desarrolladores principales: ... ¿Estás loco

Pensemos por un segundo. ¿Por qué los desarrolladores principales simplemente rechazaron lo que dijo Bob? Acaba de proponer una forma muy legítima de escalar. Solana y muchos otros L1 lo hacen, con grandes efectos de escalado.

La razón, por supuesto, es que esta EIP imaginaria va en contra de la propia hoja de ruta de escalado de Ethereum < href="https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698">""rollup-centric", que dice, entre otras cosas, que es crucial para la descentralización de la cadena de bloques que los usuarios normales puedan ejecutar un nodoy, por lo tanto, el EIP imaginario está fuera de discusión, ya que aumentaría enormemente la barrera para ejecutar un nodo.

Lo que quería ilustrar con este ejemplo es que los desarrolladores principales, que participan en el proceso de ACD y deciden sobre las actualizaciones del protocolo, están guiados por una fuerza superior que llamo las hojas de ruta. Está la hoja de ruta de escalado, la hoja de ruta de AA, la hoja de ruta de MEV, lo que sea, y colectivamente forman la hoja de ruta de Ethereum en la que los desarrolladores centrales basan sus decisiones.

Cuando los desarrolladores principales no están alineados con una hoja de ruta

Dado que las hojas de ruta no son una parte formal de la gobernanza, no hay garantía de que los desarrolladores principales estén alineados con ellas. En particular, dado que no existe un proceso formal para "aprobar" una hoja de ruta, no todas las hojas de ruta se perciben con la misma legitimidad. Depende de los investigadores detrás de las hojas de ruta defender diligentemente sus hojas de ruta a los desarrolladores principales y a la comunidad en general, en orden para ganar legitimidad y, por lo tanto, la aceptación de los desarrolladores principales.

En el caso de AA, el propio Vitalik ha impulsado una hoja de ruta de AA centrada en 4337 en @vbuterin/cuenta_abstraction_roadmap">multiple ocasiones, pero en general ha sido principalmente el equipo de 4337, en particular Yoav y Dror, quienes defienden la hoja de ruta de AA centrada en 4337 en conferencias, foros en línea y reuniones de ACD.

Sin embargo, a pesar de estos esfuerzos, hubo fuertes oposiciones por parte de algunos desarrolladores principales en contra de la hoja de ruta de AA centrada en 4337. Sintieron que 7560, la versión nativa de 4337 que los clientes eventualmente tendrían que implementar, es demasiado compleja y no es la única candidata viable para el "final del juego AA". Finalmente, el ACD decidió aprobar el 3074 a pesar de las objeciones del equipo del 4337 de que fragmentaría el ecosistema AA mediante la creación de una alternativa y @yoav/3074-implications">menos pila tecnológica AA descentralizada.

Sin embargo, una vez que se aprobó el 3074, hubo una fuerte reacción de toda la comunidad del 4337, lo que obligó a los desarrolladores principales a volver a participar en el debate del 3074. El debate entonces se convirtió en un punto muerto en el que ni los 4337 autores ni los 3074 autores podían convencerse mutuamente, hasta que Vitalik entró en el último momento y propuso EIP-7702 como una alternativa a 3074 que es explícitamente compatible con el "final de AA" centrado en 4337, y por lo tanto empujando el conflicto a favor de la hoja de ruta de AA.

El papel de Vitalik

A pesar de que Vitalik se comporta como investigador, esta saga muestra claramente que Vitalik aporta un poder de gobierno cualitativamente diferente al de otros investigadores. Así que surge la pregunta: ¿qué papel juega Vitalik en la gobernanza de Ethereum?

Personalmente, me resulta útil pensar en Vitalik como el CTO de una empresa muy, muy grande.

(Para el propósito de esta analogía, no hay un CEO en esta empresa, por cierto).

Si ha trabajado en cualquier empresa de tecnología con más de, digamos, 50 personas, sabe que el CTO no puede estar involucrado en todas las decisiones técnicas. A cierta escala, las decisiones técnicas necesariamente se descentralizan: normalmente hay un subequipo para cada área del producto de la empresa, y el subequipo es en su mayoría libre para tomar sus propias decisiones con respecto a detalles específicos de implementación.

Además, el CTO tampoco es necesariamente el principal experto en todos (o ninguno) tema. Podría muy bien haber ingenieros en una empresa que sean mejores que el CTO en áreas específicas. Por lo tanto, en cuestiones de debates técnicos, a menudo son los ingenieros los que toman las decisiones finales.

El CTO, sin embargo, 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 captura razonablemente el papel de Vitalik en el ecosistema. Vitalik no está involucrado en todas las decisiones técnicas, no puede estarlo. Tampoco es el máximo experto en todas las áreas. Pero tiene una influencia abrumadora en el establecimiento de las hojas de ruta para todos los aspectos críticos de Ethereum (escalado, AA, Proof-of-Stake ...), no solo por su experiencia técnica, sino también porque es el juez final de si una hoja de ruta es consistente con la visión de Ethereum: su visión.

Todo producto exitoso comienza con una visión

Si mi opinión de que Vitalik es el CTO de Ethereum no es lo suficientemente controvertida para ti, aquí viene la parte más controvertida: deberíamos aceptar a Vitalik como el CTO.

Es mi opinión como fundador de una startup que detrás de cada producto exitoso, y sí, Ethereum es un "producto" en el sentido de que resuelve problemas reales para personas reales, debe haber una visión coherente. Y una visión coherente debe ser necesariamente establecida por un pequeño número de personas, como los fundadores de una startup, y a menudo solo un fundador.

La belleza de Ethereum es que, a pesar de ser un sistema tan complejo con tantas partes móviles, las partes encajan maravillosamente en una computadora descentralizada en funcionamiento que mueve miles de millones de dólares en valor todos los días. Y la forma en que llegamos aquí no fue a través del diseño de comités. Es precisamente gracias al liderazgo activo de Vitalik a través de su visión que podemos llegar a un producto coherente y hermoso que es Ethereum hoy. Ethereum fue una creación de Vitalik en 2015, y sigue siéndolo hoy.

Esto no es, por supuesto, para restar importancia a las contribuciones de otros investigadores e ingenieros, que merecen la mayoría de los créditos por llevar a Ethereum a donde está hoy. Sin embargo, eso no es incompatible con el hecho de que Ethereum es una realización de la visión de Vitalik, órdenes de magnitud más que la de cualquier otra persona.

Y la verdad, ¿te puedes quejar? Cuando se sintió atraído por el ecosistema Ethereum por su apertura, resistencia a la censura y ritmo de innovación, ¿se quejó de que comenzó con la visión de Vitalik? Tal vez no lo hiciste porque no lo pensaste de esa manera, pero ahora que lo haces, ¿realmente te importa?

¿Qué pasa con la descentralización?

Pero, pero, dices, ¿qué pasa con la descentralización? Si una persona tiene un poder tan abrumador sobre Ethereum, ¿cómo podemos afirmar que está descentralizado?

Para responder a esta pregunta, debemos volver a @VitalikButerin/the-meaning-of-de-descentralization-a0c92b76a274">este artículo clásico sobre el significado de la descentralización, escrito por, tos, tos, Vitalik. La idea clave del artículo es que hay tres tipos de descentralización:

• Descentralización arquitectónica: ¿cuántos nodos pueden verse comprometidos antes de que el sistema deje de funcionar?
• Descentralización lógica: ¿pueden los subsistemas del sistema evolucionar de forma independiente manteniendo el sistema en funcionamiento? ¿O deben estar estrechamente coordinados?
• Descentralización política: ¿cuántas personas u organizaciones controlan finalmente este sistema?

Dadas estas definiciones, Ethereum está claramente descentralizado arquitectónicamente, y probablemente sea justo decir que también está lógicamente descentralizado, dada la falta de un fuerte acoplamiento entre sus diversos componentes (por ejemplo, consenso vs ejecución).

En términos de descentralización política, la buena noticia es que ningún individuo u organización puede cerrar Ethereum, ni siquiera Vitalik. Sin embargo, se podría argumentar que Ethereum no está tan descentralizado políticamente como se podría pensar, dado el papel destacado que desempeña Vitalik en el establecimiento de su visión y, por lo tanto, en la definición de sus hojas de ruta.

Sin embargo, es mi opinión que si queremos que Ethereum siga innovando, debemos abrazar a Vitalik como el CTO de facto, incluso si eso significa sacrificar algo de descentralización política.

Si Ethereum alguna vez se "osifica" en una cadena de bloques en su mayoría inmutable como Bitcoin, entonces Vitalik podría retirarse. Pero antes de llegar a ese final, es fundamental que haya una autoridad que todas las partes respeten, en quien se confíe para tomar decisiones técnicas no basadas solo en méritos técnicos, sino también en si son consistentes con la visión de Ethereum.

Sin una figura como Vitalik, solo dos resultados son posibles, ambos vívidamente ilustrados por esta saga de 3074:

• La gobernanza de Ethereum podría disolverse en interminables atascos donde ninguna de las partes está dispuesta a comprometerse y nadie podría avanzar, como se ve por cómo el debate 3074 estaba en un punto muerto hasta que entró Vitalik.
• O bien, Ethereum podría terminar convirtiéndose en un monstruo Frankenstein de diseños incoherentes, como lo indica lo cerca que estábamos de tener 3074 y 4337 sirviendo como dos pilas AA paralelas que son en gran medida incompatibles.

El papel de la comunidad

Estamos muy cerca de tener un modelo mental completo de Ethereum gobernanza, pero hay una omisión flagrante en nuestra discusión hasta ahora: la comunidad.

Si Vitalik define la visión, que son seguidas por hojas de ruta definidas por los investigadores, que a su vez son implementadas por los desarrolladores principales, ¿qué papel juega la comunidad? Seguramente no nada??

Afortunadamente, la comunidad juega el papel más importante de todos. La razón es que incluso antes de que haya una visión, hay valores. Todos nos unimos como comunidad porque nos unimos en torno a ciertos valores, con los que, en última instancia, la visión de Vitalik debe ser coherente, o perdería la comunidad.

Tal vez fue tu educación. Tal vez fue algo que sucedió en tu último trabajo. Pero en un momento u otro, todos los que formamos parte de la comunidad Ethereum decidimos que sería bueno para el mundo tener un ordenador descentralizado que fuera accesible para todos, que no pudiera ser censurado, que fuera creíblemente neutral. Afirmamos y afirmamos estos valores todos los días con el trabajo que hacemos sobre Ethereum, y al hacerlo proporcionamos legitimidad a la visión, las hojas de ruta y el código producido por Vitalik, los investigadores y los desarrolladores principales.

El modelo VVRC de gobernanza Ethereum

Así que aquí, entonces, hay un modelo mental completo para la gobernanza de Ethereum, que estoy llamando los valores ⇒ visión ⇒ hojas de ruta ⇒ modelo de clientes, o VVRC para coro:

• V == Valores == Comunidad
• V == Visión == Vitalik
• R == Hojas de ruta == Investigadores
• C == Clientes == Desarrolladores principales

Juntos funcionan así:

• La comunidad se agrupa en torno a ciertos valores.
• Vitalik articula una visión coherente con estos valores.
• Los investigadores elaboran hojas de ruta de acuerdo con la visión.
• Los desarrolladores principales implementan clientes basados en las hojas de ruta.

Mal dibujado por el nuevo GPT-4o.
Se negó a dibujar la palabra "Vitalik" debido a la "política de contenido".

Por supuesto, la realidad es mucho más complicada de lo que cualquier modelo simple puede capturar. Por ejemplo, los desarrolladores principales en realidad son las únicas personas que pueden "votar" en cualquier decisión, en virtud de la implementación de los clientes. Vitalik y otros investigadores solo cumplen un papel consultivo y, a veces, sus aportes no son aceptados por los desarrolladores principales, razón por la cual se aprobó el 3074.

Dicho esto, creo que el modelo VVRC captura razonablemente cómo funciona la gobernanza de Ethereum en el feliz caso, y depende de nosotros "depurar" el proceso para que no falle como lo hizo con 3074.

Cómo podemos mejorar Ethereum gobernanza

Ahora que tenemos un modelo mental de cómo debería funcionar la gobernanza Ethereum, aquí hay algunas ideas para mejorar el proceso de gobernanza para que podamos evitar el tipo de latigazo cervical que experimentamos con 3074/7702.

• Debe haber más visibilidad para los EIP que se están considerando activamente para su inclusión. La comunidad en general nunca debe ser "tomada por sorpresa" de que se acepte un EIP, como fue el caso con 3074.
  • Al contrario de lo que cabría esperar, el "estado" de un EIP en el sitio de EIP no refleja su estado en el proceso de ACD. Es por eso que todavía dice que 3074 está en "Revisión" a pesar de que los desarrolladores principales ya habían votado para aprobarlo, y había aún menos indicios de que alguna vez se estuviera considerando su inclusión en primer lugar.
  • Idealmente, EF lo haría alto y claro en las redes sociales cuando un EIP está a punto de ser aceptado, para aumentar la conciencia de la comunidad.
• A veces, los desarrolladores principales pueden subestimar el impacto que un EIP en particular tiene para los proyectos y usuarios posteriores, que es el caso de 3074 y la comunidad 4337. Dado que las reuniones de ACD tienen un tiempo limitado y deben coordinarse a través de zonas horarias, es comprensible que se haga hincapié en que solo las "personas relevantes" deben hablar en las reuniones. Dicho esto, podría tener sentido asignar algo de tiempo, de vez en cuando, para que los miembros de la comunidad comenten sobre el impacto posterior de ciertas propuestas de EIP.
  • Si los investigadores sienten que sus comentarios no están siendo recibidos por los desarrolladores principales, como fue el caso del equipo 4337, podrían involucrar a los miembros de la comunidad en la llamada para fortalecer su caso.
• Fundamentalmente, debe haber un reconocimiento mutuo entre los desarrolladores principales y los investigadores de que ambos son poderes de gobierno, aunque con diferentes fortalezas. El "poder del cliente" de los desarrolladores principales es el único poder que realmente puede "votar" en virtud de los clientes implementadores. El "poder de la hoja de ruta" de los investigadores suele gozar de una mayor soporte pública gracias a que los investigadores hablan y escriben activamente sobre sus hojas de ruta.
  • Cuando los dos poderes están en desacuerdo, puede ser tentador para los desarrolladores principales simplemente anular a los investigadores, como cuando los desarrolladores principales anularon las objeciones del equipo 4337. Sin embargo, la anulación como tal puede resultar en un latigazo cervical, ya que los poderes son inestables cuando están en conflicto, como se ve en el drama posterior después de que se aprobara la 3074.
  • Del mismo modo, cuando se enfrentan a resistencia, puede ser tentador para los investigadores simplemente renunciar a comprometerse con los desarrolladores principales, lo que en mi opinión es una de las razones por las que se creó el proceso RIP y por qué el AA nativo (7560) ahora se impulsa principalmente como un RIP, no como un EIP. Si bien existen beneficios reales al ayudar a las L2 a experimentar con actualizaciones de protocolos que son demasiado controvertidas para las L1, no podemos ver a los RIP como un sustituto de la participación en el proceso de gobernanza de EIP. Los investigadores deben seguir interactuando con los desarrolladores principales hasta que estén completamente alineados con las hojas de ruta.

Conclusión

La saga 3074/7702 arroja luz sobre cómo funciona realmente la gobernanza Ethereum, que además del poder de gobernanza explícito que es el proceso de EIP/ACD impulsado por los desarrolladores centrales, también existe el poder de gobernanza implícito de las hojas de ruta impulsadas por los investigadores. Cuando estos poderes se desalinean, vemos atascos y latigazos cervicales, y podría ser necesario otro poder, Vitalik, para inclinar la balanza hacia un lado u otro.

Luego argumentamos que Vitalik representa un poder distinto que es la "visión" de Ethereum, que es la base de legitimidad para cualquier hoja de ruta. Comparamos a Vitalik con el CTO de una gran empresa, y reconocemos que su papel como pseudo-CTO es necesario para que Ethereum mantenga su ritmo de innovación, sin degenerar en un sistema Frankenstein de diseños incoherentes.

Finalmente, presentamos un modelo mental para pensar la gobernanza Ethereum como VVRC: valores (comunidad) ⇒ visión (Vitalik) ⇒ hojas de ruta (investigadores) ⇒ clientes (core devs). A continuación, sugerimos varias formas de corregir los "errores" que a veces hacen que el proceso se desvíe de este modelo en la práctica.

Ethereum gobernanza es "la máquina que construye la máquina": para hacer Ethereum bien, debemos hacer que la gobernanza sea correcta. Como tal, 3074 proporcionó un estudio de caso invaluable para cuando la gobernanza salió mal, y espero haber podido extraer algunas lecciones útiles para que podamos mejorar la gobernanza de Ethereum para el futuro.

Disclaimer:

1. Este artículo es una reimpresión de [zerodev]. Todos los derechos de autor pertenecen al autor original [derek]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos se encargarán de ello con prontitud.
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.