Para conmemorar el próximo lanzamiento de Arbitrum Nitro el 31 de Agosto, hemos preparado para L2 en Español un resumen+revisión de los aspectos más importantes del reciente paper de Nitro.

En puntos simples Arbitrum es:

• Un conjunto de soluciones de escalabilidad de Ethereum. por OffChain Labs.

• Actualmente desarrolla un Optimistic Rollup y una Optimistic Chain, esta última conocida también como “AnyTrust Chain”.

• Son EVM compatibles.

• Arbitrum One, el Optimistic Rollup vigente en mainnet, es la L2 con mayor valor total bloqueado (TVL) de todo el ecosistema de soluciones de escalabilidad.

Mientras que los Optimistic Rollups son un tipo de L2 cuya seguridad conceptualmente está garantizada desde Ethereum como instancia de consenso y resolución de disputas, la Optimistic Chain desarrollada por el equipo ofrece una solución aún más económica para transaccionar basando su seguridad en una minoría honesta.

Hablar estrictamente de Arbitrum para el 27 de Agosto es referirse a las siguientes cadenas activas:

• One (Optimistic Rollup)

• Nova (Optimistic Chain según L2beat)

Estas cadenas estan conectadas a Ethereum y son versiones independientes una de la otra. La primera solo requiere la presencia de 1 participante honesto para ser segura (vía pruebas de fraude), mientras que la segunda requiere de una minoría participante (2 de 20 por ejemplo).

Aunque la versión de One trajo una reducción entre 10-20x en costes de transacción, la próxima a lanzarse este 31 de agosto, Nitro, pudiera alcanzar hasta los 50x respecto a Ethereum L1. ¿Como funcionará Nitro, Rollup y la versión tipo AnyTrust Chain? Los desarrolladores han publicado el whitepaper de Nitro, el cual revisaremos a continuación.

Arbitrum Nitro: un Optimistic Rollup de segunda generación.

“Presentamos Arbitrum Nitro, un protocolo blockchain de segunda capa. Nitro proporciona un mayor rendimiento, finalidad más rápida y una resolución de disputa más eficiente que los Rollups previos. Arbitrum logra estas propiedades a través de varios principios de diseño: separar la secuenciación de transacciones de su ejecución determinista; combinar el software de emulación de Ethereum existente con extensiones para habilitar funcionalidades cross-chain; compilar por separado la ejecución de la comprobación, de modo que la ejecución sea rápida y su comprobación sea estructurada e independiente de la misma; y asentar los resultados de las transacciones en la L1subyacente utilizando un protocolo estilo Optimistic Rollup basado en pruebas de fraude interactivas.”

Arbitrum Nitro se define como una L2 de segunda generación. Con Nitro, Arbitrum ofrecerá:

• Alto rendimiento de procesamiento de transacciones.

• Finalidad más rápida (confirmaciones seguras).

• Un eficiente sistema de resolución de disputas respecto a previos Optimistic Rollups.

Todo ello lo consigue a través de los siguientes principios del diseño de funcionamiento:

• Separación de la publicación del orden de transacciones (secuenciación) respecto a su ejecución formal (la transición de estado).

  *La transición de estado es el momento donde el Optimistic Rollup reporta los resultados de todas las transacciones publicadas*

• Emular el software de Ethereum (vía geth)

• Un sistema independiente de comprobación de transacciones vía pruebas de fraude, en L1, bajo la modalidad interactiva.

Nitro está pensado para alinear a los participantes en garantizar la seguridad de la red y funcionamiento continuo, siempre y cuando Ethereum también sea segura.

Como se sabe, los Optimistic Rollups utilizan Ethereum para reportar el funcionamiento y el avance de la cadena con toda la información necesaria. Con Nitro, el secuenciador primero publica los datos de las transacciones procesadas en un orden definido. Ethereum acá no puede garantizar que las transacciones son válidas o que la información provista de las mismas es correcta, sino que se confía en primera instancia que el secuenciador es honesto y descartará transacciones inválidas.

2.1 Sobre el secuenciador 👷‍♂️

• El secuenciador solo tiene la tarea y poder de proveer el orden en el procesamiento de transacciones sobre la cadena L2 y publicarlas en L1, o sea recibir las interacciones de los usuarios.

