Maison > web3.0 > Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais j'ai trouvé que les choses ne sont pas si simples

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais j'ai trouvé que les choses ne sont pas si simples

PHPz
Libérer: 2024-04-18 17:40:01
avant
502 Les gens l'ont consulté

Avant-propos

EIP-4844, en tant que plus grande mise à niveau d'Ethereum après The Merge, a attiré suffisamment d'attention de la part de l'ensemble du réseau. L'espace de stockage temporaire Blob introduit dans cette mise à niveau équivaut à l'ajout d'un wagon latéral au train Ethereum, offrant ainsi un espace de disponibilité des données moins cher sans affecter l'état de fonctionnement d'origine du train.

Les réseaux de couche 2 tels que Optimism, StarkNet et Arbitrum ont tous pris en charge EIP-4844 dans un court laps de temps et ont obtenu des effets de réduction de frais significatifs. Ce qui suit est une transaction dans laquelle la trésorerie de LXDAO verse les salaires aux contributeurs d'Optimism, et le gaz avant et après Les frais sont en réalité 100 fois différents.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Mais même si nous avons été agréablement surpris, nous avons découvert que StarkNet, en tant que représentant de ZK Rollup, a également obtenu un effet de réduction de frais incroyable. Par rapport au niveau précédent de consommation de gaz qui dépassait fréquemment 1 $, il a également diminué. à 0,01$.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Si vous souhaitez connaître des principes techniques plus détaillés, vous êtes invités à entrer dans MyFirstLayer2 pour apprendre.

Remarque : MyFirstLayer2 est un projet éducatif Web3 soutenu par la Fondation Ethereum et initié par LXDAO. Il vise à aider les nouveaux arrivants à comprendre l'histoire du développement de la couche 2 à travers diverses méthodes pédagogiques attrayantes, telles que du texte, des images, des animations et des interactions. concepts de base.

Pourquoi la réduction des frais de StarkNet est-elle surprenante ?

OP Rollup et ZK Rollup ont des exigences différentes pour une couche d'espace de stockage

