Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance
Les rollups sont récemment devenus le centre de la mise à l’échelle du BTC, devenant la première chose à vraiment « voler la vedette » au Lightning Network, en termes d’attention plus large. Les cumuls sont conçus pour être une couche 2 hors chaîne qui n’est pas contrainte ou restreinte par les restrictions de liquidité de base du Lightning Network, c’est-à-dire que l’utilisateur final a besoin que quelqu’un alloue (ou « prête ») les fonds à l’avance afin de recevoir l’argent, ou que la route intermédiaire Nœud ait besoin d’un solde de canal pour faciliter le flux du montant du paiement de l’expéditeur au destinataire.
Ces systèmes ont été 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 une blockchain basée sur UTXO (comme BTC). Cet article ne vise pas à discuter de la situation actuelle de leur mise en œuvre sur BTC, mais plutôt des fonctionnalités d’un Rollup idéalisé que la communauté a cherché à atteindre depuis longtemps, ce qui dépend de la capacité de BTC à vérifier directement les preuves de connaissances nulles (zk-SNARKs) que BTC ne supporte actuellement pas.
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, qui existe sous la forme de la racine de Merkle de l’arbre de Merkle, qui promet 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 afin de mettre à jour le solde du compte off-chain dans le processus de finalisation des transactions off-chain, sans quoi les transactions seraient invalides et ne pourraient pas être incluses dans la chaîne de blocs. Cette preuve permet aux gens de vérifier si toutes les modifications du solde du compte off-chain ont été légitimement 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 réattribuer 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 off-chain, les utilisateurs peuvent la consulter et y accéder, mais comment peuvent-ils placer leurs branches dans l’arbre afin de pouvoir se retirer sans autorisation quand ils le souhaitent ?
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. 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 le solde, et les comptes ne sont ajoutés que dans les transactions de mise à jour du Rollup.
Dans une implémentation plus avancée, utilisez les différences de solde du compte. 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 des soldes des comptes 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 des soldes des comptes, 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 de l’argent), tout en permettant toujours aux utilisateurs de s’assurer l’accès aux informations nécessaires pour quitter unilatéralement. Les règles de rollup exigent que ces données soient incluses dans le rollup formel fourni aux utilisateurs en utilisant la chaîne de Blocs, 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.
Une autre façon de résoudre les problèmes de disponibilité des données de retrait des utilisateurs est de les placer ailleurs que sur la chaîne Bloc. Cela soulève des problèmes subtils, car le rollup doit toujours garantir que les données sont disponibles ailleurs. Traditionnellement, d’autres chaînes Bloc sont utilisées à cet effet, spécialement conçues comme 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 la vérification que les données existent dans des preuves off-chain provenant d’autres sources, ce qui est finalement un problème d’Oracle Machine. Le Bloc de BTC ne peut pas vérifier complètement tout ce qui se passe en dehors de son propre Bloc off-chain, et il ne peut faire mieux que de vérifier les preuves à connaissances nulles. Cependant, les preuves à connaissances nulles ne peuvent pas vérifier si les données de rollup contenues dans le Bloc ont été diffusées publiquement après leur génération. Elles ne peuvent pas vérifier si les informations externes sont vraiment accessibles à tous.
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 promouvoir le rollup, mais les données ne sont pas réellement disponibles. Cela empêche les utilisateurs de retirer leurs fonds. La seule solution réelle est de dépendre entièrement de la valeur et de la structure d’incitation d’autres systèmes que le BTC.
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 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 fixera une limite maximale à la scalabilité de Rollup. L’espace Bloc est limité, ce qui limite le nombre de Rollup pouvant exister en même temps ainsi que le nombre total de transactions pouvant être traitées hors chaîne pour tous les Rollup. Chaque mise à jour de 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 n’autorise la compression des données que jusqu’à un certain point, à partir duquel il n’y a plus de potentiel d’expansion.
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 utilisant BTC pour assurer la disponibilité des données, si les données que les utilisateurs souhaitent 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 un Bloc plutôt qu’en diffusant réellement ce Bloc, ce qui rend les données disponibles.
Alors, si nous parvenons vraiment à mettre en œuvre une mise en œuvre Rollup idéale sur BTC et à réaliser véritablement des retraits unilatéraux des utilisateurs, à quoi cela ressemblera-t-il ?