Estructura de los componentes de Arbitrum interpretada por el ex embajador técnico de Arbitrum (Parte 1)

Como existe una falta de interpretación profesional de artículos o materiales relacionados con los protocolos Layer2, especialmente para Arbitrum y OP Rollup, en la comunidad china, este artículo tiene como objetivo llenar este vacío explicando el mecanismo operativo de Arbitrum. Debido a la complejidad del propio Arbitrum, el texto completo, incluso después de haberlo simplificado al máximo, todavía supera las 10.000 palabras. Por lo tanto, se divide en dos partes y se recomienda guardarlo y compartirlo como material de referencia”.

Descripción general del secuenciador acumulativo

El principio del escalado Rollup se puede resumir en dos puntos:

Optimización de costos: transfiera la mayoría de las tareas de computación y almacenamiento a la Capa 2, que se opera bajo L1. L2 se ejecuta principalmente en un único servidor, denominado secuenciador/operador, formando una cadena separada.

El secuenciador aparece casi como un servidor centralizado en términos de percepción, abandonando la descentralización en la "trinidad imposible de blockchain" para obtener ventajas en TPS y costo. Los usuarios pueden usar L2 para manejar instrucciones de transacciones en lugar de Ethereum, con costos mucho más bajos en comparación con las transacciones en Ethereum.

(Fuente: Cadena BNB)

Garantía de seguridad: el contenido de la transacción y el estado posterior a la transacción en L2 se sincronizan con Ethereum L1 y su validez se verifica mediante contratos para la transición de estado. Al mismo tiempo, Ethereum conserva el historial de L2, por lo que incluso si el secuenciador falla permanentemente, otros pueden reconstruir el estado completo de L2 a través de los registros de Ethereum.

Fundamentalmente, la seguridad de Rollup depende de Ethereum. Si el secuenciador no conoce la clave privada de una cuenta, no puede iniciar transacciones en nombre de esa cuenta ni manipular el saldo de activos de la cuenta (incluso si lo intentara, se detectaría rápidamente).

Si bien el secuenciador, como eje central, tiene un aspecto centralizado, en las soluciones Rollup maduras, el secuenciador centralizado solo puede participar en actividades maliciosas suaves, como censura de transacciones o fallas maliciosas. En un escenario ideal de Rollup, existen medidas correspondientes para restringir tales acciones, como retiros obligatorios o pruebas secuenciales para mecanismos anticensura.

(El protocolo Loopring establece una función de retiro forzado en el código fuente del contrato en L1 para que los usuarios la llamen)

Los mecanismos de verificación de estado para prevenir acciones maliciosas por parte de los secuenciadores Rollup se dividen en dos categorías: Prueba de fraude y Prueba de validez. Las soluciones acumuladas que utilizan Fraud Proof se denominan OP Rollup (Optimistic Rollup, OPR), mientras que aquellas que utilizan Validity Proof a menudo se denominan ZK Rollup (Zero-knowledge Proof Rollup, ZKR) en lugar de Validity Rollup debido al bagaje histórico.

Arbitrum One es un OPR típico, implementado en L1 con contratos que no validan activamente los datos enviados, asumiendo con optimismo que los datos son correctos. Si hay un error en los datos enviados, los nodos validadores L2 iniciarán activamente un desafío.

Por lo tanto, OPR implica un supuesto de confianza: en un momento dado, hay al menos un nodo validador L2 honesto. Por otro lado, los contratos ZKR validan de forma activa y económica los datos enviados por el secuenciador mediante cálculos criptográficos.

(Método de operación de resumen optimista)

(Método de operación ZK Rollup)

Este artículo proporciona una introducción detallada al proyecto líder en Optimistic Rollup: Arbitrum One, que cubre todos los aspectos de todo el sistema. Después de leerlo detenidamente, tendrá un conocimiento profundo de Arbitrum y Optimistic Rollup/OPR.

