El ex embajador técnico de Arbitrum explica la estructura de los componentes de Arbitrum (Parte 1)

Este artículo es la interpretación técnica de Arbitrum One por Luo Benben, ex embajador técnico de Arbitrum y ex cofundador de la empresa de auditoría de automatización de contratos inteligentes Goplus Security.

Escrito por: Luo Benben, ex embajador técnico de Arbitrum y colaborador geek de web3

**Este artículo es la interpretación técnica de Arbitrum One por Luo Benben, ex embajador técnico de Arbitrum y ex cofundador de la empresa de auditoría de automatización de contratos inteligentes Goplus Security. **

Debido a que falta una interpretación profesional de Arbitrum e incluso de OP Rollup en los artículos o materiales relacionados con la Capa 2 en el círculo chino, este artículo intenta llenar el vacío en este campo popularizando el mecanismo operativo de Arbitrum. Dado que la estructura de Arbitrum en sí es demasiado compleja, el texto completo aún supera las 10.000 palabras a pesar de estar lo más simplificado posible, por lo que se divide en dos partes. ¡Se recomienda recopilarlo y enviarlo como referencia! **

Breve descripción del clasificador acumulativo

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

**Optimización de costos: transfiera la mayoría de las tareas informáticas y de almacenamiento a la cadena L1, es decir, L2. **L2 es principalmente una cadena que se ejecuta en un único servidor, es decir, el secuenciador/operador.

El clasificador se ve y se siente cercano a un servidor centralizado: en los “tres aspectos imposibles de blockchain”, se abandona la “descentralización” a cambio de TPS y ventajas de costos. Los usuarios pueden permitir 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 posterior a la transacción en L2 se sincronizarán con Ethereum L1, y la validez de la transición de estado se verificará a través del contrato. **Al mismo tiempo, los registros históricos de L2 se conservarán en Ethereum. Incluso si el secuenciador está inactivo permanentemente, otros pueden restaurar todo el estado de L2 a través de los registros en Ethereum.

**Básicamente, la seguridad de Rollup se basa en Ethereum. **Si el secuenciador no conoce la clave privada de una cuenta, no puede iniciar transacciones en nombre de la cuenta o no puede alterar el saldo de activos de la cuenta (incluso si lo sabe, se descubrirá rápidamente).

Aunque el clasificador está centralizado como centro del sistema, ** en la solución Rollup relativamente madura, el clasificador centralizado solo puede implementar comportamientos suaves y malignos, como revisión de transacciones o tiempo de inactividad malicioso, ** pero en una solución acumulativa ideal, existen los medios correspondientes. para la contención (como mecanismos resistentes a la censura, como retiros forzosos o clasificación de pruebas).

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

Los métodos de verificación de estado para evitar que el secuenciador Rollup haga el mal se dividen en dos categorías: prueba de fraude y prueba de validez. El esquema acumulativo que utiliza prueba de fraude se denomina OP Rollup (Optimistic Rollup, OPR), mientras que debido a algunos antecedentes históricos, el esquema acumulativo que utiliza prueba de validez a menudo se denomina ZK Rollup** (Zero-knowledge Proof Rollup, ZKR) en lugar de Validity Rollup. .

Arbitrum One es un OPR típico: implementa contratos en L1 y no verifica activamente los datos enviados, y es optimista de que no hay problemas con los datos. Si los datos enviados son incorrectos, el nodo verificador L2 iniciará activamente un desafío.

Por lo tanto, **OPR también implica una suposición de confianza: hay al menos un nodo verificador L2 honesto en cualquier momento. **El contrato de ZKR utiliza cálculos criptográficos para verificar de forma activa pero rentable los datos enviados por el secuenciador.

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

(Modo de operación ZK Rollup)

Este artículo brindará una introducción detallada a Arbitrum One, el proyecto líder en resumen optimista, que cubrirá todos los aspectos de todo el sistema. Después de leerlo detenidamente, tendrá una comprensión profunda de Arbitrum y el resumen optimista/OPR.

Componentes principales y flujo de trabajo de Arbitrum

Contrato principal:

Los contratos más importantes de Arbitrum incluyen **SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, etc. **Los detalles se presentarán más adelante.

Secuenciador:

