Originalmente, “the Merge” se refería al evento más importante en la historia del protocolo de Ethereum desde su lanzamiento: la transición tan esperada y merecida de la prueba de trabajo a la prueba de participación. Hoy en día, Ethereum ha sido un sistema de prueba de participación estable en funcionamiento durante casi exactamente dos años, y esta prueba de participación ha funcionado de manera notablemente eficiente en estabilidad, rendimiento y evitar los riesgos de centralizaciónSin embargo, todavía quedan algunas áreas importantes en las que la prueba de participación necesita mejorar.

Mi diagrama de hoja de ruta de 2023 separó esto en categorías: mejorar características técnicas como estabilidad, rendimiento y accesibilidad para validadores más pequeños, y cambios económicos para abordar riesgos de centralización. Lo primero se encargó de encabezar "la Fusión", y lo segundo se convirtió en parte de "la Plaga".

La Fusión, edición del roadmap 2023.

Esta publicación se centrará en la parte “Merge”: ¿qué se puede mejorar aún en el diseño técnico de la prueba de participación y cuáles son algunos caminos para llegar allí?

Esta no pretende ser una lista exhaustiva de cosas que podrían hacerse para la prueba de participación; más bien, es una lista de ideas que están siendo consideradas activamente.

La Fusión: objetivos clave

• Finalidad de una sola ranura
• Confirmación y finalización de transacciones lo más rápido posible, manteniendo al mismo tiempo la descentralización
• Mejorar la viabilidad del staking para los stakers individuales
• Mejorar la robustez
• Mejorar la capacidad de Ethereum para resistir y recuperarse de ataques del 51% (incluyendo reversión de finalidad, bloqueo de finalidad y censura)

En este capítulo

• Finalidad de una sola ranura y democratización del staking
• Elección de líder secreto único
• Confirmaciones de transacción más rápidas
• Otras áreas de investigación

Finalidad de una sola ranura y democratización del staking

¿Qué problema estamos resolviendo?

Hoy en día, se necesitan 2-3 épocas (~15 min) para finalizar un bloque, y se requieren 32 ETH para ser un validador. Originalmente, esto fue un compromiso destinado a @VitalikButerinequilibrio entre tres objetivos:

• Maximizar el número de validadores que pueden participar en el staking (esto implica directamente minimizar la cantidad mínima de ETH requerida para hacer staking)
• Minimizando el tiempo de finalización
• Minimizar los costos operativos de ejecutar un nodo, en este caso el costo de descargar, verificar y retransmitir todas las firmas de validación de los otros validadores

Los tres objetivos están en conflicto: para que la finalidad económica sea posible (es decir, un atacante necesitaría quemar una gran cantidad de ETH para revertir un bloque finalizado), necesitas que cada validador firme dos mensajes cada vez que ocurre la finalidad. Y así, si tienes muchos validadores, o bien necesitas mucho tiempo para procesar todas sus firmas, o necesitas nodos muy potentes para procesar todas las firmas al mismo tiempo.

Tenga en cuenta que todo esto es condicional a un objetivo clave de Ethereum: asegurar que incluso los ataques exitosos tengan un costo alto para el atacante. Esto es lo que se entiende por el término "finalidad económica". Si no tuviéramos este objetivo, entonces podríamos resolver este problema seleccionando aleatoriamente un comité para finalizar cada ranura. Cadenas que no intentan lograr la finalidad económica, como Algorand,a menudo hacer exactamente esto. Pero el problema con este enfoque es que si un atacante controla el 51% de los validadores, entonces pueden llevar a cabo un ataque (revertir un bloque finalizado, o censurar, o retrasar la finalización) a un costo muy bajo: solo la porción de sus nodos que están en el comité podría ser detectada como participante en el ataque y penalizada, ya sea a través slashingobifurcación suave coordinada socialmenteEsto significa que un atacante podría atacar repetidamente la cadena muchas veces, perdiendo solo una pequeña parte de su participación en cada ataque. Por lo tanto, si queremos tener una finalidad económica, un enfoque basado en un comité ingenuo no funciona, y parece a primera vista que necesitamos el conjunto completo de validadores para participar.

Idealmente, queremos preservar la finalidad económica, al mismo tiempo que mejoramos el status quo en dos áreas:

1. Finalice los bloques en un intervalo (idealmente, mantenga o incluso reduzca la longitud actual de 12s), en lugar de 15 min
2. Permitir a los validadores apostar con 1 ETH (en lugar de 32 ETH)