Componentes principales y flujo de trabajo de Arbitrum

Contratos principales:

Los contratos más importantes en Arbitrum incluyen SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, etc. Estos se detallarán en las siguientes secciones.

Secuenciador:

El secuenciador recibe las transacciones de los usuarios, las clasifica, calcula los resultados de las transacciones y rápidamente (generalmente <1) devuelve los recibos a los usuarios. Los usuarios suelen ver sus transacciones en L2 en unos pocos segundos, lo que proporciona una experiencia similar a las plataformas Web2.

Simultáneamente, el secuenciador transmite inmediatamente el último bloque L2 generado bajo Ethereum fuera de la cadena. Cualquier nodo Layer2 puede recibir estos bloques L2 de forma asincrónica. Sin embargo, estos bloques L2 no tienen finalidad en este punto y el secuenciador puede revertirlos.

Cada pocos minutos, el secuenciador comprime los datos de transacciones L2 ordenados, los agrega en lotes y los envía al contrato SequencerInbox en Layer1 para garantizar la disponibilidad de los datos y el funcionamiento del protocolo Rollup. Generalmente, los datos L2 enviados a Layer1 no se pueden revertir y pueden tener un determinismo final.

Del proceso anterior podemos resumir: Layer2 tiene su propia red de nodos, pero la cantidad de estos nodos es escasa y, en general, no existe un protocolo de consenso comúnmente utilizado por las cadenas públicas, por lo que proporciona una seguridad muy deficiente. Debe confiar en Ethereum para garantizar la confiabilidad de la publicación de datos y la efectividad de las transiciones de estado. sexo.

Protocolo acumulativo de arbitraje:

Se trata de una serie de contratos que definen la estructura del bloque RBlock de la cadena Rollup, el método de continuación de la cadena, el lanzamiento de RBlock y el proceso del modo de desafío. Tenga en cuenta que la cadena acumulada mencionada aquí no es el libro mayor de Capa 2 que todos entienden, sino una "estructura de datos similar a una cadena" abstracta configurada de forma independiente por Arbitrum One para implementar el mecanismo a prueba de fraude.

Un RBlock puede contener los resultados de varios bloques L2 y los datos también son muy diferentes. Su entidad de datos RBlock se almacena en una serie de contratos en RollupCore. Si hay un problema con un RBlock, el Validador desafiará al remitente del RBlock.

Validador:

Los nodos de validación de Arbitrum son en realidad un subconjunto especial de nodos completos de Capa 2 y actualmente tienen acceso a una lista blanca.

El validador crea un nuevo RBlock (bloque Rollup, también llamado aserción) basado en el lote de transacciones enviado por el secuenciador al contrato SequencerInbox, además de monitorear el estado de la cadena Rollup actual y cuestionar los datos incorrectos enviados por el secuenciador.

Active Validator necesita apostar activos en la cadena ETH por adelantado. A veces también lo llamamos Staker. Aunque los nodos de Capa 2 que no hacen stake también pueden monitorear la dinámica de operación de Rollup y enviar alarmas anormales a los usuarios, no pueden intervenir directamente en los datos de error enviados por el secuenciador en la cadena ETH.

Desafío:

Los pasos básicos se pueden resumir en múltiples rondas de segmentación interactiva y prueba en un solo paso. En el proceso de segmentación, las partes desafiantes primero realizan múltiples rondas de segmentación de los datos de la transacción problemática hasta que descomponen las instrucciones del código de operación problemática y realizan la verificación. Los desarrolladores de Arbitrum consideran que el paradigma de “múltiples rondas de prueba de segmentación en un solo paso” es la implementación de prueba de fraude que ahorra más combustible. Todos los enlaces están bajo control contractual y ninguna parte puede hacer trampa.

Periodo de desafío:

Debido a la naturaleza optimista de OP Rollup, después de que cada RBlock se envía a la cadena, el contrato no se verifica activamente, lo que deja un período de ventana para que el verificador falsifique. Este período de ventana es el período de desafío, que dura 1 semana en la red principal de Arbitrum One. Una vez finalizado el período de desafío, finalmente se confirmará el RBlock. Solo se pueden liberar los mensajes correspondientes pasados de L2 a L1 dentro del bloque (como las operaciones de retiro realizadas a través del puente oficial).

ArbOS, Geth, WAVM:

La máquina virtual utilizada por Arbitrum se llama AVM, que incluye Geth y ArbOS. Geth es el software cliente más utilizado en Ethereum y Arbitrum le ha realizado ligeras modificaciones. ArbOS es responsable de todas las funciones especiales relacionadas con L2, como la gestión de recursos de red, la generación de bloques L2, el trabajo con EVM, etc. Consideramos la combinación de los dos como una AVM nativa, que es la máquina virtual utilizada por Arbitrum. WAVM es el resultado de compilar código AVM en Wasm. En el proceso de impugnación Arbitrum, la última "prueba en un paso" verifica la instrucción WAVM.

Aquí, podemos usar la siguiente figura para representar la relación y el flujo de trabajo entre los componentes anteriores:

Ciclo de vida de la transacción en L2

El flujo de procesamiento de una transacción en L2 es el siguiente:

1. Los usuarios envían instrucciones comerciales al secuenciador.

2. El secuenciador primero verifica las transacciones que se procesarán en firmas digitales y otros datos, elimina transacciones no válidas y realiza secuencias y cálculos.

3. El secuenciador envía el recibo de la transacción al usuario (generalmente muy rápido), que es solo el "preprocesamiento" realizado por el clasificador bajo la cadena ETH. Está en el estado de Finalidad Suave y no es confiable. Pero los usuarios (la mayoría de los usuarios) que confían en el secuenciador pueden ser optimistas de que la transacción se ha completado y no se revertirá.

4. El secuenciador comprime en gran medida los datos de la transacción original preprocesados y los encapsula en un lote.

5. De vez en cuando (afectado por factores como el volumen de datos y la congestión de ETH), el secuenciador publicará lotes de transacciones en el contrato de la bandeja de entrada del secuenciador en L1. En este punto, se puede considerar que la transacción tiene Finalidad Dura.

Contrato de bandeja de entrada del secuenciador

El contrato recibirá el lote de transacciones enviado por el secuenciador para garantizar la disponibilidad de datos. Si miramos esto más profundamente, los datos por lotes en Sequencer Inbox registran completamente la información de entrada de transacciones de Layer2. Incluso si el secuenciador está inactivo permanentemente, cualquiera puede restaurar el estado actual de la Capa 2 según el registro del lote y reemplazar el secuenciador defectuoso o en ejecución.

Para entenderlo de forma física, el L2 que vemos es solo la proyección del lote en SequencerInbox, y la fuente de luz es STF. Debido a que la fuente de luz STF no cambia fácilmente, la forma de la sombra solo está determinada por el lote que actúa como objeto.

El contrato de Sequencer Inbox se llama caja rápida. El secuenciador le envía específicamente transacciones preprocesadas, y solo el secuenciador puede enviarle datos. La casilla rápida correspondiente es la casilla lenta Delayer Inbox, y su función se describirá en el proceso posterior.

El validador siempre supervisará el contrato de la bandeja de entrada del secuenciador. Siempre que el secuenciador libere un lote al contrato, se producirá un evento en cadena. Después de que el Validador detecte la ocurrencia de este evento, descargará los datos del lote. Después de la ejecución local, RBlock se emitirá al contrato del protocolo Rollup en la cadena ETH.

El contrato puente de Arbitrum tiene un parámetro llamado acumulador, que registra el lote L2 recién enviado, así como el número y la información de las transacciones recién recibidas en la bandeja de entrada lenta.

(El secuenciador envía lotes continuamente a la bandeja de entrada del secuenciador)

