Vitalik: ¿Qué aspectos del PoS de Ethereum aún pueden mejorarse y cuáles son las posibles vías de mejora?

Este artículo se centrará en el tema de la "fusión" de Ethereum: ¿qué aspectos del diseño técnico de proof of stake aún pueden mejorarse y qué caminos existen para lograr esas mejoras?

Autor:Vitalik Buterin

Traducción: Deng Tong, Jinse Finance

Agradecimientos especiales a Justin Drake, Hsiao-wei Wang, @antonttc y Francesco por sus comentarios y revisión.

Originalmente, la "fusión" se refería al evento más importante en la historia del protocolo de Ethereum desde su lanzamiento: la tan esperada y difícil transición de proof of work a proof of stake. Hoy en día, Ethereum ha estado funcionando como un sistema de proof of stake estable durante casi dos años, y este proof of stake ha mostrado un rendimiento sobresaliente en estabilidad, desempeño y mitigación de riesgos de centralización. Sin embargo, aún existen áreas importantes de proof of stake que requieren mejoras.

Mi hoja de ruta de 2023 la divide en varias partes: mejoras técnicas como estabilidad, rendimiento y accesibilidad para validadores más pequeños, así como cambios económicos para abordar riesgos de centralización. La primera parte tomó el título de "fusión", mientras que la segunda se convirtió en parte de la "plaga".

Este artículo se centrará en la parte de la "fusión": ¿qué aspectos del diseño técnico de proof of stake aún pueden mejorarse y qué caminos existen para lograr esas mejoras?

Esto no es una lista exhaustiva de mejoras posibles para proof of stake; en cambio, es una lista de ideas que están siendo consideradas activamente.

Finalidad de slot único y democratización del staking

¿Qué problema estamos resolviendo?

Actualmente, se requieren 2-3 epochs (aproximadamente 15 minutos) para finalizar un bloque, y se necesitan 32 ETH para convertirse en validador. Esto fue originalmente un compromiso para equilibrar tres objetivos:

• Maximizar la cantidad de validadores que pueden participar en el staking (lo que implica minimizar la cantidad mínima de ETH requerida para hacer staking)
• Minimizar el tiempo de finalización
• Minimizar los costos operativos de los nodos

Estos tres objetivos entran en conflicto entre sí: para lograr finalidad económica (es decir, que un atacante deba destruir una gran cantidad de ETH para revertir bloques finalizados), cada validador debe firmar dos mensajes en cada finalización. Por lo tanto, si tienes muchos validadores, o bien necesitas mucho tiempo para procesar todas las firmas, o necesitas nodos muy potentes para procesarlas simultáneamente.

Notá que todo esto depende de un objetivo clave de Ethereum: asegurar que incluso un ataque exitoso tenga un costo alto para el atacante. Eso es lo que significa el término "finalidad económica". Si no tuviéramos ese objetivo, podríamos finalizar cada slot seleccionando aleatoriamente un comité (como hace Algorand). Pero el problema de ese enfoque es que, si un atacante controla el 51% de los validadores, puede atacar a bajo costo (revertir bloques finalizados, censurar o retrasar la finalidad): solo una parte de los nodos del comité pueden ser detectados y penalizados, ya sea por slashing o soft forks de minoría. Esto permite que el atacante ataque repetidamente la cadena. Por lo tanto, si queremos finalidad económica, el enfoque simple basado en comités no funciona; a primera vista, necesitamos la participación de todos los validadores.

Idealmente, queremos mantener la finalidad económica y, al mismo tiempo, mejorar la situación en dos aspectos:

• Finalizar bloques en un solo slot (idealmente manteniendo o incluso reduciendo los actuales 12 segundos de duración), en lugar de 15 minutos
• Permitir que los validadores hagan staking con 1 ETH (bajando de 32 ETH a 1 ETH)

El primer objetivo está respaldado por dos metas, ambas pueden verse como "hacer que las propiedades de Ethereum sean consistentes con las de cadenas L1 (más centralizadas) orientadas al rendimiento".

Primero, asegura que todos los usuarios de Ethereum se beneficien del mayor nivel de seguridad proporcionado por el mecanismo de finalidad. Hoy, la mayoría de los usuarios no disfrutan de esa garantía porque no quieren esperar 15 minutos; con finalidad de slot único, los usuarios pueden ver la finalidad casi inmediatamente después de la confirmación de la transacción. Segundo, si los usuarios y aplicaciones no tienen que preocuparse por posibles reversiones de la cadena (excepto en casos raros de inactivity leak), se simplifican los protocolos y la infraestructura circundante.

