Avenants Bitcoin : OP_VAULT (BIP 345)

Ceci est le quatrième article dans un série Une plongée profonde dans les propositions individuelles de l’alliance qui ont atteint un point de maturité méritant une ventilation approfondie.

Op_vault, mis en avant par James O’Beirne dans BIP 345 (avec Greg Sanders ajouté plus tard en tant que co-auteur), est une alliance conçue pour mettre en œuvre des coffres. Cela dépend, en plus de CTV (ou txhash ou d’autres opcodes similaires) pour compléter la construction d’un coffre-fort.

Avant d’entrer dans le fonctionnement de la proposition elle-même, examinons ce qu’un coffre-fort essaie d’accomplir.

Le but d’un coffre-fort est d’améliorer la sécurité de votre stockage Bitcoin. Ceci est accompli par l’introduction d’une période de retard lors de toute tentative de dépenser de la coffre-fort. Plutôt que de pouvoir envoyer directement votre bitcoin à partir du coffre-fort, le coffre-fort les restreint afin qu’ils ne puissent être envoyés qu’à une adresse « d’entente ». Bien que les pièces retirées du coffre-fort se trouvent dans cet état inférieur, elles peuvent être transférées à tout moment dans un portefeuille de stockage froid profond sous votre contrôle (idéalement un multisig de coffre-fort géographiquement distribué), et seulement à ce rangement froid profond. Après un timelock prédéfini, les pièces peuvent ensuite être consacrées à la destination ultime prévue.

C’est quelque chose qui est possible à faire actuellement avec les transactions pré-signatées, mais cela apporte un grand degré de complexité, d’inefficacité, de manque de flexibilité et de risque de perdre des fonds.

L’utilisation de transactions pré-signées oblige à décider à l’avance combien d’argent sera retiré à la fois, ce qui nécessite de s’assurer que les transactions retirant du coffre ont supprimé en toute sécurité les clés privées utilisées pour pré-signaler toutes ces transactions.

Un gros problème avec cette architecture, à part les restrictions globales des montants, des frais, etc. prédéfinis, est que la réutilisation d’adresse n’est pas sûre. Dans un schéma de coffre-fort de transaction pré-signatée, les dépôts sont envoyés à l’adresse utilisée pour pré-signer la transaction initiale du coffre-fort, et celle avec toutes les autres clés impliquées est supprimée après la signature des transactions du coffre-fort. La réutilisation de l’adresse est une mauvaise pratique, mais vous ne pouvez pas empêcher quelqu’un d’autre d’envoyer des fonds à une adresse qu’ils ont utilisée auparavant. De tels fonds déposés ultérieurs seraient perdus à jamais, car les clés de voûte ont toutes été supprimées.

De plus, chaque dépôt dans un coffre-fort nécessite une nouvelle configuration de nouvelles clés, effectuant à nouveau la cérémonie de pré-signature pour le nouvel ensemble de transactions, veillant à ce que le nouvel ensemble de clés soit en toute sécurité supprimé et en gérant le stockage approprié de toutes ces informations, y compris les sauvegardes redondantes. Chaque dépôt crée une opportunité pour quelque chose de se gâcher pendant la configuration du coffre-fort, chaque dépôt offre une chance à quelqu’un qui a compromis un système ou un appareil depuis le dernier dépôt pour essayer de voler vos fonds.

Les coffrets de transaction pré-signatés sont une construction lourde et compliquée, et présentent une complexité suffisante pour que chaque utilisation présente un risque non négligeable de gâcher d’une manière qui se traduit par la perte de fonds.

Des améliorations peuvent être apportées à CTV, comme supprimer la nécessité de supprimer solidement les clés, mais le reste de la complexité et du risque demeure. Les montants et les frais doivent toujours être prédéfinis. La réutilisation d’adresse peut toujours entraîner une perte de fonds.

Comment fonctionne OP_VAULT

OP_VAULT est construit sur une tapoot, ce qui signifie que la conception entière utilise Tapscript et dépend de l’existence de Taptrees et du chemin de dépense du script. Il dépend également de l’utilisation de CTV (ou TXHASH / fonctionnalité similaire) pour construire un coffre-fort complet.

La proposition est en fait deux OPCodes, OP_VAULT et OP_VAULT_RECOVER. OP_VAULT est utilisé pour déclencher des retraits du coffre-fort et OP_VAULT_RECOVER est utilisé pour balayer les retraits déclenchés dans le portefeuille de récupération en profondeur. L’idée est de construire un taptree qui contient des chemins OP_VAULT pour les retraits, et UP_VAULT_RECOVER pour balayer tous les fonds à mi-entraînement à un portefeuille froid sécurisé. Ce taptree est votre coffre-fort.

OP_VAULT fonctionne en restreignant à quoi les sorties d’une transaction dépensant une pièce encombrée OP_VAULT doivent être apparentées. L’opcode attend dans le témoin :

• Un corps de script Tapleaf
• Le nombre de pièces de données pour une mise à jour de script
• Un index de sortie pour le retrait
• Un index de sortie pour tous les fonds qui reviennent dans le coffre-fort
• Une quantité de satoshis retournant dans le coffre-fort

