Hoy en día, los Optimistic Rollups que incorporan sistemas de validación de pruebas de fraude, como Arbitrum One y Nova, llevan a cabo la validación de su estado en la cadena de Ethereum. Este proceso involucra a un conjunto de entidades conocidas como "validadores", los cuales emiten afirmaciones sobre el estado de la capa 2 (L2) en un contrato inteligente, después de haber verificado su autenticidad. Durante un periodo de 7 días, otros validadores tienen la posibilidad de impugnar estas afirmaciones, dando inicio a un proceso de resolución de disputas. Una vez que una afirmación es confirmada, el estado subyacente se considera como válido desde la perspectiva de Ethereum. Este proceso de validación es esencial para garantizar la seguridad en la transferencia de activos entre las cadenas de Arbitrum y Ethereum L1, aunque conlleva un cierto retraso.

No obstante, en la actualidad, la validación en Arbitrum One y Nova, a través de pruebas de fraude, se encuentra limitada debido a la vulnerabilidad de sus protocolos de disputa frente a ataques de denegación de servicio (DoS). Un validador malintencionado podría gastar repetidamente fondos con el objetivo de evitar que las afirmaciones sean confirmadas, lo que resultaría en un retraso en los retiros de L2 a L1 durante el tiempo que él esté dispuesto a mantener dicha acción.

📝 Índice

1. ¿Qué son los ataques de denegación de servicio (DoS)?

2. Arbitrum BOLD

3. Arquitectura de BOLD

4. ¿Cómo funciona?

5. Conclusión

Por definición, los DoS Attacks son un tipo de ataque por el cual actores maliciosos buscan evitar que los usuarios de un sistema informático en línea puedan acceder al mismo saturándolo con peticiones ilegítimas de servicio.

Esta situación evita que los usuarios legítimos hagan uso del sistema y del servicio que el mismo presta. Este tipo de ataques pueden estar dirigidos a afectar la fuente que ofrece la información, la aplicación o el canal de transmisión del sistema. Algo que generalmente se logra al explotar vulnerabilidades o sobrecargar la capacidad de los servidores. El último caso es el más común de ellos, pues es sencillo, rápido y muy efectivo.

Antes estas premisas, nos llega la pregunta:

¿Existe alguna solución para evitar un escenario distópico en donde se puede afectar el sistema de disputas de Arbitrum?

En el contexto de las cadenas L2, es esencial abordar los desafíos relacionados con los retrasos al asegurar la confirmación del estado  de la misma en la red Ethereum. En este sentido, BOLD surge como una evolución del sistema de resolución de disputas de Arbitrum, presentando un enfoque notablemente robusto.

BOLD representa el primer protocolo práctico de desafío que ofrece una eficiente gestión de disputas entre múltiples participantes. Las ventajas que ofrece BOLD son significativas:

• Confirmaciones más Rápidas: BOLD garantiza límites superiores fijos en los tiempos de confirmación para la determinación del estado en el Optimistic Rollup.

• Equidad y Eficiencia: BOLD garantiza que incluso una sola entidad honesta pueda prevalecer frente a un número considerable de afirmaciones maliciosas.

En el marco de BOLD, las disputas se vinculan con la ejecución determinista de un estado en la capa 2, y no con un staker o entidad específica. Esto implica que cualquier entidad que esté de acuerdo con un estado tiene el poder de defenderlo, hasta que surja un único punto de desacuerdo. Debido a la naturaleza determinista del estado L2 honesto, las entidades honestas siempre prevalecerán al participar, ya que las entidades maliciosas no pueden falsificar pruebas de ejecución, ya que las mismas tienen garantizada su realización en Ethereum.

Al analizar la interconexión de los componentes de BOLD, es útil tener en mente el software utilizado por un validador real en Arbitrum: Arbitrum Nitro. Entre sus responsabilidades clave se encuentran:

• Ejecutar transacciones entrantes desde un contrato Inbox y generar post-estados conforme a la transición de estado en la capa 2.

• Transmitir lotes de transacciones a Ethereum L1 a través de un contrato denominado SequencerInbox.

• Validar transacciones y emitir afirmaciones, conocidas como aserciones, acerca del estado en la capa 2 a intervalos regulares en Ethereum, utilizando un contrato denominado RollupCore.sol.

• Refutar las aserciones incorrectas enviadas por validadores deshonestos a RollupCore.sol

Además, es importante destacar que la tecnología Arbitrum se está transformando en una arquitectura más modular, permitiendo la ejecución independiente de componentes específicos como binarios separados. BOLD implementa un componente de Nitro encargado de emitir aserciones y desafiar afirmaciones inválidas, dependiendo, por lo tanto, de otras partes del nodo Nitro para acceder a los datos de estado necesarios.

