¿Dónde está el riesgo de seguridad de Ethereum usando la tecnología Rollup?

Ethereum ha confirmado la hoja de ruta 2.0 centrada en Rollup, lo que convierte a Rollup en una tecnología de moda, y también se puede decir que se ha convertido en la tecnología principal para la expansión de la capa 2. Si se combina con la prueba de conocimiento cero, Rollup será un maestro de las soluciones en tecnología de capa 2.

Pero como dice el refrán, "no hay un sistema absolutamente seguro", Rollup también tiene ciertos riesgos de seguridad.Los desarrolladores en el Ethereum Research Forum ya han discutido este asunto. El 20 de enero, el desarrollador de Ethereum "jchancehud" publicó una discusión sobre los ataques acumulativos virtuales.

La siguiente es una discusión sobre los ataques acumulativos virtuales. Organizado por el equipo del Plan Blanco, con algunas modificaciones y comentarios.

Razones de los riesgos de seguridad de Rollup

La razón detrás del ataque de resumen simulado es que cualquier nodo de Ethereum puede mentirle al coordinador de resumen optimista siempre que el estado virtual sea válido. Y el coordinador solo descubrirá esto cuando intente enviar transacciones o cambiar de proveedor de ethereum (es decir, sincronizar el estado del nodo completo).

El resumen optimista se realiza mediante el uso de datos de llamadas para almacenar información de bloques en la red Ethereum. Este proceso permite que cualquier persona opere un nodo Ethereum y descargue el estado del resumen. Pero en la práctica, algunas personas no operan sus propios nodos de Ethereum, sino que confían en soluciones de custodia (como Infura).

Necesita verificar la validez

Si desea crear una cadena acumulativa válida de forma rápida y económica, todo lo que necesita hacer es realizar transacciones, crear un estado y almacenarlo en otras ubicaciones fuera de la red de Ethereum. Cuando un coordinador de resumen recibe el historial de estado de un nodo de Ethereum, el coordinador puede determinar si los datos son válidos al reproducir las transacciones de estado. Sin embargo, el coordinador no puede estar seguro de que el estado exista en la cadena, la mejor manera es preguntar al nodo Ethereum.

En caso de ataque humano

Si imagina un servicio de nodo Ethereum llamado Untrust. Untrust proporciona infraestructura de bajo costo para dapps de Ethereum. Si eligen no confiar, pueden mirar un resumen en particular y crear una historia ficticia. Incluso pueden crear historias semivirtuales extrayendo datos de comunicación de algunas transacciones reales y mezclándolos con transacciones virtuales.

El sector de la moneda digital se está recuperando: el mercado muestra que el sector de la moneda digital se está recuperando, Beijing North aumentó más del 9%, las acciones de Yuyin, las acciones de Zhidu, Tianyuan Dike y Zhewen Internet siguieron su ejemplo. [2021/4/14 20:18:06]

De esta manera, crearán un hash completamente diferente del estado actual, pero esto solo se descubrirá (lo que sería fraudulento) si se confirma un bloque (en la cadena) utilizando el operador Rollup de Untrust.

Este tipo de ataque no es particularmente poderoso. Los atacantes no pueden falsificar firmas, no pueden robar fondos directamente, pero pueden mentir sobre sus actividades en un resumen.

Imagina que Untrust se vuelve más complicado. Decidieron atacar a Rollup llamado MoneyMover.

Cuando se reciben solicitudes de direcciones de MoneyMover, devuelven información de los nodos que ejecutan una red Ethereum completamente separada. En esta red Ethereum separada, Untrust refleja la mayoría de las transacciones (haciendo que los saldos de las cuentas se vean similares) e inyecta sus propias transacciones (falsas) cuando es necesario.

Ahora digamos que Untrust encuentra un sitio que paga con MoneyMoverRollup. El sitio ejecuta su propio coordinador MoneyMover que conecta Untrust para acceder a la red Ethereum.

