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

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

**Este artículo es una interpretación técnica de Arbitrum One realizada por Benben Luo, 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 que los artículos o materiales que involucran la Capa 2 en el círculo chino carecen de una interpretación profesional de Arbitrum e incluso OP Rollup, este artículo intenta llenar el vacío en este campo popularizando el mecanismo de operación de Arbitrum. Debido a la complejidad de la estructura de Arbitrum en sí, el texto completo sigue siendo de más de 10.000 palabras sobre la base de simplificar tanto como sea posible, por lo que se divide en dos artículos, que se recomienda recopilar y enviar como materiales de referencia.**

Una breve descripción del secuenciador Rollup

El principio de escalado acumulativo se puede resumir en dos puntos:

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

El secuenciador se parece a un servidor centralizado, abandonando la “Descentralización” en “Blockchain Impossible Three Times” a cambio de TPS y ventajas de costos. Los usuarios pueden dejar que L2 procese las instrucciones de transacción en lugar de Ethereum a un costo mucho menor que operar en Ethereum.

**Seguridad: El contenido de la transacción en L2 y el estado después de la transacción 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, el historial de L2 se conservará en Ethereum, e incluso si el secuenciador está permanentemente inactivo, otros pueden restaurar todo el estado de L2 a través de los registros en Ethereum.

Fundamentalmente, la seguridad de los Rollups se basa en 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 esa cuenta (e incluso si lo hace, se reconoce rápidamente).

Aunque el secuenciador está centralizado como la columna vertebral del sistema, en el esquema Rollup relativamente maduro, el secuenciador centralizado solo puede implementar comportamientos malvados suaves, como la revisión de transacciones o el tiempo de inactividad malicioso, pero en el esquema Rollup ideal, existen los medios correspondientes para frenarlo (como mecanismos de resistencia a la censura, como retiros forzosos o pruebas de pedido).

Los métodos de verificación de estado para evitar que el secuenciador de rollup sea malvado se dividen en dos tipos: a prueba de fraude y a prueba de validez. Los resúmenes que utilizan pruebas de fraude se denominan OP Rollups (Optimistic Rollups, OPR) y, debido a algunos bagajes históricos, los Rollups que utilizan pruebas de validez a menudo se denominan ZK Rollups (Zero-knowledge Proof Rollups, ZKR) en lugar de Validity Rollups.

Arbitrum One es una OPR típica que despliega contratos en L1 y no valida activamente los datos enviados, creyendo con optimismo que no hay ningún problema con los datos. Si hay un error en los datos enviados, el nodo validador de L2 inicia un desafío.

Por lo tanto, OPR también implica una suposición de confianza: hay al menos un nodo validador L2 honesto en un momento dado. El contrato de ZKR, por otro lado, utiliza la criptografía para verificar de manera activa pero rentable los datos enviados por el secuenciador.

En este artículo, presentaremos en profundidad Arbitrum One, el proyecto líder en rollups optimistas, que cubre todos los aspectos de todo el sistema, y después de leer detenidamente, tendrá un conocimiento profundo de Arbitrum y el rollup/OPR optimista.

Componentes principales y flujos de trabajo de Arbitrum

Contratos básicos:

Los contratos más importantes de Arbitrum incluyen SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, etc. Más adelante hablaremos de ello.

Secuenciador:

Las transacciones de usuario se reciben y ordenan, se calculan los resultados de las transacciones y se devuelve un recibo al usuario rápidamente (generalmente < 1 s). Los usuarios a menudo pueden ver sus transacciones en la cadena L2 en cuestión de segundos, al igual que una plataforma Web2.

Al mismo tiempo, el secuenciador también transmitirá el último bloque L2 en tiempo real bajo la cadena Ethereum, y cualquier nodo de capa 2 puede recibirlo de forma asíncrona. Pero en este punto, estos bloques L2 no están finalizados y el secuenciador puede revertirlos.

Cada pocos minutos, el secuenciador comprimirá los datos de transacción L2 ordenados, los agregará en lotes y los enviará al contrato de bandeja de entrada SequencerInbox en la capa 1 para garantizar la disponibilidad de los datos y el funcionamiento del protocolo Rollup. En general, los datos L2 enviados a la Capa 1 no se pueden revertir y se pueden finalizar.

Del proceso anterior, podemos resumir: Layer2 tiene su propia red de nodos, pero el número de estos nodos es escaso y, por lo general, no existe un protocolo de consenso utilizado por la cadena pública, por lo que la seguridad es muy pobre y debe adjuntarse a Ethereum para garantizar la confiabilidad de la liberación de datos y la efectividad de la transición de estado.

Protocolo Arbitrum Rollup:

Una serie de contratos que definen la estructura del bloque RBlock de la cadena Rollup, la continuación de la cadena, la liberación de RBlock y el proceso del modo de desafío. Tenga en cuenta que la cadena Rollup mencionada aquí no es un libro mayor de capa 2 tal como lo entendemos, sino una “estructura de datos de cadena” abstracta establecida por Arbitrum One para implementar un mecanismo a prueba de fraude.

Un RBlock puede contener los resultados de varios bloques L2, y los datos también son muy diferentes, y 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 confirmador de ese RBlock.

Validador:

El nodo validador de Arbitrum es en realidad un subconjunto especial de nodos completos de capa 2, actualmente con acceso a la lista de permitidos.

El validador crea un nuevo RBlock (Rollup Block, también conocido como aserción) basado en el lote de transacciones enviadas por el secuenciador al contrato SequencerInbox, y supervisa el estado de la cadena Rollup actual para impugnar los datos erróneos enviados por el secuenciador.

Los validadores activos requieren el staking previo de activos en la cadena de ETH, a veces denominados stakers. Aunque los nodos de capa 2 que no hacen staking también pueden monitorear la dinámica de ejecución de los Rollups, enviar alarmas anormales a los usuarios, etc., no pueden intervenir directamente en los datos de error enviados por el secuenciador en la cadena de ETH.

Desafío:

Los pasos fundamentales se pueden resumir en segmentación interactiva de varias rondas y pruebas de un solo paso. En la sesión de segmentación, ambas partes se enfrentan al reto de realizar varias rondas de subdivisión por turnos de los datos de la transacción problemática hasta que se desglose y verifique la instrucción del código de operación del paso problemático. Los desarrolladores de Arbitrum consideran que el paradigma de la “segmentación multironda - prueba de un solo paso” es la implementación más eficiente de las pruebas de fraude. Todo está bajo el control del contrato y ninguna de las partes puede hacer trampa.

Período del desafío:

Debido a la naturaleza optimista del OP Rollup, después de que cada RBlock se envía a la cadena, el contrato no lo verifica activamente, dejando una ventana de tiempo para que los validadores falsifiquen. Esta ventana de tiempo es el período de desafío, que es de 1 semana en la red principal de Arbitrum One. Una vez finalizado el período de desafío, se finalizará el RBlock y se podrá liberar el mensaje correspondiente de L2 a L1 en el bloque (como una operación de retirada realizada a través del puente oficial).

ArbOS, Geth, WAVM:

La máquina virtual utilizada por Arbitrum se llama AVM, que consta de dos partes: Geth y ArbOS. Geth es el software cliente más utilizado de 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 la EVM, etc. Pensamos en 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 el código de 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 ilustrar la relación y el flujo de trabajo entre los componentes anteriores en el siguiente diagrama:

Ciclo de vida de las transacciones L2

Así es como funciona una transacción L2:

1. El usuario envía una instrucción comercial al secuenciador.

2. El secuenciador primero verifica los datos, como la firma digital de la transacción que se va a procesar, elimina la transacción no válida y ordena y calcula.

3. El secuenciador envía el recibo de la transacción al usuario (generalmente muy rápido), pero esto es solo el “preprocesamiento” del secuenciador fuera de ETH cadena, que se encuentra en un estado de Soft Finality y no es confiable. Pero para los usuarios que confían en el secuenciador (la mayoría de los usuarios), es optimista que la transacción se haya completado y no se revierta.

4. El secuenciador encapsula los datos sin procesar de la transacción preprocesada en un lote después de una alta compresión.

5. De vez en cuando (afectado por factores como el volumen de datos, la congestión ETH, etc.), 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 una 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 los 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 en función del registro por lotes, reemplazando el secuenciador defectuoso / Rug pull.

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

El contrato de bandeja de entrada del secuenciador, también conocido como Fastbox, es un secuenciador que le envía transacciones preprocesadas y solo el secuenciador puede enviarle datos. La caja rápida correspondiente es la caja lenta Delayer Inbox, y sus funciones se describirán en el proceso posterior.

El validador siempre escuchará el contrato de SequencerInbox, y cada vez que el secuenciador libere un lote en el contrato, lanzará un evento en cadena, y después de que el validador escuche este evento, descargará los datos del lote y, después de la ejecución local, liberará RBlock en el contrato de protocolo Rollup en la cadena ETH.

El contrato puente de Arbitrum tiene un parámetro llamado acumulador, que registrará el número de lotes L2 recién enviados, así como el número de transacciones recién recibidas e información en la bandeja de entrada lenta.

El contrato SequencerInbox tiene dos funciones principales:

agregue Sequencer L2Batch From Origin(), al que el secuenciador llama cada vez para enviar datos de Batch al contrato de Sequencer Inox.

force Inclusion(), que puede ser llamado por cualquier persona y se utiliza para implementar transacciones resistentes a la censura. El funcionamiento de esta función se explicará con más detalle más adelante cuando hablemos del contrato de la bandeja de entrada retrasada.

