Explicación de la gobernanza del núcleo de Ethereum

Una presentación de Nixo Rokish de la Fundación Ethereum en ETHBoulder, que explica la gobernanza del protocolo del núcleo de Ethereum, cómo se coordinan las bifurcaciones duras, los conceptos erróneos comunes sobre quién controla Ethereum y cómo participar en el proceso de gobernanza.

Esta transcripción es una copia accesible de la transcripción original del video (opens in a new tab) publicada por EthBoulder. Ha sido ligeramente editada para facilitar su lectura.

Introducción (0:12)

Gracias a mis seis amigos que vinieron. Muy bien. Hoy les hablaré sobre la gobernanza del núcleo de Ethereum. Mi nombre es Nixo. Dirijo el equipo de soporte del protocolo en la EF (Fundación Ethereum). Entre todos nuestros mandatos, uno de ellos es hacer que el proceso de gobernanza sea más claro y fácil de navegar para todos los demás que participan en estas cosas, porque Ethereum incluye mucho más que solo a sus desarrolladores del núcleo.

Así que aquí hay un resumen de la charla. Vamos a hablar sobre qué es la gobernanza del núcleo. Hablaremos sobre los conceptos erróneos y cómo funciona actualmente la gobernanza de Ethereum. Tocaremos cómo se compara con otros sistemas de gobernanza descentralizada, por qué a los constructores les importaría y las vías de acción para participar.

Entonces, ¿qué es la gobernanza del protocolo del núcleo? Yo ejecuto un nodo. Lo que eso significa es que tengo una pieza de hardware, una computadora en mi casa donde ejecuto el software de Ethereum. Cuando configuré este software de Ethereum, tuve que elegir los clientes que iban a ejecutar ese software. Ethereum es un poco único en el sentido de que tiene múltiples clientes para la diversidad de clientes. El objetivo de esto es que si un cliente falla, si hay un error en un cliente, toda la red no se cae. Hay otras cadenas de bloques que tienen otros clientes. Sin embargo, Ethereum es la única que está configurada de una manera que realmente nos protege contra errores. Por lo tanto, si vas a Solana, por ejemplo, Solana tiene otro cliente, creo que se llama GTO, pero solo tiene un 20-21 % de adopción. Así que, si el cliente mayoritario falla, la cadena se cae. Y hemos visto caer a otras redes. Y es por eso que Ethereum es la cadena de bloques más resistente y segura.

Entonces la pregunta es cómo se introducen cambios en Ethereum cuando tienes que coordinar con tantos clientes diferentes. Primero diferenciaremos entre una bifurcación dura y una bifurcación suave. Una bifurcación suave no requiere la coordinación que requiere una bifurcación dura. Ethereum funciona principalmente con bifurcaciones duras. Así que lo que es una bifurcación dura es, básicamente, que todos los clientes construyen una nueva versión de Ethereum y deciden en un momento preconfigurado lanzar esta nueva versión de Ethereum. Sigue siendo Ethereum, pero tiene nuevas características. Tiene características diferentes. Y todos los operadores de nodos como yo, que ejecutamos nodos en casa, o los operadores profesionales, tienen que aceptar esa nueva versión de Ethereum. Tienen que actualizar su nodo o actualizar sus nodos para incluir ese nuevo software.

Entonces, ¿cómo deciden qué características se incluyen en esas bifurcaciones duras? Tienen que acordar prioridades para asignar su tiempo y recursos porque tienen un tiempo y recursos finitos para asignar allí. Priorizan cosas como fallas de seguridad o parches de seguridad, cosas como la experiencia del usuario (UX): si hay otra cadena de bloques que compite con nosotros, necesitamos volvernos competitivos con esas otras cadenas de bloques. Así que una de las cosas que observan es que cualquier característica que se incluya tiene que ser compatible hacia adelante con posibles elementos futuros de la hoja de ruta.

