From cec2fd43b13b5ec8d5e2f1970273e80ab12cf944 Mon Sep 17 00:00:00 2001 From: Navie Chan Date: Wed, 22 May 2024 23:08:05 +0300 Subject: [PATCH 1/2] Add grandine --- docs/pages/introduction.md | 3 ++- packages/beacon-node/src/monitoring/clientStats.ts | 2 +- packages/beacon-node/src/network/peers/client.ts | 2 ++ packages/beacon-node/test/unit/network/peers/client.test.ts | 5 +++++ 4 files changed, 10 insertions(+), 2 deletions(-) diff --git a/docs/pages/introduction.md b/docs/pages/introduction.md index 12b00dacf0a5..ab864b8a9df8 100644 --- a/docs/pages/introduction.md +++ b/docs/pages/introduction.md @@ -15,12 +15,13 @@ In an effort to promote client diversity there are several beacon-nodes being de - [Lighthouse](https://lighthouse.sigmaprime.io/) - [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) - [Nimbus](https://nimbus.team/) +- [Grandine](https://grandine.io) ## Why Client Diversity? The Ethereum network's robustness is significantly enhanced by its client diversity, whereby multiple, independently-developed clients conforming to a common specification facilitate seamless interaction and function equivalently across nodes. This client variety not only fosters a rich ecosystem but also provides a buffer against network-wide issues stemming from bugs or malicious attacks targeted at particular clients. For instance, during the Shanghai denial-of-service attack in 2016, the diversified client structure enabled the network to withstand the assault, underscoring the resilience afforded by multiple client configurations. -On the consensus layer, client distribution is crucial for maintaining network integrity and finality, ensuring transactions are irreversible once validated. A balanced spread of nodes across various clients helps mitigate risks associated with potential bugs or attacks that could, in extreme cases, derail the consensus process or lead to incorrect chain splits, thereby jeopardizing the network's stability and trust. While the data suggests a dominance of Prysm client on the consensus layer, efforts are ongoing to promote a more even distribution among others like Lighthouse, Teku, and Nimbus. Encouraging the adoption of minority clients, bolstering their documentation, and leveraging real-time client diversity dashboards are among the strategies being employed to enhance client diversity, which in turn fortifies the Ethereum consensus layer against adversities and fosters a healthier decentralized network ecosystem. +On the consensus layer, client distribution is crucial for maintaining network integrity and finality, ensuring transactions are irreversible once validated. A balanced spread of nodes across various clients helps mitigate risks associated with potential bugs or attacks that could, in extreme cases, derail the consensus process or lead to incorrect chain splits, thereby jeopardizing the network's stability and trust. While the data suggests a dominance of Prysm client on the consensus layer, efforts are ongoing to promote a more even distribution among others like Lighthouse, Teku, Nimbus and Grandine. Encouraging the adoption of minority clients, bolstering their documentation, and leveraging real-time client diversity dashboards are among the strategies being employed to enhance client diversity, which in turn fortifies the Ethereum consensus layer against adversities and fosters a healthier decentralized network ecosystem. The non-finality event in May 2023 on the Ethereum network posed a significant challenge. The issue arose from attestations for a fork, which necessitated state replays to validate the attestations, causing a notable strain on system resources. As a result, nodes fell out of sync, which deterred the accurate tracking of the actual head of the chain. This situation was exacerbated by a decline in attestations during specific epochs, further hampering the consensus mechanism. The Lodestar team noticed late attestations several weeks prior to the event and implemented a feature that attempted to address such challenges by not processing untimely attestations, and thus not requiring expensive state replays​. While it was done for slightly different reasons, the result was the same. Lodestar was able to follow the chain correctly and helped to stabilize the network. This example underscored the importance of client diversity and network resilience against potential forks and replay attacks. These are considered realistic threats, especially in the context of system complexity like in Ethereum's consensus mechanism. diff --git a/packages/beacon-node/src/monitoring/clientStats.ts b/packages/beacon-node/src/monitoring/clientStats.ts index 185d03428c8c..fe512bf0d71f 100644 --- a/packages/beacon-node/src/monitoring/clientStats.ts +++ b/packages/beacon-node/src/monitoring/clientStats.ts @@ -66,7 +66,7 @@ function createProcessStats(process: ProcessType): ClientStats { clientName: new StaticProperty({ jsonKey: "client_name", value: CLIENT_NAME, - description: "Name of client, e.g. lodestar, prysm, lighthouse, teku, nimbus", + description: "Name of client, e.g. lodestar, prysm, lighthouse, teku, nimbus, grandine", }), clientVersion: new MetricProperty({ jsonKey: "client_version", diff --git a/packages/beacon-node/src/network/peers/client.ts b/packages/beacon-node/src/network/peers/client.ts index 4b84233f6833..5674bee82000 100644 --- a/packages/beacon-node/src/network/peers/client.ts +++ b/packages/beacon-node/src/network/peers/client.ts @@ -4,6 +4,7 @@ export enum ClientKind { Teku = "Teku", Prysm = "Prysm", Lodestar = "Lodestar", + Grandine = "Grandine", Unknown = "Unknown", } @@ -21,6 +22,7 @@ export function getKnownClientFromAgentVersion(agentVersion: string): ClientKind if (agentLC === "teku") return ClientKind.Teku; if (agentLC === "prysm") return ClientKind.Prysm; if (agentLC === "nimbus") return ClientKind.Nimbus; + if (agentLC === "grandine") return ClientKind.Grandine; if (agentLC === "lodestar" || agentLC === "js-libp2p") return ClientKind.Lodestar; return null; diff --git a/packages/beacon-node/test/unit/network/peers/client.test.ts b/packages/beacon-node/test/unit/network/peers/client.test.ts index a179d42157cd..44d16ad4bb8f 100644 --- a/packages/beacon-node/test/unit/network/peers/client.test.ts +++ b/packages/beacon-node/test/unit/network/peers/client.test.ts @@ -28,6 +28,11 @@ describe("clientFromAgentVersion", () => { agentVersion: "js-libp2p/0.32.4", client: ClientKind.Lodestar, }, + { + name: "grandine", + agentVersion: "Grandine/0.4.1-537713d/arm-linux", + client: ClientKind.Grandine, + }, { name: "unknown client", agentVersion: "strange-client-agent-version", From 5d208bf3f55cdf8d70b4d4a31a48d1a1abdb1381 Mon Sep 17 00:00:00 2001 From: Navie Chan Date: Thu, 23 May 2024 11:23:09 +0300 Subject: [PATCH 2/2] add grandine to wordlist --- .wordlist.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/.wordlist.txt b/.wordlist.txt index ec14a5fc7886..3af9d860c6d4 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -41,6 +41,7 @@ Geth Github Gossipsub Grafana +Grandine HTTPS HackMD Homebrew