Rollups : le lieu difficile de la mise à l'échelle du Bitcoin

Les rollups sont devenus au centre du récit de la mise à l’échelle du Bitcoin ces derniers temps, devenant ainsi la première chose à véritablement « voler la vedette » au Lightning Network.

Rollups have become a hot topic in the Bitcoin scaling discussion lately, being the first thing to truly “steal the limelight” from the Lightning Network in terms of wider mindshare. Rollups aim to be an off-chain layer two that is not bound or constrained by the liquidity limitations that are central to the Lightning Network, i.e. end users required someone allocate (or “lend”) them funds ahead of time in order to be able to receive money, or intermediary routing nodes requiring channel balances that can facilitate the movement of the payment amount all the way from sender to receiver.

Les rollups sont devenus un sujet brûlant dans les discussions sur la mise à l'échelle du Bitcoin ces derniers temps, étant la première chose à véritablement « voler la vedette » au Lightning Network en termes de partage 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 « prête ») des fonds à l'avance afin de pouvoir pour 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.

These systems were originally developed to function on Ethereum and other Turing complete systems, but as of late the focus has shifted to porting them to UTXO based blockchains such as Bitcoin. This article is not going to discuss the current state of things being implemented on Bitcoin currently, but going to discuss the function of an idealized rollup that people are aiming for in the long term depending on features Bitcoin currently does not support, namely the ability to verify Zero Knowledge Proofs (ZKPs) on Bitcoin directly.

Ces systèmes ont été initialement développés pour fonctionner sur Ethereum et d’autres systèmes complets de Turing, mais ces derniers temps, l’accent s’est déplacé vers leur portage sur des blockchains basées sur UTXO telles que Bitcoin. Cet article ne discutera pas de l'état actuel des choses implémentées sur Bitcoin actuellement, mais discutera de la fonction d'un rollup idéalisé que les gens visent à long terme en fonction des fonctionnalités que Bitcoin ne prend actuellement pas en charge, à savoir la capacité de vérifiez directement les preuves de connaissances nulles (ZKP) sur Bitcoin.

The basic architecture of a roll is as follows: a single account (or in Bitcoin’s case UTXO), holds the balances of all users in the rollup. This UTXO contains a commitment in the form of a merkle root of a merkle tree that commits to all the current balances of existing accounts in the rollup. All of these accounts are authorized using public/private key pairs, so in order to propose an off-chain spend a user must still sign something with a key. This part of the structure allows users to leave without permission whenever they want, simply by crafting a transaction proving their account is part of the merkle tree, they can unilaterally exit the rollup without the operator's permission.

L'architecture de base d'un rollup est la suivante : un seul compte (ou dans le cas de Bitcoin, UTXO) contient 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 cumul. Tous ces comptes sont autorisés à l'aide de paires de clés publique/privée, 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 sans autorisation quand ils le souhaitent, simplement en créant une transaction prouvant que leur compte fait partie de l'arborescence Merkle, ils peuvent quitter unilatéralement le rollup sans l'autorisation de l'opérateur.

The operator of the rollup must include a ZKP in transactions that update the merkle root of account balances on-chain in the process of finalizing off-chain transactions, without this ZKP the transaction will be invalid and therefore not includable in the blockchain. This proof allows people to verify that all changes to off-chain accounts were properly authorized by the account holder(s), and that the operator has not conducted a malicious update of balances to steal money from users or reallocate it to other users dishonestly.

L'opérateur du rollup doit inclure un ZKP dans les transactions qui mettent à jour la racine merkle des soldes des comptes en chaîne dans le 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 gens 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.

The problem is, if only the root of the merkle tree is posted on-chain where users can view and access it, how do they get their branch in the tree in order to be capable of exiting without permission when they want to?

Le problème est que si seule la racine de l'arborescence Merkle est publiée sur la chaîne où les utilisateurs peuvent la visualiser et y accéder, comment peuvent-ils obtenir leur branche dans l'arborescence afin de pouvoir quitter sans autorisation quand ils le souhaitent ?