• Idealmente, el secuenciador optará una política de “secuencia justa” donde las transacciones las ordena en el mismo orden en que son recibidas (política anti-MEV).

• Cuando un usuario envía una transacción en L2, recibe la confirmación de recibo del secuenciador, lo que significa una promesa de que efectivamente será incluida en L1 en el futuro.

• Las transacciones son publicadas vía la función calldata en el contrato de Inbox en Ethereum. A partir de acá, si las transacciones son correctas y honestas, serán inalterables, y sólo una reorganización de la L1 puede comprometer esta finalidad.

• Por ahora, el secuenciador es centralizado, pero en un futuro se espera que existan varios disponibles que trabajen en forma de comité.

Una bandeja de entrada para L1, “Delayed Inbox” 📥

El protocolo L2 tiene la posibilidad de que los usuarios puedan enviar transacciones desde L1, sin tener que interactuar con el secuenciador directamente.

Esto tiene el propósito principal de bypasear al secuenciador, en caso de que éste comience a censurar usuarios.

El funcionamiento sería:

1. Los usuarios envían su transacción de lo que quieren hacer en L2, desde L1 al contrato Delayed Inbox.

2. El secuenciador lee dicha información en L1 y espera un tiempo razonable (10 minutos cuenta el paper) para ejecutar las transacciones recibidas allí.

3. Si aún así el secuenciador se niega a hacerlo en las próximas 24 horas, cualquiera puede forzar su inclusión en el Rollup y garantizar su ejecución, efectivamente venciendo la censura.

2.2 Ejecución determinística 📲

La función de transición de estado es lo que hace que el estado del Optimistic Rollup se actualice de acuerdo las transacciones procesadas y todos puedan observar y aceptar todos los resultados de los balance, cuentas y contratos de la L2. Es como la screenshot luego de un conjunto de últimas modificaciones.

Es determinística porque hay garantías que las transacciones publicadas y ejecutadas darán siempre los mismos resultados, de forma tal que cualquier parte independiente puede acceder y recuperar el estado del Rollup sin confiar en nadie más que en Ethereum.

Como ventaja, no hay necesidad de que los nodos L2 se comuniquen entre sí ni mantener un consenso. Todo lo necesario para garantizar que la L2 está haciendo cosas válidas es mirando lo que publica en Ethereum.

Como toda blockchain, al final del día es un software que es corrido por los participantes, conocidos como nodos. En Nitro, dicho software es etiquetado como “sandwich”, ya que los panes están basados fidedignamente en el cliente de go-ethereum (geth). Esto es:

• La base es un cliente de Geth para correr un nodo de Ethereum L1, necesario para reconocer todo el estado e info que el Optimistic Rollup deposita en mainnet.

• El intermedio, los ingredientes exóticos, corre el software llamado “ArbOS” que es la base de la comunicación entre la lectura de L1 y L2, como interpretar los batches, calcular el gas y operaciones entre L2 y L1.

• La cubierta, también basado en Geth, representa la capa de ejecución propiamente, EVM compatible donde la cual los usuarios interactúan para hacer transacciones y utilizar contratos inteligentes del Rollup.

3.2 La interacción entre L1 y L2 (también llamado cross-chain) 🔛

La gracia de las L2 es el pase de mensajes, activos o cualquier tipo de interacción de L1 a L2 y viceversa, sin confiar en terceros centralizados.

Esta interacción ocurre asincrónicamente, es decir, siempre hay un retraso según diferentes parámetros para que sea seguro.

Relevantemente, así como existe una bandeja de entrada (Inbox) existe también una de salida (outbox). En Nitro se introduce el modelo tickes asincrónicos para que cualquier comunicación de L2 a L1 pueda ser “reclamado” una vez que ha pasado el periodo de disputa (7 días o más). Esto último implica que el usuario o contrato necesita interactuar con el contrato de salida para leer o retirar cualquier cosa que se le ha enviado desde L2.

3.2.5 El puente 🌉

En esta sección se describe el puente para el pase de tokens, el cuál es referido como Canónico. Como cualquier otro, para los depósitos el puente se encarga de recibir los tokens en un contrato en L1, que luego el secuenciador lee y mintea en L2 al cabo de un pequeño periodo de tiempo. En sentido contrario, al retirar, los tokens se queman en L2 y luego son redimibles en L1.