Ambas funciones llaman a bridge.enqueueSequencerMessage() para actualizar el acumulador del parámetro accumulator en el contrato de puente.

Precios de la gasolina

Obviamente, las transacciones L2 no pueden ser gratuitas debido a los ataques DoS, los costos de funcionamiento del secuenciador L2 y la sobrecarga de enviar datos en L1. Cuando un usuario inicia una transacción dentro de una red de capa 2, la tarifa de gas se estructura de la siguiente manera:

El costo de publicación de datos generado por la ocupación de los recursos de la capa 1 proviene principalmente de los lotes enviados por el secuenciador (cada lote tiene muchas transacciones de usuario) y, en última instancia, el costo se comparte a partes iguales entre los iniciadores de transacciones. El algoritmo para la fijación de precios de las tarifas generadas por la publicación de datos es dinámico, y el secuenciador fijará el precio en función de las ganancias y pérdidas recientes, el tamaño del lote y el precio actual del gas de Ethereum.

El coste en el que incurren los usuarios debido a la ocupación de los recursos de la Capa 2 se establece en un número máximo de gases por segundo que puede garantizar el funcionamiento estable del sistema (actualmente 7 millones para Arbitrum One). Los precios orientativos del gas tanto para L1 como para L2 son rastreados y ajustados por ArbOS, y la fórmula no se repetirá aquí por el momento.

Aunque el proceso específico de cálculo del precio del gas es más complicado, los usuarios no necesitan percibir estos detalles, y es obvio que la tarifa de transacción de rollup es mucho más barata que ETH red principal.

Prueba de fraude optimista

Para recapitular, L2 es en realidad solo una proyección de la entrada por lotes de las transacciones enviadas por el secuenciador en Fastbox, es decir:

Entradas de transacción -> STF -> Salidas de estado。 Se determina la entrada, el STF es constante y también se determina la salida, y el sistema de prueba de fraude y el protocolo Arbitrum Rollup es un sistema que publica la raíz del estado de la salida en L1 en forma de RBlock (también conocido como aserción) y lo demuestra de manera optimista.

En L1 están los datos de entrada publicados por el secuenciador, y también está el estado de salida publicado por el validador. Echemos un vistazo más de cerca, ¿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 visibles públicamente, enviar el estado de salida parece redundante, pero esta idea ignora el hecho de que la liquidación de estado es realmente necesaria entre los sistemas L1-L2, es decir, el comportamiento propuesto de L2 en la dirección de L1, y debe haber una prueba de estado.

Al construir un rollup, una de las ideas centrales es poner 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, solo ayuda al secuenciador L2 a publicar 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 de acuerdo con el mensaje de interacción entre cadenas dado por L2, transferirlos a la cuenta L1 del usuario o completar otras cosas.

En este punto, el contrato de la Capa 1 preguntará: cuál es su estado en la Capa 2 y cómo puede demostrar que realmente posee los activos que dice cruzar. En este momento, el usuario debe dar la prueba de Merkle correspondiente, etc.

Por lo tanto, si construimos un rollup sin función de retiro, es teóricamente posible no sincronizar el estado con L1, y no hay necesidad de un sistema de prueba de estado como la prueba de fraude (aunque puede causar otros problemas). Pero en la práctica, esto claramente no es factible.

En la llamada prueba optimista, el contrato no comprueba si la salida presentada a L1 está en el estado correcto, y es optimista de que todo es correcto. El sistema de prueba optimista asume que hay al menos un validador honesto en un momento dado, y si hay un estado erróneo, es desafiado por la prueba de fraude.

La ventaja de este diseño es que no es necesario validar activamente cada RBlock publicado en L1 para evitar el desperdicio de gas. De hecho, no es práctico para OPR verificar cada aserción, porque cada rblock contiene uno o más bloques L2, y no es diferente de ejecutar transacciones L2 directamente en L1 para volver a ejecutar cada transacción en L1, lo que pierde el significado del escalado de capa 2.

ZKR no tiene este problema, porque ZK Proof tiene simplicidad y solo necesita verificar una prueba pequeña, y no necesita ejecutar muchas transacciones detrás de la prueba. Por lo tanto, ZKR no es optimista, y cada vez el estado de liberación es verificado matemáticamente por el contrato de Verfier.

Aunque las pruebas de fraude no pueden ser tan concisas como las pruebas de conocimiento cero, Arbitrum utiliza un proceso de interacción paso a paso de “prueba de un solo paso dividida en varias rondas” y, en última instancia, solo se debe probar un código de operación de una sola máquina virtual, que tiene un costo relativamente pequeño.

Protocolo Rollup

Echemos un vistazo a cómo funciona el protocolo Rollup, el punto de entrada para iniciar desafíos y lanzar pruebas.

