Comprendre la couche 2 du point de vue du proposant Danksharding

Auteur : Faust, geek du web3

Introduction : Récemment, Dankrad Feist, le créateur de Danksharding et chercheur à la Fondation Ethereum, a fait des remarques controversées sur Twitter. Il a clairement souligné qu'une blockchain modulaire qui n'utilise pas ETH comme couche DA (couche de disponibilité des données) n'est pas Rollup, ni Ethereum Layer 2. Selon Dankrad, Arbitrum Nova, Immutable X, ApeX et Metis peuvent tous être "supprimés" de la liste de la couche 2, car ils ne divulguent que des données de transaction en dehors de l'ETH (ils ont construit leur propre réseau DA hors chaîne appelé DAC).

Dans le même temps, Dankrad a également déclaré que les solutions telles que Plasmas et les canaux d'état qui ne nécessitent pas de disponibilité des données en chaîne (Disponibilité des données) pour garantir la sécurité sont toujours la couche 2, mais Validium (ZKRollup qui n'utilise pas ETH comme couche DA) n'est pas la couche 2.

Dès que la remarque de Dankrad est sortie, de nombreux fondateurs ou chercheurs dans le domaine du Rollup l'ont remise en question. Après tout, de nombreux projets de "couche 2" n'utilisent pas l'ETH comme couche DA (disponibilité des données) afin de réduire les coûts. Si ces projets sont expulsés de la liste L2, cela affectera inévitablement pas mal d'expansion réseaux; en même temps, si validium n'est pas compté comme L2, Plasma ne devrait pas non plus être considéré comme L2.

À cet égard, Dankrad a déclaré que lorsque DA n'est pas disponible (c'est-à-dire que le réseau de couches DA sous la chaîne s'engage dans la rétention de données et ne divulgue pas les données de transaction), les utilisateurs de Plasma peuvent toujours retirer leurs actifs en toute sécurité vers L1 ; mais dans les mêmes circonstances , Validium (la plupart des projets utilisant le schéma StarkEx sont validium) mais cela peut empêcher les utilisateurs de retirer des fonds vers L1 et de geler l'argent.

De toute évidence, Dankrad a l'intention de définir si un projet d'expansion est Ethereum Layer 2 à partir de "s'il est sûr ou non". Du point de vue de la "sécurité", Validium peut en effet geler les actifs de l'utilisateur en L2 et ne peut pas mentionner L1 dans le cas extrême d'une défaillance du séquenceur + couche DA lançant une attaque par rétention de données (cachant de nouvelles données ); Différent de Validium dans la conception, bien que la plupart des le moment où la sécurité n'est pas aussi bonne que Validium, mais lorsque la couche défaillance du séquenceur + DA lance une attaque de rétention de données (cachant de nouvelles données), cela permet aux utilisateurs d'évacuer en toute sécurité les actifs vers L1. La rhétorique de Dankrad est donc logique.

Cet article a l'intention de partir du point de vue de Dankrad et d'analyser plus en détail les détails de Layer2 pour comprendre pourquoi Validium n'est pas strictement "Layer2".

Comment définir Layer2 ?

Selon la définition du site ethereum.org et de la plupart des membres de la communauté Ethereum, la couche 2 est "une blockchain indépendante qui étend la capacité d'Ethereum + hérite de la sécurité d'Ethereum". Tout d'abord, "étendre la capacité d'Ethereum" désigne le détournement du trafic qu'Ethereum ne peut pas transporter et le partage de la pression de TPS. Et "hériter de la sécurité d'Ethereum" peut en fait être traduit par "protéger sa propre sécurité avec l'aide d'Ethereum".

Par exemple, toutes les transactions Tx sur la couche 2 doivent être finalisées sur ETH, et les Tx avec des données incorrectes ne seront pas libérées ; si vous souhaitez annuler le bloc de la couche 2, vous devez d'abord annuler le bloc Ethereum, tant que l'Ethereum Les blocs L2 du réseau principal ne seront pas annulés sans une annulation de bloc similaire à une attaque à 51 %.

Si nous explorons davantage la sécurité de la couche 2, il y a en fait de nombreux cas particuliers à considérer. Par exemple, si la partie du projet L2 s'enfuit, le séquenceur tombe en panne et la couche DA hors chaîne raccroche, les utilisateurs peuvent-ils retirer leurs fonds en toute sécurité de L2 à L1 lorsque ces événements extrêmes se produisent ?

Mécanisme de "retrait forcé" de Layer2

Indépendamment de facteurs tels que les mises à niveau de contrat L2/les dangers cachés multi-signatures, en fait, comme Arbitrum ou StarkEx, il existe des sorties permettant aux utilisateurs de définir des retraits obligatoires. En supposant que le séquenceur de L2 lance une attaque de censure, rejette délibérément la demande de transaction/retrait de l'utilisateur, ou s'arrête simplement définitivement, l'utilisateur d'Arbitrum peut appeler la fonction force Inclusion du contrat Sequencer Inbox sur L1 pour soumettre directement les données de transaction à L1 ; Dans les 24 heures, le séquenceur n'a pas traité la transaction/retrait qui doit être "inclus obligatoirement", et la transaction sera directement incluse dans la séquence de transactions du registre Rollup, ce qui crée un "retrait obligatoire" pour les utilisateurs L2. sortie".