Los tokens son incluidos y deployados sin permiso a la L2, minteado bajo el estándar ERC20 provisto por OpenZeppelin con el adicional de sumar las funciones de minteo y quemado.

Es posible depositar tokens de L1 a L2 bajo un contrato personalizado en caso de excepciones necesarias.

Tal y como lo cuenta el paper, Nitro implementa comisiones para cubrir los costes de operación, alinear los incentivos de operación y racionar los recursos cuando la demanda es alta.

Nitro distingue el cálculo de comisiones en dos campos: los correspondientes al uso de recursos en L2 y L1.

• 🛬Costo de L2: las comisiones referidas al cálculo computacional (para hacer transacciones o ejecutar contratos inteligentes) es medido en NitroGas. Esta variable es dinámica tal cual como el basefee en Ethereum, y es dependiente de el uso de la L2, ajustada por el parámetro speed limit, que se relaciona con el máxima rendimiento posible de la L2 en un periodo de tiempo extendido, determinado en la práctica por la compañía. Si el ~número de transacciones y computación en general supera el speed limit, el fee de L2 subirá acorde.

  En el formato de transacciones estándar de Ethereum también incluye tips para los productores de bloques. Si bien Nitro este mismo formato, ignora esta propiedad y el secuenciador no recolecta tips.

• 🚂Costo de L1: Nitro ni cualquier L2 puede predecir con exactitud los costes de transacción para publicar en Ethereum L1 para dar una previsión de cuánto cobrar a sus usuarios para mantener todas las operaciones involucradas que implica L2 en L1. En este caso Nitro estima de la mejor manera posible el costo de transacción de momento asumiendo las compresiones de transacción que Nitro aplica a cada una y a futuro. Para ello Nitro utiliza un algoritmo que considera el costo de transacciones pasadas y trackea un fondo de reembolso de los costos usados en L1. De esta manera el secuenciador no puede “inventarse” un fee a pagar a los usuarios y se preserva que sea sustentable las ganancias para el secuenciador.

El software de Nitro es flexible en el modo en que se ejecutan transacciones y la forma de probar que la ejecución fué correcta. Esto es un reto en los Optimistic Rollups presentes ya que hay que realizar una serie de adaptaciones para que, con la información provista del Rollup en Ethereum, sea posible ejecutar los datos necesarios para verificar si los resultados y ejecución son correctos, sin perder factibilidad ni eficiencia.

Nitro compila a WebAssembly y luego a WAVM. En el paper se afirma que estos códigos son un buen vehículo para pruebas de fraude. Nitro incluya instrucción “ReadPreImage” que es una manera eficiente de extraer la información mínima necesaria como si fuese un “capture” de bloques pasados que sirva como referencia para re ejecutar las funciones y comprobar fraude.

La producción de bloques y avance de la cadena L2 se puede observar de la siguiente manera: el secuenciador procesa transacciones (lo que veríamos en el explorador suceder en vivo), y luego crea un conjunto de L2blocks se empaqueta en forma de RBlocks y se envía a Ethereum como Rollup.

Los RBlocks almacenan los L2Blocks y su secuencia, un apuntador del RBlock predecesor y una atestación del secuenciador afirmando que dicho RBlock es correcto.

Cualquier RBlock es correcto sí:

• Toda la información publicada en dicho RBlock es válida y

• Cualquier RBlock anterior a este también lo es.

Cualquier responsable de producir publicar un RBlock también se compromete a que los Rblocks pasados también cree que lo son.

La validez de los RBlocks es confirmada luego de finalizado el periodo de disputa. Esto significa que cualquier secuenciador que publique RBlocks luego de un RBlock sospechoso, está defendiendo que es correcto.

Los verificadores están incentivados a retar a los secuenciadores por la afirmación falsa, vía pruebas de fraude, y ganarán dinero si lo descubren, causando la remoción de el RBlock involucrado en el fraude y los siguientes.

El secuenciador perdería el stake comprometido, mientras que el verificador ganaría la mitad, y el resto sería redirigido a la financiación de bienes públicos.

El protocolo de disputas es el que le da lugar a las pruebas de fraude. Esta disputa puede entenderse como un juego entre quien reta (verificador) y el acusado (secuenciador), todo realizado desde la L1.

