Esquivando balas: problemas de estado de Ethereum

El propósito de esta publicación es revelar formalmente una amenaza grave a la plataforma Ethereum, cuyos peligros son claros e inequívocos hasta la bifurcación dura "Berlín".

Comencemos con algunos antecedentes sobre Ethereum y el "estado".

El estado de Ethereum es un particia-merkle trie (un árbol de Merkle con reglas de árbol de prefijos). Este artículo no entrará en demasiados detalles, solo necesita saber que a medida que crece la cantidad de estados, las ramas de esta estructura de árbol se volverán más y más densas. Por cada cuenta adicional en la cadena de bloques de Ethereum, el árbol tiene un nodo de hoja adicional. En los nodos raíz y hoja del árbol hay muchos de los llamados nodos "intermedios".

Para encontrar una cuenta, o para encontrar una determinada "hoja" en este enorme árbol, es necesario analizar de 6 a 9 valores hash, comenzando desde el nodo raíz, pasando por nodos intermedios y finalmente analizando un valor hash que puede darnos lo que necesitamos: el valor hash de los datos.

Para decirlo en lenguaje sencillo: cada vez que desee encontrar una cuenta en este árbol, debe realizar de 8 a 9 operaciones de análisis. Cada operación de análisis es una consulta de la base de datos y cada consulta de la base de datos significa un número indeterminado de múltiples operaciones de disco. El número de operaciones del disco duro es difícil de estimar, pero debido a que las "claves" del árbol de estado son hashes criptográficos (resistentes a colisiones), estas claves son aleatorias, lo que es peor para todas las bases de datos.

A medida que aumenta el estado de Ethereum, se hace necesario aumentar el consumo de gas de las operaciones que acceden al árbol de estado. Hicimos esto en octubre de 2016 con la bifurcación "Tangerine Whistle" (incluida en EIP 150, activada en el bloque 246 3000). EIP 150 aumenta drásticamente el consumo de gas de ciertas operaciones e introduce una serie de medidas para proteger la red de ataques DoS, esto se introdujo después del llamado "ataque de Shanghai".

Otro aumento de consumo de gas similar se produjo durante la bifurcación "Estambul", activada en la altura del bloque 906 9000 (diciembre de 2019), que introdujo EIP 1884. El contenido de 1884 incluye:

El consumo de gas del código de operación SLOAD aumentó de 200 a 800 de gas

El costo de BALANCE aumentó de 400 a 700 de gas (también se agregó un código de operación SELFBALANCE más económico)

El costo de EXTCODEHASH aumentó de 400 a 700 de gas

En marzo de 2019, Martin Swende midió el rendimiento de los códigos de operación EVM. Esta investigación condujo más tarde a la creación de EIP-1884. El artículo titulado "Metro roto" se publicó (septiembre de 2019) unos meses antes de la activación de 1884.

Dos investigadores de seguridad de ethereum, Hubert Ritzdorf y Matthias Egli, trabajaron con Daniel Perez, uno de los autores del artículo, para convertir una vulnerabilidad en un arma y enviarla al programa de recompensas por errores de ethereum. Eso fue el 4 de octubre de 2019.

Le recomendamos que lea sus presentaciones en su totalidad, están muy bien escritas.

En un canal dedicado a la seguridad entre clientes, los desarrolladores del cliente Geth, el cliente Parity y el cliente Aleth recibieron información sobre el informe, todo el mismo día.

La esencia de la vulnerabilidad es desencadenar búsquedas aleatorias de árboles. Una variante muy simple es:

En su informe, los investigadores ejecutaron esta carga en nodos sincronizados con la red principal a través del punto final RPC eth_call, y a continuación se muestra el tiempo que les llevó consumir 10 millones de gas.

Escape 10 millones de gas usando EXTCOEHASH (el consumo nominal de gas es 400)

Paridad: alrededor de 90 segundos

Geth: alrededor de 70 segundos

Consume 10 millones de gas usando EXTCODESIZE (el consumo nominal de gas es 700)

Paridad: alrededor de 50 segundos

Geth: alrededor de 38 segundos

(Nota del traductor: esto significa que si un bloque de 10 millones de gas se llena con estos dos códigos de operación, el nodo tardará mucho en procesar el bloque)

Está claro que EIP-1884 reduce la efectividad del ataque, pero no es suficiente.

