Comparación de rendimiento del cliente de Ethereum 2.0 mainnet: Lighthouse, Lodestar, etc.

Comparación de todos los clientes disponibles en la red principal Ethereum 2.0 basada en las últimas métricas de rendimiento.

Después del lanzamiento de Ethereum 2.0 Beacon Chain en diciembre de 2020, es hora de presentar y comparar las implementaciones de protocolos existentes. Este artículo, el primero de una serie de artículos, compara el rendimiento del nodo de la cadena de balizas y la utilización de recursos entre 5 clientes principales en orden alfabético.

Faro (Rust, Sigma Prime)

Lodestar (Mecanografiado, ChainSafe Systems)

Nimbus (Nim, Estado)

Prysm (Ir, laboratorios prismáticos)

Teku (Java, ConsenSys Quórum)

La infraestructura de red principal de Ethereum 2.0 consta de tres componentes principales:

La cadena de balizas es una cadena PoS (Prueba de participación). Después de que la cadena Ethereum 1.x actual (el consenso es PoW) se fusionara con Ethereum 2.0, Beacon Chain se convertirá en la columna vertebral de la seguridad de Ethereum.

Los validadores son como mineros en el consenso de PoS. Todos pueden comprometer 32 ETH para convertirse en validadores, tener derecho a proponer nuevos bloques, votar sobre la finalización del bloque y luego ser recompensados.

El slasher está monitoreando validadores en busca de comportamiento malicioso en caso de que ocurra un ataque. Cualquier validador que rompa las reglas es sancionado y eliminado de la red.

Cabe señalar que este artículo se centra principalmente en el primer punto, la cadena de balizas es la base de la red Ethereum 2.0. Los investigadores pueden encontrar todos los scripts, datos y tramas relevantes en Github para un análisis más detallado:

>byz-f/eth2-bench-mainnet

Este artículo destacará estos hallazgos

Métricas de sincronización

La primera y más emocionante pregunta: ¿Cuánto tiempo se tarda en sincronizar la información de los nodos de la cadena de balizas de Ethereum 2.0? Los resultados se muestran en la figura a continuación.

En la tabla anterior, el progreso de la sincronización se compara comparando el tiempo que tardan los clientes en sincronizar la misma ranura. Antes de juzgar los resultados (aunque esto va más allá del alcance de este artículo), hay tres cosas que debemos saber sobre el gráfico.

DEX EvmoSwap, con sede en Evmos, anunció el plan de distribución de lanzamiento aéreo, con un lanzamiento aéreo total de 11,5 millones de EMO: Golden Finance News, DEX EvmoSwap, con sede en Evmos, anunció el plan de distribución de lanzamiento aéreo, un total de 11,5 millones de lanzamientos aéreos de EMO (2,3% del total), y los objetivos de airdrop incluyen los primeros partidarios, los participantes calificados de la red de prueba, la comunidad Evmos y el ecosistema Cosmos (incluidos Osmosis, Juno, SecretNetwork, la comunidad Terra). Entre ellos, 1 millón de EMO para los primeros seguidores de la comunidad, 500 000 EMO para los participantes calificados de la red de prueba y 5 millones de EMO para los proveedores de liquidez temprana de EvmoSwap, mientras que los estándares de airdrop y el tiempo de instantánea para la comunidad de Evmos y el ecosistema de Cosmos están por determinarse y votarse. por decisión de la comunidad, en breve se hará un anuncio sobre los métodos de distribución y reclamación. [2022/4/28 2:35:20]

