Un système qui permettrait d’exécuter des contrats intelligents sur Bitcoin sans que l’utilisateur ne confie la garde de ses fonds à un opérateur a été proposé le 27 mai par Burak Keceli, le développeur connu dans la communauté Bitcoin pour avoir exposé des vulnérabilités critiques dans le Lightning Network (LN) en 2022 qui ont forcé une mise à jour d’urgence.
Le nouveau projet s’appelle Cube et vise à apporter la finance programmable à Bitcoin afin que lorsqu’un utilisateur dépose ses fonds dans un contrat intelligent, il ne perde pas temporairement la possibilité de les retirer lui-même.
Keceli décrit Cube comme une plate-forme sur laquelle des échanges d’actifs sans courtier, des systèmes de prêts garantis et des pièces stables adossées au bitcoin (BTC), entre autres applications financières, pourraient être construits.
Alors que de nombreux L2 actuels nécessitent un certain degré de confiance dans les opérateurs ou les comités (tels que les propres fournisseurs de services Ark L2 de Keceli ou la fédération multisignature sur le Liquid Network de Blockstream), Cube promet que l’utilisateur ne perdra jamais la possibilité de retirer ses fonds unilatéralement dans la couche de base du Bitcoin.
En revanche, Cube nécessiterait une couche technique appelée Engine, qui agirait en tant que votre coordinateur interne. Son rôle serait d’ordonner les transactions des utilisateurs, d’enregistrer périodiquement l’état du système dans Bitcoin et de coordonner l’exécution hors réseau.
En ce sens, Keceli affirme que le moteur “n’est jamais le gardien”puisque, selon le développeur, les fonds resteraient dans le cadre d’un accord entre l’utilisateur et le moteur qui nécessite la signature des deux pour être déplacés (multisignature 2 sur 2). De plus, explique Keceli, l’utilisateur pourrait forcer sa sortie sans la collaboration du moteur s’il agissait de manière malveillante ou s’il cessait de fonctionner.
Même si les utilisateurs conservent la possibilité théorique d’une sortie unilatérale si le moteur cesse de fonctionner ou agit de manière malveillante, cela fait du moteur un point potentiel de friction opérationnelle, même si cela ne compromet pas la conservation des fonds.
Bien que Keceli n’examine pas comment le moteur pourrait échouer, une erreur dans cette structure pourrait potentiellement être due à une défaillance technique du système ou à une action délibérée, y compris la possibilité que le moteur soit compromis par un tiers.
Comment Cube fonctionnerait-il sur Bitcoin ? Trois pièces combinées
Cube combinerait trois mécanismes pour réaliser des contrats intelligents avec une sortie unilatérale :
Arbres de délai d’attente (arbres de délai d’attente)
Les premiers sont les arbres de délai d’attente (arbres de délai d’attente), qui sont la structure qui organise et enregistre les fonds de tous les utilisateurs de Cube. Ils fonctionnent comme un arbre de transactions pré-signées : chaque branche correspond à un utilisateur et a, dès le début, enregistré le droit de cet utilisateur de réclamer ses fonds directement en Bitcoin en cas de problème. L’arborescence entière partage un seul point d’enregistrement périodique dans le réseau de base.
Cette architecture permet deux modes de fonctionnement. Tant que le moteur fonctionne correctement, les transactions entre utilisateurs se produisent au sein de Cube sans qu’il soit nécessaire d’écrire chaque mouvement en Bitcoin, ce qui réduirait le temps et les coûts. Mais si le Moteur cessait de fonctionner ou tentait de retenir des fonds, l’utilisateur n’aurait pas besoin de son autorisation pour sortir : il pourrait activer sa branche de l’arbre directement dans Bitcoin et récupérer la sienne de manière autonome, une fois la période prédéfinie qui a été enregistrée lors de votre dépôt. Ce terme est la seule condition ; Aucun intermédiaire ne peut le bloquer. Cette technologie est issue du protocole Ark.
BitVM3
Le deuxième mécanisme est BitVM3, la version la plus récente de BitVM (Bitcoin Virtual Machine), une proposition du développeur Robin Linus. BitVM3, qui n’est pas encore opérationnel, vise à résoudre dans Cube comment un utilisateur pourrait prouver que le moteur ne fonctionnait pas correctement, si toutes les exécutions se faisaient en dehors de Bitcoin.
La réponse de Cube est la suivante chaque opération du moteur est accompagnée d’une déclaration vérifiable sur son résultat. Si l’utilisateur détecte que cette déclaration est fausse, il peut présenter la preuve de l’erreur directement dans Bitcoin. Bitcoin l’évalue et, s’il confirme la fraude, il activerait une pénalité contre le moteur, ce qui libérerait les fonds bloqués en garantie exposés à un litige résolu en faveur de l’utilisateur. Le mécanisme vise à garantir que le coût d’une mauvaise action soit supérieur à tout avantage possible.
CubeVM
Le troisième est CubeVM, une machine virtuelle (environnement d’exécution de programme) construite comme une extension de Bitcoin Script, le langage de programmation natif de Bitcoin.
CubeVM ajouterait prise en charge des contrats intelligents complexesqui sont des programmes capables d’exécuter une logique financière avancée, telle que des échanges d’actifs ou des pièces stables garanties, ce que le script Bitcoin natif ne permet pas.
Le problème que Cube veut résoudre dans Bitcoin
L’utilisation de contrats intelligents dans Bitcoin implique que lorsqu’un utilisateur dépose ses fonds dans un contrat, Ces fonds deviennent sous le contrôle de la logique du programmepas la clé privée de l’utilisateur.
Dans cet état intermédiaire, Bitcoin ne dispose d’aucun moyen natif pour reconnaître que ces fonds appartiennent à l’utilisateur, puisque le protocole comprend les clés et non la logique du programme. L’utilisateur est, en pratique, cela dépend du fonctionnement correct du système que vous utilisez pour récupérer le vôtre.
Le mécanisme proposé par Keceli pour résoudre ce problème s’appelle Ombrage (projection d’ombre). Cet outil conserverait à tout moment un enregistrement interne de la quantité de BTC correspondant à chaque utilisateur dans le cadre de chaque contrat.
Cet enregistrement (appelé espace d’ombreou espace fantôme) ne représenterait pas la garde directe des fonds, mais plutôt la dette que le contrat aurait avec chaque participant. Cette dette se refléterait continuellement dans le arbres de délai d’attenteafin que l’utilisateur dispose toujours d’une sortie disponible sur le réseau Bitcoin équivalente au montant que le contrat lui doit, même lorsque ses fonds sont sous le contrôle du programme.
Pour que le mécanisme fonctionne correctement, Keceli décrit une règle interne de la machine virtuelle Cube : la somme de tous les montants enregistrés dans l’espace fantôme ne doit jamais dépasser le Bitcoin que le contrat conserve effectivement. Si cette condition n’est pas respectée, l’opération que vous effectuez dans Cube serait automatiquement rejetée. Cela viserait à garantir qu’il y ait toujours des fonds réels pour soutenir chaque sortie unilatérale possible.
Dans ce contexte, alors que le débat sur les Bitcoin L2 programmables oscille entre des systèmes qui réalisent des contrats complexes en renonçant à un certain degré de garde, et ceux qui préservent la souveraineté des utilisateurs mais avec des fonctionnalités limitées, Cube, l’une des plus récentes de ces propositions, tente de ne céder sur aucun des deux fronts. Cependant, la question de savoir si la conception résiste à un examen technique et est mise en œuvre reste ouverte.
