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

Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups est récemment devenu le point focal de l’extension de BTC, devenant la première chose à véritablement voler la vedette au Lightning Network, avec une attention plus large. Rollups vise à être une deuxième couche hors chaîne non limitée ou restreinte par la liquidité centrale du Lightning Network, c’est-à-dire que les utilisateurs finaux doivent avoir des fonds pré-alloués (ou “empruntés”) pour recevoir de l’argent, ou que les nœuds de routage intermédiaires ont besoin de solde de canal pour faciliter le flux complet des montants de paiement de l’expéditeur au destinataire.

Ces systèmes ont été initialement 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 (par exemple BTC). Cet article ne vise pas à discuter de la mise en œuvre actuelle sur BTC, mais plutôt des fonctionnalités idéales de Rollup 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 tous les soldes des utilisateurs dans Rollup. Ce UTXO contient un engagement, qui existe sous la forme de la racine de Merkle dans l’arbre de Merkle, engageant 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.

Les opérateurs de Rollup doivent inclure un ZKP dans les transactions pour mettre à jour la racine de merkle du solde du compte hors chaîne lors de l’achèvement des transactions hors chaîne. Sans ce ZKP, la transaction sera invalide et ne pourra 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 titulaire du compte et si l’opérateur n’a pas mis à jour le solde de manière malveillante 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 placer leurs branches dans l’arbre afin de pouvoir se retirer à tout moment sans autorisation?

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 tout l’arbre, ce serait 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 dans les transactions de mise à jour du Rollup.

Dans les implémentations plus avancées, utilisez des différences de solde. Il s’agit essentiellement d’un résumé des comptes qui ont ajouté ou diminué des 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 l’état actuel du solde.

Cela permet d’économiser considérablement sur les dépenses et l’espace Bloc (et donc sur les fonds), tout en permettant aux utilisateurs de s’assurer qu’ils ont accès aux informations nécessaires pour sortir unilatéralement. Les règles du rollup exigent que ces données soient incluses dans le rollup formel fourni aux utilisateurs via la chaîne de Bloc, c’est-à-dire que les transactions sans résumé de compte ou 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 pour le retrait des utilisateurs est de stocker les données ailleurs que sur la chaîne de Bloc. Cela soulève des questions subtiles, le rollup devant toujours s’assurer 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 où la sécurité est tout aussi forte. 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 preuve que les données existent en dehors de la chaîne, ce qui est finalement un problème de machine Oracle. La chaîne de blocs BTC ne peut pas vérifier complètement autre chose que ce qui se passe dans son propre bloc en dehors de la chaîne. La meilleure chose qu’elle puisse faire est de vérifier les ZKP. Cependant, les ZKP ne peuvent pas vérifier si les blocs contenant des données de regroupement ont réellement été diffusés publiquement après leur génération. Ils ne peuvent pas vérifier si les informations externes sont réellement accessibles à tous.

Cela ouvre la porte aux attaques de rétention de données, à savoir 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 fait pas disponibles. Cela empêche les utilisateurs de retirer leurs fonds. La seule véritable solution est de s’appuyer entièrement sur la valeur et la structure incitative des systèmes autres que le BTC.

Entre deux feux

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 chaîne de blocs BTC ou ailleurs. Ce choix a un impact significatif sur la sécurité, la souveraineté et la scalabilité de Rollup.

D’une part, l’utilisation de la chaîne de Blocs Bitcoin (BTCBloc) en tant que couche de disponibilité des données imposerait une limite stricte à la scalabilité des rollups. L’espace Bloc est limité, ce qui impose une limite au nombre de rollups pouvant exister en même temps et au nombre total de transactions pouvant être traitées off-chain pour 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, au-delà duquel il n’y a plus de potentiel d’extension.

D’un autre côté, l’utilisation de différentes couches pour assurer la disponibilité des données élimine la limite rigide des avantages en termes de scalabilité, mais cela soulève également de nouvelles questions de sécurité et de souveraineté. Dans le Rollup qui utilise BTC pour assurer la disponibilité des données, l’état du Rollup ne peut pas changer si les données que l’utilisateur souhaite extraire ne sont pas automatiquement publiées sur la blockchain. Avec les Validiums, cette garantie dépend entièrement de la capacité du système externe utilisé à résister à la fraude 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 un bloc au lieu de diffuser effectivement ce bloc, afin de rendre les données disponibles.

Alors, si nous parvenons réellement à mettre en œuvre un Rollup idéal sur BTC, permettant réellement les retraits unilatéraux des utilisateurs, à quoi cela ressemblera-t-il ?