Esto facilitará la vida de los implementadores de tecnología, así como de los constructores de infraestructura de soporte, como los clientes ligeros.
Escrito por: Vitalik Buterin, ethresearch
Compilado por: Songxue, Golden Finance
La principal diferencia entre Ethereum y la mayoría de los demás sistemas de prueba de participación (de finalidad) es que Ethereum intenta admitir una gran cantidad de objetos validadores: actualmente tenemos 895.000 objetos validadores, y el análisis simple de la ley de Zipf muestra que esto corresponde a decenas de Miles de objetos validadores son individuos/entidades únicas. El propósito de esto es apoyar la descentralización e incluso permitir que personas comunes y corrientes participen en el stake sin requerir que cada persona renuncie a su agencia y ceda el control a uno de los pocos grupos de stake.
Sin embargo, este enfoque requiere que la cadena Ethereum procese una gran cantidad de firmas por ranura (alrededor de 28.000 hoy; 1.790.000 después de SSF), lo que supone una carga muy elevada. Soportar esta carga requiere importantes sacrificios técnicos:
- Esto requiere un mecanismo complejo de propagación de pruebas que implica dividir la prueba en múltiples subredes, lo que requiere una hiperoptimización de las operaciones de firma BLS para verificar estas firmas, etc.
- No tenemos una alternativa clara que sea lo suficientemente eficiente como para ser resistente a los cuánticos.
- Las correcciones de selección de bifurcación, como la combinación de vistas, se vuelven más complejas porque no se pueden extraer firmas individuales.
- SNARKing firmas es difícil debido a su gran número. Helios necesita operar con una firma adicional dedicada, llamada firma del comité de sincronización.
- Aumenta el intervalo de tiempo mínimo seguro al requerir tres intervalos de subtiempo en un intervalo de tiempo en lugar de dos.
El sistema de agregación de firmas puede parecer razonable a primera vista, pero en realidad crea una complejidad sistémica que impregna todos los aspectos.
Es más, ni siquiera cumple su propósito. El requisito mínimo para apostar sigue siendo 32 ETH, lo que está fuera del alcance de muchos. Solo desde un análisis lógico, a largo plazo, parece inviable que un sistema en el que todos inician sesión realmente proporcione apuestas para la gente común: si Ethereum tiene 500 millones de usuarios, y el 10% de ellos se comprometen, entonces esto significa que hay 100 millones. firmas por ranura. En términos de teoría de la información, los recortes de procesamiento en este diseño requieren al menos 12,5 MB de espacio libre de datos por ranura, aproximadamente tanto como el objetivo de una daksharding completa (!!!). Tal vez sea factible, pero requerir que la apuesta en sí dependa del muestreo de disponibilidad de datos conllevaría una gran ganancia en complejidad, incluso si eso es solo alrededor del 0,6% de la población mundial apostada, y eso ni siquiera comienza a entrar en los problemas computacionales de la verificación. tantas firmas.
Entonces, en lugar de depender de criptógrafos para crear una bala mágica (o una armadura mágica) que haga posible tener un número cada vez mayor de firmas en cada intervalo de tiempo, sugiero que hagamos un cambio filosófico: renunciar a tales expectativas en el primer lugar . Esto ampliaría enormemente el espacio de diseño de PoS y permitiría una gran simplificación técnica, haciéndolo más seguro al permitir que Helios SNARK directamente en el consenso de Ethereum, y al hacer que incluso esquemas de firmas aburridos y antiguos como Winternitz también sean factibles. resolver el problema de la resistencia cuántica.
¿Por qué no “simplemente utilizar el comité”?
Muchas cadenas de bloques que no son Ethereum y que enfrentan exactamente este problema utilizan un enfoque de seguridad basado en comités. En cada intervalo de tiempo, seleccionan aleatoriamente N validadores (por ejemplo, N es aproximadamente igual a 1000), y estos validadores son responsables de completar ese intervalo de tiempo. Vale la pena recordar por qué este enfoque no es suficiente: carece de responsabilidad.
Para entender por qué, imaginemos un ataque del 51%. Esto podría ser un ataque final de reversión o un ataque de censura. Para lanzar un ataque, el actor económico que controla la mayor parte de la participación aún debe aceptar llevar a cabo el ataque, es decir, ejecutar el software que participa en el ataque, junto con todos los validadores que finalmente son elegidos para el comité. Las matemáticas del muestreo aleatorio lo garantizan. Sin embargo, la penalización que soportan por tal ataque es pequeña porque la mayoría de los validadores que aceptan el ataque terminan sin ser vistos porque no fueron elegidos para el comité.
Actualmente, Ethereum toma el extremo opuesto. En el caso de un ataque del 51%, se reducirá la participación de la mayoría de todo el conjunto de validadores atacantes. El costo actual del ataque es de aproximadamente 9 millones de ETH (aproximadamente $20 mil millones), y esto supone que la sincronización de la red se interrumpe de una manera que maximiza el beneficio del atacante.
Creo que es un costo alto, y es un costo demasiado alto, y podemos hacer algunos sacrificios en este tema. Incluso si el costo del ataque es de 1 a 2 millones de ETH, es completamente suficiente. Además, el principal riesgo de centralización que existe actualmente para Ethereum se encuentra en un lugar completamente diferente: si la cantidad mínima de apuesta se reduce a cerca de cero, la diferencia en la fuerza de los grupos de apuestas a gran escala no será mucha.
Es por eso que propongo una solución modesta: hacer algunos sacrificios en la responsabilidad del validador, pero aún así mantener la cantidad total de ETH recortable bastante alta y, a cambio, nos brinda a un conjunto de validadores más pequeño la mayoría de los beneficios.
¿Cómo se verían 8192 firmas por intervalo de tiempo en SSF?
Suponiendo un protocolo de consenso tradicional de dos rondas (similar al utilizado por Tendermint, e inevitablemente utilizado por SSF), cada validador participante requiere dos firmas por intervalo de tiempo. Necesitamos sortear esta realidad. Veo tres formas principales en las que podemos hacer esto.
Método 1: apostar por el fondo de compromiso descentralizado
Python tiene un dicho muy crucial:
Debería haber una forma obvia, preferiblemente sólo una, de hacer esto.
Con respecto a la cuestión de la igualación de apuestas, Ethereum actualmente viola esta regla porque implementamos simultáneamente dos estrategias diferentes para lograr este objetivo: (i) apuestas individuales a pequeña escala y (ii) uso de un grupo de apuestas descentralizado con tecnología de validación distribuida (DVT). Debido a las razones anteriores, (i) solo se puede admitir a un subconjunto de participantes individuales; siempre habrá muchas personas cuyo depósito mínimo sea demasiado grande. Sin embargo, Ethereum está pagando un costo de carga técnica muy alto para respaldar (i).
Una posible solución es abandonar (i) y apostar por (ii). Podemos aumentar la cantidad mínima de apuesta a 4096 ETH y establecer un límite total de 4096 validadores (aproximadamente 16,7 millones de ETH). Se espera que los pequeños participantes se unan al grupo de DVT: ya sea proporcionando fondos o convirtiéndose en operadores de nodos. Para evitar abusos por parte de los atacantes, la función del operador del nodo debe estar limitada de alguna manera por la reputación, y los grupos competirán entre sí ofreciendo diferentes opciones a este respecto. La financiación no tendrá permiso.
Podemos hacer que las apuestas colectivas en este modelo sean más “indulgentes” limitando las sanciones, por ejemplo. a 1/8 del total aportado. Esto reducirá la confianza en los operadores de nodos, aunque vale la pena abordarlo con precaución debido a los problemas descritos aquí.
Método 2: compromiso de dos niveles
Creamos dos niveles de participantes: un nivel “pesado”, que requiere 4096 ETH, para participar en la finalización, y un nivel “ligero”, que no tiene requisitos mínimos de participación (tampoco hay retrasos en depósitos y retiros, y no hay riesgo de recortes). lo que agrega otra capa de seguridad. Para que un bloque sea definitivo, tanto la capa pesada debe finalizarlo como la capa ligera necesita >= 50% de los validadores ligeros en línea para dar fe de ello.
Esta heterogeneidad es beneficiosa para la resistencia a la censura y a los ataques, ya que tanto la capa pesada como la ligera deben corromperse para que un ataque tenga éxito. Si una capa está corrupta y otra no, la cadena se detendrá; si una capa pesada está corrupta, puede ser castigada.
Otro beneficio de este enfoque es que la capa ligera puede incluir ETH que también se utiliza como garantía en la aplicación. La principal desventaja es que hace que las apuestas sean menos equitativas al establecer una división entre pequeños y grandes apostadores.
Método 3: Participar por turnos (es decir, comité pero responsable)
El enfoque que adoptamos es similar al diseño del súper comité propuesto aquí: para cada intervalo de tiempo, seleccionamos 4096 validadores actualmente activos y ajustamos cuidadosamente este conjunto durante cada intervalo de tiempo para garantizar que permanezcamos seguros.
Sin embargo, hicimos algunas elecciones de parámetros diferentes para obtener el “máximo beneficio” dentro de este marco. En particular, permitimos que los validadores participen con saldos arbitrariamente altos, y si un validador posee más de una cierta cantidad M de ETH (que debe ser flotante), entonces participa en el comité en cada época. Si el verificador tiene N <M ETH，那么他们有 N/M 在任何给定时间段内进入委员会的概率。
Una palanca interesante que tenemos aquí es desacoplar el “peso” para fines de incentivo del “peso” para fines de consenso: la recompensa para cada validador dentro del comité debe ser la misma (al menos para los validadores con ≤M ETH), para mantener la recompensa promedio es proporcional. Aún podemos realizar un recuento por consenso de los validadores en el comité utilizando ETH como peso. Esto garantiza que romper la finalidad requiera una cantidad de ETH igual a más de un tercio de la cantidad total de ETH en el comité.
El análisis de la ley de Zipf calculará la cantidad de ETH de la siguiente manera:
En cada nivel cuadrático del saldo total, el número de validadores es inversamente proporcional a ese nivel de saldo, y el saldo total de estos validadores será el mismo.
Por lo tanto, el comité tendrá una cantidad igual de ETH participando de cada nivel de saldo, excepto los niveles por encima de la barrera M (los validadores siempre están en el comité).
Por lo tanto, tenemos el nivel Log2(M) para cada K validadores en el nivel anterior, y K+K/2+…=2K validadores de nivel superior. Por lo tanto, K=4096/Log2(M)+2.
El validador más grande tendrá M*k ETH. Podemos trabajar al revés: si el validador más grande tiene 2^18=262144 ETH, esto significa (aproximadamente) M = 1024 y k = 256.
La cantidad total de ETH prometido es:
Todos los derechos e intereses de los 512 validadores principales (2^18*1+2^17*2+……+2^10*2^8=2359296)
Más apuestas más pequeñas del muestreo aleatorio (2^8*(2^9+2^8+2^7…) es aproximadamente igual a 2^8*2^10=2^18)
Obtuvimos un total de 2621440 ETH, o el costo del ataque fue de aproximadamente 900k ETH.
La principal desventaja de este enfoque es que introduce algo más de complejidad dentro del protocolo para seleccionar validadores al azar de una manera que nos permita lograr un consenso de seguridad cuando cambia el comité.
Su principal ventaja es que conserva una forma reconocible de apuesta independiente, conserva un sistema único e incluso permite reducir la cantidad mínima de apuesta a niveles muy bajos (por ejemplo, 1 ETH).
Resumir
Si determinamos que detrás del protocolo SSF, queremos seguir con 8192 firmas, lo que facilitará la vida de los implementadores técnicos, así como de los constructores de infraestructura de soporte, como los clientes ligeros. Resulta más fácil para cualquiera ejecutar un cliente de consenso, y los usuarios, los entusiastas de las apuestas y otros pueden trabajar inmediatamente en esta suposición. La carga futura del protocolo Ethereum ya no es una incógnita: podría mejorarse en el futuro mediante bifurcaciones duras, pero sólo si los desarrolladores están convencidos de que la tecnología ha mejorado lo suficiente como para poder manejar más firmas por intervalo de tiempo con la misma facilidad.
El resto será decidir cuál de los tres enfoques anteriores queremos adoptar, o quizás un enfoque completamente diferente. Será una cuestión de con qué compensaciones nos sentimos cómodos, especialmente cómo solucionamos los problemas involucrados, como las apuestas de liquidez, que probablemente puedan resolverse por separado de los problemas técnicos que se están volviendo más fáciles ahora.
