Comment comprendre les réflexions du nouvel article de Vitalik sur l'expansion d'Ethereum ?

Comment comprendre les réflexions du nouvel article de Vitalik Buterin sur l’expansion d’Ethereum ? Certaines personnes disent que la commande de Vitalik pour Blob Inscription est scandaleuse. Alors, comment fonctionnent les paquets blob ? Pourquoi l’espace blob n’est-il pas utilisé efficacement après la mise à niveau à Cancun ? Échantillonnage de la disponibilité des données DAS en vue du partitionnement ?

À mon avis, les performances de Cancun sont utilisables après la mise à niveau, et Vitalik s'inquiète du développement de Rollup. Pourquoi? Ensuite, permettez-moi de parler de ma compréhension :

Avant de l'expliquer plusieurs fois, Blob est un package de données temporaire qui peut être directement récupéré par la couche de consensus. L'avantage direct est qu'EVM n'a pas besoin d'accéder aux données Blob lors de l'exécution de transactions. Cela se traduit par des coûts informatiques inférieurs au niveau de la couche d'exécution.

Une série de facteurs sur la plateforme actuelle, la taille d'un Blob est de 128 Ko, et un lot de transactions vers le réseau principal peut transporter jusqu'à deux blobs. Compte tenu de la situation, le but ultime d'un bloc de réseau principal est d'en transporter environ 128. Paquets Blob de 16 Mo.

Afin que le projet Rollup ait le meilleur rapport coût/performance, des facteurs tels que le coût de stockage de l'espace Blob, la capacité de transaction TPS, le stockage du nœud de réseau principal Blob, etc. peuvent être utilisés comme principales considérations pour obtenir un maximum d'avantages.

Prenons l'exemple d'Optimism. Actuellement, il y a environ 500 000 transactions par jour en moyenne, chaque transaction par lots de 2 cents est envoyée au réseau principal, transportant 1 paquet de données Blob à la fois. Pourquoi apporter autant de Blobs que vous ne pouvez pas tous les utiliser ? Bien sûr, vous pouvez également en transporter deux. La capacité de chaque Blob ne sera alors pas pleine, mais cela augmentera le coût de stockage.

Que devons-nous faire lorsque le volume de transactions hors de la chaîne Rollup augmente, par exemple, 50 millions de transactions sont traitées chaque jour ? 1. Compresser compresse le volume de transactions de chaque lot pour permettre autant de transactions que possible dans l'espace Blob ; 2. Augmenter le nombre de Blobs ; 3. Raccourcir la fréquence des transactions par lots

Étant donné la quantité de données transportées par le principal ; le bloc réseau est limité par la limite de gaz et en raison de l'impact des coûts de stockage, 128 blobs par bloc d'emplacement est l'état idéal, et actuellement nous n'en utilisons pas autant. L'optimisme n'en génère qu'un toutes les 2 minutes, ce qui laisse beaucoup de place au projet layer2 pour améliorer le TPS et augmenter le nombre d'utilisateurs du marché et la prospérité écologique.

Par conséquent, pendant un certain temps après la mise à niveau de Cancun, le Rollup n'était pas « volatil » en termes de nombre et de fréquence de Blobs utilisés, ainsi que d'utilisation des enchères d'espace Blob.

La raison pour laquelle Vitalik mentionne les inscriptions Blob est que ce type d'inscription peut augmenter temporairement le volume des transactions, ce qui entraînera une augmentation de la demande d'utilisation du Blob, augmentant ainsi la taille des inscriptions comme exemple peut fournir une compréhension plus approfondie. du mécanisme de fonctionnement des Blobs, et ce que Vitalik veut réellement exprimer, cela n'a rien à voir avec l'inscription.

Parce qu'en théorie, si une partie du projet de couche 2 effectue des transactions par lots à haute fréquence et de grande capacité sur le réseau principal et remplit le bloc Blob à chaque fois, tant qu'elle est prête à supporter le coût élevé d'un lot de transactions falsifiées , cela affectera d'autres couches2 L'utilisation normale de Blob, mais dans la situation actuelle, c'est comme si quelqu'un achetait de la puissance de calcul pour mener une attaque hard fork à 51 % sur BTC. C'est théoriquement faisable, mais en pratique, cela manque de motivation pour le profit.