Así que el año pasado ocurrió algo realmente polémico. Puede que hayan oído hablar de ello. Se llamaba EOF. Eso es EVM Object Format (Formato de Objeto de la EVM). Era un conjunto de características que estaba programado para entrar en la bifurcación dura Fusaka —Pectra, Fusaka, creo que ambas— pero se dividió. Y un detonante, entre muchos otros, por el que fue expulsado de esa bifurcación fue porque Vitalik publicó un artículo sobre el potencial de que Ethereum adoptara RISC-V. Muchas de las personas que leyeron eso lo miraron y dijeron: "Vale, si adoptamos RISC-V, las características que estamos viendo en EOF vienen de forma nativa con RISC-V. Entonces, ¿por qué añadiríamos esta complejidad al protocolo? ¿Por qué destinaríamos todos estos recursos de los desarrolladores de clientes a esto?". Sería un punto irrelevante si termináramos pasándonos a RISC-V.

Así que esa fue la gota que colmó el vaso para EOF y terminó siendo expulsado de la bifurcación. Otra cosa que tienen que considerar es que tiene que ser escrito y probado rigurosamente en seis lenguajes diferentes porque estos clientes están escritos en seis lenguajes diferentes. Así que esa es una matriz de pruebas realmente grande con la que tienen que trabajar. Y debido a eso, cada pequeña elección de diseño está sujeta a debate sin ninguna autoridad para resolver los desacuerdos. Así que la pregunta que surge es quién decide, lo cual es el punto crucial de la gobernanza.

Conceptos erróneos (5:23)

Así que eso nos lleva a los conceptos erróneos y abordaremos algunos de ellos. Uno es que Vitalik decide qué entra en el protocolo de Ethereum. Una extensión de eso es que la EF lo controla todo. Y un tercero es que todo son acuerdos a puerta cerrada: personas con información privilegiada, los veteranos (OGs) tomando estas decisiones.

Así que el primero: Vitalik decide. Acabo de elegir un subconjunto de EIP estancadas escritas por Vitalik. Lo que esto significa es que Vitalik se sentó, escribió una propuesta y dijo: "Quiero que estas cosas entren en Ethereum", y nadie estuvo de acuerdo; estas cosas simplemente están ahí paradas. No pudo introducirlas en el protocolo. Así que no todo lo que él propone se incluye automáticamente.

Una extensión de eso es que la Fundación Ethereum lo controla todo. Voy a elegir un ejemplo específico de un momento que creo que contradice eso. En 2024 se habló mucho sobre el límite de gas. Y la razón de ello es que en 2022, durante La Fusión, elevamos el límite de gas a 30 millones. Esa es la computación máxima que se permite en un bloque. Y luego, en cierto modo, no lo tocamos por un tiempo porque no era realmente un cuello de botella por el que la gente dijera: "Por esto no me paso a Ethereum" o "Esto está limitando mi caso de uso actual de Ethereum".

Y a finales de 2023, principios de 2024, existía esta narrativa de que Solana se acercaba. Iba a comerle el terreno a Ethereum. Y así la gente estaba pensando en qué puede hacer Ethereum para acelerar. Y una de las cosas fue: "Vamos a bombear esta métrica de gas". Y en ese momento, la EF y los desarrolladores de clientes decían algo así como: "Tenemos otras cosas de las que preocuparnos. Pero gracias". Sin embargo, estas dos personas, Eric Connor y Mariano Conti, intervinieron y dijeron: "No, vamos a subir el límite de gas". El límite de gas es un parámetro controlado por el validador. Y así, simplemente pudieron empezar a hablar con los validadores, operadores profesionales, y decirles: "Oigan, suban su límite de gas".

Y en algún momento hubo suficiente adopción como para que la EF y los clientes dijeran: "Oh, tenemos que prestar atención a esto. Tenemos que asegurarnos de que lo que están haciendo es seguro y de que el valor al que terminen subiendo esto va a ser algo seguro para la red". Así que tuvieron que reasignar sus recursos. Nethermind ideó este marco de pruebas. La EF hizo un montón de trabajo en Berlín. Todos los desarrolladores de clientes estaban evaluando el rendimiento de esto. Y por eso me gusta esto, porque forzó la mano de la EF a la hora de decidir qué se priorizaba.