El segundo objetivo responde al deseo de apoyar a los stakers individuales. Encuestas repetidas han mostrado que el principal factor que impide que más personas hagan staking individualmente es el mínimo de 32 ETH. Bajar el mínimo a 1 ETH resolvería ese problema, haciendo que otros factores sean los principales limitantes para el staking individual.

Existe un desafío: los objetivos de finalidad más rápida y staking más democrático entran en conflicto con el objetivo de minimizar los costos. De hecho, esa es la razón por la que no adoptamos la finalidad de slot único desde el principio. Sin embargo, investigaciones recientes han propuesto posibles soluciones a este problema.

¿Qué es y cómo funciona?

La finalidad de slot único implica usar un algoritmo de consenso que finaliza bloques en un solo slot. Esto en sí mismo no es difícil de lograr: muchos algoritmos (como el consenso Tendermint) ya lo logran con excelentes propiedades. Una propiedad ideal única de Ethereum que Tendermint no soporta es el inactivity leak, que permite que la cadena siga funcionando y eventualmente se recupere incluso si más de un tercio de los validadores están offline. Por suerte, ese deseo ya está cubierto: existen propuestas para modificar el consenso tipo Tendermint para adaptarlo al inactivity leak.

Propuestas líderes de finalidad de slot único

La parte más difícil es descubrir cómo hacer que la finalidad de slot único funcione con una cantidad muy alta de validadores, sin causar costos operativos altísimos para los operadores de nodos. Para esto, existen varias soluciones líderes:

Opción 1: Fuerza bruta: trabajar en mejores protocolos de agregación de firmas, posiblemente usando ZK-SNARKs, que permitan procesar firmas de millones de validadores por slot.

Horn, uno de los diseños propuestos para mejores protocolos de agregación.

Opción 2: Comité Orbit: un nuevo mecanismo que permite que un comité de tamaño medio, seleccionado aleatoriamente, se encargue de la finalidad de la cadena, pero de una manera que preserve las propiedades de costo de ataque que buscamos.

Una forma de pensar Orbit SSF es que abre un espacio de compromiso que va desde x=0 (comité estilo Algorand, sin finalidad económica) hasta x=1 (situación actual de Ethereum), abriendo puntos intermedios donde Ethereum aún tiene suficiente finalidad económica para ser extremadamente seguro, pero también obtenemos la eficiencia de requerir solo una muestra aleatoria de validadores de tamaño medio en cada slot.

Orbit aprovecha la heterogeneidad preexistente en los depósitos de los validadores para obtener la mayor finalidad económica posible, mientras sigue dando roles correspondientes a los validadores pequeños. Además, Orbit usa una rotación lenta de comités para asegurar una alta superposición entre quórums adyacentes, asegurando que su finalidad económica siga aplicando en los límites de rotación de comité.

Opción 3: Staking de dos capas: un mecanismo donde los stakers se dividen en dos categorías, una con requisitos de depósito más altos y otra con requisitos más bajos. Solo la capa de depósitos altos participa directamente en la finalidad económica. Hay varias propuestas sobre los derechos y responsabilidades de la capa de depósitos bajos (ver, por ejemplo, el post de Rainbow staking). Algunas ideas comunes incluyen:

• El derecho a delegar stake a los de la capa superior
• Validadores de la capa baja seleccionados aleatoriamente para atestiguar y finalizar cada bloque
• El derecho a generar listas de inclusión

¿Qué relación tiene con la investigación existente?

• Caminos hacia la finalidad de slot único (2022):
• Propuestas específicas de protocolo de finalidad de slot único para Ethereum (2023):
• Orbit SSF:
• Análisis adicional de mecanismos estilo Orbit:
• Horn, protocolo de agregación de firmas (2022):
• Agregación de firmas para consenso a gran escala (2023):
• Protocolo de agregación de firmas propuesto por Khovratovich et al.:
• Agregación de firmas basada en STARK (2022):
• Rainbow staking:

¿Qué queda por hacer? ¿Qué compensaciones hay?

Hay cuatro caminos principales viables (también podemos adoptar caminos híbridos):

• Mantener el status quo
• Orbit SSF
• SSF por fuerza bruta
• SSF con staking de dos capas

