Una red flag en Ethereum pone en riesgo millones de ETH

Los nodos validadores de Ethereum utilizan clientes, que son softwares que les permiten conectarse e interactuar con la red a nivel de creación de bloques (capa de ejecución) y a nivel de validación (capa de consenso). Recientemente, el dominio del cliente geth en la capa de ejecución alcanzó niveles realmente peligrosos.

El 22 de enero de 2024, el uso del cliente geth llegó al 84% de los nodos de Ethereum en la capa de ejecución. Muy por debajo, con el 8%, le seguía Nethermind, que el día anterior había detectado un bug en su actualización más reciente. Si bien es verdad que la falla afectaba a la capa de consenso, es posible que muchos que usaban Nethermind en la capa de ejecución hayan cambiado a otro cliente por precaución.

Al momento de redactarse este artículo, las advertencias presentadas por varios desarrolladores en las últimas horas parecen haber tenido cierto efecto. El dominio de geth bajó al 78%, mientras que el de Nethermind escaló al 14%.

No obstante, la cifra sigue estando lejos de lo ideal. Como explicó el desarrollador reconocido como cygaar, esto puede llevar a que los nodos que usan geth logren finalizar bloques sin depender de nodos que usen otros clientes. Es decir, dar por ciertas y válidas transacciones que podrían no serlo, lo que podría traducirse en penalizaciones y pérdida de los ethers (ETH) en staking para esos nodos.

En la capa de consenso, se necesitan 2/3 de los validadores para llegar a la finalización. Si hubiera un cliente de consenso de gran mayoría (66 %) que tuviera un error, la cadena no podría finalizar. Terminaríamos en un mundo con bifurcaciones incorrectas y nadie conocería la cadena canónica. Esto puede hacer que los nodos sean penalizados (pierdan los ETH apostados) y también que se desconecten, debido a problemas de memoria/cómputo/sincronización. De hecho, esto mismo ocurrió en una red de pruebas hace un par de años a causa de un error de Prysm.

Cygaar, desarrollador de los proyectos Frame XYZ y MocaverseNFT en Ethereum.

¿Por qué importa la diversidad de clientes en Ethereum?

Hay consenso general entre desarrolladores de Ethereum de promover la diversidad de clientes en la red. Al respecto, un artículo del desarrollador Dankrad Feist que fue revisado por el propio Vitalik Buterin, cocreador de Ethereum, y otros especialistas como Hsiao-Wei Wang y Caspar Schwarz-Schilling, habla del asunto.

Feist destaca la importancia de la diversidad de clientes en Ethereum para mitigar riesgos de seguridad y garantizar la continuidad de la red. Para fomentar esta diversificación, se imponen penalizaciones más altas por fallas correlacionadas, lo que incentiva a los stakers a elegir clientes menos populares, explica.

Se subraya un riesgo específico relacionado con bugs críticos, como el ejemplo de un “bug de inflación infinita”, que podría comprometer la seguridad de Ethereum. La existencia de múltiples clientes reduce la probabilidad de que un bug afecte a toda la red, ya que en caso de detectarse un problema, la mayoría de los usuarios podría optar por una cadena alternativa sin la transacción defectuosa.

El rol de los grandes pools

En su mensaje en la red social X, cygaar destaca que la gran mayoría de los nodos usan geth actualmente, incluyendo los pools de staking más grandes, como son Lido, Coinbase, Binance y Kraken. Por cierto, también se ha alertado sobre la centralización del staking en estos pocos pools, como se ha reportado en CriptoNoticias.

En el otro extremo de la balanza están pools como RocketPool y StakeWise, con un nivel saludable de variación de clientes, de los cuales alrededor del 42% corresponde a geth. Algo similar ocurre en la capa de consenso de Ethereum, donde el 39% de los nodos usa Prysm, el 32% emplea Lighthouse y el 18% recurre a Tiku.

Otras redes no están exentas de este problema. Por ejemplo, es el caso de Bitcoin, red de la principal criptomoneda del mercado, donde una abrumadora mayoría de nodos ejecutan Bitcoin Core (en distintas versiones) por sobre otras alternativas, como Bitcoin Knots o BTCD.