Analyse du nouvel article de Vitalik : pourquoi les Rollup dont l'espace Blob n'est pas utilisé efficacement sont-ils confrontés à des difficultés de développement ?
TechFlow SélectionTechFlow Sélection
Analyse du nouvel article de Vitalik : pourquoi les Rollup dont l'espace Blob n'est pas utilisé efficacement sont-ils confrontés à des difficultés de développement ?
Après la mise à niveau de Cancun, les performances sont utilisables, mais Vitalik s'inquiète fortement du développement des Rollup.
Dédié à des analyses Web3 approfondiesRédaction : Haotian
Comment comprendre la réflexion de Vitalik Buterin sur l'extensibilité d'Ethereum dans son nouvel article ? Certains disent que Vitalik fait de la publicité pour les inscriptions Blob, ce qui est absurde.
Alors, comment fonctionne un paquet de données Blob ? Pourquoi l'espace Blob n'est-il pas efficacement utilisé après la mise à niveau de Cancun ? L'échantillonnage DAS (Data Availability Sampling) prépare-t-il la mise en œuvre des shards ?
À mon avis, les performances après la mise à niveau de Cancun sont désormais utilisables, mais Vitalik s'inquiète profondément du développement des Rollups. Pourquoi ? Voici ma compréhension :
1) J'ai déjà expliqué à plusieurs reprises que le Blob est un paquet de données temporaire indépendant du calldata EVM et directement accessible par la couche de consensus. Le principal avantage est que l'EVM n'a pas besoin d'accéder aux données Blob lors de l'exécution des transactions, évitant ainsi des frais élevés liés au calcul au niveau de l'exécution.
Actuellement, après avoir équilibré divers facteurs, la taille d'un Blob est fixée à 128 Ko. Un lot (batch) de transactions envoyé au réseau principal peut transporter au maximum deux Blobs. Idéalement, l'objectif final est qu'un bloc du réseau principal puisse contenir environ 128 paquets de données Blob, soit environ 16 Mo.
Les projets Rollup doivent donc équilibrer autant que possible le nombre de blocs Blob, la capacité TPS et le coût de stockage des nœuds principaux, afin d'utiliser l'espace Blob avec un rapport qualité-prix optimal.
Prenons l'exemple d'Optimism : actuellement, environ 500 000 transactions par jour, avec un batch toutes les deux minutes vers le réseau principal, transportant un seul Blob. Pourquoi un seul ? Parce que le TPS actuel ne nécessite pas plus. Bien sûr, on pourrait en transporter deux, mais chaque Blob ne serait pas pleinement utilisé, augmentant inutilement les coûts de stockage.
Que se passerait-il si le volume des transactions hors chaîne des Rollups augmentait considérablement, par exemple atteignant 50 millions de transactions par jour ?
1. Compresser le volume de transactions par batch, afin de faire tenir le maximum de transactions dans l'espace Blob ;
2. Augmenter le nombre de Blobs ;
3. Réduire la fréquence des batches de transactions ;
2) En raison des limites de gaz (Gas Limit) et des coûts de stockage, le fait qu'un bloc puisse contenir 128 Blobs reste un objectif théorique. Actuellement, cela n'est pas nécessaire : Optimism utilise seulement un Blob toutes les deux minutes. Il reste donc une marge très importante pour que les projets Layer2 améliorent leur TPS, élargissent leur base d'utilisateurs et développent leur écosystème.
Par conséquent, pendant un certain temps après la mise à niveau de Cancun, l'utilisation des Blobs par les Rollups — en termes de quantité, de fréquence ou de concurrence pour l'espace Blob — n'est pas encore intense.
La raison pour laquelle Vitalik mentionne les inscriptions « Blobscription » est que ces opérations peuvent temporairement augmenter le volume des transactions et la demande d'utilisation des Blobs, ce qui permet d'agrandir le volume global. Utiliser les inscriptions comme exemple aide à mieux comprendre le mécanisme de fonctionnement des Blobs. En réalité, le véritable message de Vitalik n'a que peu à voir avec les inscriptions elles-mêmes.
En théorie, si un projet Layer2 envoyait fréquemment des batches de transactions volumineux au réseau principal en remplissant systématiquement chaque Blob, il pourrait affecter l'utilisation normale des Blobs par d'autres Layer2, à condition d'être prêt à supporter des coûts élevés. Mais dans la pratique actuelle, cela reviendrait à acheter de la puissance de calcul pour effectuer une attaque de type 51 % contre BTC : théoriquement possible, mais sans motivation économique réelle.
Ainsi, les frais de gaz sur Layer2 resteront stables à un niveau « bas » pendant longtemps, offrant une fenêtre dorée prolongée pour le développement et le renforcement des projets Layer2.
3) Supposons qu'un jour, le marché Layer2 devienne suffisamment prospère pour générer un volume massif de transactions envoyées au réseau principal, et que l'espace Blob disponible devienne insuffisant. Ethereum a déjà prévu une solution : la technique d’échantillonnage de disponibilité des données (DAS).
En termes simples, plutôt que de stocker toutes les données Blob sur un seul nœud, celles-ci peuvent être réparties entre plusieurs nœuds. Par exemple, chaque nœud stocke 1/8 des données totales, et un groupe de 8 nœuds assure ensemble la disponibilité des données (DA), multipliant ainsi efficacement la capacité de stockage Blob par 8. C’est précisément ce que réalisera la phase future de sharding (fractionnement en shards).
Le fait que Vitalik insiste à plusieurs reprises sur ce point est significatif. Cela ressemble à un avertissement aux projets Layer2 : cessez de vous plaindre du coût élevé de la disponibilité des données (DA) sur Ethereum. À l’heure actuelle, vos niveaux de TPS n’exploitent même pas pleinement les capacités des Blobs. Accélérez le développement de vos écosystèmes, augmentez votre base d’utilisateurs et votre volume de transactions. Arrêtez de chercher constamment à fuir la DA avec des solutions rapides comme le « one-click chain launch ».
Vitalik a ensuite ajouté que, selon lui, parmi les rollups principaux actuels, seul Arbitrum a atteint le stade 1. Bien que des projets comme DeGate ou Fuel aient atteint le stade 2, ils ne sont pas encore largement connus. Le stade 2 représente l'objectif ultime en matière de sécurité pour les rollups. Très peu ont atteint le stade 1, tandis que la majorité reste au stade 0. On comprend alors pourquoi Vitalik s’inquiète sincèrement de l’état du développement de l’industrie des rollups.
4) En réalité, en ce qui concerne simplement les goulots d'étranglement d'extensibilité, les solutions Rollup Layer2 ont encore beaucoup de marge de progression.
1. Grâce à la compression des données, l'utilisation de l'espace Blob peut être rendue plus efficace. OP-Rollup dispose déjà d'un composant dédié appelé « compressor ». Quant aux ZK-Rollup, la soumission de preuves SNARK/STARK vers le réseau principal constitue en soi un processus de « compression ».
2. Réduire autant que possible la dépendance de Layer2 vis-à-vis du réseau principal, en n'utilisant la technologie de preuve optimiste que dans des cas particuliers pour garantir la sécurité de L2. Par exemple, Plasma conserve la plupart des données sur chaîne, mais les dépôts et retraits ont lieu sur le réseau principal, ce qui permet au réseau principal de garantir la sécurité.
Cela signifie que Layer2 devrait limiter ses interactions fortes avec le réseau principal aux opérations critiques comme les dépôts et retraits. Cela allège la charge du réseau principal tout en améliorant les performances autonomes de L2. Des approches telles que la capacité de traitement parallèle du Sequencer, le tri et le prétraitement hors chaîne de nombreuses transactions, ou encore le modèle de Rollup hybride proposé par Metis — où les transactions normales passent par OP-Rollup et les demandes spéciales de retrait par une route ZK — reflètent toutes cette logique.
En résumé,
l'article de Vitalik sur les solutions futures d'extensibilité d'Ethereum est extrêmement instructif. Il exprime clairement son insatisfaction face à l'état actuel du développement Layer2, affirme avec optimisme le potentiel des performances Blob, esquisse les perspectives futures des technologies de sharding, et prodigue même des conseils bien intentionnés sur certaines directions d'optimisation pour les projets Layer2.
En fin de compte, la seule incertitude qui reste maintenant repose entièrement sur les épaules des projets Layer2 : comment accélérer leur développement ?
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Haotian | CryptoInsight
