Expulsion de Validium ? Re-comprendre Layer2 du point de vue du proposant de Danksharding

Auteur : Faust

Source originale : Geek 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 et Mantle seront tous "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 des solutions telles que les 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 le validium n'est pas considéré 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 la couche 2 pour acquérir une compréhension approfondie de la raison pour laquelle Validium n'est pas strictement la "couche 2".

Comment définir la couche 2 ?

Selon la définition du site Web 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" signifie détourner le trafic qu'Ethereum ne peut pas transporter et partager 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 S'il n'y a pas de restauration de bloc similaire à l'attaque à 51 % sur le réseau Fangzhu, le bloc L2 ne sera pas restauré.

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 couche 2

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 intentionnellement 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 nécessite une "inclusion obligatoire", et la transaction sera directement incluse dans la séquence de transaction du Rollup ledger, ce qui crée un "retrait forcé" pour les utilisateurs L2. exit" .

En comparaison, la solution StarkEx avec le mécanisme Escape Hetch n'est pas moins. 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 faire entrer L2 dans la période de gel. À ce moment, le séquenceur L2 ne pourra pas mettre à jour l'état de L2 sur L1, et il faudra 1 an pour que l'état de L2 soit dégelé après avoir été 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 rétention de données), il est impossible de retirer de l'argent via la capsule de sauvetage.

Jusqu'à présent, la raison pour laquelle Dankrad a mentionné au début de l'article 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.

(Source : eckoDAO)

Cependant, stateroot seul ne peut pas restaurer l'arbre d'état mondial state trie pour le moment, et ne peut pas 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é.

(Merkle Proof est en fait les données requises dans le processus de génération de racine, qui est la partie sombre de la figure. Pour construire une preuve Merkle correspondant à Stateroot, vous devez connaître la structure de l'arbre d'état et avoir besoin de données DA)

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 du fonctionnement 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 correspondre aux 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 le multi-sig 5/7. Bien que dYdX soit un ZKRollup, il dispose également d'un DAC, qui utilise le multi-sig 1/2. (dYdX ne publie que les différences d'état dans L1, c'est-à-dire les changements d'état, pas les données de transaction complètes. Cependant, 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 la preuve Merkle peut être construite à 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 ne sont pas 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, l'utilisateur peut s'échapper de L2.

Théoriquement, le problème existe dans Validium, mais pourquoi n'existe-t-il pas dans 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 tous é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 dans le passé.

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).

Alors tout est simple : la condition sine qua non pour que Plasma fonctionne correctement est que les données DA de L2 soient disponibles pour le 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 T 0, 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 de obtenir T 0 Les données). Étant donné que la Stateroot légale à T 0 et pour une période de temps ultérieure a été soumise avant T 0, et que les données historiques avant T 0 peuvent être retracé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 existe une période de fenêtre (OP est de 7 jours), tant que le Stateroot soumis au moment T 0 n'a pas été légalisé et que les données DA avant T 0 sont traçables, les utilisateurs peuvent retirer de l'argent en toute sécurité hors 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 DA du Stateroot nouvellement soumis ne sont pas disponibles, l'utilisateur dispose toujours des données DA du Stateroot légal actuel (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.

(Ce que Dankrad a dit dans l'image ci-dessous est un peu faux. Plasma ne devrait pas permettre la construction d'un Stateroot légal obsolète correspondant à la preuve Merkle pour retirer de l'argent, car cela conduirait à un double paiement)

Par conséquent, les attaques de rétention de données sur la couche DA hors chaîne peuvent entraîner de nombreux risques de sécurité, mais c'est précisément ce problème que Celestia tente de résoudre. De plus, étant donné que la plupart des projets de couche 2 fournissent des ports de service qui maintiennent les nœuds L2 et les séquenceurs hors chaîne synchronisés, 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 peuvent 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?"