Forward the Original Title：

Este artículo proporciona una interpretación técnica de Arbitrum One por Luo Benben (罗奔奔), ex embajador técnico de Arbitrum y ex cofundador de Goplus Security, una empresa de auditoría de automatización de contratos inteligentes.

Debido a la falta de interpretación profesional de Arbitrum e incluso OP Rollup en artículos o materiales en chino relacionados con Layer 2, este artículo intenta llenar el vacío en este campo popularizando el mecanismo de funcionamiento de Arbitrum. Dado que la estructura de Arbitrum en sí es demasiado compleja, aunque el texto completo se ha simplificado tanto como sea posible, todavía supera las 10,000 palabras, por lo que se divide en dos partes. ¡Se recomienda recopilarlo y reenviarlo como referencia!

Introducción breve del secuenciador Rollup

El principio de expansión Rollup se puede resumir en dos puntos:

Optimización de costes: Transferir la mayor parte de las tareas informáticas y de almacenamiento a la L1 offchain, es decir, a la L2. L2 es principalmente una cadena que se ejecuta en un solo servidor, es decir, el secuenciador/operador.

El secuenciador está cerca de un servidor centralizado en cierto sentido. En la “trinidad imposible de blockchain”, se abandona la “descentralización” a cambio de TPS y ventajas de costos. Los usuarios pueden hacer que L2 procese instrucciones de transacción en lugar de Ethereum, y el costo es mucho menor que operar en Ethereum.

(Fuente: Cadena BNB)

Garantía de seguridad: El contenido de la transacción y el estado resultante en la Capa 2 se sincronizan con la Capa 1 de Ethereum, donde su validez se verifica a través de contratos. Mientras tanto, Ethereum conserva los registros históricos de L2, por lo que incluso si el secuenciador se bloquea permanentemente, otros pueden reconstruir todo el estado de L2 a partir de los registros en Ethereum.

Fundamentalmente, la seguridad de Rollup se basa en Ethereum. Si un 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 esa cuenta (incluso si se intenta, se detectaría rápidamente).

Aunque el secuenciador, como eje central del sistema, puede tener un tono centralizado, en las soluciones Rollup maduras, un secuenciador centralizado solo puede participar en comportamientos maliciosos suaves, como la censura de transacciones o bloqueos maliciosos. Sin embargo, en las soluciones Rollup ideales, existen medidas correspondientes para restringir tales comportamientos (como retiros forzosos o clasificación de pruebas como 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 lo llamen)

Para evitar el comportamiento malicioso de los secuenciadores de Rollup, existen dos tipos de métodos de verificación de estado: Prueba de Fraude y Prueba de Validez. Las soluciones de Rollup que utilizan Prueba de Fraude se llaman Rollup Optimista (RO), mientras que las que utilizan Prueba de Validez a menudo se denominan Rollup ZK (Rollup de Prueba de Conocimiento Cero, ZKR), en lugar de Rollup de Validez, debido a problemas históricos.

Arbitrum One es una OPR típica, implementada en contratos L1, que no validan activamente los datos enviados, sino que asumen con optimismo que los datos son correctos. Si hay errores en los datos enviados, los validadores de L2 iniciarán impugnaciones.

Por lo tanto, OPR también implica una suposición de confianza: hay al menos un nodo validador L2 honesto en un momento dado. Por otro lado, los contratos ZKR verifican de forma proactiva y rentable los datos enviados por el secuenciador a través de cálculos criptográficos.

(Método de operación de Optimistic Rollup)

(Método de operación de ZK Rollup)

Este artículo proporcionará una introducción detallada al proyecto líder en Optimistic Rollup — Arbitrum One, cubriendo todos los aspectos del sistema. Después de leer cuidadosamente, obtendrás un profundo entendimiento 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, Puertas de Nivel 1, Puertas de Nivel 2, Outbox, RollupCore, Puente, etc. Estos se detallarán más adelante.

Secuenciador:

Recibe transacciones de usuarios y las secuencia, calcula los resultados de las transacciones y devuelve rápidamente (generalmente <1s) los recibos a los usuarios. Los usuarios suelen ver sus transacciones confirmadas en L2 en cuestión de segundos, lo que proporciona una experiencia similar a Web2.

Además, el secuenciador transmite inmediatamente los últimos Bloques L2 generados bajo la cadena de Ethereum, que cualquier nodo de Capa 2 puede recibir de forma asincrónica. Sin embargo, en este punto, estos Bloques L2 no tienen finalidad y pueden ser revertidos por el secuenciador.

Cada pocos minutos, el secuenciador comprime los datos de transacciones L2 secuenciados, los agrega en lotes y los envía al contrato SequencerInbox en la Capa 1 para garantizar la disponibilidad de datos y el funcionamiento del protocolo Rollup. Por lo general, los datos L2 enviados a la Capa 1 no pueden ser revertidos y pueden tener finalidad.

Desde el proceso anterior, podemos resumir que Layer 2 tiene su propia red de nodos, pero estos nodos son pocos en número y generalmente carecen de los protocolos de consenso comúnmente utilizados en blockchains públicas. Por lo tanto, su seguridad es pobre y deben depender de Ethereum para garantizar la confiabilidad de la publicación de datos y la validez de las transiciones de estado.

Protocolo de Arbitrum Rollup:

Define la estructura de bloques, llamados RBlocks, en la cadena Rollup, la continuación de la cadena, la publicación de RBlocks, el proceso del modo desafío, etc., a través de una serie de contratos. Es importante tener en cuenta que la cadena Rollup mencionada aquí no es el libro mayor comúnmente entendido como Capa 2, sino más bien una "estructura de datos similar a una cadena" abstracta establecida de forma independiente por Arbitrum One para implementar mecanismos a prueba de fraude.

Un RBlock puede contener los resultados de varios bloques L2, y su entidad de datos, RBlock, se almacena en una serie de contratos dentro de RollupCore. Si hay un problema con un RBlock, los validadores lo desafiarán basándose en las presentaciones del creador del RBlock.

Validadores:

Los validadores en Arbitrum son en realidad un subconjunto especial de nodos completos de Capa 2, actualmente con admisión en lista blanca.

Los validadores crean nuevos RBlocks (bloques de Rollup, también llamados afirmaciones) basados en lotes de transacciones enviadas al contrato SequencerInbox por el secuenciador, y monitorean el estado actual de la cadena Rollup para desafiar los datos incorrectos enviados por el secuenciador.

Los validadores activos necesitan apostar activos en la cadena de Ethereum con antelación, a veces se les llama validadores. Aunque los nodos de Capa 2 que no apuestan activos pueden monitorear la operación del Rollup y enviar alertas a los usuarios sobre anomalías, no pueden intervenir directamente en los datos incorrectos enviados por el secuenciador en la cadena de Ethereum.

Desafío:

Los pasos básicos se pueden resumir como subdivisión interactiva multirronda y prueba de un solo paso. En la fase de subdivisión, ambos desafiantes participan primero en una subdivisión interactiva multirronda de los datos de transacción problemáticos hasta que se descomponga y verifique la instrucción de opcode problemática. Los desarrolladores de Arbitrum consideran que el paradigma de "subdivisión multirronda-prueba de un solo paso" es la implementación más eficiente en gas de la prueba de fraude. Todos los pasos están controlados por contratos inteligentes y ninguna de las partes puede hacer trampa.

Período de desafío:

Debido a la naturaleza optimista de OP Rollup, después de que se envía cada RBlock a la cadena, el contrato no lo verifica activamente, dejando un período de tiempo para que los validadores lo falsifiquen. Esta ventana de tiempo es el período de desafío, que es de una semana en la red principal de Arbitrum One. Después de que finalice el período de desafío, el RBlock se confirmará finalmente, y los mensajes correspondientes a las transacciones de L2 a L1 (como las operaciones de retiro ejecutadas a través del puente oficial) pueden ser liberados.

ArbOS, Geth, WAVM:

Arbitrum utiliza una máquina virtual llamada AVM, que consta de Geth y ArbOS. Geth es el software cliente más utilizado para 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 y el trabajo en coordinación con EVM. Consideramos la combinación de ambos 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 de Arbitrum, la "prueba de un solo paso" final verifica las instrucciones de WAVM.

Aquí, podemos representar las relaciones y flujos de trabajo entre los diversos componentes utilizando el diagrama a continuación:

Ciclo de Vida de la Transacción L2

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

1. El usuario envía instrucciones de transacción al secuenciador.
2. El secuenciador primero verifica los datos, incluidas las firmas digitales, de las transacciones que se van a procesar, filtra las transacciones inválidas y luego las ordena y calcula.
3. El secuenciador envía el recibo de la transacción al usuario (generalmente muy rápidamente), pero esto es solo el "preprocesamiento" realizado por el secuenciador en la cadena de Ethereum, y está en un estado de Finalidad Blanda y no es confiable. Sin embargo, para los usuarios que confían en el secuenciador (la mayoría de los usuarios), pueden asumir de manera optimista que la transacción se ha completado y no será revertida.
4. El secuenciador encapsula los datos de transacción preprocesados en un lote después de comprimirlos en gran medida.
5. A intervalos regulares (afectado por factores como el volumen de datos y la congestión de Ethereum), el secuenciador publica el lote de la transacción 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 de Secuenciador

El contrato recibe lotes de transacciones enviadas por el secuenciador para garantizar la disponibilidad de datos. En profundidad, los datos del lote en el buzón del secuenciador registran completamente la información de entrada de transacciones de Layer2. Incluso si el secuenciador se bloquea permanentemente, cualquiera puede restaurar el estado actual de Layer2 basándose en los registros del lote y hacerse cargo del secuenciador fallido/faltante.

En una analogía física, lo que vemos como L2 es solo la proyección del lote en la Bandeja de secuenciador, mientras que la fuente de luz es la Finalidad Suave. Debido a que la fuente de luz Finalidad Suave no cambia fácilmente, la forma de la sombra está determinada solo por el lote que actúa como objeto.

El contrato de buzón del secuenciador también se llama caja rápida, y el secuenciador envía específicamente transacciones preprocesadas a él, y solo el secuenciador puede enviar datos a él. La caja lenta correspondiente es el buzón del retrasador, cuya función se describirá en el proceso posterior.

Los validadores monitorearán continuamente el contrato de Bandeja de entrada del Secuenciador. Cada vez que el secuenciador publique un Lote en este contrato, se activará un evento en cadena. Al detectar este evento, el validador descargará los datos del lote, los ejecutará localmente y luego publicará un RBlock en el contrato del protocolo de Rollup en la cadena de Ethereum.

El contrato puente de Arbitrum tiene un parámetro llamado el acumulador, que registra información sobre el lote L2 recién enviado y el número de transacciones recibidas en el buzón lento, entre otras cosas.

(El secuenciador envía continuamente lotes a SequencerInbox)

（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:

add Sequencer L2Batch From Origin()，El secuenciador llamará a esta función cada vez para enviar datos de lote al contrato Sequencer Inox.

force Inclusion()，Esta función puede ser llamada por cualquier persona y se utiliza para implementar transacciones resistentes a la censura. La forma en que esta función tiene efecto se explicará detalladamente más adelante cuando hablemos del contrato Delayed Inbox.

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

Precios de gas

Obviamente, las transacciones L2 no pueden ser gratuitas, porque esto llevará a ataques DoS. Además, existen costos operativos para el propio secuenciador L2, 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 es la siguiente:

El costo de la publicación de datos generados por la ocupación de recursos de Layer1 proviene principalmente de los lotes enviados por el secuenciador (cada lote contiene transacciones de muchos usuarios), y el costo se comparte en última instancia entre los iniciadores de transacciones. El algoritmo de fijación de precios para las tarifas de transacción generadas por la publicación de datos es dinámico. El secuenciador ajusta el precio en función de las condiciones recientes de ganancias y pérdidas, el tamaño del lote y el precio actual del gas en Ethereum.