Adicionalmente, el repositorio de BOLD es un proyecto autónomo en GitHub, independiente de Nitro, y se conecta a las cadenas de Nitro como una dependencia para cumplir sus funciones.

El BOLD Challenge Manager de arriba interactúa con algunos elementos de un nodo Arbitrum, permitiéndole hacer movimientos de retos y enviar compromisos de historia a los contratos en Ethereum. En código de Arbitrum, se abstraen esos componentes del nodo L2 a través de una pequeña interfaz llamada L2 State Provider.

Recordemos que el núcleo primitivo del protocolo son los challenge edges, donde un edge representa un compromiso histórico de inicio y fin de una cadena Arbitrum. Los participantes en el protocolo pueden hacer movimientos en los retos, y los validadores pueden participar en muchos retos simultáneamente. Es decir, el software necesita rastrear edges dentro de un reto y su ciclo de vida para ganar contra entidades maliciosas.

La arquitectura detallada es la siguiente:

Funciona de la siguiente manera:

1. Un Assertion Poster frecuentemente toma mensajes validados del validador L2 y los publica on-chain.

2. Un Assertion Scanner comprueba los contratos inteligentes en Ethereum en busca de nuevas aserciones publicadas y las compara con la base de datos local del nodo Nitro (o “DB” por sus siglas en inglés). Esto se hace a través de una abstracción conocida como L2 State Provider. Esto está dentro de assertions/scanner.go

3. Si no estamos de acuerdo con una aserción, nuestro Challenge Manager envía un desafío on-chain creando un canal de nivel cero, y rastrea ese canal como una go routine.

4. Nuestro Chain Watcher, en segundo plano, escanea otros edges creados en la cadena y genera goroutines “Edge trackers” para los edges honestos que aún no se han rastreado.

Cada Edge es rastreado como una goroutine llamada Edge Tracker. Los Edge Tracker son goroutines autónomos que se activan a intervalos de tick especificados y utilizan una máquina de estados finitos para decidir qué movimiento de desafío realizar. Por ejemplo, después de crear un edge, intentará dividirla, y confirmarla mediante una prueba de un paso o crear un subdesafío, dependiendo de cómo se presenta el estado actual.

Este es el aspecto de la máquina de estados finitos de un rastreador de aristas, cuyo estado final es confirmado:

Una vez que se confirma un edge de nivel cero para un desafío sobre una afirmación, la afirmación puede validarse y la parte honesta saldrá victoriosa.

Arbitrum ha creado un nuevo enfoque para la validación que nos da un límite superior fijo de 7 días de retraso adicional en las confirmaciones sin sufrir ataques de retraso. BOLD puede hacer que la validación de las cadenas Arbitrum sea segura y sin permisos, lo que las hace subir muchos peldaños en la escalera de la descentralización. El enfoque permite a un único validador honesto ganar disputas en Ethereum contra cualquier número de adversarios.

Con su incorporación, BOLD busca añadir a Arbitrum, una mejor seguridad, liveness y latencia para establecer estados en su cadena y, al mismo tiempo, evitar que las partes deshonestas aumenten el costo de las partes honestas.

Con Arbitrum BOLD, Ethereum contará con una implementación de Optimistic Rollup de propósito general completamente funcional, el cual permitirá asegurarlo bajo suposiciones de confianza ideales (1 de n) y escalar el ecosistema genuinamente y sin compromisos.

🎉 ¡Gracias por leer hasta el final!🎉 Si está interesado en esta solución de escalabilidad te invitamos a revisar nuestra biblioteca de Layer 2 en español.

Si quieres conocer mas a fondo la tecnología detrás de Arbitrum te invitamos a leer estos artículos👇👇👇

Introducción al Optimistic Rollup de Arbitrum

https://mirror.xyz/layer2es.eth/L0YiPok0FymbnHZyA5GqbKL4OL0U4jBDwTuTGzD4PiE

Arbitrum One vs Arbitrum Nova

https://mirror.xyz/layer2es.eth/InEgFG-fRvNv4LTIUSGp0vF9PTyl58AdqswqaYJYu3M

Arbitrum Orbit

https://mirror.xyz/layer2es.eth/yqFRGQzBnGqV0z-fFeuwScBfwf3FVAaplYhThGs5E2E

Si quieren seguir aprendiendo y colaborando con nosotros, le invitamos a unirse a nuestra vibrante comunidad de Telegram L2 en Español y a seguirnos en nuestro Twitter L2 en Español. Allí encontrará una gran cantidad de información sobre Layer 2 y el ecosistema de Blockchain en general. ¡Te Esperamos!