OP_VAULT garantit que le montant correct de fonds renvoyés au coffre-fort est correct et que le script de sortie de cette sortie est identique à la sortie dépensée. Il prend également le corps du script Tapleaf et les variables de données fournies et les combine dans un script Tapleaf complet. Il garantit alors que la sortie spécifiée pour le retrait a un script identique avec le taptree de l’entrée dépensée, sauf que le Tapleaf en cours de dépensé est remplacé par le script Tapleaf assemblé avec les données du témoin.

Cette dernière astuce est possible car afin de vérifier que le Tapleaf fait partie du taptree en premier lieu, les nœuds intérieurs de l’arbre Merkle doivent être présents pour vérifier. Le hachage du nouveau script avec les feuilles intérieures connues du reste de l’arbre garantit que seule cette feuille de l’arbre a été modifiée. Le modèle du script qui est rempli dynamiquement est défini au moment de la création du coffre-fort. Pour un cas d’utilisation typique de Vault, le modèle de script serait simplement un chemin de dépense CTV TIMELOCKED avec le hachage fourni lors du déclenchement d’un retrait.

OP_VAULT_RECOVER est beaucoup plus simple. Il nécessite un hachage du script de récupération et un index de sortie pour la transaction de récupération. Cette sortie doit contenir un script qui correspond exactement au hachage prédéfini, et l’intégralité de la quantité de fonds dans l’entrée récupérée doit aller à cette sortie.

Ces deux scripts peuvent être « fermés » avec un script d’autorisation, c’est-à-dire fournissant une signature à partir d’une clé spécifique afin de déclencher un retrait ou de déclencher une reprise. Cela a quelques compensations. Si vous perdez une clé d’autorisation de récupération, vous ne pourrez plus déclencher une transaction de récupération en cas de vol de votre clé de déclenchement de retrait. Cependant, cela vous permet de lancer une reprise à partir de plusieurs cavaliers UTXOS dans la même transaction en raison de la spécification des sorties correspondantes de chaque entrée manuellement.

Qu’est-ce que OP_VAULT est bon pour

De toute évidence, les coffres. OP_VAULT a proprement abordé toutes les principales limites d’une transaction pré-signée ou d’un coffre-fort basé sur CTV. Aucune dénomination prédéfinie ou frais prédéfini, aucun danger, ne réutilisez pas les adresses, et aucune nécessité de faire face à un problème de sécurité élevé comme la suppression de clés à chaque fois que vous déposez.

C’est beaucoup plus flexible que de simples voûtes. C’était le cas d’utilisation prévu lorsqu’il a été conçu, mais c’est une alliance beaucoup plus générale garantissant qu’un taptree se fait réellement vers le prochain UTXO lorsque vous le souhaitez, avec des conditions de sortie prédéfinies qui ont un certain degré de flexibilité.

Vous pouvez faire quelque chose de très proche d’un Drivechain avec OP_VAULT. Créez un modèle de coffre-fort qui a un timelock incroyablement long, à l’ordre de 3 à 6 mois (similaire aux retraits DriveChain). N’ayez aucune porte d’autorisation pour un script et rendez le modèle public. Les gens peuvent désormais simplement déposer des fonds dans le « DriveChain » en envoyant de l’argent à ce script de coffre-fort. Tout le monde peut proposer un retrait en dépensant simplement un chemin OP_VAULT et en incluant un hachage CTV de sa transaction de retrait. Les mineurs peuvent appliquer cela en refusant simplement d’extraire des transactions de retrait non valides, et si un mineur malveillant a jamais exploité un déclencheur de retrait malveillant, le prochain mineur honnête pourrait simplement révolter les fonds.

C’est ce qui peut être fait en utilisant un modèle de script identique comme recommandé dans le BIP. Le modèle de script défini pour les retraits est arbitraire et, en tant que tel, est potentiellement très général en termes de types d’auto-contrats perpétués qu’OP_VAULT pourrait permettre.

Réflexions de clôture

OP_VAULT atteint clairement l’objectif de permettre des voûtes appropriées qui ne viennent pas avec les restrictions, les complexités et le risque que les coffrets de transaction pré-signés (ou même les voûtes d’alliance plus simples avec quelque chose comme CTV) viennent avec. Cependant, ce faisant, il a fini par introduire un ensemble de fonctionnalités assez large et généralisé pour atteindre cet objectif original.

La proposition permettrait définitivement une fonctionnalité de coffre-fort relativement lisse et sécurisée, mais elle ouvre également de nombreuses autres portes. Les drivechains sont quelque chose qui vient avec un un grand degré de risque centré autour de la valeur extractible de mineurs (MEV). Les inconvénients de permettre une telle fonctionnalité, et les problèmes et les conséquences incitatives qu’ils pourraient avoir, doivent être pesés avec la hausse de l’activation d’un coffre-fort bien construit.

OP_VAULT est une proposition relativement mature, mais le degré de fonctionnalité qu’elle permet ne doit pas être approché légèrement.