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

Source: Bitcoin Magazine; Compiler: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC scalability, becoming the first thing to truly steal the spotlight from the Lightning Network in terms of broader attention. Rollups aim to be an off-chain second layer that is not constrained or restricted by the core liquidity of the Lightning Network, which 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 initialement été déployés sur des systèmes Turing complet tels qu’Ethereum et d’autres, mais récemment, l’accent a été mis sur leur portage sur des blockchains basées sur UTXO (comme BTC). Cet article ne vise pas à discuter de la mise en œuvre actuelle sur BTC, mais à examiner les fonctionnalités d’un Rollup idéalisé, qui dépend de capacités actuellement non prises en charge par BTC, à savoir la capacité de vérifier directement les preuves de connaissance nulle (zk-SNARKs) sur BTC.

L’architecture de base de Roll est la suivante : un seul compte (UTXO dans BTC) qui stocke les soldes de tous les utilisateurs dans Rollup. Cette UTXO contient un engagement sous forme de racine de Merkle de l’arbre de Merkle, qui représente tous les soldes actuels des comptes dans Rollup. Tous ces comptes sont autorisés par une clé publique / privée, ce qui signifie 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 fournissant une preuve de transaction montrant que leur compte fait partie de l’arbre de Merkle, ils peuvent sortir de Rollup unilatéralement sans l’autorisation d’un opérateur.

Les opérateurs de Rollup doivent inclure un ZKP dans la transaction pour mettre à jour la racine de merkle du solde du compte hors chaîne lors de la finalisation de la transaction hors chaîne. Sans ce ZKP, la transaction sera invalide et ne peut donc pas être incluse dans le bloc. Cette preuve permet de vérifier si toutes les modifications du solde du compte hors chaîne sont correctement autorisées par le titulaire du compte et si l’opérateur ne met pas malicieusement à jour le solde pour voler les fonds des utilisateurs ou les réaffecter de manière malhonnête à d’autres utilisateurs.

Le problème est que si seule la racine de l’arbre Merkle est publiée hors chaîne et que les utilisateurs peuvent la consulter et y accéder, comment peuvent-ils insérer leurs branches dans l’arbre afin de pouvoir sortir sans autorisation quand ils le souhaitent?

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’arbre entier, 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 sont ajoutés que lors de la mise à jour des transactions Rollup.

Dans les mises en œuvre plus avancées, utilisez des différences de solde du compte. Cela résume essentiellement quels comptes ont augmenté ou diminué les 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’ depuis le début du Rollup pour obtenir l’état actuel des soldes du compte, ce qui leur permet de reconstruire l’arbre de Merkle des soldes actuels.

Cela permet d’économiser considérablement les dépenses et l’espace Bloc (et donc les fonds), tout en permettant aux utilisateurs de s’assurer 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 formel fourni aux utilisateurs à l’aide de 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 d’extraction utilisateur est de stocker les données ailleurs que sur la chaîne de Bloc. Cela soulève des questions subtiles, le rollup doit toujours garantir que les données sont disponibles ailleurs. Traditionnellement, d’autres chaînes de Bloc sont utilisées à cette fin, spécifiquement conçues pour servir de 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, ce qui pose finalement un problème d’Oracle Machine. Le Bloc de BTC ne peut pas vérifier complètement quoi que ce soit en dehors de ce qui se passe dans son propre off-chain, il peut au mieux vérifier ZKP. Cependant, ZKP ne peut pas vérifier si les données rollup du Bloc, une fois générées, sont réellement diffusées publiquement. Il ne peut pas vérifier si les informations externes sont réellement rendues publiques pour tous.

Cela ouvre la porte aux attaques de rétention de données, c’est-à-dire la création d’engagements envers la publication de données et leur utilisation pour faire avancer le rollup, mais les données ne sont en fait pas disponibles. Cela empêche les utilisateurs de retirer leurs fonds. La seule solution véritable est de s’appuyer entièrement sur la valeur et la structure incitative des systèmes autres que le BTC.

Hésitation

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é de rollup. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollups pouvant exister en une seule fois 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’extension.

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 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, tout producteur de Bloc sur le système de disponibilité des données externes peut détourner 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 vraiment à réaliser une implémentation Rollup idéale sur BTC, permettant réellement aux utilisateurs de retirer unilatéralement, à quoi cela ressemblera-t-il?