Hoy en día, los Optimistic Rollups que incorporan sistemas de validación de pruebas de fraude, como Arbitrum One y Nova, llevan a cabo la validación de su estado en la cadena de Ethereum. Este proceso involucra a un conjunto de entidades conocidas como "validadores", los cuales emiten afirmaciones sobre el estado de la capa 2 (L2) en un contrato inteligente, después de haber verificado su autenticidad. Durante un periodo de 7 días, otros validadores tienen la posibilidad de impugnar estas afirmaciones, dando inicio a un proceso de resolución de disputas. Una vez que una afirmación es confirmada, el estado subyacente se considera como válido desde la perspectiva de Ethereum. Este proceso de validación es esencial para garantizar la seguridad en la transferencia de activos entre las cadenas de Arbitrum y Ethereum L1, aunque conlleva un cierto retraso.

No obstante, en la actualidad, la validación en Arbitrum One y Nova, a través de pruebas de fraude, se encuentra limitada debido a la vulnerabilidad de sus protocolos de disputa frente a ataques de denegación de servicio (DoS). Un validador malintencionado podría gastar repetidamente fondos con el objetivo de evitar que las afirmaciones sean confirmadas, lo que resultaría en un retraso en los retiros de L2 a L1 durante el tiempo que él esté dispuesto a mantener dicha acción.

📝 Índice

1. ¿Qué son los ataques de denegación de servicio (DoS)?

2. Arbitrum BOLD

3. Arquitectura de BOLD

4. ¿Cómo funciona?

5. Conclusión

Por definición, los DoS Attacks son un tipo de ataque por el cual actores maliciosos buscan evitar que los usuarios de un sistema informático en línea puedan acceder al mismo saturándolo con peticiones ilegítimas de servicio.

Esta situación evita que los usuarios legítimos hagan uso del sistema y del servicio que el mismo presta. Este tipo de ataques pueden estar dirigidos a afectar la fuente que ofrece la información, la aplicación o el canal de transmisión del sistema. Algo que generalmente se logra al explotar vulnerabilidades o sobrecargar la capacidad de los servidores. El último caso es el más común de ellos, pues es sencillo, rápido y muy efectivo.

Antes estas premisas, nos llega la pregunta:

¿Existe alguna solución para evitar un escenario distópico en donde se puede afectar el sistema de disputas de Arbitrum?

En el contexto de las cadenas L2, es esencial abordar los desafíos relacionados con los retrasos al asegurar la confirmación del estado  de la misma en la red Ethereum. En este sentido, BOLD surge como una evolución del sistema de resolución de disputas de Arbitrum, presentando un enfoque notablemente robusto.

BOLD representa el primer protocolo práctico de desafío que ofrece una eficiente gestión de disputas entre múltiples participantes. Las ventajas que ofrece BOLD son significativas:

• Confirmaciones más Rápidas: BOLD garantiza límites superiores fijos en los tiempos de confirmación para la determinación del estado en el Optimistic Rollup.

• Equidad y Eficiencia: BOLD garantiza que incluso una sola entidad honesta pueda prevalecer frente a un número considerable de afirmaciones maliciosas.

En el marco de BOLD, las disputas se vinculan con la ejecución determinista de un estado en la capa 2, y no con un staker o entidad específica. Esto implica que cualquier entidad que esté de acuerdo con un estado tiene el poder de defenderlo, hasta que surja un único punto de desacuerdo. Debido a la naturaleza determinista del estado L2 honesto, las entidades honestas siempre prevalecerán al participar, ya que las entidades maliciosas no pueden falsificar pruebas de ejecución, ya que las mismas tienen garantizada su realización en Ethereum.

Al analizar la interconexión de los componentes de BOLD, es útil tener en mente el software utilizado por un validador real en Arbitrum: Arbitrum Nitro. Entre sus responsabilidades clave se encuentran:

• Ejecutar transacciones entrantes desde un contrato Inbox y generar post-estados conforme a la transición de estado en la capa 2.

• Transmitir lotes de transacciones a Ethereum L1 a través de un contrato denominado SequencerInbox.

• Validar transacciones y emitir afirmaciones, conocidas como aserciones, acerca del estado en la capa 2 a intervalos regulares en Ethereum, utilizando un contrato denominado RollupCore.sol.

• Refutar las aserciones incorrectas enviadas por validadores deshonestos a RollupCore.sol

Además, es importante destacar que la tecnología Arbitrum se está transformando en una arquitectura más modular, permitiendo la ejecución independiente de componentes específicos como binarios separados. BOLD implementa un componente de Nitro encargado de emitir aserciones y desafiar afirmaciones inválidas, dependiendo, por lo tanto, de otras partes del nodo Nitro para acceder a los datos de estado necesarios.

