Les sidechains fédérés sont la mise en œuvre originale de sidechain évolutif de Bitcoin

Ceci est un éditorial d'opinion de Shinobi, un éducateur autodidacte dans l'espace Bitcoin et hôte de podcast Bitcoin orienté technologie.

Sidechains fédérés are currently the only deployed type of Bitcoin sidechain (the most recent paper ici). L’idée d’utiliser un système fédéré de parité et de consensus était en fait une annexe du livre blanc original sur les sidechains. Il n'y avait aucune conception concrète pour un quelconque type de rattachement bidirectionnel impliquant des mineurs, donc un rattachement fédéré a été décrit comme un moyen de déployer une sidechain maintenant et de passer à un rattachement vérifié dans les deux sens en utilisant des preuves de vérification de paiement simple (SPV) similaires à quoi chaînes souples do, when something was concretely designed that was safe and deployable. It was also pointed out that in terms of incentives, for very small systems it might be dangerous to use a miner-based peg as they could steal from a very small group of people without much consensus on doing anything about it from the wider Bitcoin system. Federations could be useful for smaller systems where the group of users isn’t big enough to be a disincentive for miners to steal coins.

The general idea is to effectively have a blockchain where a selected group of trusted parties custody bitcoin pegged into the system using multisig, and produce the blocks on the sidechain, signing them with cryptographic keys instead of using proof-of-work. The entire security model is based on having a decently large set of distinct participants in the group, or federation, that are very geographically distributed and are publicly known.

Federations use a threshold of members for both the custody of bitcoin on the mainchain and blocksigning, i.e., a 5-of-7 multisig. This is done instead of requiring all seven of the members to sign in order to balance the two major risks of such a system: theft versus loss. The federation together can steal all of the funds locked in a federated sidechain if they choose to cooperate together to do so; this is why the entire security model is based around many different actors in many different legal jurisdictions. You want it to be exceedingly difficult and unlikely that many different governments all cooperate in order to force a federation to do something malicious, so you want a large number of people needed to sign things. On the other hand, if you require all seven members to sign everything, then all it takes is a single member to lose access to their keys to result in permanent loss of all funds in the sidechain. Hence requiring a majority of members to sign, but not all of them. This leaves some margin of error for key loss while also still requiring a high number of members to be coerced or to conspire to result in a theft of funds.

Cela rend le modèle de sécurité du système bidirectionnel en termes de seuils de sécurité. Comme indiqué précédemment, pour que les fonds soient activement volés, cinq des sept participants à cette situation hypothétique doivent s'entendre ou être contraints de s'entendre afin de voler les fonds de la sidechain. Cependant, seuls trois des sept participants doivent perdre, détruire ou être contraints de désactiver leurs clés afin de laisser les fonds de la sidechain gelés et incapables d'être déplacés – éventuellement de façon permanente. Les seuils constituent un exercice d’équilibre entre ces deux risques.

Les deux doivent être simultanément suffisamment élevés pour que les deux pires cas soient improbables.

Outre ces propriétés principales, il existe un grand degré de liberté dans la manière dont vous pouvez implémenter une sidechain fédérée, à la fois en termes de conception de la sidechain elle-même et de gestion des clés pour la signature de bloc et les clés de garde.

Liquide

Liquid was the first federated sidechain deployed on Bitcoin, designed for private transactions between exchanges for trading and issuance of other assets like stablecoins or equity tokens. Its codebase is built almost entirely on that of Bitcoin itself. One of the core features of the Liquid network was the implementation of Transactions confidentielles, une fonctionnalité utilisant des preuves de plage cryptographique pour masquer les montants envoyés dans les transactions tout en fournissant une garantie, sous certaines hypothèses, qu'aucun argent qui n'existe n'est dépensé. Liquide également mis en œuvre Actifs confidentiels, une extension des transactions confidentielles. Les actifs confidentiels masquent le jeton dépensé en plus du montant.

Ces deux fonctionnalités combinées offrent une solution solide à l’une des grandes lacunes possibles d’une sidechain fédérée : la censure. Une majorité seuil (dans notre hypothétique fédération de 5 sur 7 ci-dessus) pourrait tous accepter de censurer des transactions spécifiques ou des UTXO s'ils avaient tous des raisons de le faire, comme une activité illégale suspectée ou confirmée. Dans un tel cas, ils auraient même une incitation rationnelle à le faire, pour ne pas donner aux gouvernements une raison de s’en prendre à l’ensemble du système. Les transactions/actifs confidentiels peuvent fournir un niveau de confidentialité suffisamment élevé pour que même si une fédération avait des raisons de censurer certains types de transactions, elle aurait beaucoup de mal à les sélectionner pour le faire.