En ese momento, estaba muy cerca de Devcon Osaka. Durante Devcon, el conocimiento de este problema se extendió entre los desarrolladores de clientes de mainnet. También nos reunimos con Hubert y Mathias, y Greg Markou (que es del equipo de Chainsafe y ha estado trabajando en ETC). Los desarrolladores de la cadena de bloques ETC también recibieron el informe.

A medida que 2019 llegaba a su fin, descubrimos que el problema era aún más complicado de lo que pensábamos, con transacciones maliciosas que podían hacer que los tiempos de bloqueo se extendieran a los minutos. Lo que es más difícil es que la comunidad de desarrolladores ya está insatisfecha con EIP-1884, que rompe algunos contratos, y tanto los usuarios como los mineros quieren aumentar el límite de gas del bloque.

Además, solo dos meses después, en diciembre de 2019, Partiy Ethereum anunció que se retiraba y el proyecto OpenEthereum se hizo cargo del mantenimiento del código para el cliente de Parity.

Así que se creó un nuevo canal de colaboración de clientes y los desarrolladores de Geth, Netheremind, OpenEthereum y Besu continuaron colaborando.

Nos dimos cuenta de que este problema solo puede resolverse mediante un enfoque doble. Por un lado, necesitamos mejorar el protocolo de Ethereum, es decir, solucionar este problema a nivel de protocolo, lo mejor es no incumplir el contrato, y no castigar el comportamiento de “buena fe”, sino prevenir ataques.

Por otro lado, podemos confiar en la ingeniería de software para cambiar el esquema y la estructura de datos dentro del cliente.

La primera línea de pensamiento para hacer frente a este tipo de ataque es la siguiente. En febrero de 2020, se publicó su versión oficial como EIP 2583. La idea detrás de esta propuesta es agregar una penalización que se active-kepj cada vez que una búsqueda en el árbol resulte en un error ("no encontrado").

Sin embargo, Peter descubrió una forma de evitarlo, un ataque de "relevo protegido", que esencialmente limitó la penalización (alrededor de 800).

El problema con el método de falta de penalización es que debe haber un proceso de búsqueda antes de que se pueda determinar si se impone una penalización. Pero si el gas remanente ya no alcanza para imponer la sanción, entonces (desde el punto de vista del protocolo) ya se ha ejecutado un proceso de consumo mal pagado. Aunque esto provoque que se arroje un error, estas lecturas de estado se pueden encapsular en llamadas anidadas, lo que permite a los llamantes externos repetir el ataque sin pagar la penalización (total).

Por lo tanto, este EIP también se ha abandonado y estamos buscando una mejor alternativa.

Alexey Akhunov investigó el concepto de petróleo, un "gas" secundario, pero a diferencia del gas, es invisible para la capa de ejecución y puede provocar una reversión global de transacciones.

Martin hizo una propuesta similar llamada "Karma" en mayo de 2020.

Si bien muchas de estas propuestas están progresando, Vitalik Buterin propone simplemente aumentar el consumo de gas y mantener una "lista de acceso". En agosto de 2020, Martin y Vitalik comenzaron a iterar sobre lo que se convertiría en EIP-2929 y su compañero, EIP-2930.

EIP-2929 resuelve fundamentalmente muchos de los problemas mencionados anteriormente.

A diferencia de EIP-1884, 1884 aumenta incondicionalmente el consumo de gas, pero 2929 solo aumenta el consumo de gas para acceder a nuevos objetos. Eso agrega menos de un punto porcentual a los costos netos.

Del mismo modo, cuando se combina con EIP-2930, no se romperá ningún contrato.

También se puede ajustar aún más aumentando el consumo de gas (sin romper el contrato)

El 14 de abril de 2021, ambos EIP se activarán durante la bifurcación "Berlín".

Peter intentó resolver este problema con una instantánea de estado dinámico, era octubre de 2019.

Una instantánea es una estructura de datos secundaria que se utiliza para almacenar el estado de Ethereum en un formato plano. Las instantáneas se pueden crear durante el funcionamiento normal de un nodo Geth, sin necesidad de desconectarlo para una ejecución especial. El beneficio de una instantánea es que se puede usar como una estructura acelerada para el acceso estatal:

En lugar de realizar lecturas de disco O(log N) (multiplicadas por la sobrecarga de LevelDB) para acceder a una cuenta/elemento de almacenamiento, las instantáneas proporcionan un tiempo de acceso O(1) inmediato (multiplicado por la sobrecarga de LevelDB).

