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

Source: Bitcoin Magazine; Compilation: Wuzhu, Jinse Finance

Rollups est récemment devenu le point focal de l’expansion de BTC, devenant la première chose à véritablement voler la vedette au Lightning Network, avec une attention plus large. Rollups vise à devenir une deuxième couche off-chain non limitée par les contraintes ou restrictions de Liquidité du Lightning Network, c’est-à-dire que les utilisateurs finaux doivent disposer de fonds pré-alloués (ou “empruntés”) pour recevoir de l’argent, ou que les Nœud de routage intermédiaires ont besoin d’un solde de canal pour faciliter le flux complet des paiements du expéditeur au destinataire.

Ces systèmes étaient initialement 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 Bitcoin (BTC). Cet article ne vise pas à discuter de l’état actuel de la mise en œuvre sur BTC, mais plutôt à discuter des fonctionnalités d’un Rollup idéalisé, qu’il est actuellement impossible de réaliser sur BTC, c’est-à-dire la capacité de vérifier directement les preuves de zéro connaissance (ZKP) sur BTC.

L’architecture de base de Roll est la suivante : un compte unique (UTXO dans BTC) contient 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 contient 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 certaines données avec une clé secrète. Cette partie de la structure permet aux utilisateurs de quitter à tout moment sans autorisation, en prouvant simplement 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 afin de mettre à jour la racine de merkle du solde du compte hors chaîne lorsqu’ils effectuent des transactions hors chaîne. Sans ce ZKP, la transaction est invalide et ne peut pas être incluse dans le bloc. Cette preuve permet de vérifier si toutes les modifications apportées au solde du compte hors chaîne ont été autorisées par le détenteur de compte, et si l’opérateur n’a pas malicieusement modifié le solde pour voler les fonds des utilisateurs ou les réattribuer 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. Comment peuvent-ils alors placer leurs branches dans l’arbre afin de pouvoir sortir à tout moment sans autorisation ?

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, la différence de solde est utilisée. C’est essentiellement un résumé des comptes qui 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 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 l’avoir actuel du solde.

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 une sortie unilatérale. Les règles du 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érence de compte sont considérées comme invalides.

Période de validité

Une autre approche pour traiter la question de l’accessibilité des données d’extraction utilisateur est de stocker les données ailleurs que sur la chaîne Bloc. Cela soulève des questions délicates, le rollup devant toujours s’assurer que les données sont accessibles ailleurs. Traditionnellement, d’autres chaînes Bloc sont utilisées à cette fin, spécialement conçues pour servir de couche d’accessibilité 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 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.

Il faut vérifier que les données existent dans d’autres preuves off-chain, c’est en fin de compte un problème d’Oracle Machine. Le Bloc de BTC ne peut pas vérifier complètement quoi que ce soit qui se produit en dehors de son propre Blocoff-chain, sa meilleure capacité est de vérifier ZKP. Cependant, ZKP ne peut pas vérifier si les données de 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 tout le monde.

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 s’appuyer entièrement sur la valeur et la structure incitative des systèmes autres que le BTC.

Entre le marteau et l’enclume

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

D’une part, l’utilisation de la chaîne de blocs BTC comme couche de disponibilité des données imposerait une limite rigide à l’évolutivité de rollup. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollup pouvant exister à un moment donné et au nombre total de transactions pouvant être traitées hors chaîne. Chaque mise à jour de rollup nécessite une proportionnelle à l’espace Bloc du 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’expansion.

D’autre part, l’utilisation de différentes couches pour atteindre la disponibilité des données éliminera le plafond dur des gains d’évolutivité, mais elle apportera également de nouveaux problèmes de sécurité et de souveraineté. Dans un Rollup utilisant BTC pour atteindre la disponibilité des données, si les données que les utilisateurs doivent extraire ne sont pas automatiquement publiées sur la chaîne de blocs, 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 saisir les fonds des utilisateurs de BTCRollup en produisant des blocs au lieu de diffuser effectivement ce bloc, rendant ainsi les données disponibles.

Alors, si nous parvenons vraiment à mettre en place une mise en œuvre Rollup idéale sur BTC et à réaliser le retrait unilatéral des utilisateurs, à quoi cela ressemblera-t-il ?