Parce que OP Rollup et ZK Rollup ont des coûts DA (Disponibilité des données : disponibilité des données, y compris les services de stockage et de distribution de données, afin que les tiers puissent obtenir ce qu'ils veulent . données) à des degrés divers.

OP Rollup regroupera et compressera tous les détails des transactions récentes, y compris les signatures des utilisateurs et d'autres informations, et les téléchargera sur le réseau de premier niveau. Cela ne nécessite pas trop de tâches de vérification sur le réseau de premier niveau, et presque tous les coûts sont dans l'espace de stockage du réseau de premier niveau.

ZK Rollup, en comparaison, a un taux de compression des données plus élevé. Par exemple, il peut abandonner les données de signature de l'utilisateur et s'appuyer sur une preuve sans connaissance pour garantir que les transactions sont légales et il n'a pas besoin de regrouper tous les détails de la transaction, seuls les changements de statut sont regroupés et téléchargés.

Par exemple, sur le réseau de deuxième couche, 100 utilisateurs ont négocié sur la paire de trading USDC/USDT. Chaque fois que l'utilisateur négocie, les soldes USDC et USDC du contrat Swap changeront. Pour OP Rollup, il s'agit de 100 transactions et 400 modifications de solde de 200 comptes ; pour ZK Rollup, il n'y a pas beaucoup de différence concernant les modifications des soldes des utilisateurs, mais pour le contrat Swap, ses soldes USDC et USDT. Un total de 200 modifications peuvent être compressées. en 2 changements dans le solde final, réduisant considérablement le volume de données.

ZK Rollup vérifie le gaz supplémentaire consommé par ZK Proof

Après avoir compris la différence entre les deux, votre première impression peut être que les frais de gaz de ZK Rollup seront généralement inférieurs, mais les étudiants qui l'ont pratiqué devraient tous le savoir, tels que StarkNet, ZkSync et autres ZK Rollup L2, les frais sont souvent nettement plus élevés que ceux d'OP Rollup. En particulier, la route technologique STARK de StarkNet est plus large que la preuve ZK des autres routes SNARK et se situe souvent au bas du classement de L2. frais de transfert. .

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

La raison pour laquelle ZK Rollup n'a pas battu OP Rollup partout dès sa mise en ligne est simplement parce que bien qu'il ait un taux de compression plus élevé pour les données de transaction et économise le coût de transmission des données vers la première couche, Cela nécessite de vérifier la légitimité de la preuve à connaissance nulle sur une couche du réseau, ce qui augmente le coût de calcul.

Blob ne peut que réduire le coût de la partie stockage, mais n'aide pas la partie calcul. Par conséquent, ZK Rollup peut tirer encore moins d'avantages de l'EIP-4844, nous voyons donc le classement StarkNet du bas des "sous-performants". ne soyez pas surpris lorsque vous progressez au même niveau que la première et la deuxième place de la classe.

Exploration des frais StarkNet

Je dois dire que le mécanisme du ZK Rollup est bien plus compliqué que celui de l'OP Rollup. Par exemple, via le contrat Optimism : Batcher, le coût du packaging des données sur le réseau principal avant et après. la mise à niveau. Tout le monde peut parfaitement comprendre pourquoi les frais de transaction ont été réduits de deux ordres de grandeur.

Cliquez sur les mots bleus pour en savoir plus :

Le dernier ancien lot avant la mise à niveau.

Le premier nouveau lot après la mise à niveau (y compris les frais Blob, un total de 0,0011 ETH) :

Le coût de 6 Blobs (un total de 0,00078 ETH)

Mais en train d'explorer les frais de StarkNet Gas, l'auteur a connu des difficultés considérables et a même rencontré de multiples renversements d'intrigue. Le processus d'exploration lui-même est également très inspirant. Revivons-le avec l'article.

Le L1DA disparu

Avec l'expérience d'explorer les secrets de la réduction des frais d'Optimism, nous avons naturellement pensé qu'il nous suffisait de trouver le contrat qui soumettait initialement les données au réseau principal par StarkNet. Cet important contrat devait avoir été consommé par Etherscan's Gas. Il est sur la liste, donc il ne devrait pas être difficile à trouver. Scroll, qui n'a pas été adapté à Blob, est toujours parmi les meilleurs et reste accroché au sommet éblouissant.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Lorsque nous recherchons des mots-clés StarkNet, nous trouverons 3 contrats liés : Opérateur, Contrat principal et Registre des faits de la page mémoire. Cependant, le troisième contrat qui semble être lié à l'espace de stockage a été interrompu il y a près de deux ans. . utilisé.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Nous pouvons donc seulement voir que l'opérateur interagit constamment avec le contrat principal et met constamment à jour le dernier statut.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Et si nous regardons l'avant et l'arrière du blob d'adaptation, nous constatons que la transaction Operator's Update State a effectivement été mise à niveau, mais ce n'est qu'un hachage pointant vers un autre paquet. Même la dernière mise à jourStateKzgDA consomme plus de gaz, ce qui ne peut pas du tout expliquer la raison de la réduction des frais de StarkNet.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Cette dernière mise à jour n'est qu'un engagement polynomial KZG, utilisé pour prouver que les données du Blob correspondent au paquet de données de son lot correspondant, et c'est aussi juste une "racine d'état". Racine)". Cette racine d'état correspond au « petit registre » qui enregistre tous les états de tous les contrats sur le réseau de deuxième niveau. Ce petit registre existe théoriquement également sur le réseau de premier niveau.

Alors la question est : pourquoi ne reste-t-il qu’une seule racine ? Où est passé cet épais petit registre ?

Analyse après le premier échec

Bien que la première exploration n'ait pas été très réussie, nous pouvons encore tirer quelques inférences et conjectures. Les amis qui ont regardé MyFirstLayer2 doivent savoir que le problème principal abordé par Rollup est le problème DA (disponibilité des données), et les solutions qu'ils adoptent consistent à télécharger les données clés sur le réseau principal pour résoudre le problème de disponibilité des données, afin que tout le monde puisse y accéder facilement. cela nécessitait des données.

  1. OP Rollup est en fait un moyen simple et grossier de compresser et de regrouper chaque transaction et de la télécharger sur le réseau de première couche. Ensuite, d'autres peuvent obtenir une image complète du petit grand livre de deuxième couche en décompressant et en rejouant chaque transaction. vérifier si la transaction est exécutée correctement.

  2. ZK Rollup n'a pas besoin de télécharger tous les détails de la transaction, seul le State Diff (la partie du changement d'état de chaque lot) peut être téléchargé. La preuve sans connaissance garantit que toutes les transactions ont été correctement exécutées sur la deuxième couche. D'autres peuvent restaurer l'image complète du petit grand livre de deuxième couche en rejouant les résultats de plusieurs changements d'état.