La primera meta está justificada por dos objetivos, ambos de los cuales pueden ser vistos como "alinear las propiedades de Ethereum con las de las cadenas L1 centradas en el rendimiento (más centralizadas)".

Primero, asegura que todos los usuarios de Ethereum realmente se beneficien del mayor nivel de garantías de seguridad alcanzado a través del mecanismo de finalidad. Hoy en día, la mayoría de los usuarios no lo hacen, porque no están dispuestos a esperar 15 minutos; con finalidad de un solo slot, los usuarios verán que sus transacciones se finalizan casi tan pronto como se confirman. En segundo lugar, simplifica el protocolo y la infraestructura circundante si los usuarios y las aplicaciones no tienen que preocuparse por la posibilidad de que la cadena se revierta, excepto en el caso relativamente raro de un fuga de inactividad.

La segunda meta está justificada por el deseo de apoyar a los stakers individuales. Encuesta tras encuesta muestran repetidamente que el principal factor que impide que más personas hagan staking individual es el mínimo de 32 ETH. Reducir el mínimo a 1 ETH resolvería este problema, hasta el punto en que otras preocupaciones se conviertan en el factor dominante que limita el staking individual.

Hay un desafío: los objetivos de una finalización más rápida y una participación más democratizada entran en conflicto con el objetivo de minimizar los gastos generales. Y de hecho, este hecho es la razón completa por la cual no comenzamos con una finalización de un solo espacio al principio. Sin embargo, investigaciones más recientes presentan algunas posibles soluciones al problema.

¿Qué es y cómo funciona?

La finalidad de un solo slot implica el uso de un algoritmo de consenso que finaliza los bloques en un solo slot. Esto en sí mismo no es un objetivo difícil: muchos algoritmos, como consenso de Tendermint, ya haga esto con propiedades óptimas. Una propiedad deseada única de Ethereum, que Tendermint no admite, esfiltraciones de inactividad, que permiten que la cadena siga funcionando y eventualmente se recupere incluso cuando más de 1/3 de los validadores se desconecten. Afortunadamente, este deseo ya ha sido atendido: hay ya propuestasque modifican el consenso estilo Tendermint para adaptarse a fugas de inactividad.

Una propuesta líder de finalidad de un solo slot

La parte más difícil del problema es descubrir cómo hacer que la finalidad de una sola ranura funcione con un número muy alto de validadores, sin provocar una sobrecarga extremadamente alta para el operador del nodo. Para esto, hay algunas soluciones líderes:

• Opción 1: Fuerza bruta: trabajar arduamente en la implementación de mejores protocolos de agregación de firmas, potencialmente utilizando ZK-SNARKs, lo que realmente nos permitiría procesar firmas de millones de validadores en cada ranura.

Horn, uno de los diseños propuestos para un mejor protocolo de agregación.

• Opción 2: Comités de órbita - un nuevo mecanismo que permite que un comité de tamaño mediano seleccionado al azar sea responsable de finalizar la cadena, pero de una manera que preserve las propiedades de costo de ataque que estamos buscando.

  Una forma de pensar en Orbit SSF es que abre un espacio de opciones de compromiso a lo largo de un espectro desde x=0 (comités al estilo Algorand, sin finalidad económica) hasta x=1 (estado actual de Ethereum), abriendo puntos intermedios donde Ethereum aún tiene suficiente finalidad económica para ser extremadamente seguro, pero al mismo tiempo obtenemos los beneficios de eficiencia al necesitar solo una muestra aleatoria de tamaño mediano de validadores para participar en cada ranura.

Orbit aprovecha la heterogeneidad preexistente en los tamaños de depósito de validadores para obtener la mayor cantidad de finalidad económica posible, mientras sigue dando a los pequeños validadores un papel proporcional. Además, Orbit utiliza una rotación lenta de comités para garantizar una alta superposición entre cuórumes adyacentes, asegurando que su finalidad económica siga aplicándose en los límites de cambio de comités.

• Opción 3: stake en dos niveles, un mecanismo en el que hay dos clases de stakers, uno con requisitos de depósito más altos y otro con requisitos de depósito más bajos. Solo el nivel de depósito más alto estaría directamente involucrado en proporcionar la finalidad económica. Hay varias propuestas (por ejemplo, ver la publicación de participación en Rainbow) para conocer exactamente qué derechos y responsabilidades tiene el nivel de depósito más bajo. Las ideas comunes incluyen:
  • el derecho a delegar la participación a un apostador de nivel superior
  • una muestra aleatoria de validadores de nivel inferior que atestiguan, y que son necesarios para finalizar, cada bloque
  • el derecho de generarlistas de inclusión

