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

Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC scalability and the first thing to truly steal the spotlight from the Lightning Network, gaining wider 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. This means that end users need someone to allocate (or ‘lend’) funds in advance in order to receive money, or intermediate routing nodes need channel balances to facilitate the smooth flow of payment amounts from senders to receivers.

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 Bitcoin). Cet article ne vise pas à discuter de la situation actuelle de mise en œuvre sur Bitcoin, mais plutôt à discuter des fonctionnalités d’un Rollup idéalisé, qui dépendent de la capacité de vérifier directement les preuves de connaissance nulle (ZKP) sur Bitcoin, une fonctionnalité qui n’est pas actuellement supportée.

L’architecture de base de Roll est la suivante: un seul compte (UTXO dans BTC) contient tous les soldes des utilisateurs dans Rollup. Cette UTXO contient un engagement sous la forme d’une racine de Merkle de l’arbre de Merkle, qui représente tous les soldes actuels des comptes existants dans Rollup. Tous ces comptes sont autorisés par une paire de clés publiques/privées, 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, en faisant simplement la preuve de transaction 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 la racine Merkle du solde du compte hors chaîne lors du processus de finalisation des transactions hors chaîne. Sans ce ZKP, la transaction sera invalide et ne peut pas être incluse dans le bloc. Cette preuve permet de vérifier si toutes les modifications du solde du compte hors chaîne ont été autorisées par le détenteur 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.

Rollup approprié

Dans un Rollup approprié, chaque fois qu’une nouvelle transaction hors chaîne est confirmée et que l’état du compte Rollup change, les informations sont directement placées dans la blockchain. Ce n’est pas l’ensemble de 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 le solde, et les comptes ne sont ajoutés que dans les transactions de mise à jour du Rollup.

Dans des implémentations plus avancées, utilisez des différences de solde du compte. En substance, il s’agit d’un résumé de quels comptes ont augmenté ou diminué leurs fonds au cours 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 des coûts considérables et de l’espace Bloc (économisant ainsi des 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 formel fourni aux utilisateurs en utilisant la chaîne Bloc, c’est-à-dire que les transactions ne contenant 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 disponibilité des données des utilisateurs lors de l’extraction est de les stocker ailleurs que sur la chaîne de blocs. Cela soulève des questions délicates, car le rollup doit toujours s’assurer 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 également un dilemme de sécurité tout aussi puissant. Lorsque les données sont directement publiées sur la chaîne de blocs BTC, 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 une vérification que les données existent dans d’autres preuves off-chain, c’est finalement un problème d’Oracle Machine. Le Blocchain de BTC ne peut pas vérifier complètement quoi que ce soit en dehors de ce qui se passe dans son propre Bloc off-chain, 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 sont 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.

Cela ouvre 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 en réalité pas disponibles. Cela empêche les utilisateurs de retirer leurs fonds. La seule solution réelle est de dépendre entièrement de la valeur et de la structure incitative des systèmes autres que le BTC.

Dilemme

Cela pose un dilemme pour 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é de rollup.

D’une part, l’utilisation de la chaîne BTCBloc comme couche de disponibilité des données imposerait une limite stricte à la scalabilité de rollup. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollups pouvant exister à la fois et au nombre total de transactions pouvant être traitées off-chain pour tous les rollups. Chaque mise à jour du rollup nécessite une quantité d’espace Bloc proportionnelle 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’extension.

D’autre part, l’utilisation de différentes couches pour assurer la disponibilité des données éliminera la limite rigide des avantages de l’évolutivité, mais cela soulèvera également de nouveaux problèmes de sécurité et de souveraineté. Dans le Rollup utilisant 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 les 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, n’importe quel producteur de Bloc sur le système de disponibilité des données externes peut détourner les fonds des utilisateurs de BTCRollup en produisant un Bloc au lieu de diffuser effectivement ce Bloc, rendant ainsi les données disponibles.

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