（La información específica del Lote; el campo de datos corresponde a los datos del lote. El tamaño de esta parte de los datos es muy grande y la captura de pantalla no se muestra completamente).

El contrato SequencerInbox tiene dos funciones principales:

agregar secuenciador L2Batch desde origen()

El secuenciador llamará a esta función cada vez para enviar datos por lotes al contrato de Sequencer Inox.

forzar inclusión()

Cualquiera puede llamar a esta función y se utiliza para implementar transacciones resistentes a la censura. La forma en que esta función entra en vigor se explicará en detalle más adelante cuando hablemos del contrato de Bandeja de entrada retrasada.

Las dos funciones anteriores llamarán a 'bridge.enqueueSequencerMessage()' para actualizar el parámetro del acumulador en el contrato puente.

Precio del gas

Obviamente, las transacciones L2 no pueden ser gratuitas, porque esto conducirá a ataques DoS. Además, existen costos operativos para el clasificador L2 en sí y habrá gastos generales para enviar datos en L1. Cuando un usuario inicia una transacción dentro de la red de Capa 2, la estructura de tarifas de gas sería la siguiente:

Costos de publicación de datos incurridos al ocupar recursos de Capa1

Este costo proviene principalmente de los lotes enviados por el secuenciador (cada lote tiene muchas transacciones de usuario) y, en última instancia, el costo se comparte equitativamente entre los iniciadores de transacciones. El algoritmo de fijación de precios de tarifas generado por la publicación de datos es dinámico y el secuenciador fijará el precio en función del estado reciente de pérdidas y ganancias, el tamaño del lote y el precio actual del gas Ethereum.

El costo incurrido por los usuarios que ocupan recursos de Capa 2.

Se establece un límite de gas para TPS para asegurar el funcionamiento estable del sistema (actualmente 7 millones en Arbitrum One). ArbOS realiza un seguimiento y ajusta los precios orientativos del gas para L1 y L2, y la fórmula no se detalla aquí por ahora.

Aunque el proceso de cálculo del precio específico del gas es relativamente complicado, los usuarios no necesitan conocer estos detalles y pueden sentir claramente que las tarifas de transacción acumuladas son mucho más baratas que las de la red principal de ETH.

Prueba de fraude optimista

Recordando lo anterior, L2 es en realidad solo la proyección del lote de entrada de transacciones enviado por el secuenciador en el cuadro rápido, es decir:

Entradas de transacciones -> STF -> Salidas de estado. La entrada se ha determinado y el STF no ha cambiado, por lo que también se determina el resultado de salida. El sistema de prueba de fraude y protocolo Arbitrum Rollup es un sistema que publica la raíz del estado de salida en forma de RBlock (también conocido como aserción) en L1 y realiza pruebas optimistas sobre él.

En L1, hay datos de entrada publicados por el secuenciador y estado de salida publicado por el verificador. Considerémoslo detenidamente: ¿Es necesario publicar el estado de la Capa 2 en la cadena?

Debido a que la entrada ha determinado completamente la salida y los datos de entrada son públicamente visibles, ¿parece redundante enviar el estado del resultado de salida? Pero esta idea ignora la necesidad real de un acuerdo estatal entre los dos sistemas L1 y L2, es decir, el comportamiento de retirada de L2 a L1 requiere prueba del estado.

Al crear Rollup, una de las ideas centrales es colocar la mayor parte de la informática y el almacenamiento en L2 para evitar el alto costo de L1. Esto significa que L1 no conoce el estado de L2, solo ayuda a L2. El secuenciador publica los datos de entrada de todas las transacciones, pero no es responsable de calcular el estado de L2.

El comportamiento de retiro es esencialmente desbloquear los fondos correspondientes del contrato L1, transferirlos a la cuenta L1 del usuario o completar otras cosas siguiendo el mensaje entre cadenas proporcionado por L2.