El costo incurrido por los usuarios por ocupar los recursos de Layer2 se determina estableciendo un límite máximo en el gas procesado por segundo para garantizar el funcionamiento estable del sistema (actualmente Arbitrum One es de 7 millones). Los precios de orientación del gas tanto para L1 como para L2 son rastreados y ajustados por ArbOS, y la fórmula no se elabora aquí.

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

Prueba de fraude optimista

Mirando hacia atrás en el texto anterior, es evidente que Layer2 (L2) es esencialmente solo una proyección de los lotes de entrada de transacciones enviados por el secuenciador en la Bandeja de entrada del Secuenciador:

Entradas de transacción -> Función de transición de estado (STF) -> Salidas de estado

Las entradas ya están determinadas y el STF es inmutable, por lo que el resultado de la salida también está determinado. El sistema de prueba de fraude y protocolo de Arbitrum Rollup publican el estado de salida, representado por un RBlock (también conocido como una afirmación), en Layer1 y proporcionan pruebas optimistas para ello.

En L1, tanto los datos de entrada publicados por el secuenciador como los estados de salida publicados por los validadores. Tras una cuidadosa consideración, ¿es necesario publicar el estado de Layer2 en la cadena? Dado que las entradas ya han determinado completamente las salidas y los datos de entrada son visibles públicamente, parece redundante enviar los resultados de salida o el estado. Sin embargo, esta idea pasa por alto el hecho de que es necesario realizar un ajuste de estados entre los sistemas L1 y L2. Esto es especialmente necesario para las acciones de retiro de L2 a L1, que requieren una prueba de estado.

Al construir Rollup, la idea principal es trasladar la mayoría de los cálculos y el almacenamiento a L2 para evitar los altos costos de L1. Esto implica que L1 no conoce el estado de L2; solo ayuda al secuenciador de L2 a publicar los datos de entrada de todas las transacciones, pero no es responsable de calcular el estado de L2.

Las acciones de retiro implican principalmente desbloquear los activos correspondientes del contrato L1 basándose en los mensajes intercadenas proporcionados por L2 y transferirlos a la cuenta L1 del usuario o completar otras tareas.

En este punto, el contrato de Layer1 preguntará: ¿cuál es su estado en Layer2 y cómo demuestra que realmente posee los activos que está reclamando transferir? En esta etapa, los usuarios deben proporcionar Pruebas de Merkle correspondientes, etc.

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

En la llamada prueba optimista, el contrato no verifica si el estado de salida enviado a L1 es correcto, sino que cree optimistamente que todo es preciso. El sistema de prueba optimista asume que siempre hay al menos un Validador honesto. Si ocurre un estado incorrecto, se impugnará a través de una prueba de fraude.

La ventaja de este diseño es que no es necesario verificar activamente cada RBlock emitido a L1 para evitar desperdiciar gas. De hecho, para OPR, es irrealizable verificar cada afirmación, ya que cada Rblock contiene uno o más bloques L2, y cada transacción debe ser reejecutada en L1. No difiere de ejecutar transacciones L2 directamente en L1, lo que pierde el significado de la escalabilidad de la Capa 2.

ZKR no enfrenta este problema porque las Pruebas de Conocimiento Cero (ZK Proofs) tienen concisión, lo que solo requiere la validación de una pequeña prueba sin necesidad de ejecutar realmente las numerosas transacciones detrás de la prueba. Por lo tanto, ZKR no opera de manera optimista; cada publicación de estado está acompañada de una verificación matemática por parte de un contrato Verificador.

Aunque las pruebas de fraude no pueden lograr el alto nivel de concisión como las pruebas de conocimiento cero, Arbitrum emplea un proceso interactivo de "subdivisión de múltiples rondas - prueba de un solo paso", donde en última instancia solo se debe probar un solo opcode de máquina virtual, lo que resulta en costos relativamente más bajos.

protocolo Rollup

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

El contrato central del protocolo Rollup es RollupProxy.sol. Mientras se asegura de que la estructura de datos sea consistente, se utiliza una rara estructura de agente dual. Un agente corresponde a dos implementaciones de RollupUserLogic.sol y RollupAdminLogic.sol, que no pueden ser bien analizadas por 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 pruebas de fraude.

