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

Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups ont récemment été au centre de l’attention pour l’expansion de BTC, devenant la première chose à réellement voler la vedette au Lightning Network, avec une attention plus large. Rollups visent à devenir une deuxième couche hors chaîne, non limitée par les contraintes ou restrictions de Liquidité 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 d’équilibres de canal pour faciliter le flux complet des paiements du payeur au bénéficiaire.

Ces systèmes fonctionnaient initialement sur Ethereum et d’autres systèmes complets de Turing, mais récemment, l’accent a été mis sur leur portage sur des blockchains basées sur UTXO telles que BTC. L’intention de cet article n’est pas de discuter de l’état actuel de la mise en œuvre sur BTC, mais plutôt de discuter de la fonctionnalité longtemps recherchée des Rollups idéalisés, qui dépend d’une fonctionnalité que BTC ne prend pas en charge actuellement, à savoir la possibilité de vérifier Zéro Knowledge Proof (ZKP) directement sur BTC.

L’architecture de base de Roll est la suivante : un seul compte (UTXO dans BTC) stocke les soldes de tous les utilisateurs dans Rollup. Ce UTXO contient un engagement, sous la forme de la racine de Merkle de l’arbre de Merkle, engageant tous les soldes actuels des comptes dans Rollup. Tous ces comptes sont autorisés par une clé publique / une clé privée, de sorte que, pour effectuer des dépenses hors chaîne, les utilisateurs doivent encore signer certains contenus avec une clé secrète. Cette partie de la structure permet aux utilisateurs de quitter unilatéralement Rollup à tout moment sans permission, en prouvant simplement que leur compte fait partie de l’arbre de Merkle, sans avoir besoin d’une autorisation de l’opérateur.

Les opérateurs de Rollup doivent inclure un ZKP dans les transactions afin de mettre à jour la racine merkle du solde du compte hors chaîne lors de la finalisation des transactions hors chaîne. Sans ce ZKP, la transaction sera invalide et ne pourra pas être incluse dans la chaîne de blocs. Cette preuve permet aux gens 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 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 hors-chaîne, les utilisateurs peuvent la consulter et y accéder. Comment vont-ils insérer leurs branches dans l’arbre afin de pouvoir se retirer sans autorisation quand ils le souhaitent ?

Rollup approprié

Dans le 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 insérées dans la chaîne. Ce n’est pas tout l’arbre, ce serait trop absurde, mais les informations nécessaires à la reconstruction de 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, utilisez les différences de solde. Cela résume essentiellement quels comptes ont ajouté ou retiré des 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, l’utilisateur peut 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 des dépenses considérables et de l’espace Bloc (et donc de l’argent), tout en permettant aux utilisateurs de s’assurer l’accès aux informations nécessaires pour une sortie unilatérale. Les règles de rollup exigent que ces données soient incluses dans le rollup formel fourni aux utilisateurs en utilisant la chaîne Bloc, c’est-à-dire que les transactions ne contenant pas de résumé de Bloc ou de différences de compte sont considérées comme invalides.

Durée de validité

Une autre façon de résoudre le problème de disponibilité des données d’extraction des utilisateurs est de stocker les données ailleurs que sur la chaîne de Bloc. Cela soulève des problèmes subtils, car le rollup doit toujours s’assurer que les données sont disponibles ailleurs. Traditionnellement, d’autres chaînes de Bloc 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 la vérification de la présence de données sur d’autres preuves en dehors de la chaîne, ce qui pose finalement un problème d’Oracle Machine. La chaîne Bloc BTC ne peut pas vérifier complètement ce qui se passe en dehors de son propre Bloc off-chain, la meilleure chose qu’elle puisse faire est de vérifier ZKP. Cependant, ZKP ne peut 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 un engagement envers la publication des données 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 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.

Être dans l’impasse

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 Blockchain Bitcoin (BTC) comme couche de disponibilité des données fixe une limite supérieure contraignante à l’évolutivité des rollups. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollups pouvant exister à un moment donné, ainsi qu’au nombre total de transactions que tous les rollups peuvent traiter hors chaîne. Chaque mise à jour du rollup doit être proportionnelle à l’espace Bloc selon le 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, ce qui signifie qu’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 le plafond dur des gains d’évolutivité, mais elle pose également de nouveaux problèmes de sécurité et de souveraineté. Dans 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 chaîne de blocs, l’état de Rollup ne peut pas changer. Avec Validiums, cette garantie dépend entièrement de la capacité du système externe utilisé à résister à la fraude et à la dissimulation de 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 au lieu de diffuser réellement ce bloc, permettant ainsi la disponibilité des données.

Alors, si nous parvenons vraiment à réaliser une implémentation Rollup idéale sur BTC, permettant véritablement des retraits unilatéraux des utilisateurs, à quoi cela ressemblerait-il ?