Vitalik Buterin explore les prochaines étapes de la scalabilité sur Ethereum

Le 13 mars dernier, le hard fork Cancun Deneb a été déployé sur le mainnet d’Ethereum. En pratique, celui-ci a introduit une évolution de taille avec l’arrivée des blobs. Il s’agit d’un nouveau type de stockage plus efficient que les calldatas jusqu’ici utilisé. Cela a entraîné une nette réduction des frais sur les L2. Toutefois, cela ne résout pas pour autant le problème de scalabilité rencontré par l’écosystème d’Ethereum. Face à l’essor des blobscriptions, le débat sur les mesures à adopter pour améliorer la scalabilité du réseau reprend de plus belle.

Vitalik Buterin explore le futur d’Ethereum

Alors qu’ils ont fait leur arrivée sur Ethereum il y a peu, les blobs montrent déjà leurs limites. En effet, ces espaces de stockages dans un premier temps uniquement utilisés par les L2 pour stocker les données des transactions ayant lieu hors chaîne, sont désormais pris d’assaut par les Inscriptions. Hé oui, les mêmes que nous avons déjà pu rencontrer sur Bitcoin en 2023.

Comme l’ont souligné de nombreux observateurs, dont Vitalik Buterin le cofondateur d’Ethereum, les blobs jusqu’ici quasiment gratuit ne le sont plus du fait de cette hausse de l’activité.

« Dans un premier temps, le fork a réduit les frais de transaction des rollups d’un facteur de plus de 100, les blobs étant presque gratuits. Le dernier jour, nous avons enfin vu les blobs augmenter en volume et le marché des frais s’activer lorsque le protocole blobscriptions a commencé à les utiliser. Les blobs ne sont pas gratuits, mais ils restent beaucoup moins chers que les calldata. »

Explique Vitalik Buterin dans sa dernière publication.

Désormais, il va falloir coupler cette solution avec d’autres méthodes, pour améliorer la scalabilité du réseau sur le long terme. Et c’est justement cette question que Vitalik Buterin a explorée dans son article de blog publié le 28 mars.

Pour rappel, Ethereum suit une feuille de route dite rollup-centric. À savoir que les rollups et autres L2 sont les solutions privilégiées pour améliorer la scalabilité du réseau. Pour rappel, ils permettent de déporter une partie des transactions hors de la chaîne principale.

Et dans cette optique, les blobs ne sont qu’une première étape, permettant de résoudre partiellement le problème du stockage des données relatives aux transactions ayant lieu sur les L2.

Le data sampling availability : une solution pour des blobs plus efficaces

Comme nous l’avons brièvement abordé, les blobs permettent de stocker les données des rollups. Avant cela, les L2 utilisaient la partie calldata des transactions.

Bien que les blobs apportent une méthode plus efficace pour ce stockage, ils ne sont pas parfaits. Par exemple, chaque bloc peut contenir au maximum 6 blobs, ce qui engendre des files d’attente au niveau de la mempool pour leur inclusion.

« Un élément clé de la feuille de route centrée sur les rollups était l’idée d’un espace séparé pour la disponibilité des données : une section spéciale de l’espace dans un bloc, à laquelle l’EVM n’aurait pas accès, qui pourrait contenir des données pour les projets de niveau 2 tels que les rollups. »

Désormais, afin d’augmenter la quantité de données dans chaque blobs, le réseau va devoir appliquer une méthode de vérification appelée data sampling availability. Sans trop entrer dans le détail, cela permet à chaque nœud de vérifier que les données ont été correctement publiées en contrôlant uniquement des échantillons (samples) au hasard.

La mise en place de cette méthode sur Ethereum permettrait selon les dires de Buterin d’augmenter l’espace dans les blobs jusqu’à 16 Mo.

PeerDAS : la première étape pour le data sampling availability

Dans son article, Buterin explique que la prochaine étape logique est donc la mise en place de ce mécanisme de data sampling availability.

Cela passera probablement dans un premier temps par le déploiement d’une version simplifiée, appelée PeerDAS.

« Dans PeerDAS, chaque nœud stocke une fraction significative (par exemple, 1/8) de toutes les données blob, et les nœuds maintiennent des connexions avec de nombreux pairs dans le réseau p2p. Lorsqu’un nœud a besoin d’échantillonner un élément de données particulier, il demande à l’un des pairs dont il sait qu’il est responsable du stockage de cet élément. »

Cela permet de réduire la charge sur l’ensemble des nœuds qui se partageront le stockage et n’auront qu’à demander à leurs voisins les données qu’ils ne stockent pas eux-mêmes.

Bien que cela augmente la taille des blobs, les effets positifs ne seront que de courte durée. En effet, cela améliorera la scalabilité des L2 jusqu’à ce que les blobs soient à nouveau pleins atteignant de fait cette nouvelle limite.

Alors il faut trouver d’autres solutions qui viennent se coupler à la data availability sampling. Et pour cela Vitalik Buterin a déjà une idée.

Améliorer l’efficacité des L2

Pour cela, Buterin estime qu’il faut améliorer la manière dont fonctionnent les L2 afin d’optimiser leur fonctionnement. Une fois encore, plusieurs pistes coexistent pour arriver à ce  résultat.

Compression des données

Une première méthode réside dans la compression des données. En effet, si l’on arrive à compresser les données créées par les L2, cela permettrait de réduire leur taille sur le L1 et par conséquent plus de données peuvent être insérées dans les blobs.

« Naïvement, une transaction occupe environ 180 octets de données. Cependant, il existe une série de techniques de compression qui peuvent être utilisées pour réduire cette taille en plusieurs étapes ; avec une compression optimale, nous pourrions potentiellement descendre jusqu’à moins de 25 octets par transaction. »

Cela permettrait en théorie de stocker jusqu’à 7 fois plus de données dans les blobs.

Plasma

D’autres techniques, telles que Plasma, une méthode remise au goût du jour par Buterin en novembre dernier pourrait également être utilisée. 

« Plasma est une catégorie de techniques qui permet d’obtenir une sécurité équivalente au rollup pour certaines applications tout en conservant les données sur L2 dans le cas normal. »

Cette méthode permettrait de garder une partie des données sur les L2, ce qui réduirait l’implication du L1 en tant qu’espace de stockage. Bien que cela ne soit pas optimal pour toutes les applications, cela permettrait tout de même dans certains cas spécifiques de réduire la charge de données publiées sur le L1.

La parallélisation

Enfin, Vitalik Buterin milite pour une amélioration des performances directement sur les L2. Une des pistes explorées dans son article consiste à paralléliser le traitement des transactions.

C’est d’ailleurs ce que propose l’EIP-648. Sans entrer dans les détails techniques, cela permettrait au rollup de traiter plusieurs transactions en même temps, plutôt que de les traiter les unes après les autres.

« Cela permet aux transactions dans l’EVM d’être traitées en parallèle beaucoup plus facilement, en spécifiant statiquement les adresses auxquelles elles peuvent accéder ; cela incite également à faire des transactions qui sont faciles à paralléliser. »

Vous l’aurez compris, la quête de la scalabilité est loin d’arriver à son terme. De nouvelles évolutions devront être apportées à tous les niveaux pour optimiser le fonctionnement d’Ethereum et de ses rollups.

En parallèle, le réseau fait face à un autre problème de taille. En effet, celui-ci a récemment dépassé la barre du million de validateurs. Cependant, l’essor du set de validateur pourrait entraîner d’importants problèmes de latence sur le réseau. Une situation qui devrait être en partie adressée lors du prochain hard fork intitulé Prague-Electra.