Esta es una traducción de un artículo en inglés llamado “Bridging and Finality: Optimism and Arbitrum” escrito por Jenny Pan para Jump.

En el siguiente artículo vamos a repasar cada aspecto del rollup y explicar qué salvaguardas tiene el usuario respecto de la finalidad de sus transacciones en cada punto.

Actualmente, tanto Arbitrum como Optimism, operan un solo secuenciador centralizado que está a cargo de ordenar todas las transacciones que recibe y se asume que este esta operando de manera honesta y ordenando por orden de llegada. Se supone que existen planes para descentralizar el secuenciador usando un whitelist o nodos de L2 aprobados por la comunidad, pero el roadmap sigue sin estar muy claro.

Primero, el secuenciador recibe una transacción de dos maneras. Normalmente, cuando uno opera dentro de una L2, los usuarios conectan sus wallets a un nodo de L2 y envían de manera directa una transacción firmada offchain al secuenciador. En otras instancias, un usuario puede enviar una transacción al secuenciador al publicar una transacción de L1 en el contract del rollup en Ethereum; esto suele ser el caso para las operaciones realizadas en la L1 que requieran un mensaje en la L2, e.j. depositar un asset con un bridge en el rollup (depositando en la L1 y después minteando en la L2).

Después de recibir una transacción, el secuenciador ordena las transacciones offchain y emite un recibo instantáneo de la transacción al usuario como “soft finality” (finalidad blanda) dentro de 1-2 segundos. Esta transacción en tiempo real no requiere ninguna confirmación adicional onchain y se anuncia en vivo, así que cualquiera lo puede verificar y correr independientemente un State Transition Function (STF), o Función de Transición de Estado, determinista para deducir el resultado de esa transacción de manera inmediata.

Si la transacción fue enviada a la L1, el secuenciador de Arbitrum va a emitir un recibo en la L2 10 minutos antes de que esta llegue al secuenciador para asegurarse que ninguna reorganización de bloques en el corto plazo de la L1 ocurra y revierta la inclusión de las transacciones en el rollup. En Optimism Bedrock, se espera que las transacciones a la L1 se confirmen dentro de 3 minutos.

Además, en los intervalos de los bloques de la L2 en Optimism bedrock van a ser de 2 segundos (antes eran esporádicos). En Arbitrum Nitro, los intervalos de los bloques de la L2 son variables, generados 3-4 veces por segundo.

La confianza del usuario en la finalidad depende completamente de la confianza que se le tiene al secuenciador; un secuenciador que censure o esté offline podría diferir entre el orden indicado en este recibo instantáneo y el orden publicado en última instancia en un batch (lote). Lo peor que un secuenciador podría hacer es reordenar o demorar una transacción, ya que es imposible que este falsifique una transaccióndel usuario o proponaga una actualización inválida al estado.

En Arbitrum, para prevenir la censura por el secuenciador, un usuario puede forzar la inclusión de una transacción al sigueinte bloque de la L2, para bypass al secuenciador, en el caso de que este se haya atrasado por más de 24 horas - las transacciones después son incluidos en orden FIFO (first in, first out - primera en entrar, primera en salir).

En Optimism, las transacciones enviadas a la L1, se incluyen automáticamente en un bloque de la L2 lo antes posible; el primer bloque de la L2 en un rollup epoch debe incluir todas las transacciones depositadas en el primer bloque de la L1 (cada bloque de la L1 define un rollup epoch, y pueden haber varios bloques de la L2 por cada epoch).

Si la transacción se envió directamente a la L2 y la L1 enfrentó una reorganización antes de que esa transacción se agrupara y finalizara en la L1, entonces las L2 podrían, en teoría, seguir creando bloques y agrupar todas esas transacciones que no lograron pasar la reorganización. Sin embargo, no hay documentación sobre esto para ninguna de las L2.

