Au cœur de tous les Optimistic Rollups, il existe une hypothèse clé : les propositions d'état soumises sont par défaut valides tant qu'elles n'ont pas été prouvées fausses. Cependant, cette hypothèse ne tient que si le Rollup dispose d'un mécanisme de preuve de fraude robuste. Les chaînes manquant de ce mécanisme deviennent immédiatement non sécurisées si un état invalide n'est pas contesté ou si le processus de règlement est bloqué en raison de défis malveillants.
Le fardeau de la preuve de fraude
Pour soutenir l'hypothèse ci-dessus, le L2 Optimistic doit prendre en charge un mécanisme de preuve de fraude (également appelé protocole de résolution des litiges), qui permet aux validateurs (challengers) de contester les propositions d'état potentiellement erronées soumises par les ordonneurs (proposants). Ce mécanisme doit garantir deux caractéristiques clés :
Toutes les propositions d'état incorrectes peuvent être identifiées,
Un défi erroné ne réussira jamais.
D'un point de vue technique, ce mécanisme comprend deux composants essentiels :
Sous-protocole de défi : gérer les litiges concernant une seule proposition d'état.
Mécanisme de tournoi : Lorsqu'un même bloc présente plusieurs propositions d'état concurrentes, il est utilisé pour sélectionner la seule proposition correcte.
Chaque proposition d'état est une déclaration des résultats d'exécution d'un ensemble de transactions, généralement composée de trois parties :
État initial : Le dernier état L2 d'Ethereum récemment confirmé.
Charge de transaction : une série de transactions L2 survenues depuis cet état ;
État final : Le proposeur affirme le résultat obtenu après l'exécution de ces transactions.
Ainsi, une proposition complète dit essentiellement :
"Supposons que l'état initial actuel soit A, en exécutant la liste de transactions suivante (payload), je pense que l'état final devrait être X."
Nous pouvons visualiser cette structure sous la forme du graphique ci-dessous :
À ce moment-là, le rôle du sous-protocole de défi est de vérifier si cette affirmation est correcte. Si elle est incorrecte, le défi doit réussir et la proposition doit être rejetée.
Preuve de défaillance interactive (jeu de défi à deux parties)
Dans la plupart des systèmes de rollup optimistes actuellement dominants, un protocole interactif est utilisé : un challenger et un proposeur s'affrontent dans des échanges.
Une fois le litige soulevé, les deux parties procéderont à une démarche binaire des résultats intermédiaires du processus de calcul (les résultats d'exécution à chaque étape revendiqués par le proposeur), réduisant progressivement la portée des erreurs potentielles. Ce processus sera continuellement récursif jusqu'à ce que les deux parties localisent une seule étape de calcul erronée (par exemple, une transaction exécutée de manière incorrecte).
Une fois l'erreur spécifique déterminée, cette étape sera réexécutée sur le réseau principal Ethereum pour déterminer s'il existe réellement une fraude.
Mais ce mécanisme présente plusieurs problèmes :
Délai élevé : Chaque interaction nécessite de lancer une transaction sur la chaîne Ethereum. Un processus complet de résolution de litige peut prendre plusieurs heures voire plusieurs jours, en particulier en cas de congestion du réseau ou de censure ;
Exigences élevées pour le proposeur : Même si le proposeur est honnête et que le défi est sans fondement, il doit tout de même participer à l'ensemble du processus de contestation, ce qui entraîne des coûts de calcul et d'interaction sur la chaîne non négligeables ;
Facilement exploitable : Des challengers malveillants peuvent constamment soumettre des défis infondés, forçant les proposeurs honnêtes à gaspiller sans cesse du temps et des frais de gas pour défendre l'état correct.
Dans la réalité, la preuve de fraude interactive est coûteuse, fragile en période de forte charge et facilement sujette à abus.
Preuve de fraude non interactive (Modèle de défi ZK)
MegaETH emprunte un chemin complètement différent : il exige que le challenger génère uniquement une preuve de connaissance nulle (ZKP) concise pour prouver que l'état final déclaré par le proposeur est invalide.
Plus précisément, cette preuve ZK indique que l'exécution de la séquence de transactions à partir de l'état initial ne produira pas l'état final revendiqué par le proposeur. Ce mécanisme sera construit sur le zkVM de RISC Zero et s'inspirera de l'architecture hybride de preuve de fraude non interactive d'OP Kailua pour sa mise en œuvre.
Cette preuve est soumise à Ethereum par une transaction unique, le contrat de validateurs sur la chaîne confirmera sa validité. Le soumissionnaire de la preuve n'a pas besoin de participer à aucun travail, ne peut pas interférer dans le processus entier et ne participe pas aux litiges.
Bien sûr, générer une telle preuve ZK n'est pas une tâche facile — cela nécessite d'exécuter complètement le processus de calcul contesté dans une machine virtuelle zk, ce qui devrait coûter environ 100 milliards de cycles de calcul, et dans le pire des cas, le coût est d'environ 100 dollars. Cependant, ce coût n'intervient que lorsque la fraude est prouvée, et selon la conception, il est supporté par la partie malhonnête. Ce modèle allège considérablement la pression financière sur les challengers honnêtes et élimine fondamentalement le risque de sabotage malveillant dans le mécanisme binaire.
ZK utilisé pour la preuve de fraude, et non pour la validité de l'état
Dans le domaine de la cryptographie, "Zero-Knowledge (ZK)" est souvent simplifié comme synonyme de ZK Rollup - c'est-à-dire un système qui utilise des preuves ZK pour valider hors chaîne les transitions d'état, puis les publier sur la chaîne. Mais cette compréhension ne couvre en réalité qu'une moitié du potentiel des ZK.
Le but de MegaETH utilisant des preuves à divulgation nulle de connaissance n'est pas de vérifier la justesse des états, mais de prouver des comportements frauduleux. Cela nous permet d'ajouter un mécanisme sans confiance et non interactif pour détecter et contester des transitions d'état invalides, tout en conservant l'efficacité et l'évolutivité des Optimistic Rollups.
Nous appelons cette approche hybride preuve de fraude ZK, qui introduit un modèle de confiance fondamentalement différent.
La fenêtre de détection reste inchangée, le temps de fin est considérablement réduit
Pour des raisons de sécurité et de prudence, MegaETH conservera toujours une fenêtre de contestation de 7 jours typique des chaînes Optimistic, ce qui signifie que tout participant a une semaine entière pour contester un certain état racine. Mais la véritable différence se produit après qu'une contestation a été soulevée. Dans un modèle interactif, si une contestation est soulevée le 7ème jour, il pourrait encore falloir quelques jours supplémentaires pour résoudre la contestation. Pendant ce temps, la finalité de la chaîne sur le réseau principal Ethereum sera gelée, les progrès du protocole seront interrompus et l'activité de la chaîne sera également affectée.
Dans le cas d'une preuve de fraude ZK, l'ensemble du processus de litige sera terminé en environ 1 heure. Le challenger génère une preuve ZK, la soumet au réseau principal Ethereum, et elle prend effet immédiatement après vérification, l'état de la chaîne acquérant rapidement une finalité. Cela protège efficacement contre un vecteur d'attaque clé : des challengers malveillants qui lancent des litiges frauduleux à plusieurs reprises pour entraver la finalité de la chaîne.
Garanties de disponibilité des données fournies par EigenDA
Pour garantir l'intégrité du processus de preuve de fraude, le challenger doit pouvoir accéder facilement et de manière fiable aux données de bloc d'origine afin de reproduire le processus de calcul contesté.
C'est précisément la raison pour laquelle nous utilisons le modèle de fraude ZK avec EigenDA (une couche de disponibilité des données décentralisée et à haut débit).
Grâce à cette structure, l'ensemble du processus est simplifié sous la forme la plus sécurisée et la plus efficace :
Le sélecteur publie des données de blocs sur EigenDA, tout en soumettant uniquement un petit résumé des données sur Ethereum. Les garanties cryptographiques fournies par EigenDA garantissent qu'il est toujours possible de générer des preuves de fraude, et que le sélecteur ne peut pas "cacher" les données pour échapper à l'examen ;
Tout observateur peut récupérer les données de blocs depuis EigenDA, reconstruire des blocs complets et les exécuter dans zkVM ;
Une fois la fraude détectée, l'observateur peut générer une preuve de fraude ZK concise, soumise au contrat de validation sur Ethereum ; le triant sera pénalisé et sa proposition invalide sera rejetée.
Un modèle de confiance sécurisé et évolutif
MegaETH remplace le preuve de fraude ZK non interactive simple aux jeux de fraude interactifs complexes. Cette approche élimine le risque d'attaques de harcèlement, réduit considérablement le temps de confirmation finale et garantit que les litiges peuvent être résolus de manière efficace et évolutive.
Avec la capacité de calcul vérifiable fournie par RiscZero et le soutien d'@eigen_da pour l'accès aux données brutes, chaque proposition d'état dispose de :
Reconstructibilité, vérifiabilité, possibilité d'être contesté par quiconque - peu importe l'échelle.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
La bataille finale : comment utilisons-nous la technologie ZK pour protéger la sécurité de MegaETH
Auteur : MegaETH Source : @megaeth_labs Traduction : Shan Ouba, Jinse Caijing
Au cœur de tous les Optimistic Rollups, il existe une hypothèse clé : les propositions d'état soumises sont par défaut valides tant qu'elles n'ont pas été prouvées fausses. Cependant, cette hypothèse ne tient que si le Rollup dispose d'un mécanisme de preuve de fraude robuste. Les chaînes manquant de ce mécanisme deviennent immédiatement non sécurisées si un état invalide n'est pas contesté ou si le processus de règlement est bloqué en raison de défis malveillants.
Le fardeau de la preuve de fraude
Pour soutenir l'hypothèse ci-dessus, le L2 Optimistic doit prendre en charge un mécanisme de preuve de fraude (également appelé protocole de résolution des litiges), qui permet aux validateurs (challengers) de contester les propositions d'état potentiellement erronées soumises par les ordonneurs (proposants). Ce mécanisme doit garantir deux caractéristiques clés :
D'un point de vue technique, ce mécanisme comprend deux composants essentiels :
Chaque proposition d'état est une déclaration des résultats d'exécution d'un ensemble de transactions, généralement composée de trois parties :
Ainsi, une proposition complète dit essentiellement :
"Supposons que l'état initial actuel soit A, en exécutant la liste de transactions suivante (payload), je pense que l'état final devrait être X."
Nous pouvons visualiser cette structure sous la forme du graphique ci-dessous :
À ce moment-là, le rôle du sous-protocole de défi est de vérifier si cette affirmation est correcte. Si elle est incorrecte, le défi doit réussir et la proposition doit être rejetée.
Preuve de défaillance interactive (jeu de défi à deux parties)
Dans la plupart des systèmes de rollup optimistes actuellement dominants, un protocole interactif est utilisé : un challenger et un proposeur s'affrontent dans des échanges.
Une fois le litige soulevé, les deux parties procéderont à une démarche binaire des résultats intermédiaires du processus de calcul (les résultats d'exécution à chaque étape revendiqués par le proposeur), réduisant progressivement la portée des erreurs potentielles. Ce processus sera continuellement récursif jusqu'à ce que les deux parties localisent une seule étape de calcul erronée (par exemple, une transaction exécutée de manière incorrecte).
Une fois l'erreur spécifique déterminée, cette étape sera réexécutée sur le réseau principal Ethereum pour déterminer s'il existe réellement une fraude.
Mais ce mécanisme présente plusieurs problèmes :
Dans la réalité, la preuve de fraude interactive est coûteuse, fragile en période de forte charge et facilement sujette à abus.
Preuve de fraude non interactive (Modèle de défi ZK)
MegaETH emprunte un chemin complètement différent : il exige que le challenger génère uniquement une preuve de connaissance nulle (ZKP) concise pour prouver que l'état final déclaré par le proposeur est invalide.
Plus précisément, cette preuve ZK indique que l'exécution de la séquence de transactions à partir de l'état initial ne produira pas l'état final revendiqué par le proposeur. Ce mécanisme sera construit sur le zkVM de RISC Zero et s'inspirera de l'architecture hybride de preuve de fraude non interactive d'OP Kailua pour sa mise en œuvre.
Cette preuve est soumise à Ethereum par une transaction unique, le contrat de validateurs sur la chaîne confirmera sa validité. Le soumissionnaire de la preuve n'a pas besoin de participer à aucun travail, ne peut pas interférer dans le processus entier et ne participe pas aux litiges.
Bien sûr, générer une telle preuve ZK n'est pas une tâche facile — cela nécessite d'exécuter complètement le processus de calcul contesté dans une machine virtuelle zk, ce qui devrait coûter environ 100 milliards de cycles de calcul, et dans le pire des cas, le coût est d'environ 100 dollars. Cependant, ce coût n'intervient que lorsque la fraude est prouvée, et selon la conception, il est supporté par la partie malhonnête. Ce modèle allège considérablement la pression financière sur les challengers honnêtes et élimine fondamentalement le risque de sabotage malveillant dans le mécanisme binaire.
ZK utilisé pour la preuve de fraude, et non pour la validité de l'état
Dans le domaine de la cryptographie, "Zero-Knowledge (ZK)" est souvent simplifié comme synonyme de ZK Rollup - c'est-à-dire un système qui utilise des preuves ZK pour valider hors chaîne les transitions d'état, puis les publier sur la chaîne. Mais cette compréhension ne couvre en réalité qu'une moitié du potentiel des ZK.
Le but de MegaETH utilisant des preuves à divulgation nulle de connaissance n'est pas de vérifier la justesse des états, mais de prouver des comportements frauduleux. Cela nous permet d'ajouter un mécanisme sans confiance et non interactif pour détecter et contester des transitions d'état invalides, tout en conservant l'efficacité et l'évolutivité des Optimistic Rollups.
Nous appelons cette approche hybride preuve de fraude ZK, qui introduit un modèle de confiance fondamentalement différent.
La fenêtre de détection reste inchangée, le temps de fin est considérablement réduit
Pour des raisons de sécurité et de prudence, MegaETH conservera toujours une fenêtre de contestation de 7 jours typique des chaînes Optimistic, ce qui signifie que tout participant a une semaine entière pour contester un certain état racine. Mais la véritable différence se produit après qu'une contestation a été soulevée. Dans un modèle interactif, si une contestation est soulevée le 7ème jour, il pourrait encore falloir quelques jours supplémentaires pour résoudre la contestation. Pendant ce temps, la finalité de la chaîne sur le réseau principal Ethereum sera gelée, les progrès du protocole seront interrompus et l'activité de la chaîne sera également affectée.
Dans le cas d'une preuve de fraude ZK, l'ensemble du processus de litige sera terminé en environ 1 heure. Le challenger génère une preuve ZK, la soumet au réseau principal Ethereum, et elle prend effet immédiatement après vérification, l'état de la chaîne acquérant rapidement une finalité. Cela protège efficacement contre un vecteur d'attaque clé : des challengers malveillants qui lancent des litiges frauduleux à plusieurs reprises pour entraver la finalité de la chaîne.
Garanties de disponibilité des données fournies par EigenDA
Pour garantir l'intégrité du processus de preuve de fraude, le challenger doit pouvoir accéder facilement et de manière fiable aux données de bloc d'origine afin de reproduire le processus de calcul contesté.
C'est précisément la raison pour laquelle nous utilisons le modèle de fraude ZK avec EigenDA (une couche de disponibilité des données décentralisée et à haut débit).
Grâce à cette structure, l'ensemble du processus est simplifié sous la forme la plus sécurisée et la plus efficace :
Un modèle de confiance sécurisé et évolutif
MegaETH remplace le preuve de fraude ZK non interactive simple aux jeux de fraude interactifs complexes. Cette approche élimine le risque d'attaques de harcèlement, réduit considérablement le temps de confirmation finale et garantit que les litiges peuvent être résolus de manière efficace et évolutive.
Avec la capacité de calcul vérifiable fournie par RiscZero et le soutien d'@eigen_da pour l'accès aux données brutes, chaque proposition d'état dispose de :
Reconstructibilité, vérifiabilité, possibilité d'être contesté par quiconque - peu importe l'échelle.