El contrato principal del protocolo Rollup es RollupProxy.sol, que utiliza una estructura de proxy dual poco común para garantizar la coherencia de la estructura de datos, un proxy corresponde a dos implementaciones de RollupUserLogic.sol y RollupAdminLogic.sol, que no se pueden analizar bien en herramientas como Scan.

Además, existe el contrato ChallengeManager.sol para gestionar el reto, y la serie de contratos OneStepProver para determinar las pruebas de fraude.

En RollupProxy, se registran una serie de RBlocks (también conocidos como aserciones) enviados por diferentes validadores, que son los cuadrados en el siguiente diagrama: verde - confirmado, azul - no confirmado, amarillo - falsificado.

RBlock contiene el estado final de uno o más bloques L2 después de la ejecución desde el último RBlock. Estos RBlocks forman morfológicamente una cadena de acumulación formal (tenga en cuenta que el libro mayor L2 en sí es diferente). En un escenario optimista, esta cadena de acumulación no debería bifurcarse, porque tener una bifurcación significa que hay validadores que han enviado bloques de acumulación en conflicto.

Para hacer o estar de acuerdo con una aserción, el validador primero debe apostar una cierta cantidad de ETH por la aserción y convertirse en un staker. De esta manera, en caso de una prueba de impugnación/fraude, se reducirá drásticamente la garantía del perdedor, que es la base económica para garantizar el comportamiento honesto de los validadores.

El bloque azul 111 en la esquina inferior derecha de la imagen eventualmente se falsificará porque su bloque principal 104 es Bloque incorrecto (amarillo).

Además, el validador A propone el Rollup Block 106, mientras que B no está de acuerdo y lo impugna.

Después de que B inicie un desafío, el contrato de ChallengeManager es responsable de validar el desglose de los pasos del desafío:

1. La segmentación es un proceso en el que dos partes se turnan para interactuar, una de las cuales segmenta los datos históricos contenidos en un bloque consolidado y la otra señala qué parte del fragmento de datos es problemática. Similar a un proceso de dicotomía (N/K, en realidad) que reduce gradualmente el rango.

2. Después de eso, puede continuar localizando qué transacción y el resultado es problemático, y luego subdividirlo en una instrucción de máquina que se disputa en esa transacción.

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

4. Cuando el impugnador y la parte impugnada localizan la instrucción de la máquina que se va a impugnar, el impugnador 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 la instrucción de la máquina.

Prueba de un solo paso

Las pruebas de un solo paso están en el corazón de las pruebas de fraude en todo Arbitrum. Echemos un vistazo a lo que demuestra una prueba de pasos.

Esto requiere una comprensión de WAVM, Wasm Arbitrum Virtual Machine, que es una máquina virtual compilada a partir de módulos ArbOS y módulos centrales Geth (cliente Ethereum). Dado que L2 es muy diferente de L1 en muchos aspectos, el núcleo Geth original tuvo que ser ligeramente modificado y trabajar con ArbOS.

Por lo tanto, las transiciones de estado en L2 son en realidad una característica común de ArbOS+Geth Core.

El cliente de nodo de Arbitrum (secuenciador, validador, nodo completo, etc.) compila el programa procesado por el núcleo ArbOS+Geth anterior en código de máquina nativo (para x86/ARM/PC/Mac/etc.) que puede ser procesado directamente por el host del nodo.

Si cambia el idioma de destino compilado a Wasm, obtiene el WAVM que el validador utiliza para generar la prueba de fraude, y el contrato que verifica la prueba de un solo paso también emula la funcionalidad de la máquina virtual WAVM.

La razón principal es que el contrato que verifica la prueba de fraude en un solo paso utiliza EthereumSmart Contract para simular una máquina virtual VM que puede manejar un determinado conjunto de conjuntos de instrucciones, y WASM es fácil de implementar en el contrato.

Sin embargo, WASM es un poco más lento que el código máquina nativo, por lo que WAVM solo será utilizado por el Nodo/Contrato de Arbitrum cuando se generen y verifiquen pruebas de fraude.

Después de las rondas anteriores de segmentación de interacción, la prueba de un solo paso finalmente resultó ser la instrucción de un solo paso en el conjunto de instrucciones WAVM.

Como 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, a continuación, llama al probador correspondiente, como Mem, Math, etc., y pasa la instrucción paso a paso al contrato del probador.

El resultado final del afterHash volverá al ChallengeManager, y si el hash es inconsistente con el hash registrado en el Rollup Block, el desafío será exitoso. Si es coherente, significa que el resultado de la ejecución de la instrucción registrada en el bloque consolidado es correcto y el desafío falla.

En el próximo artículo, analizaremos los módulos de contrato que manejan las funciones de interacción/puente entre cadenas entre Arbitrum e incluso la Capa 2 y la Capa 1, y aclararemos aún más cómo una verdadera Capa 2 debe ser resistente a la censura.