Untrust puede crear transacciones ficticias en su red espejo que el coordinador de MoneyMover interpreta como válidas (siempre que la transacción estatal sea válida). Dado que el coordinador de MoneyMover no está conectado a ningún par, la única forma de determinar la presencia en la cadena es preguntar a un nodo Ethereum (Untrust en este caso).

Untrust realizó una transacción ficticia en su red espejo, que fue detectada como un pago válido por los coordinadores de MoneyMover operados por el sitio. Untrust ahora ofrece acceso al sitio sin pagar. Los sitios web solo descubrirán este pago ficticio cuando envíen transacciones o cambien a otros proveedores de Ethereum (es decir, para sincronizar datos con otros nodos).

Riesgos realmente posibles

El ataque anterior solo tiene sentido si el coordinador no está ejecutando su propio nodo Ethereum. Hay algunas situaciones en las que esto es problemático:

Los diferenciales de precios de futuros de Bitcoin han seguido fluctuando ligeramente en los últimos días: según Jinse Finance, según datos de clientes pares, el 30 de noviembre, la diferencia de precios de futuros de Bitcoin anualizada fue del 8,57 %, un aumento del 0,19 % con respecto al día anterior, y el El índice de sentimiento del mercado fue "optimista".

Referencia del índice: >20 % extremadamente alcista; 10 %~20 % alcista; 5 %~10 % optimista; 2 %~5 % cautelosamente optimista; 0~2 % cauteloso; -5 %~0 cautelosamente pesimista; -10 %~- 5% pesimista; -20%~-10% bajista; <-20%: extremamente bajista. [2020/11/30 22:33:15]

1. Los consumidores intermedios de los datos del coordinador no tienen forma de saber si los datos que reciben existen (en la cadena) y no pueden confiar en el nodo eth que utiliza el coordinador porque el consumidor no ejecuta ese nodo por sí mismo.

2. Los probadores de fraude (la parte que prueba una transacción maliciosa) son especialmente vulnerables a este ataque porque solo envían transacciones cuando se detecta un fraude. Un nodo eth malicioso podría eliminar las transacciones no válidas de los datos de la cadena de bloques y simplemente devolver un hash de estado diferente. Un probador de fraude no tendrá forma de saber que el hash del estado es fabricado y nunca cometerá un reclamo de fraude.

3. Los operadores de nodos eth mienten a los coordinadores de resumen para engañarlos para que envíen transacciones de estado no válidas o reclamos de fraude no válidos. Una vez que esto sucede, los operadores de nodos eth maliciosos pueden actuar como contrapartes efectivas y recolectar los fondos apostados.

Solución 1

En el contexto de una cadena de prueba de trabajo, un coordinador puede solicitar datos de bloque y verificar si es lo suficientemente difícil. Verificar al menos la mitad de la dificultad actual debería hacer que la mayoría de los ataques sean financieramente imposibles.

En una cadena de prueba de participación, este proceso se vuelve inviable, ya que los nodos eth maliciosos pueden proporcionar firmas de direcciones no votadas. Pueden hacerlo prometiendo una cantidad de garantía en el momento de la consulta.

Solución 2

Una solución menos elegante es firmar continuamente nodos de buena reputación y publicar una lista de hashes de estado de resumen que ya existen en la cadena. La lista se puede publicar en un servicio como IPFS. El nodo coordinador puede incluir una lista preestablecida de claves públicas de buena reputación conocidas (Rollup Creator, EF, etc.).

Los coordinadores saben que los datos de Rollup son reales si:

1. Todas las transacciones de estado son válidas.

2. Todos los hashes estatales están firmados por fuentes acreditadas (nodos).

Esto garantizará que los datos del resumen sean válidos y no ficticios, y permitirá que los nodos del resumen utilicen cualquier nodo de Ethereum para sincronizar datos.

Lo anterior es la posibilidad de un ataque de seguridad de Rollup discutido por "jchancehud".

