Bitcoin Magazine: Quels sont les défis auxquels est confronté le Rollup ?

Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Les Rollups sont devenus récemment un point focal pour l’expansion de BTC, devenant la première chose à réellement éclipser le Lightning Network et attirant une attention plus large. Les Rollups visent à être une couche secondaire off-chain indépendante des restrictions de Liquidité de base du Lightning Network, ce qui signifie que les utilisateurs finaux doivent avoir des fonds pré-alloués (ou «prêtés») pour recevoir de l’argent, ou que les Nœuds de routage intermédiaires ont besoin de soldes de canal pour faciliter le flux de paiement de l’expéditeur au destinataire.

Ces systèmes ont été initialement développés pour fonctionner sur Ethereum et d’autres systèmes Turing complets, mais récemment, l’accent a été mis sur leur portage vers des blockchains basées sur les UTXO (comme BTC). Cet article ne vise pas à discuter de la mise en œuvre actuelle sur BTC, mais plutôt des fonctionnalités idéalisées des rollups, qui dépendent de la capacité de BTC à valider directement les preuves de connaissance nulle (ZKP) sur la blockchain.

L’architecture de base de Roll est la suivante : un seul compte (appelé UTXO dans BTC) stocke les soldes de tous les utilisateurs dans Rollup. Ce UTXO contient un engagement qui existe sous la forme de la racine de Merkle de l’arbre de Merkle, engageant tous les soldes actuels des comptes dans Rollup. Tous ces comptes sont autorisés par une Clé publique/Clé privée, de sorte que pour effectuer des dépenses hors chaîne, les utilisateurs doivent toujours signer certains contenus avec une Clé secrète. Cette partie de la structure permet aux utilisateurs de sortir à tout moment sans permission, il leur suffit de prouver par une transaction que leur compte fait partie de l’arbre de Merkle, et ils peuvent sortir unilatéralement de Rollup sans l’autorisation de l’opérateur.

Les opérateurs de Rollup doivent inclure un ZKP dans les transactions pour mettre à jour la racine de Merkle du solde du compte off-chain lors du processus de transaction off-chain. Sans ce ZKP, la transaction sera invalide et ne peut pas être incluse dans le bloc. Cette preuve permet aux personnes de vérifier si toutes les modifications du compte off-chain sont correctement autorisées par le détenteur du compte et si l’opérateur ne met pas malicieusement à jour le solde pour voler les fonds des utilisateurs ou les réallouer de manière malhonnête à d’autres utilisateurs.

Le problème est que si seule la racine de l’arbre de Merkle est publiée hors chaîne, les utilisateurs peuvent la consulter et y accéder, mais comment peuvent-ils placer leurs branches dans l’arbre afin de pouvoir sortir à tout moment sans permission ?

Rollup Approprié

Dans le Rollup approprié, chaque fois qu’une nouvelle transaction off-chain est confirmée et que l’état du compte Rollup change, les informations sont directement placées dans la blockchain. Ce n’est pas tout l’arbre, ce serait trop absurde, mais les informations nécessaires à la reconstruction de l’arbre. Dans une implémentation simple, le résumé de tous les comptes existants dans le Rollup contiendra les soldes, et les comptes ne sont ajoutés que dans les transactions de mise à jour du Rollup.

Dans les implémentations plus avancées, utilisez les différences de solde du compte. Cela résume fondamentalement quels comptes ont ajouté ou retiré des fonds lors du processus de mise à jour. Cela permet à chaque mise à jour de Rollup de ne contenir que les modifications de solde du compte qui se sont produites. Ensuite, les utilisateurs peuvent simplement parcourir la chaîne et “calculer” à partir du début du Rollup pour obtenir l’état actuel du solde du compte, ce qui leur permet de reconstruire l’arbre de Merkle de solde actuel.