El proceso de disputa no ocurre en un solo paso, sino que el verificador y secuenciador deben interactuar durante dicho periodo para llegar a una resolución usando a Ethereum como última fuente de la verdad.

El objetivo del protocolo reducir lo máximo razonable la tamaño de código a verificar sobre un determinado punto de las transacciones o estado que se considera como falso/incorrecto.

Según el paper, se describen dos tipos:

• 6.1 - Básico: el verificador reta al secuenciador en una serie de bloques y estado N. Como no necesariamente todo el bloque o bloques contiene datos malignos, el secuenciador debe dividir por la mitad el reclamo recibido y el verificador debe escoger cual está de acuerdo o a cual disputar. El objetivo de esto que el verificador y secuenciador dividan por la mitad en rondas sucesivas hasta que llegue al trozo puntual del estado en disputa. Luego mediante WAVM, se procede a hacer lo mismo pero con la transacción o segmento del estado en disputa hasta reejecutar la función que generó un estado incorrecto.

• 6.2 - Con mejoras: en vez de dividir por la mitad de forma consecutiva, es posible dividir en más segmentos para reducir el numero de pasos lógicos. Esto reduce además los costos por transacción de cada proceso de disputa.

Al final del día el protocolo no le interesa reconocer cual de las dos partes es honesta, sino asumir que existe. Esto quiere decir que tanto el secuenciador como verificador pueden decir la verdad o mentir, y sea como sea, es inevitable llegar a una resolución en la que alguno de los dos perderá.

AnyTrust es una variante de Nitro que más bajos costes aceptando algunas asumiendo algunos ligeras suposiciones de confianza (esto es similar al enfoque o nivel de un Validium).

Hasta ahora, Nitro como Optimistic Rollup requiere que todos los nodos de L2 tengan acceso a la información de las transacciones desde Ethereum L1, lo que les provee seguridad de que efectivamente podrán obtenerla. No obstante, esto representa un alto coste para el funcionamiento del Rollup.

AnyTrust utiliza un comité de disponibilidad de datos para almacenar los datos de transacciones en vez de ser grabadas en Ethereum, lo cual van compartiendo cuando alguien lo requiera. El comité es un simple grupo de N participantes/nodos que reciben la información de las transacciones y firman que la han almacenado, que es correcta y coincide.

Para que exista consenso sobre toda esta información, AnyTrust requiere que existan por lo menos 2 participantes honesto en el comité de N. Si un participante honesto se desconecta, aún existe 1 que sí sea honesto y desee proveer acceso a los datos.

A su vez, el comité deber reportar a Ethereum de que los miembros poseen los datos y están disponibles, permitiendo a la cadena AnyTrust proceder con normalidad.

La ventaja es que si el comité no colabora en guardar los datos, como por ejemplo, no firmar los bloques que el secuenciador a producido, luego de un periodo de tiempo la AnyTrustChain puede convertirse en un Optimistic Rollup y el secuenciador empezar a postear data directamente en Ethereum.

Nitro es una mejora significativa respecto a la primera generación de Optimistic Rollups pensados en 2019-2020, un desarrollo heredado de lo que también fueron los intentos fallidos de Plasma. El sistema de Nitro con la compresión de transacciones y pruebas de fraude interactivas le provee al protocolo eficiencia en su funcionamiento en todas sus aristas. Al ser EVM compatible, los usuarios podrán gozar de una experiencia tal y como en Ethereum, la velocidad y bajos coste que se merecen.

Los retos por delante para Nitro son: la descentralización de los secuenciadores bajo el enfoque descrito en forma de “comité” que falta por esclarecer; la puesta a producción de pruebas de fraude abierta al público, y la factibilidad de que una AnyTrustChain se pueda replicar para quien necesite desplegar la suya propia para casos de uso específicos.

🎉 ¡Gracias por leer hasta el final! En L2 en Español estamos avocados en educar, aprender y estudiar juntos, sigue nuestras redes sociales y unite a la conversación en nuestra comunidad de Telegram!

https://twitter.com/Layer2es

https://t.me/l2espaniol

Con 💗 desde DeFi LATAM 🤝 DeFi para principiantes