Adicionalmente, el repositorio de BOLD es un proyecto autónomo en GitHub, independiente de Nitro, y se conecta a las cadenas de Nitro como una dependencia para cumplir sus funciones.

El BOLD Challenge Manager de arriba interactúa con algunos elementos de un nodo Arbitrum, permitiéndole hacer movimientos de retos y enviar compromisos de historia a los contratos en Ethereum. En código de Arbitrum, se abstraen esos componentes del nodo L2 a través de una pequeña interfaz llamada L2 State Provider.

Recordemos que el núcleo primitivo del protocolo son los challenge edges, donde un edge representa un compromiso histórico de inicio y fin de una cadena Arbitrum. Los participantes en el protocolo pueden hacer movimientos en los retos, y los validadores pueden participar en muchos retos simultáneamente. Es decir, el software necesita rastrear edges dentro de un reto y su ciclo de vida para ganar contra entidades maliciosas.

La arquitectura detallada es la siguiente:

Funciona de la siguiente manera:

1. Un Assertion Poster frecuentemente toma mensajes validados del validador L2 y los publica on-chain.

2. Un Assertion Scanner comprueba los contratos inteligentes en Ethereum en busca de nuevas aserciones publicadas y las compara con la base de datos local del nodo Nitro (o “DB” por sus siglas en inglés). Esto se hace a través de una abstracción conocida como L2 State Provider. Esto está dentro de assertions/scanner.go

3. Si no estamos de acuerdo con una aserción, nuestro Challenge Manager envía un desafío on-chain creando un canal de nivel cero, y rastrea ese canal como una go routine.

4. Nuestro Chain Watcher, en segundo plano, escanea otros edges creados en la cadena y genera goroutines “Edge trackers” para los edges honestos que aún no se han rastreado.

Cada Edge es rastreado como una goroutine llamada Edge Tracker. Los Edge Tracker son goroutines autónomos que se activan a intervalos de tick especificados y utilizan una máquina de estados finitos para decidir qué movimiento de desafío realizar. Por ejemplo, después de crear un edge, intentará dividirla, y confirmarla mediante una prueba de un paso o crear un subdesafío, dependiendo de cómo se presenta el estado actual.

Este es el aspecto de la máquina de estados finitos de un rastreador de aristas, cuyo estado final es confirmado:

Una vez que se confirma un edge de nivel cero para un desafío sobre una afirmación, la afirmación puede validarse y la parte honesta saldrá victoriosa.

Arbitrum ha creado un nuevo enfoque para la validación que nos da un límite superior fijo de 7 días de retraso adicional en las confirmaciones sin sufrir ataques de retraso. BOLD puede hacer que la validación de las cadenas Arbitrum sea segura y sin permisos, lo que las hace subir muchos peldaños en la escalera de la descentralización. El enfoque permite a un único validador honesto ganar disputas en Ethereum contra cualquier número de adversarios.

Con su incorporación, BOLD busca añadir a Arbitrum, una mejor seguridad, liveness y latencia para establecer estados en su cadena y, al mismo tiempo, evitar que las partes deshonestas aumenten el costo de las partes honestas.

Con Arbitrum BOLD, Ethereum contará con una implementación de Optimistic Rollup de propósito general completamente funcional, el cual permitirá asegurarlo bajo suposiciones de confianza ideales (1 de n) y escalar el ecosistema genuinamente y sin compromisos.

🎉 ¡Gracias por leer hasta el final!🎉 Si está interesado en esta solución de escalabilidad te invitamos a revisar nuestra biblioteca de Layer 2 en español.

Si quieres conocer mas a fondo la tecnología detrás de Arbitrum te invitamos a leer estos artículos👇👇👇

Introducción al Optimistic Rollup de Arbitrum

https://mirror.xyz/layer2es.eth/L0YiPok0FymbnHZyA5GqbKL4OL0U4jBDwTuTGzD4PiE

Arbitrum One vs Arbitrum Nova

https://mirror.xyz/layer2es.eth/InEgFG-fRvNv4LTIUSGp0vF9PTyl58AdqswqaYJYu3M

Arbitrum Orbit

https://mirror.xyz/layer2es.eth/yqFRGQzBnGqV0z-fFeuwScBfwf3FVAaplYhThGs5E2E

Si quieren seguir aprendiendo y colaborando con nosotros, le invitamos a unirse a nuestra vibrante comunidad de Telegram L2 en Español y a seguirnos en nuestro Twitter L2 en Español. Allí encontrará una gran cantidad de información sobre Layer 2 y el ecosistema de Blockchain en general. ¡Te Esperamos!