Cela permet d’économiser beaucoup de frais et d’espace Bloc (et donc d’argent), tout en permettant aux utilisateurs de garantir l’accès aux informations nécessaires pour une sortie unilatérale. Les règles de rollup exigent que ces données soient incluses dans le rollup officiel fourni aux utilisateurs par la chaîne Bloc, c’est-à-dire que les transactions qui n’incluent pas de résumé de compte ou de différence de compte sont considérées comme invalides.

Durée de validité

Une autre façon de traiter le problème de disponibilité des données d’extraction des utilisateurs est de les placer ailleurs que sur la chaîne de Blocs. Cela introduit des problèmes subtils, car le roll-up doit toujours s’assurer que les données sont disponibles ailleurs. Traditionnellement, d’autres Blocs sont utilisés à cette fin, spécialement conçus pour servir de couche de disponibilité des données pour des systèmes tels que le roll-up.

Cela crée un dilemme de sécurité tout aussi puissant. Lorsque les données sont directement publiées sur la chaîne de blocs BTCBloc, les règles de consensus peuvent garantir qu’elles sont absolument correctes. Cependant, lorsqu’elles sont publiées sur un système externe, la meilleure chose qu’elles puissent faire est de vérifier la preuve SPV, c’est-à-dire que les données ont été publiées sur un autre système.

Cela nécessite la validation des données qui existent dans d’autres preuves off-chain, ce qui pose finalement un problème d’Oracle Machine. Le Bloc de BTC ne peut pas valider complètement quoi que ce soit qui se produit en dehors de son propre Blocoff-chain, sa meilleure capacité étant de valider les ZKP. Cependant, les ZKP ne peuvent pas vérifier si les données de rollup du Bloc, une fois générées, sont réellement diffusées publiquement. Ils ne peuvent pas vérifier si les informations externes sont réellement rendues publiques pour tous.

Cela ouvre la porte à une attaque de rétention de données, c’est-à-dire la création d’un engagement envers les données publiées et leur utilisation pour promouvoir le rollup, mais les données ne sont pas réellement disponibles. Cela empêche les utilisateurs de retirer leurs fonds. La seule véritable solution est de dépendre entièrement de la valeur et de la structure d’incitation d’un système autre que le BTC.

Entre le marteau et l’enclume

Cela pose un dilemme pour rollup. Lorsqu’il s’agit de la disponibilité des données, il existe essentiellement un choix binaire entre publier les données sur la blockchain BTC ou ailleurs. Ce choix a un impact majeur sur la sécurité, la souveraineté et la scalabilité de rollup.

D’une part, l’utilisation de la chaîne BTCBloc en tant que couche de disponibilité des données fixe une limite supérieure à la scalabilité des rollups. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollups pouvant exister en même temps et au nombre total de transactions pouvant être traitées hors chaîne par tous les rollups. Chaque mise à jour du rollup nécessite un espace Bloc proportionnel au nombre de comptes dont le solde a changé depuis la dernière mise à jour. La théorie de l’information limite la compression des données à un certain niveau, à partir duquel il n’y a plus de potentiel d’expansion.

D’autre part, l’utilisation de différentes couches pour assurer la disponibilité des données éliminera le plafond dur des gains d’évolutivité, mais elle soulèvera également de nouveaux problèmes de sécurité et de souveraineté. Dans un Rollup utilisant BTC pour assurer la disponibilité des données, si les données à extraire ne sont pas automatiquement publiées sur la chaîne de blocs, l’état du Rollup ne pourra pas changer. Avec les Validiums, cette garantie dépend entièrement de la capacité du système externe utilisé à contrer la fraude et la dissimulation des données.

Maintenant, n’importe quel producteur de Bloc sur le système de disponibilité des données externes peut s’approprier les fonds des utilisateurs de BTCRollup en produisant un Bloc plutôt qu’en diffusant réellement ce Bloc, rendant ainsi les données disponibles.

Alors, si nous parvenons réellement à mettre en œuvre une solution Rollup idéale sur BTC, permettant réellement des retraits unilatéraux des utilisateurs, à quoi cela ressemblerait-il ?