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

Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups sont récemment devenus le point central de l’expansion de BTC, devenant la première véritable chose à voler la vedette au Lightning Network, dans un contexte d’attention plus large. Les Rollups visent à devenir une deuxième couche hors chaîne, non limitée ou restreinte par les contraintes de Liquidité centrales au Lightning Network, c’est-à-dire que les utilisateurs finaux ont besoin que des fonds soient préalablement alloués (ou “empruntés”) pour recevoir de l’argent, ou que les Nœuds de routage intermédiaires aient besoin de soldes de canal pour faciliter le flux complet des paiements du payeur au bénéficiaire.

Ces systèmes ont été initialement développés pour fonctionner sur Ethereum et d’autres systèmes Turing complets, mais récemment, l’accent s’est déplacé vers leur portage sur des blockchains basées sur UTXO, comme BTC. Cet article n’a pas l’intention de discuter de l’état actuel de mise en œuvre sur BTC, mais plutôt des fonctionnalités idéalisées longtemps recherchées dans Rollup, 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 (ZKP) 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, qui existe sous forme de racine de Merkle de l’arbre de Merkle, englobant 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 off-chain, les utilisateurs doivent toujours signer certains contenus avec la clé secrète. Cette partie de la structure permet aux utilisateurs de partir à tout moment sans permission, simplement en prouvant par une transaction 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 la racine merkle du solde du compte off-chain pendant le processus de transaction off-chain, sans quoi la transaction serait invalide et ne pourrait pas être incluse dans la Blockchain. Cette preuve permet de vérifier si toutes les modifications du solde du compte off-chain 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 frauduleuse à 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 sans autorisation quand ils le souhaitent?

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 ne sont 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 seront ajoutés que dans les transactions de mise à jour du Rollup.

Dans les implémentations plus avancées, utilisez la différence de solde du compte. Cela résume essentiellement quels comptes ont augmenté ou diminué leur financement lors de la mise à jour. Cela permet à chaque mise à jour de Rollup de ne contenir que les modifications de solde de compte qui se sont produites. Ensuite, les utilisateurs peuvent simplement balayer la chaîne et « calculer » à partir du début du Rollup pour obtenir l’état actuel du solde de compte, ce qui leur permet de reconstruire l’arbre de Merkle pour le solde actuel.

Cela permet d’économiser beaucoup de dépenses et d’espace de bloc (et donc d’argent), tout en permettant aux utilisateurs de garantir l’accès aux informations nécessaires pour une sortie unilatérale. Selon les règles du rollup, ces données doivent être incluses dans le rollup officiel fourni aux utilisateurs via la chaîne de blocs, et les transactions qui n’incluent pas de résumé de compte ou de différence de compte sont considérées comme invalides.

Période de validité

Une autre approche pour résoudre le problème de la disponibilité des données utilisateur est de stocker les données ailleurs que sur la Blocchaîne. Cela soulève des questions délicates, car le rollup doit toujours garantir que les données sont disponibles ailleurs. Traditionnellement, d’autres Blocchaînes sont utilisées à cette fin, spécialement conçues comme couche de disponibilité des données pour des systèmes tels que le rollup.

Cela crée un dilemme de sécurité tout aussi puissant. Lorsque les données sont directement publiées sur la chaîne BTCBloc, 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 de vérifier que les données existent dans la preuve off-chain d’autres, ce qui est finalement un problème d’Oracle Machine. La chaîne de blocs BTC ne peut pas vérifier complètement quoi que ce soit en dehors de ce qui se passe dans son propre Bloc off-chain, elle peut tout au plus vérifier ZKP. Cependant, ZKP ne peut pas vérifier si le Bloc contenant des données de rollup a été réellement 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 la création d’engagements pour publier des données et les utiliser 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 le marteau et l’enclume

Cela pose un dilemme pour le rollup. Lorsqu’il s’agit de la 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 significatif sur la sécurité, la souveraineté et la scalabilité du rollup.

D’une part, l’utilisation de la chaîne BTCBloc comme couche de disponibilité des données fixe une limite supérieure rigide à l’évolutivité de rollup. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollup pouvant exister à la fois, ainsi qu’au nombre total de transactions pouvant être traitées hors chaîne par rollup. Chaque mise à jour de rollup nécessite une proportionnelle de l’espace Bloc avec le nombre de comptes dont le solde a changé depuis la dernière mise à jour. La théorie de l’information ne permet que la compression des données jusqu’à un certain point, il n’y a donc plus de potentiel d’expansion.

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 elle 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, 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 Validiums, cette garantie dépend entièrement de la capacité des systèmes externes utilisés à 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 des Blocs plutôt qu’en diffusant réellement ces Blocs, rendant ainsi les données disponibles.

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