Et nous savons que les données dans le Blob ne sont qu'une chaîne de texte binaire vers la première couche. La première couche protège uniquement l'exactitude des données dans le Blob sans vérifier sa légalité. ne peut pas le lire et le vérifier. Le contenu du Blob, donc si la preuve ZK est toujours vérifiée par une couche, alors la preuve ZK elle-même ne doit pas être placée dans le Blob. Par conséquent, StarkNet peut avoir un certain effet de réduction des coûts en mettant l'État. diff de chaque lot dans le bingo Blob.

Notre prochaine tâche est donc évidemment de déterminer où StarkNet place-t-il la différence d'État ? Où était-il placé dans le passé ? Est-il placé dans le Blob maintenant ?

De plus, le fait qu'une seule racine d'état puisse être trouvée amène également les gens à se demander si StarkNet a discrètement téléchargé des données de changement d'état sur le réseau principal il y a longtemps et les a modifiées vers son propre DAC (Data Availability Committee). Si c'est vraiment le cas. Dans ce cas, les frais élevés antérieurs de StarkNet sont complètement déraisonnables et ne peuvent être expliqués que par...

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Liens connexes :

https://layer2.myfirst.io/zh#2.4-rollup

SHARP System

Heureusement, après avoir discuté avec @0xYandhii, une nouvelle aube a marqué le début. Avant le lancement du réseau principal général, le premier produit de StarkNet était en fait StarkEX, y compris l'échange décentralisé de produits dérivés DYDX, qui était également un produit de cette période. Après la mise en ligne du réseau principal, le produit d'origine n'a pas été abandonné, mais a plutôt partagé un système de vérification avec le réseau principal.

C'est-à-dire SHARP : Shared Proving and Verifying System, puis nous avons trouvé des contrats associés tels que SHARP Blockchain Writer et Starkware : SHARP Verifier.

Ouvrez le navigateur de blocs pour interroger les transactions associées, vous constaterez que SHARP Blockchain Writer a effectué les 4 types d'opérations suivants :

  1. Vérifier Merkle : Vérifier l'arbre Merkle

  2. Vérifier FRI : Oracle interactif Fast Reed-Solomon La preuve de proximité est utilisée pour garantir que les données soumises ou les résultats de calcul suivent des règles ou des contraintes spécifiques sans révéler le contenu des données elles-mêmes.

  3. Page d'enregistrement de la mémoire continue : téléchargée plus d'une centaine de fois en un seul cycle, enregistrant un espace mémoire continu, qui est soupçonné d'être la partie qui écrit les données sur le réseau de première couche.

  4. Vérifiez la preuve et enregistrez-vous : une fois par cycle, cela peut être aussi rapide que dix minutes ou aussi lent qu'une ou deux heures. Cela devrait suffire pour accumuler suffisamment de transactions pour un lot de vérification.

Il n'est pas difficile de voir que les étapes 1, 2 et 4 sont des étapes liées à la preuve de connaissance nulle, et la troisième étape d'enregistrement de l'espace mémoire est évidemment l'étape d'écriture des données sur une couche du réseau, et est le plus susceptible de stocker les différences d'état L'endroit.

Il est raisonnable de supposer que les coûts de ces trois étapes de vérification n'ont pas changé de manière significative avant et après la mise à niveau de Blob, et que le coût de la troisième étape devrait pouvoir expliquer les deux ordres de grandeur d'effet de réduction des coûts avant et après StarkNet. .

