Morph : Une solution intégrée de zkEVM EIP-4844 et de preuves agrégées
TechFlow SélectionTechFlow Sélection
Morph : Une solution intégrée de zkEVM EIP-4844 et de preuves agrégées
Cet article propose une conception de circuit pratique et efficace dans le cadre de la proposition EIP-4844.
Dédié à des analyses Web3 approfondiesRédaction : Morph
Contexte
L’EIP-4844 introduit un nouveau type de transaction appelé « transaction transportant des blobs », qui contient une grande quantité de données inaccessibles via l’exécution EVM, mais dont les engagements (commitments) peuvent être consultés. Ce format de transaction est conçu pour être entièrement compatible avec les schémas de mise en shard.
Un blob est un vecteur composé de 4096 éléments d’un corps fini (le corps scalaire BLS12-381). Mathématiquement, ces 4096 éléments peuvent interpoler un polynôme p(x) de degré 4095, dont la valeur en chaque wi correspond exactement au i-ème élément du corps fini.
L’engagement (commitment) du blob peut être calculé via un engagement KZG et vérifié par la méthode appropriée.
Quelques constantes présentées dans l’EIP-4844 :
L’EIP-4844 joue un rôle crucial dans le processus des rollups. Contrairement à l’approche consistant à insérer les données du rollup dans le calldata des transactions, cette proposition permet au submitter d’insérer les données directement dans les blobs. Cette solution garantit la disponibilité des données tout en réduisant significativement les coûts liés à l’utilisation excessive du calldata sur la chaîne. Les rollups doivent assurer la disponibilité des données pendant une durée suffisante pour permettre aux opérateurs honnêtes de construire des preuves d’état, sans nécessiter que ces données restent indéfiniment sur la chaîne. Un ZK-rollup fournira deux types d’engagements pour ses transactions ou son état : l’engagement du blob et la preuve zk.
Preuve d’équivalence de l’engagement KZG dans l’EIP-4844
Dans les circuits de preuve à divulgation nulle (zero-knowledge proof) actuels, les opérations non natives telles que les accouplements bilinéaires sur la courbe elliptique BLS12-381 ne sont pas encore supportées. Ainsi, afin de valider l’engagement du blob, on transforme le problème en une vérification d’équivalence entre la cohérence de l’évaluation du polynôme en un point de défi et la nature limitée de l’engagement, en prouvant simplement la cohérence de l’évaluation en un point arbitraire.
La preuve de cohérence dans l’EIP-4844 comprend trois parties :
-
Prouver par circuit la cohérence entre le texte brut des transactions dans le blob et les éléments du corps fini du blob.
-
Prouver par circuit que le polynôme encodé par les éléments du corps fini prend bien la valeur y en un point de défi x.
-
Utiliser un contrat précompilé pour prouver la relation entre l’engagement c, la valeur de défi x et la valeur du polynôme y.
Vérification de la cohérence entre texte brut des transactions et blob
On conçoit d’abord un circuit pour prouver la correspondance entre le texte brut des transactions et les éléments du corps fini dans le blob. L’entrée de ce circuit comprend le texte brut des transactions et les 4096 éléments du corps fini. La logique de codage est contrainte comme suit :
-
Encoder 31 octets de données d’entrée en 32 octets, formant ainsi un élément du corps scalaire BLS12-381, tout en veillant à ce que les données encodées restent inférieures au module du corps scalaire. Pour supporter ultérieurement la validation par fragments, les données d’entrée (informations des transactions) dans un lot (batch) sont divisées en blocs (chunks).
-
Pour chaque encodage de chunk dans le blob, la longueur des données d’entrée est stockée dans les 4 premiers octets des 31 octets, puis les 27 premiers octets des données sont encodés dans les 27 octets restants. Cela forme le premier élément du corps fini du fragment (32 octets : le premier octet vaut 0, les deuxième à quatrième octets représentent la longueur des données du chunk, les 27 octets suivants contiennent les 27 premiers octets des données).
-
Les données restantes du chunk sont divisées en blocs de 31 octets, chacun encodé en 32 octets. Si les données finales du chunk sont inférieures à 31 octets, des zéros sont ajoutés à la fin.
Cette méthode de codage divise la longueur totale du lot en plusieurs longueurs de chunks, chacune stockée dans les éléments blob respectifs, facilitant ainsi la conception ultérieure de schémas agrégables.
Vérification de l’évaluation du polynôme du blob
Ce circuit sert à vérifier que le polynôme p(x) interpolé à partir des valeurs du blob prend bien la valeur y en un point arbitraire (point de défi) x. En utilisant cette approche, la validation du blob dans l’EIP-4844 — initialement impossible à cause de l’impossibilité de vérifier directement l’engagement — se ramène à la vérification conjointe du point de défi x, de la valeur du polynôme y et de l’engagement c. L’entrée du circuit est constituée des 4096 éléments du corps fini et du point de défi x ; la sortie est la valeur calculée y du polynôme.
Le calcul repose principalement sur la formule d’évaluation barycentrique. Pour un blob de 4096 éléments du corps fini :
La formule d’évaluation est la suivante :
Vérification de la cohérence entre l’engagement du blob et sa valeur évaluée
Avant cette étape, la vérification de cohérence entre le blob et son engagement a été convertie en une vérification de cohérence entre le point de défi x, la valeur fonctionnelle y et l’engagement du blob. Grâce au support de l’EIP-4844, les contrats intelligents peuvent accéder à l’engagement du blob, permettant ainsi de réaliser cette vérification directement via un contrat sur la chaîne. Nous discutons ci-dessous de l’optimisation par agrégation des évaluations effectuées précédemment dans le circuit.
Schéma de vérification agrégable pour les blobs
Chaque bloc de 32 octets dans un blob peut être représenté par un élément du corps scalaire BLS12-381. Toutefois, la longueur des données brutes des transactions varie, ce qui pose plusieurs problèmes :
-
Il n’est pas garanti que les données d’un chunk soient un multiple de 32 octets, donc elles ne s’encodent pas nécessairement en un nombre entier d’éléments du corps fini.
-
Les données d’une transaction peuvent être réparties sur deux blobs différents.
-
Après encodage, un batch ou un chunk peut occuper moins de 4096 éléments du corps fini, entraînant une faible utilisation de l’espace du blob.
Pour résoudre le premier problème, nous complétons chaque chunk par des zéros afin que le nombre total d’éléments du corps fini encodés soit entier. Concernant le second, nous imposons qu’une transaction ne chevauche jamais deux blobs, et optimisons le traitement de plusieurs blobs via une ouverture multi-points de l’engagement KZG. Pour le troisième problème, nous proposons un nouveau schéma d’agrégation.
Nous modifions le stockage initial de la longueur du batch (sur 4 bits parmi les 5 premiers) pour y stocker désormais la longueur du chunk dans chaque fragment. Le reste du codage reste inchangé. De plus, dans la preuve du chunk, outre la vérification de cohérence, nous incluons les indices des éléments du corps fini correspondant aux données de transaction dans le blob (indices du premier et dernier élément du chunk).
Notre solution présente les avantages suivants :
-
Compatibilité : L’EIP-4844 utilise les blob-data. Notre schéma implémente précisément le processus d’encodage des données brutes vers les blob-data, ce qui assure la compatibilité avec les circuits ZKevm existants.
-
Applicabilité : Les contrats précompilés d’Ethereum ne supportent que BN254. Utiliser BLS12-381 pour vérifier les engagements KZG entraînerait de nombreux calculs coûteux hors-courbe (comme les accouplements), consommant trop de gas. Notre utilisation de la formule barycentrique réduit fortement ces calculs hors-corps, rendant la charge de calcul réellement praticable.
-
Agrégabilité : Les preuves agrégées réduisent le nombre de preuves et les vérifications, abaissant ainsi la consommation de gas sur la chaîne. Notre approche améliore l’agrégation au niveau du chunk, et combinée à l’EIP-4844, permet une réduction encore plus marquée du gas utilisé.
Conclusion
Les solutions Layer-2 jouent un rôle clé dans la feuille de route de montée en charge d’Ethereum, mais soulèvent aussi des questions de sécurité et des limitations de performance. Les ZK-rollups, fondés sur des bases mathématiques solides, offrent une très haute sécurité, bien que cela implique un coût élevé en génération et vérification de preuves. Grâce à de meilleurs algorithmes et à des améliorations matérielles, le coût de génération des preuves peut être réduit efficacement ; grâce à l’optimisation des calculs et du stockage sur chaîne, la vérification peut également être améliorée.
L’EIP-4844, en tant que catalyseur pour les rollups, permet une optimisation majeure du coût en gas lié au stockage des données sur chaîne, tout en posant de nouveaux défis pratiques. Cet article propose un schéma de conception de circuit pratique et efficace sous l’EIP-4844, réduisant efficacement la consommation de gas tout en résolvant certains problèmes d’application. L’équipe Morph poursuit constamment son objectif de créer un écosystème de transactions plus sûr et à moindre coût, explorant activement de nouvelles technologies dans le but de contribuer davantage à l’écosystème communautaire.
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
@MorphLayer
