Reth accélère le client Ethereum

Reth 2.3.0, publié par Paradigm le 10 juin, apporte une amélioration mesurée des performances de ce client Ethereum écrit en Rust. La note de version indique que le débit de référence passe d’environ 1,4 à 1,5 Ggas/s, soit 8,1 % de mieux, grâce à des optimisations sur l’exécution parallèle, la construction des blocs, les tries (structures de données qui indexent l’état) et le pool de transactions. Ce n’est pas une promesse abstraite de vitesse : c’est une modification de plomberie pour les opérateurs qui fabriquent, relaient ou vérifient des blocs.

L’intérêt tient à la place particulière de Reth dans l’écosystème Ethereum. Un client d’exécution est le logiciel qui applique les transactions, maintient l’état de la chaîne et dialogue avec les clients de consensus. Plus cette couche devient rapide et prévisible, plus elle donne de marge aux validateurs, aux constructeurs de blocs et aux services d’infrastructure. Reth 2.3.0 vise précisément ces zones de friction : insertion moins coûteuse dans le pool de transactions, preuves et chemins de trie plus rapides, réduction du coût de construction des payloads, et corrections de justesse sur eth_simulate, la désérialisation des preuves ou la gestion de RocksDB et MDBX.

La version continue aussi le déploiement des Block Access Lists, ou BAL. Ces listes décrivent à l’avance quelles parties de l’état un bloc va toucher. Dit simplement, elles peuvent aider les clients à préparer le travail au lieu de découvrir tous les accès pendant l’exécution. Reth ajoute ici de la validation BAL, du stockage, du réseau, du RPC et du support côté constructeur de payloads. C’est une brique encore technique, mais elle compte pour la trajectoire d’Ethereum : mieux connaître les accès à l’état peut rendre l’exécution plus parallèle et plus facile à vérifier.

La note de version ne demande pas de migration aux opérateurs qui utilisent les réglages par défaut. Elle prévient en revanche les développeurs de SDK et les équipes avec des intégrations personnalisées autour des payloads, du pool de transactions ou du consensus de vérifier les changements cassants. Le signal est sobre mais important : Ethereum ne gagne pas seulement en capacité par de grands hard forks visibles. Il progresse aussi par ces versions de clients qui rendent l’exécution plus rapide, mieux instrumentée et moins fragile.