In a proper rollup, the information is put directly into the blockchain everytime that new off-chain transactions are confirmed and the state of the rollup accounts change. Not the entire tree, that would be absurd, but the information necessary to reconstruct the tree. In a naive implementation, the summary of all existing accounts in the rollup would have balances and accounts simply added in the transaction updating the rollup.

Dans un cumul approprié, 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 cumulés change. Pas l’arbre entier, ce serait absurde, mais les informations nécessaires à la reconstruction de l’arbre. Dans une implémentation naïve, le résumé de tous les comptes existants dans le cumul aurait des soldes et des comptes simplement ajoutés dans la transaction mettant à jour le cumul.

In more advanced implementations, a balance diff is used. This is essentially a summary of what accounts have had money added to or subtracted from them during the course of an update. This allows each rollup update to only include the changes to account balances that occur. Users can then simply scan the chain and “do the math” from the beginning of the rollup to arrive at the current state of account balances, which allows them to reconstruct the merkle tree of current balances.

Dans les implémentations plus avancées, un différentiel de balance 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 modifications apportées aux soldes des comptes qui se produisent. Les utilisateurs peuvent alors simplement scanner la chaîne et « faire le calcul » depuis le début du cumul pour arriver à l’état actuel des soldes des comptes, ce qui leur permet de reconstruire l’arbre Merkle des soldes actuels.

This saves a lot of overhead and blockspace (and therefore money) while still allowing users to guarantee access to the information needed for them to exit unilaterally. Including this data in a formal rollup that uses the blockchain to make it available to users is mandated by the rules of the rollup, i.e. a transaction that does not include the account summary or account diff is considered an invalid transaction.

Cela permet d'économiser beaucoup de temps et d'espace de bloc (et donc d'argent) tout en permettant aux utilisateurs de garantir l'accès aux informations nécessaires pour quitter unilatéralement. L'inclusion de ces données dans un cumul formel qui utilise la blockchain pour les mettre à la 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 invalide.

The other way to handle the problem of data availability for users to withdraw is to put the data somewhere else besides the blockchain. This introduces subtle issues, the rollup still needs to enforce that the data was made available somewhere else. Traditionally other blockchains are used for this purpose, specifically designed to function as data availability layers for systems like rollups.

L’autre façon de résoudre le problème de la disponibilité des données que les utilisateurs peuvent retirer est de placer les données ailleurs que dans la blockchain. Cela introduit des problèmes subtils, le cumul 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 couches de disponibilité des données pour des systèmes tels que les rollups.

This creates the dilemma of security guarantees being as strong. When the data is posted directly to the Bitcoin blockchain, consensus rules can guarantee it is correct with absolute certainty. However when it is posted to an external system, the best it can do is verify an SPV proof that the data was posted to another system.

Cela crée le dilemme de savoir si les garanties de sécurité sont aussi solides. Lorsque les données sont publiées directement sur la blockchain Bitcoin, les règles de consensus peuvent garantir leur exactitude avec une certitude absolue. Cependant, lorsqu'elles sont publiées sur un système externe, le mieux qu'il puisse faire est de vérifier une preuve SPV que les données ont été publiées sur un autre système.

This entails verifying an attestation that data exists on other chains, which is ultimately an oracle problem. Bitcoin’s blockchain cannot verify anything completely except what occurs on its own blockchain, the best it can do is verify a ZKP. A ZKP however cannot verify that a block containing rollup data was actually publicly broadcast after being produced. It cannot verify that external information is actually publicly available to everyone.

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, le mieux qu'elle puisse faire est de 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 sa production. Il ne peut pas vérifier que les informations externes sont effectivement accessibles à tous.

This opens the door to data withholding attacks, where a commitment

Cela ouvre la porte à des attaques de rétention de données, où un engagement