Les rollups sont devenus le centre d'attention de la mise à l'échelle de Bitcoin ces derniers temps, devenant la première chose à vraiment « voler la vedette » au Lightning Network en termes de part d'esprit plus large. Les rollups visent à être une couche deux hors chaîne qui n'est pas liée ou contrainte par les limitations de liquidité qui sont au cœur du Lightning Network, c'est-à-dire que les utilisateurs finaux ont besoin que quelqu'un leur alloue (ou « leur prête ») des fonds à l'avance pour pouvoir recevoir de l'argent, ou des nœuds de routage intermédiaires nécessitant des soldes de canaux qui peuvent faciliter le mouvement du montant du paiement de l'expéditeur au destinataire.
Ces systèmes ont été développés à l'origine pour fonctionner 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 telles que Bitcoin. Cet article ne va pas discuter de l'état actuel des choses mises en œuvre sur Bitcoin actuellement, mais va discuter de la fonction d'un rollup idéalisé que les gens visent à long terme en fonction des fonctionnalités que Bitcoin ne prend pas actuellement en charge, à savoir la possibilité de vérifier les preuves de connaissance nulle (ZKP) sur Bitcoin directement.
L'architecture de base d'un rollup est la suivante : un seul compte (ou dans le cas de Bitcoin UTXO), détient les soldes de tous les utilisateurs du rollup. Cet UTXO contient un engagement sous la forme d'une racine merkle d'un arbre merkle qui s'engage sur tous les soldes actuels des comptes existants dans le rollup. Tous ces comptes sont autorisés à l'aide de paires de clés publiques/privées, donc pour proposer une dépense hors chaîne, un utilisateur doit toujours signer quelque chose avec une clé. Cette partie de la structure permet aux utilisateurs de quitter le rollup sans autorisation quand ils le souhaitent, simplement en créant une transaction prouvant que leur compte fait partie de l'arbre merkle, ils peuvent quitter unilatéralement le rollup sans l'autorisation de l'opérateur.
L'opérateur du rollup doit inclure un ZKP dans les transactions qui mettent à jour la racine Merkle des soldes de compte sur la chaîne lors du processus de finalisation des transactions hors chaîne. Sans ce ZKP, la transaction sera invalide et ne pourra donc pas être incluse dans la blockchain. Cette preuve permet aux personnes de vérifier que toutes les modifications apportées aux comptes hors chaîne ont été correctement autorisées par le(s) titulaire(s) du compte et que l'opérateur n'a pas effectué de mise à jour malveillante des soldes pour voler de l'argent aux utilisateurs ou le réaffecter à d'autres utilisateurs de manière malhonnête.
Le problème est que, si seule la racine de l'arbre Merkle est publiée sur la chaîne où les utilisateurs peuvent la voir et y accéder, comment peuvent-ils obtenir leur branche dans l'arbre afin de pouvoir sortir sans autorisation quand ils le souhaitent ?
Rollups appropriés
Dans un rollup correct, les informations sont placées directement dans la blockchain à chaque fois que de nouvelles transactions hors chaîne sont confirmées et que l'état des comptes du rollup change. Pas l'arbre entier, ce serait absurde, mais les informations nécessaires pour reconstruire l'arbre. Dans une implémentation naïve, le résumé de tous les comptes existants dans le rollup aurait des soldes et des comptes simplement ajoutés dans la transaction mettant à jour le rollup.
Dans les implémentations plus avancées, un différentiel de solde est utilisé. Il s'agit essentiellement d'un résumé des comptes sur lesquels de l'argent a été ajouté ou soustrait au cours d'une mise à jour. Cela permet à chaque mise à jour cumulative d'inclure uniquement les changements pour tenir compte des soldes qui se produisent. Les utilisateurs peuvent ensuite simplement scanner la chaîne et « faire le calcul » depuis le début de la synthèse pour arriver à l'état actuel des soldes des comptes, ce qui leur permet de reconstruire l'arbre de Merkle des soldes actuels.
Cela permet d'économiser beaucoup de frais généraux et d'espace de bloc (et donc d'argent) tout en permettant aux utilisateurs de garantir l'accès aux informations nécessaires pour qu'ils puissent sortir unilatéralement. L'inclusion de ces données dans un cumul formel qui utilise la blockchain pour les mettre à disposition des utilisateurs est imposée par les règles du cumul, c'est-à-dire qu'une transaction qui n'inclut pas le résumé du compte ou le différentiel de compte est considérée comme une transaction non valide.
Validiums
L’autre façon de gérer le problème de la disponibilité des données pour que les utilisateurs puissent les retirer est de placer les données ailleurs que dans la blockchain. Cela introduit des problèmes subtils, le rollup doit toujours garantir que les données ont été mises à disposition ailleurs. Traditionnellement, d’autres blockchains sont utilisées à cette fin, spécifiquement conçues pour fonctionner comme des couches de disponibilité des données pour des systèmes tels que les rollups.
Cela crée un dilemme : les garanties de sécurité doivent-elles être aussi solides ? Lorsque les données sont publiées directement sur la blockchain Bitcoin, les règles de consensus peuvent garantir qu'elles sont correctes avec une certitude absolue. Cependant, lorsqu'elles sont publiées sur un système externe, le mieux qu'elles puissent faire est de vérifier une preuve SPV que les données ont été publiées sur un autre système.
Cela implique de vérifier une attestation selon laquelle des données existent sur d'autres chaînes, ce qui est en fin de compte un problème d'oracle. La blockchain de Bitcoin ne peut rien vérifier complètement, sauf ce qui se passe sur sa propre blockchain, meilleur Il ne peut que vérifier un ZKP. Un ZKP ne peut cependant pas vérifier qu'un bloc contenant des données de cumul a effectivement été diffusé publiquement après avoir été produit. Il ne peut pas vérifier que les informations externes sont effectivement accessibles au public.
Cela ouvre la porte aux attaques de rétention de données, où un engagement envers les données publiées est créé et utilisé pour faire avancer le cumul, mais les données ne sont pas réellement mises à disposition. Cela rend les fonds des utilisateurs au-delà de leur capacité de retrait. La seule véritable solution à ce problème est de dépendre entièrement de la valeur et de la structure d'incitation de systèmes complètement extérieurs à Bitcoin.
Entre le marteau et l'enclume
Cela crée un dilemme en termes de rollups. En ce qui concerne la question de la disponibilité des données, il existe essentiellement un choix binaire entre publier les données sur la blockchain Bitcoin ou ailleurs. Ce choix a des implications massives à la fois pour la sécurité et la souveraineté des rollups, ainsi que pour leur évolutivité.
D'une part, l'utilisation de la blockchain Bitcoin pour la couche de disponibilité des données introduit un plafond strict sur la capacité des rollups à évoluer. L'espace de bloc est limité, ce qui impose une limite supérieure au nombre de rollups pouvant exister simultanément et au nombre de transactions que tous les rollups peuvent traiter dans leur ensemble. hors chaîne. Chaque mise à jour cumulative nécessite un espace de 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 de compresser les données que dans une certaine mesure, et à ce stade, il n'y a plus de potentiel de gains d'évolutivité.
D’un autre côté, l’utilisation d’une couche différente pour la disponibilité des données supprime le plafond strict des gains d’évolutivité, mais introduit également de nouveaux problèmes de sécurité et de souveraineté. Dans un rollup utilisant Bitcoin pour la disponibilité des données, il est littéralement impossible que l’état du rollup change sans que les données dont les utilisateurs ont besoin pour se retirer soient publiées de manière atomique sur la blockchain. Avec Validiums, cette garantie dépend entièrement de la capacité du système externe utilisé à résister aux jeux et à la rétention de données.
Tout producteur de blocs sur le système de disponibilité des données externes est désormais capable de retenir en otage les fonds des utilisateurs de Bitcoin Rollup en produisant un bloc et en ne le diffusant pas réellement pour rendre les données disponibles.
Alors, que se passera-t-il si nous parvenons un jour à une implémentation idéale de rollup sur Bitcoin qui permette réellement le retrait unilatéral de l'utilisateur ? Le marteau ou l'enclume ?