En este momento, el contrato de Capa 1 preguntará: ¿Cuál es su estado en la Capa 2 y cómo demostrar que realmente posee los activos que declara transferir? En este momento, el usuario deberá proporcionar el Merkle Proof correspondiente, etc.

Por lo tanto, si construimos un Rollup sin función de retiro, en teoría es posible no sincronizar el estado con L1 y no hay necesidad de un sistema de prueba de estado como el de fraude (aunque puede causar otros problemas). Pero en aplicaciones reales, esto obviamente no es factible.

En la llamada prueba optimista, el contrato no verifica si el estado de salida enviado a L1 es correcto, pero cree con optimismo que todo es exacto. El sistema de prueba optimista supone que hay al menos un Validador honesto en cualquier momento. Si se produce un estado incorrecto, se impugnará mediante prueba de fraude.

La ventaja de este diseño es que no es necesario verificar activamente cada RBlock emitido a L1 para evitar el desperdicio de gas. De hecho, para OPR, no es realista verificar cada afirmación, porque cada Rblock contiene uno o más bloques L2 y cada transacción debe volver a ejecutarse en L1. No es diferente de ejecutar transacciones L2 directamente en L1, lo que hace que la expansión de la Capa 2 no tenga sentido.

ZKR no tiene este problema porque ZK Proof es conciso. Solo necesita verificar una Prueba muy pequeña y no es necesario ejecutar muchas transacciones correspondientes a la Prueba. Por lo tanto, ZKR no actúa con optimismo. Cada vez que se publica el estado, habrá un contrato de Verificador para la verificación matemática.

Aunque la prueba de fraude no puede ser tan concisa como la prueba de conocimiento cero, Arbitrum utiliza un proceso interactivo por turnos de “múltiples rondas de segmentación y prueba de un solo paso”. Al final, lo que hay que probar es solo un código de operación de máquina virtual y el costo es relativamente pequeño.

Protocolo acumulativo

Primero echemos un vistazo a la entrada para iniciar desafíos e iniciar pruebas, es decir, cómo funciona el protocolo Rollup.

El contrato principal del protocolo Rollup es RollupProxy.sol, que utiliza una estructura de agente dual poco común al tiempo que garantiza que la estructura de datos sea consistente. Un agente corresponde a dos implementaciones de RollupUserLogic.sol y RollupAdminLogic.sol, que no pueden analizarse bien con herramientas como Scan.

Además, el contrato ChallengeManager.sol es responsable de gestionar los desafíos y los contratos de la serie OneStepProver se utilizan para determinar las pruebas de fraude.

(Fuente: sitio web oficial de L2BEAT)

Esto muestra el registro de una serie de RBlocks (también conocidos como afirmaciones), en RollupProxy, enviados por diferentes Validadores, que son los cuadros en la siguiente figura: Verde confirmado, azul no confirmado, amarillo falsificado.

RBlock contiene el estado final después de la ejecución de uno o más bloques L2 desde el último RBlock. Estos RBlocks forman una cadena acumulada formal (tenga en cuenta que el libro mayor L2 en sí es diferente). En circunstancias optimistas, esta Cadena Acumulada no debería tener bifurcaciones, porque una bifurcación significa que un Validador ha enviado Bloques Acumulados en conflicto.

Para proponer o estar de acuerdo con una afirmación, el verificador primero debe apostar una cierta cantidad de ETH para la afirmación y convertirse en Staker. De esta manera, cuando se produzca una impugnación/prueba de fraude, la garantía del perdedor se reducirá drásticamente. Esta es la base económica para asegurar el comportamiento honesto del verificador.

El bloque azul número 111 en la esquina inferior derecha de la imagen eventualmente será cortado porque su bloque principal número 104 (amarillo) es incorrecto.

Además, el verificador A propuso el Rollup Block No. 106, pero B no estuvo de acuerdo y lo impugnó.

