20.000 palabras: El debate sobre la seguridad de los Rollups

¿Los Rollups heredan la seguridad?

Escrito originalmente por Jon Charbonneau

Compilado originalmente por Frank, Foresight News

Introducción

Te guste o no, Twitter probablemente nunca dejará de discutir sobre si "L2" o Rollup es "heredar seguridad".

Si bien la mayoría de los debates son batallas semánticas indiscernibles, si logras reducir el argumento, los puntos subyacentes son valiosos porque tocan las preguntas centrales de cuándo, dónde y por qué Rollup tiene sentido.

¿La L2 escalable elimina la necesidad de L1 en el mercado? ¿Es posible convertir una L1 como Solana en una L2?

Estos debates se reducen principalmente a cuestiones de seguridad. Desafortunadamente, la definición de "seguridad" aquí siempre ha sido muy difícil de alcanzar. Por lo general, usamos este término de manera casual, y la mayoría de la gente sabe aproximadamente de lo que estamos hablando, pero no completamente. Aquí desglosaremos la seguridad en detalle en diferentes arquitecturas.

Definición de palabra de moda

Paquete acumulativo

Anteriormente utilicé la siguiente definición de Mustafa: "Rollup es una cadena de bloques que publica sus bloques en otra cadena de bloques y hereda el consenso y la disponibilidad de datos (DA) de esa cadena de bloques".

La siguiente es una definición más general dada por James Prestwich: "Rollup es una forma de optar por otro mecanismo de consenso mediante la personalización de las funciones de transición de estado y la preservación del estado de superconjunto".

Ninguno de los dos requiere un puente de verificación, y la capacidad de construir puentes entre cadenas con suposiciones de confianza mínimas es un beneficio importante de Rollup, pero analizarlos por separado es crucial.

Podemos tener en cuenta los siguientes criterios de acumulación:

• Rollup es un sistema con estado (por ejemplo, blockchain) derivado de la ejecución de una función de transición de estado (STF) personalizada en la entrada de datos en la cadena principal (capa DA).
• Todos los datos de entrada (es decir, datos completos de la transacción o diferencias de estado) utilizados para derivar el estado de confirmación final de la cadena remota (es decir, Rollup) se confirman en la cadena principal.
• Dado que el estado del resumen se deriva de la función de transición de estado (STF) que se ejecuta en los datos de la cadena principal, la validez del resumen depende de la validez de la cadena principal. A continuación, el nodo Rollup debe verificar completamente el consenso y la validez de la cadena principal (o hacer una suposición mayoritaria honesta sobre la cadena principal);

El nodo Rollup determina el estado de Rollup en el resultado de consenso de la cadena principal (como la cadena principal que confirma el orden y la disponibilidad de los bloques de datos) mediante la aplicación de su propia función de transición de estado (STF).

Puente de cadena cruzada

Un puente entre cadenas es un sistema que permite que dos cadenas de bloques se comuniquen entre sí. La cadena A (la cadena objetivo) necesita estar segura de que algo ha sucedido en la cadena B (la cadena de origen) y viceversa. Idealmente, queremos que esta comunicación sea bidireccional, con atributos de seguridad fuertemente correlacionados (por ejemplo, alta confianza en que el mensaje es válido, la cadena de origen no se deshará, etc.).

Fundamentalmente, el puente entre cadenas actúa como un "observador" de otra cadena de bloques (como cualquier otro usuario humano típico). El puente entre cadenas implementa una regla de confirmación dada por la que está convencido del estado de la cadena conectada (por ejemplo, cuántos bloques de Ethereum deben pasar para aceptar entradas de transferencia).

• Los puentes tradicionales entre cadenas suelen ejecutar nodos ligeros validadores de consenso en cadena de la cadena de origen (es decir, lo que sea que confíen en la mayoría de los signos de consenso);
• Los puentes entre cadenas pueden proporcionar atributos de seguridad más fuertes al actuar como nodos ligeros de validación completa (es decir, agregar muestreo de disponibilidad de datos (DAS) + validez/prueba de fallo). Por ejemplo, es posible que el validador de una cadena deba ejecutarse en todos los nodos ligeros DAS que conectan la cadena, lo cual es una alternativa más liviana que un nodo completo que requiere que el validador ejecute la cadena conectada;
• El puente de cadena cruzada Rollup también puede conservar la actividad y la resistencia de la cadena principal (porque Rollup debe compartir el consenso de la cadena principal);

Puente desde la cadena principal → Rollup

Esta dirección es muy sencilla, ya que el nodo Rollup verifica completamente la cadena principal.

Los nodos Rollup saben todo lo que sucede en la cadena principal, por lo que saben cuándo se producen las transacciones puente entre cadenas, y el nodo completo actual de Ethereum Rollup también debe ejecutar el nodo completo para la propia capa base de Ethereum.

Tenga en cuenta que los nodos Rollup también pueden ejecutar un nodo ligero de validador completo de su cadena principal en su lugar, si se admite. Consideremos un ejemplo hipotético en el que Ethereum ha implementado completamente las siguientes actualizaciones:

• Bloques de ejecución de Ethereum con prueba de validez (la investigación de zkEVM en la capa base está en curso);
• Ethereum ha implementado un DAS completo, por lo que los nodos pueden muestrear el DA;
• La capa de ejecución de Ethereum publica sus datos como blobs en la capa de datos, al igual que cualquier otro rollup en Ethereum (por ejemplo, los datos de la capa de ejecución de Celestia se publicarán en su capa DA, por lo que los nodos DAS comprobarán la disponibilidad de los datos de Rollup y la propia capa de ejecución de Celestia);
• Ethereum proporciona una prueba completa de consenso en lugar de depender de comités de sincronización (por ejemplo, a través de la integración de validadores, una mejor agregación de firmas, una posible prueba de consenso de ZK, etc.);

Ahora, suponiendo que desee ejecutar un nodo completo para un rollup basado en Ethereum, para seguir una cadena de rollup válida, debe comprender la cadena canónica de Ethereum, que requiere verificar el consenso y la validez de Ethereum en sí:

• Consenso de Ethereum: cualquier cliente de nodo ligero puede rastrear el consenso firmado como cadena de bloques, encabezado de bloque;
• DA de la capa de ejecución propia de Ethereum: los nodos de Rollup muestran la capa DA de Ethereum, comprobando la disponibilidad de los datos de Rollup y los datos de la propia capa de ejecución de Ethereum (tenga en cuenta que los nodos DAS todavía hacen algunas suposiciones adicionales sobre los nodos completos, como veremos más adelante);
• Validez de estado propia de Ethereum: con zkEVM, cada bloque de Ethereum viene con una prueba de validez;

Los nodos Rollup deben comprobar la validez de estado y el DA de la propia capa de ejecución de Ethereum, ya que estas son las condiciones de validez de los bloques de Ethereum. El nodo Rollup necesita saber que no solo rastrea Ethereum donde se ha firmado el consenso, sino también que es un encabezado de bloque válido. Por ejemplo, pueden rastrear accidentalmente bloques de Ethereum que están firmados por consenso pero no son válidos (por ejemplo, genera una gran cantidad de ETH).

Si la propia capa de ejecución subyacente publica sus datos en la capa DA (al igual que otros resúmenes) y agrega validez o prueba de error, se convierte en un paquete acumulativo integrado.

Puente desde el Rollup → cadena principal

Esta dirección es complicada, porque la cadena principal no conoce el estado de Rollup y STF de forma predeterminada (es decir, los nodos de Ethereum no necesitan ejecutar nodos de Rollup). Para que la cadena principal crea en el estado del rollup, puede implementar la lógica del rollup en el contrato inteligente implementado en la cadena principal (es decir, el contrato puente de verificación del rollup). Este contrato inteligente comprueba la validez de los estados DA y Rollup.

Una vez más, este puente de cadena cruzada es opcional. Los contratos inteligentes en la cadena principal se utilizan para convencer a todos los nodos de la cadena principal de la validez de Rollup, que permite la comunicación bidireccional bajo supuestos de buena confianza.

Acumulativos, coprocesadores e intenciones

Como se ha comentado, los Rollups guardan parte de su propio estado (el estado de Rollup) además de poseer el estado de su cadena principal (por ejemplo, Ethereum). Entonces, ¿CoW Swap tiene su propio estado que no forma parte del estado de Ethereum? Si es así, entonces suena como un rollup. Si no es así, entonces podría ser un "coprocesador".

Sin embargo, incluso esta pregunta no es tan simple como parece:

En cambio, se podría pensar que el factor distintivo es la persistencia del estado:

Si CoW Swap permite a participantes específicos proporcionar a los usuarios preconfirmaciones rápidas (más rápidas que el tiempo de bloque de Ethereum) y promete pedidos que incluyen lotes, dado que el procesamiento por lotes de Ethereum lleva más tiempo de lo que a la mayoría de los usuarios les gustaría, ¿es ahora un rollup?

Chris Goes tocó este tema en su charla en la Cumbre de Modularidad, comenzando con una definición aproximada de intenciones: "el compromiso de una función de preferencia para un espacio de estado del sistema dado".

Tenga en cuenta las similitudes entre la resolución parcial (intención de coincidencia) y la ordenación consolidada. El operador obtiene el mensaje firmado fuera de la cadena del usuario → publica los datos resultantes en la cadena principal.