En el caso de que la transacción se envió a la L1, Arbitrum no tiene nada implementado para lidiar con una reorganización de L1. Esto no es tan grave, ya que desde el merge, hay un retraso de finalidad en la L1 de 12.8 minutos, por lo que este no está muy lejos de los 10 minutos. En Optimism, debido a que la L2 sigue a la L1 más estrechamente dentro de una ventana de 3 minutos, tendrá que manejar las reorganizaciones de L1 mediante la reorganización de L2 si es necesario, pero no se especifica cómo lo hace.

En estos escenarios, los rollups no ofrecen garantías. Las transacciones pueden nunca aparecer en la cadena y el procedimiento para su inclusión después de la reorganización no está bien detallado.

Luego, el secuenciador comprime y publica las transacciones de la L2 en batches como calldata de Ethereum cada 1-3 minutos en el caso de Arbitrum y cada 30 segundos - 1 minuto en el caso de Optimism. Calldata es la parte no modificable de un smart contract que básicamente funciona como memoria y queda registrado onchain pero no como parte del estado del blockchain, lo que permite que sea más rentable para el almacenamiento de datos onchain.

En Solidity, la palabra calldata se utiliza para pasar argumentos a una función de smart contract específica. En este escenario, el secuenciador utiliza calldata para llamar a la función del contrato de rollup en la L1 y pasar datos de transacción comprimidos como input a la función. La transacción de la L2 ahora tiene la misma finalidad que el bloque L1 que la incluyó en un batch, así logrando un “Hard Finality”.

El estado de L2, que consta de cuentas, balances, contratos, etc., se estructura como un Merkle tree, llamado "árbol de estado" (state tree en inglés). La raíz de este árbol de estado es la raíz de estado de la L2 (state root) y define el estado más reciente del rollup, que se guarda en el contrato de rollup de la L1. Un secuenciador necesita enviar las raíces de estado antiguas (estado antes de las transacciones agrupadas) y nuevas (estado después de que se ejecutan las transacciones agrupadas) al publicar batches, que son necesarios para demostrar que los cambios en el estado son correctos.

Una vez que el secuenciador envía el batch, el contrato verifica que el state root previo coincida con el state root existente. Si las dos coinciden, el contrato descarta el antiguo state root y almacena un nuevo state root propuesto por el secuenciador.

El usuario ahora puede usar el estándar de finalidad que desee para las transacciones regulares en la L1 hacia la transacción en la L2 que ahora está incluida en un bloque de la L1. La ejecución en rollups optimistas es completamente determinista; un estado del chain actual y nuevo input data (datos de entrada) son suficientes para calcular el nuevo estado de la cadena a través del STF. En el momento en que este input data está disponible cuando el secuenciador publica un batch, se puede computar el nuevo estado de la L2 y el orden de las transacciones está determinado por la L1; el secuenciador ya no tiene más input. Los datos del batch publicados en la L1 están disponibles y son suficientes para que cualquier nodo reconstruya y valide el estado de la L2.

Cualquier usuario que no esté cómodo con las trust assumptions del secuenciador en la "soft finality" simplemente puede esperar a que el Secuenciador publique su transacción en un batch, ya que ofrece las mismas garantías que la finalidad L1.

Los batches pasan por una reestructuración solo si Ethereum también lo hace.Esto se vuelve menos probable a medida que la presentación de los batches es seguida por más confirmaciones. Ya que estos batches se envían como calldata de Ethereum, no hay forma de censurar o modificarlos después de que la transacción se incluye en un bloque que tiene suficientes atestaciones; así es como las L2 heredan las garantías de seguridad de Ethereum. Por lo tanto, las transacciones de Arbitrum y Optimism que experimentan una "hard finality" están protegidas contra grandes reorganizaciones de bloques siempre que el mecanismo de consenso de Ethereum lo esté.