Después de que B inicie el desafío, el contrato ChallengeManager será responsable de verificar la segmentación de los pasos del desafío:

1. La segmentación es un proceso en el que ambas partes se turnan para interactuar. Una parte segmenta los datos históricos contenidos en un determinado Rollup Block y la otra parte señala qué parte del fragmento de datos es problemática, un proceso similar a la dicotomía (en realidad N/K) que estrecha el alcance de forma continua y gradual.

2. Después de eso, puede continuar localizando la transacción y el resultado que son problemáticos, y luego subdividirlos en una instrucción de máquina en disputa en la transacción.

3. El contrato ChallengeManager solo verifica si los "fragmentos de datos" generados después de segmentar los datos originales son válidos.

4. Cuando el retador y la parte desafiada localizan la instrucción de máquina que será desafiada, el retador llama a la función 'oneStepProveExecution()' y envía una prueba de fraude de un solo paso para demostrar que hay un problema con el resultado de la ejecución de esta instrucción de máquina.

Prueba en un solo paso

La prueba en un solo paso es el núcleo de toda la prueba de fraude de Arbitrum. Echemos un vistazo a lo que demuestra específicamente la prueba de un solo paso.

Esto requiere primero comprender WAVM. Wasm Arbitrum Virtual Machine es una máquina virtual compilada por el módulo ArbOS y el módulo central Geth (cliente Ethereum). Dado que L2 es muy diferente de L1, el núcleo Geth original tuvo que modificarse ligeramente y funcionar con ArbOS.

Por lo tanto, la transición de estado en L2 es en realidad el trabajo conjunto de ArbOS+Geth Core.

El cliente de nodo de Arbitrum (secuenciador, verificador, nodo completo, etc.) compila el programa de procesamiento ArbOS+Geth Core mencionado anteriormente en código de máquina nativo que el host del nodo puede procesar directamente (para x86/ARM/PC/Mac/etc.).

Si cambia el idioma de destino obtenido después de la compilación a Wasm, obtendrá el WAVM utilizado por el verificador al generar pruebas de fraude, y el contrato para verificar la prueba de un solo paso también simula las funciones de la máquina virtual WAVM.

Entonces, ¿por qué es necesario compilarlo en el código de bytes de Wasm al generar pruebas de fraude? La razón principal es que, para verificar el contrato a prueba de fraude en un solo paso, es necesario utilizar el contrato inteligente de Ethereum para simular una máquina virtual VM que pueda manejar un determinado conjunto de conjuntos de instrucciones, y WASM es fácil de implementar la simulación en el contrato.

Sin embargo, WASM se ejecuta un poco más lento que el código de máquina nativo, por lo que los nodos/contratos de Arbitrum utilizarán WAVM solo al generar y verificar pruebas de fraude.

Después de las rondas anteriores de segmentación interactiva, la prueba de un paso finalmente demostró la instrucción de un paso en el conjunto de instrucciones WAVM.

Como se puede ver en el código siguiente, OneStepProofEntry primero determina a qué categoría pertenece el código de operación de la instrucción que se va a probar y luego llama al probador correspondiente, como Mem, Math, etc., para pasar la instrucción de un paso al contrato de prueba.

El resultado final después de Hash se devolverá al ChallengeManager. Si el hash es inconsistente con el hash después de la operación de instrucción registrada en el bloque acumulativo, el desafío tiene éxito. Si son consistentes, significa que no hay ningún problema con el resultado de la ejecución de esta instrucción registrada en el bloque acumulativo y el desafío falló.

En la parte 2, analizaremos Arbitrum e incluso el módulo de contrato que maneja funciones de mensajería/puente entre cadenas entre Layer2 y Layer1, y aclararemos más cómo una verdadera Layer2 debería lograr resistencia a la censura.

Descargo de responsabilidad:

1. Este artículo está reimpreso de [WeChat]. Todos los derechos de autor pertenecen al autor original [Luo Benben]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.