Y me gusta este estúpido tuit del que tomé una captura de pantalla aquí porque es como si un medio de noticias cualquiera llamara a Eric Connor y Mariano Conti desarrolladores del núcleo. No son desarrolladores del núcleo. Eric Connor era un participante (staker) y un miembro de la comunidad. Mariano Conti era un antiguo desarrollador de aplicaciones de MakerDAO. Pero simplemente los llamaron desarrolladores del núcleo porque el desarrollo de Ethereum está realmente fuera del mundo de cómo funciona el software tradicional y, por lo tanto, vieron que se modificaba un parámetro central y dijeron: "Oh, estos deben ser desarrolladores del núcleo". No lo eran. Así que este es solo un ejemplo de miembros de la comunidad que intervienen y dicen "queremos ver este cambio" y lo hacen realidad.

Todo son acuerdos a puerta cerrada, personas con información privilegiada, veteranos (OGs): entiendo un poco más por qué esto es un concepto erróneo porque básicamente vienes a estas llamadas de gobernanza, hay cien personas en estas llamadas de gobernanza. Parece que todos están muy cómodos con lo que está pasando. Tú estás perdido. No tienes idea de cómo se toman estas decisiones. Piensas: "¿Ya es mi turno de hablar?". Y da la sensación de que la gente está escuchando a las mismas 10 personas para tomar estas decisiones.

Meritocracia y estadísticas de participación (10:18)

Pero la verdad es que el desarrollo de Ethereum es más una meritocracia de lo que he visto en la mayor parte del desarrollo de software. Todas estas personas en esta captura de pantalla (esta es una de tres en esta llamada ACD aleatoria de la que decidí tomar una captura) ninguna de estas personas fue designada para estar aquí. Todos son simplemente las personas que se presentaron. Son los desarrolladores que han pasado mucho tiempo con este protocolo. Son los que la gente ha reconocido como desarrolladores talentosos en este espacio que toman buenas decisiones de manera constante, y nadie en esto está designado para estar aquí.

Así que me uní a la EF hace poco más de un año. Tomé estas estadísticas. Solo se remontan a marzo de 2025. Así que menos de un año. El promedio de asistentes a All Core Dev (esas son las llamadas de gobernanza) es de 98. Así que, en promedio, hay 98 personas en estas llamadas. El máximo de asistentes en una llamada desde entonces fue de 153. Creo que fue el día en que estábamos decidiendo la fecha de la Red principal de Pectra. Y el total de asistentes únicos es de 567 solo en el último año. Realmente me gusta esa métrica porque demuestra que no son las mismas 100 personas las que asisten a estas llamadas cada vez. Estos desarrolladores de aplicaciones, investigadores, alguien escucha sobre alguna característica que se está discutiendo, se presentan para expresar su oposición o su apoyo y luego no asisten a otra llamada.

Cómo funciona el proceso de gobernanza (11:52)

Así que esta es una diapositiva un poco aburrida, pero creo que es importante repasarla: así es como funciona actualmente la gobernanza de Ethereum. Entonces, cuando se está discutiendo una de estas bifurcaciones, lo primero que sucede es que las personas, durante este período de tiempo asignado, pueden enviar su propuesta principal. La propuesta principal es la característica más importante en torno a la cual queremos que la gente se reúna para esta bifurcación. Puede ser un miembro de la comunidad, un investigador, un desarrollador del núcleo; realmente cualquiera que envíe una de estas propuestas principales. Luego, la ventana termina y en las llamadas de gobernanza discutimos cuál de estas tiene sentido. La gente expone sus argumentos, la gente debate y hay consenso sobre cuál deberíamos elegir para esa próxima bifurcación.

Después de eso, eligen las características menores. Es decir, las cosas más pequeñas que realmente no necesitan ser estas características principales que impulsan la bifurcación. Y durante todo este tiempo tenemos redes de desarrollo específicas para cada característica. Una red de desarrollo es como una red de prueba: una red de prueba privada para que los desarrolladores prueben estas características y se aseguren de que realmente funcionan en Ethereum. Y luego, en algún momento, hay un congelamiento de características. Así que hemos discutido las características principales, hemos discutido las características menores, hemos ejecutado estas redes de desarrollo específicas para cada característica que suelen ser las principales de la bifurcación. Y eso es un congelamiento de características con un asterisco porque en ese momento hemos decidido que no agregaremos más características a esta bifurcación. Vamos a ejecutar todas las características juntas, asegurarnos de que todo esté bien, asegurarnos de que nada se vaya a romper. Pero si algo empieza a ralentizar las cosas, si la bifurcación se retrasa, si es demasiado compleja, todavía se pueden expulsar cosas en ese momento.

