Saltar al contenido principal
Change page

Diversidad de clientes

El comportamiento de un nodo de Ethereum está controlado por el software de cliente que ejecuta. Existen varios clientes de Ethereum a nivel de producción, cada uno desarrollado y mantenido en diferentes lenguajes por equipos separados. Los clientes se construyen según una especificación común que garantiza que se comuniquen entre sí sin problemas, tengan la misma funcionalidad y proporcionen una experiencia de usuario equivalente. Sin embargo, en este momento la distribución de clientes entre los nodos no es lo suficientemente equitativa como para aprovechar al máximo el potencial de esta fortificación de la red. Idealmente, los usuarios se dividen de manera más o menos equitativa entre los distintos clientes para aportar la mayor diversidad de clientes posible a la red.

Requisitos previos

Si aún no comprende qué son los nodos y los clientes, consulte nodos y clientes. Las capas de y se definen en el glosario.

¿Por qué hay múltiples clientes?

Existen múltiples clientes desarrollados y mantenidos de forma independiente porque la diversidad de clientes hace que la red sea más resistente a ataques y errores. Tener múltiples clientes es una fortaleza exclusiva de Ethereum; otras cadenas de bloques dependen de la infalibilidad de un solo cliente. Sin embargo, no basta con tener múltiples clientes disponibles, la comunidad debe adoptarlos y los nodos activos totales deben distribuirse de manera relativamente uniforme entre ellos.

¿Por qué es importante la diversidad de clientes?

Tener muchos clientes desarrollados y mantenidos de forma independiente es vital para la salud de una red descentralizada. Exploremos las razones.

Errores

Un error en un cliente individual representa un riesgo menor para la red cuando este representa a una minoría de los nodos de Ethereum. Con una distribución de nodos más o menos uniforme entre muchos clientes, la probabilidad de que la mayoría de los clientes sufran un problema compartido es pequeña y, como resultado, la red es más robusta.

Resistencia a los ataques

La diversidad de clientes también ofrece resistencia a los ataques. Por ejemplo, es poco probable que un ataque que engañe a un cliente en particular (opens in a new tab) para que siga una rama específica de la cadena tenga éxito, porque es poco probable que otros clientes sean explotables de la misma manera y la cadena canónica permanece incorrupta. La baja diversidad de clientes aumenta el riesgo asociado con un hackeo al cliente dominante. La diversidad de clientes ya ha demostrado ser una defensa importante contra ataques maliciosos en la red; por ejemplo, el ataque de denegación de servicio de Shanghái en 2016 fue posible porque los atacantes lograron engañar al cliente dominante (Geth) para que ejecutara una operación lenta de entrada/salida de disco decenas de miles de veces por bloque. Debido a que también había clientes alternativos en línea que no compartían la vulnerabilidad, Ethereum pudo resistir el ataque y continuar operando mientras se solucionaba la vulnerabilidad en Geth.

Finalidad de la prueba de participación (PoS)

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 alcance la finalidad, lo que significa que los usuarios no podrían confiar en que las transacciones no se revertirían o cambiarían en algún momento. Esto sería muy problemático para muchas de las aplicaciones construidas sobre Ethereum, particularmente para las finanzas descentralizadas (DeFi).

Peor aún, un error crítico en un cliente con una mayoría de dos tercios podría causar que la cadena se divida y finalice incorrectamente, lo que llevaría a un gran conjunto de validadores a quedarse atascados en una cadena no válida. Si desean volver a unirse a la cadena correcta, estos validadores se enfrentan a un recorte o a un retiro voluntario y reactivación lentos y costosos. La magnitud de un recorte aumenta proporcionalmente con el número de nodos culpables, siendo penalizada al máximo (32 ETH) una mayoría de dos tercios.

Aunque estos son escenarios poco probables, el ecosistema de Ethereum puede mitigar su riesgo equilibrando la distribución de clientes entre los nodos activos. Idealmente, ningún cliente de consenso alcanzaría jamás una participación del 33% del total de nodos.

Responsabilidad compartida

