Título original: “Apegarse a 8192 firmas por ranura post-SSF: cómo y por qué”
Artículo original de Vitalik Buterin, ETH investigación
Compilación original: Luccy, BlockBeats
*Nota del editor: SSF (Single Slot Finality) significa Single Slot Finality, que proporciona una forma de reducir significativamente la latencia de Ethereum. En el Mecanismo de Consenso de Blockchain, la finalidad significa que una transacción o Bloque se vuelve irrevocable, lo que garantiza que no pueda ser manipulado o revertido. Lograr la finalidad es esencial para la confianza y la seguridad de los sistemas de descentralización, ya que elimina el riesgo de doble gasto y otras actividades maliciosas. *
El SSF sugiere que en el Mecanismo de Consenso de Blockchain, un solo intervalo de tiempo o unidad de tiempo puede considerarse “final”. A diferencia del EthereumConsensus original, permite que todos los validadores participen en el reconocimiento o la firma de ranuras, lo que reduce el tiempo de confirmación de las transacciones y mejora la experiencia general del usuario. *
Vitalik “regresa” ETH investigación explora por qué es necesario que los validadores participantes tengan dos firmas por ranura después de SSF, es decir, para llegar a 8192 firmas, y presenta 3 hipótesis sobre cómo lograr este objetivo, a saber, staking completo, participación de dos niveles y participación rotativa, analiza cómo manejar el número de firmas por ranura de manera más eficiente mientras se mantiene la seguridad del protocolo, y discute sus ventajas y desventajas y el impacto en el protocolo y los usuarios. BlockBeats compiló el texto original de la siguiente manera:*
Una diferencia importante entre Ethereum y la mayoría de los otros sistemas PoS (con finalidad) es que Ethereum se esfuerza por admitir un gran número de validadores: actualmente tenemos 895.000 validadores, lo que el análisis de la ley de Zipf muestra que equivale a decenas de miles de personas o entidades independientes. El propósito de esto es apoyar la descentralización, permitiendo que la gente común participe en el staking sin requerir que todos renuncien a su capacidad de actuar y entreguen el control a uno de los pocos grupos de staking.
Sin embargo, este enfoque requiere que la cadena Ethereum procese un gran número de firmas por ranura (unas 28.000 en la actualidad; 1.790.000 después de SSF), lo que supone una carga muy alta. Para soportar esta carga, se deben hacer una serie de sacrificios técnicos:
Un sistema de agregación de firmas puede parecer razonable a primera vista, pero en realidad crea una complejidad sistémica que impregna todo el sistema.
Es más, ni siquiera logró sus objetivos. El requisito mínimo para hacer staking sigue siendo de 32 ETH, lo que está fuera del alcance de mucha gente. Desde el punto de vista del análisis lógico, el objetivo de un sistema que permita a todo el mundo firmar cada slot a largo plazo no parece factible para proporcionar realmente staking a la gente común: si Ethereum tiene 500 millones de usuarios, el 10% de los cuales participan en el staking, eso significa 100 millones de firmas por sranura. Desde el punto de vista de la teoría de la información, las penalizaciones de procesamiento en este diseño requieren al menos 12,5 MB de espacio libre de datos por ranura, lo que equivale aproximadamente al objetivo de la fragmentación completa. Puede ser posible, pero exigir que el propio staking se base en el muestreo de disponibilidad de datos es una gran ganancia de complejidad. E incluso entonces, solo alrededor del 0,6% de la población mundial participa en el staking, y aún no ha comenzado a implicar el problema computacional de verificar tantas firmas.
Entonces, en lugar de confiar en la criptografía para crear balas mágicas (o a prueba de balas mágicas) para lograr un número cada vez mayor de firmas por ranura, sugiero un cambio filosófico: primero abandone tales expectativas. Esto ampliaría en gran medida el espacio de diseño de PoS y permitiría una gran simplificación técnica, lo haría más seguro al permitir que Helios hiciera SNARK directamente en el EthereumConsensus, y resolvería el problema de la resistencia cuántica haciendo factible incluso un esquema de firma poco interesante pero de larga data como Winternitz.
Muchas de las cadenas de bloques que no son de Ethereum que se enfrentan a este problema exacto adoptan un enfoque de seguridad basado en comités. Durante cada ranura, seleccionan aleatoriamente N validadores (por ejemplo, N ≈ 1000) que son responsables de confirmar en última instancia la ranura. Vale la pena recordar por qué este enfoque no es suficiente, ya que no proporciona rendición de cuentas.
Para entender por qué, digamos que ocurrieron el 51% de los ataques. Esto podría ser un ataque de reversión terminal o un ataque de censura. Para llevar a cabo el ataque, todavía es necesario que el actor económico controle la mayoría de la participación para acordar el ataque, es decir, ejecutar el software involucrado en el ataque y participar en el ataque con todos los validadores que finalmente son elegidos para el comité. El muestreo matemáticamente aleatorio garantiza esto. Sin embargo, las sanciones que recibieron por esto fueron mínimas, ya que la mayoría de los validadores que aceptaron el ataque no fueron finalmente elegidos para el comité y, por lo tanto, no fueron vistos.
Actualmente, Ethereum hace exactamente lo contrario. Si se produce un ataque del 51%, se cortará el depósito de la mayoría de toda la colección de validadores de ataques. El coste actual del ataque es de unos 9 millones de ETH (unos 20.000 millones de dólares), y se supone que la interrupción de la sincronización de la red se lleva a cabo de la manera más favorable para el atacante.
Creo que es un costo alto, pero es un precio demasiado alto a pagar, y podemos hacer algunos sacrificios en este tema. Incluso un coste de ataque de 1-2 millones de ETH es perfectamente suficiente. Además, el principal riesgo de centralización que existe actualmente en Ethereum se refleja en un lugar completamente diferente: si la cantidad mínima de depósito se reduce a casi cero, el poder de los grupos de participación a gran escala no disminuirá mucho.
Es por eso que estoy abogando por una solución intermedia: hacer algunos sacrificios en las responsabilidades de los validadores, pero aún así mantener una cantidad alta de ETH total recortable y, a cambio, podemos disfrutar de la mayoría de los beneficios de un conjunto más pequeño de validadores.
Suponiendo un protocolo de consenso tradicional de dos rondas (como el protocolo utilizado por Tendermint y el protocolo que SSF utiliza inevitablemente), cada validador participante necesita dos firmas por ranura. Tenemos que abordar esta realidad, y veo que hay tres formas principales de resolver este problema.
El Zen de Python contiene una frase muy crucial:
Debería haber una, y preferiblemente solo una, forma obvia de hacerlo. )
Ethereum está violando actualmente esta regla cuando se trata de hacer que el staking sea igualitario, ya que estamos implementando simultáneamente dos estrategias diferentes para lograr este objetivo: (i) staking independiente a pequeña escala, y (ii) pools de staking de descentralización utilizando tecnología de validación distribuida (DVT). Por las razones anteriores, (i) solo se puede admitir a unos pocos stakers individuales, y siempre habrá muchas personas cuyo monto mínimo de depósito sea demasiado grande. Sin embargo, Ethereum está pagando un costo de carga técnica muy alto para soportar (i).
Una posible solución es darse por vencido (i) e ir a por todas (ii). Podemos aumentar el monto mínimo de depósito a 4096 ETH y establecer el límite total del validador en 4096 (alrededor de 16,7 millones de ETH). Se espera que los stakers de pequeña escala se unan al grupo de DVT: proporcionando capital o convirtiéndose en operadores de nodos. Para evitar el abuso por parte de los atacantes, el rol de operador de nodo debe estar limitado por el umbral de prestigio de alguna manera, y los grupos competirán ofreciendo diferentes opciones en este sentido. La aportación de capital será sin permiso.
Podemos hacer que el staking en este modelo sea más “indulgente” estableciendo un límite de penalización (por ejemplo, 1/8 del depósito total proporcionado). Esto permitirá una menor confianza en los operadores de Node, aunque vale la pena tratarlo con precaución debido a los problemas descritos.
Creamos dos capas de stakers: una capa “pesada” que requiere 4096 ETH para participar en la confirmación del estado final, y una capa “ligera” sin requisitos mínimos (sin retrasos en los depósitos y retiros, sin vulnerabilidades de corte), agregando una segunda capa de seguridad. Para que se confirme el estado final de un bloque, se requiere tanto una confirmación del estado final de la capa pesada como al menos el 50% de la capa ligera de pruebas de validación ligera en línea.
Esta heterogeneidad es beneficiosa para la censura y la resistencia a los ataques, ya que tanto las capas pesadas como las ligeras deben corromperse para que un ataque tenga éxito. Si una capa está dañada y la otra no, la cadena se detendrá, y si la capa pesada está corrompida, puede ser castigada.
Otro beneficio de esto es que el nivel ligero puede contener ETH que también se usa como garantía en la aplicación. El principal inconveniente es que el staking se vuelve menos equitativo al establecer una división entre los stakers a pequeña escala y los de gran escala.
Adoptamos un enfoque similar al diseño del supercomité propuesto aquí: para cada ranura, seleccionamos 4096 validadores actualmente activos y ajustamos cuidadosamente el conjunto en cada ranura para que aún tengamos seguridad.
Sin embargo, hicimos algunas elecciones de parámetros diferentes dentro de este marco para obtener una “relación calidad-precio”. En particular, permitimos que los validadores participen con saldos arbitrariamente altos, y si los validadores tienen más de una cierta cantidad de ETH (que tendría que ser flotante), participan en comités en cada ranura. Si un validador tiene N<M ETH, entonces tiene una probabilidad de N/M en cualquier espacio dado para participar en el comité.
Aquí tenemos una palanca interesante para desacoplar el “peso” en el propósito del incentivo del “peso” en el propósito del Consenso: la recompensa para cada validador en el comité debe ser la misma (al menos para los validadores que usan ≤M ETH) para mantener la recompensa promedio proporcional al saldo, pero aún podemos calcular los pesos de los validadores de consenso en el comité ponderando ETH. Esto asegura que la cantidad de ETH necesarios para romper la finalidad sea igual a más de 1/3 del total de ETH en el comité.
Un análisis aproximado de la ley de Zipf calcula esta cantidad de ETH de la siguiente manera:
Nota: Para mostrar los datos calculados con mayor claridad, los siguientes pasos serán capturas de pantalla