En revanche, le schéma StarkEx avec le mécanisme de la capsule de sauvetage Escape Hetch est encore pire. Si l'utilisateur L2 n'obtient pas de réponse du séquenceur lorsque la demande de retrait forcé soumise par L1 se termine dans la fenêtre de 7 jours, l'utilisateur peut appeler la fonction de demande de gel pour permettre à L2 d'entrer dans la période de gel. À ce stade, le séquenceur L2 ne pourra pas mettre à jour l'état L2 sur le L1, et il faudra 1 an après que l'état L2 est gelé pour être dégelé.

Une fois l'état L2 gelé, l'utilisateur peut construire une preuve Merkle liée à l'état actuel pour prouver qu'il dispose d'un montant de fonds XX sur L2 et retirer de l'argent via le contrat lié à Escape Hetch sur L1. Il s'agit du service de "retrait complet" fourni par le programme StarkEx. Même si la fête du projet L2 a disparu et que le séquenceur échoue définitivement, les utilisateurs ont toujours un moyen de retirer des fonds de L2.

Mais il y a un problème ici: la plupart des L2 utilisant le schéma StarkEx sont Validium (comme Immutable X et ApeX), et ne publieront pas les données requises par DA à ETH, et les informations pour construire l'arbre d'état L2 actuel sont stockées hors chaîne. Si l'utilisateur ne peut pas obtenir les données pour construire la chaîne hors chaîne Merkle Proof (par exemple, la couche DA hors chaîne lance une attaque de retenue de données), il est impossible de retirer des fonds via la capsule de secours.

Jusqu'à présent, la raison mentionnée par Dankrad au début de l'article pense que Validium n'est pas sûr est en fait très claire : étant donné que Validium n'envoie pas de données DA à la chaîne comme Rollup, les utilisateurs peuvent ne pas être en mesure de construire le Merkle requis pour "forcé retrait". Preuve.

La différence entre Validium et Plasma en cas d'attaque par rétention de données

En fait, le séquenceur de Validium ne publie que le dernier Stateroot (la racine de l'arbre d'état) de L2 sur la chaîne L1, puis soumet une preuve de validité (ZK Proof) pour prouver la transition d'état (changement de fonds utilisateur) impliquée dans le nouveau Stateroot processus de génération. , sont tous corrects.

Cependant, stateroot seul ne peut pas restaurer l'arbre d'état mondial state trie pour le moment, et il est impossible de connaître l'état spécifique de chaque compte L2 (y compris le solde du fonds), et les utilisateurs L2 ne peuvent pas construire une preuve Merkle correspondant au Stateroot légal actuel. C'est là que Validium est désavantagé.

Ici, nous devons souligner la chose DAC. Les données impliquées dans le DA de Validium, telles que le dernier lot de transactions traitées par le séquenceur, seront synchronisées avec le réseau DA exclusif L2 appelé le Comité de disponibilité des données (DAC).Et les membres de la communauté ou d'autres unités sont responsables de l'exploitation et de la supervision ( mais ce n'est qu'en surface, en fait, il est difficile pour le monde extérieur de vérifier qui sont les membres du CAD).

Ce qui est intéressant, c'est que les membres du DAC de Validium doivent soumettre fréquemment des multi-signatures en L1 pour prouver que les nouvelles Stateroot et Validity Proof soumises par le séquenceur L2 en L1 peuvent être mises en correspondance avec les données DA synchronisées par le DAC. Après la soumission multi-signature du DAC, le nouveau Stateroot et Validity Proof seront considérés comme légaux.

À l'heure actuelle, le DAC d'Immutable X adopte la multi-signature 5/7. Bien que dYdX soit ZKRollup, il possède également un DAC, qui utilise la multi-signature 1/2. (dYdX ne publie que les différences d'état dans L1, c'est-à-dire les changements d'état, plutôt que les données de transaction complètes. Mais après avoir obtenu la différence d'état dans les enregistrements historiques, le solde des actifs de toutes les adresses L2 peut être restauré et Merkle Proof peut être construit à cette fois de se retirer intégralement).

Dankrad marque un point. Si les membres du DAC de Validium conspirent pour lancer une attaque de rétention de données, empêchent les autres nœuds L2 de synchroniser les dernières données pour le moment et mettent à jour le Stateroot légal du L2 pour le moment, l'utilisateur ne peut pas construire la preuve Merkle correspondant au légal root au moment de retirer de l'argent (parce que les données DA actuelles ne sont plus disponibles, les données DA précédentes sont disponibles).

Mais Dankrad ne considère que les extrêmes théoriques.En réalité, la plupart des séquenceurs Validium diffuseront les données de transaction nouvellement traitées vers d'autres nœuds L2 en temps réel, y compris de nombreux nœuds honnêtes. Tant qu'il y a un nœud honnête qui peut obtenir des données DA à temps, les utilisateurs peuvent s'échapper de L2.

Mais le problème qui existe théoriquement sur Validium, pourquoi n'existe-t-il pas sur Plasma ? En effet, la façon dont Plasma détermine le Stateroot légal est différente de Validium, car il existe une période de fenêtre anti-fraude. Plasma est la solution d'extension L2 avant OPRollup. Comme OPR, il s'appuie sur des preuves de fraude pour assurer la sécurité de L2.

Plasma, comme OPR, a un paramètre de période de fenêtre. La nouvelle racine d'état publiée par le séquenceur ne sera pas jugée légale immédiatement. Elle doit attendre que la période de fenêtre soit fermée et qu'aucun nœud L2 n'émette un certificat de fraude. Par conséquent, les Stateroots juridiques actuels de Plasma et OPR ont été soumis il y a quelques jours (c'est comme la lumière des étoiles que nous voyons, qui a en fait été publiée il y a longtemps), et les utilisateurs peuvent souvent obtenir des données DA à des moments passés.

Dans le même temps, la condition préalable pour que le mécanisme anti-fraude prenne effet à ce moment est que le L2 DA soit disponible pour le moment, c'est-à-dire que le nœud Verifier de Plasma puisse obtenir les données impliquées dans le DA pour le moment, donc que la preuve de fraude à l'heure actuelle peut être générée (si nécessaire).

Ensuite, tout est très simple : la prémisse de Plasma pour fonctionner normalement est que les données DA de L2 sont disponibles à ce moment. Si désormais, le DA de L2 est indisponible, les utilisateurs peuvent-ils retirer des fonds en toute sécurité ?

Ce problème n'est pas difficile à analyser, en supposant que la période de fenêtre de Plasma est de 7 jours, si à partir d'un certain point de temps T0, les nouvelles données DA ne seront pas disponibles (DAC lance une attaque de rétention de données pour empêcher les nœuds L2 honnêtes d'obtenir données après T0 ). Étant donné que le Stateroot légal à T0 et pour une période de temps ultérieure a été soumis avant T0, et que les données historiques avant T0 peuvent être tracées, les utilisateurs peuvent construire Merkle Proof pour forcer le retrait.

Même si de nombreuses personnes ne peuvent pas détecter l'anomalie immédiatement, car il y a une période de fenêtre (OP est de 7 jours), tant que le Stateroot soumis à T0 n'a pas été légalisé et que les données DA avant T0 peuvent être tracées, les utilisateurs peuvent retirer en toute sécurité l'argent de L2.

Résumer

Jusqu'à présent, nous pouvons comprendre à peu près la différence entre Validium et Plasma en termes de sécurité :

Une fois que le séquenceur de Validium a publié Stateroot, tant qu'il publie immédiatement Validity Proof et DAC multi-signature, il peut le rendre légal et devenir le dernier Stateroot légal ; si les utilisateurs et les nœuds L2 honnêtes rencontrent des attaques de rétention de données, ils ne peuvent pas construire le Merkle correspondant à la Stateroot légale actuelle Preuve, vous ne pouvez pas retirer d'argent à L1.

Cependant, une fois que Plasma a soumis un nouveau Stateroot, il ne peut pas être légal avant la fin de la période de fenêtre. À ce moment, le Stateroot légal a été soumis dans le passé. Parce qu'il y a une période de fenêtre (ARB est de 3 jours, OP est de 7 jours), même si les données Stateroot DA nouvellement soumises ne sont pas disponibles, l'utilisateur dispose toujours des données Stateroot DA légales actuelles (la racine légale a été soumise dans le passé) , et il y a suffisamment de temps pour forcer Retrait à L1.

Donc, ce que Dankrad a dit a du sens. Lorsqu'une attaque de rétention de données se produit, Validium peut piéger les actifs de l'utilisateur dans L2, mais Plasma n'a pas ce problème.

Par conséquent, les attaques de rétention de données sur la couche DA hors chaîne entraîneront de nombreux risques de sécurité, mais c'est ce problème que Celestia tente de résoudre. De plus, étant donné que la plupart des projets de couche 2 fourniront des ports de service pour maintenir les nœuds L2 et les séquenceurs synchronisés hors chaîne, les préoccupations de Dankrad sont souvent théoriques plutôt que réelles.

Si nous utilisons une attitude tatillonne et avançons une hypothèse plus extrême : tous les nœuds Plasma hors chaîne sont indisponibles, alors les utilisateurs ordinaires qui n'ont pas parcouru les nœuds L2 ne pourront pas forcer les retraits vers L1. Mais la probabilité qu'une telle chose se produise équivaut à la probabilité que tous les nœuds d'une chaîne publique tombent collectivement en panne de façon permanente, et cela peut ne jamais arriver.

Donc, souvent, les gens parlent juste de choses qui ne se sont jamais produites. Tout comme la phrase d'or que le vice-président de Rick Gerb a dite au protagoniste du drame américain "Tchernobyl": "Pourquoi s'inquiéter de choses qui n'arriveront jamais?"