En Arbitrum, los validadores (actualmente con whitelist) verifican los batches de transacciones de la L1, los procesan uno a la vez utilizando un STF determinista y pueden impugnar el state root de la L2 publicada en el batch. El contrato de rollup en la L1 acepta nuevas raíces de estado inmediatamente después de que se publican, por lo que los state commitments (compromisos de estado) se pueden publicar en Ethereum sin la necesidad de una prueba de que sean correctos (por lo tanto optimistas, ya que se espera que sean correctos, de ahí el nombre de los rollups).

Si un state commitment propuesto no se impugna durante el período de desafío, se considera definitivo, después de lo cual los smart contracts en Ethereum pueden aceptar de manera segura pruebas de retiro sobre el estado de la L2 basado en ese commitment. Si se impugna con éxito un state commitment, el batch que no sea válido y los que sean publicados después de este serán revertidos, restaurando el rollup a su antiguo state root. El protocolo de rollup luego necesitará volver a ejecutar las transacciones y actualizar el estado del rollup.

Cualquier otro validador puede impugnar el state root dentro del período de desafío, el cual es de una semana, que incluye un juego de pruebas de fraude interactivo de varias rondas que finalmente será resuelto por la L1. Siempre que haya al menos un validador honesto, se garantiza que el state root de la L2 correcto se publique en la L1. Las pruebas de fraude utilizadas para impugnar los state commitments actualmente no están implementadas en Optimism.

Después de que el período de desafío ha terminado, finalmente se permiten los retiros. Los retiros son transacciones entre dominios (cross-domain) que se inician en la L2 y se finalizan mediante una transacción ejecutada en la L1, como para transferir tokens de una cuenta en una L2 a una cuenta en la L1. Un usuario simplemente necesita proporcionar una prueba de Merkle (usando calldata) al contrato de rollup que demuestra que su transacción fue incluida en el state root del rollup.

Si algún validador intenta desviarse del estado de la L2 válido, un validador honesto podrá impugnar esto. Solo necesitamos un validador honesto para que esto ocurra, por lo que sabemos que el estado válido finalmente prevalecerá. Un solo nodo honesto es todo lo que se necesita para avanzar la chain correctamente, publicando afirmaciones válidas o impugnando afirmaciones inválidas.

Un state commitment (el resultado de ejecutar las transacciones) puede ser invalidado a través de una prueba de fraude exitosa y eliminado para finalmente ser reemplazado por otro commitment propuesto. Pero un desafío exitoso no reorganiza la L2 ni afecta la finalidad de la transacción; todavía está incluido en la L1. Solo significa que el cálculo del resultado de esta transacción en el estado de la chain es incorrecto y se volverá a calcular. El orden de las transacciones y el estado de la L2 no se ve afectado por un desafío de prueba de fraude.

Hemos desarrollado un marco que los bridges pueden seguir y los tipos de finalidad que ofrecerían garantías suficientes en diferentes casos de uso. Operaremos bajo el supuesto de que los bridges están ejecutando nodos completos en Arbitrum/Optimism y validando todas las transacciones del rollup. De esta manera, el puente no depende de los state commitments o las pruebas de fraude (por lo que no importa mucho que las pruebas de fraude aun no hayan sido implementadas en Optimism). Incluso cuando se implementen las pruebas de fraude, los puentes no necesitarán esperar el período de desafío de una semana, lo que permitirá a los usuarios acceder a sus activos antes. Creemos que usar los datos por batches de "hard finality" es suficiente, y los retiros de tokens se pueden implementar en bridges que se basan en el hard finality (dos épocas) en lugar del período de desafío (una semana).

En ciertos escenarios, los puentes aceleran el proceso aún más al permitir que los protocolos operen en commitment de "soft finality", hasta la especificación del cliente. Todas las transacciones son vistas por cada uno de los validadores para el bridge al conectarse directamente a sus nodos operados de forma independiente. En lugar de validar solo los mensajes que alcanzan la finalidad en la chain original, que en este caso son dos épocas, los bridges brindan flexibilidad, permitiendo a los integradores especificar un mensaje más rápido si así lo desean, desde la entrega inmediata basada en recibos de transacciones instantáneos (publicando la transacción tan pronto como se recibe), hasta el límite original de dos épocas e incluso períodos más largos si es necesario.

