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

Source: Bitcoin Magazine; Compilation: Wu Zhu, 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 é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 (comme BTC). Cet article ne vise pas à discuter de l’état actuel de la mise en œuvre sur BTC, mais plutôt des fonctionnalités d’un Rollup idéalisé que les gens recherchent depuis longtemps, qui dépendent de la capacité de vérifier directement les preuves de connaissance nulle (ZKP) sur BTC, une fonctionnalité actuellement non prise en charge.

L’architecture de base de Roll est la suivante: un seul compte (UTXO dans BTC) contient les soldes de tous les utilisateurs dans Rollup. Cette UTXO contient un engagement sous la forme d’une racine de Merkle pour tous les soldes actuels des comptes existants dans Rollup. Tous ces comptes sont autorisés par une paire de clés publiques/privées, de sorte que les utilisateurs doivent toujours signer certains contenus avec une clé secrète pour effectuer des dépenses hors chaîne. Cette partie de la structure permet aux utilisateurs de quitter Rollup à tout moment sans autorisation en prouvant par une transaction que leur compte fait partie de l’arbre 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 lors du processus de finalisation des transactions off-chain, sans quoi les transactions seront invalides et ne pourront pas être incluses dans la Blockchain. Cette preuve permet de vérifier si toutes les modifications du solde du compte off-chain ont été autorisées par le titulaire du compte et si l’opérateur n’a pas intentionnellement mis à jour le solde pour voler les fonds des utilisateurs ou les redistribuer de manière malhonnête.

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 pour pouvoir sortir à 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 l’arbre entier, 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 le compte ne sera ajouté que lors de la mise à jour des transactions du Rollup.

Dans les implémentations plus avancées, utilisez la différence de solde du compte. Cela résume essentiellement quels comptes ont ajouté ou réduit des fonds lors du processus de mise à jour. Cela permet à chaque mise à jour du 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 du solde du compte actuel.

Cela permet d’économiser beaucoup de dépenses et d’espace Bloc (et donc d’économiser des fonds), tout en permettant aux utilisateurs de s’assurer l’accès aux informations nécessaires à une sortie unilatérale. Les règles du rollup exigent que ces données soient incluses dans le rollup formel fourni par la chaîne Bloc aux utilisateurs, de sorte que les transactions sans résumé de compte ou différence de compte sont considérées comme invalides.

Période de validité

Une autre façon de traiter les problèmes d’accessibilité des données d’extraction des utilisateurs est de les placer ailleurs que sur le bloc Bloc. Cela soulève des problèmes subtils, Rollup doit toujours garantir que les données sont accessibles ailleurs. Traditionnellement, d’autres blocs sont utilisés à cette fin, spécialement conçus pour servir de couche d’accessibilité des données pour des systèmes tels que Rollup.

Cela crée 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 l’existence des données dans une preuve off-chain, ce qui pose finalement un problème d’Oracle Machine. La chaîne de Blocs de BTC ne peut pas vérifier complètement tout ce qui se passe en dehors de son propre bloc off-chain, la meilleure chose qu’elle puisse faire est de vérifier les ZKP. Cependant, les ZKP ne peuvent 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 à des 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 réalité pas disponibles. Cela empêche les utilisateurs de retirer des 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 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 de blocs BTC comme couche de disponibilité des données imposera une limite maximale à l’évolutivité de rollup. L’espace Bloc est limité, ce qui limite le nombre de rollup qui peuvent exister à la fois et le nombre total de transactions que tous les rollup peuvent traiter hors ligne. 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 ne permet 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 éliminera le plafond dur des gains d’évolutivité, mais cela soulèvera é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 à 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 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 saisir les fonds des utilisateurs de BTCRollup en produisant un Bloc au lieu de diffuser effectivement ce Bloc, rendant ainsi les données disponibles.

Alors, si nous parvenons réellement à réaliser une mise en œuvre Rollup idéale sur BTC, permettant véritablement des retraits unilatéraux des utilisateurs, à quoi cela ressemblerait-il ?