Les listes d'accès aux blocs (EIP-7928) vont changer la trajectoire de mise à l'échelle d'Ethereum. Ce n'est pas seulement un éloignement du goulot d'étranglement de mise à l'échelle des vérificateurs lents. Cela ramène la viabilité d'une infrastructure de vérificateur plus simple : Clients non-rust. Bases de données d'état simples. MEV statique.

Non-rust : plus le traitement des blocs est parallèle, plus les langages "lents" deviennent viables à nouveau. Go, Java, Typescript, peut-être même Python pourraient être vus plus souvent. DBs d'état simples : il est difficile d'optimiser l'accès à l'état dans le chemin critique, ce qui est mauvais, pas seulement pour l'évolutivité : actuellement, chaque nouvel outil d'infrastructure est bloqué sur (1) la connexion à un RPC externe ou (2) sa propre implémentation de DB, juste pour maintenir un état à jour. Cela change, sans pipelines de mise à jour d'état personnalisés hors protocole. Les clients uniquement vérificateurs peuvent être écrits avec des DBs stupides-lents, et cela n'aura plus beaucoup d'importance. MEV statique : le temps pour "voir" un changement d'état ne sera pas bloqué par le traitement des transactions dans un nouveau bloc, mais seulement par la réception de la liste d'accès au bloc elle-même. Plus de temps pour rechercher le MEV. Et les pools de transactions de sentinelles deviennent également faciles à synchroniser avec les changements de solde/nonce.

Oui, la construction de blocs elle-même sera toujours intense. Mais les bâtisseurs sont incités à utiliser leurs propres ressources pour le profit de toute façon. Abaisser la barrière à l'entrée pour des déploiements de vérificateurs viables signifie beaucoup pour la prolifération de l'infrastructure ethereum. L'"edge" d'ethereum peut avoir de nombreux nouveaux entrants, de nouvelles intégrations, qui n'étaient pas viables auparavant. Le giga-gaz et un large écosystème de nœuds ne sont pas mutuellement exclusifs.