Análisis de una actualización importante de Arbitrum: verificación sin permiso con BOLD

Autor: @francescoweb3; traducción: Huohuo/vernacular blockchain

**Arbitrum se está volviendo más descentralizado: usa BOLD para verificación sin permiso. **Si bien esta puede no ser una semana con un nombre como BALD, esta es una actualización importante del diseño de Arbitrum.

BOLD son las siglas de Bounded Liquidity Delay y, como sugiere su nombre, es un "protocolo de disputas" que proporciona a Arbitrum capacidades de verificación sin permiso.

**1. ¿Por qué necesita BOLD? **

En términos simples, todos los Rollups optimistas establecen su estado en Ethereum. **¿Cómo se aseguran de que la transacción sea válida? A través del llamado sistema a prueba de fraude. **

En la práctica, esto sucede a través de un conjunto de entidades llamadas validadores. Estos validadores emiten declaraciones sobre el estado de L2 y confirman a través de contratos inteligentes que estas declaraciones son ciertas.

Luego, hay un período de impugnación de 7 días (o período de enfriamiento) durante el cual otros validadores pueden impugnar estas afirmaciones y, si hay una discrepancia, se inicia el proceso de resolución de disputas.

Si se confirma un reclamo, el estado L2 se considera correcto y la liquidación se completa en Ethereum.

Es el proceso de verificación a través de la prueba de fraude lo que provoca un retraso de aproximadamente 7 días para el puente local entre Arbitrum y Ethereum.

El protocolo de disputa involucra a las partes que envían pruebas de fraude a Ethereum para determinar el resultado válido de una transacción L2.

**¿Cuál es el problema? Actualmente, la verificación a través de pruebas de fraude requiere permiso tanto en Arbitrum One como en Nova. **

El motivo de esto es proteger el protocolo de disputa de los ataques de denegación de servicio. Si un validador malintencionado sigue gastando fondos para evitar que se confirmen las reclamaciones, se bloquearán los retiros de L2 a Ethereum y, mientras tengan fondos suficientes, este proceso puede continuar durante casi mucho tiempo.

Esto se denomina ataque de demora e intenta detener el progreso del protocolo de resumen al "intentar prevenir o retrasar la confirmación de cualquier resultado". Este ataque está diseñado para evitar que los validadores envíen pruebas fraudulentas, de modo que el estado L2 no pueda confirmarse y liquidarse en Ethereum.

De hecho, pasar a la verificación sin permiso requiere un protocolo que sea resistente a los ataques de retraso, como BOLD.

BOLD es un nuevo método de verificación L2 sin permiso.

Le permite a Arbitrum:

Garantizar la seguridad y vivacidad de la cadena

Minimizar la latencia en la liquidación del estado

Evite que las partes deshonestas aumenten los costos para las partes honestas.

De hecho, BOLD puede ayudar a descentralizar la cadena Arbitrum al proporcionar una "confirmación retrasada adicional fija de 7 días" que es inmune a los ataques de retraso.

Logra esto al permitir "disputas de todos contra todos" eficientes, en las que incluso un solo validador honesto puede ganar una disputa con cualquier cantidad de reclamos maliciosos.

Por lo tanto, BOLD puede resolver de manera eficiente disputas entre múltiples partes en un solo proceso sin depender de desafíos uno a uno anteriores.

BOLD pide a todas las partes que apoyen una declaración en particular que luchen juntas "como un equipo".

Por lo tanto, cualquier disputa en NEGRITA está relacionada con la ejecución "determinista" del estado L2, no con un participante o entidad específica.

Esto significa que cualquiera que esté de acuerdo con un estado puede justificarlo antes de encontrar un solo punto de inconsistencia.

Por lo tanto, dado que las disputas en BOLD se llevan a cabo como parte de todo el equipo, cualquier acción acordada que se tome en nombre del equipo cuenta con el respaldo de cada miembro honesto del equipo.

La naturaleza determinista de un estado L2 correcto significa que las partes honestas siempre ganarán si participan, ya que las partes maliciosas no pueden falsificar pruebas de ejecución de transacciones. Este diseño es más eficiente porque cada parte puede "confiar tranquilamente en que otros representen su posición sin preocuparse de que la parte falle deliberadamente en el desafío".

Comprensión profunda de BOLD

En lugar de ser visto como un protocolo de desafío entre diferentes partes, el protocolo BOLD debe entenderse como una competencia entre "bordes" donde el objetivo de los participantes es seleccionar el borde correcto como ganador.

¿Cómo funciona este proceso en segundo plano?

1. "Edge" es la estructura de datos principal en el protocolo de desafío.
2. El objetivo de BOLD es confirmar los bordes correspondientes a los cálculos correctos y evitar que se confirmen bordes incorrectos.
3. BOLD rastrea el estado de un borde, pero no vincula un borde a ninguna parte en particular.
4. Los filos se clasifican según su relación con la ejecución correcta.
5. El protocolo no sabe a qué categoría pertenece el borde, pero los participantes honestos pueden decirlo.
6. Un borde tiene un "compromiso de historial de inicio" y un "compromiso de historial de finalización".
7. Un borde es demostrable si tanto su comienzo como su final son verdaderos, es desviado si solo su comienzo es verdadero y es irrelevante si ambos son falsos.
8. Para justificar el protocolo: 8.1 Teorema de Seguridad: No se puede confirmar ninguna desviación de ningún margen. 8.2 Teorema del tiempo de finalización: los bordes honestos se pueden confirmar antes de una fecha límite.

Infraestructura audaz

2. Conclusión

BOLD logra un límite de latencia óptimo en la confirmación de resultados, y también limita linealmente el trabajo requerido por las partes honestas en términos de los beneficios confiscados por la parte adversaria.