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

Source: Bitcoin Magazine; Translation: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC scaling, becoming the first thing to truly steal the limelight from the Lightning Network in terms of broader attention. Rollups aim to be an off-chain second layer that is not constrained or limited by the core liquidity constraints of the Lightning Network, meaning end users need someone to pre-allocate (or ‘lend’) funds in order to receive money, or intermediary nodes need channel balances to facilitate the seamless flow of payment amounts from sender to receiver.

Ces systèmes ont initialement été exécutés 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 UTXO, telles que BTC. Cet article ne vise pas à discuter de l’état actuel de la mise en œuvre sur BTC, mais plutôt des fonctionnalités d’un Rollup idéalisé, qui dépendent de capacités non prises en charge actuellement par BTC, à savoir la capacité de vérifier directement les Preuve de Connaissance Zéro (ZKP) sur BTC.

L’architecture de base de Roll est la suivante : un compte unique (UTXO dans BTC) qui stocke les soldes de tous les utilisateurs dans Rollup. Cette UTXO contient un engagement sous la forme de la racine de l’arbre de Merkle, qui garantit tous les soldes actuels des comptes dans Rollup. Tous ces comptes sont autorisés par une clé publique/clé privée, de sorte que les utilisateurs doivent toujours signer certains contenus avec une clé secrète pour effectuer des dépenses hors chaîne. Cette partie de la structure permet aux utilisateurs de partir à tout moment sans permission, en présentant une preuve de transaction prouvant que leur compte fait partie de l’arbre de Merkle. Ils peuvent ainsi quitter Rollup unilatéralement, 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 compte off-chain lors de l’achèvement des transactions off-chain, sans quoi les transactions seront invalides et ne pourront pas être incluses dans le Bloc. Cette preuve permet à chacun de vérifier si toutes les modifications du solde du compte off-chain ont été autorisées par le titulaire du compte et si l’opérateur n’a pas malicieusement mis à 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 insérer leurs branches dans l’arbre afin de pouvoir se retirer sans autorisation quand ils le souhaitent?

Rollup approprié

Dans le Rollup approprié, chaque fois qu’une nouvelle transaction off-chain est confirmée et que l’état du compte Rollup subit des changements, 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 inclura les soldes, et les comptes ne sont ajoutés que dans les transactions de mise à jour du Rollup.

Dans une implémentation plus avancée, utilisez des différences de solde. Cela résume essentiellement quels comptes ont été ajoutés ou retirés de fonds lors du processus de mise à jour. Cela permet à chaque mise à jour de Rollup de ne contenir que les modifications de solde de 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 considérablement les dépenses et l’espace de bloc (et donc les fonds), 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 de blocs, c’est-à-dire que les transactions qui n’incluent pas de résumé de compte ou de différences de compte sont considérées comme invalides.

Période de validité

Une autre façon de résoudre le problème de l’accessibilité des données de retrait des utilisateurs est de les placer ailleurs que sur la chaîne de Bloc. Cela pose des problèmes subtils, rollup devant toujours garantir que les données sont accessibles ailleurs. Traditionnellement, d’autres Blocs sont utilisés à cette fin, spécialement conçus pour servir de couche d’accessibilité des données pour les systèmes tels que rollup.

Cela crée un dilemme de sécurité tout aussi puissant. Lorsque les données sont directement publiées sur la chaîne BTCBloc, les règles de consensus peuvent garantir leur exactitude absolue. 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.

Il est nécessaire de vérifier que les données existent dans d’autres preuves off-chain, ce qui pose finalement un problème d’Oracle Machine. Le Blocchain de BTC ne peut pas vérifier pleinement autre chose que ce qui se passe dans son propre Bloc off-chain, et la meilleure chose qu’il puisse faire est de vérifier ZKP. Cependant, ZKP ne peut pas vérifier si les données de rollup du Bloc ont été réellement diffusées publiquement après leur génération. Il ne peut pas vérifier si les informations externes sont réellement accessibles à tous.

Ceci a ouvert la porte aux attaques de rétention de données, c’est-à-dire la création d’engagements envers les données publiées et leur utilisation pour faire avancer le rollup, mais les données ne sont pas réellement disponibles. Cela empêche les utilisateurs de retirer leurs fonds. La seule solution réelle est de compter sur des systèmes de valeur et de motivation en dehors de BTC.

Entre le marteau et l’enclume

Cela pose un dilemme pour le rollup. Lorsqu’il s’agit de problèmes de 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é du 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é de rollup. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollups pouvant exister simultanément et au nombre total de transactions pouvant être traitées hors chaîne. Chaque mise à jour de 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 permet uniquement une compression des données jusqu’à un certain point, à 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 rigide des gains d’évolutivité, mais cela soulèvera également de nouveaux problèmes de sécurité et de souveraineté. Dans le Rollup utilisant le 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 pourra pas changer. Avec Validiums, cette garantie dépend entièrement de la capacité des systèmes externes utilisés à résister à la tromperie et à la dissimulation des données.

Maintenant, tout producteur de Bloc sur le système de disponibilité des données externes peut saisir les fonds des utilisateurs de BTCRollup en produisant un Bloc au lieu de diffuser réellement ce Bloc, ce qui rend les données disponibles.

Alors, si nous parvenons vraiment à réaliser une implémentation Rollup idéale sur BTC, permettant réellement des retraits unilatéraux pour les utilisateurs, à quoi cela ressemblerait-il ?