En ciertos casos de uso, simplemente observar el registro del secuenciador puede considerarse "suficientemente seguro"; por ejemplo, si los oráculos quisieran emitir desde Ethereum, solo importa la validez de los mensajes, no tanto que los mensajes alcancen el consenso. Siempre que el puente ejecute nodos completos, se garantiza la validez de los mensajes y la mensajería más rápida podría ser una opción viable.

Para mensajes regulares, el bridge no tiene que confiar en el secuenciador para la disponibilidad, ya que los usuarios también pueden enviar transacciones directamente a la L1 (aunque a un costo de gas más alto) y no necesitamos confiar en su seguridad, ya que las transacciones se finalizan en la L1.

Para mensajes personalizados y más rápidos, sí tenemos que confiar en el secuenciador, ya que no hay ningún mecanismo que impida que el secuenciador se desvíe de su orden de transacción esperado - por orden de llegada y del orden que realmente publica en la L1. Este riesgo lo asume completamente el remitente que especifica que su mensaje sea retransmitido de inmediato en lugar de esperar la finalidad de la L1. Por lo tanto, un bridge de tokens debe seguir contando con el límite de 2-epochs, mientras que los mensajes order-insensitive (insensibles al orden) pueden ser verificados antes de la finalidad si así se desea.

En esta publicación, exploramos las suposiciones de confianza en cada fase del rollup optimista y el riesgo de reversión asociado con ellas. Luego vinculamos estos diferentes niveles de finalidad a las decisiones de diseño que consideran los protocolos de puente genéricos para que los usuarios y las aplicaciones entre chains tengan confianza en comprender las garantías que especifican para sus transacciones.

Esta es una traducción de un artículo en inglés llamado “Bridging and Finality: Optimism and Arbitrum” escrito por Jenny Pan para Jump.

En el siguiente artículo vamos a repasar cada aspecto del rollup y explicar qué salvaguardas tiene el usuario respecto de la finalidad de sus transacciones en cada punto.

Actualmente, tanto Arbitrum como Optimism, operan un solo secuenciador centralizado que está a cargo de ordenar todas las transacciones que recibe y se asume que este esta operando de manera honesta y ordenando por orden de llegada. Se supone que existen planes para descentralizar el secuenciador usando un whitelist o nodos de L2 aprobados por la comunidad, pero el roadmap sigue sin estar muy claro.

Primero, el secuenciador recibe una transacción de dos maneras. Normalmente, cuando uno opera dentro de una L2, los usuarios conectan sus wallets a un nodo de L2 y envían de manera directa una transacción firmada offchain al secuenciador. En otras instancias, un usuario puede enviar una transacción al secuenciador al publicar una transacción de L1 en el contract del rollup en Ethereum; esto suele ser el caso para las operaciones realizadas en la L1 que requieran un mensaje en la L2, e.j. depositar un asset con un bridge en el rollup (depositando en la L1 y después minteando en la L2).

Después de recibir una transacción, el secuenciador ordena las transacciones offchain y emite un recibo instantáneo de la transacción al usuario como “soft finality” (finalidad blanda) dentro de 1-2 segundos. Esta transacción en tiempo real no requiere ninguna confirmación adicional onchain y se anuncia en vivo, así que cualquiera lo puede verificar y correr independientemente un State Transition Function (STF), o Función de Transición de Estado, determinista para deducir el resultado de esa transacción de manera inmediata.

