Note de l'éditeur : Depuis toujours, la discussion sur la sécurité des rollups Ethereum en trois phases est un point d'intérêt majeur pour la communauté de l'écosystème Ethereum. Cela concerne non seulement la stabilité opérationnelle du réseau principal 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 l'étiquette de nom de phase pour le réseau L2 Stage 2 : #BattleTested. Il estime que seuls les réseaux L2 dont le code et la configuration sont en ligne sur le réseau principal Ethereum depuis plus de 6 mois, avec une valeur totale verrouillée (TVL) supérieure à 100 millions de dollars et dont au moins 50 millions de dollars sont en ETH et en principales stablecoins, peuvent obtenir ce titre. De plus, ce titre est évalué de manière dynamique pour éviter la création de « fantômes en chaîne ». Vitalik Buterin, co-fondateur d'Ethereum, a ensuite répondu à cette question avec des éclaircissements et des partages de points de vue, comme le rapporte 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.
Les trois phases de la sécurité des rollups Ethereum peuvent être déterminées en fonction de la période à laquelle 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 le contrôle total. Il peut y avoir un système de preuve en fonctionnement (mode Optimism ou ZK), mais le comité de sécurité peut le renverser par un simple mécanisme de vote majoritaire. Par conséquent, le système de preuve n'est que de nature "consultative".
Étape 1 : Le comité de sécurité a besoin d'une approbation de 75 % (au moins 6/8) pour couvrir le système en fonctionnement. Un quorum doit 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 lorsque 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 » détenue par le comité de sécurité à différentes étapes :
Structure de vote de gouvernance en trois phases
Une question importante est : quel est le moment optimal pour passer du stade 0 au stade 1 du réseau L2, ainsi que pour évoluer du stade 1 au stade 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 : ce système est composé d'un grand nombre de lignes de code, et si le code présente des vulnérabilités, un attaquant pourrait voler les actifs de tous les utilisateurs. Plus vous avez confiance dans le système de preuve (ou au contraire, moins vous avez confiance dans le comité de sécurité), plus vous souhaiterez faire avancer l'écosystème entier 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é non disponible) et les défaillances de sécurité (signature d'éléments erronés ou clé compromise) comme des événements de probabilité égale. En réalité, nous supposons simplement une catégorie de "défaillance", où les membres du conseil de sécurité de la défaillance ont à la fois signé des éléments erronés et ont échoué à 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 global unique (par rapport au mécanisme de conception des 2/3, le comité de sécurité peut trancher en cas de désaccord entre les deux opinions). Ainsi, à 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 la distribution binomiale pour accomplir ce travail :
Si chaque membre du conseil de sécurité a une probabilité d'échec indépendant de 10 %, alors la probabilité qu'au moins 4 sur 7 échouent est ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728 Ainsi, le système d'intégration à l'étape 0 a un taux d'échec fixe de 0,2728 %.
L’intégration de la phase 1 peut également échouer si le système d’attestation échoue et que le mécanisme de vérification du comité de sécurité échoue ≥ 3 fois et que la couverture de calcul du réseau ne peut pas être effectuée (probabilité ∑i = 38( 8 i)∗ 0,1 i∗ 0,98 −i = 0,03809179 multiplié par le taux de défaillance du système d’attestation), ou si le comité de sécurité a 6 échecs ou plus, Il est possible de se forcer à générer une réponse calculée incorrecte (probabilité fixe ∑i= 68( 8 i)∗ 0,1 i∗ 0,98 −i= 0,00002341 probabilité) ;
La probabilité d'échec de la fusion à l'étape 2 est la même que celle d'échec du système de preuve.
Voici 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 a été suggéré ci-dessus, avec l'amélioration de la qualité du système de preuve, la meilleure étape passe de l'étape 0 à l'étape 1, puis de l'étape 1 à l'étape 2. Utiliser un système de preuve de qualité d'étape 0 pour l'exploitation du réseau à l'étape 2 donne 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) un « défaut de mode commun » : ils peuvent se liguer, ou être tous soumis à la même contrainte ou à la même attaque de hackers, etc. L'exigence d'un nombre légal en dehors de l'organisation principale pour empêcher un sous-ensemble vise à éviter cela, mais n'est toujours pas parfaite.
Le système de preuve lui-même peut être composé de plusieurs systèmes indépendants (j'ai recommandé 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 à l'étape 2, le comité de sécurité est également important car il est essentiel pour résoudre les litiges.
Ces deux arguments indiquent que, par rapport à ce qui est montré dans le graphique, la phase 1 et la phase 2 sont plus attrayantes.
Si vous croyez aux mathématiques, alors l'existence de la phase 1 ne sera presque jamais prouvée comme raisonnable : vous devriez directement passer à la phase 1. La principale objection que j'entends est que s'il y a une erreur critique, il peut être difficile d'obtenir rapidement la signature de 6 des 8 membres du comité de sécurité pour la corriger. Mais il y a une solution simple : donner à l'un des membres du comité de sécurité le pouvoir de retarder le retrait de 1 à 2 semaines, donnant aux autres suffisamment de temps pour prendre des mesures (correctives).
En même temps, cependant, passer prématurément à l'étape 2 est également une erreur, surtout si le travail de transition vers l'étape 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 globaux, afin que nous puissions les réutiliser), accompagnés d'une présentation de l'étape.
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.
Le modèle mathématique révèle la logique de sélection de la phase L2 : pourquoi la phase 1 pourrait-elle être sautée ?
Rédigé par : Vitalik Buterin
Compilation : Wenser, Odaily Planet Daily
Note de l'éditeur : Depuis toujours, la discussion sur la sécurité des rollups Ethereum en trois phases est un point d'intérêt majeur pour la communauté de l'écosystème Ethereum. Cela concerne non seulement la stabilité opérationnelle du réseau principal 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 l'étiquette de nom de phase pour le réseau L2 Stage 2 : #BattleTested. Il estime que seuls les réseaux L2 dont le code et la configuration sont en ligne sur le réseau principal Ethereum depuis plus de 6 mois, avec une valeur totale verrouillée (TVL) supérieure à 100 millions de dollars et dont au moins 50 millions de dollars sont en ETH et en principales stablecoins, peuvent obtenir ce titre. De plus, ce titre est évalué de manière dynamique pour éviter la création de « fantômes en chaîne ». Vitalik Buterin, co-fondateur d'Ethereum, a ensuite répondu à cette question avec des éclaircissements et des partages de points de vue, comme le rapporte 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.
Les trois phases de la sécurité des rollups Ethereum peuvent être déterminées en fonction de la période à laquelle 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érentes étapes :
Une question importante est : quel est le moment optimal pour passer du stade 0 au stade 1 du réseau L2, ainsi que pour évoluer du stade 1 au stade 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 : ce système est composé d'un grand nombre de lignes de code, et si le code présente des vulnérabilités, un attaquant pourrait voler les actifs de tous les utilisateurs. Plus vous avez confiance dans le système de preuve (ou au contraire, moins vous avez confiance dans le comité de sécurité), plus vous souhaiterez faire avancer l'écosystème entier 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 d'effondrement du système de preuve, nous souhaitons minimiser la possibilité d'effondrement du réseau L2.
Nous pouvons utiliser la distribution binomiale pour accomplir ce travail :
Voici présenté sous forme de graphique :
Comme le résultat a été suggéré ci-dessus, avec l'amélioration de la qualité du système de preuve, la meilleure étape passe de l'étape 0 à l'étape 1, puis de l'étape 1 à l'étape 2. Utiliser un système de preuve de qualité d'étape 0 pour l'exploitation du réseau à l'étape 2 donne le pire résultat.
Maintenant, veuillez noter que les hypothèses dans le modèle simplifié ci-dessus ne sont pas parfaites :
Ces deux arguments indiquent que, par rapport à ce qui est montré dans le graphique, la phase 1 et la phase 2 sont plus attrayantes.
Si vous croyez aux mathématiques, alors l'existence de la phase 1 ne sera presque jamais prouvée comme raisonnable : vous devriez directement passer à la phase 1. La principale objection que j'entends est que s'il y a une erreur critique, il peut être difficile d'obtenir rapidement la signature de 6 des 8 membres du comité de sécurité pour la corriger. Mais il y a une solution simple : donner à l'un des membres du comité de sécurité le pouvoir de retarder le retrait de 1 à 2 semaines, donnant aux autres suffisamment de temps pour prendre des mesures (correctives).
En même temps, cependant, passer prématurément à l'étape 2 est également une erreur, surtout si le travail de transition vers l'étape 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 globaux, afin que nous puissions les réutiliser), accompagnés d'une présentation de l'étape.