¿Cuáles son algunos enlaces a investigaciones existentes?

• Caminos hacia la finalidad de un solo slot (2022): @vbuterin/single_slot_finality"">https://notes.ethereum.org/@vbuterin/single_slot_finality
• Una propuesta concreta para un protocolo de finalidad de una sola ranura para Ethereum (2023): https://eprint.iacr.org/2023/280
• Orbit SSF: https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928
• Análisis adicional sobre mecanismos de estilo Orbit: https://ethresear.ch/t/vorbit-ssf-with-circular-and-spiral-finality-validator-selection-and-distribution/20464
• Horn, protocolo de agregación de firmas (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219
• Fusion de firmas para consenso a gran escala (2023): https://ethresear.ch/t/fusion-de-firmas-para-consenso-a-gran-escala/17386?u=asn
• Protocolo de agregación de firmas propuesto por Khovratovich et al: @7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/"">https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/
• Agregación de firmas basada en STARK (2022): @vbuterin/stark_aggregation"">https://hackmd.io/@vbuterin/stark_aggregation
• Rainbow staking: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683

¿Qué queda por hacer y cuáles son los compromisos?

Hay cuatro posibles caminos principales para tomar (y también podemos tomar caminos híbridos):

1. Mantener el statu quo
2. SSF de fuerza bruta
3. Orbit SSF
4. SSF con staking de dos niveles

(1) significa no hacer ningún trabajo y dejar el staking como está, pero deja la experiencia de seguridad de Ethereum y las propiedades de centralización del staking peor de lo que podría ser.

(2) fuerza bruta el problema con alta tecnología. Hacer que esto suceda requiere agregar un número muy grande de firmas (1 millón +) en un período de tiempo muy corto (5-10s). Una forma de pensar en este enfoque es que implicaminimizando la complejidad sistémica al aceptar por completo la complejidad encapsulada.

(3) evita el “alto nivel tecnológico” y resuelve el problema con una reconsideración ingeniosa en torno a las suposiciones del protocolo: relajamos el requisito de “finalidad económica” para que requiramos que los ataques sean costosos, pero estamos bien con el costo del ataque siendo quizás 10 veces menor que hoy (por ejemplo, el costo del ataque de $2.5 mil millones en lugar de $25 mil millones). Es una opinión común que Ethereum hoy en día tiene mucha más finalidad económica de la que necesita, y sus principales riesgos de seguridad están en otro lado, por lo que este sacrificio es discutiblemente aceptable.

El trabajo principal a realizar es verificar que el mecanismo de Orbit es seguro y tiene las propiedades que deseamos, y luego formalizarlo e implementarlo completamente. Además, EIP-7251 (aumentar el saldo efectivo máximo)permite la consolidación voluntaria del saldo del validador que reduce inmediatamente en cierta medida la sobrecarga de verificación de la cadena, y actúa como una etapa inicial efectiva para un despliegue de Orbit.

(4) evita el replanteamiento ingenioso y la alta tecnología, pero crea un sistema de participación en dos niveles que todavía tiene riesgos de centralización. Los riesgos dependen en gran medida de los derechos específicos que obtiene el nivel inferior de participación. Por ejemplo:

• Si un staker de bajo nivel necesita delegar sus derechos de validación a un staker de alto nivel, entonces la delegación podría centralizarse y así terminaríamos con dos niveles de validación altamente centralizados.
• Si se necesita una muestra aleatoria de la capa inferior para aprobar cada bloque, entonces un atacante podría gastar una cantidad muy pequeña de ETH para bloquear la finalidad.
• Si los validadores de nivel inferior solo pueden crear listas de inclusión, entonces la capa de certificación puede permanecer centralizada, momento en el que un ataque del 51% en la capa de certificación puede censurar las propias listas de inclusión.

Se pueden combinar múltiples estrategias, por ejemplo:

(1 + 2): utilizar técnicas de fuerza bruta para reducir el tamaño mínimo de depósito sin realizar una finalidad de ranura única. La cantidad de agregación requerida es 64 veces menor que en el caso puro (3), por lo que el problema se vuelve más fácil.

(1 + 3): agregar Orbit sin hacer finalidad de un solo slot

(2 + 3): hacer Orbit SSF con parámetros conservadores (por ejemplo, comité de validadores de 128k en lugar de 8k o 32k), y utilizar técnicas de fuerza bruta para hacerlo ultraeficiente.

(1 + 4): agregar el staking arcoiris sin hacer finalidad de ranura única

¿Cómo interactúa con otras partes del plan de trabajo?

Además de sus otros beneficios, la finalidad de un solo slot reduce el riesgo de ciertos tipos de ataques MEV multi-bloqueAdemás, los diseños de separación de atestiguador-proponedor y otros flujos de producción de bloques en el protocolo deberían ser diseñados de manera diferente en un mundo de finalidad de una sola ranura.

Las estrategias de fuerza bruta tienen la debilidad de que hacen que sea más difícil reducir los tiempos de ranura.

Elección de un solo líder secreto

¿Qué problema estamos resolviendo?

Hoy en día, se sabe de antemano qué validador va a proponer el siguiente bloque. Esto crea una vulnerabilidad de seguridad: un atacante puede observar la red, identificar qué validadores corresponden a qué direcciones IP y atacar a cada validador justo cuando están a punto de proponer un bloque.

¿Qué es y cómo funciona?

La mejor manera de solucionar el problema de DoS es ocultar la información sobre qué validador va a producir el siguiente bloque, al menos hasta el momento en que el bloque se produce realmente. Tenga en cuenta que esto es fácil si eliminamos el requisito “único”:una soluciónes permitir a cualquiera crear el siguiente bloque, pero requerir el revelación de randaoser menor que 2256 / N. En promedio, solo un validador podría cumplir con este requisito, pero a veces habría dos o más y a veces no habría ninguno. Combinar el requisito de "secreto" con el requisito de "único" ha sido durante mucho tiempo el problema difícil.

Los protocolos de elección de líder secreto único resuelven esto utilizando algunas técnicas criptográficas para crear un ID de validador 'oculto' para cada validador, y luego dando a muchos proponentes la oportunidad de mezclar y volver a ocultar el grupo de IDs ocultos (esto es similar a cómo unmixnet works). Durante cada espacio, se selecciona un ID enmascarado al azar. Solo el propietario de ese ID enmascarado puede generar una prueba válida para proponer el bloque, pero nadie más sabe a qué validador corresponde ese ID enmascarado.

Protocolo SSLE de batido

¿Cuáles son algunos enlaces a investigaciones existentes?

• Artículo de Dan Boneh (2020): https://eprint.iacr.org/2020/025.pdf
• Whisk (propuesta concreta para Ethereum, 2022): https://ethresear.ch/t/whisk-un-protocolo-ssle-basado-en-mezclas-practicas-para-Ethereum/11763
• Etiqueta de elección de líder secreto único en ethresear.ch:https://ethresear.ch/tag/single-secret-leader-election
• SSLE simplificado usando firmas de anillo: https://ethresear.ch/t/simplified-ssle/12315

¿Qué queda por hacer y cuáles son los compromisos?

Realísticamente, lo que queda es encontrar e implementar un protocolo que sea lo suficientemente simple como para que estemos cómodos implementándolo en mainnet. Valoramos mucho que Ethereum sea un protocolo razonablemente simple y no queremos que la complejidad aumente aún más. Las implementaciones de SSLE que hemos visto añaden cientos de líneas de código de especificación e introducen nuevas suposiciones en criptografía complicada. Resolver una implementación de SSLE lo suficientemente eficiente y resistente a los cuánticos también es un problema abierto.

Puede suceder que la complejidad adicional introducida por SSLE solo disminuya lo suficiente una vez que nos lancemos e introduzcamos la maquinaria para realizar pruebas de conocimiento cero de propósito general en el protocolo Ethereum en L1 por otras razones (por ejemplo, árboles de estado, ZK-EVM).

Una opción alternativa es simplemente no molestarse con SSLE y usar mitigaciones fuera del protocolo (por ejemplo, en la capa p2p) para resolver los problemas de DoS.

¿Cómo interactúa con otras partes del plan de acción?

Si agregamos un mecanismo de separación de atestiguadores-proponentes (APS), por ejemplo. boletos de ejecución, entonces los bloques de ejecución (es decir, los bloques que contienen transacciones de Ethereum) no necesitarán SSLE, porque podríamos confiar en que los constructores de bloques sean especializados. Sin embargo, seguiríamos beneficiándonos de SSLE para bloques de consenso (es decir, bloques que contienen mensajes de protocolo como confirmaciones, quizás partes de listas de inclusión, etc).

Confirmaciones de transacciones más rápidas

¿Qué problema estamos resolviendo?

Hay valor en Ethereum’s tiempo de confirmación de transacción disminuyendo aún más, de 12 segundos a p. ej. 4 segundos. Hacer esto mejoraría significativamente la experiencia del usuario tanto de la L1 como de los rollups basados, al tiempo que haría que los protocolos defi fueran más eficientes. También facilitaría la descentralización de los L2, ya que permitiría que una gran cantidad de aplicaciones L2 funcionen en basados en rollups, reduciendo la demanda de L2s para construir su propio protocolo de secuenciación descentralizado basado en comités.

¿Qué es y cómo funciona?

Hay ampliamente dos familias de técnicas aquí:

1. Reducir los tiempos de ranura, hasta por ejemplo. 8 segundoso 4 segundos. Esto no necesariamente tiene que significar una finalidad de 4 segundos: la finalidad inherentemente implica tres rondas de comunicación, por lo que podemos hacer que cada ronda de comunicación sea un bloque separado, lo que después de 4 segundos obtendría al menos una confirmación preliminar.
2. Permitir a los proponentes publicar pre-confirmaciones a lo largo de un espacio de tiempo. En el extremo, un proponente podría incluir transacciones que ven en su bloque en tiempo real e inmediatamente publicar un mensaje de pre-confirmación para cada transacción ("Mi primera transacción es 0×1234…", "Mi segunda transacción es 0×5678…"). El caso de un proponente que publica dos confirmaciones conflictivas se puede manejar de dos maneras: (i) mediante la eliminación del proponente, o (ii) mediante el uso de atestiguadores para votar sobre cuál llegó primero.

¿Cuáles son algunos enlaces a investigaciones existentes?

• Preconfirmaciones basadas: https://ethresear.ch/t/based-preconfirmations/17353
• Compromisos de proponentes reforzados por protocolo (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
• Períodos escalonados en cadenas paralelas (una idea de la era de 2018 para lograr baja latencia):https://ethresear.ch/t/staggered-periods/1793

¿Qué queda por hacer y cuáles son los compromisos?

Está lejos de ser claro cuán práctico es reducir los tiempos de ranura. Incluso hoy, los validadores en muchas regiones del mundo tienen dificultades para incluir lo suficientemente rápido las validaciones. Intentar ejecutar tiempos de ranura de 4 segundos conlleva el riesgo de centralizar el conjunto de validadores y hacer que sea impracticable ser un validador fuera de unas pocas geografías privilegiadas debido a la latencia. Específicamente, pasar a tiempos de ranura de 4 segundos requeriría reducir el límite de latencia de red ("delta") a dos segundos.

El enfoque del proponente preconfirmación tiene la debilidad de que puede mejorar en gran medida los tiempos de inclusión en el caso promedio, pero no en el peor caso: si el actual proponente funciona bien, su transacción será preconfirmada en 0.5 segundos en lugar de ser incluida (en promedio) en 6 segundos, pero si el actual proponente está fuera de línea o no funciona bien, aún tendría que esperar hasta 12 segundos completos para que comience el siguiente slot y proporcione un nuevo proponente.

Además, está abierta la cuestión de cómo se incentivarán las preconfirmaciones. Los proponentes tienen un incentivo para maximizar su opcionalidad el mayor tiempo posible. Si los certificadores aprueban la puntualidad de las preconfirmaciones, entonces los remitentes de transacciones podrían condicionar una parte de la tarifa a una preconfirmación inmediata, pero esto supondría una carga adicional para los atestiguadores y potencialmente dificultaría que los atestiguadores continúen funcionando como una "tubería tonta" neutral.

Por otro lado, si no intentamos esto y mantenemos los tiempos de finalidad en 12 segundos (o más), el ecosistema pondrá mayor peso en los mecanismos de preconfirmación realizados por las capas 2, y la interacción entre capas 2 llevará más tiempo.

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

Las preconfirmaciones basadas en el proponente dependen realistamente de un mecanismo de separación de atestiguador y proponente (APS), por ejemplo. Tickets de ejecuciónDe lo contrario, la presión para proporcionar preconfirmaciones en tiempo real puede ser demasiado centralizadora para los validadores regulares.

Exactamente qué tan cortos pueden ser los tiempos de ranura también depende de la estructura de la ranura, que depende en gran medida de las versiones de APS, listas de inclusión, etc. que terminemos implementando. Hay estructuras de ranura que contienen menos rondas y, por lo tanto, son más amigables con los tiempos de ranura cortos, pero hacen compensaciones en otros lugares.

Otras áreas de investigación

Recuperación de ataque del 51%

A menudo se asume que si ocurre un ataque del 51% (incluidos los ataques que no son criptográficamente demostrables, como la censura), la comunidad se unirá para implementar un bifurcación suave de minoríaque asegura que los buenos ganen y que los malos sean filtrados por inactividad o sean sancionados. Sin embargo, este grado de dependencia excesiva de la capa social es discutiblemente poco saludable. Podemos intentar reducir la dependencia de la capa social, haciendo que el proceso de recuperación sea lo más automatizado posible.

La automatización completa es imposible, porque si lo fuera, eso contaría como un algoritmo de consenso tolerante a fallos del >50%, y ya conocemos el algoritmo (muy restrictivo) limitaciones matemáticamente demostrables de ese tipo de algoritmosPero podemos lograr una automatización parcial: por ejemplo, un cliente podría rechazar automáticamente aceptar una cadena como finalizada, o incluso como la cabeza de la elección de bifurcación, si censura transacciones que el cliente ha visto durante el tiempo suficiente. Un objetivo clave sería asegurar que al menos los malos en un ataque no puedan obtener una victoria rápida y limpia.

Aumentando el umbral de quórum

Hoy, un bloque se finaliza si el 67% de los validadores lo respaldan. Existe un argumento de que esto es demasiado agresivo. Solo ha habido una falla de finalización (muy breve) en toda la historia de Ethereum. Si este porcentaje se aumenta, por ejemplo, al 80%, entonces el número agregado de períodos de no finalización será relativamente bajo, pero Ethereum ganaría propiedades de seguridad: en particular, muchas más situaciones conflictivas resultarán en la detención temporal de la finalización. Esto parece ser una situación mucho más saludable que ver a “la parte equivocada” obtener una victoria instantánea, tanto cuando la parte equivocada es un atacante, como cuando es un cliente que tiene un error.

Esto también responde a la pregunta "¿cuál es el punto de los apostadores en solitario"? Hoy en día, la mayoría de los apostadores ya están apostando a través de grupos y parece muy improbable que los apostadores en solitario lleguen al 51% de los ETH apostados. Sin embargo, lograr que los apostadores en solitario lleguen a una minoría de bloqueo de quórum, especialmente si el quórum es del 80% (por lo que una minoría de bloqueo de quórum solo necesitaría el 21%), parece potencialmente alcanzable si trabajamos duro en ello. Siempre y cuando los apostadores en solitario no se unan a un ataque del 51% (ya sea de reversión de finalidad o censura), dicho ataque no lograría una "victoria limpia", y los apostadores en solitario estarían motivados para ayudar a organizar una bifurcación suave de minoría.

Tenga en cuenta que hay interacciones entre los umbrales de quórum y el mecanismo de Orbit: si terminamos usando Orbit, entonces qué significa exactamente "21% de validadores" se convertirá en una pregunta más complicada, y dependerá en parte de la distribución de los validadores.

Resistencia cuántica

Metaculus currently believes, aunque con barras de error amplias, 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 la posibilidad de que los ordenadores cuánticos realmente funcionen a medio plazomucho más en serio. Esto tiene consecuencias en toda la hoja de ruta de Ethereum: significa que cada pieza del protocolo de Ethereum que actualmente depende de curvas elípticas necesitará tener algún reemplazo basado en hash o resistente a la cuántica. Esto significa, en particular, que no podemos asumir que seremos capaces de apoyarnos en las excelentes propiedades de la agregación BLSprocesar firmas de un gran conjunto de validadores para siempre. Esto justifica el conservadurismo en las suposiciones sobre el rendimiento de los diseños de prueba de participación, y también es una razón para ser más proactivo en el desarrollo de alternativas resistentes a la computación cuántica.

Descargo de responsabilidad：

1. Este artículo se reimprime de [Vitalik Buterin], Todos los derechos de autor pertenecen al autor original [Vitalik Buterin]. If there are objections to this reprint, please contact the Gate Learnequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las 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 Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.