Ethereum dévoile sa feuille de route pour la mise à l'échelle. Qu'est-ce qui est différent cette fois-ci ?

Auteur original : @VitalikButerin
Traduction : Peggy, BlockBeats

Note de la rédaction : Alors que l'écosystème Ethereum continue de se développer, parvenir à une évolutivité du réseau sans sacrifier la sécurité et la décentralisation est devenu un enjeu central. Dans cet article, Vitalik Buterin décrit plus en détail la voie vers la scalabilité d'Ethereum : à court terme, améliorer l'efficacité d'exécution grâce à l'optimisation du mécanisme Gas, la parallélisation de la validation des blocs et d'autres mises à niveau techniques ; à long terme, s'appuyer sur ZK-EVM et la structure de données blobs pour favoriser la scalabilité du réseau.

Dans l'ensemble, cette feuille de route fournit un plan d'évolutivité par étapes conçu pour jeter les bases permettant à Ethereum d'étendre continuellement la capacité de son réseau dans les années à venir.

Voici le texte original :

Parlons maintenant de la mise à l'échelle. Il peut être divisé en deux parties principales : le dimensionnement à court terme et le dimensionnement à long terme.

Mise à l'échelle à court terme

En ce qui concerne la mise à l'échelle à court terme, j'ai déjà écrit à ce sujet ailleurs. L'idée centrale est à peu près la suivante :

· Les listes d'accès au niveau des blocs (qui seront introduites dans la mise à niveau Glamsterdam) peuvent permettre la parallélisation de la validation des blocs.

· ePBS (qui sera également introduit dans Glamsterdam) dispose de multiples fonctionnalités, dont l'une est la suivante : il nous permet d'utiliser en toute sécurité une plus grande partie du temps disponible dans chaque créneau pour valider les blocs, au lieu de n'utiliser que quelques centaines de millisecondes comme c'est le cas actuellement.

· La réévaluation du prix du gaz garantira que le coût du gaz pour diverses opérations reste cohérent avec leur durée d'exécution réelle (et les autres coûts qu'elles engendrent). Nous commençons également à explorer un mécanisme multidimensionnel de gaz, permettant à différentes ressources d'avoir des limites distinctes. La combinaison de ces deux éléments nous permet d'utiliser une plus grande partie du temps alloué à la validation des blocs sans nous soucier des scénarios extrêmes.

En ce qui concerne le gaz multidimensionnel, nous avons établi une feuille de route par étapes. La première phase concerne la mise à niveau Glamsterdam, où le « coût de configuration de l'état » est séparé des « coûts d'exécution et de données d'appel ».

Par exemple, actuellement : une opération SSTORE coûte 5000 gaz si l'emplacement de stockage passe de non nul → non nul ; elle coûte 20000 gaz s'il passe de zéro → non nul.

Lors d'un événement de réévaluation du prix du gaz à Glamsterdam, ce coût supplémentaire sera considérablement augmenté (par exemple, porté à 60 000). L'objectif est d'augmenter le coût tout en rendant le taux d'expansion de la capacité d'exécution nettement supérieur au taux d'expansion de la taille de l'état.

En ce qui concerne les raisons, j'ai déjà écrit à ce sujet : https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

Par conséquent, à Glamsterdam : Cette opération SSTORE consommera 5 000 « gaz de base », soit 55 000 « gaz de création d'état ».

Il est important de noter : Le gaz utilisé pour créer un état n'est pas pris en compte dans la limite d'environ 16 millions de gaz de transaction.

Cela signifie : Il sera désormais possible de créer des contrats plus importants qu'aujourd'hui.

Comment le gaz multidimensionnel est-il obtenu dans l'EVM ?

Voici un problème : La conception de l'EVM part du principe que le gaz n'a qu'une seule dimension ; par exemple, les opcodes GAS, CALL et autres sont tous basés sur cette hypothèse.

Notre solution consiste à maintenir deux invariants :

Si vous lancez un appel avec X gaz, cet appel disposera de X gaz pour les « opérations de base », la « création d'état » ou toute dimension supplémentaire potentielle future.

Si l'opcode GAS vous indique que vous disposez actuellement de Y gaz, et que vous lancez ensuite un appel qui consomme X gaz, après le retour de l'appel, vous disposez toujours d'au moins Y − X gaz pour les opérations suivantes.