Si la transacción fue enviada a la L1, el secuenciador de Arbitrum va a emitir un recibo en la L2 10 minutos antes de que esta llegue al secuenciador para asegurarse que ninguna reorganización de bloques en el corto plazo de la L1 ocurra y revierta la inclusión de las transacciones en el rollup. En Optimism Bedrock, se espera que las transacciones a la L1 se confirmen dentro de 3 minutos.

Además, en los intervalos de los bloques de la L2 en Optimism bedrock van a ser de 2 segundos (antes eran esporádicos). En Arbitrum Nitro, los intervalos de los bloques de la L2 son variables, generados 3-4 veces por segundo.

La confianza del usuario en la finalidad depende completamente de la confianza que se le tiene al secuenciador; un secuenciador que censure o esté offline podría diferir entre el orden indicado en este recibo instantáneo y el orden publicado en última instancia en un batch (lote). Lo peor que un secuenciador podría hacer es reordenar o demorar una transacción, ya que es imposible que este falsifique una transaccióndel usuario o proponaga una actualización inválida al estado.

En Arbitrum, para prevenir la censura por el secuenciador, un usuario puede forzar la inclusión de una transacción al sigueinte bloque de la L2, para bypass al secuenciador, en el caso de que este se haya atrasado por más de 24 horas - las transacciones después son incluidos en orden FIFO (first in, first out - primera en entrar, primera en salir).

En Optimism, las transacciones enviadas a la L1, se incluyen automáticamente en un bloque de la L2 lo antes posible; el primer bloque de la L2 en un rollup epoch debe incluir todas las transacciones depositadas en el primer bloque de la L1 (cada bloque de la L1 define un rollup epoch, y pueden haber varios bloques de la L2 por cada epoch).

Si la transacción se envió directamente a la L2 y la L1 enfrentó una reorganización antes de que esa transacción se agrupara y finalizara en la L1, entonces las L2 podrían, en teoría, seguir creando bloques y agrupar todas esas transacciones que no lograron pasar la reorganización. Sin embargo, no hay documentación sobre esto para ninguna de las L2.

En el caso de que la transacción se envió a la L1, Arbitrum no tiene nada implementado para lidiar con una reorganización de L1. Esto no es tan grave, ya que desde el merge, hay un retraso de finalidad en la L1 de 12.8 minutos, por lo que este no está muy lejos de los 10 minutos. En Optimism, debido a que la L2 sigue a la L1 más estrechamente dentro de una ventana de 3 minutos, tendrá que manejar las reorganizaciones de L1 mediante la reorganización de L2 si es necesario, pero no se especifica cómo lo hace.

En estos escenarios, los rollups no ofrecen garantías. Las transacciones pueden nunca aparecer en la cadena y el procedimiento para su inclusión después de la reorganización no está bien detallado.

Luego, el secuenciador comprime y publica las transacciones de la L2 en batches como calldata de Ethereum cada 1-3 minutos en el caso de Arbitrum y cada 30 segundos - 1 minuto en el caso de Optimism. Calldata es la parte no modificable de un smart contract que básicamente funciona como memoria y queda registrado onchain pero no como parte del estado del blockchain, lo que permite que sea más rentable para el almacenamiento de datos onchain.

En Solidity, la palabra calldata se utiliza para pasar argumentos a una función de smart contract específica. En este escenario, el secuenciador utiliza calldata para llamar a la función del contrato de rollup en la L1 y pasar datos de transacción comprimidos como input a la función. La transacción de la L2 ahora tiene la misma finalidad que el bloque L1 que la incluyó en un batch, así logrando un “Hard Finality”.

El estado de L2, que consta de cuentas, balances, contratos, etc., se estructura como un Merkle tree, llamado "árbol de estado" (state tree en inglés). La raíz de este árbol de estado es la raíz de estado de la L2 (state root) y define el estado más reciente del rollup, que se guarda en el contrato de rollup de la L1. Un secuenciador necesita enviar las raíces de estado antiguas (estado antes de las transacciones agrupadas) y nuevas (estado después de que se ejecutan las transacciones agrupadas) al publicar batches, que son necesarios para demostrar que los cambios en el estado son correctos.