Las instantáneas también admiten la iteración sobre la cuenta y los elementos de almacenamiento con una complejidad de O(1) por entrada, lo que permite que los nodos remotos recuperen datos de estado continuo mucho más baratos que antes.

La presencia de instantáneas también admite otros usos más exóticos, como la poda fuera de línea del árbol de estado y la migración a otro formato de datos.

La desventaja es que una instantánea equivale a una copia completa de los datos sin procesar de la cuenta y los elementos de almacenamiento. Si se usa en un entorno de red principal, esto significa que se requieren 25 GB adicionales de espacio SSD.

La idea de las instantáneas dinámicas existe desde mediados de 2019, cuando el objetivo principal era habilitar la "sincronización de instantáneas". En ese momento, el equipo de Geth todavía estaba trabajando en muchos "grandes proyectos":

Poda de estado sin conexión

Instantánea homomórfica + sincronización de instantáneas

Descentralización del estado LES a través del estado compartido

Sin embargo, más tarde decidieron centrarse en la función de instantáneas y pospusieron otros proyectos. Estos trabajos sentaron las bases para el posterior algoritmo de sincronización snap/1. Este algoritmo se fusionó con el código base en marzo de 2020.

Con la función "Instantánea de movimiento", podemos tomar un respiro. Sería doloroso si la red Ethereum fuera atacada, pero al menos podemos notificar a los usuarios para que activen las instantáneas. Se tarda un tiempo en generar instantáneas y aún no hay forma de sincronizarlas, pero al menos la red continúa funcionando.

En marzo/abril de 2021, se lanzó el protocolo snap/1 en el cliente geth, y los nodos podrán usar el nuevo algoritmo basado en instantáneas para sincronizar la cadena de bloques. Si bien aún no es el modo síncrono predeterminado, esto es parte de lo que hace que las instantáneas no solo sean una defensa contra los ataques, sino también una mejora significativa de la experiencia del usuario.

A nivel de protocolo, la actualización "Berlín" se activó en abril de 2021.

En nuestro entorno de monitoreo de AWS, nuestros resultados de referencia son los siguientes:

Antes de "Berlín", sin instantáneas, 25 millones de gas procesado: 14,3 segundos

Antes de "Berlín", con instantáneas, procesando 25 millones de gas: 1,5 segundos

Después de "Berlín", sin instantáneas, 25 millones de gas procesado: unos 3,1 segundos

Después de "Berlín", con instantánea, procesando 25 millones de gas: alrededor de 0,3 segundos

Este número (aproximado) muestra que la actualización "Perlin" hizo que el ataque fuera 5 veces menos efectivo, y la instantánea lo hizo 10 veces menos efectivo, lo que finalmente redujo su impacto en 50 veces.

Estimamos que en la red principal actual (con un bloque de 15 millones de gas), un nodo geth que no use instantáneas puede ejecutar un bloque en solo 2,5 a 3 segundos. Este número continúa empeorando a medida que crece el estado (para los nodos que no usan instantáneas).

Si el mecanismo de devolución de gas se utiliza para aumentar el uso real de gas de un solo bloque, el multiplicador (máximo) de este deterioro es 2 veces. Después de la implementación de EIP-1559, el límite de gas del bloque tendrá una mayor flexibilidad y el multiplicador de deterioro máximo de 2 veces se puede explotar en un corto período de tiempo.

En cuanto a la viabilidad de implementar este ataque, el costo para que un atacante compre un bloque es de unos pocos ETH (15 millones de gas, 100 Gwei, multiplicado por 1,5 ETH).

Esta amenaza ha sido un "secreto a voces" durante mucho tiempo: se ha revelado públicamente al menos una vez por descuido; y también se ha mencionado varias veces en las reuniones principales de desarrolladores, aunque no se han hecho públicos los detalles.

Dado que activamos la actualización "Berlín", y dado que el cliente geth ya usa instantáneas de forma predeterminada, creemos que la amenaza es lo suficientemente baja como para que la transparencia sea más importante. Así que es hora de sacar a la luz el trabajo detrás de escena.

Lo importante es que la comunidad tuvo la oportunidad de comprender y pensar sobre estos cambios que afectan la experiencia del usuario (estos EIP aumentarán el consumo de gas y limitarán el efecto del mecanismo de devolución).

Tags：

SHIB