Así que después de una serie de redes de desarrollo (podrían ser dos, podrían ser 10), todos los clientes deciden en algún momento que esto es estable. Confiamos en lo que está pasando ahora mismo. Estamos en un buen lugar. Empecemos a pensar en sacar esto a la Red principal de Ethereum. Lanzan versiones de los clientes y luego hay un período de 30 días en el que el equipo de seguridad de la EF publica un programa de recompensas por errores (bug bounty). Contratan auditorías de seguridad. Y luego, al final de ese período de 30 días, lanzamos la bifurcación en las redes de prueba. Estas son redes de prueba de las que quizás hayan oído hablar, como Holesky. Aquí es donde los desarrolladores de aplicaciones pueden probar sus cosas antes de que la bifurcación se active. Y estas generalmente duran un mínimo de 14 días cada una solo para asegurarse de que todo esté bien. No esperamos grandes problemas porque ya ha pasado por redes de desarrollo específicas de características y redes de desarrollo generalizadas antes, pero históricamente ha roto algunas de estas redes de prueba. Y por lo tanto, esta es una especie de última llamada para encontrar y aplastar todos estos errores.

Y luego, una vez que la red de prueba sin permisos es estable, se elige la fecha de la Red principal. Después de eso, hay un margen de 30 días. Este margen de 30 días existe porque las L2 y los protocolos lo han solicitado para prepararse para la bifurcación. Así que eso es un mínimo de 30 días y luego ocurre la bifurcación.

Estructura de llamadas y coordinación (15:01)

Durante todo este tiempo se llevan a cabo algunas series de llamadas principales. Todas estas son llamadas públicas transmitidas en vivo por YouTube. Las principales son ACDE y ACDC. La E es por la capa de ejecución: eso son cosas como transacciones, implementaciones de contratos inteligentes, gestión de la mempool. ACDC es la capa de consenso: así que eso son cosas de validadores como la gestión de validadores, el recorte. Y esas se alternan los jueves. Así que hay una ACD cada jueves y una de ellas es ACDE y luego la siguiente es ACDC, continuando de esa manera.

Las llamadas ACDE y ACDC se centran en la bifurcación que estamos haciendo actualmente y en las bifurcaciones que estamos planificando para el futuro. Las llamadas ACDT son más minuciosas y detalladas. Son los clientes hablando de errores que no pueden superar o detalles de implementación que deben resolverse sobre la bifurcación en la que están trabajando actualmente. Así que ahora mismo la próxima bifurcación que va a ocurrir es Glamsterdam. Por lo tanto, estas llamadas ACDT están dominadas por conversaciones sobre ePBS y listas de acceso a nivel de bloque, que son las cosas que van a entrar en Glamsterdam. Y estas son las llamadas altamente técnicas.

Y luego están las llamadas de trabajo (breakout calls). Las llamadas de trabajo son miembros de la comunidad, investigadores, desarrolladores que dicen: "Oye, tengo una característica que quiero introducir en Ethereum dentro de dos bifurcaciones". Y así organizan estas llamadas semanales, mensuales o bimensuales donde discuten los detalles de implementación, cambian e iteran sobre la especificación y, en general, abordan todas las preguntas que tiene la gente, todas las incógnitas conocidas para asegurarse de que esté en el mejor lugar posible para ser incluida en la bifurcación dentro de dos bifurcaciones. Y esas se pueden programar cuando el facilitador lo decida.

Un proceso en evolución (15:29)

Así que una cosa que quiero dejar clara a todos es que este proceso es cualquier cosa menos estático. Este proceso que les acabo de describir ha estado activo durante menos de un año. Ethereum ha estado activo durante 10 años. Pero cambia constantemente y la razón por la que cambia constantemente es porque nadie está a cargo. Y este proceso evoluciona de alguna manera para descubrir la forma más eficiente de operar. Y digo eficiente, pero la reputación que tiene la gobernanza de Ethereum es de ser realmente estancada, difícil de sacar cosas adelante, confusa; y eso es porque cuando tienes de 100 a 500 personas tomando decisiones, honestamente me impresiona que esto funcione en absoluto.