Una vez que el secuenciador envía el batch, el contrato verifica que el state root previo coincida con el state root existente. Si las dos coinciden, el contrato descarta el antiguo state root y almacena un nuevo state root propuesto por el secuenciador.

El usuario ahora puede usar el estándar de finalidad que desee para las transacciones regulares en la L1 hacia la transacción en la L2 que ahora está incluida en un bloque de la L1. La ejecución en rollups optimistas es completamente determinista; un estado del chain actual y nuevo input data (datos de entrada) son suficientes para calcular el nuevo estado de la cadena a través del STF. En el momento en que este input data está disponible cuando el secuenciador publica un batch, se puede computar el nuevo estado de la L2 y el orden de las transacciones está determinado por la L1; el secuenciador ya no tiene más input. Los datos del batch publicados en la L1 están disponibles y son suficientes para que cualquier nodo reconstruya y valide el estado de la L2.

Cualquier usuario que no esté cómodo con las trust assumptions del secuenciador en la "soft finality" simplemente puede esperar a que el Secuenciador publique su transacción en un batch, ya que ofrece las mismas garantías que la finalidad L1.

Los batches pasan por una reestructuración solo si Ethereum también lo hace.Esto se vuelve menos probable a medida que la presentación de los batches es seguida por más confirmaciones. Ya que estos batches se envían como calldata de Ethereum, no hay forma de censurar o modificarlos después de que la transacción se incluye en un bloque que tiene suficientes atestaciones; así es como las L2 heredan las garantías de seguridad de Ethereum. Por lo tanto, las transacciones de Arbitrum y Optimism que experimentan una "hard finality" están protegidas contra grandes reorganizaciones de bloques siempre que el mecanismo de consenso de Ethereum lo esté.

En Arbitrum, los validadores (actualmente con whitelist) verifican los batches de transacciones de la L1, los procesan uno a la vez utilizando un STF determinista y pueden impugnar el state root de la L2 publicada en el batch. El contrato de rollup en la L1 acepta nuevas raíces de estado inmediatamente después de que se publican, por lo que los state commitments (compromisos de estado) se pueden publicar en Ethereum sin la necesidad de una prueba de que sean correctos (por lo tanto optimistas, ya que se espera que sean correctos, de ahí el nombre de los rollups).

Si un state commitment propuesto no se impugna durante el período de desafío, se considera definitivo, después de lo cual los smart contracts en Ethereum pueden aceptar de manera segura pruebas de retiro sobre el estado de la L2 basado en ese commitment. Si se impugna con éxito un state commitment, el batch que no sea válido y los que sean publicados después de este serán revertidos, restaurando el rollup a su antiguo state root. El protocolo de rollup luego necesitará volver a ejecutar las transacciones y actualizar el estado del rollup.

Cualquier otro validador puede impugnar el state root dentro del período de desafío, el cual es de una semana, que incluye un juego de pruebas de fraude interactivo de varias rondas que finalmente será resuelto por la L1. Siempre que haya al menos un validador honesto, se garantiza que el state root de la L2 correcto se publique en la L1. Las pruebas de fraude utilizadas para impugnar los state commitments actualmente no están implementadas en Optimism.

Después de que el período de desafío ha terminado, finalmente se permiten los retiros. Los retiros son transacciones entre dominios (cross-domain) que se inician en la L2 y se finalizan mediante una transacción ejecutada en la L1, como para transferir tokens de una cuenta en una L2 a una cuenta en la L1. Un usuario simplemente necesita proporcionar una prueba de Merkle (usando calldata) al contrato de rollup que demuestra que su transacción fue incluida en el state root del rollup.