• Aplicaciones basadas en la intención: los cambios de estado resultantes se resuelven en la cadena (por ejemplo, en el ejemplo de CoW Swap, la aplicación está en la cadena subyacente, por lo que los tokens se intercambian allí);
• Aplicación Rollup: utiliza los datos enviados a la cadena principal para calcular los cambios de estado generados por Rollup;

Las arquitecturas centradas en la intención y las arquitecturas centradas en Rollup logran objetivos similares desde direcciones opuestas. El enfoque centrado en la intención aborda este problema de manera amplia desde la perspectiva de los usuarios y las aplicaciones, y el enfoque centrado en Rollup aborda este problema de manera amplia desde la perspectiva de diferentes cadenas de bloques.

Aquí, no es importante establecer límites distintivos específicos. Además, descubrimos que Rollup en realidad no es muy diferente de las aplicaciones a las que nos hemos acostumbrado con la coincidencia de intenciones fuera de la cadena.

Confía en los participantes fuera de la cadena (secuenciadores frente a solucionadores/rellenos, etc.) para obtener algunas garantías más débiles, como proporcionar la mejor ejecución y una buena experiencia de usuario → determinar el resultado en función de los datos publicados en la cadena principal. Sin embargo, no mantienen sus fondos en custodia.

A medida que la computación verificable fuera de la cadena se vuelve más importante, las líneas entre los dos pueden volverse borrosas:

Si quieres que el solucionador de intenciones o el ordenador de paquetes acumulativos sean menos confiables...

Cadena de bloques modular y cadena de bloques monolítica

Las cadenas de bloques monolíticas (también conocidas como cadenas de bloques integradas) a menudo se definen como cadenas que integran verticalmente todas las funciones principales, es decir, consenso, DA y ejecución. Asumen toda la responsabilidad de su propia seguridad, y Solana y Cosmos Hub son excelentes ejemplos.

Las capas DA (como Ethereum y Celestia) a menudo se denominan cadenas de bloques "modulares" porque subcontratan la ejecución a Rollup, pero esto no es del todo exacto. También son responsables de forma independiente de su propio consenso, DA y aplicación.

Incluso la ejecución de Celestia será limitada (por ejemplo, transferencias, staking, cross-chain). Del mismo modo, si alguien inicia Rollup sobre Solana, no se convertirá mágicamente en una cadena de bloques "modular".

Entonces, cuando escuche a la gente referirse a cadenas como Ethereum o Celestia como cadenas de bloques "modulares", tenga en cuenta que esta es más una distinción práctica que estrictamente técnica. A menudo, ambos optimizan sus propias arquitecturas para admitir Rollup. Se espera que estos rollups manejen la mayor parte de la ejecución de operaciones dentro de su alcance.

Incluso Rollup no es necesariamente completamente "modular": el secuenciador de Rollup puede acordar la secuencia de transacciones, proporcionar DA y ejecutar transacciones antes de que la cadena principal haga algo. Así es como los usuarios obtienen la preconfirmación. A continuación, la cadena principal proporciona otro compromiso "final", declarando de nuevo el DA y el consenso sobre el orden de las transacciones de Rollup.

Enrollables y cadenas integradas

Para nuestros propósitos, la distinción más importante es "Rollup" o "Non-Rollup". ¿El estado final de la cadena se origina a partir de los datos publicados en una cadena principal separada (es decir, la capa DA)?

Si bien hoy en día asociamos el DAS y la validez/prueba de falla con los rollups tradicionales, debemos tener en cuenta que estos son conceptos lógicamente diferentes. En teoría, cualquier "cadena de integración" (como una cadena de aplicaciones típica de Cosmos) se puede actualizar para agregar DAS y pruebas de validez sin tener que publicar sus datos en otras cadenas principales externas como Ethereum. El nodo muestreará y comprobará la cadena por separado.

Vitalik habla de esta diferencia en su Endgame:

Puede notar que una "gran cadena de bloques tradicional" (cadena de integración) con DAS + validez/prueba de falla puede terminar pareciendo un "rollup consagrado". Del mismo modo, "un rollup escalable y dominante" podría tener tanto éxito que simplemente se fusione con su cadena principal para dar cabida a ese rollup.

Los límites de la distinción se difuminan en el límite.

Por lo tanto, si cree que la efectividad de DAS+ / prueba de falla es el resultado final, entonces "Rollup" en cierto sentido es inevitable. Hay una diferencia válida entre los dos métodos en el diagrama anterior:

• "Rollups", también conocido como "modularidad": construya cadenas lógicamente independientes, publique datos en su cadena principal (capa DA) y reutilice el consenso de la cadena principal;
• "Cadena de bloques integrada", también conocida como "cadena de bloques monolítica": integra todo en un protocolo con su propio consenso, sin publicar datos en una cadena principal separada (incluso si la capa DA y la capa de ejecución son partes lógicamente separadas del protocolo compartido en cierto sentido);

Cuando hablamos de "Rollup" en este informe, nos referimos al primero (es decir, no a una cadena de integración con DAS + validez/prueba de fallo, que puede denominarse Rollup incorporado).

Si bien el Rollup "tradicional" no tiene el monopolio de DAS o pruebas (es decir, las grandes cadenas de bloques integradas pueden agregarlas), tenga en cuenta que estamos pasando por alto muchos detalles técnicos aquí, y no puede simplemente elegir Solana y decidir "Oh, supongo que agregaremos DAS hoy".

Esto requiere una refactorización fundamental del protocolo para comenzar a acercarse a lo que estamos viendo hacer Ethereum y Celestia:

Cambiar la forma en que se codifican los datos para admitir DAS equivaldrá a ralentizar la codificación y propagación de bloques, comenzando a acercarse a la capa DA tradicional:

Por esta razón, vemos que el equipo construye lo siguiente:

• Capas DA especializadas (por ejemplo, Danksharding de Ethereum, Celestia, etc.) - bloques lentos + DAS;
• Secuenciadores compartidos (por ejemplo, Espresso, Astria o incluso Solana) - realmente solo capas DA rápidas, no se requiere DAS;

Sin embargo, si separa el tiempo de los fragmentos rápidos y DAS, no son necesariamente compatibles. Por ejemplo, puedes imaginar una cadena como Solana que ofrece dos caminos diferentes:

• Ruta rápida: continuar ejecutando transacciones y difundiendo datos lo más rápido posible (como lo es hoy);
• Ruta lenta: codificar los datos después del hecho de manera que se pueda llevar a cabo un muestreo asíncrono, lo que proporciona la seguridad de que los nodos DAS están ligeramente por detrás del consenso;

Anatoly analiza en el podcast cómo Eclipse reúne a Ethereum, Celestia y Solana, y desde el otro extremo del espectro, puede imaginar que la capa DA agregue una ruta más rápida antes de que los datos estén disponibles para el muestreo:

Proporcionar dos rutas en el mismo protocolo de capa base internaliza de manera efectiva la clasificación compartida rápida, lo que proporciona un diseño interesante basado en Rollup. Tenga en cuenta que por el momento esta es todavía una idea muy exploratoria.

Confirmar la regla

Con esos antecedentes, ahora podemos comenzar a desglosar los atributos de seguridad de estas diferentes arquitecturas.

En primer lugar, los nodos interactúan con cualquier cadena de bloques mediante la ejecución de "reglas de confirmación":

"Las reglas de confirmación se refieren al algoritmo que ejecuta un nodo para generar si un bloque está confirmado o no. En este caso, bajo ciertos supuestos, que involucran principalmente la sincronización de la red y el porcentaje de acciones honestas, cuando se cumplan estas condiciones, el bloque tendrá garantizado que nunca se producirá una reorganización".

Puede haber cualquier número de reglas de confirmación para una cadena determinada:

• ¿Cuántos bloques hay que esperar antes de confirmar una transacción de Bitcoin? 1 ？ 6 ？ 10 ？
• ¿Usas LMD GHOST para confirmar bloques basados en el libro mayor utilizable de Ethereum, o esperas a que el gadget final (Casper FFG) lo confirme?
• ¿Ejecuta nodos completos que verifican directamente cada bloque, o solo nodos ligeros que verifican la firma de consenso?
• ¿Acabas de preguntarle a Infura?

Dado que cada regla de confirmación puede hacer suposiciones muy diferentes, pueden tener propiedades de seguridad muy diferentes incluso cuando interactúan con la misma cadena:

Esta distinción es sutil pero importante:

Seguridad = Seguridad + Actividad

Ahora profundicemos en si Rollup "hereda la seguridad" de su cadena principal.

La herencia, y quizás más claramente, Rollup siempre "alquila" en lugar de "heredar" cualquier cosa en su cadena principal, paga un costo continuo por los recursos consumidos (DA) y cualquiera de las partes puede optar por terminar la relación. Pero esa no es la parte interesante del problema.

Seguridad, a partir de ahora nos centraremos en la seguridad. La seguridad de un algoritmo consiste en Seguridad y Vida:

• Seguridad (no pasará nada malo), el estado final determinado por dos nodos sanos nunca entrará en conflicto;
• Liveness (eventualmente sucederán cosas buenas), todos los nodos en buen estado completarán un nuevo estado que refleje las transacciones incluidas dentro de un tiempo limitado;

Usando el excelente marco de Sreeram, podemos dividirlos en cinco atributos que trabajan juntos para asegurar las reglas de confirmación:

Consideremos un ejemplo de una hipotética cadena de integración con DAS + validez/prueba de fallo. Sus datos no se publican en ninguna otra cadena principal externa. Para simplificar, asumimos una finalización instantánea (por ejemplo, Tendermint), por lo que no hay una distinción utilizable entre un libro mayor disponible y un libro mayor finalizado (por ejemplo, Gasper de Ethereum).

Consideraremos tres reglas de confirmación que se pueden usar para rastrear la cadena utilizando diferentes tipos de nodos:

• Nodo ligero validador de consenso: verifica la prueba de consenso (es decir, confía en el consenso de la mayoría honesta).
• Nodo ligero de validador completo: verifique el consenso + verifique DA (usando DAS) + verifique la validez del estado (usando validez / prueba de falla);
• Nodo completo - consenso de verificación + verificación directa de DA (descarga de todos los datos) y validez (ejecución de todas las transacciones y cálculo del estado);

Confirme que la regla tiene atributos de seguridad, la cadena no

De nuevo, "hablamos coloquialmente de que una cadena es segura, pero en realidad es una regla de confirmación adjunta al atributo de seguridad".

Veamos algunos ejemplos.

Teorema CAP

Como antecedente, el teorema CAP nos dice que ningún libro mayor puede satisfacer estas dos condiciones al mismo tiempo:

Adaptabilidad (también conocida como disponibilidad dinámica): mantenerse activo con participación dinámica (es decir, si la mayoría de los nodos están fuera de línea); Finalidad (también conocida como consistencia): mantener la seguridad bajo particiones de red;

Los protocolos de consenso tienden a dividirse en dos partes, cada una de las cuales satisface una de las condiciones anteriores:

• Protocolos de cadena más larga: estos protocolos (por ejemplo, el Consenso Satoshi de Bitcoin) garantizan la actividad incluso cuando el número de nodos participantes activos es variable (es decir, son adaptativos), sin embargo, no son seguros (es decir, no son definitivos) bajo la partición de la red; Protocolos de tipo BFT: los protocolos de consenso clásicos (por ejemplo, PBFT) alcanzan la finalidad pero no la adaptabilidad;

Reglas de confirmación de Bitcoin

El consenso de Bitcoin no proporciona ninguna finalidad económica dura.

Los nodos observan la cadena más larga en su vista local, y cada usuario es libre de aplicar cualquier regla de confirmación que desee (por ejemplo, aceptar bloques con confirmaciones >k). Lo normal es esperar a que se confirmen 6 bloques, pero tú decides.

Para transacciones de mayor valor, es razonable esperar más tiempo. Existe un equilibrio entre el tiempo de espera y la seguridad, es decir, la posibilidad de reorganización.

Reglas de confirmación de Ethereum

El consenso PoS de Ethereum (Gasper) parece a primera vista eludir el teorema CAP. Sin embargo, implementa estas dos propiedades porque contiene dos libros de contabilidad anidados:

• Libro mayor disponible dinámicamente: si la red no está particionada, es segura y activa con participación dinámica;
• Libro mayor de prefijos finalizado: siempre seguro y protegido. Si la red no está particionada y participan suficientes nodos, permanece activa;

Gasper pertenece a la familia de protocolos "ebb-and-flow" (también conocida como doble libro mayor o regla de doble confirmación). El diseño de dos libros de contabilidad queda fuera del alcance del teorema CAP (es decir, asume una única regla de confirmación). Cuando se particiona la red, el libro mayor finalizado se retrasa con respecto al libro mayor adaptable, pero se pone al día cuando se repara la red.

Esto permite que el equilibrio entre adaptabilidad y finalidad se aborde a nivel de usuario y no a nivel de todo el sistema. Esta es una característica del protocolo de "cadena más larga de puntos de control" propuesto por el teorema CAP de blockchain en términos de adaptabilidad y finalidad en la que los usuarios pueden confiar. Estos protocolos ofrecen a los usuarios individuales la posibilidad de elegir entre la finalidad y la adaptabilidad, en lugar de imponerla a nivel general del sistema.

Gasper expone explícitamente dos reglas de confirmación diferentes, asignadas a los dos libros de contabilidad mencionados anteriormente:

• Reglas disponibles dinámicamente: adaptabilidad garantizada. Respete el encabezado del bloque de la cadena más larga. LMD GHOST es una regla de selección de bifurcación que se utiliza para determinar el subárbol más pesado;
• Reglas de finalización - Garantiza la certeza final. Respeta los bloqueos confirmados por los artilugios finales. Los FFG de Casper son dispositivos finales que se aplican además de las reglas de selección de horquillas;

Como se discute en el documento:

"Las reglas adaptativas más optimistas siempre confirman los bloques marcados como finalizados por las reglas más conservadoras, y pueden confirmar más bloques durante los niveles de participación variables. Los clientes (usuarios) eligen localmente entre las reglas de confirmación en función de sus preferencias personales, mientras que los mineros siguen reglas de propuesta de bloques fijos que son consistentes con estas dos reglas de confirmación".

Esto permite que todos los nodos (honestos) del sistema:

• Seguir un mecanismo común de propuesta de bloques;
• Sin embargo, diferentes nodos pueden elegir diferentes reglas de confirmación;

Los validadores continúan alargando la cadena más larga (minando nuevos bloques a alturas cada vez mayores), independientemente del nivel de participación, pero solo cuando haya suficiente participación, aparecerán nuevos puntos de control.

La cadena más larga (que contiene el punto de control más reciente) puede alternar entre diferentes cadenas (es decir, volver a ensamblar bloques incompletos), pero se garantiza que el punto de control está en una sola cadena independientemente de las condiciones de la red (es decir, la finalidad).

La seguridad de los usuarios depende de las reglas de confirmación que sigan. Existe un equilibrio entre el reconocimiento rápido de bloques y las garantías de seguridad más sólidas. Los usuarios que venden café pueden preferir la actividad a la seguridad, pero los usuarios que venden yates pueden preferir la seguridad a la actividad.

Los nodos de Ethereum también pueden aplicar otras heurísticas de reglas de confirmación intermedias con fines prácticos. En lugar de usar bloques k ingenuos como una regla de confirmación adaptativa, como lo hace Bitcoin, podemos agregar otras heurísticas que incluyen suposiciones sobre la sincronización de la red y la honestidad del validador.

Esto es exactamente lo que se propone en las Reglas de Confirmación del Protocolo de Consenso de Ethereum, que proponen reglas de confirmación con las siguientes propiedades:

• En condiciones ideales, la regla confirmará un nuevo bloque inmediatamente después de su ranura;
• En condiciones típicas de la red principal, la regla debería ser capaz de confirmar la mayoría de los bloques nuevos en un minuto;

Esta regla de confirmación no sustituye a la finalidad económica. En su lugar, proporciona una heurística útil para los usuarios que creen que la sincronización de red se mantendrá en un futuro próximo. Comparemos los dos:

Consideremos algunos ejemplos, como si vendes un yate por 2,5 millones de dólares en ETH, aquí tienes algunas posibles reglas de confirmación:

• Nodo completo + esperando el resultado final: incluso una mayoría maliciosa de validadores no puede engañarlo para que acepte bloques no válidos (por ejemplo, producir ETH falso). Si le pagan $ 2.5 millones en ETH y luego intentan reestructurar el bloque finalizado más tarde, incurrirán en un costo enorme (al menos un tercio del capital es un corte punible);
• Nodo completo + espera un bloque: la mayoría de los validadores maliciosos aún no pueden engañarlo para que acepte un bloque no válido, sin embargo, pueden enviarle $ 2.5 millones en ETH en un bloque válido, irse en un yate y luego el bloque se reorganiza de inmediato, lo cual es posible si hay suficiente peso de participación o malas condiciones de red, no se cortan punitivamente;
• Cliente de nodo ligero: los tableros de sincronización maliciosos pueden mentirle sin penalización y los compradores pueden irse en el yate (tenga en cuenta que este comité de sincronización es exclusivo de Ethereum como un subconjunto de consenso, otras cadenas PoS con soporte de cliente de nodo ligero más eficiente pueden verificar todos los votos de consenso con un pequeño número de validadores);
• MetaMask – Solo confías en Infura, la persona que te compró el yate le prometió al empleado de Infura que podría llevarse el yate el fin de semana, así que te mintió, pensaste que tenías 2,5 millones de dólares en ETH y luego entregaste las llaves;

Rollup confirma las reglas

Al igual que con cualquier cadena, los nodos interactúan con Rollup utilizando diferentes reglas de confirmación. Las reglas de confirmación más estrictas de Rollup se finalizarán junto con el consenso de su cadena principal. El secuenciador Rollup puede exponer reglas de confirmación más débiles para una mejor experiencia de usuario (es decir, proporcionar una preconfirmación rápida para los usuarios impacientes), pero los usuarios también pueden esperar la seguridad total de las reglas de confirmación de la cadena principal.

Un flujo de transacción consolidado típico tiene el siguiente aspecto:

• El usuario envía una transacción al secuenciador;
• El secuenciador clasifica las transacciones y da una confirmación previa;
• El STF determinista debe aplicarse a las transacciones ordenadas para calcular el nuevo estado Rollup;
• El compromiso de estado de rollup actualizado y los datos de transacción relacionados se liberan finalmente a la cadena principal;

Una vez publicados los datos de la transacción en la cadena principal:

• Rollup Full Node: verifica directamente que el estado de la cadena propuesto es correcto;
• Nodos ligeros acumulativos (incluidos los puentes de verificación): no se pueden verificar directamente;
• Diferentes observadores del mismo Rollup utilizan diferentes reglas de confirmación, por lo que finalizan su punto de vista en diferentes momentos:
• Asumir la publicación de los datos completos de las transacciones (no solo las diferencias de estado);
• Como se mencionó anteriormente, los nodos Rollup también deben ejecutar nodos completos de la cadena principal o nodos ligeros de validador completos (o usar nodos ligeros de validador de consenso para hacer suposiciones mayoritarias honestas). Los nodos ligeros de rollup pueden ejecutarse como software adicional o implícitamente dentro del nodo de la cadena principal (es decir, rollup de verificación de contratos de puente entre cadenas en la cadena principal);

Los usuarios también pueden confirmar las transacciones más rápido confiando en que el secuenciador confirme por adelantado, incluso antes de que el enlace principal reciba los datos. Si el secuenciador se comporta incorrectamente, la seguridad puede fallar. Luego, una vez que los datos estén en la cadena principal (y haya verificado la validez de DA+), solo una falla de la cadena principal (como una reorganización de Ethereum) afectará su seguridad.

Por lo tanto, incluso los pedidos centralizados no reducen realmente la seguridad de "Rollup". Siempre obtendrá una seguridad que cumpla con las reglas de confirmación que necesita. Ya sea que el Rollup tenga un diseño basado en secuenciador o de otro tipo, puede usar las mismas reglas de confirmación (por ejemplo, esperar a que se finalice la cadena principal y verificar la validez del Rollup). Suponiendo una implementación adecuada (por ejemplo, hacer cumplir la inclusión de transacciones a través de la cadena principal), puede obtener los mismos atributos de seguridad dentro del mismo período de tiempo mientras mantiene las mismas condiciones.

Del mismo modo, puede imaginar que los productores de bloques L1 de Ethereum proporcionan una confirmación previa debido a la lentitud de los tiempos de los bloques, lo que no hace que "Ethereum" sea menos seguro. Sólo tienes que decidir si quieres utilizar otra regla de confirmación (menos segura) hasta que el validador de Ethereum finalice la mayor seguridad.

La idea de la preconfirmación encaja bien con la lógica de Gasper descrita por Vitalik:

El principio general es que se quiere proporcionar "el mayor consenso posible" al usuario: si hay > 2/3, entonces llegamos a un consenso de forma regular, pero si hay < 2/3, entonces no hay razón para retrasarse sin aportar nada, porque obviamente la cadena seguirá creciendo a pesar del nivel de seguridad temporalmente más bajo del nuevo bloque. Si una sola aplicación no está satisfecha con un nivel de seguridad más bajo, no dude en ignorar estos fragmentos hasta que estén finalizados.

Juntando todo esto, cuando todas las reglas de confirmación coinciden en el mismo estado del libro mayor al mismo tiempo, tenemos un "área de consistencia":

Confirme la regla: seguridad y accesibilidad

Si su regla de confirmación es confiar en un solo secuenciador ejecutado por un SBF, en lugar de un secuenciador descentralizado formado por los validadores más reputados del mundo, entonces su seguridad puede ser peor, y la falla activa y la reorganización son fallas de seguridad.

Alternativamente, puede esperar a que las reglas de confirmación más fuertes (cadena principal) estén disponibles. Entonces, en igualdad de condiciones, un secuenciador que no sea de confianza no afectará a su seguridad. Si está vendiendo café, probablemente vaya de inmediato, pero si está vendiendo un yate, deberá verificar la confirmación de la cadena principal.

Sin embargo, si todo el mundo utiliza esa regla de confirmación para vender su yate, no podemos ignorar por completo la seguridad potencialmente baja de la regla de confirmación de "confiar en una persona aleatoria que ejecuta un secuenciador separado". El diseño preciso se basa en un equilibrio entre el nivel de compromiso progresivo requerido y el tiempo necesario para un caso de uso determinado.

Una vez más, esto toca una crítica real a las cadenas de bloques de alto rendimiento como Solana. ¿Qué reglas de confirmación pueden usar las personas? Es posible que tenga buenas condiciones de seguridad para ejecutar nodos completos de Solana, pero es posible que la mayoría de las personas no tengan acceso a esa regla de confirmación (es decir, dependiendo de los requisitos de recursos y/o el costo).

La verificación directa (es decir, no solo confiar en la mayoría honesta) es un atributo central de estos sistemas. Por lo tanto, para una regla de confirmación dada, realmente nos preocupamos por dos aspectos: la seguridad y la accesibilidad:

En una palabra:

• Los usuarios interactúan con cualquier cadena a través de reglas de confirmación;
• Una cadena puede tener cualquier número de reglas de confirmación;
• La seguridad es un atributo de la regla de confirmación, no de la cadena en sí;
• Nos preocupamos por la seguridad y accesibilidad de las reglas de confirmación para una cadena determinada;

De hecho, cuando decimos que una cadena dada es segura, estamos tratando de expresar la noción de que sus reglas de confirmación asociadas son seguras y accesibles.

Rollups con seguridad de cadena de integración

1 , cadena de integración con prueba de validez de DAS+

Ahora estamos viendo que la seguridad con respecto a DA y validez de estado se puede verificar directamente mediante criptografía (DAS + validez / prueba de fallo) sin hacer suposiciones fuertes sobre los operadores de la cadena. Cualquier protocolo puede implementarlos técnicamente. Los nodos completos también pueden comprobar la validez de DA y estado sin suposiciones externas.

Ahora centrémonos en otras propiedades: actividad y resistencia a la recombinación. Como hemos visto anteriormente, estos pueden fallar sin importar qué tipo de regla de confirmación ejecute. Echemos un vistazo a otra cadena de integración que demuestra la finalidad de la eficacia DAS+ del zócalo único +PoS:

La elección de reglas de reconocimiento sólidas es particularmente eficaz para un subconjunto de fallas de seguridad, donde incluso la mayoría de los validadores malintencionados no pueden engañar a los nodos completos o a los nodos ligeros de validador completos para que crean que:

• Los datos no disponibles están realmente disponibles;
• o las transiciones de estado no válidas son válidas;

Ya sea que Ethereum tenga 1 validador o innumerables validadores, todos los nodos creen más o menos en el DA o validez del bloque, que están garantizados mediante la verificación. Los nodos ligeros validadores completos se pueden comprobar de una manera más sencilla (pero tenga en cuenta que DAS hace algunas otras suposiciones, que discutiremos más adelante).

Sin embargo, una mayoría maliciosa de validadores puede impedir que el libro mayor crezca, lo censure o reorganice la cadena (los errores que ocurran dependen de las reglas de confirmación). DAS + ZK no te salvará. La resistencia a la reorganización y a la actividad depende siempre en cierta medida de los diversos atributos subyacentes de una cadena determinada (por ejemplo, operadores fiables, incentivos económicos, consenso social, etc.).

De manera menos obvia, la actividad y la resistencia a la reorganización siguen siendo atributos de una regla de reconocimiento dada, ya que cada nodo está sujeto al mismo ataque que en la tabla anterior. Independientemente de las reglas de confirmación aquí, tienen la misma garantía.

Sin embargo, esto vuelve a ser evidente cuando se elimina la suposición de finalidad de una sola ranura. En el Gasper de Ethereum, dependiendo del libro mayor que sigas (es decir, el libro mayor de la cadena más larga o el punto de control disponible), volverás a tener diferentes propiedades resistentes a la actividad y a la reorganización. La mayoría de los validadores malintencionados provocan diferentes fallos de seguridad en función de las reglas de confirmación que se ejecuten.

En cualquier caso, el punto es que la construcción subyacente de la cadena es muy importante aquí. Se necesitan operadores fuertes, incentivos económicos y consenso social para mantener la cadena activa y resistente a la reestructuración. Además, los protocolos de consenso de doble contabilidad, como Ethereum, proporcionan a los usuarios una valiosa flexibilidad para calcular la disponibilidad y la finalidad según sus necesidades.

2, Prueba de acumulación usando DAS + validez

Ahora modifiquemos un poco este ejemplo:

• Ejemplo anterior: una cadena de integración con prueba de validez de DAS +, imagine tomar la Solana de hoy, pero agregando prueba de DAS +;
• Nuevo ejemplo: Rollup se implementa en una cadena principal externa (por ejemplo, Ethereum) con prueba de validez + DAS (tenga en cuenta que Ethereum DAS aún no está activo), Rollup tiene un conjunto de secuenciador descentralizado que puede llegar a un consenso con una rápida confirmación previa;

Notarás que Rollup tiene dos tipos completamente separados de reglas de confirmación para diferentes períodos de tiempo (es decir, si estás operando en función del consenso previo del secuenciador o esperando el consenso final de la cadena principal), veamos ahora cada ruta.

Ruta rápida: antes del consenso de la cadena principal

Los nodos consolidados pueden basarse en la confirmación del secuenciador (antes de publicar en la cadena principal) y suponemos que pueden ejecutar los siguientes nodos consolidados:

• Nodo ligero del validador de consenso de Rollup: confíe en la mayoría honesta en el consenso del secuenciador de rollup;
• Rollup Full Validator Light Node: ejecuta DAS + en el feed del secuenciador para verificar la prueba de validez antes de publicar algo en Ethereum;
• Rollup Full Node: descargue todos los datos de la fuente del secuenciador y ejecute todas las transacciones para verificar directamente DA y validez;

Técnicamente, el secuenciador Rollup puede facilitar el DAS y proporcionar una prueba de validez antes de publicar en la cadena principal, pero esto no sucede realmente. Los nodos ligeros de validador completo suelen estar diseñados para comprobarlos a través de la cadena principal, pero supongo que las pruebas DAS+ "vivas" pueden compararse más claramente con las mismas que las de la cadena integrada.

En la siguiente tabla se muestran los cambios en comparación con el ejemplo de la cadena de integración:

• Confíe en el secuenciador Rollup para la actividad y la anti-recombinación, en lugar del conjunto de validadores de la cadena integrada;
• Solo se eliminó el atributo de actividad final, porque aquí solo se ve el rango de tiempo antes del consenso de la cadena principal (estos atributos de actividad "finales" serán de propiedad propia más adelante en el futuro);

Las eliminaciones se muestran tachadas en rojo y las adiciones se muestran en azul:

Ruta lenta: espere el consenso de la cadena principal

Para mayor seguridad, los nodos pueden esperar el consenso de la cadena principal (por ejemplo, Ethereum), que es donde entra en juego más claramente, es decir, los nodos Rollup también deben ejecutar el nodo principal de la cadena:

• Nodo ligero del validador de consenso de la cadena principal: confíe en el consenso mayoritario honesto de la cadena principal;
• Nodo ligero de validador completo de la cadena principal: verifique la prueba de validez de la cadena principal + ejecute DAS en la cadena principal (incluidos los datos Rollup + datos de la cadena principal);
• Nodo completo de la cadena principal: descargue todos los datos de la cadena principal (incluida la verificación de los datos acumulativos) + ejecute todas las transacciones de la cadena principal para verificar directamente la validez;
• Tenga en cuenta que la validez del estado de Rollup se puede verificar a través de dos rutas diferentes:
• Fuera de la cadena principal (ejecutando software de nodo Rollup adicional): Rollup no requiere que su cadena principal verifique su estado o STF, no necesita implementar un puente de verificación, en su lugar puede verificar la prueba de Rollup mediante otro método (por ejemplo, recibiendo la prueba de Rollup a través de p2p), lo que requiere ejecutar software de nodo Rollup adicional para verificar la prueba (es decir, nodos ligeros Rollup);
• Dentro de la cadena principal (implementar el nodo Rollup dentro de la cadena principal): esta es la norma hoy en día, la lógica del validador de nodo ligero Rollup se implementa en la propia cadena principal (es decir, el contrato de puente integrado de Rollup), dado que este nodo validador Rollup se ejecuta dentro del STF de la cadena principal, validar el STF de la cadena principal también significa verificar el STF del rollup;

Si obtenemos una cadena principal a prueba de conocimiento cero (por ejemplo, Ethereum L1 zkEVM) + todos los rollups prueban su estado dentro de la cadena principal→ obtenemos la visión de Vitalik de la prueba de singularidad. Una prueba de conocimiento cero de la validación de Ethereum significa validar todas las demás cadenas y validar los nodos de sus implementaciones internas:

Para simplificar, asumimos aquí que la validez de estado del rollup se verifica dentro de la propia cadena principal (por ejemplo, el rollup tiene un puente integrado con la cadena principal), por lo que podemos ignorar explícitamente la ejecución explícita de software de nodo de rollup adicional fuera del protocolo.

Los cambios con respecto a la tabla acumulativa de rutas rápidas anterior son los siguientes:

Esto se logra forzando la cadena principal a las transacciones a incluir o imponiendo la sustitución de secuenciador/demostrador, lo que aquí llamamos actividad "final", porque desde el punto de vista de Rollup, es un camino lento, pero desde la perspectiva de la cadena principal, esto puede considerarse actividad "en tiempo real".

Rollup con blockchain integrado

Ahora podemos ver los cambios en los atributos de seguridad relacionados con la cadena de bloques integrada y el Rollup:

• DA y validez de estado: si se implementa, la prueba de validez DAS+ puede proporcionar garantías de seguridad aplicables, independientemente de si la cadena es integrada o Rollup tradicional. De hecho, estas tecnologías hoy en día están dominadas por Rollup; Resistencia a la vida y a la reorganización: las cadenas de bloques integradas son responsables de esto de forma independiente en todos los escenarios. En su lugar, Rollup ofrece una selección de reglas de confirmación dentro de diferentes períodos de tiempo. Puede usar reglas de confirmación menos seguras (consenso del secuenciador de confianza) para obtener garantías rápidas, o esperar reglas de confirmación más seguras (esperar el consenso de la cadena principal);

Actividad y resistencia a la recombinación

Estos atributos no se pueden garantizar con una contraseña e incluso a través de reglas de reconocimiento (por ejemplo, si se ejecuta un nodo completo o ligero), puede ser vulnerable a errores de seguridad.

Si el operador está completamente fuera de control, ningún nodo completo o prueba de ZK puede protegerlo de fallas de actividad o reorganización.

Estos atributos se logran a través de operadores fuertes y descentralizados, mecanismos resistentes a la censura, consensos propicios para la actividad, alto "costo" de reestructuración, fuertes consensos sociales, etc. Compararlos objetivamente suele ser un reto.

¿Cómo se mide la descentralización de los operadores y el consenso social? No hay una respuesta correcta. Podría decirse que estos son los aspectos más difíciles de diseñar y, de hecho, son muy exclusivos de una cadena determinada.

Es importante destacar que Rollup puede delegar la actividad y la anti-reorganización a la cadena principal, y que las reglas de confirmación utilizadas en Rollup pueden tener los mismos atributos de seguridad que si se ejecutaran en la cadena principal dentro del mismo período de tiempo.

Las cadenas pueden incluso elegir qué atributos delegar a qué cadena, y los diferentes tipos de arquitecturas "L2" (como validiums, optimism y sidechains) pueden absorber diferentes subconjuntos de atributos de seguridad. Por ejemplo:

• Anti-reestructuración - Rollup puede delegar la anti-reestructuración a Ethereum, y sus reglas de selección de bifurcación se basan en lo que el consenso de Ethereum confirma para seleccionar la "cadena canónica". Si Ethereum se reorganiza, Rollup también se reorganizará.
• Liveness - Sin embargo, si Rollup carece de un mecanismo de inclusión forzada y reemplazo forzado de operadores, los usuarios de Rollup aún no reciben el atributo de vivacidad de Ethereum;

Rollup también puede proporcionar a los usuarios una ruta de escape para salir de Rollup, pero conserva la capacidad de examinar a los usuarios y evitar que los depósitos entren en Rollup (así es como funciona Loopring, por ejemplo). Si el depósito permanece sin procesar después de un cierto período de tiempo, el usuario puede retirar los fondos bloqueados del contrato L1.

Esto pone de relieve la importancia de estos mecanismos.

Disponibilidad de datos y validez de estado

A diferencia de la actividad y la anti-recombinación, los nodos pueden garantizar la validez de DA y el estado sin hacer grandes suposiciones de umbral (o compensaciones de seguridad entre los dos). Los productores de bloques mayoritarios malintencionados pueden causar errores de actividad y reorganización, pero no causarán errores de DA o validez para nodos completos o nodos ligeros de validador completos.

Sin embargo, los nodos ligeros validadores de consenso se ven afectados, por supuesto, por la validez de estado de las mayorías honestas y los fallos de DA. Simplemente creen todo lo que dice el consenso. Es por eso que la validez de DA y de estado es lo que hace que las reglas de confirmación de seguridad sean accesibles y realmente funcionen. Esta es a menudo la gran diferencia ideológica entre los Rollups tradicionales y las grandes cadenas de bloques que no ponen mucho énfasis en la verificación del usuario.

En orden, estas suelen ser las formas preferidas de equilibrar la seguridad y la accesibilidad:

• Hacer que el DAS y la prueba de eficacia estén ampliamente disponibles;
• Si no tiene DAS y/o prueba de validez, haga que los nodos completos sean ampliamente accesibles (es decir, con bajos requisitos de recursos, fáciles de ejecutar, etc.);
• Si no tiene DAS y/o prueba de validez, y el nodo completo es en gran medida inaccesible, haga que el nodo ligero del validador de consenso sea ampliamente accesible y tenga un consenso mayoritario honesto y confiable;
• Visita a Infura;

Tenga en cuenta que 2 (nodo completo) es en realidad el más seguro. La verificación de ZK es sencilla, pero los nodos DAS hacen algunas suposiciones adicionales que los nodos completos no hacen. Sin embargo, proporcionan casi la misma seguridad que los nodos completos, y con requisitos de recursos a una fracción de eso, son escalables.

Los nodos completos solo necesitan descargar todos los datos, por lo que están 100% seguros. Firman el bloque solo cuando todo está allí. No se han hecho suposiciones sobre las partes externas.

El objetivo de DAS es lograr una seguridad casi tan buena como la de los nodos completos, al tiempo que con requisitos de recursos significativamente más bajos (es decir, una escala más alta). Este artículo sobre los niveles de seguridad de disponibilidad de datos de nodos ligeros cubre bien esto.

