Análisis en profundidad del mecanismo de seguridad de Arbitrum

La solución de expansión de Capa 2 es un tema candente en la comunidad Ethereum actual, y también es un tema candente que se está discutiendo en toda la comunidad de tecnología blockchain. Arbitrum basado en Optimistic Rollups es actualmente una de las soluciones de escalado de Capa 2 más atractivas. Fue el primero en implementar una versión beta de la red principal y obtuvo el apoyo de proyectos centrales de DeFi como Uniswap y Compound.

Para los usuarios que tienen la intención de migrar de la red principal de Ethereum a la Capa 2, una de sus mayores preocupaciones es qué tan segura es la solución de Capa 2. Este artículo profundizará en los mecanismos de seguridad de Arbitrum, que incluyen: cómo Arbitrum se basa en la seguridad de Ethereum, por qué el período de desafío es de siete días y cómo defenderse de los ataques de censura.

Arraigado en la seguridad de Ethereum

Todos sabemos que la mayor ventaja de las soluciones de Capa 2 en comparación con otras soluciones de expansión es que su seguridad depende de la seguridad de la red principal de Ethereum. Sin embargo, la mayoría de las personas probablemente conocen esta verdad, pero no saben por qué. Entonces, ¿cómo se incrusta Arbitrum en la seguridad de Ethereum?

Primero repasemos las características principales de la solución Optimistic Rollup:

En una solución de resumen, las transacciones (como datos de llamadas) se escriben en L1, pero su cálculo real y almacenamiento de contratos se realiza en L2 para escalar.

El verificador publica una aserción en L1, que puede entenderse como un paquete de todas las transacciones y resultados en un bloque de resumen y luego lo envía a la transacción L1.

Resumen optimista se denomina solución de resumen "optimista" porque cuando se emite una afirmación, no contiene una prueba que la acompañe que garantice su validez, es decir, la afirmación es válida de forma predeterminada. En cambio, habrá una ventana de tiempo dentro de la cual cualquiera puede cuestionar la afirmación. Si la impugnación tiene éxito, todas las transacciones dentro de esta afirmación se revertirán y la persona que hizo la afirmación perderá su depósito. Si el período de impugnación expira y nadie tiene éxito, se finaliza la aserción.

Después de comprender esta solución, pensemos en cómo Arbitrum está arraigado en la seguridad de Ethereum desde varios ángulos.

Disponibilidad de datos

Todas las transacciones ejecutadas en L2 se envían primero al contrato inteligente de Inbox que se ejecuta en L1 y luego se escriben en L1 como datos de llamada. Cualquiera puede aprovechar estos datos para recuperar todas las transacciones en L2 y restaurar L2 a su estado original. La disponibilidad de estos datos está garantizada a través de L1 y los usuarios no tienen que preocuparse por perder sus activos en L2 debido a una falla en L2.

Cualquier Confianza

AnyTrust es una función de seguridad clave del protocolo Rollup. Esta característica permite que cualquier validador honesto se asegure de que las transacciones se ejecuten correctamente en L2. No importa cuántos atacantes maliciosos impidan que se procese la transacción, usted o cualquier persona que contrate puede hacer cumplir la ejecución correcta de la transacción sin confiar en ningún tercero.

CEO de MicroStrategy: el comité de minería de Bitcoin 'defenderá' Bitcoin: Golden Finance Reports, el CEO de MicroStrategy, Michael Saylor, dice que el comité de minería de Bitcoin 'defenderá' a Bitcoin contra 'desinformados' y 'hostiles' "The Energy Critic. [2021/5/26 22:44:11]

Mecanismo de salida de emergencia

Arbitrum actualmente no cuenta con un mecanismo de salida de emergencia específico, pero cuenta con una serie de mecanismos de seguridad para garantizar que los usuarios puedan salir de manera segura.

En primer lugar, la disponibilidad de datos garantiza que los activos y los datos de los usuarios almacenados en L2 se puedan restaurar desde L1 en cualquier momento y nunca se perderán.

