Passons à la question de la mise à l’échelle.
Deux grands axes sont à distinguer : le court terme et le long terme.
J’ai déjà traité la mise à l’échelle à court terme ailleurs. En résumé :
Les listes d’accès au niveau des blocs (attendues avec Glamsterdam) permettent de vérifier les blocs en parallèle.
ePBS (également prévu lors de Glamsterdam) introduit plusieurs fonctionnalités, dont l’une permet d’utiliser en toute sécurité une part importante de chaque slot (et non plus seulement quelques centaines de millisecondes) pour la vérification d’un bloc.
Les réajustements du gas garantissent que le coût des opérations reflète le temps réel d’exécution (ainsi que les autres ressources mobilisées). Nous explorons aussi le gas multidimensionnel, qui permet de plafonner différemment chaque ressource. Ces deux approches autorisent l’utilisation d’une plus grande part d’un slot pour vérifier les blocs, sans craindre les cas exceptionnels.
Un plan de déploiement progressif est prévu pour le gas multidimensionnel.
Dès Glamsterdam, nous dissocions les coûts de « création d’état » des coûts d’« exécution et calldata ». Aujourd’hui, un SSTORE qui passe d’une valeur non nulle à une autre coûte 5 000 gas, alors qu’un SSTORE qui passe de zéro à une valeur non nulle coûte 20 000. L’un des réajustements de Glamsterdam augmente fortement ce différentiel (par exemple à 60 000) ; cette évolution, combinée à une hausse de la limite de gas, vise à accroître la capacité d’exécution bien au-delà de la capacité de stockage d’état, pour des raisons déjà détaillées (
https://
ethresear.ch/t/hyper-scalin
g-state-by-creating-new-forms-of-state/24052
). Ainsi, à Glamsterdam, ce SSTORE facturera 5 000 gas « classique » et (par exemple) 55 000 gas de « création d’état ».
Le gas de création d’état ne sera PAS intégré au plafond d’environ 16 millions de gas par transaction, ce qui rendra possible la création de contrats plus volumineux qu’actuellement.
Une difficulté se pose : comment gérer cela dans l’EVM ? Les opcodes EVM (GAS, CALL, etc.) reposent tous sur une seule dimension. Voici notre solution. Nous maintenons deux invariants :
Si vous faites un appel avec X gas, cet appel disposera de X gas utilisables pour le « gas classique », la « création d’état » ou d’autres dimensions futures
Si vous interrogez l’opcode GAS, il indique Y gas disponibles, puis vous effectuez un appel avec X gas, il vous reste au moins Y-X gas, utilisables pour toute fonction, après l’appel pour d’éventuelles opérations ultérieures
Concrètement, nous créons N+1 « dimensions » de gas, avec par défaut N=1 (création d’état), et une dimension supplémentaire appelée « réservoir ». L’EVM consomme d’abord les dimensions spécialisées si possible, sinon elle utilise le réservoir. Par exemple, avec (100 000 gas création d’état, 100 000 réservoir), si vous utilisez SSTORE pour créer un nouvel état trois fois, le solde évolue ainsi : (100 000, 100 000) -> (45 000, 95 000) -> (0, 80 000) -> (0, 20 000). L’opcode GAS retourne le réservoir. CALL transmet la quantité de gas spécifiée depuis le réservoir, ainsi que tout le gas non réservoir.
Par la suite, nous passerons à une tarification multidimensionnelle, chaque dimension pouvant avoir un prix du gas flottant distinct. Cela apporte une viabilité économique durable et optimale (voir
https://
vitalik.eth.limo/general/2024/0
5/09/multidim.html
). Le mécanisme du réservoir résout le problème des sous-appels évoqué à la fin de cet article.
Pour la mise à l’échelle à long terme, deux axes : ZK-EVM et les blobs.
Côté blobs, l’objectif est de poursuivre les itérations sur PeerDAS pour atteindre, à terme, un système capable de traiter environ 8 Mo/s de données. Cela suffirait aux besoins d’Ethereum, sans ambition de devenir une couche mondiale de données. Actuellement, les blobs servent aux L2. À l’avenir, les données de blocs Ethereum devraient être injectées directement dans les blobs. C’est indispensable pour permettre à quiconque de valider une chaîne Ethereum hyper-scalée sans devoir la télécharger ni la réexécuter : les ZK-SNARKs éliminent le besoin de réexécution, et PeerDAS sur les blobs permet de vérifier la disponibilité sans téléchargement individuel.
Pour ZK-EVM, l’enjeu est d’accroître progressivement notre niveau de confiance dans son usage :
Des clients permettant de participer comme attesteur via ZK-EVM existeront en 2026. Ils ne seront pas assez sûrs pour que le réseau fonctionne entièrement dessus, mais par exemple, 5 % du réseau pourra s’y appuyer. (Si le ZK-EVM échoue, vous ne serez pas slashed, vous risquerez seulement de bâtir sur un bloc invalide et de perdre du revenu)
En 2027, nous recommanderons à une minorité plus large du réseau d’utiliser ZK-EVM, tout en concentrant les efforts sur la vérification formelle, la sécurisation maximale, etc. Même 20 % du réseau sur ZK-EVM permettrait d’augmenter fortement la limite de gas, car cela ouvre une voie peu coûteuse pour les validateurs solo, qui pèsent de toute façon moins de 20 %.
Une fois prêts, nous passerons à une preuve obligatoire 3-sur-5 : pour qu’un bloc soit valide, il devra contenir 3 preuves sur 5 issues de systèmes de preuve différents. À ce stade, tous les nœuds (sauf ceux qui nécessitent de l’indexation) devraient s’appuyer sur les preuves ZK-EVM.
Poursuivre l’amélioration du ZK-EVM et le rendre aussi robuste et certifié formellement que possible. Cela inclura aussi toute évolution de la VM (par exemple RISC-V).
Avertissement :
- Cet article est reproduit à partir de [vitalikbuterin]. Tous droits d’auteur réservés à l’auteur original [vitalikbuterin]. Pour toute objection à cette republication, veuillez contacter l’équipe Gate Learn, qui traitera la demande dans les meilleurs délais.
- Clause de non-responsabilité : Les opinions exprimées dans cet article n’engagent que leur auteur et ne constituent en aucun cas un conseil en investissement.
- Les traductions de l’article dans d’autres langues sont assurées par l’équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.