Así que Tim hizo una publicación en abril de 2025 llamada "Reconfiguring All Core Devs" (Reconfigurando a todos los desarrolladores del núcleo) que terminó siendo la propuesta de cómo funcionan las cosas ahora mismo. Y la razón de ello es porque antes de eso teníamos una especie de narrativa cohesiva sobre en qué deberíamos centrarnos en Ethereum. Estuvo La Fusión, que fue una empresa enorme. Todo el mundo estaba muy emocionado. La mayoría de la gente estaba muy emocionada. Los mineros no. Y luego, después de La Fusión, tuvimos los retiros. Así que no queríamos que la gente tuviera su ETH bloqueado en un contrato y que este FUD (miedo, incertidumbre y duda) fuera como si nunca fueran a sacar el ETH de esto. Así que tuvimos que lanzar eso lo más rápido posible. Y luego estuvo Proto-Danksharding y luego llegó Pectra y Pectra fue una especie de amalgama de diferentes EIP no relacionadas y realmente no tenía una narrativa cohesiva. Y se hizo tan grande porque la gente simplemente estaba metiendo cosas debido a la falta de cohesión, que tuvo que dividirse en dos bifurcaciones diferentes porque los equipos de pruebas decían algo así como: "El alcance es demasiado grande. No podemos probar todo esto".

Y así, el ímpetu de Tim para hacer esto fue: "Vale, tenemos que pensar en una forma de mantener estas bifurcaciones lo más enfocadas y cohesivas posible". Y la propuesta principal fue una especie de respuesta a eso. El objetivo de eso era lanzar de una manera que priorizara hacer sentir que todos sabían de qué se trataba la bifurcación, para que no tuvieran que meter 25 EIP diferentes.

Así que la otra captura de pantalla en la parte superior es Tim proponiendo definiciones para las etapas de inclusión de estas EIP. Y el punto que quiero destacar con esto es que a veces escuchas a la gente decir que este proceso es demasiado burocrático. Pero lo que realmente está sucediendo es que la gente entra en este proceso de gobernanza y dice: "¿Cómo introduzco una EIP?", y las personas que han estado allí durante 10 años dicen: "Simplemente lo haces". Y la gente dice: "Esto es horrible". Y así, lo que hacen estas cosas es describir lo que está sucediendo para facilitar que los forasteros participen en este proceso, porque si acabas de llegar aquí y dices: "Tengo una EIP, no me importa la gobernanza de Ethereum, solo quiero que entre esta EIP", quieres una rúbrica, quieres una lista de verificación, quieres un paso a paso muy claro sobre cómo introducir esta EIP. Por lo tanto, la mayoría de estas cosas se tratan más de describir cómo funciona el proceso que de crear reglas burocráticas que la gente tenga que seguir para dificultar la introducción de EIP.

La tercera cosa son los commits a lo largo del tiempo en Forkcast. Forkcast es un producto de mi equipo, de Wolfram Mark, un chico de mi equipo que creó esto a mediados del año pasado cuando se formó mi equipo en su iteración actual. Y se ha convertido en un recurso tan canónico para que la gente lo use para interactuar con una bifurcación, para ver qué entra en una bifurcación y cómo les afecta. Todas estas cosas tienen menos de dos años. Así que el punto que estoy planteando es que este proceso cambia mucho. No es estático en absoluto. No es una burocracia congelada en la que sea difícil meter un pie.

Sistemas de gobernanza comparables (20:21)

Así que, rápidamente, quería tocar los sistemas de gobernanza descentralizada más similares que puedo ver a la gobernanza de Ethereum. Y el punto que estoy tratando de plantear aquí es que esto es sostenible: aunque es sorprendente que de 100 a 500 personas puedan tomar decisiones, es sostenible en el mundo real. Vemos ejemplos de que esto funciona.

El IETF es el Grupo de Trabajo de Ingeniería de Internet (Internet Engineering Task Force). Es el organismo de estándares dirigido por voluntarios que creó TCP/IP, HTTP. Es la organización más responsable del hecho de que hoy tengamos el internet libre. El núcleo de Linux: es el núcleo del sistema operativo Linux. Así que es software de código abierto que impulsa servidores de internet, teléfonos Android, supercomputadoras. La diferencia allí es que tienen una especie de modelo de dictador benevolente con Linus Torvalds. Pero incluso entonces tienen más de 17.000 colaboradores, lo cual es alucinante.