En segundo lugar, cualquier usuario puede enviar una solicitud de transacción al contrato de bandeja de entrada en L1 para forzar una salida.

Finalmente, el mecanismo AnyTrust garantiza que los usuarios puedan obligar a L2 a manejar adecuadamente las transacciones de salida.

En los tres puntos anteriores, los usuarios no necesitan confiar en ningún tercero, lo que demuestra plenamente que Arbitrum tiene sus raíces en la seguridad de Ethereum y no es confiable.

Por qué el período del desafío es de siete días

Arbitrum es una solución acumulativa con múltiples rondas de interacción. Esta solución primero cree de manera optimista que la afirmación hecha por el verificador es válida, y otros verificadores pueden cuestionarla y cuestionarla durante el período de impugnación. En la mayoría de los casos, no hay desafíos y el sistema general puede ser más eficiente y menos costoso.

Obviamente, cuanto más largo sea el período de desafío, más seguro será el sistema en su conjunto, pero al mismo tiempo la experiencia del usuario será peor (porque el usuario debe esperar hasta que finalice el período de desafío antes de poder cerrar sesión). Entonces, ¿cómo determinamos el mejor período de desafío?

El equipo de Arbitrum propone este modelo para calcular el período de desafío óptimo:

Suponga que un período de desafío es igual a la longitud de C bloques, y el valor máximo que un atacante puede obtener en L2 es V.

Entonces el valor esperado obtenido por el atacante es V exp(-AC).

Nota: exp es la función exponencial "e", A es una cierta constante A, y el símbolo "-" antes de AC indica que C es inversamente proporcional al rendimiento esperado.

Los asertores deben garantizar que sus activos excedan con creces el valor de los activos del ataque para hacer frente al ataque. Digamos que sobre 10x, el costo del asertor es 10V exp(-AC)I. Me refiero a la tasa de capital.

Suponemos que el activo de retiro bloqueado por un usuario que sale durante el período de desafío es CWV (W es un decimal, WV es una parte de los activos totales en L2, y habrá C bloques de desafío sin terminar en cada punto de tiempo) y el usuario costo de los activos para CWVI.

El período de impugnación óptimo debe establecerse cuando el costo total de los activos del afirmador y el usuario que se retira es el más bajo. Es decir, cuando se toma el valor de C, 10V exp(-AC)I+CWVI es el más pequeño. Tanto V como I aparecen en ambos términos, no afecta el punto mínimo y se puede ignorar. Simplemente derivamos con respecto a C, establecemos la derivada resultante en 0 y obtenemos C = ln(10A / W) / A.

Ahora insertamos algunos números razonables en la ecuación anterior para obtener un período de desafío óptimo aproximado.

Suponga que la tasa de éxito de la revisión continua dentro de un bloque de tiempo es tan alta como 99,99 %, es decir, A = -ln(0,99) = 0,01.

Suponga además que el retiro diario es el 1 % del valor total, y el porcentaje de retiro por bloque es de aproximadamente W=0,000002, según la premisa de que el tiempo del bloque es de 15 segundos.

Conectándolos a la fórmula, obtenemos un período de desafío óptimo de C = 62146 bloques, o 10,79 días. Esto está muy cerca de la fecha límite de desafío de 7 días que finalmente eligió el equipo de Arbitrum.

Cómo defenderse de los ataques de censura

En esta parte, discutimos cómo Arbitrum se defiende contra cuatro tipos principales de ataques de censura: ataques de bifurcación, ataques de rechazo, ataques de interferencia y ataques de demonio de velocidad.

Ataques de bifurcación: los mineros conspiran (o son sobornados) para descartar bloques que contienen desafíos normales para aceptar cadenas alternativas que no contienen desafíos.

En primer lugar, debido a la existencia de retadores, una vez que ocurre un ataque de bifurcación, inevitablemente será descubierto por un retador. Y cuando se descubre que el monopolio del poder minero en la cadena de bloques (que es un requisito previo para un ataque de bifurcación) está rompiendo descaradamente las reglas con fines de lucro, la propia cadena de bloques se destruye. En este momento, es discutible si Arbitrum adoptó el modelo de diseño del período de desafío.