Reciba y clasifique transacciones de usuarios, calcule resultados de transacciones y devuelva recibos a los usuarios rápidamente (normalmente <1). Los usuarios a menudo pueden ver sus transacciones enumeradas en L2 en unos pocos segundos y la experiencia es similar a la de la plataforma Web2.

Al mismo tiempo, el secuenciador también transmitirá el último bloque L2 inmediatamente bajo la cadena Ethereum, y cualquier nodo Layer2 puede recibirlo de forma asíncrona. Pero en este momento, estos bloques L2 no son definitivos y el secuenciador puede revertirlos.

Cada pocos minutos, el secuenciador comprimirá los datos de transacciones L2 ordenados, los agregará en lotes y los enviará al contrato de bandeja de entrada SequencerInbox en Layer1 para garantizar la disponibilidad de los datos y el funcionamiento del protocolo Rollup. En términos generales, los datos L2 enviados a Layer1 no se pueden revertir y pueden ser definitivos.

Del proceso anterior, podemos resumir: ** La capa 2 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 la seguridad es muy pobre y debe garantizarse. confiando en Ethereum, confiabilidad de la publicación de datos y efectividad de las transiciones de estado. **

Protocolo acumulativo de arbitraje:

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 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 creada independientemente por Arbitrum One para implementar el mecanismo a prueba de fraude. **

Un RBlock puede contener los resultados de múltiples 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 la 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,** y monitorea el estado de la cadena Rollup actual y evalúa las transacciones enviadas por el secuenciador Desafío con datos incorrectos. **

El Validador activo necesita comprometer activos en la cadena ETH por adelantado, a veces también lo llamamos Staker. Aunque los nodos de Capa 2 que no se comprometen también pueden monitorear la dinámica de ejecució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 “**Subdivisión de múltiples rondas-prueba de un solo paso” es la implementación de prueba de fraude que ahorra más gas. **Todos los aspectos están bajo control del contrato y ninguna de las partes puede hacer trampa.

Período del 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. **Esta ventana de tiempo es el período del desafío, que es de 1 semana en la red principal de Arbitrum One. Una vez finalizado el período de desafío, finalmente se confirmará el RBlock y se podrán liberar los mensajes correspondientes pasados de L2 a L1 en el 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 de 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 de Arbitrum, la última “prueba de un solo 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 L2

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

1. El usuario envía instrucciones comerciales al secuenciador.

2. El clasificador primero verifica las transacciones que se procesarán en firmas digitales y otros datos, elimina las transacciones no válidas y realiza la clasificación y los cálculos.

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

4. El clasificador 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. Mirando más profundamente, los datos por lotes en SequencerInbox registran completamente la información de entrada de transacciones de la Capa 2. **Incluso si el secuenciador está permanentemente inactivo, cualquiera puede restaurar el estado actual de la Capa 2 según el registro del lote y reemplazar el secuenciador fallido/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 la bandeja de entrada del secuenciador también se denomina 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, su función se describirá en el proceso posterior.

El Validador siempre monitoreará el contrato de SequencerInbox. **Siempre que el secuenciador libere un lote al contrato, se generará un evento en cadena. Después de que el Validador escuche la ocurrencia de este evento, descargará los datos del lote y lo ejecutará. localmente Finalmente, emita RBlock al contrato de protocolo Rollup en la cadena ETH.

Hay un parámetro llamado acumulador en el contrato puente de Arbitrum, 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 continuamente lotes a SequencerInbox)

• *

(Información específica del lote, el campo de datos corresponde a los datos del lote, esta parte de los datos es muy grande y la captura de pantalla no se muestra completamente)

El contrato SequencerInbox tiene dos funciones principales:

agregue Sequencer L2Batch From Origin(), el secuenciador llamará a esta función cada vez para enviar datos por lotes al contrato de Sequencer Inox.

force Inclusion(), 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 acumulador de parámetros del acumulador en el contrato puente.

Precio de la gasolina

Obviamente, las transacciones de 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 los usuarios inician transacciones dentro de la red de Capa 2, la estructura de tarifas de gas es la siguiente:

El costo de publicación de datos incurrido al ocupar recursos de Capa1 proviene principalmente del lote enviado por el clasificador (cada lote tiene muchas transacciones de usuario) y, en última instancia, el costo lo comparten equitativamente los iniciadores de la transacción. El algoritmo de fijación de precios de tarifas generado por la publicación de datos es dinámico y el clasificador 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 en el que incurren los usuarios por ocupar recursos de Capa 2 establece un límite de gas que se puede procesar por segundo para garantizar el funcionamiento estable del sistema (actualmente Arbitrum One es de 7 millones). ArbOS rastrea y ajusta los precios guía del gas de L1 y L2, y las fórmulas no se describirán aquí por el momento.

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 clasificador 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 el resultado de salida también se determina. **El sistema de prueba de fraude y el protocolo Arbitrum Rollup publica la raíz del estado de salida en L1 en forma de RBlock (también conocido como afirmación) y es un sistema de prueba optimista. **

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

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

Al construir Rollup, una de las ideas centrales es colocar la mayor parte de la computación y el almacenamiento en L2 para evitar el alto costo de L1, lo que significa que L1 no conoce el estado de L2 y solo ayuda a L2 a publicar los datos de entrada en el secuenciador. de todas las transacciones, pero no es responsable de calcular el estado de L2.

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

En este momento, el contrato de Layer1 preguntará: ** ¿Cuál es su estado en Layer2 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 y cree con optimismo que todo es exacto. **El sistema de prueba optimista asumirá que hay al menos un Validador honesto en cualquier momento. Si ocurre un estado incorrecto, será impugnado mediante una 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, que pierde el significado de la expansión de la Capa 2.

ZKR no tiene este problema, porque ZK Proof es simple y solo necesita verificar una prueba muy pequeña, y no es necesario ejecutar muchas transacciones correspondientes a la prueba. Por lo tanto, ZKR no opera de manera optimista: cada vez que se publica el estado, habrá un contrato Verfier 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 “prueba de múltiples rondas divididas en un solo paso”. Al final, lo que necesita ser probado es solo una única máquina virtual. Código de operación, el costo es relativamente pequeño. **

Protocolo acumulativo

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

**El contrato principal del protocolo Rollup es RollupProxy.sol. **Bajo la condición de garantizar una estructura de datos consistente, se utiliza una estructura de agente dual poco común. Un agente corresponde a dos implementaciones de RollupUserLogic.sol y RollupAdminLogic.sol. En herramientas como Scan It aún no se pueden analizar bien.

También existe el contrato **ChallengeManager.sol responsable de gestionar los desafíos y la serie de contratos OneStepProver para determinar pruebas de fraude. **

(Fuente de la foto: sitio web oficial de L2BEAT)

En RollupProxy, se registra una serie de RBlocks (también conocidos como afirmaciones) 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, se perderá la garantía del perdedor, lo que constituye la base económica para garantizar el comportamiento honesto del verificador.

El bloque azul No. 111 en la esquina inferior derecha de la figura eventualmente será falsificado porque su bloque principal No. 104 es incorrecto (amarillo).

**Además, el verificador A propuso el Bloque Acumulado No. 106, pero B no estuvo de acuerdo y lo cuestionó. **

Después de que B inicia el desafío, el contrato ChallengeManager es responsable de verificar el desglose 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 bloque acumulativo 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 va estrechando continua y gradualmente el alcance.

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. Una vez que el retador y el retador han localizado la instrucción de la máquina que se va a desafiar, el retador llama a oneStepProveution() 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 la máquina. **

Prueba en un solo paso

La prueba en un solo paso es el núcleo de 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, que es una máquina virtual compilada por el módulo ArbOS y el módulo central Geth (cliente Ethereum). **Dado que L2 es completamente diferente de L1, el núcleo Geth original debe 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, validador, 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 puede procesar un determinado conjunto de conjuntos de instrucciones, y WASM es una simulación fácil de implementar. 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 subdivisiones interactivas, la prueba de un solo paso finalmente demuestra la instrucción de un solo paso en el conjunto de instrucciones WAVM. **

Como se puede ver en el código siguiente, OneStepProofEntry primero debe determinar a qué categoría pertenece el código de operación de la instrucción que se va a probar y luego llamar al probador correspondiente, como Mem, Math, etc., para pasar la instrucción de un solo paso a el 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 es exitoso. Si son consistentes, significa que no hay ningún problema con el resultado de la ejecución de este comando registrado en el bloque acumulativo y que el desafío falló.

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