Une introduction à Spiderchain
Un examen du dernier protocole de couche 2 proposé pour rattacher Bitcoin à une sidechain
Avec toutes les récentes discussions et drames autour des chaînes de transmission, il semble que la plupart des gens ont négligé l’annonce récente d’une autre proposition visant à créer des chaînes latérales à ancrage bidirectionnel.
Botanix Labs s’est récemment dévoilé et a publié ce livre blanc. Étant donné que leur logiciel n’est pas encore disponible pour être exécuté et inspecté, voici mes impressions après avoir lu le système tel que décrit dans le document.
Bien qu’il existe une variété de propositions en cours de discussion pour améliorer les capacités de couche 2 de Bitcoin, telles que les chaînes d’entraînement, les cumuls de connaissances nulles et les cumuls de validité, une distinction avec les Spiderchains est qu’elles peuvent être implémentées sur Bitcoin aujourd’hui sans aucune modification de protocole dans la couche de base.
Motivation :
Ethereum a connu une croissance massive des applications financières décentralisées qui sont pour la plupart indisponibles sur Bitcoin. La valeur totale des deuxièmes couches de Bitcoin est inférieure à 0,1 % de la capitalisation boursière du Bitcoin, tandis que dans le même temps, la valeur du Bitcoin enveloppé disponible sur Ethereum est supérieure à 2 %. Bitcoin n’a pas connu la croissance massive de la TVL (Total value verrouillé) sur ses secondes couches ou dans ses applications.
Cet article propose une deuxième couche construite sur Bitcoin avec une équivalence complète avec la machine virtuelle Ethereum (EVM). Avec Bitcoin comme couche inférieure la plus décentralisée et la plus sécurisée, la deuxième couche ouvrira les portes de la composabilité, de l’écosystème et des capacités des contrats intelligents Ethereum. Nous introduisons la primitive Spiderchain, une conception de deuxième couche au-dessus de Bitcoin optimisée pour la décentralisation.
Très bien, nous savons donc d’emblée que cette proposition visera à créer une Sidechain similaire à Rootstock, mais avec un mécanisme d’ancrage différent. Un rappel du livre blanc Pegged Sidechains publié en 2014 :
Le problème est que les altchains, comme Bitcoin, ont généralement leur propre crypto-monnaie native, ou altcoin, avec un prix flottant. Pour accéder à l’altchain, les utilisateurs doivent utiliser un marché pour obtenir cette devise, les exposant au risque élevé et à la volatilité associés aux nouvelles devises. En outre, la nécessité de résoudre de manière indépendante les problèmes de distribution initiale et de valorisation, tout en luttant contre les effets de réseau négatifs et un marché encombré, décourage l’innovation technique tout en encourageant les jeux de marché. Cela est dangereux non seulement pour ceux qui participent directement à ces systèmes, mais aussi pour l’industrie des cryptomonnaies dans son ensemble.
Certains détracteurs ont récemment déclaré que les Sidechains sont inutiles et qu’il n’y a aucune demande pour elles puisque les deux Sidechains les plus anciens et les plus remarquables, Liquid et Rootstock, n’ont pas été largement adoptés. Pourtant, il est empiriquement évident qu’il existe une demande pour « utiliser le bitcoin » comme unité de compte pour des fonctions financières plus complexes. La demande est si élevée que plus de 150 000 BTC ont été confiés à un dépositaire tiers de confiance (BitGo) pour émettre des jetons BTC indexés à utiliser sur Ethereum !
Quelle que soit votre opinion sur les Sidechains, je soutiens que la poursuite de la recherche et du développement de mécanismes robustes d’ancrage bidirectionnel sans autorisation est une poursuite qui en vaut la peine.
“Les tiers de confiance sont des failles de sécurité.”
-Nick Szabo
Introduction:
Botanix note que la vision de la Fondation Ethereum pour résoudre le problème d’évolutivité consiste en plusieurs couches de chaînes compatibles EVM (Ethereum Virtual Machine), la chaîne principale servant de couche de règlement en bas. Mais Ethereum est toujours confronté à des questions de centralisation avec plusieurs hard forks sur la feuille de route, le rôle de la Fondation Ethereum et leur passage à la preuve de participation. Botanix affirme que Bitcoin constitue une base plus appropriée sur laquelle construire une deuxième couche, car il est extrêmement difficile à modifier et est sécurisé par une preuve de travail.
Pourquoi EVM ?
Les contrats intelligents de solidité bénéficient de l’effet Lindy et bénéficient de niveaux de confiance et de familiarité plus élevés. Du point de vue du langage de programmation, Solidity est solidement implanté dans le monde de la cryptographie et Botanix a donc choisi de tirer parti des outils qui existent déjà dans l’écosystème EVM.
La chaîne d’araignées (Spiderchain):
Le peg Spiderchain est une série de portefeuilles multisig successifs gérés par des Orchestrateurs. Une explication extrêmement simpliste du fonctionnement du système :
- Les gens déposent des garanties BTC dans un portefeuille multisig pour exécuter un Orchestrator.
- Les orchestrateurs exécutent 2 nœuds côte à côte : un nœud Bitcoin et un nœud Spiderchain.
- Les orchestrateurs gèrent les demandes d’entrée et de sortie en contrôlant les portefeuilles multisig et s’assurent que les autres orchestrateurs agissent honnêtement et restent actifs.
- De nouvelles demandes de rattachement entraînent la création d’un nouveau portefeuille multisig géré par un sous-ensemble aléatoire d’orchestrateurs actuellement actifs.
- Un orchestrateur spécifique est choisi pour diriger chaque époque de Spiderchain (lorsqu’un bloc Bitcoin se produit et que des entrées et des sorties peuvent se produire) en fonction du hachage de bloc Bitcoin des 6 blocs précédents. Chaque bloc Spiderchain successif est dirigé par un orchestrateur différent désigné via des calculs séquentiels effectués sur le même hachage de bloc.
Il s’agit de l’image utilisée pour visualiser la relation entre la Spiderchain, la blockchain Bitcoin et les pools de Bitcoin indexés. Je pense qu’une chose qui manque est qu’il n’y a pas de relation 1:1 entre les blocs Spiderchain et les blocs Bitcoin. Au contraire, comme Ethereum, la spiderchain a des blocages toutes les 12 secondes. Le premier nouveau bloc Spiderchain créé après un nouveau bloc Bitcoin devient un point d’ancrage et délimite une nouvelle « époque » sur la Spiderchain, créant ainsi une finalité pour toutes les transactions dans les blocs antérieurs à ce point.
Modèle de sécurité :
Botanix a opté pour un modèle consensuel Proof of Stake. Étant donné que le Bitcoin synthétique sur la Spiderchain sera rattaché à 1:1 avec BTC, la tendance à la centralisation des participants observée dans le PoS sera contrebalancée par le PoW de Bitcoin. Cependant, cela signifie également qu’il n’y aura pas de récompense de frais de base pour les parieurs — ils ne peuvent collecter que des frais de transaction et probablement des mises réduites auprès des orchestrateurs qui se comportent mal.
Botanix bénéficie des fonctionnalités de sécurité du système PoW de Bitcoin et les utilise pour atténuer les vulnérabilités potentielles (centralisation, sélection aléatoire du validateur, finalité) des algorithmes de consensus PoS.
Tant que le nombre d’acteurs collaborateurs adverses est dépassé par 2/3 ou plus d’orchestrateurs honnêtes, la théorie des jeux est solide.
Pour le processus d’ancrage, Spiderchain propose un nouvel ensemble de compromis.
- Multisig fédéré (fonds gérés par consortium statique)
- Drivechain (fonds gérés par des signataires dynamiques : mineurs)
- Spiderchain (fonds gérés par des jalonneurs dynamiques)
Les sections sur la gestion d’UTXO sont intéressantes étant donné que, contrairement à d’autres propositions de sidechain indexées, Spiderchain ne repose pas sur un seul pool de fonds indexés. En tant que tel, l’utilisation du dernier entré, premier sorti (LIFO) pour les ancrages garantira que les pièces les plus anciennes seront sécurisées par les orchestrateurs les plus anciens, ne donnant ainsi aucune chance à un jeune adversaire malveillant de prendre le contrôle des pièces les plus anciennes.
Un orchestrateur peut déposer des bitcoins et après 6 blocs, commencer à jalonner et à orchestrer. Cependant, ils ne seront ajoutés à aucun des portefeuilles multisig à moins qu’un orchestrateur actuel ne publie son intention de quitter. Lorsqu’un Orchestrator souhaite quitter, il doit attendre que chaque portefeuille multisig sur lequel il est signataire voit sa clé remplacée par celle d’un autre Orchestrator récemment rejoint.
Il y a quatre variables qui affectent le niveau de sécurité d’une spiderchain :
- Taille du multisig (nombre de signataires)
- La mise (collatéral) apportée par les Orchestrateurs
- Le nombre total d’Orchestrateurs
- Le bitcoin total bloqué dans la Spiderchain
Le document note que les deux premiers peuvent être contrôlés au niveau du protocole. Ce que j’aimerais voir davantage, c’est comment ils pourraient être ajustés dynamiquement à mesure que les deux dernières variables changent au fil du temps. Bien que je m’attende à ce que ce soit un processus d’apprentissage au cours des années à venir, à mesure que la première chaîne d’araignées sera démarrée.
Hypothèses :
Si l’un des attributs suivants ne parvient pas à tenir, la sécurité de la Spiderchain et de son Bitcoin rattaché est en péril.
Personne ne dispose de plus de 50 % des fonds rattachés au réseau (mis en jeu).
Aucun multisig de Spiderchain ne contient un quorum contradictoire ou insensible de 33 %. Si 1/3 des orchestrateurs d’un multisig donné ne coopèrent pas, il devient impossible de répartir ces fonds. Par conséquent, les orchestrateurs inactifs ne recevront plus de récompenses de bloc et, après une semaine d’inactivité, ils seront progressivement supprimés des multisigs.
Il existe également une hypothèse tacite selon laquelle Bitcoin ne souffrira jamais d’une réorganisation de la chaîne de plus de 5 blocs. En effet, les orchestrateurs sont déterminés 6 blocs à l’avance en effectuant un module sur le hachage du bloc Bitcoin. Que se passe-t-il si une réorganisation plus longue se produit ? Il semble qu’il soit possible que le rattachement soit brisé, même s’il est peu probable que cela soit catastrophique en raison de la façon dont les fonds sont dispersés dans de nombreux portefeuilles multisig.
Chiffres Boucle d’Or :
Il existe de nombreuses valeurs optimales encore à déterminer pour les variables techniques et économiques en jeu. Je pense que c’est la principale raison pour laquelle nous voyons un processus d’amorçage par étapes proposé pour le lancement et l’évolution de l’architecture de sécurité de Spiderchain.
- Taille et coordination multisig. S’il y a trop de signataires sur un multisig donné, il peut devenir trop fastidieux de coordonner les signatures en temps opportun. S’il y a trop peu de signataires, il est trop facile pour un attaquant d’ajouter suffisamment de signataires aux portefeuilles d’attaque Sybil et de drainer des fonds.
- Taille de l’enjeu et centralisation. Si la taille de la participation choisie est trop importante, les entités sont moins enclines à gérer un nœud, réduisant ainsi la décentralisation. Si la taille de l’enjeu est trop faible, le coût pour une entité malveillante de produire une attaque Sybil pourrait être trop faible.
- Vivacité de l’orchestrateur. Si 1/3 des signataires d’un multisig donné ne répondent pas ou ne sont pas conformes, les fonds ne peuvent pas être affectés. Si la période d’inactivité pour pénaliser les orchestrateurs qui se comportent mal est trop courte, cela pourrait ouvrir la voie à des attaques DoS. Si la période est trop longue, cela augmente le risque que les fonds d’un multisig soient temporairement gelés, voire perdus définitivement.
Il me semble que certains de ces nombres devraient probablement être dynamiques et devraient évoluer en fonction de la taille de la chaîne d’araignées en termes de nombre total d’orchestrateurs et de BTC total rattachés au système.
Efficacité du capital :
Un capital spiderchain est-il efficace au regard de ses exigences de sécurité ? Donné:
- x = le BTC sécurisé dans un certain multisig
- n = le nombre de signataires sur un multisig
- s = la taille de la mise en BTC par orchestrateur
Un orchestrateur rationnel choisira de signaler un comportement erratique et recevra la récompense tranchante tant que :
Qu’est-ce que cela signifie d’un point de vue pratique ? Supposons que nous ne souhaitions pas plus de 50 signataires sur un multisig en raison de la complexité croissante de la coordination.
Si nous avions un multisig de 10 signataires mettant chacun 10 BTC, alors le montant maximum « sûr » à gérer pour ce multisig serait d’environ 420 BTC. Pas génial puisque l’efficacité du capital n’est que de ~ 3X.
Si nous avions un multisig de 30 signataires mettant chacun en jeu 30 BTC, le montant maximum « sûr » à gérer pour ce multisig serait d’environ 12500 BTC. Pas mal, étant donné que seulement 900 BTC sont en jeu. Cela représente une bien meilleure efficacité du capital ~ 13X.
Bien que 50 signataires pariant 50 BTC augmenteraient le plafond de sécurité à 55 555 BTC. Une efficacité du capital ~22X.
Notez que pour que ces équations soient vraies, un nombre relativement élevé de nœuds Orchestrator doivent être opérationnels, de sorte que la probabilité qu’un adversaire tentant une attaque Sybil ait plusieurs Orchestrators dans le même multisig est assez faible.
Amorçage de la chaîne d’araignée :
Botanix semble bien conscient qu’il y a beaucoup de variables en jeu ici et cela impliquera probablement des expérimentations et des leçons apprises en production pour naviguer dans le processus d’amorçage. Pour éviter les attaques majoritaires malveillantes silencieuses, le bootstrap se déroulera en 5 phases, la phase initiale étant composée d’orchestrateurs contrôlés à 100 % par Botanix.
Il suffit de dire que cela ressemble à un long chemin entre une chaîne latérale 100% centralisée et publique sans autorisation à 2 voies. Je suis certainement sceptique quant à tout projet présentant une feuille de route allant du centralisé au décentralisé, car la tendance pour tout est de devenir plus centralisé au fil du temps. Pourtant, compte tenu de toutes les inconnues impliquées dans cette expérience, il semble que se lancer tête baissée dans une architecture purement sans autorisation équivaut à une catastrophe.
Des incitations :
Pourquoi voudrait-on diriger honnêtement un Orchestrator ? Le réseau lui-même ne génère pas de nouveaux jetons, les parieurs ne peuvent donc gagner des revenus que grâce aux frais de transaction.
En tant que tel, le mécanisme de tarification du gaz sur la Spiderchain est une considération économique importante. En supposant que c’est la même chose qu’Ethereum, et 1 satoshi == 10 gwei et que les frais de transaction de base sont de 100 gwei (selon la documentation Ethereum), alors les frais de base plancher sur la spiderchain sont de 10 satoshis « synthétiques » pour un simple transfert EOA vers EOA. À titre de comparaison, le transfert Bitcoin simple en chaîne (P2TR) le moins cher coûterait environ 150 satoshis au taux plancher de 1 satoshi par octet virtuel. Le fait est qu’il semble que le plancher des frais de transaction soit d’un ordre de grandeur inférieur sur la chaîne araignée que sur la chaîne de base. Cela semble être une incitation décente pour les opérateurs à vouloir l’utiliser, mais le revers de la médaille est que cela peut s’avérer un chemin plus difficile pour amorcer un volume de frais durable. Bien sûr, tout cela n’est que spéculation et les frais de base pourraient très bien être fixés plus haut sur une spiderchain.
Questions ouvertes :
Le document semble supposer que chaque bloc Bitcoin comprendra des entrées et des sorties de Spiderchain. Que se passe-t-il (le cas échéant) si un orchestrateur ne parvient pas à publier les mises à jour UTXO convenues pour le prochain bloc Bitcoin ?
Que se passe-t-il si quelqu’un demande une adresse de rattachement qui, selon le document, est générée par l’orchestrateur actuel, mais qu’il envoie le bitcoin à une date ultérieure OU qu’elle n’est pas confirmée rapidement en raison du paiement de frais non compétitifs ? Ces ancrages « périmés » peuvent-ils être balayés plus tard ou y a-t-il un risque de perte de fonds ?
Les peg-ins constituent-ils un point de défaillance unique potentiel s’ils ne sont contrôlés/surveillés que par un seul orchestrateur ? Le document nous indique qu’« après le processus de rattachement, les fonds en chaîne restent sécurisés dans une chaîne multisig entre les différents nœuds Orchestrator », mais les garanties concernant l’état de limbes d’un rattachement non confirmé ne sont pas claires.
Si l’objectif est d’éviter la perte de fonds des ancrages en raison d’une confirmation tardive, il semble que chaque orchestrateur devra conserver l’historique complet des adresses multisig de ancrage et les rechercher à chaque nouveau bloc Bitcoin. Cela pourrait ne pas s’adapter correctement sur une période pluriannuelle.
De même, ce problème peut également exister à l’envers pour le processus de rattachement, bien que les problèmes de mise à l’échelle seraient environ 60 fois plus élevés si le nœud Orchestrator utilisé pour créer l’UTXO de rattachement était un orchestrateur « à emplacement » par opposition à un orchestrateur « d’époque ». — ce n’est pas clair dans le journal.
Si un Orchestrator publie une transaction ou un blocage invalide, sa mise est réduite et… ? Je n’ai vu aucun détail sur les aspects économiques des réductions budgétaires et sur la façon dont les fonds sont distribués.
D’après la description de l’entrée/sortie de l’Orchestrator et du mécanisme permettant d’ajouter les Orchestrateurs les plus récents aux multisigs, il semble qu’il y ait un potentiel de lacunes. Autrement dit, il semble possible qu’un Orchestrator ne soit jamais ajouté à un multisig si une tonne d’autres Orchestrators rejoignent la spiderchain peu de temps après eux.
Combien de temps faut-il réellement pour s’en sortir ? Avec les chaînes cinématiques, cela prend des mois, ce qui laisse énormément de temps à l’intervention humaine en cas d’attaque. Il semble qu’avec Spiderchains, cela pourrait prendre quelques heures seulement. Des délais plus courts peuvent augmenter les risques d’attaques minières ou DoS.
Quel est le seuil de suppression des orchestrateurs peu fiables ? D’après le journal, il semble qu’une semaine d’inactivité à 100 % donne le coup d’envoi au processus de suppression. Mais que se passe-t-il s’ils ne sont tout simplement pas fiables et ne sont actifs que pour environ 5 % des blocs chaque semaine ? Bien sûr, ils sont incités à être actifs, sinon ils perdront la collecte des frais de transaction, mais il semble qu’il devrait y avoir un seuil supérieur à 0 % auquel un Orchestrator est démarré pour manque de fiabilité. Le document indique que l’inactivité “entraînera une lente fuite d’inactivité de la mise”, mais il n’est pas clair si cela signifie un manque de récompenses ou si leur mise sera réellement redistribuée aux orchestrateurs actifs.
Je soupçonne qu’il y a également des questions épineuses autour de la gestion d’UTXO en ce qui concerne les différents portefeuilles multisig. Par exemple, s’il n’y a qu’une fenêtre de rattachement limitée et que les fonds sont ensuite rattachés, mais que le portefeuille n’est pas complètement vidé et que de nouveaux portefeuilles sont créés pour les rattachements, je soupçonne qu’il est possible de se retrouver avec “ la poussière” s’est répandue sur de nombreux multisigs. Il reste donc une question ouverte quant à la logique qui sera mise en place pour traiter l’ensemble de tous les portefeuilles multisig comme un seul grand portefeuille virtuel.
De même, je me demande comment les orchestrateurs de Spiderchain peuvent réagir à la volatilité des frais sur la chaîne de base. Seront-ils assez intelligents pour RBF/CPFP dans tous les cas de blocage ?
Le schéma de signature multisig n’est jamais mentionné, mais je suppose qu’il s’agit de Schnorr ou d’une sorte de construction comme MPC qui n’apparaît que comme une signature unique sur la chaîne, sinon la taille des données de transaction et les frais seront prohibitifs. En outre, les orchestrateurs doivent pouvoir changer les détenteurs de clés d’un multisig donné, probablement sans avoir à déplacer des fonds sur la chaîne.
Attaques potentielles :
Le livre blanc parle beaucoup des attaques de Sybil, mais il n’aborde pas beaucoup les problèmes liés à la vivacité. Par exemple, nous savons que les orchestrateurs inactifs sont supprimés des multisigs après une semaine d’inactivité. Et si cet attribut était utilisé conjointement avec une attaque par déni de service ? Si les opérateurs d’Orchestrator n’y prêtent pas attention, ils pourraient se retrouver exclus du système et potentiellement même perdre des fonds si suffisamment d’Orchestrateurs honnêtes sont supprimés en tant que signataires multisig.
Il peut également exister un vecteur d’attaque potentiel lié à la réorganisation de la blockchain Bitcoin. Bien que le mécanisme de vote des mineurs utilisé pour les chaînes de transmission ait fait l’objet de beaucoup de bruit, ce processus prend des mois pour se dérouler pendant que le monde entier peut l’observer. Le fait que les spiderchains n’aient qu’un délai de 6 blocs pour sélectionner les orchestrateurs me semble inutilement court. Personnellement, je recommanderais un délai de 100 blocs pour le mettre en conformité avec le seuil de maturation de Coinbase. D’un autre côté, compte tenu de la façon dont les multisigs de la chaîne d’araignée sont distribués et de la nature LIFO de la gestion UTXO du rattachement, une attaque à courte portée est plus limitée dans la quantité de fonds du rattachement qu’elle peut affecter.
Coûts de lancement de la sidechain :
Un aspect des sidechains ancrés dont on ne parle pas beaucoup est le coût de leur lancement. Rappelez-vous la vision originale d’un univers sidechains :
Cette vision ne sera réalisable que lorsque les coûts de lancement auront été considérablement réduits. En regardant les options disponibles:
Sidechains fédérés : coûts de lancement élevés pour organiser un consortium et déployer des modules matériels sécurisés pour la signature.
Chaînes de transmission : coûts de lancement moyens pour convaincre suffisamment de mineurs de voter pour le rattachement.
Spiderchains : coûts de lancement inconnus, probablement élevés si de longues phases de démarrage, de l’autorisation à l’autorisation sans autorisation, sont nécessaires.
Dernières pensées :
Nous sommes depuis près d’une décennie dans la quête du Saint Graal du rattachement de sidechain sans autorisation et les progrès ont été plutôt lents. Jusqu’à présent, nous n’avons vraiment que 2 options viables :
1- Répartir la confiance entre une fédération suffisamment large d’entités réputées.
2 -Créer une théorie des jeux pour gérer un pool de BTC indexés. Drivechains crée des incitations pour les mineurs à gérer le BTC, tandis que Spiderchains crée des incitations pour les parties prenantes à gérer le BTC. Chacun comporte des compromis et de la complexité.
À un niveau élevé, je pense que Spiderchain a du sens lorsque les conditions sont telles que décrites dans le livre blanc. La question du million de bitcoins est de savoir dans quelle mesure le système peut résister aux cas extrêmes et aux conditions contradictoires. La complexité et la théorie des jeux à plusieurs variables rendent difficile le raisonnement, et ces types de systèmes de sécurité économique ne peuvent pas vraiment être mis en œuvre sur un réseau de test à valeur nulle.
J’ai hâte de voir cette expérience progresser !
Traduction document original par Tetardmartien