L'auteur a donc continué à parcourir l'explorateur de blocs et a pris un cycle de vérification de chacune des trois périodes de l'avant-dernière ancienne version avant EIP-4844, de l'avant-dernière version et de la dernière version qui a été mise à niveau, et a compté le Gaz consommé dans les quatre étapes comment.

Les résultats sont les suivants, ce qui fait se gratter la tête.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Le coût de la mémoire a diminué de moitié, mais à en juger par sa proportion dans le coût dans l'ensemble du processus de vérification ZK Proof, ce niveau de baisse de DA n'explique aucun problème.

L'exploration est presque arrivée au bout du chemin. L'auteur se sent comme un physicien assis devant le grand collisionneur de particules du monde Trisolaran. Chaque cellule du cerveau crie : cela n'a aucun sens ! La communauté StarkNet a posté un message demandant, mais peut-être parce que la question était trop compliquée, personne dans la communauté anglophone n'a répondu.

SHARP System GasUsed Exploration

À ce stade, il nous reste la dernière petite astuce dans le csv des données de transaction précédemment téléchargées, il n'y a que l'ETH consommé par les frais de gaz, et il n'y a aucune information telle que Gaslimit, donc le. L’impact des fluctuations du prix unitaire du gaz sur les statistiques ne peut être exclu. L'auteur a donc écrit un script pour compter le GasUsed (la partie utilisée du Gaslimit) réellement consommé par chaque transaction impliquée.

Enfin, la lumière apparaît ! On peut voir qu'avant la mise à niveau, les transactions d'enregistrement de l'espace mémoire étaient en fait envoyées par groupes de 2. L'un des gaz était au minimum de 50 000, tandis que l'autre était généralement d'environ 300 000.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Après la mise à niveau, presque toutes les transactions de mémoire enregistrées sont devenues des transactions à faible consommation de 50 000.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

La conclusion étrange la dernière fois était probablement due au fait que nous avons prélevé trop peu d'échantillons. Il est arrivé que le cycle de vérification après la mise à niveau ait rattrapé une longue période de surtension du réseau principal, ce qui a duré plus longtemps que des centaines de pages de mémoire continue d'enregistrement. les transactions coûtent plus cher le gaz, ce qui fausse les résultats statistiques.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

Suite à cette idée, nous avons réorganisé les données GasUsed de 3 instants, ce qui est bien plus raisonnable cette fois. À ce stade, il peut être confirmé que la taille de la page mémoire a effectivement été considérablement réduite après la mise à niveau. C'est ici que les données de changement d'état State Diff sont stockées. Après la mise à niveau, cette partie des données a été transférée. au Blob.

Et plus tard, nous avons trouvé le schéma technique de StarkNet sur l2beat.com et avons constaté que le diff d'état est effectivement stocké dans la page mémoire comme nous l'espérions.

Après EIP-4844, les frais StarkNet ont été réduits de 100 fois ? Mais jai trouvé que les choses ne sont pas si simples