También hay un costo humano al tener clientes mayoritarios. Pone una tensión y responsabilidad excesivas sobre un pequeño equipo de desarrollo. Cuanto menor sea la diversidad de clientes, mayor será la carga de responsabilidad para los desarrolladores que mantienen el cliente mayoritario. Distribuir esta responsabilidad entre múltiples equipos es bueno tanto para la salud de la red de nodos de Ethereum como para su red de personas.

Diversidad de clientes actual

Clientes de ejecución

Clientes de consenso

Este diagrama puede estar desactualizado; visite ethernodes.org (opens in a new tab) y clientdiversity.org (opens in a new tab) para obtener información actualizada.

Los dos gráficos circulares anteriores muestran instantáneas de la diversidad de clientes actual para las capas de ejecución y consenso (al momento de escribir este artículo en octubre de 2025). La diversidad de clientes ha mejorado a lo largo de los años, y la capa de ejecución ha visto una reducción en el dominio de Geth (opens in a new tab), con Nethermind (opens in a new tab) en un cercano segundo lugar, Besu (opens in a new tab) en tercero y Erigon (opens in a new tab) en cuarto, con otros clientes que comprenden menos del 3% de la red. El cliente más utilizado en la capa de consenso, Lighthouse (opens in a new tab), está bastante cerca del segundo más utilizado. Prysm (opens in a new tab) y Teku (opens in a new tab) representan ~31% y ~14% respectivamente, y otros clientes rara vez se utilizan.

Los datos de la capa de ejecución se obtuvieron de supermajority.info (opens in a new tab) el 26 de octubre de 2025. Los datos de los clientes de consenso se obtuvieron de Michael Sproul (opens in a new tab). Los datos de los clientes de consenso son más difíciles de obtener porque los clientes de la capa de consenso no siempre tienen rastros inequívocos que puedan usarse para identificarlos. Los datos se generaron utilizando un algoritmo de clasificación que a veces confunde a algunos de los clientes minoritarios (consulte aquí (opens in a new tab) para obtener más detalles). En el diagrama anterior, estas clasificaciones ambiguas se tratan con una etiqueta de uno u otro (por ejemplo, Nimbus/Teku). Sin embargo, está claro que la mayoría de la red está ejecutando Prysm. A pesar de ser solo instantáneas, los valores en el diagrama proporcionan una buena idea general del estado actual de la diversidad de clientes.

Los datos actualizados de diversidad de clientes para la capa de consenso ahora están disponibles en clientdiversity.org (opens in a new tab).

Capa de ejecución

Hasta ahora, la conversación sobre la diversidad de clientes se ha centrado principalmente en la capa de consenso. Sin embargo, el cliente de ejecución Geth (opens in a new tab) representa actualmente alrededor del 85% de todos los nodos. Este porcentaje es problemático por las mismas razones que para los clientes de consenso. Por ejemplo, un error en Geth que afecte el manejo de transacciones o la construcción de cargas útiles de ejecución podría llevar a que los clientes de consenso finalicen transacciones problemáticas o con errores. Por lo tanto, Ethereum sería más saludable con una distribución más uniforme de clientes de ejecución, idealmente sin que ningún cliente represente más del 33% de la red.

Use un cliente minoritario

Abordar la diversidad de clientes requiere más que usuarios individuales eligiendo clientes minoritarios: requiere que los grupos de validadores e instituciones como las principales aplicaciones descentralizadas (dapps) y los intercambios también cambien de clientes. Sin embargo, todos los usuarios pueden hacer su parte para corregir el desequilibrio actual y normalizar el uso de todo el software de Ethereum disponible. Después de La Fusión, todos los operadores de nodos deberán ejecutar un cliente de ejecución y un cliente de consenso. Elegir combinaciones de los clientes sugeridos a continuación ayudará a aumentar la diversidad de clientes.

Clientes de ejecución

Clientes de consenso

Los usuarios técnicos pueden ayudar a acelerar este proceso escribiendo más tutoriales y documentación para clientes minoritarios y animando a sus compañeros operadores de nodos a migrar lejos de los clientes dominantes. Las guías para cambiar a un cliente de consenso minoritario están disponibles en clientdiversity.org (opens in a new tab).

Paneles de diversidad de clientes

Varios paneles ofrecen estadísticas de diversidad de clientes en tiempo real para la capa de ejecución y de consenso.

Capa de consenso:

Capa de ejecución:

Lecturas adicionales