Título original: Posibles futuros del protocolo Ethereum, parte 1: The Merge
Autor original: Vitalik Buterin
Compilación original: Deng Tong, Golden Finance
Un agradecimiento especial a Justin Drake, Hsiao-wei Wang, @antonttc y Francesco por sus comentarios y reseñas.
Inicialmente, "fusión" se refería al evento más importante en la historia del protocolo Ethereum desde su lanzamiento: la tan esperada y duramente ganada transición de Prueba de Trabajo a Prueba de Participación. Hoy en día, Ethereum ha sido un sistema de prueba de participación estable y funcional durante casi dos años, que ha funcionado extremadamente bien en términos de estabilidad, rendimiento y evitación de riesgos de centralización. Sin embargo, todavía hay algunas áreas importantes en las que es necesario mejorar la prueba de participación.
Mi hoja de ruta para 2023 la divide en varias partes: mejoras en las características técnicas como la estabilidad, el rendimiento y la accesibilidad a validadores más pequeños, y cambios económicos para abordar los riesgos de centralización. El primero tomó el título de "Merge", mientras que el segundo pasó a formar parte de "The Scourge".
Este artículo se centrará en la parte de "fusión": ¿qué más se puede mejorar en el diseño técnico de la prueba de participación y cuáles son las formas de lograr estas mejoras?
Esta no es una lista exhaustiva de mejoras que podrían realizarse en la Prueba de participación, sino más bien una lista de ideas que se están considerando activamente.
Finalidad de una sola ranura y democratización de las apuestas
¿Qué problema estamos resolviendo?
Hoy en día, se necesitan de 2 a 3 épocas (~15 minutos) para completar un bloque y se requieren 32 ETH para convertirse en apostador. Originalmente se trataba de un compromiso para lograr un equilibrio entre tres objetivos:
· Maximizar la cantidad de validadores que pueden participar en la apuesta (esto significa directamente minimizar el ETH mínimo requerido para apostar)
· Minimizar el tiempo de finalización
· Minimizar la sobrecarga de los nodos en ejecución
Estos tres objetivos están en conflicto entre sí: para lograr la finalidad económica (es decir, un atacante necesitaría destruir una gran cantidad de ETH para recuperar un bloque finalizado), cada validador necesitaría firmar dos mensajes por finalización. Entonces, si tiene muchos validadores, tomará mucho tiempo procesar todas las firmas o necesitará nodos muy potentes para procesar todas las firmas al mismo tiempo.
Tenga en cuenta que todo esto depende de un objetivo clave de Ethereum: garantizar que incluso un ataque exitoso imponga un alto costo al atacante. Esto es lo que se entiende por el término "finalidad económica". Si no tenemos este objetivo, entonces podemos resolver este problema seleccionando aleatoriamente un comité (como lo que hace Algorand) para finalizar cada puesto. Pero el problema con este enfoque es que si un atacante controla el 51% de los validadores, puede atacar a un costo muy bajo (recuperando bloques finalizados, censura o retrasando la finalización): solo una parte del comité Los nodos pueden ser detectados como participantes. en ataques y castigados, ya sea mediante cortes o un puñado de tenedores blandos. Esto significa que un atacante puede atacar la cadena muchas veces. Entonces, si queremos finalidad económica, un enfoque simple basado en comités no funcionará y, a primera vista, necesitamos un conjunto completo de validadores para participar.
Idealmente, queremos preservar la finalidad económica y al mismo tiempo mejorar el status quo de dos maneras:
· Finalizar bloques dentro de un intervalo de tiempo (idealmente, mantener o incluso reducir la duración actual de 12 segundos) en lugar de 15 minutos
· Permitir a los validadores apostar con 1 ETH (reducido de 32 ETH a 1 ETH)
El primer objetivo se evidencia en dos objetivos, los cuales pueden verse como "alinear las propiedades de Ethereum con las de las cadenas L1 (más centralizadas) centradas en el rendimiento".
En primer lugar, garantiza que todos los usuarios de Ethereum se beneficien de un mayor nivel de seguridad logrado a través del mecanismo de finalización. Hoy en día, la mayoría de los usuarios no disfrutan de esta garantía porque no están dispuestos a esperar 15 minutos; con un mecanismo de finalización de una sola ranura, los usuarios pueden ver la transacción finalizada casi inmediatamente después de que se confirma. En segundo lugar, simplifica el protocolo y la infraestructura circundante si los usuarios y las aplicaciones no tienen que preocuparse por la posibilidad de una reversión de la cadena (salvo el caso relativamente raro de fugas de inactividad).
El segundo objetivo está impulsado por el deseo de apoyar a los interesados individuales. Encuesta tras encuesta ha demostrado repetidamente que lo principal que impide que más personas apuesten por sí solas es el mínimo de 32 ETH. Reducir el mínimo a 1 ETH resolvería este problema hasta el punto de que otras cuestiones se conviertan en el principal factor que limita las apuestas individuales.
Existe un desafío: los objetivos de una finalidad más rápida y una apuesta más democratizada entran en conflicto con el objetivo de minimizar los gastos generales. De hecho, este hecho es la única razón por la que no adoptamos el determinismo de ranura única en primer lugar. Sin embargo, investigaciones recientes sugieren algunas posibles soluciones a este problema.
¿Qué es y cómo funciona?
La finalidad de una sola ranura implica el uso de un algoritmo de consenso que finaliza los bloques dentro de una ranura. Este no es un objetivo inalcanzable en sí mismo: muchos algoritmos (como el consenso de Tendermint) ya lo logran con propiedades óptimas. Una propiedad deseable exclusiva de Ethereum que Tendermint no admite es la fuga de inactividad, que permite que la cadena continúe funcionando y eventualmente se recupere incluso si más de 1/3 de los validadores están fuera de línea. Afortunadamente, este deseo ya se ha cumplido: ya hay propuestas para modificar el consenso al estilo Tendermint para dar cabida a las filtraciones de inactividad.
Propuesta líder de finalidad de ranura única
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 incurrir en una sobrecarga extremadamente alta del operador del nodo. Existen varias soluciones líderes para esto:
Opción 1: Fuerza bruta: trabajar para lograr un mejor protocolo de agregación de firmas, posiblemente utilizando ZK-SNARK, lo que esencialmente nos permitiría procesar firmas de millones de validadores por ranura.
Horn, uno de los diseños propuestos para mejores protocolos de agregación.
Opción 2: Comité 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, que van desde x=0 (comité estilo Algorand, sin finalidad económica) hasta x=1 (situación actual de Ethereum), abriendo un punto en el medio. , Ethereum Todavía hay suficiente finalidad económica para lograr una seguridad extrema, pero al mismo tiempo obtenemos la ventaja de eficiencia de requerir solo una muestra aleatoria de validadores de tamaño moderado para participar en cada época.
Orbit aprovecha la heterogeneidad preexistente en el tamaño de los depósitos de los validadores para obtener la mayor finalidad económica posible, sin dejar de otorgar a los pequeños validadores un papel relevante. Además, Orbit utiliza una rotación lenta de los comités para garantizar un alto grado de superposición entre quórums adyacentes, asegurando que su finalidad económica aún se aplique a los límites de rotación de los comités.
Opción 3: Apuesta de dos niveles: un mecanismo en el que los apostadores se dividen en dos categorías, una con requisitos de depósito más altos y la otra con requisitos de depósito más bajos. Sólo los niveles con requisitos de depósito más altos están directamente involucrados en proporcionar finalidad económica. Hay varias propuestas sobre cuáles serían exactamente los derechos y responsabilidades para los niveles con requisitos de depósito más bajos (ver, por ejemplo, la publicación Rainbow Stake). Las ideas comunes incluyen:
· El derecho a delegar intereses a accionistas de nivel superior
· Las partes interesadas de nivel inferior seleccionadas al azar están certificadas y se les exige que completen cada bloque
· El derecho a generar listas de inclusión.
¿Cuáles son las conexiones con la investigación existente?
· Caminos hacia la finalidad de una sola ranura (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality
· Propuesta específica para el protocolo de finalidad de un solo slot de 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 de la mecánica del estilo Orbit: https://notes.ethereum.org/@anderselowsson/Vorbit_SSF
· Horn, Protocolo de agregación de firmas (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219
· Fusión de firmas para un consenso a gran escala (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn
· Protocolo de agregación de firmas propuesto por Khovratovich et al.: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/
· Agregación de firmas basada en STARK (2022): https://hackmd.io/@vbuterin/stark_aggregationRainbow
· Replanteo: https://ethresear.ch/t/unbundling-s Taking-towards-rainbow-stake/18683
¿Qué queda por hacer? ¿Cuáles son las compensaciones?
Hay cuatro caminos posibles principales (también podemos tomar caminos híbridos):
· Mantener el status quo
· Órbita SSF
· Potente SSF
· SSF con dos niveles de participación
(1) significa no hacer ningún trabajo y mantener las apuestas como están, pero esto haría que la experiencia de seguridad de Ethereum y las propiedades de centralización de apuestas sean peores de lo que serían de otra manera.
(2) Evite la "alta tecnología" y resuelva el problema repensando inteligentemente los supuestos del protocolo: relajamos el requisito de "finalidad económica" para exigir que el costo del ataque sea alto, pero aceptamos que el costo del ataque puede ser 10 veces menor. que ahora (por ejemplo, el coste del ataque es de 2.500 millones de dólares, no de 25.000 millones de dólares). Se cree ampliamente 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 otra parte, por lo que podría decirse que este es un sacrificio aceptable.
El esfuerzo principal es verificar que el mecanismo Orbit sea seguro y tenga las propiedades que queremos, y luego formalizarlo e implementarlo por completo. Además, EIP-7251 (Aumento del saldo válido máximo) permite la consolidación voluntaria del saldo del validador, lo que reduce inmediatamente los gastos generales de validación de la cadena y sirve como una fase inicial efectiva para el lanzamiento de Orbit.
(3) Evitar replanteamientos inteligentes y, en cambio, problemas de fuerza bruta con alta tecnología. Hacer esto requiere recopilar una gran cantidad de firmas (más de 1 millón) en muy poco tiempo (entre 5 y 10 segundos).
(4) Evita replanteamientos inteligentes y alta tecnología, pero crea un sistema de participación de dos niveles que aún presenta riesgos de centralización. El riesgo depende en gran medida de los derechos específicos adquiridos por los niveles de participación más bajos. Por ejemplo:
Si los interesados de nivel inferior necesitan delegar sus derechos de certificación a los interesados de nivel superior, entonces la delegación puede centralizarse y terminar con dos niveles de participación altamente centralizados. Si se requiere un muestreo aleatorio de niveles inferiores para aprobar cada bloque, un atacante puede gastar una pequeña cantidad de ETH para evitar la finalidad. Si los participantes de bajo nivel solo pueden hacer listas de inclusión, entonces la capa de prueba aún puede estar centralizada, momento en el cual un ataque del 51% a la capa de prueba puede censurar la lista de inclusión misma.
Se pueden combinar múltiples estrategias, tales como:
· (1 + 2): Agrega Orbit sin realizar finalidad de ranura única.
· (1 + 3): utilice técnicas de fuerza bruta para reducir el tamaño mínimo del depósito sin imponer la finalidad de una sola ranura. La cantidad de polimerización requerida es 64 veces menor que en el caso puro (3), por lo que el problema se vuelve más sencillo.
· (2 + 3): Ejecute Orbit SSF con parámetros conservadores (por ejemplo, comité de validación de 128k en lugar de 8k o 32k) y utilice técnicas de fuerza bruta para hacerlo súper eficiente.
· (1 + 4): Agrega apuestas de arcoíris sin imponer la finalidad de una sola ranura.
¿Cómo interactúa con otras partes de la hoja de ruta?
Entre otros beneficios, la finalidad de una sola ranura reduce el riesgo de ciertos tipos de ataques MEV multibloque. Además, en un mundo de finalidad de una sola ranura, el diseño de separación del probador-proponente y otros procesos 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 del slot.
Elección de líder secreto único
¿Qué problema estamos tratando de resolver?
Hoy en día se sabe de antemano qué validador propondrá el siguiente bloque. Esto crea un agujero de seguridad: un atacante podría monitorear la red, identificar qué validadores corresponden a qué direcciones IP y lanzar un ataque DoS contra los validadores cuando están a punto de proponer un bloqueo.
¿qué es? ¿Cómo funciona?
La mejor manera de resolver el problema DoS es ocultar la información de qué validador generará el siguiente bloque, al menos hasta que el bloque se genere realmente. Tenga en cuenta que esto es fácil si eliminamos el requisito "único": una solución sería permitir que cualquiera cree el siguiente bloque, pero requerir que randao revele menos de 2256/N. En promedio, solo un validador cumple este requisito, pero a veces hay dos o más y, a veces, cero. Combinar el requisito de "confidencialidad" con el requisito de "soltería" siempre ha sido un problema difícil.
El protocolo de elección de líder secreto único resuelve este problema mediante el uso de algunas técnicas criptográficas para crear una identificación de validador "ciega" para cada validador, y luego brinda a muchos proponentes la oportunidad de mezclar y volver a cegar el conjunto de identificaciones ciegas (esto es similar a Cómo las redes híbridas funcionan). En cada período, se selecciona una identificación aleatoria y ciega. Sólo el propietario del ID ciego puede generar una prueba válida para proponer un bloqueo, pero nadie sabe a qué validador corresponde el ID ciego.
Batir el protocolo SSLE
¿Cuáles son algunos vínculos con la investigación existente?
· Artículo de Dan Boneh (2020): https://eprint.iacr.org/2020/025.pdf
· Whisk (una propuesta práctica para Ethereum, 2022): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-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? ¿Cuáles son las compensaciones?
Realmente, todo lo que queda es encontrar e implementar un protocolo que sea lo suficientemente simple como para que podamos implementarlo fácilmente en la red principal. Nos tomamos muy en serio a Ethereum como un protocolo bastante simple y no queremos que la complejidad aumente aún más. Las implementaciones SSLE que vimos agregaron cientos de líneas de código canónico e introdujeron nuevas suposiciones en cifrado complejo. Encontrar una implementación suficientemente eficiente de SSLE resistente a los cuánticos también es un problema abierto.
Eventualmente puede suceder que la "complejidad adicional marginal" de SSLE solo disminuya cuando introduzcamos un mecanismo general de prueba de conocimiento cero en L1 del protocolo Ethereum por otras razones (por ejemplo, árboles de estado, ZK-EVM) a un nivel suficientemente bajo.
Otra opción es ignorar SSLE y en su lugar utilizar mitigaciones fuera de protocolo (como en la capa p2p) para abordar los problemas de DoS.
¿Cómo interactúa con otras partes de la hoja de ruta?
Si agregamos un mecanismo de separación entre probador y proponente (APS), como tickets de ejecución, entonces la ejecución de bloques (es decir, bloques que contienen transacciones de Ethereum) no requerirá SSLE, ya que podemos confiar en creadores de bloques especializados. Sin embargo, para los bloques de consenso (es decir, bloques que contienen mensajes de protocolo (por ejemplo, pruebas, posiblemente partes de listas, etc.)), aún nos beneficiaremos de SSLE.
Confirmación de transacción más rápida
¿Qué problema estamos resolviendo?
Es valioso reducir aún más los tiempos de confirmación de transacciones de Ethereum, de 12 segundos a 4 segundos. Hacerlo mejorará significativamente la experiencia del usuario L1 y basada en agregación, al tiempo que hará que el protocolo defi sea más eficiente. También facilitará la descentralización de L2, ya que permitirá que una gran cantidad de aplicaciones L2 funcionen en pedidos basados en agregación, reduciendo así la necesidad de que L2 cree su propio pedido descentralizado basado en comités.
¿qué es? ¿Cómo funciona?
Aquí hay aproximadamente dos técnicas:
· Reducir el tiempo del slot, por ejemplo a 8 segundos o 4 segundos. Esto no significa necesariamente 4 segundos de finalidad: la finalidad esencialmente requiere tres rondas de comunicación, por lo que podríamos hacer de cada ronda de comunicación un bloque separado, con al menos un reconocimiento preliminar después de 4 segundos.
· Permitir a los proponentes emitir preconfirmaciones durante un espacio. En casos extremos, los proponentes podrían incorporar las transacciones que ven en sus bloques en tiempo real y publicar inmediatamente un mensaje de confirmación previa para cada transacción ("Mi primera transacción fue 0x1234...", "La segunda transacción es 0×5678". ...”). La situación en la que un proponente emite dos confirmaciones contradictorias se puede manejar de dos maneras: (i) eliminando al proponente o (ii) utilizando probadores para votar cuál es anterior.
¿Cuáles son algunos vínculos con la investigación existente?
· Basado en confirmaciones previas: https://ethresear.ch/t/based-preconfirmations/17353
· Protocolo de compromisos del proponente aplicado (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
· Períodos escalonados en cadenas paralelas (ideas para lograr una latencia baja en 2018): https://ethresear.ch/t/staggered-periods/1793
¿Qué queda por hacer y cuáles son las compensaciones?
No está claro qué tan práctica será la reducción del tiempo de las franjas horarias. Incluso hoy en día, los interesados en muchas partes del mundo luchan por obtener pruebas con la suficiente rapidez. Intentar un intervalo de tiempo de 4 segundos corre el riesgo de concentrar el conjunto de validadores y hacer que sea poco práctico convertirse en validador fuera de unas pocas regiones privilegiadas debido a la latencia.
La debilidad del método de confirmación previa del proponente es que mejora en gran medida el tiempo promedio de inclusión del caso, pero no el tiempo de inclusión del peor caso: si el proponente actual está funcionando bien, su transacción será preconfirmada en 0,5 segundos, mientras que no (en promedio) Se incluyen 6 segundos, pero si el proponente actual está desconectado o no tiene un buen desempeño, aún tendrá que esperar 12 segundos completos antes de que pueda comenzar el siguiente espacio y proporcionar un nuevo proponente.
Además, queda abierta la cuestión de cómo incentivar la confirmación previa. Los proponentes tienen un incentivo para maximizar su opcionalidad durante el mayor tiempo posible. Si el probador firma la puntualidad de la preconfirmación, entonces el remitente de la transacción puede condicionar parte de la tarifa a la preconfirmación inmediata, pero esto impondrá una carga adicional al probador y puede hacer que le resulte más difícil continuar actuar como un "tubo tonto" neutral.
Por otro lado, si no intentamos hacer esto y mantenemos el tiempo de finalización en 12 segundos (o más), el ecosistema pondrá más énfasis en el mecanismo de confirmación previa promulgado por la Capa 2 y las interacciones a través de la Capa 2 tomarán más tiempo.
¿Cómo interactúa con otras partes de la hoja de ruta?
La confirmación previa basada en el proponente en realidad se basa en mecanismos de separación entre el proponente y el proponente (APS), como los tickets de ejecución. De lo contrario, la presión para proporcionar confirmaciones previas en tiempo real puede crear una presión demasiado centralizada sobre los validadores habituales.
Otras áreas de investigación
51% de recuperación de ataques
En general, se cree que en caso de un ataque del 51% (incluidos ataques que no pueden ser probados criptográficamente, como la censura), la comunidad se unirá para implementar una bifurcación suave minoritaria, asegurando que los buenos ganen y los malos se queden. filtradas o restringidas debido a la inactividad. Sin embargo, se puede decir que este nivel de dependencia excesiva de la capa social es perjudicial para la salud. Podemos intentar reducir la dependencia de la capa social y hacer que el proceso de recuperación sea lo más automatizado posible.
La automatización total no es posible, porque si lo fuera, esto contaría como un algoritmo de consenso con >50% de tolerancia a fallas, y ya conocemos las limitaciones (muy estrictas) matemáticamente demostrables de tales algoritmos. Pero podemos lograr una automatización parcial: por ejemplo, un cliente puede automáticamente negarse a aceptar una cadena como final, o incluso negarse a aceptarla como cabeza de una selección de bifurcación, si el cliente ha revisado una transacción que ha visto durante mucho tiempo. suficiente. Un objetivo clave es garantizar que los malos del ataque no consigan al menos una victoria rápida.
Aumentar el umbral de quórum
Hoy, se finalizará un bloque si el 67% de los participantes lo apoyan. Algunos piensan que esto es demasiado radical. En toda la historia de Ethereum, sólo ha habido un (muy breve) fracaso final. Si este porcentaje se aumentara al 80%, el número de épocas de no finalidad aumentadas sería relativamente bajo, pero Ethereum ganaría seguridad: en particular, muchas de las situaciones más controvertidas resultarían en una suspensión temporal de la finalidad. Esto parece mucho más saludable que ganar el "lado equivocado" inmediatamente, ya sea que el lado equivocado sea el atacante o haya un error en el lado del cliente.
Esto también responde a la pregunta "¿Cuál es el objetivo de un apostador independiente?" Hoy en día, la mayoría de los participantes ya están apostando a través de grupos, y parece poco probable que un solo participante reciba hasta el 51% del ETH apostado. Sin embargo, lograr que un apostador en solitario llegue a una minoría que bloquea a la mayoría parece posible si nos esforzamos, especialmente si la mayoría alcanza el 80% (por lo que solo se necesita el 21% para bloquear a la mayoría). Mientras los participantes solitarios no participen en un ataque del 51% (ya sea una reversión de finalidad o una revisión), este ataque no logrará una "victoria limpia" y los participantes solitarios ayudarán activamente a organizar las bifurcaciones suaves minoritarias.
Resistencia cuántica
Metaculus actualmente cree que, aunque con grandes márgenes de error, las computadoras cuánticas probablemente comenzarán a descifrar 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 tomar más en serio la posibilidad de que las computadoras cuánticas realmente funcionen a mediano plazo. Esto tiene implicaciones para toda la hoja de ruta de Ethereum: significa que cada parte del protocolo Ethereum que actualmente se basa en curvas elípticas necesitará algún tipo de alternativa basada en hash u otra alternativa resistente a los cuánticos. Esto significa en particular que no podemos asumir que alguna vez podremos confiar en las propiedades superiores de la agregación BLS para manejar firmas de grandes conjuntos de validadores. Esto justifica el conservadurismo en los supuestos de rendimiento del diseño de prueba de participación y es una razón para desarrollar de manera más agresiva alternativas resistentes a los cuánticos.
Enlace original