La principal desventaja de este enfoque es un ligero aumento en la complejidad de la selección aleatoria de validadores en el protocolo para que podamos obtener seguridad de consenso en caso de cambios en el comité.
La principal ventaja es que conserva el staking independiente de forma reconocible, mantiene un sistema de una sola clase e incluso permite que la cantidad mínima de depósito se reduzca a un nivel muy bajo (por ejemplo, 1 ETH).
Si decidimos quedarnos con las firmas 8192 después del protocolo SSF, el trabajo será mucho más fácil para los implementadores de tecnología y los constructores de infraestructura secundaria, como los clientes ligeros. Los clientes de consenso pueden ser administrados más fácilmente por cualquier persona, y los usuarios, los entusiastas del staking y otros pueden trabajar inmediatamente en esta suposición. La carga futura del protocolo Ethereum ya no es desconocida: el futuro puede ser impulsado por una bifurcación dura, pero solo si los desarrolladores confían en que la tecnología ha mejorado lo suficiente como para manejar más firmas por ranura con el mismo nivel de facilidad.
El resto del trabajo consistirá en decidir cuál de los tres métodos queremos adoptar, o tal vez un enfoque completamente diferente. Va a ser una cuestión de con qué compensaciones nos sentimos cómodos, específicamente cómo lidiamos con problemas relacionados como el staking líquido, que pueden resolverse por separado de los problemas técnicos que ahora son mucho más fáciles.
Enlace al artículo original