Evitar ataques: los mineros conspiran (o son sobornados) para ignorar los desafíos comunes en los bloques que producen.

Asumimos que un monopolio controla el 90% de la potencia minera y tiene un plazo de 50 bloques. Luego, el monopolista necesita empaquetar 50 bloques consecutivos para completar el ataque. Esta probabilidad es de 0,9 a la 50ª potencia, o 0,5%. El período de desafío real es mucho más de 50 bloques, por lo que la probabilidad de un ataque exitoso es extremadamente pequeña. En el diseño de Arbitrum, el atacante paga una gran multa si el ataque falla, por lo que es muy antieconómico para un monopolista lanzar un ataque evasivo.

Ataques de interferencia: el atacante lanza un "ataque de denegación de servicio (DoS) anticuado" para evitar que cualquier parte publique transacciones (las transacciones que contienen desafíos no se pueden publicar).

Dado que el ataque falla mientras haya un solo retador honesto, el atacante debe bloquear a todos los posibles retadores. Si hay muchos de esos retadores, el ataque será difícil de completar. Peor aún, cualquier parte interesada puede contratar a un perro guardián silencioso como plan de respaldo. Solo intervienen si los jugadores principales publican el desafío demasiado tarde o tienen problemas para publicar el desafío. El atacante no sabe si hay monitores silenciosos en la red, o incluso sabe que existen, y no sabe quiénes son, por lo que el atacante no puede lanzar un ataque DoS contra estos monitores hasta que realmente tomen medidas.

Ataques de demonio de velocidad: el atacante genera afirmaciones en cadena tan rápido que otras partes no pueden verificar y desafiar todas las afirmaciones antes de que expire el tiempo.

Arbtirum responde limitando la velocidad a la que se crean las afirmaciones para garantizar que la cantidad total de trabajo necesaria para verificar las afirmaciones pendientes y cuestionar una en cualquier momento se pueda realizar dentro del plazo del acuerdo. Específicamente, se impone un límite de velocidad en el progreso de las operaciones de contratos inteligentes en la cadena Rollup, por lo que incluso si alguien puede generar una gran cantidad de afirmaciones rápidamente, eventualmente debe ralentizarse.

En conclusión, no tenemos que preocuparnos demasiado por los ataques de bifurcación. Si existe un monopolio del poder informático de minería maliciosa, entonces se puede decir que esta cadena de bloques básicamente se ha vuelto poco atractiva. Arbitrum puede defenderse de los otros tres ataques de censura a través de un diseño o práctica adecuados.

Ventajas y riesgos del modo secuenciador

El modo Sequencer es una característica opcional de Arbitrum, y Offchain Labs ejecuta el único nodo Sequencer en la versión de lanzamiento de la red principal.

El secuenciador tiene un poder limitado para controlar el orden de cada transacción en la bandeja de entrada para garantizar que el resultado de la transacción del usuario se pueda determinar de inmediato, sin esperar cinco minutos para que se confirme el bloque en Ethereum, o incluso sin requerir también esperar 15 segundos para el bloque de tiempo.

Al mismo tiempo, un secuenciador que se comporte bien puede defenderse eficazmente contra los ataques frontales.

Por lo tanto, un nodo Sequencer centralizado y de buen comportamiento operado por Offchain Labs es muy beneficioso para el desarrollo temprano del proyecto y le ahorra muchos problemas. Pero los riesgos de seguridad también son obvios (aunque es difícil imaginar que Offchain Labs haga el mal, no descarta la posibilidad). Offchain Labs promete cambiar a una solución de nodo de secuenciador múltiple descentralizada tan pronto como la tecnología madure.

Además, la bandeja de entrada también se dividirá en dos, una para aceptar transacciones enviadas por Sequencer y la otra para aceptar transacciones enviadas por agregadores o usuarios habituales, lo que también proporciona otra forma de elección para los usuarios que no confían en el Sequencer centralizado.

Fuente | Hackernoon

Autor | DeGate

Tags：

XRP