En este artículo, exploraremos paso a paso las diferentes fases por las que atraviesa una transacción en Arbitrum, desde que un cliente crea una transacción firmada hasta que se confirma la misma en la capa 1. También analizaremos los “checks de finalidad” que garantizan al cliente que el resultado de su transacción está garantizado y no será alterado posteriormente durante las etapas posteriores.
Es importante tener en cuenta que este artículo se centra en el protocolo Arbitrum Rollup y no en el protocolo Arbitrum AnyTrust. Si deseas conocer más de ambos protocolos, dirígete al siguiente artículo: Arbitrum Chains: Una visión conceptual
Fase 1: Recepción de la transacción por parte del Sequencer
El ciclo de vida de una transacción en Arbitrum comienza con el Sequencer recibiendo una transacción de un cliente. ¿Y quién es el secuencer? Bueno, resumidamente es la entidad encargada de ordenar las transacciones.
El Sequencer puede recibir una transacción de dos formas diferentes: directamente, cuando un cliente se conecta a un nodo de Arbitrum y envía una transacción firmada (por ejemplo, al utilizar una dapp), o a través de una L1 (mediante el Delayed Inbox), es decir, cuando un cliente envía un mensaje al Sequencer firmado y publica una transacción en la cadena de Arbitrum (esta funcionalidad se utiliza comúnmente para depositar ETH o tokens a través de un bridge).
Fase 2: El Sequencer ordena la transacción
Una vez que el Sequencer recibe una transacción, procede a ordenarla en su Inbox, esto lo hace fuera de la cadena. Luego ejecuta la transacción localmente utilizando la máquina virtual Arbitrum Nitro, lo que implica la recolección y asignación de tarifas de L1 y L2, entre otras cosas. Por último, proporciona al cliente un estilo de “recibo” de transacción de forma instantánea. Este recibo no requiere confirmaciones adicionales y suele tardar solo unos pocos segundos en generarse.
Es importante destacar que en esta fase, la aceptación de la finalidad de la transacción por parte del cliente se basa plenamente en la confianza en el Sequencer. Es decir, si el Sequencer fuera malicioso o defectuoso, podría modificar el recibo de la transacción. A pesar de esto, un Sequencer malicioso solo podría reordenar o retrasar temporalmente las transacciones, pero no puede falsificar la transacción ni proponer una actualización de estado inválida. Dado el nivel de confianza en el Sequencer, es que a veces nos referimos al “recibo instantáneo” como una “confirmación suave”.
Fase 3: El Sequencer publica la transacción en un lote
En esta fase, el Sequencer finalmente publica un lote de transacciones de la L2 que incluye la transacción del cliente en la capa subyacente de la L1 como calldata. Bajo condiciones normales, el Sequencer publica lotes cada pocos minutos y es ahí donde la incluye.
Si el Sequencer no incluye nuestra transacción en un lote, el cliente aún puede incluirla en la L2 publicándola en el Delayed Inbox y posteriormente forzando su inclusión después de un período de retraso (actualmente de aproximadamente 24 horas en Arbitrum One). Sin embargo, es importante destacar que el Sequencer está obligado a incluir los mensajes del Delayed Inbox en el orden en que aparecen en la cadena. Esto significa que no puede retrasar selectivamente ciertos mensajes mientras incluye otros. Retrasar el mensaje en la parte frontal de la cola implica retrasar todos los mensajes que le siguen.
Fase 4: El validador afirma el RBlock que incluye la transacción
Posteriormente, un validador activo ejecuta la máquina virtual sobre las entradas en el Inbox y realiza una afirmación en la cadena sobre el estado más reciente de misma, conocida como un bloque de rollup o “RBlock”. Normalmente, estas afirmaciones se realizan cada 30 o 60 minutos.
En el caso ideal, el validador realizará una afirmación válida y, durante el período de disputa de una semana en Arbitrum One, ningún otro validador desafiará dicha afirmación. Sin embargo, si dos validadores afirman RBlocks diferentes, solo uno de ellos puede ser válido y en ese caso, se iniciaría un proceso de disputa.
Fase 5: Confirmación del RBlock en la L1
Una vez que se hayan resuelto todas las disputas y/o haya pasado suficiente tiempo, el RBlock puede confirmar en la L1 cualquier cuenta de Ethereum en L1. Y al confirmarse, se actualiza también, la raíz del Outbox en la L1.
Es importante destacar que, si la transacción del cliente no incluía mensajes de L2 a L1, la fase 5 no afectará su transacción. Sin embargo, si la transacción incluía una transacción de L2 a L1, solo después de la confirmación se podrá ejecutar el mensaje en el Outbox de la L1.
De todas maneras, Incluso antes de la fase 5, el cliente tiene la finalidad en L1 del resultado de su mensaje de L2 a L1, solo que no puede ejecutarlo todavía. Es decir, tiene la garantía de que eventualmente podrá finalizar su retiro, pero no puede reclamar sus fondos en la L1 hasta que se confirme el RBlock correspondiente.
Conclusión
El ciclo de vida de una transacción en Arbitrum es un proceso complejo que implica varias fases y verificaciones. Desde la recepción de la transacción por parte del Sequencer hasta la confirmación del RBlock en la L1, cada etapa es crucial para garantizar la seguridad y finalidad de las transacciones en la red.