Para conmemorar el próximo lanzamiento de Arbitrum Nitro el 31 de Agosto, hemos preparado para L2 en Español un resumen+revisión de los aspectos más importantes del reciente paper de Nitro.

En puntos simples Arbitrum es:

• Un conjunto de soluciones de escalabilidad de Ethereum. por OffChain Labs.

• Actualmente desarrolla un Optimistic Rollup y una Optimistic Chain, esta última conocida también como “AnyTrust Chain”.

• Son EVM compatibles.

• Arbitrum One, el Optimistic Rollup vigente en mainnet, es la L2 con mayor valor total bloqueado (TVL) de todo el ecosistema de soluciones de escalabilidad.

Mientras que los Optimistic Rollups son un tipo de L2 cuya seguridad conceptualmente está garantizada desde Ethereum como instancia de consenso y resolución de disputas, la Optimistic Chain desarrollada por el equipo ofrece una solución aún más económica para transaccionar basando su seguridad en una minoría honesta.

Hablar estrictamente de Arbitrum para el 27 de Agosto es referirse a las siguientes cadenas activas:

• One (Optimistic Rollup)

• Nova (Optimistic Chain según L2beat)

Estas cadenas estan conectadas a Ethereum y son versiones independientes una de la otra. La primera solo requiere la presencia de 1 participante honesto para ser segura (vía pruebas de fraude), mientras que la segunda requiere de una minoría participante (2 de 20 por ejemplo).

Aunque la versión de One trajo una reducción entre 10-20x en costes de transacción, la próxima a lanzarse este 31 de agosto, Nitro, pudiera alcanzar hasta los 50x respecto a Ethereum L1. ¿Como funcionará Nitro, Rollup y la versión tipo AnyTrust Chain? Los desarrolladores han publicado el whitepaper de Nitro, el cual revisaremos a continuación.

Arbitrum Nitro: un Optimistic Rollup de segunda generación.

“Presentamos Arbitrum Nitro, un protocolo blockchain de segunda capa. Nitro proporciona un mayor rendimiento, finalidad más rápida y una resolución de disputa más eficiente que los Rollups previos. Arbitrum logra estas propiedades a través de varios principios de diseño: separar la secuenciación de transacciones de su ejecución determinista; combinar el software de emulación de Ethereum existente con extensiones para habilitar funcionalidades cross-chain; compilar por separado la ejecución de la comprobación, de modo que la ejecución sea rápida y su comprobación sea estructurada e independiente de la misma; y asentar los resultados de las transacciones en la L1subyacente utilizando un protocolo estilo Optimistic Rollup basado en pruebas de fraude interactivas.”

Arbitrum Nitro se define como una L2 de segunda generación. Con Nitro, Arbitrum ofrecerá:

• Alto rendimiento de procesamiento de transacciones.

• Finalidad más rápida (confirmaciones seguras).

• Un eficiente sistema de resolución de disputas respecto a previos Optimistic Rollups.

Todo ello lo consigue a través de los siguientes principios del diseño de funcionamiento:

• Separación de la publicación del orden de transacciones (secuenciación) respecto a su ejecución formal (la transición de estado).

  *La transición de estado es el momento donde el Optimistic Rollup reporta los resultados de todas las transacciones publicadas*

• Emular el software de Ethereum (vía geth)

• Un sistema independiente de comprobación de transacciones vía pruebas de fraude, en L1, bajo la modalidad interactiva.

Nitro está pensado para alinear a los participantes en garantizar la seguridad de la red y funcionamiento continuo, siempre y cuando Ethereum también sea segura.

Como se sabe, los Optimistic Rollups utilizan Ethereum para reportar el funcionamiento y el avance de la cadena con toda la información necesaria. Con Nitro, el secuenciador primero publica los datos de las transacciones procesadas en un orden definido. Ethereum acá no puede garantizar que las transacciones son válidas o que la información provista de las mismas es correcta, sino que se confía en primera instancia que el secuenciador es honesto y descartará transacciones inválidas.

2.1 Sobre el secuenciador 👷‍♂️

• El secuenciador solo tiene la tarea y poder de proveer el orden en el procesamiento de transacciones sobre la cadena L2 y publicarlas en L1, o sea recibir las interacciones de los usuarios.