En resumen, normalmente se hacen algunas suposiciones en torno a la sincronización de la red y si hay suficientes nodos para reconstruir los datos. Si los productores de bloques hostiles ocultan algún dato, incluso un pequeño grupo de nodos ligeros honestos debería poder reconstruir colectivamente los bloques. También hay supuestos sobre la divulgación selectiva de acciones, en los que los productores de bloques hostiles pueden engañar a un pequeño número de nodos de luz individualmente, pero no colectivamente.

Estos supuestos "N-en-2" (por ejemplo, una minoría honesta de nodos puede asegurar DAS) son muy ventajosos en relación con el supuesto típico aproximado de "N/2" (por ejemplo, el 51% de los productores de bloques pueden conducir a la reorganización). Vitalik tiene una buena introducción a esto en su publicación sobre el modelo de confianza.

En general, la DA y la efectividad del estado no son "comisionadas" por Rollup como actividad y resistencia recombinante. La validez de DA y estado puede ser verificada directamente por el usuario, mientras que otros atributos dependen en mayor medida de los participantes de consenso de la cadena y sus incentivos.

Revise un ejemplo de una validación anterior de la prueba acumulativa:

• Publique la prueba de ZK de Rollup en un contrato inteligente de Ethereum, donde ejecute un nodo completo de Ethereum y verifique implícitamente la prueba;
• Enviar la prueba ZK de Rollup a mi nodo de luz de Rollup para verificar la prueba directamente;

En cualquier caso, puede garantizar la efectividad. No importa dónde lo revises, no puedes determinar su efectividad. Ethereum no tiene la misma efectividad verdaderamente "forzada" que los nodos de Ethereum "fuerzan" las propiedades anti-reestructuración o activas. La antirreestructuración y la vitalidad dependen en gran medida de quién las obtengas.

Considere un rollup basado en cadena de estafas:

• Las reglas de selección de bifurcaciones de Rollup siguen la punta de la cadena→ Si se reorganiza la cadena, Rollup también se reorganizará;
• El mecanismo de inclusión obligatorio de Rollup y la eliminación del secuenciador se aplican a través de contratos puente entre cadenas en la cadena de estafas→ Si el libro mayor de la cadena de estafas se detiene, también lo hace el libro mayor del acumulativo. Si la cadena de estafas quiere censurar su Rollup, entonces usted será censurado;

Rollup puede exponer reglas de confirmación con los mismos atributos de seguridad que su cadena principal, que pueden recibir como máximo a la velocidad del consenso de su cadena de host (de hecho, normalmente será más lento, dependiendo de la frecuencia con la que se publique Rollup en la cadena principal).

Los resúmenes también pueden proporcionar una "ruta feliz" con reglas de confirmación más relajadas (es decir, secuenciadores) para una mejor experiencia del usuario, pero conservan las reversiones de transacciones en caso de error. Si el secuenciador se detiene, puede seguir moviéndose. Sin embargo, este no es el caso si su cadena depende completamente de su propio conjunto de validadores (es decir, como una cadena de integración).

Elegir sabiamente la cadena principal de Rollup puede tener un impacto concreto en los atributos de seguridad. Es especialmente valioso aprovechar una cadena de transferencia con una fuerte actividad (crecimiento del libro mayor + CR) y resistencia a la reorganización.

Diferentes supuestos de seguridad para diferentes períodos de tiempo

Veamos un ejemplo sencillo. Chain X está decidiendo si se implementa como un Rollup en una cadena principal existente o como su propia cadena de bloques integrada.

Rollup tiene las siguientes características:

• 10 segundos de tiempo de bloqueo;
• Los nodos de luz DAS son compatibles
• Se pueden proporcionar reglas de confirmación de "alta seguridad" para la actividad y la anti-reorganización (por ejemplo, validadores de confianza descentralizados, etc.);

La cadena de bloques integrada tiene las siguientes características:

• El tiempo de salida del bloque es de 1 segundo;
• El nodo ligero DAS y la prueba de validez se pueden implementar, ya sea que se lance como una cadena de bloques integrada o como un rollup;
• Si se implementa un secuenciador centralizado, proporcionará reglas de confirmación de "baja seguridad" sobre la actividad y la resistencia a la recombinación;
• Si implementa su propio consenso descentralizado (ya sea como un conjunto de secuenciadores Rollup preconfirmados o como un conjunto de validadores de cadena integrados), proporcionará reglas de confirmación de "seguridad media" para la actividad y la anti-reorganización;

En la tabla siguiente se ofrece una representación visual simplificada de las mejores garantías de seguridad que los usuarios pueden tener en varias implementaciones (es decir, usan las reglas de confirmación más estrictas disponibles). En particular, nos centramos aquí en la actividad y la resistencia a la recombinación (porque asumimos que la cadena solo logrará la prueba de eficacia DAS+ en estos dos casos):

La "seguridad máxima" de Rollup es mayor que su "seguridad en tiempo real" porque la cadena principal no puede garantizarnos más rápido que su propio tiempo de bloque. Aunque puede comprobar que las reconfirmaciones previas del secuenciador son transiciones de estado válidas, no puede garantizar completamente su finalidad hasta que finalmente lleguen a la capa DA.

Pero, como hemos visto, la implementación en una cadena principal sólida de forma acumulativa mejora la seguridad. Pueden alquilar seguridad a la velocidad de su cadena principal. Fundamentalmente, no hay forma de obtener todos los atributos de seguridad de la cadena principal más rápido que el consenso de la propia cadena principal.

Sin embargo, los usuarios tienden a ser impacientes. Como resultado, Rollup normalmente proporcionará una confirmación previa más rápida, pero la garantía será menor durante este período. Rollup puede elegir un diseño de secuenciador balanceado:

• Funcionalidad práctica y eficiencia. Por ejemplo, los secuenciadores centralizados pueden proporcionar una validación previa rápida y reducir la sobrecarga operativa;
• Fuerte garantía. Por ejemplo, un conjunto increíble de secuenciadores descentralizados puede proporcionar una mejor actividad en tiempo real, pero a costa de mayores costos operativos y latencia (en el caso más extremo, simplemente deja que la capa DA se encargue del orden del rollup, eligiendo no exponer la ruta más rápida);

Curiosamente, se puede argumentar que los resúmenes de pedidos L1 son menos activos que los secuenciadores centralizados, dependiendo de su escala de tiempo. Hasta ahora, hemos hablado de la actividad, incluyéndola en algún tipo de concepto de "tiempo finito". Sin embargo, esto es totalmente relativo y subjetivo. ¿En relación con qué? ¿Cuánto tiempo se tarda?

Un rollup secuencial L1 puro solo se incluirá a la velocidad de los bloques L1 (por ejemplo, 10 segundos), y no tiene ninguna garantía de actividad entre estos bloques cuando cambie el mundo que lo rodea. Por lo tanto, depende de su punto de referencia:

• Si baseline = operación dentro de Rollup, L1 Rollup secuencial puede proporcionar una mejor actividad. No se debe prometer a nadie más en la cadena hasta que se confirme la cadena principal, por lo que todos están en igualdad de condiciones;
• Si la línea de base = operación fuera del Rollup: el Rollup con precalificación suave puede proporcionar una mejor actividad. La preconfirmación es solo una opción gratuita, y aún así recurre a la garantía de la cadena principal a la velocidad de la cadena principal, pero puede obtener una garantía más débil mientras tanto. Si no confía en ellos, espere la confirmación de la cadena principal. El mundo no se congela entre los bloques de Ethereum, y para muchas aplicaciones, los precios obsoletos entre largos tiempos de bloque pueden ser inaceptables;

Si intenta implementar un rollup basado en "real" sin confirmación previa, incluso es posible que la confirmación previa se produzca de todos modos. Para los participantes, como los constructores y validadores de Ethereum, existe un incentivo financiero para que asuman este compromiso ellos mismos. Esta es exactamente la razón por la que existe una discusión sobre cómo los constructores de Ethereum y las partes interesadas están tratando de proporcionar una preconfirmación rápida en la capa base.

Aquí hay una última nota importante. Suponiendo que los usuarios de Rollup pueden volver al mismo nivel de actividad que la cadena principal, suponiendo que se puede forzar la inclusión completamente a la velocidad del bloque de la cadena principal (por ejemplo, si el ordenante de Rollup te está revisando, puedes forzar que las transacciones se incluyan en el siguiente bloque de Ethereum de la cadena principal).

En la práctica, suele haber un breve retraso. Si se permite la inclusión obligatoria inmediata, se corre el riesgo de exponer los rentables MEV de censura junto con otras complejidades. Sin embargo, algunos diseños pueden proporcionar garantías de actividad casi en tiempo real desde la cadena principal (por ejemplo, tal vez a la velocidad de varios bloques de la cadena principal en lugar de un bloque).

Independientemente de la escala de tiempo exacta, la actividad final de la absorción de la cadena principal es muy fuerte, y el uso de una cadena principal fuerte como mecanismo de coordinación proporciona amenazas creíbles y derechos de salida. La mera exposición de esta amenaza creíble por sí sola hace que sea muy poco probable que sea necesaria para prevenir el comportamiento malicioso en primer lugar.

Por ejemplo, si el usuario tiene un mecanismo confiable para salir por la fuerza o incluso eliminar por la fuerza al operador, entonces el secuenciador Rollup centralizado no puede extraer arbitrariamente el alquiler del usuario y bloquearlo. Esta es un área general discutida en Chris Goes en su charla sobre MEV, Conversion Cost, Edge y Slow Gaming.

