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

Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups est récemment devenu le point focal de l’extension de BTC, devenant la première chose à vraiment voler la vedette au Lightning Network, dans un plus large contexte d’attention. Rollups vise à devenir une deuxième couche off-chain non limitée ou restreinte par les contraintes de liquidité du Lightning Network, c’est-à-dire que les utilisateurs finaux doivent avoir des fonds pré-alloués (ou “prêtés”) pour recevoir de l’argent, ou que les nœuds de routage ont besoin d’équilibres de canal pour faciliter le flux complet des paiements du expéditeur au destinataire.

Ces systèmes ont initialement été déployés 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 (par exemple BTC). Cet article ne vise pas à discuter de la mise en œuvre actuelle sur BTC, mais à examiner les fonctionnalités de Rollup idéales recherchées par les gens à long terme, 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 (zk-SNARKs) 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. Cette UTXO contient un engagement sous la forme de la racine de l’arbre 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, donc 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 autorisation, en produisant une preuve de transaction prouvant que leur compte fait partie de l’arbre de Merkle, ils peuvent sortir de Rollup unilatéralement sans l’autorisation de l’opérateur.

Les opérateurs de Rollup doivent inclure un ZKP dans les transactions pour mettre à jour le solde du compte off-chaincompte lors de la finalisation des transactions hors chaîne, sans quoi les transactions seront invalides et ne pourront pas être incluses dans le Bloc. Cette preuve permet de vérifier si toutes les modifications du solde du compte off-chaincompte ont été correctement 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 réattribuer de manière non honnê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 vont-ils placer leurs branches dans l’arbre afin de pouvoir les retirer à tout moment sans permission?

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 intégrées à la blockchain. Ce n’est pas tout l’arbre, ce serait 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 lors de la mise à jour des transactions du Rollup.

Dans une implémentation plus avancée, utilisez la différence 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 changements de solde du compte qui se sont produits. Ensuite, les utilisateurs peuvent simplement scanner 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 actuel.

Cela permet d’économiser des coûts importants et de l’espace Bloc (et donc de l’argent), tout en permettant aux utilisateurs de garantir 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 à l’aide de la chaîne Bloc, et donc que les transactions ne contenant pas de résumé de compte ou de différence de compte sont considérées comme des transactions invalides.

Période de validité

Une autre façon de traiter les problèmes de disponibilité des données d’extraction des utilisateurs est de les placer ailleurs que sur la chaîne de blocs. Cela introduit des problèmes subtils, le rollup devant toujours garantir que les données sont disponibles ailleurs. Historiquement, d’autres blocs ont été utilisés à cette fin, spécialement conçus pour servir de 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 la vérification des données qui existent en dehors de la preuve de chaîne, ce qui est finalement un problème de machine Oracle. La chaîne de blocs BTC ne peut pas vérifier complètement autre chose que ce qui se passe dans son propre bloc hors chaîne, elle peut au mieux vérifier ZKP. Cependant, ZKP ne peut pas vérifier si le bloc contenant les 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 créer un engagement envers les données publiées et les utiliser pour promouvoir rollup, mais les données ne sont pas réellement disponibles. Cela empêche les utilisateurs de retirer des fonds. La seule véritable solution est de dépendre entièrement de la valeur et de la structure d’incitation d’un système autre que le BTC.

L’impasse

Cela pose un dilemme pour Rollup. Quand il s’agit de problèmes de disponibilité des données, il y a 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é de Rollup.

D’une part, l’utilisation de la Blockchain Bitcoin comme couche de disponibilité des données fixe une limite supérieure contraignante à la scalabilité de rollup. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollups pouvant exister à la fois et au nombre total de transactions pouvant être traitées hors chaîne. Chaque mise à jour de rollup doit être proportionnelle à l’espace Bloc disponible, en fonction du 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 pas de potentiel d’expansion supplémentaire à ce stade.

D’autre part, l’utilisation de différentes couches pour assurer la disponibilité des données éliminera le plafond rigide des avantages de la scalabilité, mais elle apportera é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 l’utilisateur doit 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 Blocs plutôt qu’en diffusant effectivement ces Blocs, rendant ainsi les données disponibles.

Alors, si nous réussissons vraiment à mettre en œuvre une implémentation Rollup idéale sur BTC et à réaliser le retrait unilatéral des utilisateurs, à quoi cela ressemblerait-il ?