(Fuente: sitio web oficial de L2BEAT)

En el RollupProxy, se registran una serie de RBlocks (también conocidos como afirmaciones) enviados por diferentes validadores, representados por bloques en el diagrama: verde para confirmados, azul para no confirmados y amarillo para refutados.

El RBlock contiene el estado final resultante de la ejecución de uno o más bloques L2 desde el RBlock anterior. Estos RBlocks forman una cadena de Rollup en apariencia (tenga en cuenta la distinción del propio libro mayor L2). En un escenario optimista, esta cadena de Rollup no debería tener bifurcaciones, ya que la bifurcación implica que los validadores envíen bloques de Rollup conflictivos.

Para proponer o aceptar una afirmación, los validadores deben apostar una cierta cantidad de ETH, convirtiéndose en un Validador. Esto garantiza la base económica para un comportamiento honesto entre los validadores, ya que la apuesta del perdedor se perderá en caso de desafío/prueba de fraude.

El bloque azul numerado 111 en la esquina inferior derecha del diagrama será finalmente refutado porque su bloque padre, el bloque número 104, es incorrecto (amarillo).

Además, el Validador A ha propuesto el Bloque de Rollup 106, con el que el Validador B no está de acuerdo y desafía.

Después de que B inicie el desafío, el contrato ChallengeManager es 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 cierto Bloque de Rollup, 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 continuamente y gradualmente el alcance.

2. Posteriormente, se puede precisar aún más qué transacción y sus resultados son problemáticos, luego subdividirlos aún más en la instrucción de máquina específica dentro de esa transacción que se disputa.

3. El contrato ChallengeManager solo verifica si el "segmento de datos" generado después de subdividir los datos originales es válido.

4. Cuando el retador y la parte desafiada identifican la instrucción de máquina a desafiar, el retador invoca oneStepProveExecution() para enviar una prueba de fraude de un solo paso, demostrando que el resultado de ejecución de esta instrucción de máquina es defectuoso.

Prueba de un paso

La prueba de un solo paso es el núcleo de toda la prueba de fraude de Arbitrum. Veamos qué prueba específicamente demuestra la prueba de un solo paso.

Esto requiere entender primero WAVM. Wasm Arbitrum Virtual Machine es una máquina virtual compilada por el módulo ArbOS y el módulo principal de Geth (cliente de Ethereum). Dado que L2 es muy diferente de L1, el núcleo original de Geth tuvo que ser ligeramente modificado y trabajar 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, validador, nodo completo, etc.) compila el programa de procesamiento ArbOS+Geth Core mencionado anteriormente en código máquina nativo que el host del nodo puede procesar directamente (para x86/ARM/PC/Mac, etc.).

Si cambias el lenguaje objetivo obtenido después de la compilación a Wasm, obtendrás 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 cuando se generan pruebas de fraude? La razón principal es que para verificar el contrato a prueba de fraude en un solo paso, es necesario usar el contrato inteligente de Ethereum para simular una máquina virtual VM que pueda manejar un cierto conjunto de conjuntos de instrucciones, y WASM es fácil de implementar la simulación en el contrato.

Sin embargo, WASM se ejecuta ligeramente 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 subdivisiones interactivas, la prueba de un solo paso finalmente demostró la instrucción de un solo paso en el conjunto de instrucciones de WAVM.

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

El resultado final después deHash será devuelto al ChallengeManager. Si el hash es inconsistente con el hash después de la operación de instrucción registrada en el Bloque de Rollup, el desafío es exitoso. Si son consistentes, significa que no hay problema con el resultado de ejecución de este comando registrado en el Bloque de Rollup, y el desafío falló.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [GateGeek Web3], Todos los derechos de autor pertenecen al autor original [Luo Benben, ex embajador técnico de Arbitrum, colaborador geek de web3]. If there are objections to this reprint, please contact the Gate Learnequipo, y lo resolverán rápidamente.
2. Responsabilidad de responsabilidad: Las vistas y opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.