Por supuesto, también puede ocurrir una actividad inesperada, en cuyo caso esta ruta de copia de seguridad puede volver a ser muy valiosa.

La prueba no protege la cadena, pero protege al usuario

Siguiendo todo esto, podemos ver que para una regla de confirmación dada, resulta que es más preciso proteger a los diferentes "observadores" (usuarios) de Rollup que proteger el "Rollup" en sí. La seguridad de "Rollup" no existe como una única medida específica.

Garantizar la seguridad del observador es, por supuesto, lo más importante, ¡porque todos somos observadores de la cadena! Esta cadena es lo que digan sus observadores. Si no puedes observarlo de forma segura, tienes que confiar en que otra persona (como un verificador) te diga la "verdad" al respecto. Pero no queremos confiar, queremos verificación→ queremos pruebas.

Para entender por qué es importante distinguir entre "prueba de cadena" y "observador de cadena de prueba", considere lo siguiente:

• Nodos ligeros: los nodos ligeros enrollables son más seguros si hay pruebas, no tienen que confiar en la validez de las palabras de nadie;
• Nodo completo: si hay una prueba, la seguridad del nodo completo de Rollup no aumentará ni disminuirá, puede iniciar Rollup ("rollup pesimista") sin un puente incorporado o incluso sin ninguna prueba, si comienza a enviar una prueba de validez, la seguridad del nodo completo no aumentará ni disminuirá;

Probado agrega seguridad a los observadores de la cadena (es decir, nodos de luz) cuya validez no se puede verificar directamente. No queremos que los usuarios tengan que ejecutar nodos completos potentes, por lo que estas pruebas son importantes.

La atestación protege el puente Rollup

¡El puente de verificación de Rollup es un observador extremadamente importante! ¡La evidencia garantiza la seguridad del puente!

Al igual que con cualquier nodo ligero típico, el puente no puede comprobar directamente la validez de Rollup. No creemos en las mayorías honestas, sino que protegemos los puentes con pruebas. El protocolo de consenso para la base de datos A (la capa DA) ordena los blobs de datos y, a continuación, comprueba que el puente comprueba de forma independiente la validez de la actualización correspondiente a la base de datos B (acumulativo):

El puente es un observador de otra cadena, y cada activo que acuña siempre lleva la asunción de seguridad de las reglas de confirmación del puente correspondiente. La seguridad de sus reglas de confirmación puede tener implicaciones de gran alcance. Es por eso que es tan importante construir puentes seguros (o idealmente, reducir la necesidad de tantos puentes escalando aún más la ejecución de una sola cadena en primer lugar).

Si ejecuta nodos completos para la cadena, las partes malintencionadas no pueden engañarle para que acepte transiciones de estado no válidas. Sin embargo, si la parte malintencionada tiene reglas de confirmación diferentes, aún puede suplantar el puente. Si tiene activos respaldados por garantías en el puente, es posible que sus fondos dejen de estar respaldados. En este sentido, el fallo de seguridad del puente de suplantación de identidad es "contagioso".

Consideremos un viejo escenario hipotético sobre Terra:

• Terra tiene su propio conjunto de validadores, su token nativo es LUNA y se puede emitir UST nativo;
• Osmosis tiene su propio conjunto de validadores, y su token nativo es OSMO.
• Tenemos un puente IBC estándar de Terra ←→ Osmosis donde cada lado ejecuta el nodo ligero validador de consenso de la otra cadena (es decir, cada lado del puente depende de una mayoría honesta del conjunto de validadores de la otra cadena);
• Ejecuta su propio nodo completo para cada cadena como usuario;
• Nos referimos a UST en Osmosis puenteada sobre IBC como osmoUST;
• Nos referimos a OSMO en Terra puenteado a través de IBC como terraOSMO;
• Eres dueño de terraOSMO en Terra;
• Estás haciendo LPs en un pool de osmoUST/OSMO en Osmosis;

Con el colapso de Terra, el precio de LUNA se desploma y, eventualmente, la ganancia del conjunto de validadores que teóricamente se vuelve malicioso excederá el valor de LUNA apostada, y el validador de Terra puede firmar bloques no válidos y hacer lo siguiente:

• Acuñar UST falso → cadena cruzada a Osmosis para acuñar osmoUST, usarlo para agotar todos los pares comerciales de osmoUST (por ejemplo, sacar todo OSMO del grupo osmoUST/OSMO;
• Acuñar terraOSMO falso → cadena cruzada a ósmosis para retirar todas las garantías nativas de OSMO bloqueadas en Osmosis que admite terraOSMO, todo terraOSMO restante en Terra ahora ya no será compatible;
• Bueno, la seguridad falla aquí:
• Nodo completo (yo) - mi nodo completo reconoce los bloques de Terra como no válidos y los rechaza, los validadores de Terra no pueden robar mis posiciones de terraOSMO u osmoUST/OSMO LP;
• Nodo ligero (puente): el puente solo verifica que el consenso de Terra esté firmado en el bloque (no verifica las transiciones de estado válidas) para que no las rechace, los validadores de Terra pueden robar la garantía de OSMO que soporta mi terraOSMO y drenar todo OSMO del grupo osmoUST/OSMO (dejando un montón de osmoUST sin valor);

El puente utiliza reglas de reconocimiento con supuestos de confianza más sólidos.

Los validadores de Terra no pueden robar grandes cantidades de activos propios de Terra de nodos completos (no serán engañados), rechazarán estos bloques. Sin embargo, los validadores pueden engañar a los validadores de consenso para que hagan clientes ligeros (incluidos los puentes), por lo que los errores de consenso afectan a los activos entre cadenas.

Tenga en cuenta que es importante que estas fallas no "infecten" al resto de la cadena, es decir, la falla "infecta" los activos de Osmosis expuestos a la ruta del puente Terra, pero no hay falla de seguridad en la cadena de Osmosis en sí.

Sin embargo, obviamente queremos tender un puente entre las cosas (en general, la comunicación entre cadenas), sería malo limitarnos a usar activos nativos en su cadena principal, necesitamos cadenas para comunicarse de forma segura y tender puentes entre cadenas.

Como experimento mental, la solución más simple es hacer que cada usuario ejecute nodos completos de cada cadena, lo que incluye el puente entre cadenas. Tenga en cuenta que hemos visto algunos puentes de nodo completo integrados unidireccionales:

• Los rollups de Ethereum actualmente requieren que sus nodos ejecuten nodos completos de Ethereum, y estos rollups comparten el consenso de Ethereum; Namada (una cadena separada de Tendermint, no una cadena Rollup) requerirá que sus nodos ejecuten nodos completos de Ethereum, sin embargo, Namada no está de acuerdo con el consenso de Ethereum (es decir, no publica datos en Ethereum ni deriva su estado en función de eso);

Esto funciona para los nodos completos de Ethereum, pero obviamente esto no escala. No se puede empezar a tener cada cadena de Cosmos, solo es necesario ejecutar nodos completos para todas las demás cadenas de Cosmos. Estos puentes bidireccionales de nodo completo no se escalan, solo aumentan los requisitos de hardware.

Afortunadamente, existe una opción más escalable. Podemos implementar puentes para verificar completamente la validez del estado y el DA de otra cadena (además de seguir comprobando el consenso).

Validez del estado: si bien IBC se usa actualmente con la prueba de consenso tradicional, se puede modificar para agregar una prueba de validez para conectar cadenas, y ahora los puentes no son falsificados por transiciones de estado no válidas. Esto habría evitado exactamente lo que el ataque describió anteriormente, y si el puente hubiera podido verificar la validez de la transición de estado, habría rechazado el bloque del validador de Terra como inválido.

Esto se parece mucho a la forma en que el puente Rollup en Ethereum comprueba las pruebas de Rollup, excepto que también puede ser bidireccional.

DA - Además, una cadena puede requerir que sus nodos ejecuten nodos ligeros DAS que conectan la cadena. Por ejemplo, puede tener dos cadenas de Cosmos que requieran sus propios validadores para ejecutar los nodos ligeros DAS de la otra cadena (si cada cadena implementa clientes ligeros DAS, que actualmente no son compatibles). Una vez hecho esto, cada cadena puede conocer la validez y el DA de la otra sin tener que ejecutar nodos completos.

En el caso de Rollup, por definición, usted es el propietario de todos los datos de la cadena principal, por lo que el puente puede acceder a ellos. Los nodos acumulativos, por otro lado, ejecutan nodos de la cadena principal.

Cadenas dependientes e independientes

Echemos un vistazo a nuestros cinco atributos de seguridad de nuevo, ahora en el contexto de la observación del puente de verificación de Rollup en Ethereum:

• Crecimiento del libro mayor: los validadores de Ethereum pueden obligar al libro mayor de Rollup a seguir creciendo (por ejemplo, forzar transacciones de inclusión);
• Resistente a la censura: los validadores de Ethereum pueden obligar a los operadores de Rollup a no censurar indefinidamente (por ejemplo, forzar la inclusión de transacciones o la sustitución del secuenciador);
• Anti-reestructuración - La anti-reestructuración de Rollup está relacionada con Ethereum. Si Ethereum se reorganiza, entonces todos los rollups en Ethereum se reagruparán;
• Disponibilidad de datos: el DA de Rollup está garantizado porque Rollup se deriva por definición de los datos confirmados por el consenso de la cadena principal (donde se encuentra el contrato de Rollup), Rollup y la cadena principal comparten el consenso de fusión, DA es una condición de validez del propio Ethereum, por lo que si los datos no están disponibles, entonces el bloque de Ethereum en sí no es válido. El puente puede acceder a los datos de la cadena principal sin agregar suposiciones de confianza;
• Validez del estado: el contrato verificará la prueba de validez de la transición de estado del Rollup (o esperará a que pase la ventana de desafío), que demuestra que la actualización del estado declarada es un resultado válido de la aplicación del STF del Rollup en los datos correspondientes confirmados en la cadena principal;

Tenga en cuenta que la seguridad de un puente no solo se maximiza mediante reglas de confirmación súper fuertes para cadenas adicionales (por ejemplo, un puente de validador completo a una cadena con un conjunto de validadores súper confiable). Si el puente tiene los mismos supuestos de seguridad que la cadena principal, puede obtener la mayor seguridad cuando se cruzan los activos nativos.

Vitalik proporciona un ejemplo ilustrativo útil:

"Transfieres 100 ETH a un puente sobre Solana y obtienes 100 Solana-WETH, y Ethereum es atacado en un 51%. El atacante deposita un montón de su ETH en Solana-WETH y luego reanuda la transacción en el lado de Ethereum tan pronto como el lado de Solana lo confirma. El contrato Solana-WETH ya no es totalmente compatible, y tal vez sus 100 Solana-WETH ahora solo valgan 60 ETH. Incluso con un puente perfecto basado en ZK-SNARK que valide plenamente el consenso, sigue siendo vulnerable a un ataque del 51% como este.

Por lo tanto, siempre es más seguro mantener activos nativos de Ethereum en Ethereum o activos nativos de Solana en Solana que mantener activos nativos de Ethereum en Solana o activos nativos de Solana en Ethereum. En este contexto, "Ethereum" se refiere no solo a la cadena subyacente, sino también a cualquier L2 apropiada construida sobre ella.

Si Ethereum es atacado en un 51% y se recupera, Arbitrum y Optimism también se recuperarán, por lo que incluso si Ethereum es atacado por el 51%, se garantiza que las aplicaciones de "cross-rollup" que guardan el estado en Arbitrum y Optimism seguirán siendo consistentes. Si Ethereum no hubiera sido atacado en un 51%, no habría forma de hacer un ataque del 51% en Arbitrum y Optimism, respectivamente. Por lo tanto, sigue siendo completamente seguro mantener activos emitidos por Optimism, con sede en Arbitrum.

Puedes sustituir Solana por cualquier cadena que desees, incluso una cadena hipotética en la que superes a un validador de Ethereum en términos de confianza y, fundamentalmente, cualquier suposición de seguridad es aditiva cuando se habla de activos de cadena cruzada con su libro mayor de registro (por ejemplo, ETH de Ethereum), y siempre existe la posibilidad de que una cadena conectada se reorganice o falle en la actividad.

Sin embargo, las cadenas con consenso fusionado (es decir, los rollups que comparten el consenso de su cadena principal) pueden eludir estos supuestos de seguridad adicionales. Los puentes de cadena cruzada entre estas diferentes regiones pueden tener la misma actividad final y propiedades antirrecombinación que la propia cadena principal. El consenso compartido minimiza las suposiciones de confianza entre cadenas dentro de esa zona de seguridad compartida.

Lo que son las suposiciones de seguridad razonables depende de usted. De hecho, no ha habido un fracaso de consenso similar entre las principales cadenas. Esto sería obvio y costoso, pero podría ser una suposición más fuerte sobre la conexión de cadenas más débiles.

También hay algunos inconvenientes al vincular una cadena Rollup a la cadena principal. Comparemos dos escenarios de cadena cruzada, en ambos casos tenemos dos cadenas que utilizan un puente bidireccional de cadena cruzada entre validadores completos:

• Dependencia: la cadena remota (es decir, Rollup) comparte el consenso de la cadena principal (es decir, la capa DA) y deriva su propio estado de los datos de la cadena principal, la cadena remota debe bifurcarse con la cadena principal y determinar su finalidad en función de la cadena principal;
• Independiente: estas cadenas tienen su propio consenso independiente, no derivan su propio estado en función de los datos de otras cadenas. No comparten una relación de cadena remota (es decir, Rollup) ←→ cadena principal (es decir, capa DA). No se reagrupan y no dependen de la actividad de los demás;
• Curiosamente, estos son tanto buenos como malos:
• Malo - Reorganizar su cadena con otras cadenas o tener fallas de actividad puede sonar como un inconveniente a primera vista, ¿por qué mi cadena tiene problemas porque su cadena está rota?
• Bueno: si esta divergencia causa problemas graves en su cadena, esto es en realidad un beneficio importante (por ejemplo, si tiene una gran cantidad de activos entre cadenas de la cadena de origen, entonces se reorganizará desde la perspectiva de su puente entre cadenas, dejando garantías sin respaldo), la cadena y su puente entre cadenas deben ser consistentes entre sí;

Del mismo modo, los bloqueos y la búsqueda excesiva de rentas tienen posibles efectos positivos y negativos, lo que pone de manifiesto por qué es tan importante una capa base neutra y resistente a la censura:

• Bueno - Una buena cadena principal protege a los usuarios de Rollup de los operadores de Rollup que les exprimen demasiado valor, imponiendo privilegios de salida;
• Malo: las cadenas de transferencia defectuosas pueden inflar arbitrariamente el precio y extraer ese valor de Rollup y sus propios usuarios;
• La prueba de envío + ejecutar DAS en ambas direcciones en lugar de compartir una cadena principal común también tiene algunas ineficiencias:
• No desea requerir que su nodo ejecute un montón de nodos ligeros DAS de otras cadenas, y tenga que agregar manualmente nuevas cadenas, ejecutar DAS en una enorme capa DA compartida es mucho más eficiente;
• Es ineficiente para cada cadena verificar la validez de muchas cadenas diferentes, sin embargo, es teóricamente posible agregar pruebas entre varias cadenas para que todo el grupo de cadenas solo necesite publicar una prueba en la cadena;

Aquí hay compensaciones y beneficios, pero también hay que tener en cuenta que hay una gran dependencia de la ruta de dónde se encuentran los activos interesantes, y si quieres utilizar un montón de activos nativos de Ethereum (incluidos los de su Rollup), tiene sentido rootear tu cadena en Ethereum y sus puentes entre cadenas.

Conclusión

"Seguridad de herencia de Rollups" es una buena abreviatura, pero recuerde que estos son los puntos clave a los que realmente nos referimos:

• Rollup paga un alquiler a su cadena principal, como Ethereum, por los recursos que consume (DA);
• Rollup puede exponer reglas de confirmación con propiedades de seguridad hasta la cadena principal (es decir, los usuarios pueden obtener las mismas garantías de seguridad que cuando operan en la propia cadena principal);
• Los usuarios obtienen estos atributos de seguridad de la cadena principal a la velocidad del consenso de la cadena principal;
• Si los usuarios de Rollup quieren ser más rápidos que la confirmación proporcionada por la cadena principal, pueden usar reglas de confirmación, que hacen suposiciones de seguridad temporales adicionales;
• El observador (es decir, el usuario) interactúa con Rollup a través de reglas de confirmación, y el puente de verificación con la suposición de menor confianza es un observador (opcional pero muy valioso);

Ahora, considere las ventajas de implementar Rollup en la cadena de integración:

Seguridad del usuario: ya sea que desee implementar puentes entre cadenas o no, los Rollups pueden arrendar DA de su cadena principal y reclamar su consenso, lo que permite a Rollup exponer reglas de confirmación que coincidan con la cadena principal a sus usuarios sin tener que llegar a su propio consenso;

Seguridad entre cadenas: Rollup puede crear cadenas cruzadas dentro del dominio de seguridad compartido de la cadena principal (es decir, la propia cadena principal y su Rollup), y sus propiedades de seguridad son comparables a las de operar en la propia cadena principal;

Deberíamos ver que en realidad se trata de dos caras de la misma moneda, y Rollup solo permite que la cadena proporcione reglas de confirmación, y su seguridad puede alcanzar la seguridad de la cadena principal. Tanto los puentes entre cadenas como los usuarios normales son observadores de cadenas con reglas de reconocimiento dadas. Los puentes son quizás los "observadores" más importantes en estas cadenas porque su seguridad tiene implicaciones de amplio alcance.

Cuando intentamos crear un sistema seguro, debemos preocuparnos por la seguridad de las reglas de confirmación dadas, así como por su accesibilidad. Si la mayoría de los observadores (usuarios) que interactúan con estas cadenas están fuera de su alcance, las reglas de confirmación de seguridad no ayudan mucho.

Si bien hoy en día asociamos DAS y pruebas de validez con Rollup, son conceptos lógicamente separados. Cualquier cadena puede integrar estas tecnologías, y la distinción entre lo que es un rollup o no es un rollup comienza a romperse al final del juego (es decir, para un solo rollup integrado, puede tener capas de DA y ejecución lógicamente separadas bajo un protocolo).

Sin embargo, las capas "rollup tradicional" y DA dominan claramente estas tecnologías de verificación y escalado en la actualidad.