Source: Bitcoin Magazine; Compilation: Wu Zhu, Jinse Finance

Rollups est devenu récemment un point focal de l'extension de BTC, devenant la première chose à vraiment voler la vedette au Lightning Network, dans un contexte d'attention plus large. Rollups vise à être une deuxième couche hors chaîne, non limitée ou restreinte par la liquidité principale 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 intermédiaires ont besoin d'avoir un solde de canal pour faciliter le flux complet des paiements du destinataire vers l'expéditeur.

Ces systèmes étaient initialement développés pour fonctionner sur Ethereum et d'autres systèmes Turing complet, mais récemment, l'accent a été mis sur leur portage vers des blockchains basées sur UTXO, telles que BTC. Cet article ne vise pas à discuter de l'état actuel de la mise en œuvre sur BTC, mais à discuter des fonctionnalités d'un Rollup idéalisé, qui dépendent des fonctionnalités actuellement non prises en charge par BTC, c'est-à-dire la capacité de vérifier les preuves de connaissances nulles (ZKP) directement 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 partir à tout moment sans permission, 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 pour mettre à jour la racine 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 donc pas être incluse dans le Bloc. Cette preuve permet aux gens de vérifier si toutes les modifications du solde du compte hors chaîne ont été correctement autorisées par le propriétaire du compte, et si l'opérateur n'a pas malicieusement mis à jour le solde pour voler les fonds des utilisateurs ou les redistribuer de manière malhonnête à d'autres utilisateurs.

Le problème est que si seulement la racine de l'arbre de Merkle est publiée en off-chain, les utilisateurs peuvent la consulter et y accéder, mais comment peuvent-ils insérer leurs branches dans l'arbre afin de pouvoir sortir 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 chaîne de blocs. 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 les soldes, et les comptes ne sont ajoutés que dans les transactions de mise à jour du Rollup.

Dans des mises en œuvre plus avancées, utilisez la différence de solde. Fondamentalement, il s'agit d'un résumé des comptes qui ont augmenté ou diminué pendant le processus de mise à jour. Cela permet à chaque mise à jour Rollup de contenir uniquement les modifications de solde des comptes qui ont eu lieu. Ensuite, les utilisateurs peuvent simplement parcourir la chaîne et "calculer" à partir du début du Rollup pour obtenir l'état actuel des soldes des comptes, ce qui leur permet de reconstruire l'arbre de Merkle pour les soldes actuels.

Cela permet d'économiser considérablement les dépenses et l'espace de Bloc (et donc de l'argent), 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 officiel fourni aux utilisateurs via la chaîne de Bloc, et que les transactions ne contenant pas de résumé de compte ou de différence de compte soient considérées comme invalides.

Période de validité

Une autre approche pour résoudre le problème de disponibilité des données d'extraction des utilisateurs 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 chaînes de Blocs sont utilisées à cette fin, spécialement 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 preuve que les données existent en dehors de la chaîne, ce qui pose finalement un problème d'Oracle Machine. La chaîne Bloc du BTC ne peut pas vérifier entièrement autre chose que ce qui se passe dans son propre bloc off-chain, elle peut seulement le mieux vérifier le ZKP. Cependant, le ZKP ne peut pas vérifier si les données de bloc contenant les données de rollup ont réellement été diffusées publiquement après leur génération. Il ne peut pas vérifier si les informations externes sont réellement 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 pour la publication de données et leur utilisation pour faire avancer 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 compter sur des systèmes de valeur et de motivation en dehors de BTC.

Entre l'enclume et le marteau

Cela pose un dilemme pour le 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é du 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 à l'évolutivité des rollups. L'espace Bloc est limité, ce qui limite le nombre de rollups pouvant exister à la fois et le nombre total de transactions pouvant être traitées hors chaîne. 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 permet seulement de compresser les données jusqu'à un certain point, à 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 élimine la limite supérieure rigide des avantages d'évolutivité, mais cela pose également de nouveaux problèmes de sécurité et de souveraineté. Dans le Rollup qui utilise BTC pour assurer la disponibilité des données, si les données que l'utilisateur souhaite 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 fraude 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 Bloc au lieu de diffuser réellement ce Bloc, rendant ainsi les données disponibles.

Alors, si nous mettons vraiment en œuvre une implémentation Rollup idéale sur BTC et réalisons véritablement les retraits unilatéraux des utilisateurs, à quoi cela ressemblera-t-il ?