La mise en œuvre spécifique est la suivante : Nous introduisons les dimensions N+1 du gaz. Par défaut, N = 1 (création d'état), et la dimension supplémentaire est appelée réservoir.

La logique d'exécution de l'EVM est la suivante :

Si possible, privilégiez la consommation de gaz provenant de dimensions spécialisées.

Si cela ne suffit pas, consommez à partir du réservoir.

Par exemple, si vous avez : (100 000 gaz créé par l'État, 100 000 réservoir)

Si vous utilisez SSTORE pour créer trois nouveaux états, le processus de transformation du gaz est le suivant : (100 000, 100 000) → (45 000, 95 000) → (0, 80 000) → (0, 20 000)

Dans cette conception :

L'opcode GAS renvoie le réservoir.

CALL transmettra une quantité spécifiée de gaz provenant du réservoir et tout le gaz ne provenant pas du réservoir.

Tarification multidimensionnelle du gaz

Plus tard, nous présenterons plus en détail la tarification multidimensionnelle, qui permet d'appliquer des prix du gaz variables en fonction des différentes dimensions des ressources.

Cela apportera :

Meilleure viabilité économique à long terme

Efficacité optimisée de l'allocation des ressources

Pour en savoir plus, rendez-vous sur : https://vitalik.eth.limo/general/2024/05/09/multidim.html

Le mécanisme de réservoir résout parfaitement le problème des sous-appels mentionné à la fin de cet article.

Évolutivité à long terme

La mise à l'échelle à long terme implique principalement deux directions : ZK-EVM et Blobs.

Taches

Pour les blobs, nous prévoyons de continuer à itérer sur PeerDAS, dans le but d'atteindre à terme un débit de données d'environ 8 Mo/seconde.

Cette échelle :

Est suffisant pour répondre aux besoins propres d'Ethereum

Et n'est pas destiné à devenir une « couche de données mondiale ».

Actuellement, les blobs sont principalement utilisés pour L2. Le projet futur consiste à écrire directement les données des blocs Ethereum dans des blobs.

Le but est de permettre aux utilisateurs de valider un réseau Ethereum hautement évolutif sans avoir à télécharger et réexécuter l'intégralité de la chaîne :

Les ZK-SNARK éliminent la nécessité d'une réexécution.

PeerDAS + blobs permettent de vérifier la disponibilité des données sans télécharger toutes les données.

ZK-EVM

Pour ZK-EVM, notre objectif est d'augmenter progressivement la dépendance du réseau à son égard.

2026 : Des clients prenant en charge ZK-EVM feront leur apparition, permettant aux nœuds de participer à l'attestation avec ZK-EVM. Cependant, ils ne sont pas encore suffisamment sécurisés pour permettre à l'ensemble du réseau de dépendre d'eux pour fonctionner. Néanmoins, il est acceptable qu'environ 5 % du réseau les utilise. (Si vous rencontrez des problèmes avec ZK-EVM, vous ne serez pas pénalisé par une réduction, mais vous risquez de construire sur des blocs invalides, ce qui entraînera une perte de revenus.)

2027 : Nous commencerons à recommander une plus grande proportion de nœuds pour exécuter ZK-EVM, tout en nous concentrant sur la vérification formelle et les améliorations en matière de sécurité. Même si seulement 20 % du réseau utilise ZK-EVM, nous pouvons augmenter considérablement la limite de gaz, car cela offre un moyen de validation peu coûteux pour les stakers individuels, et la proportion de stakers individuels est inférieure à 20 %.

Maturité post-technique : Nous allons introduire un mécanisme de preuve obligatoire 3 sur 5. Autrement dit, un bloc doit contenir au moins 3 preuves provenant de 5 systèmes de preuve différents pour être considéré comme valide. D'ici là, nous prévoyons que la plupart des nœuds s'appuieront sur les preuves ZK-EVM, à l'exception des nœuds qui doivent effectuer un indexage.

À long terme : Continuer à améliorer ZK-EVM afin de le rendre plus robuste et de le soumettre à une vérification formelle plus stricte. Cette étape peut également impliquer des changements au niveau de la machine virtuelle, comme l'orientation de RISC-V.

Voir : https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

[Lien vers l'article original]