Le principal avantage est de réduire la quantité de données stockées sur Ethereum, réduisant ainsi le coût pour les utilisateurs des transactions sur L2.
**Écrit par : **OneTrueKirk
Compilé par : Yvonne, MarsBit
Message original de OneTrueKirk sur ethresear.ch
C'est la première fois que je poste sur un sujet ici, donc je m'excuse si je vous offense de quelque manière que ce soit. J'ai pensé à cette idée (Stateless Rollups) principalement pour les rollups dédiés à notre protocole de prêt, mais j'espère qu'elle pourra être applicable de manière générale, tout commentaire est apprécié.
TLDR：
Seule la racine d'état est publiée, pas les données d'appel.
(Remarque MarsBit : Calldata est la valeur de la partie données dans la transaction contractuelle et ne peut pas être modifiée.)
détail
Et si au lieu d'utiliser Ethereum comme couche de disponibilité des données, en publiant l'état complet en tant que données d'appel et en publiant uniquement la racine de l'état sur le réseau principal ? Le principal avantage est de réduire la quantité de données stockées sur Ethereum, réduisant ainsi le coût pour les utilisateurs des transactions sur L2. Même avec EIP-4844, blobace n'est pas gratuit.
Le principal risque est une attaque de rétention de données, où un proposant publie une racine d'état valide mais retient des données complètes d'autres nœuds de cumul pour monopoliser la production future de blocs ou retenir des fonds en otage. Pour éviter cela, les nœuds honnêtes doivent remettre en question toute mise à jour d'état pour laquelle aucun pair ne peut fournir de données. Les preuves de fraude interactives de type Arbitrum peuvent être utilisées pour forcer les proposants à divulguer l'état complet sur le réseau principal, mais font toujours échouer le défi si la racine est valide, donc même en cas d'échec, le coût du défi est faible.
(Remarque MarsBit : l'attaque par rétention de données fait référence à un attaquant qui ne renvoie délibérément pas toutes les données ou renvoie des données erronées lors de l'accès à des données protégées, afin d'atteindre l'objectif de tromperie ou de destruction.
Si le coût d'un échec de défi est faible, les proposants honnêtes pourraient être misérables en les forçant à payer pour publier toutes les données d'état sur le réseau principal en défense du défi, même s'ils ont correctement propagé les données d'état point à point. Le coût d'initiation d'une contestation doit être proportionnel au coût de la défense pour s'assurer que les proposants honnêtes ne peuvent pas être attaqués de cette manière.
Dans le pire des cas, si un attaquant peut dépenser 1 $ pour coûter 1 $ à un proposant honnête, il peut forcer le proposant à abandonner et récupérer son blocage. Un nouveau proposant honnête peut alors enchérir, et à moins que l'attaquant ne puisse répéter l'attaque contre tous les proposants honnêtes potentiels, ce qui inclut tous ceux qui disposent de fonds, ils ne peuvent pas provoquer un temps d'arrêt permanent. Il est possible d'ajouter une autre clause, où le coût du défi augmente lorsque trop de temps s'est écoulé depuis qu'un bloc valide a été finalisé. De cette façon, il est facile de défier un proposant malhonnête, mais impossible d'arrêter les transitions d'état pendant longtemps.
De manière plus optimiste, si les nœuds répartissent les données entre pairs, ils peuvent décider de leurs propres solutions de sauvegarde et d'accessibilité des données, et les utilisateurs ont intérêt à stocker localement les données dont ils ont besoin pour leurs propres transitions d'état. Dans le contexte d'une application particulière, j'ai pensé à coder l'état de cumul d'une manière complètement différente de celle de l'EVM pour optimiser cela. Tous les états associés à un compte utilisateur particulier peuvent être encodés dans le même hachage, afin que les utilisateurs puissent plus facilement vérifier les modifications apportées à leur compte sans connaître l'état global (c'est-à-dire confirmer que vous avez reçu le nombre souhaité de jetons sans se soucier de leur provenance) .
Résumer
J'aimerais entendre vos pensées et apprécierais des liens vers des travaux connexes. Contrairement au cumul optimiste ordinaire, dans le cumul optimiste, il est facile de déterminer si les données d'appel soumises correspondent à la racine d'état du réseau principal et si les deux sont valides, mais il est impossible de savoir si une mise à jour est valide à partir de la racine d'état seule, donc il est nécessaire d'examiner attentivement les aspects économiques des périodes de défi et du chagrin (c'est-à-dire un comportement malveillant).
Voir l'original
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.
Aperçu rapide des avantages et des problèmes potentiels du cumul sans état
**Écrit par : **OneTrueKirk
Compilé par : Yvonne, MarsBit
Message original de OneTrueKirk sur ethresear.ch
C'est la première fois que je poste sur un sujet ici, donc je m'excuse si je vous offense de quelque manière que ce soit. J'ai pensé à cette idée (Stateless Rollups) principalement pour les rollups dédiés à notre protocole de prêt, mais j'espère qu'elle pourra être applicable de manière générale, tout commentaire est apprécié.
TLDR：
Seule la racine d'état est publiée, pas les données d'appel.
(Remarque MarsBit : Calldata est la valeur de la partie données dans la transaction contractuelle et ne peut pas être modifiée.)
détail
Et si au lieu d'utiliser Ethereum comme couche de disponibilité des données, en publiant l'état complet en tant que données d'appel et en publiant uniquement la racine de l'état sur le réseau principal ? Le principal avantage est de réduire la quantité de données stockées sur Ethereum, réduisant ainsi le coût pour les utilisateurs des transactions sur L2. Même avec EIP-4844, blobace n'est pas gratuit.
Le principal risque est une attaque de rétention de données, où un proposant publie une racine d'état valide mais retient des données complètes d'autres nœuds de cumul pour monopoliser la production future de blocs ou retenir des fonds en otage. Pour éviter cela, les nœuds honnêtes doivent remettre en question toute mise à jour d'état pour laquelle aucun pair ne peut fournir de données. Les preuves de fraude interactives de type Arbitrum peuvent être utilisées pour forcer les proposants à divulguer l'état complet sur le réseau principal, mais font toujours échouer le défi si la racine est valide, donc même en cas d'échec, le coût du défi est faible.
(Remarque MarsBit : l'attaque par rétention de données fait référence à un attaquant qui ne renvoie délibérément pas toutes les données ou renvoie des données erronées lors de l'accès à des données protégées, afin d'atteindre l'objectif de tromperie ou de destruction.
Si le coût d'un échec de défi est faible, les proposants honnêtes pourraient être misérables en les forçant à payer pour publier toutes les données d'état sur le réseau principal en défense du défi, même s'ils ont correctement propagé les données d'état point à point. Le coût d'initiation d'une contestation doit être proportionnel au coût de la défense pour s'assurer que les proposants honnêtes ne peuvent pas être attaqués de cette manière.
Dans le pire des cas, si un attaquant peut dépenser 1 $ pour coûter 1 $ à un proposant honnête, il peut forcer le proposant à abandonner et récupérer son blocage. Un nouveau proposant honnête peut alors enchérir, et à moins que l'attaquant ne puisse répéter l'attaque contre tous les proposants honnêtes potentiels, ce qui inclut tous ceux qui disposent de fonds, ils ne peuvent pas provoquer un temps d'arrêt permanent. Il est possible d'ajouter une autre clause, où le coût du défi augmente lorsque trop de temps s'est écoulé depuis qu'un bloc valide a été finalisé. De cette façon, il est facile de défier un proposant malhonnête, mais impossible d'arrêter les transitions d'état pendant longtemps.
De manière plus optimiste, si les nœuds répartissent les données entre pairs, ils peuvent décider de leurs propres solutions de sauvegarde et d'accessibilité des données, et les utilisateurs ont intérêt à stocker localement les données dont ils ont besoin pour leurs propres transitions d'état. Dans le contexte d'une application particulière, j'ai pensé à coder l'état de cumul d'une manière complètement différente de celle de l'EVM pour optimiser cela. Tous les états associés à un compte utilisateur particulier peuvent être encodés dans le même hachage, afin que les utilisateurs puissent plus facilement vérifier les modifications apportées à leur compte sans connaître l'état global (c'est-à-dire confirmer que vous avez reçu le nombre souhaité de jetons sans se soucier de leur provenance) .
Résumer
J'aimerais entendre vos pensées et apprécierais des liens vers des travaux connexes. Contrairement au cumul optimiste ordinaire, dans le cumul optimiste, il est facile de déterminer si les données d'appel soumises correspondent à la racine d'état du réseau principal et si les deux sont valides, mais il est impossible de savoir si une mise à jour est valide à partir de la racine d'état seule, donc il est nécessaire d'examiner attentivement les aspects économiques des périodes de défi et du chagrin (c'est-à-dire un comportement malveillant).