L'introduction de Blob vise à réduire la charge sur EVM et à améliorer les capacités d'exploitation et de maintenance des nœuds, ce qui est sans aucun doute une solution sur mesure pour Rollup. De toute évidence, il n’est pas utilisé efficacement pour le moment et les frais de gaz pour la deuxième couche resteront stables dans la fourchette « inférieure » pendant longtemps. Cela donnera au marché de couche 2 une fenêtre de développement en or à long terme pour « augmenter les troupes et rassembler de la nourriture ».

3) Alors, que se passerait-il si un jour le marché de la couche 2 prospérait dans une certaine mesure et que le nombre de transactions de Batch vers le réseau principal atteignait un montant énorme chaque jour et que les paquets de données Blob actuels ne suffisaient pas ? Ethereum a déjà fourni une solution : en utilisant la technologie d'échantillonnage de disponibilité des données (DAS) :

Une compréhension simple est que les données qui doivent initialement être stockées dans un nœud peuvent être distribuées sur plusieurs nœuds en même temps, par exemple sur chaque nœud. stocke toutes les données Blob 1/8, 8 nœuds forment un groupe pour répondre à la capacité DA, ce qui équivaut à augmenter la capacité de stockage Blob actuelle de 8 fois. C'est en fait ce que Sharding fera lors de la future étape de sharding.

Mais maintenant, Vitalik l'a répété à plusieurs reprises, avec charme, et semble avertir la majorité des parties au projet de couche 2 : ne vous plaignez pas toujours des capacités DA coûteuses d'Ethereum. Avec votre capacité TPS actuelle, vous n'avez pas développé le. capacités des paquets de données Blob à l'extrême. Dépêchez-vous d'augmenter la puissance de feu pour développer l'écosystème, augmenter les utilisateurs et le volume des transactions, et ne pensez pas toujours à DA s'enfuir pour s'engager dans la création de chaînes en un clic.

Plus tard, Vitalik a ajouté que parmi les rollups de base actuels, seul Arbitrum a atteint l'étape 1. Bien que DeGate, Fuel, etc. aient atteint l'étape 2, ils ne sont pas encore familiers à la communauté au sens large. L'étape 2 est l'objectif ultime de la sécurité des rollups. Très peu de rollups ont atteint l'étape 1, et la plupart des rollups sont au stade 0. On voit que le développement de l'industrie des rollups inquiète vraiment Vitalik.

4) En fait, en termes de problème de goulot d'étranglement d'expansion, il reste encore beaucoup de place pour que la solution Rollup layer2 améliore les performances.

1. Utilisez l'espace Blob plus efficacement grâce à la compression des données. OP-Rollup dispose actuellement d'un composant Compressor dédié pour effectuer ce travail. La compression hors chaîne SNARK/STARK de ZK-Rollup prouve que la soumission au réseau principal est une « compression » ;

2. Réduisez autant que possible la dépendance de la couche 2 à l'égard du réseau principal et utilisez uniquement la technologie de preuve optimiste pour garantir la sécurité L2 dans des circonstances particulières. Par exemple, la plupart des données de Plasma se trouvent sur la chaîne, mais les dépôts et les retraits ont lieu sur la chaîne principale. réseau. Par conséquent, le réseau principal peut promettre sa sécurité.

Cela signifie que la couche 2 ne doit considérer que les opérations importantes telles que les dépôts et les retraits comme étant fortement liées au réseau principal, ce qui non seulement réduit la charge sur le réseau principal, mais améliore également les propres performances de L2. La capacité de « traitement parallèle » de Sequencer mentionnée précédemment en parlant d'EVM parallèle peut filtrer, classer et prétraiter un grand nombre de transactions hors chaîne, ainsi que le cumul hybride promu par Metis. Les transactions normales passent par OP-Rollup, les demandes de retrait spéciales passent par ZK Route, etc. Toutes ont des considérations similaires.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!