Finance native de Bitcoin sans ponts

Curiosité

1. Comment un contrat financier peut-il être réglé en satoshi natifs sans introduire de nouveau jeton ou de nouvelle chaîne ?
2. Quelles hypothèses de confiance spécifiques sont introduites lors de l’utilisation d’un oracle pour les données de prix par rapport à leur vérification locale ?
3. Pourquoi la capacité de quitter unilatéralement pour retourner à la couche de base est-elle considérée comme la principale métrique de sécurité pour les finances natives de Bitcoin ?

Explorer

1. Les contrats Log discrets, proposés par T. Dryja en 2017, permettent d’établir des contrats financiers sur Bitcoin en utilisant uniquement des pièces natives. Les deux parties verrouillent des fonds dans une sortie multisig de type 2-of-2 et signent à l’avance une transaction de paiement pour chaque résultat possible ; chacune de ces transactions devient utilisable grâce à une signature d’adaptateur qui n’est valide qu’avec la signature de l’oracle correspondant à ce résultat. L’oracle publie son attestation sans connaître l’existence du contrat. Lorsqu’il atteste, le paiement associé devient valable ; s’il échoue ou se comporte mal, un mécanisme de verrou temporel permet aux participants de récupérer leur capital après une période déterminée. Cette conception évite d’emballer Bitcoin dans des tokens d’une autre chaîne, mais introduit une dépendance cruciale : l’utilisateur doit faire confiance à l’oracle pour qu’il ne signe pas de manière malveillante, et au réseau pour que le mécanisme de verrou temporel soit appliqué.
2. Les structures multisig et timelock facilitent les protocoles de prêt où le preneur conserve la garde de ses clés tandis que la garantie est verrouillée. Dans ces systèmes, le prêteur détient une clé et le preneur une autre ; un mécanisme tiers ou basé sur des scripts gère la liquidation si la valeur de la garantie tombe en dessous d’un seuil. Contrairement aux actifs encapsulés qui nécessitent un gardien pour créer des tokens sur une autre chaîne, cette approche conserve toute la valeur dans le modèle UTXO de Bitcoin. Le compromis réside dans la complexité de la gestion des clés et le risque d’erreurs dans le logiciel qui crée et signe ces transactions.
3. Les canaux du Lightning Network permettent des flux de paiement hors chaîne qui ne sont réglés sur la couche de base que lorsqu’ils sont fermés. Cela réduit la congestion et les frais liés aux transactions à haute fréquence, tout en maintenant les garanties de finalité de Bitcoin. Ark permet à de nombreux utilisateurs de partager un résultat sur chaîne coordonné par un opérateur ; chaque utilisateur dispose d’un chemin pré-signé pour quitter la chaîne seul en cas de disparition de l’opérateur. La sécurité de ces systèmes repose entièrement sur le consensus de la chaîne sous-jacente ; aucun nouveau ensemble de validateurs n’est introduit, ce qui préserve le modèle de sécurité décentralisé établi dans les leçons précédentes.
4. Les conceptions de type BitVM visent à vérifier des calculs arbitraires sans modifier les règles de consensus de Bitcoin. BitVM (Robin Linus, 2023) est optimiste : un preneur prétend obtenir un résultat en dehors de la chaîne, et si quelqu’un remet cela en question, un différend géré au moyen du langage Script de Bitcoin permet d’identifier l’étape erronée et de pénaliser le preneur. Son utilisation principale concerne les ponts dont la sécurité ne nécessite qu’un vérificateur honnête parmi beaucoup, plutôt qu’une fédération fiable. Cela représente un changement significatif par rapport aux chaînes à usage général et complètes de Turing vers des calculs sélectifs et vérifiables.
5. Chacun de ces mécanismes introduit des hypothèses de confiance distinctes qui doivent être évaluées au regard des propriétés fondamentales de Bitcoin. Les oracles exigent une confiance dans les sources de données externes ; les contrats multisig nécessitent une confiance dans la correction du code et la gestion des clés ; les canaux d’état requièrent une confiance dans les mécanismes de résolution des conflits. Le point commun est la préservation de l’autogestion : les utilisateurs peuvent toujours se réfugier vers des satoshis natifs sans autorisation d’une fondation ou d’une clé administrative. Cela contraste fortement avec les actifs emballés, où pour sortir il faut passer par des intermédiaires fiables, ce qui réintroduit un risque de contrepartie que les architectures natives évitent.
6. Lisez la structure de la transaction dans les spécifications DLC (dlcspecs) : une transaction de financement avec une sortie multisig 2-sur-2, une transaction d’exécution pré-signée pour chaque résultat, et une transaction de remboursement verrouillée jusqu’à un moment donné au cas où l’oracle ne certifierait jamais rien. Indiquez quelle partie est considérée comme fiable par chacune des parties concernées, l’oracle et la chaîne.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• T. Dryja, 'Discreet Log Contracts' (2017)
• R. Linus, 'BitVM: Compute Anything on Bitcoin' (2023); Discreet Log Contract specifications (github.com/discreetlogcontracts/dlcspecs)
• Lightning Network Whitepaper: J. Poon & T. Dryja (2015/2016)