Il y a deux semaines, Jeremy Rubin a présenté une proposition intitulée Un’FE’d Covenants (FE = Functional Encryption). Cette initiative arrive dans un contexte où les discussions autour des propositions d’alliance pour Bitcoin se poursuivent depuis deux ans et offre une nouvelle option pratique. Contrairement aux autres propositions qui nécessitent un soft fork, l’utilisation de cryptographie non éprouvée ou des coûts élevés (comme ColliderScript), la suggestion de Jeremy est sans softfork et ne présente pas de charges d’utilisation excessives pour les utilisateurs. Toutefois, cela implique un modèle de sécurité fondamentalement différent grâce à l’emploi d’un système d’oracles et d’obligations basées sur BitVM. Ces éléments permettent d’implémenter des engagements sur Bitcoin dès maintenant.
Les Oracles
La première composante de cette solution repose sur les oracles, qui appliquent divers critères d’alliance. C’est un élément relativement simple et constitue le fondement de la proposition de Jeremy. Dans ce système, l’oracle détient les fonds et est responsable de l’exécution des conditions d’engagement. Pour éviter que l’oracle doive suivre les conditions de l’alliance pour chaque pièce, ce qui pourrait engendrer des risques si la base de données des oracles est compromise, Jeremy fait appel à Taproot.
Les clés basées sur Schnorr permettent de modifier une clé publique à l’aide d’un hachage de données. Cela modifie également la clé privée correspondante, autorisant ainsi la signature de la clé modifiée tout en prouvant que les données utilisées pour la modification étaient engagées par cette clé. En demandant à l’oracle de générer la clé et à l’utilisateur de la modifier via son programme d’engagement, on assure une certaine sécurité sans surcharger l’oracle avec des obligations de stockage.
Les oracles peuvent également fonctionner de manière fédérée, réduisant ainsi la confiance nécessaire envers une seule entité. Une fois les conditions remplies, les utilisateurs peuvent soumettre l’adresse résultante à l’oracle avec les données essentielles pour valider les transactions. En cas de conformité avec les règles de l’alliance, l’oracle est en mesure de signer la transaction.
Pour des accords simples dont les résultants sont connus avant, tels que CHECKTEMPLATEVERIFY (CTV), les utilisateurs peuvent demander à l’oracle de pré-signer les transactions et les activer ultérieurement. Pour des engagements plus complexes, comme ceux basés sur des états, il est crucial que les transactions signées par l’oracle reflètent l’état actuel de l’engagement via OP_RETURN, afin que l’oracle puisse vérifier les mises à jour sans stocker d’informations localement.
Lire plus
Le lien BitVM
Actuellement, le système repose essentiellement sur la confiance plénière. Toutefois, des ajustements peuvent être réalisés pour garantir une incitation économique favorable. OP_RETURN peut également être utilisé pour prouver que les conditions de l’accord ont été respectées. Un circuit BitVM peut être conçu pour vérifier si une transaction signée par un oracle respecte les conditions définies dans l’engagement. Les oracles peuvent être tenus de déposer une caution, garantissant que tant que la caution d’un oracle dépasse l’engagement, le système demeure sécurisé.
Compromis
Cependant, plusieurs compromis notables sont à considérer. D’abord, l’oracle doit être en ligne pour faire respecter les clauses, ce qui pourrait poser problème si l’oracle est hors ligne. Ensuite, les besoins de liquidité pour ces oracles pourraient devenir énormes avec une adoption large, rendant le système inefficace comparé à des implémentations directes au niveau du consensus. Enfin, les données supplémentaires requises pour le système de liaison BitVM risquent de consommer un espace de blocage plus important que des clauses natives.
En somme, cette proposition, bien que moins efficace que les engagements autochtones, constitue une alternative viable en cas d’ossification prématurée, facilitant l’intégration d’engagements dans Bitcoin sans recourir à une cryptographie incertaine ou à des coûts exorbitants.
Jeremy nous offre ici une perspective face aux situations les plus contraignantes, élargissant ainsi les possibilités de conception autour de Bitcoin.
Résumé
La proposition de Jeremy Rubin sur les Un’FE’d Covenants présente une alternative pratique aux alliances Bitcoin grâce à l’utilisation d’oracles sans imposer les contraintes d’un soft fork ni de coûts excessifs. Bien qu’elle introduise de nouveaux compromis et groupes de confiance, elle ouvre des voies pour intégrer des engagements dans le réseau Bitcoin tout en contournant des méthodes potentiellement risquées ou inefficaces.
.png?ssl=1 "Les importations américaines chutent de 64 %, les exportations de 30 % alors que la guerre commerciale pave la voie à l’hyper bitcoinisation")