Cosas a las que esto no se parece: otras cadenas de bloques que tienen votación de tokens en cadena. Ethereum evita específicamente cualquier tipo de mecanismo de votación porque, en mi opinión, eso conduce a vías de captura y, en cierto modo, elimina el incentivo de hacer que las cosas sean una meritocracia donde la gente simplemente confía en las personas que escriben el mejor código. Y luego están las L2. Tienen firmas múltiples (multi-sigs). Tienen consejos de seguridad. Estos son más bien puestos designados que toman estas decisiones. Y eso tiene sus compensaciones. Es más centralizado. Sin embargo, se mueve más rápido.

Por qué a los constructores les importa (22:38)

Entonces, ¿por qué a los constructores les importa la gobernanza? Porque los constructores son literalmente para quienes se creó Ethereum. Ethereum no está creado para los desarrolladores del núcleo. No está creado para los validadores. A veces estas personas se confunden al respecto. Los desarrolladores del núcleo de Ethereum y los validadores sirven a Ethereum, que sirve a los constructores y usuarios.

Y todo el mundo ha tenido ese momento con una IA en el que te estás metiendo demasiado en los detalles y está tratando de arreglar esta pequeña cosa y no logra alejarse y mirar todo el propósito del proyecto. Y los desarrolladores del núcleo pueden ser así cuando intentan perfeccionar el proceso de desarrollo del núcleo. Y es muy crucial en ese caso que los constructores intervengan porque el desarrollo del núcleo es tan absorbente que la mayor parte del tiempo no están construyendo también sobre Ethereum. Están muy involucrados en el desarrollo del núcleo. Les quita todo su tiempo. Y por eso los constructores de aplicaciones realmente tienen que hacer un esfuerzo para intervenir y decir: "Oigan, necesitamos esto. Esto es crucial para Ethereum". Solo para asegurarse de que la perspectiva esté ahí y que no se encasillen en trabajar solo para los desarrolladores del núcleo.

Cómo participar (24:40)

Entonces, ¿cómo participas o introduces tu característica? Este es un consejo un poco genérico, pero creo que es el mejor. Haz ruido sobre tus puntos débiles. Ve a Twitter, escribe publicaciones de blog, identifica soluciones para tus puntos débiles. Especula sobre las cosas que podrían ayudarte. Si encuentras a otras personas que tienen esos mismos puntos débiles, generalmente puedes encontrar una EIP que exista para abordar ese punto débil o hacer que alguien te ayude a escribir una EIP que lo haga.

Una cosa que me gusta del software de código abierto es que, por lo general, las empresas bien capitalizadas asignarán su tiempo y recursos de desarrollo para mantener las herramientas de código abierto que están utilizando. Y termina siendo un montón de empresas diferentes colaborando en el mantenimiento de esta cosa y así es como puede funcionar en Ethereum también. Así que si tienes un punto débil que has identificado, puedes encontrar a un desarrollador de Base que tenga un punto débil similar, y Base es una organización bien capitalizada, por lo que probablemente estarían dispuestos a asignar algunos recursos para lanzar una característica o guiar una característica a través de una bifurcación dura de Ethereum.

Solo les dejaré algunos recursos. Forkcast.org: ahí es donde pueden ir y ver qué entra en una bifurcación, cómo afecta a ciertas partes interesadas. Así que, si eres un desarrollador de aplicaciones, hay una sección para desarrolladores de aplicaciones. Si eres un desarrollador de billeteras, un desarrollador de clientes de la capa de consenso, hay secciones sobre cómo les afecta todo eso. En YouTube es donde se suben todos los videos de esas llamadas. También están integrados en la página forkcast.org/calls donde hay resúmenes, atribuciones de los oradores, por lo que es más fácil navegar por esas llamadas. El directorio de EIP, el foro de Ethereum Magicians donde puedes ir a hablar con otras personas sobre posibles soluciones o EIP que quieras escribir. Y muy pronto mi equipo tendrá un sitio de soporte del protocolo. Se ve increíble. No está listo para compartir. Mi correo electrónico también está ahí: nixo@ethereum.org (opens email client). Eso es todo.