Si algún validador intenta desviarse del estado de la L2 válido, un validador honesto podrá impugnar esto. Solo necesitamos un validador honesto para que esto ocurra, por lo que sabemos que el estado válido finalmente prevalecerá. Un solo nodo honesto es todo lo que se necesita para avanzar la chain correctamente, publicando afirmaciones válidas o impugnando afirmaciones inválidas.

Un state commitment (el resultado de ejecutar las transacciones) puede ser invalidado a través de una prueba de fraude exitosa y eliminado para finalmente ser reemplazado por otro commitment propuesto. Pero un desafío exitoso no reorganiza la L2 ni afecta la finalidad de la transacción; todavía está incluido en la L1. Solo significa que el cálculo del resultado de esta transacción en el estado de la chain es incorrecto y se volverá a calcular. El orden de las transacciones y el estado de la L2 no se ve afectado por un desafío de prueba de fraude.

Hemos desarrollado un marco que los bridges pueden seguir y los tipos de finalidad que ofrecerían garantías suficientes en diferentes casos de uso. Operaremos bajo el supuesto de que los bridges están ejecutando nodos completos en Arbitrum/Optimism y validando todas las transacciones del rollup. De esta manera, el puente no depende de los state commitments o las pruebas de fraude (por lo que no importa mucho que las pruebas de fraude aun no hayan sido implementadas en Optimism). Incluso cuando se implementen las pruebas de fraude, los puentes no necesitarán esperar el período de desafío de una semana, lo que permitirá a los usuarios acceder a sus activos antes. Creemos que usar los datos por batches de "hard finality" es suficiente, y los retiros de tokens se pueden implementar en bridges que se basan en el hard finality (dos épocas) en lugar del período de desafío (una semana).

En ciertos escenarios, los puentes aceleran el proceso aún más al permitir que los protocolos operen en commitment de "soft finality", hasta la especificación del cliente. Todas las transacciones son vistas por cada uno de los validadores para el bridge al conectarse directamente a sus nodos operados de forma independiente. En lugar de validar solo los mensajes que alcanzan la finalidad en la chain original, que en este caso son dos épocas, los bridges brindan flexibilidad, permitiendo a los integradores especificar un mensaje más rápido si así lo desean, desde la entrega inmediata basada en recibos de transacciones instantáneos (publicando la transacción tan pronto como se recibe), hasta el límite original de dos épocas e incluso períodos más largos si es necesario.

En ciertos casos de uso, simplemente observar el registro del secuenciador puede considerarse "suficientemente seguro"; por ejemplo, si los oráculos quisieran emitir desde Ethereum, solo importa la validez de los mensajes, no tanto que los mensajes alcancen el consenso. Siempre que el puente ejecute nodos completos, se garantiza la validez de los mensajes y la mensajería más rápida podría ser una opción viable.

Para mensajes regulares, el bridge no tiene que confiar en el secuenciador para la disponibilidad, ya que los usuarios también pueden enviar transacciones directamente a la L1 (aunque a un costo de gas más alto) y no necesitamos confiar en su seguridad, ya que las transacciones se finalizan en la L1.

Para mensajes personalizados y más rápidos, sí tenemos que confiar en el secuenciador, ya que no hay ningún mecanismo que impida que el secuenciador se desvíe de su orden de transacción esperado - por orden de llegada y del orden que realmente publica en la L1. Este riesgo lo asume completamente el remitente que especifica que su mensaje sea retransmitido de inmediato en lugar de esperar la finalidad de la L1. Por lo tanto, un bridge de tokens debe seguir contando con el límite de 2-epochs, mientras que los mensajes order-insensitive (insensibles al orden) pueden ser verificados antes de la finalidad si así se desea.

En esta publicación, exploramos las suposiciones de confianza en cada fase del rollup optimista y el riesgo de reversión asociado con ellas. Luego vinculamos estos diferentes niveles de finalidad a las decisiones de diseño que consideran los protocolos de puente genéricos para que los usuarios y las aplicaciones entre chains tengan confianza en comprender las garantías que especifican para sus transacciones.