1. Lo especial de Prysm (línea morada) es que se conectará a los nodos Ethereum 1.x, obtendrá todos los depósitos ETH del registro de información del validador y luego construirá la génesis Eth2 desde el estado Eth1. Si bien esta función es útil desde el punto de vista de la seguridad, dado que los usuarios no tienen que confiar en los desarrolladores de Prysm para obtener el estado de génesis correcto, el proceso lleva algún tiempo. Como resultado, existe una diferencia de tiempo significativa entre el inicio del cliente y el inicio de la sincronización. (#8209).

2. Lodestar (línea gris) se bloqueó durante la evaluación comparativa debido a un problema de falta de memoria del montón de JavaScript (n.º 2005). Sin embargo, el script lo reinicia automáticamente después de 10 segundos.

3. Invisible: en la sincronización inicial, Loderstar no ha verificado completamente todas las firmas (#1217). Por lo tanto, no está claro cómo se compara Loderstar con otros clientes.

En el gráfico anterior, podemos ver que Lighthouse (línea naranja) hace un buen trabajo en general, y Prysm, Teku (línea verde) y Nimbus (línea azul) son excelentes para mantener la velocidad. Pero echemos otro vistazo a la siguiente tabla:

En este diagrama, eliminamos el desfase de tiempo entre el inicio del cliente de Prysm y el inicio de la sincronización (es decir, la generación del primer bloque de la cadena de balizas). Se puede ver que, si simplemente comparamos la velocidad de sincronización, Prysm funciona ligeramente mejor que Lighthouse, y puede sincronizarse en menos de dos horas, mientras que Lighthouse tarda dos horas y media. Teku y Nimbus tardan unas cinco horas.

Snowden: los capitalistas de riesgo deberían promover las criptomonedas para que se conviertan en un estándar global en lugar de adquirir empresas de pago para aceptar pagos encriptados: Golden Finance informó que Edward Snowden (Edward Snowden) dijo en Twitter que los capitalistas de riesgo deberían seguir aumentando Invertir en hacer de las criptomonedas un estándar global, en su lugar de simplemente comprar empresas de sistemas de pago y luego hacer que las cajas registradoras y las aplicaciones más comunes del mercado admitan pagos encriptados de forma predeterminada, la empresa de pagos Square y el fundador de Twitter, Jack Dorsey, retuitearon este tuit y dijeron: La respuesta decía que era exactamente correcta. [2021/10/24 6:10:24]

Vale la pena señalar que la implementación de Eth2 TypeScript (el lenguaje utilizado por Lodestar) no solo pretende ser el cliente elegido para ejecutar una cadena completa de balizas o nodos de validación. En cambio, Lodestar proporcionará la infraestructura para todos los componentes web, de navegador y basados ​​en complementos de las aplicaciones descentralizadas de Ethereum 2.0.

Suponiendo que conocemos la altura de ranura actual del bloque de encabezado de baliza del cliente y podemos verificar la altura del encabezado de bloque antes de estos 60 segundos, podemos mostrar la cantidad de ranuras sincronizadas por cada cliente por segundo (indicado por puntos), para calcular un media móvil de los últimos 60 segundos para comparar las velocidades de sincronización entre los clientes. Los promedios móviles de más de 10 minutos se indican con una línea continua.

Los resultados son consistentes con el gráfico anterior. Aunque Prysm es el cliente más rápido para sincronizar a 60 ranuras por segundo debido al tiempo que lleva obtener el estado Eth1. Lighthouse es un segundo cercano, sincronizando 46 ranuras por segundo. Ligeramente por detrás están Teku (23/seg) y Nimbus (22/seg).

Pero, ¿qué es una ranura? En las cadenas de bloques tradicionales, como las cadenas Bitcoin y Eth1, hay bloques o no hay bloques. Luego, al comparar el rendimiento del cliente en estas cadenas, comparamos sus velocidades de sincronización en bloques por segundo. ¿En qué se diferencia esto de tomar ranuras/segundo como una unidad?

En Ethereum 2.0, siempre hay un espacio designado cada 12 segundos. Si se asigna un validador para proponer un bloque en un slot, ese slot tiene un bloque. Sin embargo, si el validador pierde la ranura, entonces es una ranura vacía (sin bloque), pero el conteo de ranuras continuará a pesar de esto. Por lo tanto, en Ethereum 2.0 calculamos la velocidad de sincronización en unidades de slots/segundo.

En este gráfico, eliminamos la variable (tiempo), la abscisa es el número de ranuras que se han sincronizado y asignamos la velocidad de sincronización en el gráfico anterior a este gráfico. Todos los clientes muestran una tendencia: a medida que aumenta la ranura, la velocidad de sincronización disminuye. Dado que estos datos se recopilaron en la red principal de Ethereum 2.0, sabemos que hay una cola de validadores esperando para unirse a la red 2.0. Al momento de escribir, hay 13_458 validadores en la cola de espera, que son casi 15 días a una tasa de 900 validadores nuevos por día.

Sabiendo que la cantidad de validadores en la red principal de Ethereum 2.0 crece linealmente, podemos suponer que el mayor conjunto de validadores activos hace que la sincronización sea más lenta.

Métricas de recursos informáticos

En la primera mitad, solo analizamos las métricas de sincronización y seleccionamos los clientes de sincronización más rápidos. Pero, ¿qué cliente es rápido y eficiente en términos de utilización de recursos?

En el gráfico anterior, se compara la capacidad de la base de datos de cada cliente a medida que aumenta el número de ranuras de sincronización. Vale la pena señalar que Lodestar tiene la huella más pequeña con un total de 1,49 GiB para nodos de red principal completamente sincronizados (420_000 ranuras). Los resultados de Lighthouse (2,98 GiB) y Prysm (3,16 GiB) también son buenos.

Sabemos que los nodos Eth1 almacenan datos completos del historial de bloques. No obstante, los nodos Eth1 eliminan el estado histórico para minimizar el espacio en disco necesario para la base de datos. Los nodos Eth2 son comparables a este concepto. Al mismo tiempo que almacenan todos los bloques en el disco, eliminan el estado final. La principal diferencia entre los dos es que los estados históricos deben almacenarse en límites de época por conveniencia. Actualmente, Nimbus almacena el estado en los límites de época cada 32 épocas, mientras que Lodestar registra el estado en el disco cada 1024 épocas. La diferencia se puede ver claramente en la figura.

El gráfico es el mismo, pero traza el tamaño del conjunto de memoria residente de cada cliente durante una sincronización. Según el gráfico, el cliente de Nimbus es muy eficiente y requiere solo alrededor de 1 GiB de RAM para todo el proceso en la red principal de Beacon Chain. Le siguen Lighthouse y Lodestar, ambos con poco menos de 3 GiB.

Nota: La memoria fuera del montón que Java asigna a Teku está fuera del control del desarrollador del cliente. El consumo de memoria disponible de JVM es particularmente grande. Los resultados de las métricas de Teku varían significativamente con la cantidad total de memoria disponible.

Por último, pero no menos importante, veamos la utilización de la CPU. Algunas diferencias interesantes entre los clientes se pueden ver en el gráfico anterior.

Blockchain es una estructura de datos altamente jerárquica. Al sincronizar los datos de la cadena de bloques, validar los bloques y calcular el estado más reciente, la mayor parte del trabajo se realiza en secuencia. Por lo tanto, el desafío para el cliente es paralelizar este proceso tanto como sea posible. Los gráficos muestran resultados que son comparables a las métricas de velocidad de sincronización, con Prysm y Lighthouse a la cabeza (los números más altos significan más eficiente), mientras que Teku se mantiene bien.

Preguntas frecuentes

P: El artículo es bueno, pero ¿por qué no comparaste los indicadores de tráfico?

R: Tengo comparaciones, pero no comento todas las comparaciones de métricas. Puede encontrar métricas de tráfico punto a punto sin comentarios en Github. Para obtener más información, visite: eth2-bench-mainnet/doc/00-plots-uncommented.md

P: ¿Qué cliente recomienda personalmente?

R: Esta pregunta es difícil de responder. Si me dejo llevar por las sensaciones, elijo Lighthouse, creo que su experiencia de usuario en general, rendimiento, funciones y usabilidad de la herramienta son muy buenas. Sin embargo, Prysm sigue siendo el cliente más maduro y actualmente el más rápido. La experiencia con Teku también es muy buena, creo que todos los clientes son de grado de producción.

P: ¿El tamaño de la base de datos de la cadena de balizas superará 1 TiB?

No, en primer lugar, la cadena de balizas en sí es relativamente pequeña en comparación con Eth1. El factor principal que impulsa el tamaño de la base de datos es el estado de la baliza. Sin embargo, a diferencia de Eth1, Eth2 no requiere que todo el estado se almacene en el disco, ya que los usuarios siempre pueden reconstruir cualquier estado a partir de bloques que se ejecutan localmente.

Además, PoS finalizó este proceso, mientras que PoW no lo hizo (reorganizaciones, 51 % de ataque). Una vez que se finaliza un bloque, ese bloque nunca se puede manipular. Finalizado significa que en el futuro, el cliente ya no necesitará sincronizar los datos de la cadena desde el génesis, sino que obtendrá los datos del último jefe de cadena de la época finalizada.

Enlace original:

https://dev.to/q9/ethereum-2-0-mainnet-clients-3and

Fuente | dev.to/q9

Autor | Afri Schoedon

Tags：

Luna