• Idealmente, el secuenciador optará una política de “secuencia justa” donde las transacciones las ordena en el mismo orden en que son recibidas (política anti-MEV).

• Cuando un usuario envía una transacción en L2, recibe la confirmación de recibo del secuenciador, lo que significa una promesa de que efectivamente será incluida en L1 en el futuro.

• Las transacciones son publicadas vía la función calldata en el contrato de Inbox en Ethereum. A partir de acá, si las transacciones son correctas y honestas, serán inalterables, y sólo una reorganización de la L1 puede comprometer esta finalidad.

• Por ahora, el secuenciador es centralizado, pero en un futuro se espera que existan varios disponibles que trabajen en forma de comité.

Una bandeja de entrada para L1, “Delayed Inbox” 📥

El protocolo L2 tiene la posibilidad de que los usuarios puedan enviar transacciones desde L1, sin tener que interactuar con el secuenciador directamente.

Esto tiene el propósito principal de bypasear al secuenciador, en caso de que éste comience a censurar usuarios.

El funcionamiento sería:

1. Los usuarios envían su transacción de lo que quieren hacer en L2, desde L1 al contrato Delayed Inbox.

2. El secuenciador lee dicha información en L1 y espera un tiempo razonable (10 minutos cuenta el paper) para ejecutar las transacciones recibidas allí.

3. Si aún así el secuenciador se niega a hacerlo en las próximas 24 horas, cualquiera puede forzar su inclusión en el Rollup y garantizar su ejecución, efectivamente venciendo la censura.

2.2 Ejecución determinística 📲

La función de transición de estado es lo que hace que el estado del Optimistic Rollup se actualice de acuerdo las transacciones procesadas y todos puedan observar y aceptar todos los resultados de los balance, cuentas y contratos de la L2. Es como la screenshot luego de un conjunto de últimas modificaciones.

Es determinística porque hay garantías que las transacciones publicadas y ejecutadas darán siempre los mismos resultados, de forma tal que cualquier parte independiente puede acceder y recuperar el estado del Rollup sin confiar en nadie más que en Ethereum.

Como ventaja, no hay necesidad de que los nodos L2 se comuniquen entre sí ni mantener un consenso. Todo lo necesario para garantizar que la L2 está haciendo cosas válidas es mirando lo que publica en Ethereum.

Como toda blockchain, al final del día es un software que es corrido por los participantes, conocidos como nodos. En Nitro, dicho software es etiquetado como “sandwich”, ya que los panes están basados fidedignamente en el cliente de go-ethereum (geth). Esto es:

• La base es un cliente de Geth para correr un nodo de Ethereum L1, necesario para reconocer todo el estado e info que el Optimistic Rollup deposita en mainnet.

• El intermedio, los ingredientes exóticos, corre el software llamado “ArbOS” que es la base de la comunicación entre la lectura de L1 y L2, como interpretar los batches, calcular el gas y operaciones entre L2 y L1.

• La cubierta, también basado en Geth, representa la capa de ejecución propiamente, EVM compatible donde la cual los usuarios interactúan para hacer transacciones y utilizar contratos inteligentes del Rollup.

3.2 La interacción entre L1 y L2 (también llamado cross-chain) 🔛

La gracia de las L2 es el pase de mensajes, activos o cualquier tipo de interacción de L1 a L2 y viceversa, sin confiar en terceros centralizados.

Esta interacción ocurre asincrónicamente, es decir, siempre hay un retraso según diferentes parámetros para que sea seguro.

Relevantemente, así como existe una bandeja de entrada (Inbox) existe también una de salida (outbox). En Nitro se introduce el modelo tickes asincrónicos para que cualquier comunicación de L2 a L1 pueda ser “reclamado” una vez que ha pasado el periodo de disputa (7 días o más). Esto último implica que el usuario o contrato necesita interactuar con el contrato de salida para leer o retirar cualquier cosa que se le ha enviado desde L2.

3.2.5 El puente 🌉

En esta sección se describe el puente para el pase de tokens, el cuál es referido como Canónico. Como cualquier otro, para los depósitos el puente se encarga de recibir los tokens en un contrato en L1, que luego el secuenciador lee y mintea en L2 al cabo de un pequeño periodo de tiempo. En sentido contrario, al retirar, los tokens se queman en L2 y luego son redimibles en L1.

