Jeremy Rubin a publié une proposition il y a deux semaines intitulée Conventions Un’FE’d (FE = Cryptographie Fonctionnelle). Étant donné le débat en cours sur les propositions de conventions pour Bitcoin au cours de la dernière année ou deux, sa proposition marque une nouvelle option pratique. Toutes les propositions de conventions jusqu'à présent nécessitent un soft fork (opcodes réels), le développement et la mise en œuvre d'une cryptographie non prouvée (Cryptographie Fonctionnelle), ou un coût monétaire absurdement élevé pour l'utiliser (ColliderScript).
La proposition de Jeremy ne nécessite aucun soft fork et n'impose pas un coût lourd et impraticable aux utilisateurs pour l'utiliser. Le compromis pour cette capacité est un modèle de sécurité radicalement différent. En utilisant un système d'oracles et des obligations basées sur BitVM capables de couper, les conventions peuvent être émuler sur Bitcoin dès maintenant.
Les Oracles
La première partie du schéma est évidemment les oracles qui appliquent différentes conditions de convention. C'est un ensemble relativement simple, et le premier élément nécessaire à la proposition de Jeremy. L'oracle a la garde des fonds dans ce schéma et est chargé de l'application des conditions de la convention. Vous voulez que l'oracle n'ait pas à suivre localement les conditions de la convention appliquées pour chaque pièce qu'il garde. Cela introduit un risque d'état où, si la base de données des oracles est corrompue ou perdue, il n'a aucune idée de la façon de gérer une application honnête pour les pièces de chacun. Pour contourner ce problème, Jeremy utilise Taproot.
Les clés basées sur Schnorr peuvent être « ajustées » en utilisant le hachage des données pour modifier une clé publique. Cela permet d’ajuster la clé privée correspondante pour pouvoir signer pour la clé modifiée, ainsi que de prouver que quelles que soient les données utilisées pour ajuster la clé publique sont engagées par cette clé. Faire générer une clé par l'oracle, puis l'utilisateur ajustant cette clé avec son programme de convention permet un engagement à ce que l'oracle est censé appliquer tout en gardant le fardeau de stocker cette information sur l'utilisateur.
Les oracles peuvent également être fédérés afin de minimiser la confiance requise envers une seule partie pour appliquer les choses. À partir de là, les utilisateurs peuvent simplement charger l'adresse résultante, et chaque fois qu'ils veulent appliquer la condition, approcher l'oracle(s) avec la transaction de dépense, le programme oracle et les données de témoin nécessaires pour prouver que la transaction donnée à l'oracle respecte les conditions de la convention. Si la transaction est valide selon les règles de la convention, l'oracle la signe.
Pour toute convention simple où les résultats sont connus à l'avance, comme CHECKTEMPLATEVERIFY (CTV), les utilisateurs peuvent immédiatement demander à l'oracle de pré-signer les transactions appliquant la convention et simplement retarder leur utilisation jusqu'à ce qu'il soit nécessaire.
Un scénario important à considérer nécessitant une fonctionnalité supplémentaire est les conventions basées sur l'état, telles que les rollups, qui progressent régulièrement et ont un état réel (le solde actuel des utilisateurs) à suivre. Dans le cas de telles conventions, les transactions que l'oracle signe doivent s'engager à l'état actuel de la convention en utilisant OP_RETURN afin que l'oracle puisse vérifier efficacement chaque transaction mettant à jour le rollup ou un autre système sans avoir à télécharger les données de témoin pour l'ensemble de l'historique. Cela permet d'éviter que l'oracle ne doive stocker l'état localement, ce qui, comme mentionné ci-dessus, crée des risques.
À long terme, les exigences en matière de données des oracles peuvent être optimisées en utilisant des preuves à connaissance nulle, de sorte que l'oracle puisse simplement vérifier une preuve que la transaction qu'on lui demande de signer respecte les règles de la convention sans avoir à vérifier les données brutes du témoin pour des conventions plus grandes et plus complexes. Encore une fois, dans le cas de systèmes comme les rollups, il faut faire attention à les concevoir pour garantir que les données nécessaires pour sortir du système soient mises à la disposition des utilisateurs afin qu'ils les aient en leur possession s'ils ont besoin de contacter directement l'oracle pour récupérer leurs fonds.
L'Obligation BitVM
Jusqu'à présent, le schéma est entièrement de confiance. Vous donnez essentiellement votre argent à quelqu'un d'autre en espérant qu'il puisse être digne de confiance pour appliquer les conditions de conventions arbitraires. En modifiant légèrement le schéma ci-dessus, cela peut être sécurisé par un incitatif crypto-économique plutôt que par une pure confiance.
Il a été décrit ci-dessus comment OP_RETURN doit être utilisé pour suivre l'état des conventions d'état. OP_RETURN peut également être utilisé pour publier les données de témoin de toutes les transactions de convention afin de prouver que les conditions ont été correctement remplies.
Un circuit BitVM peut être construit pour vérifier si une transaction signée par l'oracle correspond effectivement aux conditions de la convention qu'il applique. N'oubliez pas que la clé elle-même qui est générée et les fonds envoyés s'engagent aux conditions de toute convention appliquée. Cela signifie que des données, ainsi qu'une transaction étant dépensée depuis l'adresse, peuvent être alimentées dans une instance BitVM.
Les oracles peuvent alors être tenus de poster une obligation de garantie avec un opérateur BitVM (qui doit également poster une obligation que l'oracle peut revendiquer s'il est faussement accusé). De cette façon, tant que la valeur de l'obligation est supérieure à la valeur sécurisée dans des conventions par un oracle, le système peut être utilisé en toute sécurité. Il n'y aurait aucun moyen pour un oracle de violer les conditions d'une convention qu'il applique sans perdre de l'argent en agrégé.
Compromis
Il y a des compromis clairs ici qui sont matériellement pires que d'implémenter simplement des conventions dans les règles de consensus. Tout d'abord, l'oracle doit être en ligne et accessible pour utiliser des conventions appliquées par oracle. À l'exception des conventions pré-signées telles que CTV, si l'oracle est hors ligne lorsque les utilisateurs doivent appliquer une convention, ils ne peuvent pas. L'oracle doit être présent pour signer.
Deuxièmement, les exigences de liquidité pour les obligations oracle peuvent devenir massives si le système était un jour largement adopté. Cela le rend incroyablement inefficace par rapport à l'implémentation native des opcodes de convention au niveau du consensus.
Enfin, les données supplémentaires requises pour être publiées sur la chaîne afin que le schéma d'obligation BitVM fonctionne sont beaucoup moins efficaces avec l'utilisation de l'espace de bloc que les implémentations de conventions natives.
Dans l'ensemble, la proposition n'est pas du tout aussi efficace et sécurisée que les conventions natives. D'autre part, si nous nous retrouvons dans le pire des scénarios d'ossification prématurée, c'est un moyen très praticable d'intégrer des conventions dans Bitcoin sans dépendre d'une cryptographie non prouvée ou de coûts complètement impraticables imposés aux utilisateurs finaux.
Jeremy nous a donné une option de scénario de pire cas pour élargir l'espace de conception de ce qui peut être construit sur Bitcoin.
Source : Bitcoin Magazine
Le post Un Dernier Recours : Des Conventions Un’FE’d Pour Bitcoin est apparu en premier sur Crypto Breaking News.
