Ethereum Core Developer Floats Proposal for Execution Layer Cross-Validation - Unchained

Ethereum Core Developer Floats Proposal for Execution Layer Cross-Validation – Unchained

The solution to Ethereum’s validators slashing penalties could lie in cross-validation, according to a proposal from core developer Péter Szilágyi.

Ethereum Core Developer Floats Proposal for Execution Layer Cross-Validation - Unchained PlatoBlockchain Data Intelligence. Vertical Search. Ai.

Péter Szilágyi shared a proposal aimed at solving for the heavy validator penalties in the event of a consensus fault.

Shutterstock

Posted June 26, 2024 at 5:21 am EST.

Ethereum’s proof-of-stake (PoS) consensus offers economic incentives to participants who stake their ether and operate validators, with the slashing mechanism playing an important role in keeping validators in check.

Validators that engage in dishonest behaviour are penalized by being “slashed” from the network and the proportion of their staked ETH will be destroyed by the network. However, a majority of slashing events that take place are often unintentional.

“Client diversity in Ethereum is exceedingly important due to the aggressive slashing penalties: in case of a consensus error, the more validators are in the wrong, the heavier the penalties are,” wrote Ethereum core developer Péter Szilágyi on GitHub, in a proposal for cross-validation on the execution layer.  

An Ethereum client is an implementation of Ethereum that verifies data against the protocol rules and keeps the network secure, with nodes running consensus clients and an execution client.

Of the five Ethereum execution clients, Geth controls 47.6% and Nethermind controls 34.5% according to data from ethernodes. This means that in a situation where the majority of validators on Geth are in the wrong puts these validators, and the entire networks in a less than ideal risk bracket, according to Szilágyi.

While developers have often stressed for the need to run more than one client side by side, and greater client diversity, Szilágyi acknowledged that it may not always be realistic given the different resource requirements and hidden incompatibilities.

He proposes adding an extra cross-validation step, where the user’s client creates a witness for the block that is executing it, and sends the witness to a variety of other clients. Then, the aggregate results from these clients could be sent to the consensus client.

“Instead of asking people to run a minority client (may be inconvenient), or asking them to run multiple clients (may be expensive); we can let them use whatever client they fancy, and rather only ask them to cross-validate with other clients, statelessly,” said Szilágyi.

Time Stamp:

More from Unchained