Los tokens son incluidos y deployados sin permiso a la L2, minteado bajo el estándar ERC20 provisto por OpenZeppelin con el adicional de sumar las funciones de minteo y quemado.

Es posible depositar tokens de L1 a L2 bajo un contrato personalizado en caso de excepciones necesarias.

Tal y como lo cuenta el paper, Nitro implementa comisiones para cubrir los costes de operación, alinear los incentivos de operación y racionar los recursos cuando la demanda es alta.

Nitro distingue el cálculo de comisiones en dos campos: los correspondientes al uso de recursos en L2 y L1.

• 🛬Costo de L2: las comisiones referidas al cálculo computacional (para hacer transacciones o ejecutar contratos inteligentes) es medido en NitroGas. Esta variable es dinámica tal cual como el basefee en Ethereum, y es dependiente de el uso de la L2, ajustada por el parámetro speed limit, que se relaciona con el máxima rendimiento posible de la L2 en un periodo de tiempo extendido, determinado en la práctica por la compañía. Si el ~número de transacciones y computación en general supera el speed limit, el fee de L2 subirá acorde.

  En el formato de transacciones estándar de Ethereum también incluye tips para los productores de bloques. Si bien Nitro este mismo formato, ignora esta propiedad y el secuenciador no recolecta tips.

• 🚂Costo de L1: Nitro ni cualquier L2 puede predecir con exactitud los costes de transacción para publicar en Ethereum L1 para dar una previsión de cuánto cobrar a sus usuarios para mantener todas las operaciones involucradas que implica L2 en L1. En este caso Nitro estima de la mejor manera posible el costo de transacción de momento asumiendo las compresiones de transacción que Nitro aplica a cada una y a futuro. Para ello Nitro utiliza un algoritmo que considera el costo de transacciones pasadas y trackea un fondo de reembolso de los costos usados en L1. De esta manera el secuenciador no puede “inventarse” un fee a pagar a los usuarios y se preserva que sea sustentable las ganancias para el secuenciador.

El software de Nitro es flexible en el modo en que se ejecutan transacciones y la forma de probar que la ejecución fué correcta. Esto es un reto en los Optimistic Rollups presentes ya que hay que realizar una serie de adaptaciones para que, con la información provista del Rollup en Ethereum, sea posible ejecutar los datos necesarios para verificar si los resultados y ejecución son correctos, sin perder factibilidad ni eficiencia.

Nitro compila a WebAssembly y luego a WAVM. En el paper se afirma que estos códigos son un buen vehículo para pruebas de fraude. Nitro incluya instrucción “ReadPreImage” que es una manera eficiente de extraer la información mínima necesaria como si fuese un “capture” de bloques pasados que sirva como referencia para re ejecutar las funciones y comprobar fraude.

La producción de bloques y avance de la cadena L2 se puede observar de la siguiente manera: el secuenciador procesa transacciones (lo que veríamos en el explorador suceder en vivo), y luego crea un conjunto de L2blocks se empaqueta en forma de RBlocks y se envía a Ethereum como Rollup.

Los RBlocks almacenan los L2Blocks y su secuencia, un apuntador del RBlock predecesor y una atestación del secuenciador afirmando que dicho RBlock es correcto.

Cualquier RBlock es correcto sí:

• Toda la información publicada en dicho RBlock es válida y

• Cualquier RBlock anterior a este también lo es.

Cualquier responsable de producir publicar un RBlock también se compromete a que los Rblocks pasados también cree que lo son.

La validez de los RBlocks es confirmada luego de finalizado el periodo de disputa. Esto significa que cualquier secuenciador que publique RBlocks luego de un RBlock sospechoso, está defendiendo que es correcto.

Los verificadores están incentivados a retar a los secuenciadores por la afirmación falsa, vía pruebas de fraude, y ganarán dinero si lo descubren, causando la remoción de el RBlock involucrado en el fraude y los siguientes.

El secuenciador perdería el stake comprometido, mientras que el verificador ganaría la mitad, y el resto sería redirigido a la financiación de bienes públicos.

El protocolo de disputas es el que le da lugar a las pruebas de fraude. Esta disputa puede entenderse como un juego entre quien reta (verificador) y el acusado (secuenciador), todo realizado desde la L1.

