Nous savons tous que OP-Rollup a une période de défi de 7 jours. Le problème est qu'aucun test de combat efficace n'a eu lieu jusqu'à présent. On pensait à l'origine qu'il était optimiste, mais de manière inattendue, il s'est avéré vraiment "optimiste" ?
Pourquoi OP-Rollup conteste-t-il rarement les cas ? Que se passera-t-il si le Séquenceur est autorisé à faire le mal sans défi ? OP Stack est-il un autre mouvement compensatoire ? Dans quelle mesure le BOLD d'Arbitrum peut-il être utile ? Après avoir lu cet article, vous aurez peut-être une compréhension plus approfondie d'OP-Rollup.
Pour faire simple, la chaîne layer2 regroupera un grand nombre de transactions sur le réseau principal. Le réseau principal confirmera que les transactions L2 ont passé l'étape de vérification de validation avant de changer de statut. La méthode de vérification OP-Rollup actuelle est anti-fraude. , c'est-à-dire tous les validateurs de la chaîne L2. Vous pouvez lancer un défi pour soulever des questions. Dans les 7 jours, si le challenger réussit, le réseau principal rejettera le dernier changement d'état et L2 devra reconditionner et soumettre une nouvelle déclaration d'état. Si le challenger échoue, les actifs promis seront confisqués.
Ce modèle de soumission d'abord, puis de défi est très logique. Après tout, le but de la couche 2 en tant que couche d'extension est de donner la priorité à l'efficacité. Cependant, il faut qu’un véritable « défi » se produise, n’est-ce pas ? Même s'il y a peu de défis, c'est logique : il n'y a pas de défis, mais c'est un peu déraisonnable de faire croire à tout le monde que la chaîne L2 ne fera pas le mal à 100 %.
A ce stade, Optimism n'a pas de mécanisme de challenge. Si vous demandez, ils vous diront En Développement. On ne sait pas s'il y a un développement réel, mais si son Séquenceur est centralisé, il n'y a vraiment pas besoin de challenger à ce stade. Voulez-vous vous gifler ? La table du réseau principal est-elle fidèle ? Arbitrum dispose de son propre mécanisme de défi bêta interne BOLD, qui tente de faire passer l'objet de défi d'autorisé à sans autorisation, ouvrant ainsi la voie à la décentralisation de Sequencer.
Étant donné que le mécanisme de défi est en fait un mécanisme d'auto-correction, si un défi survient, il retardera le fonctionnement du réseau ou, dans le pire des cas, provoquera des temps d'arrêt. Nous n'encouragerons pas activement l'apparition de défis à moins que cela ne soit absolument nécessaire. Si le mécanisme d'incitation au défi est conçu de manière déraisonnable et que certains nœuds malveillants sont prêts à payer beaucoup d'argent pour contester, il est tout à fait possible que l'objectif soit de provoquer le crash du réseau à cause de malfaiteurs. Par conséquent, les acteurs de la couche 2 sur la piste OP-Rollup seront très prudents en ce qui concerne la conception du mécanisme de défi.
Alors, que se passera-t-il si nous ne contestons pas ? Un exemple simple : la couche 2 peut créer une fausse transaction de transfert dans Sequencer, puis le validateur réussit la vérification. Après confirmation du réseau principal, le transfert généré à partir de rien sera légalement retiré sur le réseau principal. L'impact sur le réseau de la couche 2 on peut l'imaginer. .
Maintenant que le Sequencer est centralisé, vous n’avez plus à vous soucier de ce problème. C’est très simple. Cela n’a pas de sens de transférer vos actifs entre la main gauche et la main droite. Mais que se passe-t-il si Sequencer est décentralisé ? Si un voleur apparaît à l’un de ces nœuds, ce problème deviendra inévitable.
Dans une certaine mesure, le scénario d'Optimism est que le séquenceur doit être centralisé parce qu'il a peur d'être contesté de manière malveillante. Parce que le séquenceur est centralisé, il n'est pas nécessaire de le contester. Eh bien, c'est logique.
Mais cette histoire n’est visiblement pas assez attractive pour Pitching. Par conséquent, Optimism a choisi la méthode distribuée douce d'OP Stack pour résoudre le problème de la centralisation du séquenceur. Parce que si un jour, la famille SuperChain est formée, chacun des membres de la famille OP Stack aura un siège dans les sièges de gouvernance et de prise de décision du Sequencer, et gouvernera et prendra des décisions conjointement. N'est-ce pas aussi une restriction sur le risque d'un seul -une centralisation ponctuelle ? À l'heure actuelle, Optimism fait progresser la pile OP assez rapidement, au moins plus rapidement que le mécanisme challenger en développement...
Le script d'Arbitrum est relativement honnête. Puisque tout le monde veut voir le mode défi se produire, Arbitrum construira un ensemble de modes. Bold lors de tests internes le fait. J'ai étudié clairement le mécanisme de fonctionnement complexe de Bold. Prenons l'essence et simplifions-la. et partagez-le :
Layer2 publie une déclaration d'assertion de statut dans le contrat de cumul du réseau principal ;
Challenge Manage remet en question l'assertion, puis lance un défi ;
Chaque fois qu'une contestation est lancée, un actif doit être mis en gage, puis la partie contestée peut soumettre des preuves à Edge Tracker, y compris les changements de statut, les appels de fonction, les paramètres et autres détails d'exécution de chaque étape passée ;
Si le challenger n'est pas d'accord avec les preuves cette fois, il doit continuer à mettre en gage ses actifs et à continuer de contester, mais cela coûtera de l'argent à chaque fois ;
L'observateur de chaîne tiers surveille les preuves soumises pendant le processus de contestation et donne une certaine référence pour déterminer quelle partie est honnête. Enfin, le contrat edgeChallengeManage détermine qui gagne et qui perd.
Si ce mode de défi audacieux est réellement appliqué, ce sera une bonne solution, mais réfléchissons-y de côté, pourquoi les challengers dépensent-ils de l'argent pour défier ? Le responsable a-t-il parlé des récompenses incitatives pour les défis réussis ? Si l'incitation est trop élevée, il y aura des gens qui contesteront à tout prix. Si l'incitation est trop faible, les gains ne seront pas à la hauteur des amendes. Donc, à mon avis, même si le mécanisme de défi BOLD est lancé à l'avenir, ce sera encore et encore comme des exercices militaires, et l'impact réel sera limité.
Imaginez, et si le défi réussissait ? Pendant la période de défi de 7 jours, si le challenger réussit, L2 effectuera tranquillement un hard fork. Qui peut le sentir ? De plus, pourquoi ne pas ajuster l'état du réseau en mettant à niveau le contrat Rollup du réseau principal ?
Par conséquent, l'impact du défi OP-Rollup sur les acteurs de la couche 2 n'est pas si grand, ce qui compte c'est la confiance et le consensus d'OP-Rollup dans l'esprit de chacun.
Voir l'original
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.
Les défis OP Rollup se produisent rarement, « l'hypothèse optimiste » est-elle correcte ?
Écrit par : Haotain
Nous savons tous que OP-Rollup a une période de défi de 7 jours. Le problème est qu'aucun test de combat efficace n'a eu lieu jusqu'à présent. On pensait à l'origine qu'il était optimiste, mais de manière inattendue, il s'est avéré vraiment "optimiste" ?
Pourquoi OP-Rollup conteste-t-il rarement les cas ? Que se passera-t-il si le Séquenceur est autorisé à faire le mal sans défi ? OP Stack est-il un autre mouvement compensatoire ? Dans quelle mesure le BOLD d'Arbitrum peut-il être utile ? Après avoir lu cet article, vous aurez peut-être une compréhension plus approfondie d'OP-Rollup.
Pour faire simple, la chaîne layer2 regroupera un grand nombre de transactions sur le réseau principal. Le réseau principal confirmera que les transactions L2 ont passé l'étape de vérification de validation avant de changer de statut. La méthode de vérification OP-Rollup actuelle est anti-fraude. , c'est-à-dire tous les validateurs de la chaîne L2. Vous pouvez lancer un défi pour soulever des questions. Dans les 7 jours, si le challenger réussit, le réseau principal rejettera le dernier changement d'état et L2 devra reconditionner et soumettre une nouvelle déclaration d'état. Si le challenger échoue, les actifs promis seront confisqués.
Ce modèle de soumission d'abord, puis de défi est très logique. Après tout, le but de la couche 2 en tant que couche d'extension est de donner la priorité à l'efficacité. Cependant, il faut qu’un véritable « défi » se produise, n’est-ce pas ? Même s'il y a peu de défis, c'est logique : il n'y a pas de défis, mais c'est un peu déraisonnable de faire croire à tout le monde que la chaîne L2 ne fera pas le mal à 100 %.
A ce stade, Optimism n'a pas de mécanisme de challenge. Si vous demandez, ils vous diront En Développement. On ne sait pas s'il y a un développement réel, mais si son Séquenceur est centralisé, il n'y a vraiment pas besoin de challenger à ce stade. Voulez-vous vous gifler ? La table du réseau principal est-elle fidèle ? Arbitrum dispose de son propre mécanisme de défi bêta interne BOLD, qui tente de faire passer l'objet de défi d'autorisé à sans autorisation, ouvrant ainsi la voie à la décentralisation de Sequencer.
Étant donné que le mécanisme de défi est en fait un mécanisme d'auto-correction, si un défi survient, il retardera le fonctionnement du réseau ou, dans le pire des cas, provoquera des temps d'arrêt. Nous n'encouragerons pas activement l'apparition de défis à moins que cela ne soit absolument nécessaire. Si le mécanisme d'incitation au défi est conçu de manière déraisonnable et que certains nœuds malveillants sont prêts à payer beaucoup d'argent pour contester, il est tout à fait possible que l'objectif soit de provoquer le crash du réseau à cause de malfaiteurs. Par conséquent, les acteurs de la couche 2 sur la piste OP-Rollup seront très prudents en ce qui concerne la conception du mécanisme de défi.
Alors, que se passera-t-il si nous ne contestons pas ? Un exemple simple : la couche 2 peut créer une fausse transaction de transfert dans Sequencer, puis le validateur réussit la vérification. Après confirmation du réseau principal, le transfert généré à partir de rien sera légalement retiré sur le réseau principal. L'impact sur le réseau de la couche 2 on peut l'imaginer. .
Maintenant que le Sequencer est centralisé, vous n’avez plus à vous soucier de ce problème. C’est très simple. Cela n’a pas de sens de transférer vos actifs entre la main gauche et la main droite. Mais que se passe-t-il si Sequencer est décentralisé ? Si un voleur apparaît à l’un de ces nœuds, ce problème deviendra inévitable.
Dans une certaine mesure, le scénario d'Optimism est que le séquenceur doit être centralisé parce qu'il a peur d'être contesté de manière malveillante. Parce que le séquenceur est centralisé, il n'est pas nécessaire de le contester. Eh bien, c'est logique.
Mais cette histoire n’est visiblement pas assez attractive pour Pitching. Par conséquent, Optimism a choisi la méthode distribuée douce d'OP Stack pour résoudre le problème de la centralisation du séquenceur. Parce que si un jour, la famille SuperChain est formée, chacun des membres de la famille OP Stack aura un siège dans les sièges de gouvernance et de prise de décision du Sequencer, et gouvernera et prendra des décisions conjointement. N'est-ce pas aussi une restriction sur le risque d'un seul -une centralisation ponctuelle ? À l'heure actuelle, Optimism fait progresser la pile OP assez rapidement, au moins plus rapidement que le mécanisme challenger en développement...
Le script d'Arbitrum est relativement honnête. Puisque tout le monde veut voir le mode défi se produire, Arbitrum construira un ensemble de modes. Bold lors de tests internes le fait. J'ai étudié clairement le mécanisme de fonctionnement complexe de Bold. Prenons l'essence et simplifions-la. et partagez-le :
Layer2 publie une déclaration d'assertion de statut dans le contrat de cumul du réseau principal ;
Challenge Manage remet en question l'assertion, puis lance un défi ;
Chaque fois qu'une contestation est lancée, un actif doit être mis en gage, puis la partie contestée peut soumettre des preuves à Edge Tracker, y compris les changements de statut, les appels de fonction, les paramètres et autres détails d'exécution de chaque étape passée ;
Si le challenger n'est pas d'accord avec les preuves cette fois, il doit continuer à mettre en gage ses actifs et à continuer de contester, mais cela coûtera de l'argent à chaque fois ;
L'observateur de chaîne tiers surveille les preuves soumises pendant le processus de contestation et donne une certaine référence pour déterminer quelle partie est honnête. Enfin, le contrat edgeChallengeManage détermine qui gagne et qui perd.
Si ce mode de défi audacieux est réellement appliqué, ce sera une bonne solution, mais réfléchissons-y de côté, pourquoi les challengers dépensent-ils de l'argent pour défier ? Le responsable a-t-il parlé des récompenses incitatives pour les défis réussis ? Si l'incitation est trop élevée, il y aura des gens qui contesteront à tout prix. Si l'incitation est trop faible, les gains ne seront pas à la hauteur des amendes. Donc, à mon avis, même si le mécanisme de défi BOLD est lancé à l'avenir, ce sera encore et encore comme des exercices militaires, et l'impact réel sera limité.
Imaginez, et si le défi réussissait ? Pendant la période de défi de 7 jours, si le challenger réussit, L2 effectuera tranquillement un hard fork. Qui peut le sentir ? De plus, pourquoi ne pas ajuster l'état du réseau en mettant à niveau le contrat Rollup du réseau principal ?
Par conséquent, l'impact du défi OP-Rollup sur les acteurs de la couche 2 n'est pas si grand, ce qui compte c'est la confiance et le consensus d'OP-Rollup dans l'esprit de chacun.