Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance
Les rollups sont récemment devenus le point focal de l’extension de BTC, devenant la première chose à vraiment voler la vedette au Lightning Network, sous un éclairage plus large. Les rollups visent à devenir une deuxième couche hors chaîne 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 de soldes de canal pour faciliter le flux complet des paiements du payeur au bénéficiaire.
Ces systèmes étaient initialement déployés sur des blockchains Turing complet telles qu’Ethereum et d’autres, mais récemment, l’accent a été mis sur leur portage vers des blockchains basées sur UTXO (par exemple BTC). Le présent article ne vise pas à discuter de la situation actuelle de mise en œuvre sur BTC, mais à aborder les fonctionnalités idéalisées de Rollup recherchées à long terme, qui dépendent de capacités actuellement non prises en charge par BTC, à savoir la capacité de vérifier les preuves de zéro connaissance (ZKP) directement sur BTC.
L’architecture de base de Roll est la suivante : un seul compte (UTXO dans BTC) contient tous les soldes des utilisateurs dans Rollup. Cette UTXO contient un engagement sous forme de racine de Merkle de l’arbre de Merkle, promettant tous les soldes actuels des comptes dans Rollup. Tous ces comptes sont autorisés par une paire de clés publique/privée, de sorte que pour effectuer des dépenses hors-chaîne, les utilisateurs doivent toujours signer certains contenus avec leur clé secrète. Cette partie de la structure permet aux utilisateurs de partir à tout moment sans permission, tant qu’ils peuvent prouver leur compte en faisant une transaction montrant qu’il fait partie de l’arbre de Merkle, ils peuvent sortir de Rollup unilatéralement sans l’autorisation de l’opérateur.
L’opérateur de Rollup doit inclure un ZKP dans la transaction afin de mettre à jour la racine de merkle du solde du compte hors chaîne lors de la finalisation de la transaction hors chaîne. Sans ce ZKP, 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 hors chaîne sont dûment autorisées par le titulaire du compte et si l’opérateur ne met pas à jour le solde de manière malveillante 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 off-chain, les utilisateurs peuvent y accéder et la consulter, mais comment peuvent-ils insérer leurs branches dans l’arbre afin de pouvoir sortir sans permission quand ils le souhaitent ?
Rollup approprié
Dans un Rollup approprié, chaque fois qu’une nouvelle transaction off-chain est confirmée et que l’état du compte Rollup change, les informations sont directement insérées dans la chaîne de blocs. Ce n’est pas tout 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 des mises en œuvre plus avancées, utilisez la différence de solde du compte. Fondamentalement, il s’agit d’un résumé des comptes qui ont augmenté ou diminué leurs fonds lors du processus de mise à jour. Cela permet à chaque mise à jour de 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 de solde actuel.
Cela permet d’économiser des dépenses importantes 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 du rollup exigent que ces données soient incluses dans le rollup formel fourni aux utilisateurs à l’aide de la chaîne Bloc, c’est-à-dire que les transactions sans résumé de compte ou différences de compte sont considérées comme invalides.
Période de validité
Une autre méthode pour traiter le problème de disponibilité des données d’extraction pour les utilisateurs est de les placer ailleurs que sur la chaîne de blocs. Cela soulève des problèmes subtils car le rollup doit toujours s’assurer que les données sont disponibles ailleurs. Traditionnellement, d’autres blocs sont utilisés à cette fin, spécifiquement conçus comme une 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 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 validation des données qui existent dans d’autres preuves off-chain, ce qui pose finalement un problème d’Oracle Machine. Le Bloc de BTC ne peut pas valider complètement autre chose que ce qui se passe dans son propre off-chain, il peut tout au plus valider ZKP. Cependant, ZKP ne peut pas vérifier si les données rollup du Bloc, une fois générées, sont réellement diffusées publiquement. Il ne peut pas vérifier si les informations externes sont réellement rendues publiques pour tout le monde.
Cela ouvre la porte aux attaques de rétention de données, c’est-à-dire créer des engagements sur la publication de 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 consiste à s’appuyer entièrement sur la valeur et la structure d’incitation des systèmes autres que le BTC.
Entre l’enclume et le marteau
Cela pose un dilemme pour 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 capacité de mise à l’échelle de rollup.
D’une part, l’utilisation de la chaîne BTCBloc comme couche de disponibilité des données imposerait une limite stricte à la scalabilité de rollup. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollups pouvant exister simultanément et au nombre total de transactions pouvant être traitées off-chain. Chaque mise à jour du rollup nécessite une quantité d’espace Bloc proportionnelle au 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’expansion.
D’autre part, l’utilisation de différentes couches pour assurer la disponibilité des données éliminerait la limite rigide des gains d’évolutivité, mais elle poserait également de nouveaux problèmes de sécurité et de souveraineté. Dans un 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 peut pas changer. Avec les Validiums, cette garantie dépend entièrement de la capacité des systèmes externes utilisés à lutter contre 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 à mettre en œuvre un Rollup idéal sur BTC, permettant réellement aux utilisateurs de retirer unilatéralement, à quoi cela ressemblerait-il ?
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Bitcoin Magazine: Quels sont les défis auxquels est confronté Rollup?
Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance
Les rollups sont récemment devenus le point focal de l’extension de BTC, devenant la première chose à vraiment voler la vedette au Lightning Network, sous un éclairage plus large. Les rollups visent à devenir une deuxième couche hors chaîne 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 de soldes de canal pour faciliter le flux complet des paiements du payeur au bénéficiaire.
Ces systèmes étaient initialement déployés sur des blockchains Turing complet telles qu’Ethereum et d’autres, mais récemment, l’accent a été mis sur leur portage vers des blockchains basées sur UTXO (par exemple BTC). Le présent article ne vise pas à discuter de la situation actuelle de mise en œuvre sur BTC, mais à aborder les fonctionnalités idéalisées de Rollup recherchées à long terme, qui dépendent de capacités actuellement non prises en charge par BTC, à savoir la capacité de vérifier les preuves de zéro connaissance (ZKP) directement sur BTC.
L’architecture de base de Roll est la suivante : un seul compte (UTXO dans BTC) contient tous les soldes des utilisateurs dans Rollup. Cette UTXO contient un engagement sous forme de racine de Merkle de l’arbre de Merkle, promettant tous les soldes actuels des comptes dans Rollup. Tous ces comptes sont autorisés par une paire de clés publique/privée, de sorte que pour effectuer des dépenses hors-chaîne, les utilisateurs doivent toujours signer certains contenus avec leur clé secrète. Cette partie de la structure permet aux utilisateurs de partir à tout moment sans permission, tant qu’ils peuvent prouver leur compte en faisant une transaction montrant qu’il fait partie de l’arbre de Merkle, ils peuvent sortir de Rollup unilatéralement sans l’autorisation de l’opérateur.
L’opérateur de Rollup doit inclure un ZKP dans la transaction afin de mettre à jour la racine de merkle du solde du compte hors chaîne lors de la finalisation de la transaction hors chaîne. Sans ce ZKP, 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 hors chaîne sont dûment autorisées par le titulaire du compte et si l’opérateur ne met pas à jour le solde de manière malveillante 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 off-chain, les utilisateurs peuvent y accéder et la consulter, mais comment peuvent-ils insérer leurs branches dans l’arbre afin de pouvoir sortir sans permission quand ils le souhaitent ?
Rollup approprié
Dans un Rollup approprié, chaque fois qu’une nouvelle transaction off-chain est confirmée et que l’état du compte Rollup change, les informations sont directement insérées dans la chaîne de blocs. Ce n’est pas tout 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 des mises en œuvre plus avancées, utilisez la différence de solde du compte. Fondamentalement, il s’agit d’un résumé des comptes qui ont augmenté ou diminué leurs fonds lors du processus de mise à jour. Cela permet à chaque mise à jour de 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 de solde actuel.
Cela permet d’économiser des dépenses importantes 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 du rollup exigent que ces données soient incluses dans le rollup formel fourni aux utilisateurs à l’aide de la chaîne Bloc, c’est-à-dire que les transactions sans résumé de compte ou différences de compte sont considérées comme invalides.
Période de validité
Une autre méthode pour traiter le problème de disponibilité des données d’extraction pour les utilisateurs est de les placer ailleurs que sur la chaîne de blocs. Cela soulève des problèmes subtils car le rollup doit toujours s’assurer que les données sont disponibles ailleurs. Traditionnellement, d’autres blocs sont utilisés à cette fin, spécifiquement conçus comme une 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 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 validation des données qui existent dans d’autres preuves off-chain, ce qui pose finalement un problème d’Oracle Machine. Le Bloc de BTC ne peut pas valider complètement autre chose que ce qui se passe dans son propre off-chain, il peut tout au plus valider ZKP. Cependant, ZKP ne peut pas vérifier si les données rollup du Bloc, une fois générées, sont réellement diffusées publiquement. Il ne peut pas vérifier si les informations externes sont réellement rendues publiques pour tout le monde.
Cela ouvre la porte aux attaques de rétention de données, c’est-à-dire créer des engagements sur la publication de 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 consiste à s’appuyer entièrement sur la valeur et la structure d’incitation des systèmes autres que le BTC.
Entre l’enclume et le marteau
Cela pose un dilemme pour 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 capacité de mise à l’échelle de rollup.
D’une part, l’utilisation de la chaîne BTCBloc comme couche de disponibilité des données imposerait une limite stricte à la scalabilité de rollup. L’espace Bloc est limité, ce qui fixe une limite au nombre de rollups pouvant exister simultanément et au nombre total de transactions pouvant être traitées off-chain. Chaque mise à jour du rollup nécessite une quantité d’espace Bloc proportionnelle au 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’expansion.
D’autre part, l’utilisation de différentes couches pour assurer la disponibilité des données éliminerait la limite rigide des gains d’évolutivité, mais elle poserait également de nouveaux problèmes de sécurité et de souveraineté. Dans un 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 peut pas changer. Avec les Validiums, cette garantie dépend entièrement de la capacité des systèmes externes utilisés à lutter contre 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 à mettre en œuvre un Rollup idéal sur BTC, permettant réellement aux utilisateurs de retirer unilatéralement, à quoi cela ressemblerait-il ?