la combinaison de la gouvernance humaine et du mécanisme, la deuxième étape de la L2 est plus antifragile.
Rédaction : Vitalik Buterin
Traduit par : Wenser, Odaily Planet Daily
Note de l'éditeur : Depuis toujours, la discussion sur la sécurité des trois phases des rollups d'Ethereum est un point focal de l'écosystème Ethereum, ce qui concerne non seulement la stabilité opérationnelle du réseau principal d'Ethereum et des réseaux L2, mais aussi l'état réel de développement des réseaux L2. Récemment, Daniel Wang, membre de la communauté Ethereum, a proposé sur la plateforme X un label de nommage pour la phase Stage 2 des réseaux L2 : #BattleTested. Il estime que seuls les réseaux L2 dont le code et la configuration actuels sont en ligne sur le mainnet Ethereum depuis plus de 6 mois, et qui maintiennent une valeur totale verrouillée (TVL) supérieure à 100 millions de dollars, dont au moins 50 millions de dollars en ETH et en principales stablecoins, peuvent obtenir ce titre. Ce titre est évalué de manière dynamique afin d'éviter la création de "fantômes en chaîne". Vitalik Buterin, co-fondateur d'Ethereum, a ensuite fourni une réponse détaillée et partagé ses points de vue sur cette question, comme l'a traduit Odaily Planet Daily.
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.
La sécurité des rollups Ethereum peut être déterminée en fonction des trois étapes 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 opérationnel (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 est uniquement 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 les cas d'erreurs prouvables. Par exemple, une erreur prouvable peut être le fait que deux systèmes de preuve redondants (par exemple, OP et ZK) se contredisent. En cas d'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 » détenue par le comité de sécurité à différents stades :
Structure de vote de gouvernance en trois phases
Une question importante est : quels sont les moments optimaux pour la transition des réseaux L2 de la phase 0 à la phase 1, ainsi que 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 préoccupation compréhensible : le système est composé d'une grande quantité de code, et si le code présente des vulnérabilités, alors un attaquant pourrait voler tous les actifs des 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 du réseau vers la prochaine phase.
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 une probabilité de 10 % 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'une mauvaise affaire ou clé piratée) comme des événements d'égale probabilité. En réalité, nous ne supposons qu'une seule catégorie de « défaillance », où les membres du conseil de sécurité des défaillances ont à la fois signé des affaires incorrectes et ont échoué à signer des affaires correctes.
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 global unique (par rapport au mécanisme de conception 2/3, le comité de sécurité peut trancher en cas de désaccord entre les deux parties). Ainsi, à la phase 2, l'existence du comité de sécurité est complètement insignifiante.
Dans ces hypothèses, en tenant compte de la probabilité spécifique de l'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 des 7 échouent est ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728 Ainsi, le système intégré de la phase 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 validation 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 imposer de générer une réponse de calcul erronée (fixe ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 probabilité);
La probabilité d'échec de la fusion à l'étape 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 prévu, 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 l'exécution du réseau en phase 2 donne les pires résultats.
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 totalement indépendants, il peut exister des « modes de défaillance communs » entre eux : ils peuvent conspirer ensemble, ou être tous soumis aux mêmes pressions ou attaques de hackers, etc. L'objectif d'exiger un nombre minimum légal en dehors de l'organisation principale pour empêcher un sous-ensemble est 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 (j'ai préconisé cela dans mon précédent blog). Dans ce cas, (i) la probabilité d'effondrement du système de preuve est très faible, et (ii) même au stade 2, le comité de sécurité est également important, car il est la clé pour résoudre les litiges.
Ces deux arguments indiquent que les phases 1 et 2 sont plus attrayantes par rapport à ce qui est montré dans le graphique.
Si vous croyez en la mathématique, alors l'existence de la phase 1 ne sera presque jamais prouvée comme étant raisonnable : vous devriez entrer directement dans la phase 1. La principale objection que j'entends est la suivante : si une erreur cruciale se produit, il peut être difficile d'obtenir rapidement la signature de 6 membres sur 8 du comité de sécurité pour la corriger. Mais il existe une solution simple : donner à n'importe quel membre du comité de sécurité le pouvoir de retarder les retraits de 1 à 2 semaines, afin de donner aux autres le temps suffisant pour agir (de manière corrective).
En même temps, cependant, sauter trop tôt à la phase 2 est également une erreur, 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 présenter 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 des indicateurs de l'ensemble de la synthèse, afin que nous puissions les réutiliser), accompagnés d'une présentation de la phase.
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.
Nouvelle œuvre de Vitalik : Une discussion sur les principes mathématiques de la répartition raisonnable des étapes L2.
Rédaction : Vitalik Buterin
Traduit par : Wenser, Odaily Planet Daily
Note de l'éditeur : Depuis toujours, la discussion sur la sécurité des trois phases des rollups d'Ethereum est un point focal de l'écosystème Ethereum, ce qui concerne non seulement la stabilité opérationnelle du réseau principal d'Ethereum et des réseaux L2, mais aussi l'état réel de développement des réseaux L2. Récemment, Daniel Wang, membre de la communauté Ethereum, a proposé sur la plateforme X un label de nommage pour la phase Stage 2 des réseaux L2 : #BattleTested. Il estime que seuls les réseaux L2 dont le code et la configuration actuels sont en ligne sur le mainnet Ethereum depuis plus de 6 mois, et qui maintiennent une valeur totale verrouillée (TVL) supérieure à 100 millions de dollars, dont au moins 50 millions de dollars en ETH et en principales stablecoins, peuvent obtenir ce titre. Ce titre est évalué de manière dynamique afin d'éviter la création de "fantômes en chaîne". Vitalik Buterin, co-fondateur d'Ethereum, a ensuite fourni une réponse détaillée et partagé ses points de vue sur cette question, comme l'a traduit Odaily Planet Daily.
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.
La sécurité des rollups Ethereum peut être déterminée en fonction des trois étapes où le comité de sécurité peut couvrir les composants sans confiance (c'est-à-dire purement cryptographiques ou théoriques des jeux) :
Nous pouvons utiliser le graphique ci-dessous pour représenter la « part de vote » détenue par le comité de sécurité à différents stades :
Structure de vote de gouvernance en trois phases
Une question importante est : quels sont les moments optimaux pour la transition des réseaux L2 de la phase 0 à la phase 1, ainsi que 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 préoccupation compréhensible : le système est composé d'une grande quantité de code, et si le code présente des vulnérabilités, alors un attaquant pourrait voler tous les actifs des 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 du réseau vers la prochaine phase.
En fait, nous pouvons quantifier cela à l'aide d'un modèle mathématique simplifié. Tout d'abord, énumérons les hypothèses :
Dans ces hypothèses, en tenant compte de la probabilité spécifique de l'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 :
Ici présenté sous forme de graphique :
Probabilité de défaillance du système de preuve à différentes étapes du réseau L2
Comme prévu, 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 l'exécution du réseau en phase 2 donne les pires résultats.
Maintenant, veuillez noter que les hypothèses dans le modèle simplifié ci-dessus ne sont pas parfaites :
Ces deux arguments indiquent que les phases 1 et 2 sont plus attrayantes par rapport à ce qui est montré dans le graphique.
Si vous croyez en la mathématique, alors l'existence de la phase 1 ne sera presque jamais prouvée comme étant raisonnable : vous devriez entrer directement dans la phase 1. La principale objection que j'entends est la suivante : si une erreur cruciale se produit, il peut être difficile d'obtenir rapidement la signature de 6 membres sur 8 du comité de sécurité pour la corriger. Mais il existe une solution simple : donner à n'importe quel membre du comité de sécurité le pouvoir de retarder les retraits de 1 à 2 semaines, afin de donner aux autres le temps suffisant pour agir (de manière corrective).
En même temps, cependant, sauter trop tôt à la phase 2 est également une erreur, 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 présenter 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 des indicateurs de l'ensemble de la synthèse, afin que nous puissions les réutiliser), accompagnés d'une présentation de la phase.