Bitcoin Magazine: Quels sont les défis auxquels fait face Rollup ?

Source: Bitcoin Magazine; Translation: 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, 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 intermediate routing nodes need channel balances to facilitate the full flow of payment amounts from sender to receiver.

Ces systèmes ont été initialement déployés sur des systèmes Turing complets tels qu’Ethereum et d’autres, 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 situation actuelle de la mise en œuvre sur BTC, mais à examiner les fonctionnalités de Rollup idéalisées recherchées depuis longtemps, qui dépendent 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) contient les soldes de tous les utilisateurs dans Rollup. Ce UTXO contient un engagement sous la forme de la racine de Merkle, qui représente 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 unilatéralement de Rollup à tout moment sans permission, en prouvant simplement que leur compte fait partie de l’arbre de Merkle, sans nécessiter l’autorisation de l’opérateur.

L’opérateur Rollup doit inclure un ZKP dans la transaction pour mettre à jour la racine de Merkle du solde du compte hors chaîne lors de l’achèvement de la transaction hors chaîne. Sans ce ZKP, la transaction est invalide et ne peut donc pas être incluse dans le bloc. Cette preuve permet aux gens de vérifier si toutes les modifications apportées au compte hors chaîne 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 de la chaîne, les utilisateurs peuvent la consulter et y accéder, mais comment peuvent-ils placer leurs propres branches dans l’arbre afin de pouvoir les 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 change, les informations sont directement placées dans la blockchain. Ce n’est pas tout l’arbre, ce serait absurde, mais les informations nécessaires pour reconstruire l’arbre. Dans une mise en œuvre 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 une implémentation plus avancée, utilisez la différence de solde du compte. Cela résume essentiellement quels comptes ont augmenté ou diminué leurs 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 des frais 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 se retirer 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 façon de traiter la question de la disponibilité des données des utilisateurs est de stocker les données ailleurs que sur la chaîne de Bloc. Cela soulève des questions subtiles, car 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 des données qui existent en dehors de la preuve hors chaîne, ce qui est finalement un problème de machine Oracle. La chaîne Bloc de BTC ne peut pas vérifier complètement autre chose que ce qui se passe dans son propre bloc hors chaîne, ce qu’elle peut faire de mieux est de vérifier les ZKP. Cependant, les ZKP ne peuvent pas vérifier si le bloc contenant les données de rollup a réellement été diffusé publiquement après sa 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 créer des engagements sur les données soumises et les utiliser pour faire avancer le rollup, mais les données ne sont en réalité pas disponibles. Cela empêche les utilisateurs de retirer des fonds. La seule vraie solution est de s’appuyer entièrement sur la valeur et la structure incitative des systèmes autres que le BTC.

Dans l’impasse

Cela pose un dilemme pour le rollup. Lorsqu’il s’agit de 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 considérable 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 fixe une limite supérieure contraignante à l’extensibilité des rollups. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollups pouvant exister à un moment donné et au nombre total de transactions pouvant être traitées off-chain par 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 ne permet de compresser les données qu’à un certain degré, à ce stade, 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 élimine la limite rigide des avantages d’évolutivité, mais cela pose également de nouveaux problèmes de sécurité et de souveraineté. Dans le Rollup qui utilise 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 peut 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 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 véritablement des retraits unilatéraux pour les utilisateurs, à quoi cela ressemblerait-il ?