Introducción
En los artículos previos, hemos explorado los fundamentos de los nodos y hemos proporcionado una guía completa para configurar un nodo de Ethereum y Arbitrum desde cero. Además, hemos subrayado la importancia de mantener la diversidad de clientes entre el conjunto de nodos existentes, en lugar de simplemente seguir a los más populares.
Si aún no has tenido la oportunidad de leer esos artículos, te sugerimos que los revises antes de continuar. Esto te permitirá obtener una visión completa y comprensiva de todo el panorama de los nodos de Ethereum.
El funcionamiento de un nodo es controlado por el software del cliente que corre y hay distintos niveles de proveedores desarrollados en distintos lenguajes y por equipos distintos.
En un mundo ideal, la usabilidad de cada cliente es relativamente similar al de cada uno de sus pares, para que la red sea más segura y robusta.
En este artículo tendrás un análisis de cada cliente, y entenderás aún más porque es tan importante la diversidad que mencionamos. Además, esto te permitirá tomar la mejor decisión según tus necesidades y beneficiar con ello a la red.
Comencemos con la siguiente imagen:
Esta representación gráfica refleja la actual diversidad de clientes, indicando que Geth tiene el 83.94% de la participación de nodos de ejecución; mientras que Prysm tiene el 45.41% de los nodos de consenso. Esta información es fundamental para comprender el propósito de este artículo y lo que detallaremos a continuación.
Aclaración: Ten en cuenta que esta información puede no ser correcta al 100% ya que no hay una forma exacta de saber que clientes utiliza cada nodo.
¿Por qué la diversidad de clientes es tan importante?
Ethereum cuenta con varios clientes interoperables desarrollados y mantenidos en diferentes lenguajes por equipos independientes. Esto es un logro significativo y puede proporcionar resiliencia a la red al limitar los efectos de errores o ataques en la parte de la red que utiliza el cliente afectado. Sin embargo, esta fortaleza sólo se materializa si los usuarios se distribuyen de manera aproximadamente uniforme entre los clientes disponibles. En la actualidad, la gran mayoría de los nodos de Ethereum utilizan un solo cliente, lo que representa un riesgo indeseado para la red. La buena noticia, es que este riesgo es perfectamente evitable y mitigable.
Es fundamental saber que la salud de la red se mide por su resiliencia ante ataques y la probabilidad reducida de errores. La presencia de una amplia variedad de clientes es un factor que contribuye a una red más robusta y resistente.
Hay tres tipos de fallos que te ayudarán a entender mejor los riesgos de depender de un solo cliente:
-
Evento masivo de sanciones: Un error provoca que los validadores del cliente con mayor cuota emitan declaraciones sancionables (slashables).
-
Evento masivo de desconexión: Un error lleva a la desconexión de todos los validadores del cliente mayoritario.
-
Evento de bloque inválido: Un error conduce a que todos los validadores con mayor participación emitan declaraciones sobre un bloque inválido.
Existen otros tipos de fallos y sanciones masivas que pueden ocurrir, pero estos están relacionados con errores en el cliente y deben considerarse al elegir qué cliente utilizar.
Por lo tanto, si un cliente experimenta un error y todos los nodos utilizan el mismo cliente, existe el riesgo de comprometer el funcionamiento de TODA la red. Sin embargo, al contar con múltiples clientes, la probabilidad de que todos compartan el mismo error disminuye significativamente. En otras palabras, la diversidad de clientes reduce la probabilidad de que un error afecte a toda la cadena de bloques.
Además, la diversidad de clientes también proporciona una mayor resistencia a los ataques en la red. Si un cliente es atacado, es improbable que los demás clientes sean vulnerables, lo que mantiene segura la cadena canónica.
Tener diversos clientes es como tener una copia de seguridad de tu computadora; si un malware te ataca, tendrás respaldo de tus datos mientras resuelves el problema principal.
La siguiente imagen es un caso ejemplo de lo que sucedería si un solo cliente tuviera un bug y los demás siguieran funcionando correctamente, manteniendo a salvo la red.
Es CRUCIAL que ningún cliente tenga una cuota superior al 33%.
Un error en un cliente de consenso con más del 33% de los nodos de Ethereum podría impedir que la capa de consenso funcione correctamente y alcance el nivel de finalización, lo que significa que los usuarios no podrían tener certeza en que las transacciones no se revertirán o cambiarán en algún momento. Esto es especialmente problemático para muchas de las aplicaciones construidas en Ethereum, principalmente las relacionadas con DeFi.
Peor aún, un error crítico en un cliente con una cuota de dos tercios hará que la cadena se bifurque y termine de manera incorrecta, lo que implica que un gran número de validadores se vean atrapados en una cadena inválida. Si los validadores desean regresar a la cadena correcta, se verán afectados por recortes o por un proceso de retirada y reactivación voluntaria lento y costoso. La magnitud de los recortes aumenta en función del número de nodos culpables, con un máximo de dos tercios de la mayoría (32 ETH) recortados.
Aunque es poco probable que se produzcan estas situaciones, el ecosistema de Ethereum puede mitigar estos riesgos equilibrando la distribución de clientes entre los nodos activos.
En la siguiente imagen, encontrarán un tweet con el siguiente mensaje:
“Alguien falló al intentar atacar Ethereum hoy al publicar 550 bloques que contenian pow’s invalidos.Solo un pequeño porcentaje de clientes de Nethermind (Execution client) se cambiaron a la red inválida. Todos los demás clientes rechazaron la larga sidechain por ser inválida.”
Este es otro ejemplo que ilustra la importancia de la diversidad de clientes para mantener la red en óptimas condiciones.
También, es importante destacar que la implementación de múltiples clientes fomenta una competencia saludable e impulsa la innovación entre los desarrolladores.
Desde cualquier perspectiva, la diversidad de clientes, tanto en los nodos de ejecución como en los de consenso, es algo que todos debemos considerar y promover para lograr una distribución equitativa. El hecho de que G-eth (o go-ethereum) tenga más del 80% de la cuota y Prysm +40% es altamente riesgoso y debería cambiar lo antes posible.
Clientes de la capa de ejecución
Estos clientes desempeñan un papel crucial al escuchar las nuevas transacciones (gossip transactions) transmitidas en la red, ejecutarlas en la EVM y mantener el estado más actualizado junto con la base de datos de todos los datos actuales de Ethereum. Además, todos los clientes ejecutan la API de JSON-RPC, facilitando la comunicación entre las capas de consenso y ejecución.
Besu
Hyperledger Besu es un cliente Ethereum de código abierto desarrollado bajo la licencia Apache 2.0 y escrito en Java. Puede operar en la red pública de Ethereum, en redes privadas con permisos, así como en redes de prueba como Rinkeby, Ropsten y Göerli.
Nethermind
Nethermind es compatible con Linux, Windows y MacOS, y es compatible con Clique, AuRa, Ethash y PoS. Ofrece acceso confiable a datos en cadena con un alto rendimiento a través de JSON-RPC. Su sincronización de alta velocidad permite ponerse al día con la red principal en aproximadamente 3 horas y con una latencia mínima. La disposición de la base de datos plana es una mejora que acelera el procesamiento de transacciones, la ejecución de las máquinas virtuales y las llamadas a la API.
Han comenzado a implementar sus blobs (EIP-4844 Shard Blob Transactions) durante las primeras etapas de la integración de la EIP. Su objetivo es proporcionar un manejo rápido y estable de las transacciones de Shard Blob y un grupo eficiente de transacciones para ellas.
Erigon
Erigon es un fork de Go Ethereum que se enfoca en la velocidad y el ahorro de espacio en disco. Erigon es una implementación completamente reestructurada de Ethereum escrita en Go, aunque los planes futuros incluyen su portabilidad a otros lenguajes. Erigon fue desarrollado con el objetivo de ofrecer una implementación de Ethereum más rápida, modular y mejor optimizada. Este cliente puede completar una sincronización de nodo de archivo completo en menos de tres días con menos de 2 TB de espacio de almacenamiento.
Go-Ethereum
Geth (go-ethereum) es una implementación en Go de Ethereum, es uno de los clientes Ethereum más probados y sólidos. Geth es un cliente de ejecución Ethereum, lo que significa que maneja transacciones, implementa y ejecuta contratos inteligentes y contiene una computadora integrada conocida como la Máquina Virtual de Ethereum (EVM).
RETH
Reth (Rust Ethereum) representa una nueva implementación del nodo de Ethereum enfocada en ofrecer una experiencia amigable para el usuario, además de ser modular, rápida y eficiente. Reth es un EC que garantiza la compatibilidad con todas las implementaciones de clientes de consenso de Ethereum que admiten la Engine API.
Es importante tener en cuenta que Reth se encuentra en constante desarrollo y está sujeto a cambios frecuentes. Para garantizar su seguridad, el equipo detrás de Reth realiza múltiples verificaciones del estado de la Máquina Virtual Ethereum (EVM), realiza sincronizaciones completas de los nodos de manera regular y opera diversos nodos tanto en la red principal de Ethereum como en sus testnets, entre otras medidas.
A continuación verás un cuadro comparativo de los clientes de ejecución para una mayor claridad de sus cualidades.
Clientes de la capa de consenso
El cliente de consenso implementa el algoritmo de consenso de la prueba de participación, lo que permite que la red llegue a un acuerdo basado en datos validados por el cliente de ejecución. También existe una tercera pieza de software conocida como "validador" que se puede agregar al cliente de consenso, lo que permite que un nodo participe en la protección de la red y forme parte de la Beacon Chain.
Nimbus
Nimbus es una implementación de cliente para la capa de consenso y la capa de ejecución de Ethereum que busca ser lo más liviana posible en cuanto a recursos utilizados. Esto le permite tener un buen rendimiento en sistemas integrados y dispositivos como Raspberry Pis y dispositivos móviles. Nimbus se esfuerza por funcionar igual de bien en hardware con recursos limitados que en computadoras de escritorio y servidores.
Lighthouse
Lighthouse es un cliente de consenso Ethereum que está escrito en Rust, un lenguaje de programación rápido y moderno. Su pila se basa en el marco libp2p con importantes adiciones y personalizaciones, y fue diseñada para ser resistente a ataques avanzados de denegación de servicio.
Teku
Teku es un cliente completo de Ethereum escrito en Java y mantenido por el mismo equipo detrás de Besu. Teku está preparado para ofrecer servicios de participación a empresas y ofrece gestión externa de claves para ser compatible con almacenes de claves de grado empresarial. Fue desarrollado por el equipo detrás de Hyperledger Besu, el principal cliente Ethereum para empresas, y ofrece una implementación completa de las API estándar de Ethereum.
Lodestar
Lodestar es un cliente de consenso Ethereum de código abierto escrito en Typescript. Lodestar es un nodo faro de consenso y un cliente validador para la cadena de bloques de Ethereum. Las herramientas y bibliotecas de Lodestar permiten el desarrollo del protocolo Ethereum para el ecosistema de JavaScript. Este cliente está diseñado para ser desplegable y ligero.
Prysm
Prysm es un cliente de Ethereum de PoS escrito en Go. Soporta los SO Linux, Windows y macOS. Prysm se centra en la usabilidad, la seguridad y la confiabilidad. Además de su cliente de consenso, Prysm admite herramientas gRPC, un almacén de clave-valor optimizado y Protocol Labs para una eficiente comunicación entre pares.
¿Por qué entonces los node providers siguen eligiendo un solo cliente?
Algunos usuarios muestran resistencia a cambiar a un cliente minoritario debido a la carga de trabajo adicional que conlleva. Prefieren mantener un sistema que ya funcione, y un cliente minoritario puede presentar más desafíos y contar con menos desarrolladores para respaldarlo o brindar soporte. Estarían más dispuestos a ejecutar otro cliente si hubiera una documentación bien elaborada disponible. Algunos usuarios han considerado la posibilidad de utilizar un cliente minoritario, pero dudan debido a los posibles problemas y están esperando herramientas más eficientes que simplifiquen el proceso.
A pesar de que la diversidad es importante, algunos usuarios priorizan mantener su configuración actual funcionando sin problemas, ya que hay mucho en juego para ellos. Quieren utilizar el cliente más maduro, que funcione de manera óptima y sea altamente estable.
A su vez, el uso intensivo de recursos de RAM también entra en la discusión ya que varios proveedores de nodos optan por clientes que requieran menos RAM para ser ejecutados.
Entonces ¿Qué es lo más importante para los proveedores de nodos a la hora de elegir un cliente?
Por empezar, el equipo de los clientes y el soporte de desarrollo que tienen son los factores más influyentes, seguidos de la disponibilidad de documentación, características específicas y participación en la red.
Los usuarios valoran un cliente que utiliza menos recursos del sistema y tiene una buena documentación, fiabilidad y sincronización rápida. También están interesados en un cliente minoritario que tenga características distintivas, como requisitos de almacenamiento/memoria más bajos, pero desean comprender cualquier compensación que pueda existir. Los costos de cambio son altos, por lo que los usuarios preferirían un cliente que ofrezca un mejor rendimiento, estabilidad, uso de disco o monitoreo en comparación con su cliente actual.
El tiempo de sincronización al cambiar a un nuevo cliente de ejecución es un obstáculo importante que puede llevar a la procrastinación por lo que también lo toman en consideración. Además, a los usuarios les gustaría ver incentivos económicos para ejecutar clientes minoritarios, como también una estandarización en la base de datos e interoperabilidad entre clientes.
Con un esquema de base de datos estándar compartido entre múltiples clientes, se podría permitir que estos cambien automáticamente, continuando la grabación de los bloques, según la diversidad actual. Probablemente esto no sea posible en la práctica, pero si la instalación, configuración y ejecución de clientes fueran más similares, es posible que las personas estén dispuestas a cambiar de un cliente a otro.
Conclusión
En resumen, la elección del cliente Ethereum adecuado es una decisión de suma importancia para aquellos que desean correr su propio nodo en casa. Aunque Geth y Prysm son nombres familiares en el espacio, la diversidad de clientes desempeña un papel crucial en la salud y seguridad de la red Ethereum.
La resistencia a los ataques y la estabilidad de la red se ven reforzadas cuando los usuarios optan por clientes minoritarios como Nethermind y Lodestar. Estos clientes, aunque pueden presentar desafíos, están trabajando incansablemente para mejorar su estandarización, brindar un mayor soporte a los desarrolladores, ofrecer documentación más sólida y reducir su consumo de RAM.
Si valoramos la descentralización y la seguridad de Ethereum, es esencial evitar que exista la dominancia de un solo cliente . Optar por una opción minoritaria contribuye a diversificar la red y a mitigar el riesgo de fallos masivos. Además, al elegir clientes minoritarios, alentamos la competencia y la innovación entre los desarrolladores, lo que en última instancia fortalece todo el ecosistema.
Si bien los clientes minoritarios tienen trabajo por hacer para alcanzar niveles óptimos de soporte, documentación y eficiencia, la comunidad tiene un papel importante en respaldar su desarrollo continuo. Al considerar cuidadosamente su elección de cliente y explorar alternativas más allá de los gigantes conocidos, los usuarios pueden contribuir a una red Ethereum más segura y verdaderamente descentralizada.
En última instancia, la diversidad de clientes es un pilar fundamental para la sostenibilidad y resiliencia de Ethereum, y es tarea de la comunidad asegurar que esta diversidad se mantenga y crezca en el futuro.
Fuentes
-
Ethereum Merge: Run the majority client at your own peril! | Dankrad Feist
-
GitHub - ledgerwatch/erigon: Ethereum implementation on the efficiency frontier
-
https://ethereum-on-arm-documentation.readthedocs.io/en/latest/user-guide/running-l1-clients.html
-
GitHub - ethereum/execution-specs: Specification for the Execution Layer. Tracking network upgrades.
SeedLatam
El ecosistema SEEDLatam tiene el objetivo de promover el conocimiento y el pensamiento crítico sobre la Web3 en América Latina, así como impulsar a los líderes Web3 del futuro. Para lograr esta misión, SEEDLatam trabaja en conjunto con comunidades: creando, alineándose y coordinándose con ellas en la consecución de un objetivo más amplio: la educación en diversas áreas del ecosistema Web3 y generar un mayor impacto positivo en América Latina a través de la participación activa en las gobernanzas de mayor impacto.
Node Team
-
@SeedsPuntoEth — Leader
-
@JuanuMusic — Dev
-
@MateoEmilio1 — Research
-
@iamnicki15 — Research & Comms