En fin de compte, sur la base de notre calcul basé sur le nombre de GasUsed (une estimation large basée sur la petite taille d'échantillon actuellement sélectionnée au hasard), le coût réel de L1DA pour StarkNet est environ 4 à 10 fois plus petit, ce qui est légèrement inférieur. qu'un ordre de grandeur. Ceci est également cohérent avec la déduction théorique : dans la mise à niveau EIP-4844, ZK Rollup ne bénéficie pas d'autant d'avantages que OP Rollup.

Résumé

Après l'exploration ci-dessus, nous avons finalement clarifié les raisons et l'étendue de la réduction des frais de StarNet, et la conclusion est toujours un peu intrigante.

Le coût du L1DA a diminué de manière significative, mais cela ne peut pas expliquer la baisse de deux ordres de grandeur

Il est clair que StarNet avait l'habitude d'écrire les données de chaque lot de changements d'état dans une couche du réseau, mais maintenant il place cette partie du données dans Blobs , de sorte que l'effet de réduction des frais légèrement inférieur à un ordre de grandeur peut être obtenu dans le comportement d'enregistrement de l'espace mémoire.

Mais StarkNet est passé du premier ou de l'avant-dernier classement à un effet de réduction des frais au même niveau que les meilleurs étudiants OP. En termes de progrès relatif, il bat même tous les cumuls OP. C'est évidemment impossible.

Alors la seule explication raisonnable est que le prix "Cœur-Cœur" était effectivement trop élevé avant. Avant l'émission des jetons STRK, toutes les incitations au développement et à la communauté de StarkNet nécessitent des fonds. En plus de brûler l'argent des investisseurs, fixer une différence de prix du gaz L2 L1 plus élevée peut être l'un de leurs moyens de maintenir le développement, ce qui a causé l'embarras du gaz StarNet précédent. situation de facturation.

Maintenant que l'émission de tokens STRK leur a apporté suffisamment de liquidités et d'incitations écologiques, il est temps de ramener le Gas à un niveau raisonnable et de profiter de cette vague d'améliorations Blob pour supprimer les sacs de sable attachés à leurs pieds, l'effet de réduction des frais. cela a vraiment surpris beaucoup de gens.

OP rollup de ZK

OP Rollup Après la mise à niveau, les données initialement stockées dans Calldata sur le réseau principal Ethereum ont été transférées vers la zone de stockage temporaire, ce qui a en fait sacrifié un peu de sécurité.

Auparavant, les données de l'espace Calldata étaient stockées de manière permanente, ce qui signifiait que n'importe qui pouvait obtenir suffisamment de données du réseau principal Ethereum pour restaurer tous les états actuels sur l'OP L2.

Mais après la mise à niveau, les données Blob expireront. Si aucune entité de l'ensemble du réseau ne sauvegarde les données Blob passées, les enregistrements historiques des transactions de l'OP L2 risquent d'être perdus. Bien que le dernier état du réseau de couche 2 puisse toujours être protégé - parce que la période de stockage du Blob dépasse la période de défi de 7 à 14 jours de l'OP, donc avant que chaque Blob ne soit sur le point d'expirer, son état de couche 2 correspondant est toujours crédible, ces derniers. dix jours d'enregistrement des transactions maintiennent la sécurité de l'OP L2 sur une base continue.

ZK Rollup Si vous souhaitez profiter des avantages de Blob, vous devez également transférer les données d'état importantes de deuxième couche de l'espace Calldata permanent vers l'espace Blob. Cela signifie qu'après un certain temps, nous ne pouvons plus compter sur les données fournies par le réseau de premier niveau pour rejouer l'état du réseau de deuxième niveau comme avant.

Cela deviendra peut-être une nouvelle norme. À l'avenir, tous les réseaux de deuxième couche s'appuieront sur les Blobs pour maintenir le dernier état de sécurité, et chaque L2 devra également trouver sa propre façon de résoudre la disponibilité des données de transaction historiques, afin qu'entre sécurité et efficacité parviennent à un meilleur équilibre.

Tendance d'intégration d'OP et de ZK

Dans le passé, la première génération d'OP Rollup a été la première à être mise en ligne, mais la première génération de ZK Rollup n'a pas apporté de frais d'essence plus compétitifs après sa mise en ligne. Avec la tendance à la modularisation qui a suivi, provoquée par l'émergence d'OP Stack et de Polygon SDK, OP Stack prévoit même d'introduire la technologie ZK à l'avenir pour réduire la période de défi.

Cela montre sans aucun doute que les deux voies techniques OP et ZK ne sont pas une compétition à mort. Elles apprendront l'une de l'autre et auront tendance à s'intégrer, mais cette fois c'est le "noble" ZK. qui apprend une fois du PO "simple et grossier".

Il est difficile d’imaginer que la technologie du réseau de deuxième couche ait évolué à ce point en seulement deux ou trois ans. C’est peut-être le charme du monde de la blockchain.

Référence :

[1] FeedTheFed. Disponibilité des données avec EIP4844[EB/OL]. (2024-02-11)[2024-04-16]. /data-availability-with-eip4844/113065.

[2] Équipe de recherche L2BEAT [EB/OL]. [2024-04-16]. ?selectedChart=activity#contracts.

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!

source:panewslab.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal