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

Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups est récemment devenu le point focal de l’expansion de BTC, devenant la première chose à réellement voler la vedette au Lightning Network, avec une attention plus large. Rollups vise à être une deuxième couche off-chain qui n’est pas limitée ou restreinte par la liquidité centrale du Lightning Network, c’est-à-dire que les utilisateurs finaux doivent avoir des fonds pré-alloués (ou “empruntés”) pour recevoir de l’argent, ou que les nœuds de routage intermédiaires ont besoin de solde de canal pour faciliter le flux complet des paiements du expéditeur au destinataire.

Ces systèmes étaient à l’origine déployés sur des blockchains Turing complet telles qu’Ethereum, mais récemment, l’accent a été mis sur leur portage sur des blockchains basées sur UTXO (par exemple BTC). Cet article ne vise pas à discuter de la mise en œuvre actuelle sur BTC, mais plutôt des fonctionnalités idéales de Rollup, qui dépendent de capacités non prises en charge actuellement par BTC, à savoir la capacité de vérifier directement la preuve de connaissance nulle (zk-SNARKs) sur BTC.

L’architecture de base de Roll est la suivante : un seul compte (UTXO dans BTC) contient les soldes de tous les utilisateurs dans Rollup. Cette UTXO contient un engagement qui existe sous la forme de la racine de Merkle de l’arbre de Merkle, englobant tous les soldes actuels des comptes dans Rollup. Tous ces comptes sont autorisés par Clé publique/Clé privée, donc pour effectuer des dépenses hors chaîne, les utilisateurs doivent toujours signer certains contenus avec Clé secrète. Cette partie de la structure permet aux utilisateurs de quitter à tout moment sans autorisation, il leur suffit de produire une preuve de transaction prouvant que leur compte fait partie de l’arbre de Merkle, 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 le solde du compte off-chaincompte lors de la finalisation des transactions off-chain, sans quoi les transactions seront invalides et ne pourront pas être incluses dans le Bloc. Cette preuve permet de vérifier si toutes les modifications du solde du compte off-chaincompte ont été correctement autorisées par le propriétaire du compte et si l’opérateur n’a pas malicieusement mis à jour les soldes pour voler les fonds des utilisateurs ou les redistribuer 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 off-chain, les utilisateurs peuvent la consulter et y accéder, mais comment peuvent-ils mettre leurs branches dans l’arbre afin de pouvoir sortir à tout moment sans permission ?

Rollup approprié

Dans un 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 pour reconstruire 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 seront ajoutés que dans les transactions de mise à jour du Rollup.

Dans les implémentations plus avancées, les écarts d’équilibre sont utilisés. Il s’agit essentiellement d’un résumé des comptes qui ont augmenté ou diminué le financement au cours du processus de mise à jour. Ainsi, chaque mise à jour de cumul ne contient que les modifications du solde du compte qui ont eu lieu. L’utilisateur peut alors simplement scanner la chaîne et « faire le calcul » depuis le début du Rollup pour arriver à l’état actuel du solde du compte, ce qui lui permet de reconstruire l’arbre de Merkle du solde actuel.

Cela permet d’économiser des coûts importants et de l’espace Bloc (et donc de l’argent), tout en permettant aux utilisateurs de garantir l’accès aux informations nécessaires pour sortir unilatéralement. 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 sans résumé de compte ou différence de compte sont considérées comme invalides.

Période de validité

Une autre méthode pour traiter le problème de disponibilité des données d’extraction pour les utilisateurs est de les placer ailleurs que dans la chaîne de blocs. Cela soulève des questions délicates, car le rollup doit toujours garantir que les données sont disponibles ailleurs. Traditionnellement, d’autres blocs ont été utilisés à cette fin, spécialement conçus comme une couche de disponibilité des données pour des systèmes tels que le rollup.

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 vérification que les données existent dans une preuve off-chain, ce qui est finalement un problème de machine Oracle. La chaîne de blocs BTC ne peut pas vérifier complètement autre chose que ce qui se passe dans son propre Bloc off-chain, la meilleure chose qu’elle puisse faire est de vérifier ZKP. Cependant, ZKP ne peut pas vérifier si le Bloc contenant les données rollup est réellement diffusé publiquement après sa génération. Il ne peut pas vérifier si les informations externes sont réellement publiques pour tous.

Cela ouvre la porte à des attaques de rétention de données, c’est-à-dire la création d’engagements vis-à-vis des données publiées et leur utilisation pour faire avancer le rollup, mais les données ne sont en réalité pas disponibles. Cela empêche les utilisateurs d’extraire des fonds. La seule véritable solution est de s’appuyer totalement sur une valeur et une structure d’incitation en dehors du BTC.

Entre le marteau et l’enclume

Cela pose un dilemme pour le rollup. En ce qui concerne la disponibilité des données, il existe essentiellement un choix binaire entre publier les données sur la chaîne de blocs BTC ou ailleurs. Ce choix a un impact majeur sur la sécurité, la souveraineté et la scalabilité du rollup.

D’une part, l’utilisation de la chaîne BTCBloc comme couche de disponibilité des données fixerait une limite supérieure contraignante à la scalabilité de rollup. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollup pouvant exister à la fois et au nombre total de transactions pouvant être traitées hors chaîne. Chaque mise à jour de rollup doit être proportionnelle à la quantité de comptes dont le solde a changé depuis la dernière mise à jour, en termes d’espace Bloc. 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’extension.

D’autre part, l’utilisation de différentes couches pour assurer la disponibilité des données éliminera la limite rigide des gains d’évolutivité, mais cela pose également de nouveaux problèmes de sécurité et de souveraineté. Dans le Rollup qui utilise BTC pour assurer la disponibilité des données, si les données à extraire ne sont pas automatiquement publiées sur la blockchain, l’état du Rollup ne peut pas changer. Avec les Validiums, cette garantie dépend entièrement de la capacité du système externe utilisé à résister à la tromperie et à la dissimulation des données.

Maintenant, n’importe quel producteur de Bloc sur le système de disponibilité des données externes peut intercepter les fonds des utilisateurs de BTCRollup en produisant des Blocs au lieu de diffuser réellement ce Bloc, rendant ainsi les données disponibles.

Alors, si nous parvenons réellement à réaliser une implémentation Rollup idéale sur BTC, permettant véritablement des retraits unilatéraux des utilisateurs, à quoi cela ressemblera-t-il ?