(1) significa no hacer nada, mantener el staking como está, pero eso haría que la experiencia de seguridad y las propiedades de centralización del staking en Ethereum sean peores de lo que podrían ser.

(2) Evita la "alta tecnología" y resuelve el problema repensando inteligentemente los supuestos del protocolo: relajamos el requisito de "finalidad económica" para que el costo de ataque siga siendo alto, pero aceptamos que podría ser 10 veces menor que ahora (por ejemplo, un costo de ataque de 2.5 billones de dólares en vez de 25 billones). Se cree ampliamente que la finalidad económica de Ethereum hoy es mucho mayor de lo necesario y que los principales riesgos de seguridad están en otros lados, así que esto puede ser un sacrificio aceptable.

El trabajo principal es verificar que el mecanismo Orbit sea seguro y tenga las propiedades deseadas, luego formalizarlo e implementarlo completamente. Además, EIP-7251 (aumentar el saldo efectivo máximo) permite la fusión voluntaria de saldos de validadores, lo que reduce inmediatamente los costos de validación de la cadena y sirve como una fase inicial efectiva para el despliegue de Orbit.

(3) Evita el repensamiento inteligente y, en cambio, resuelve el problema con alta tecnología. Esto requiere recolectar una gran cantidad de firmas (más de 1 millón) en un tiempo muy corto (5-10 segundos).

(4) Evita tanto el repensamiento inteligente como la alta tecnología, pero crea un sistema de staking de dos capas que aún tiene riesgos de centralización. El riesgo depende en gran medida de los derechos específicos otorgados a la capa baja. Por ejemplo:

• Si los stakers de la capa baja deben delegar su derecho de atestiguación a los de la capa alta, la delegación puede centralizarse y terminaríamos con dos capas de staking altamente centralizadas.
• Si se requiere muestreo aleatorio de la capa baja para aprobar cada bloque, un atacante puede gastar una cantidad mínima de ETH para impedir la finalidad.
• Si los stakers de la capa baja solo pueden crear listas de inclusión, la capa de atestiguación puede seguir centralizada, permitiendo que un ataque del 51% a la capa de atestiguación censure las listas de inclusión.

Se pueden combinar varias estrategias, por ejemplo:

• (1 + 2): agregar Orbit sin implementar finalidad de slot único.
• (1 + 3): usar técnicas de fuerza bruta para reducir el depósito mínimo sin implementar finalidad de slot único. La cantidad de agregación requerida es 64 veces menor que en el caso puro (3), por lo que el problema es más fácil.
• (2 + 3): implementar Orbit SSF con parámetros conservadores (por ejemplo, comité de 128k validadores en vez de 8k o 32k) y usar técnicas de fuerza bruta para hacerlo ultra eficiente.
• (1 + 4): agregar Rainbow staking sin implementar finalidad de slot único.

¿Cómo interactúa con otras partes de la hoja de ruta?

Además de otros beneficios, la finalidad de slot único reduce el riesgo de ciertos tipos de ataques MEV de múltiples bloques. Además, en un mundo con finalidad de slot único, el diseño de separación de proponentes y atestiguadores y otros pipelines de producción de bloques dentro del protocolo deben diseñarse de manera diferente.

La debilidad de las estrategias de fuerza bruta es que hacen más difícil acortar el tiempo de slot.

Elección secreta única de líder

¿Qué problema queremos resolver?

Hoy en día, se sabe de antemano qué validador propondrá el siguiente bloque. Esto crea una vulnerabilidad de seguridad: un atacante puede monitorear la red, identificar qué validadores corresponden a qué direcciones IP y lanzar un ataque DoS cuando el validador está por proponer un bloque.

¿Qué es? ¿Cómo funciona?

La mejor manera de resolver el problema DoS es ocultar qué validador generará el siguiente bloque, al menos hasta que el bloque sea realmente generado. Notá que si eliminamos el requisito de "único", esto es fácil: una solución es permitir que cualquiera cree el siguiente bloque, pero exigir que el randao revelado sea menor que 2^256 / N. En promedio, solo un validador podrá cumplir ese requisito, pero a veces habrá dos o más, y a veces ninguno. Combinar el requisito de "secreto" con el de "único" ha sido un desafío.

El protocolo de elección secreta única de líder resuelve esto usando criptografía para crear un "ID ciego" para cada validador, y luego permite que muchos proponentes mezclen y re-ceguen el pool de IDs ciegos (similar a cómo funcionan las mixnets). En cada slot, se selecciona un ID ciego al azar. Solo el dueño de ese ID ciego puede generar una prueba válida para proponer el bloque, pero nadie sabe a qué validador corresponde ese ID ciego.