El proceso de disputa no ocurre en un solo paso, sino que el verificador y secuenciador deben interactuar durante dicho periodo para llegar a una resolución usando a Ethereum como última fuente de la verdad.

El objetivo del protocolo reducir lo máximo razonable la tamaño de código a verificar sobre un determinado punto de las transacciones o estado que se considera como falso/incorrecto.

Según el paper, se describen dos tipos:

• 6.1 - Básico: el verificador reta al secuenciador en una serie de bloques y estado N. Como no necesariamente todo el bloque o bloques contiene datos malignos, el secuenciador debe dividir por la mitad el reclamo recibido y el verificador debe escoger cual está de acuerdo o a cual disputar. El objetivo de esto que el verificador y secuenciador dividan por la mitad en rondas sucesivas hasta que llegue al trozo puntual del estado en disputa. Luego mediante WAVM, se procede a hacer lo mismo pero con la transacción o segmento del estado en disputa hasta reejecutar la función que generó un estado incorrecto.

• 6.2 - Con mejoras: en vez de dividir por la mitad de forma consecutiva, es posible dividir en más segmentos para reducir el numero de pasos lógicos. Esto reduce además los costos por transacción de cada proceso de disputa.

Al final del día el protocolo no le interesa reconocer cual de las dos partes es honesta, sino asumir que existe. Esto quiere decir que tanto el secuenciador como verificador pueden decir la verdad o mentir, y sea como sea, es inevitable llegar a una resolución en la que alguno de los dos perderá.

AnyTrust es una variante de Nitro que más bajos costes aceptando algunas asumiendo algunos ligeras suposiciones de confianza (esto es similar al enfoque o nivel de un Validium).

Hasta ahora, Nitro como Optimistic Rollup requiere que todos los nodos de L2 tengan acceso a la información de las transacciones desde Ethereum L1, lo que les provee seguridad de que efectivamente podrán obtenerla. No obstante, esto representa un alto coste para el funcionamiento del Rollup.

AnyTrust utiliza un comité de disponibilidad de datos para almacenar los datos de transacciones en vez de ser grabadas en Ethereum, lo cual van compartiendo cuando alguien lo requiera. El comité es un simple grupo de N participantes/nodos que reciben la información de las transacciones y firman que la han almacenado, que es correcta y coincide.

Para que exista consenso sobre toda esta información, AnyTrust requiere que existan por lo menos 2 participantes honesto en el comité de N. Si un participante honesto se desconecta, aún existe 1 que sí sea honesto y desee proveer acceso a los datos.

A su vez, el comité deber reportar a Ethereum de que los miembros poseen los datos y están disponibles, permitiendo a la cadena AnyTrust proceder con normalidad.

La ventaja es que si el comité no colabora en guardar los datos, como por ejemplo, no firmar los bloques que el secuenciador a producido, luego de un periodo de tiempo la AnyTrustChain puede convertirse en un Optimistic Rollup y el secuenciador empezar a postear data directamente en Ethereum.

Nitro es una mejora significativa respecto a la primera generación de Optimistic Rollups pensados en 2019-2020, un desarrollo heredado de lo que también fueron los intentos fallidos de Plasma. El sistema de Nitro con la compresión de transacciones y pruebas de fraude interactivas le provee al protocolo eficiencia en su funcionamiento en todas sus aristas. Al ser EVM compatible, los usuarios podrán gozar de una experiencia tal y como en Ethereum, la velocidad y bajos coste que se merecen.

Los retos por delante para Nitro son: la descentralización de los secuenciadores bajo el enfoque descrito en forma de “comité” que falta por esclarecer; la puesta a producción de pruebas de fraude abierta al público, y la factibilidad de que una AnyTrustChain se pueda replicar para quien necesite desplegar la suya propia para casos de uso específicos.

🎉 ¡Gracias por leer hasta el final! En L2 en Español estamos avocados en educar, aprender y estudiar juntos, sigue nuestras redes sociales y unite a la conversación en nuestra comunidad de Telegram!

https://twitter.com/Layer2es

https://t.me/l2espaniol

Con 💗 desde DeFi LATAM 🤝 DeFi para principiantes