Une transaction de rattachement sur Liquid est un processus relativement simple en deux étapes. Un utilisateur souhaitant se connecter prend l'adresse multisig de la fédération puis « peaufine » chaque clé publique impliquée en utilisant payer pour contracter avec une adresse Liquid qu'ils contrôlent, pour créer de nouvelles clés publiques. Les membres de la fédération peuvent dériver les clés privées correspondantes une fois qu'ils ont appris l'adresse Liquid utilisée. Jusqu'à ce que cette information soit révélée, personne, pas même la fédération, ne sait qu'une transaction vers cette adresse modifiée est un ancrage liquide. Ensuite, l'utilisateur diffuse la transaction sur la chaîne principale et attend 100 confirmations. Une fois les confirmations accumulées, l'utilisateur peut soumettre une transaction sur le réseau Liquid pour s'envoyer ses pièces. Cette transaction utilise une entrée spéciale qui contient l'adresse Liquid avec laquelle ils ont modifié les clés de la fédération, une signature prouvant qu'ils la contrôlent et une preuve Merkle montrant que la transaction de rattachement de la chaîne principale a au moins 100 confirmations.

The peg-out process is much simpler. A user constructs a transaction that burns bitcoin on Liquid using OP_RETURN, contains an address to send to on the mainchain, and a special zero-knowledge proof from one of the federation members (which one is hidden). When federation members see such a transaction with a valid member proof, they will sign a withdrawal on the mainchain. The proof is implemented to prevent fraudulent or invalid withdrawals and allows whichever federation member is providing the proof to enforce whitelisting or restrictions on peg-outs. Anyone can freely peg bitcoin into the Liquid network, but a relationship with a federation member is required to peg-out.

En termes de gestion des clés et de sécurité de gestion, Blockstream a développé des modules de sécurité matérielle (HSM) pour gérer les clés et effectuer des opérations de signature. Ces appareils sécurisent les clés utilisées pour la signature de bloc et les entrées/sorties, les protégeant ainsi contre la falsification ou l'extraction de clé. Afin de fournir des moyens de récupération en cas de perte de clés par des appareils défaillants, mais également de se protéger contre l'extraction de clés à des fins malveillantes, les sauvegardes de chaque clé de membre sont conservées cryptées de manière à exiger que ce membre et Blockstream coopèrent pour déchiffrer la clé pour la charger dans un nouveau HSM. Aucune des parties ne peut déchiffrer la sauvegarde par elle-même. Les clés de retrait d’urgence constituent une dernière ligne de défense contre la perte de clés. Chaque adresse vers laquelle la fédération envoie des pièces de monnaie a deux voies de dépenses : le seuil requis de la fédération et, après un délai d'environ un mois (bien que la durée puisse être modifiée), le seuil requis des clés d'urgence. Il s'agit d'un deuxième jeu de clés qui peut être conservé par la fédération, une autre partie ou une combinaison de ceux-ci pour garantir que les pièces peuvent être récupérées en cas de perte d'un trop grand nombre de clés de la fédération. La fédération déplace régulièrement les pièces de la chaîne principale sous sa garde avant l'expiration du délai, donc tant que la fédération n'a pas échoué, cette voie d'urgence ne sera jamais utilisable. Actuellement, Blockstream conserve les clés de récupération qui sont géographiquement réparties.

Enfin, il existe une fonctionnalité appelée « Fédérations dynamiques ». Cela permet à une grande majorité de la fédération de mettre à jour la composition, en ajoutant ou en supprimant des membres. Cela se fait via une mise à jour logicielle du logiciel de signature après avoir décidé quels nouveaux membres ajouter ou ceux existants à supprimer, puis une période de signalisation d'un mois. Si, pendant un mois, les quatre cinquièmes des blocs signalés pour la fédération changent, le réseau « bifurque » pour reconnaître la nouvelle fédération comme signataires du bloc. Le réseau commence alors à utiliser de nouvelles adresses de rattachement avec la nouvelle fédération, mais reconnaît toujours les anciennes pendant un mois supplémentaire pour garantir qu'aucun rattachement ne soit invalidé lors du changement de fédération. Il n’est pas non plus permis de supprimer un nombre de membres de la fédération tel qu’il n’en reste plus assez pour signer les retraits d’anciennes adresses. Tous ces aspects des mises à niveau de la fédération font partie des règles de consensus et sont appliqués/validés par les HSM.