Protocolo Whisk SSLE

¿Qué enlaces a investigaciones existentes hay?

• Papel de Dan Boneh (2020):
• Whisk (propuesta específica para Ethereum, 2022):
• Etiqueta de elección secreta única de líder en ethresear.ch:
• SSLE simplificado usando firmas de anillo:

¿Qué queda por hacer? ¿Qué compensaciones hay?

En la práctica, lo que queda es encontrar e implementar un protocolo lo suficientemente simple como para que pueda implementarse fácilmente en mainnet. Valoramos mucho que Ethereum sea un protocolo relativamente simple y no queremos aumentar la complejidad. Las implementaciones de SSLE que hemos visto agregan cientos de líneas de código de especificación e introducen nuevos supuestos criptográficos complejos. Encontrar una implementación de SSLE suficientemente eficiente y resistente a la computación cuántica también es un problema abierto.

Finalmente, puede darse el caso de que solo cuando, por otras razones (como árboles de estado, ZK-EVM), introduzcamos mecanismos de prueba de conocimiento cero generalizados en la L1 del protocolo de Ethereum, la "complejidad marginal adicional" de SSLE baje lo suficiente.

Otra opción es ignorar SSLE y usar mitigaciones fuera del protocolo (por ejemplo, en la capa p2p) para abordar el problema DoS.

¿Cómo interactúa con otras partes de la hoja de ruta?

Si agregamos mecanismos de separación de proponentes y atestiguadores (APS), como ejecución de tickets, entonces los bloques de ejecución (es decir, los bloques que contienen transacciones de Ethereum) no necesitarán SSLE porque podemos depender de constructores de bloques especializados. Sin embargo, para los bloques de consenso (es decir, los bloques que contienen mensajes de protocolo como atestiguaciones, listas de inclusión parciales, etc.), aún nos beneficiaríamos de SSLE.

Confirmación de transacciones más rápida

¿Qué problema estamos resolviendo?

Reducir aún más el tiempo de confirmación de transacciones en Ethereum es valioso, de 12 segundos a 4 segundos. Esto mejoraría significativamente la experiencia de usuario en L1 y en soluciones basadas en rollups, y haría los protocolos defi más eficientes. También facilitaría la descentralización de L2, permitiendo que muchas aplicaciones L2 funcionen sobre rollups, reduciendo la necesidad de que L2 construyan su propio ordenamiento descentralizado basado en comités.

¿Qué es? ¿Cómo funciona?

Hay dos técnicas principales aquí:

• Reducir el tiempo de slot, por ejemplo, a 8 o 4 segundos. Esto no necesariamente significa finalidad en 4 segundos: la finalidad requiere esencialmente tres rondas de comunicación, por lo que podemos hacer que cada ronda sea un bloque separado y obtener una confirmación preliminar después de 4 segundos.
• Permitir que el proponente publique pre-confirmaciones durante el slot. En el caso extremo, el proponente puede incluir transacciones en su bloque en tiempo real y publicar inmediatamente un mensaje de pre-confirmación para cada transacción ("mi primera transacción es 0×1234...", "mi segunda transacción es 0×5678..."). Si el proponente publica dos confirmaciones conflictivas, esto puede manejarse de dos maneras: (i) penalizando al proponente, o (ii) usando el voto de los atestiguadores para decidir cuál fue primero.

¿Qué enlaces a investigaciones existentes hay?

• Basado en pre-confirmaciones:
• Compromiso obligatorio del proponente por protocolo (PEPC):
• Ciclos intercalados en cadenas paralelas (idea de 2018 para baja latencia):

¿Qué queda por hacer y qué compensaciones hay?

No está claro cuán práctico es reducir el tiempo de slot. Incluso hoy, a muchos validadores en varias partes del mundo les cuesta obtener atestiguaciones lo suficientemente rápido. Intentar slots de 4 segundos corre el riesgo de centralizar el set de validadores y, debido a la latencia, puede ser poco realista ser validador fuera de unas pocas regiones privilegiadas.

La debilidad del método de pre-confirmación del proponente es que mejora mucho el tiempo de inclusión en promedio, pero no en el peor caso: si el proponente actual funciona bien, tu transacción recibirá pre-confirmación en 0.5 segundos en vez de (en promedio) ser incluida en 6 segundos, pero si el proponente está offline o funciona mal, igual tendrás que esperar los 12 segundos completos para el siguiente slot y un nuevo proponente.

