Note de l’éditeur : Pendant longtemps, la discussion sur les trois phases de la sécurité du rollup Ethereum a été au centre de la communauté écologique Ethereum, ce qui n’est pas seulement lié à la stabilité opérationnelle du réseau principal Ethereum et du réseau L2, mais également lié au développement réel du réseau L2. Récemment, Daniel Wang, membre de la communauté Ethereum, a proposé l’étiquette de dénomination #BattleTested pour la phase 2 du réseau L2 sur la plate-forme X, arguant que seuls les réseaux L2 avec le code et la configuration actuels qui sont en ligne sur le réseau principal Ethereum depuis plus de 6 mois et ont maintenu une valeur totale de blocage (TVL) de plus de 100 millions de dollars et au moins 50 millions de dollars en ETH et les principaux stablecoins peuvent obtenir ce titre, et le titre est évalué dynamiquement pour éviter les « fantômes on-chain ». 」。 Le cofondateur d’Ethereum, Vitalik, a ensuite donné une réponse détaillée à cette question et a partagé son point de vue, compilé par Odaily Planet Daily ci-dessous.
Les 3 grandes étapes du réseau L2 : de 0 à 1 puis à 2, la sécurité est déterminée par la part de gouvernance.
Les trois phases de la sécurité des rollups Ethereum peuvent être déterminées en fonction du moment où le comité de sécurité peut couvrir les composants sans confiance (c'est-à-dire purement cryptographiques ou théoriques des jeux) :
Phase 0 : Le comité de sécurité a un contrôle total. Il peut y avoir un système de preuve en cours d'exécution (mode Optimism ou ZK), mais le comité de sécurité peut le renverser par un simple mécanisme de vote à la majorité. Par conséquent, le système de preuve n'est que de nature « consultative ».
Étape 1 : Le comité de sécurité a besoin de 75 % (au moins 6/8) d'approbation pour couvrir le système opérationnel. Il doit y avoir un quorum pour empêcher un sous-ensemble (comme ≥ 3) en dehors de l'organisation principale. Par conséquent, la difficulté de contrôler le système de preuve est relativement élevée, mais pas insurmontable.
Étape 2 : Le comité de sécurité ne peut agir que dans le cas d'une erreur prouvable. Par exemple, une erreur prouvable pourrait être le fait que deux systèmes de preuve redondants (comme OP et ZK) se contredisent. S'il y a une erreur prouvable, il ne peut choisir qu'une des réponses proposées : il ne peut pas répondre arbitrairement à un mécanisme.
Nous pouvons utiliser le graphique ci-dessous pour représenter la « part de vote » que possède le comité de sécurité à différentes étapes :
Structure de vote de gouvernance en trois phases
Une question importante est : quels sont les moments optimaux pour la transition du réseau L2 de la phase 0 à la phase 1, ainsi que pour son développement de la phase 1 à la phase 2 ?
La seule raison valable de ne pas entrer immédiatement dans la phase 2 est que vous ne pouvez pas faire entièrement confiance au système de preuve - c'est une inquiétude compréhensible : ce système est composé d'un grand nombre de lignes de code, et si le code présente des vulnérabilités, alors un attaquant pourrait voler les actifs de tous les utilisateurs. Plus votre confiance dans le système de preuve est forte (ou inversement, plus votre confiance dans le comité de sécurité est faible), plus vous voudrez faire avancer l'ensemble de l'écosystème réseau vers la phase suivante.
En fait, nous pouvons quantifier cela à l'aide d'un modèle mathématique simplifié. Tout d'abord, énumérons les hypothèses :
Chaque membre du comité de sécurité a 10 % de chances de « défaillance unique » ;
Nous considérons les défaillances d'activité (refus de signer un contrat ou clé indisponible) et les défaillances de sécurité (signature d'éléments erronés ou clé piratée) comme des événements d'égale probabilité. En réalité, nous supposons uniquement une catégorie de « défaillance », où les membres du conseil de sécurité des défaillances ont à la fois signé des éléments erronés et n'ont pas réussi à signer des éléments corrects.
Au stade 0, le critère de jugement du comité de sécurité est de 4/7, au stade 1, il est de 6/8 ;
Nous supposons qu'il existe un système de preuve unique (par rapport au mécanisme de conception à 2/3, le comité de sécurité peut trancher en cas de désaccord). Par conséquent, à l'étape 2, l'existence du comité de sécurité est totalement sans importance.
Dans ces hypothèses, en tenant compte de la probabilité spécifique d'effondrement du système de preuve, nous souhaitons minimiser la possibilité d'effondrement du réseau L2.
Nous pouvons utiliser une distribution binomiale pour accomplir ce travail :
Si chaque membre du conseil de sécurité a 10% de chances de défaillance indépendante, alors la probabilité qu'au moins 4 sur 7 échouent est ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728. Par conséquent, le système d'intégration à l'étape 0 a une probabilité d'échec fixe de 0.2728%.
L'intégration de la phase 1 peut également échouer si le système de preuve échoue et que le mécanisme de vérification du comité de sécurité échoue ≥ 3 fois, rendant impossible la couverture du calcul réseau (probabilité ∑𝑖= 38( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.03809179 multiplié par le taux d'échec du système de preuve), ou si le comité de sécurité échoue 6 fois ou plus, il peut forcer la génération d'une réponse de calcul incorrecte (fixe ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 probabilité);
La probabilité d'échec de la fusion à la phase 2 est cohérente avec la probabilité d'échec du système de preuve.
Ici présenté sous forme de graphique :
Probabilité de défaillance du système de preuve à différentes étapes du réseau L2
Comme le résultat suggéré ci-dessus, avec l'amélioration de la qualité du système de preuve, la meilleure phase passe de la phase 0 à la phase 1, puis de la phase 1 à la phase 2. Utiliser un système de preuve de qualité de phase 0 pour faire fonctionner le réseau en phase 2 est le pire résultat.
Maintenant, veuillez noter que les hypothèses dans le modèle simplifié ci-dessus ne sont pas parfaites :
Dans la réalité, les membres du comité de sécurité ne sont pas complètement indépendants, (il peut exister entre eux) des « défaillances de mode commun » : ils peuvent conspirer ensemble, ou être tous soumis à la même coercition ou attaque de hackers, etc. L'exigence d'un quorum en dehors de l'organisation principale pour empêcher un sous-ensemble a pour but d'éviter que cela ne se produise, mais ce n'est toujours pas parfait.
Le système de preuve lui-même peut être composé de plusieurs systèmes indépendants combinés (je l'ai préconisé dans mon blog précédent). Dans ce cas, (i) la probabilité que le système de preuve échoue est très basse, et (ii) même à la phase 2, le comité de sécurité est également important car il est clé pour résoudre les litiges.
Ces deux arguments montrent que, par rapport au graphique, la phase 1 et la phase 2 sont plus attrayantes.
Si vous croyez aux mathématiques, alors l’existence de l’étape 1 ne sera presque jamais justifiée : vous devriez passer directement à l’étape 1. La principale objection que j’ai entendue est la suivante : si une erreur critique se produit, il peut être difficile d’obtenir rapidement les signatures de 6 des 8 membres du comité de sécurité pour la corriger. Mais il existe une solution simple : donner à tout membre du Comité de sécurité le pouvoir de retarder les retraits de 1 à 2 semaines, en donnant aux autres suffisamment de temps pour prendre des mesures (correctives).
Cependant, il est également erroné de passer prématurément à la phase 2, surtout si le travail de transition vers la phase 2 se fait au détriment du renforcement du système de preuve sous-jacent. Idéalement, des fournisseurs de données comme L2Beat devraient montrer des audits du système de preuve et des indicateurs de maturité (de préférence des indicateurs de mise en œuvre du système de preuve plutôt que ceux de l'ensemble de la synthèse, afin que nous puissions les réutiliser) et présenter les étapes.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Nouvel article de Vitalik : Une discussion sur les principes mathématiques de la division raisonnable des phases L2
Rédigé par : Vitalik Buterin
Compilation : Wenser, Odaily Planet Daily
Note de l’éditeur : Pendant longtemps, la discussion sur les trois phases de la sécurité du rollup Ethereum a été au centre de la communauté écologique Ethereum, ce qui n’est pas seulement lié à la stabilité opérationnelle du réseau principal Ethereum et du réseau L2, mais également lié au développement réel du réseau L2. Récemment, Daniel Wang, membre de la communauté Ethereum, a proposé l’étiquette de dénomination #BattleTested pour la phase 2 du réseau L2 sur la plate-forme X, arguant que seuls les réseaux L2 avec le code et la configuration actuels qui sont en ligne sur le réseau principal Ethereum depuis plus de 6 mois et ont maintenu une valeur totale de blocage (TVL) de plus de 100 millions de dollars et au moins 50 millions de dollars en ETH et les principaux stablecoins peuvent obtenir ce titre, et le titre est évalué dynamiquement pour éviter les « fantômes on-chain ». 」。 Le cofondateur d’Ethereum, Vitalik, a ensuite donné une réponse détaillée à cette question et a partagé son point de vue, compilé par Odaily Planet Daily ci-dessous.
Les 3 grandes étapes du réseau L2 : de 0 à 1 puis à 2, la sécurité est déterminée par la part de gouvernance.
Les trois phases de la sécurité des rollups Ethereum peuvent être déterminées en fonction du moment où le comité de sécurité peut couvrir les composants sans confiance (c'est-à-dire purement cryptographiques ou théoriques des jeux) :
Phase 0 : Le comité de sécurité a un contrôle total. Il peut y avoir un système de preuve en cours d'exécution (mode Optimism ou ZK), mais le comité de sécurité peut le renverser par un simple mécanisme de vote à la majorité. Par conséquent, le système de preuve n'est que de nature « consultative ».
Étape 1 : Le comité de sécurité a besoin de 75 % (au moins 6/8) d'approbation pour couvrir le système opérationnel. Il doit y avoir un quorum pour empêcher un sous-ensemble (comme ≥ 3) en dehors de l'organisation principale. Par conséquent, la difficulté de contrôler le système de preuve est relativement élevée, mais pas insurmontable.
Étape 2 : Le comité de sécurité ne peut agir que dans le cas d'une erreur prouvable. Par exemple, une erreur prouvable pourrait être le fait que deux systèmes de preuve redondants (comme OP et ZK) se contredisent. S'il y a une erreur prouvable, il ne peut choisir qu'une des réponses proposées : il ne peut pas répondre arbitrairement à un mécanisme.
Nous pouvons utiliser le graphique ci-dessous pour représenter la « part de vote » que possède le comité de sécurité à différentes étapes :
Structure de vote de gouvernance en trois phases
Une question importante est : quels sont les moments optimaux pour la transition du réseau L2 de la phase 0 à la phase 1, ainsi que pour son développement de la phase 1 à la phase 2 ?
La seule raison valable de ne pas entrer immédiatement dans la phase 2 est que vous ne pouvez pas faire entièrement confiance au système de preuve - c'est une inquiétude compréhensible : ce système est composé d'un grand nombre de lignes de code, et si le code présente des vulnérabilités, alors un attaquant pourrait voler les actifs de tous les utilisateurs. Plus votre confiance dans le système de preuve est forte (ou inversement, plus votre confiance dans le comité de sécurité est faible), plus vous voudrez faire avancer l'ensemble de l'écosystème réseau vers la phase suivante.
En fait, nous pouvons quantifier cela à l'aide d'un modèle mathématique simplifié. Tout d'abord, énumérons les hypothèses :
Chaque membre du comité de sécurité a 10 % de chances de « défaillance unique » ;
Nous considérons les défaillances d'activité (refus de signer un contrat ou clé indisponible) et les défaillances de sécurité (signature d'éléments erronés ou clé piratée) comme des événements d'égale probabilité. En réalité, nous supposons uniquement une catégorie de « défaillance », où les membres du conseil de sécurité des défaillances ont à la fois signé des éléments erronés et n'ont pas réussi à signer des éléments corrects.
Au stade 0, le critère de jugement du comité de sécurité est de 4/7, au stade 1, il est de 6/8 ;
Nous supposons qu'il existe un système de preuve unique (par rapport au mécanisme de conception à 2/3, le comité de sécurité peut trancher en cas de désaccord). Par conséquent, à l'étape 2, l'existence du comité de sécurité est totalement sans importance.
Dans ces hypothèses, en tenant compte de la probabilité spécifique d'effondrement du système de preuve, nous souhaitons minimiser la possibilité d'effondrement du réseau L2.
Nous pouvons utiliser une distribution binomiale pour accomplir ce travail :
Si chaque membre du conseil de sécurité a 10% de chances de défaillance indépendante, alors la probabilité qu'au moins 4 sur 7 échouent est ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728. Par conséquent, le système d'intégration à l'étape 0 a une probabilité d'échec fixe de 0.2728%.
L'intégration de la phase 1 peut également échouer si le système de preuve échoue et que le mécanisme de vérification du comité de sécurité échoue ≥ 3 fois, rendant impossible la couverture du calcul réseau (probabilité ∑𝑖= 38( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.03809179 multiplié par le taux d'échec du système de preuve), ou si le comité de sécurité échoue 6 fois ou plus, il peut forcer la génération d'une réponse de calcul incorrecte (fixe ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 probabilité);
La probabilité d'échec de la fusion à la phase 2 est cohérente avec la probabilité d'échec du système de preuve.
Ici présenté sous forme de graphique :
Probabilité de défaillance du système de preuve à différentes étapes du réseau L2
Comme le résultat suggéré ci-dessus, avec l'amélioration de la qualité du système de preuve, la meilleure phase passe de la phase 0 à la phase 1, puis de la phase 1 à la phase 2. Utiliser un système de preuve de qualité de phase 0 pour faire fonctionner le réseau en phase 2 est le pire résultat.
Maintenant, veuillez noter que les hypothèses dans le modèle simplifié ci-dessus ne sont pas parfaites :
Dans la réalité, les membres du comité de sécurité ne sont pas complètement indépendants, (il peut exister entre eux) des « défaillances de mode commun » : ils peuvent conspirer ensemble, ou être tous soumis à la même coercition ou attaque de hackers, etc. L'exigence d'un quorum en dehors de l'organisation principale pour empêcher un sous-ensemble a pour but d'éviter que cela ne se produise, mais ce n'est toujours pas parfait.
Le système de preuve lui-même peut être composé de plusieurs systèmes indépendants combinés (je l'ai préconisé dans mon blog précédent). Dans ce cas, (i) la probabilité que le système de preuve échoue est très basse, et (ii) même à la phase 2, le comité de sécurité est également important car il est clé pour résoudre les litiges.
Ces deux arguments montrent que, par rapport au graphique, la phase 1 et la phase 2 sont plus attrayantes.
Si vous croyez aux mathématiques, alors l’existence de l’étape 1 ne sera presque jamais justifiée : vous devriez passer directement à l’étape 1. La principale objection que j’ai entendue est la suivante : si une erreur critique se produit, il peut être difficile d’obtenir rapidement les signatures de 6 des 8 membres du comité de sécurité pour la corriger. Mais il existe une solution simple : donner à tout membre du Comité de sécurité le pouvoir de retarder les retraits de 1 à 2 semaines, en donnant aux autres suffisamment de temps pour prendre des mesures (correctives).
Cependant, il est également erroné de passer prématurément à la phase 2, surtout si le travail de transition vers la phase 2 se fait au détriment du renforcement du système de preuve sous-jacent. Idéalement, des fournisseurs de données comme L2Beat devraient montrer des audits du système de preuve et des indicateurs de maturité (de préférence des indicateurs de mise en œuvre du système de preuve plutôt que ceux de l'ensemble de la synthèse, afin que nous puissions les réutiliser) et présenter les étapes.