Porte-greffe (RSK)

Rootstock is a federated sidechain with many design differences versus Liquid. Firstly, it is essentially a copy-paste clone of Ethereum in terms of functionality. It fully supports Solidity, the scripting language used by Ethereum, so that any contract deployed on Ethereum is trivially portable to Rootstock. The rationale for doing this is obviously that Ethereum has a lot of demand and can deliver functionality that Bitcoin is not capable of. Obviously, there are many downsides and risks to Ethereum’s architecture, but you can’t deny there is demand for it.

Another major difference in terms of architecture is what the federation does — they collectively manage a multisig that custodies the funds on the mainchain, but the federation does not in normal circumstances participate in minting blocks. This is done by Bitcoin miners through merged mining, allowing them to mine Bitcoin and Rootstock at the same time. While this provides no meaningful security difference for Bitcoin pegged into the Rootstock chain, it does provide some for other assets issued on the sidechain. The federation can always steal the Bitcoin on the mainchain if enough collude, but because miners actually mine the sidechain it can continue and allow the other assets to keep being transacted. If those other assets have enough value, even without being backed by real bitcoin, the Rootstock BTC token should still have enough market demand to pay fees to utilize other assets to incentivize miners to keep mining.

The involvement of miners isn’t absolute, though. As long as a majority of Bitcoin miners are also mining Rootstock, they are in total control of organizing transactions and mining them into blocks, but if that percent of miners drops into the range of half (or slightly lower), there are consensus rules allowing the federation to sign checkpoints preventing reorgs back before the checkpoint. If the hash rate drops more drastically than that they are even capable of taking over as blocksigners, like Liquid’s federation members. It’s a very dynamic system that can function both without miners and without the federation in order to keep the blockchain progressing forward.

The peg-in process is very simple: send bitcoin to the RSK peg-in address and then wait for enough confirmations. After enough confirmations have built up, a Solidity smart contract on the sidechain will recognize the transaction and credit it to an account on the sidechain controlled by the same key that the UTXO you pegged-in was locked to. Pegging-out is also controlled by a smart contract, which will communicate with the federation’s HSMs, which will sign a mainchain withdrawal transaction when told to by the contract.

Lorsque Roostock a lancé pour la première fois, il suffisait que la majorité des HSM de la fédération signent la transaction après y avoir été invitées par le contrat intelligent sur la sidechain. En 2020, ils ont mis en œuvre un nouveau mécanisme de fixation appelé POWpeg. Cette mise à niveau a permis aux HSM de valider réellement les preuves SPV des mineurs. Les HSM refusent désormais de signer des transactions de rattachement à moins qu'une majorité de l'ensemble actuel de mineurs RSK ne s'appuie sur la transaction dès le lancement du rattachement. Le modèle de sécurité se résume en fin de compte à ce que les HSM restent sécurisés, mais à moins qu'une majorité d'entre eux ne soient falsifiés et que les clés soient extraites, ils ne signeront pas sans une preuve de travail suffisante attestant des ancrages.

Liquider

Les gens travaillent sur la conception de sidechains depuis maintenant huit ans, et pendant que nous sont partis à quatre different designs (and there are a few more out there: these are just the ones that have gotten traction with technical Bitcoiners), there is nothing currently deployed except federated chains. Federated systems might not be the trustless sidechain that many people want, but they are still very useful systems — especially in any context where the only way to meet a market demand is to trust a single custodian to arbitrate something. Federations immediately become a default improvement by spreading the counterparty risk around to multiple players.

Eh bien, cela représente en un mot les sidechains fédérés. Le dernier article à venir aborde tous les inconvénients et les points négatifs des principales propositions actuelles, au moins quelques réflexions de haut niveau sur ce que les gens attendent vraiment d'une sidechain « parfaite » et comment y parvenir potentiellement.

Ceci est un article invité de Shinobi. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou de Bitcoin Magazine.