La razón principal es que Rollup es un estado fuera de la cadena, y es fácil que la sincronización de la información no sea oportuna en muchos estados. Según "jchancehud", la parte que necesita verificar si el estado fuera de la cadena es válido necesita sincronizar los datos de otros nodos completos de Ethereum para confirmar En última instancia, por seguridad, esto significa que muchas plataformas necesitan ejecutar un nodo de Ethereum.

Con respecto al método de ataque virtual mencionado anteriormente, "Konstantin Kladko", director de tecnología del equipo de solución de capa 2 de Ethereum, SKALE Labs, dijo: "¡Esto es realmente interesante! Creo que demuestra que al destruir Infrua, básicamente se pueden destruir todos los Rollups". ”

Por supuesto, esto representa aquellos productos que se comunican con Ethereum a través de Infura. Infura realiza una gran escala de servicios de nodo de Ethereum. También ha habido discusiones sobre si Infura será el mayor punto de vulnerabilidad en la red de Ethereum. En cuanto a este riesgo de seguridad de un solo punto, se maneja principalmente en forma de equilibrio de carga de múltiples nodos para evitarlo tanto como sea posible.

En cuanto a la discusión de "jchancehud", lo más interesante es que el desarrollador "adlerjohn" propuso que este "ataque" virtual parece ser aplicable no solo a Optimista Rollup, sino también a zkRollup, y de hecho a cualquier contrato inteligente.

Es probable que esta inferencia se base en el proceso de colaboración "siempre que exista el peligro de asimetría de la información", se enfrentará al riesgo de ataque mencionado por "jchancehud".

Por lo tanto, "adlerjohn" propuso que en la Sección 8 del libro blanco de Bitcoin, hay una forma de verificar que la información sea correcta o incorrecta, es decir, el verificador determina la cadena más larga y confía en la cadena más larga. Este método describe un bien- esquema conocido, este esquema se puede usar para evitar que los nodos de Sybil proporcionen información falsa, lo que no requiere que la mayoría de los cálculos sean honestos.

Sección 8 del Libro Blanco de Bitcoin

Además, "adlerjohn" propuso que la raíz del estado de Rollup se puede enviar como un evento, e incluso se puede almacenar en el estado de Ethereum, y también se puede consultar por transacciones falsificadas (por ejemplo, la Sección 7 del libro blanco de Bitcoin indica que se puede confirmar verificando el encabezado del bloque).

Además, "adlerjohn" también mencionó que el esquema de resumen optimista también puede incluir un diseño llamado "Consenso de fusión mínima factible", que puede lograr la disponibilidad de datos mediante la publicación de datos ordenados, lo que permite el uso de múltiples cadenas laterales y fragmentos.

Nota al Plan Bai: La interpretación del consenso mínimo factible de fusión se encuentra en el siguiente enlace

https://ethresear.ch/t/minimal-viable-merged-consensus/5617

Pero es previsible que utilizar el método propuesto por "adlerjohn" sea más difícil de diseñar.

Al final de la discusión, "jchancehud" respondió a "adlerjohn" que no estaba seguro de si este tipo de predicción de ataque es aplicable a ZKRollup. Pero dado que las pruebas ZK son más difíciles de generar, al menos será más difícil. Pensar en los paquetes acumulativos de esta manera es especialmente importante si se adoptan ampliamente.

Los coordinadores de resumen pueden verificar todos los encabezados de bloque en un nodo antes de usar el nodo, que es otra solución potencial, aunque costosa en tiempo y ancho de banda. Pero es mejor que los usuarios ejecuten nodos eth light en los que saben que pueden confiar. La ejecución de un nodo ligero también puede consultar eventos si se han resuelto los problemas de validación.

Al final de la discusión, encontraremos que para lograr seguridad, escalabilidad y eficiencia, estas soluciones se pueden probar de acuerdo con la idea de ingeniería, pero el proceso de implementación debe ser difícil, porque las ideas de discusión de diferentes los desarrolladores necesitan sintetizar el código al final e incluye muchos desafíos, como la estructura de la red, el cliente, el idioma y la interfaz de operación.

La marca de tiempo avanza y los bloques no se detienen. Sigamos esperándolo.

Tags：

DOT