Además, queda la cuestión de cómo incentivar las pre-confirmaciones. El proponente tiene incentivos para maximizar su opcionalidad el mayor tiempo posible. Si los atestiguadores firman la puntualidad de la pre-confirmación, el remitente de la transacción puede condicionar parte de la tarifa a la pre-confirmación inmediata, pero esto agrega carga a los atestiguadores y puede dificultar que sigan siendo un "tubo tonto" neutral.

Por otro lado, si no intentamos esto y mantenemos el tiempo de finalidad en 12 segundos (o más), el ecosistema valorará más los mecanismos de pre-confirmación desarrollados en L2, y las interacciones entre L2 tomarán más tiempo.

¿Cómo interactúa con otras partes de la hoja de ruta?

Las pre-confirmaciones basadas en el proponente dependen en realidad de mecanismos de separación de atestiguadores y proponentes (APS), como ejecución de tickets. De lo contrario, la presión para proporcionar pre-confirmaciones en tiempo real podría ser demasiado para los validadores regulares.

Otras áreas de investigación

Recuperación de ataques del 51%

Se suele pensar que, si ocurre un ataque del 51% (incluyendo ataques que no pueden probarse criptográficamente, como censura), la comunidad se unirá para implementar un soft fork de minoría, asegurando que los buenos ganen y los malos sean penalizados por inactividad o slashing. Sin embargo, este nivel de dependencia en la capa social puede considerarse poco saludable. Podemos intentar reducir la dependencia de la capa social y automatizar el proceso de recuperación tanto como sea posible.

La automatización total es imposible, porque si lo fuera, sería un algoritmo de consenso tolerante a fallas de más del 50%, y ya conocemos las limitaciones matemáticas (muy estrictas) de ese tipo de algoritmos. Pero podemos lograr una automatización parcial: por ejemplo, si un cliente censura transacciones que ha visto durante suficiente tiempo, el cliente puede rechazar automáticamente aceptar una cadena como finalizada, o incluso como cabeza de la elección de fork. Un objetivo clave es asegurar que los malos en un ataque al menos no puedan ganar rápidamente.

Aumentar el umbral de quórum

Hoy, si el 67% de los stakers apoyan, el bloque se finaliza. Algunos consideran que esto es demasiado agresivo. En toda la historia de Ethereum, solo ha habido una (muy breve) falla de finalidad. Si aumentamos ese porcentaje al 80%, el número de períodos sin finalidad aumentaría relativamente poco, pero Ethereum ganaría en seguridad: en particular, muchos casos más controvertidos llevarían a una pausa temporal en la finalidad. Esto parece más saludable que que el "lado equivocado" gane inmediatamente, ya sea un atacante o un cliente con errores.

Esto también responde a la pregunta "¿para qué sirve el staking individual?". Hoy, la mayoría de los stakers ya hacen staking a través de pools, y parece poco probable que los stakers individuales alcancen el 51% del ETH en staking. Sin embargo, si lo intentamos, alcanzar una minoría de bloqueo, especialmente si la mayoría es del 80% (por lo que la minoría de bloqueo requiere solo el 21%), parece posible. Mientras los stakers individuales no participen en un ataque del 51% (ya sea reversión de finalidad o censura), ese ataque no obtendrá una "victoria limpia" y los stakers individuales ayudarán activamente a organizar el soft fork de minoría.

Resistencia cuántica

Metaculus actualmente estima que, aunque con gran margen de error, es probable que las computadoras cuánticas comiencen a romper la criptografía en algún momento de la década de 2030:

Expertos en computación cuántica, como Scott Aaronson, también han comenzado recientemente a considerar más seriamente la posibilidad de que las computadoras cuánticas funcionen realmente en el mediano plazo. Esto afecta a toda la hoja de ruta de Ethereum: significa que cada parte del protocolo de Ethereum que actualmente depende de curvas elípticas necesitará alguna alternativa basada en hash u otra resistencia cuántica. En particular, no podemos asumir que siempre podremos depender de las excelentes propiedades de agregación de BLS para manejar firmas de grandes conjuntos de validadores. Esto justifica ser conservadores en los supuestos de rendimiento del diseño de proof of stake y es una razón para desarrollar alternativas resistentes a la computación cuántica de manera más activa.