Modèle d'engagement de script utilisant l'introspection et l'autorité du jeton de groupe : btc
J’ai essayé de comprendre si une alliance de script pouvait être créée à l’aide de Script et de nouveaux opcodes d’introspection. Là, j’ai réalisé que c’était impossible car le script de verrouillage ne peut pas accéder au TX parent complet, il ne peut accéder qu’aux sorties. Prouver quelque chose sur les entrées qui ont créé une sortie nécessiterait le TX entier comme preuve. C’est pourquoi PMv3 a été proposé, pour combler l’écart en compressant la preuve à une taille fixe, et je pense que cela a finalement « cliqué » avec moi (voir ci-dessous) afin que je puisse maintenant mieux raisonner sur les différentes approches.
La tokenisation de groupe fonctionne d’une autre manière. Il code en dur le comportement du jeton en consensus, donc du point de vue du script, il n’est pas nécessaire de prouver qu’un jeton de groupe est authentique ou qu’il s’est comporté selon certaines règles, de même qu’il n’a pas besoin de prouver que BCH sur lequel il opère est authentique et qu’il s’est comporté. Son existence est une preuve suffisante. Ce que je n’ai réalisé que récemment, c’est qu’il est possible de créer un script collant, qui colle au jeton et qui peut prouver qu’il était collé au jeton à la genèse et prouver qu’il n’aurait pas pu être décollé et recollé dessus. En prouvant cela, il prouve également qu’il respectait toutes les règles symboliques depuis la genèse.
C’est possible parce que la dernière spécification de consensus de groupe verrouille la sortie d’autorité (alias bâton) à exactement 1 UTXO. Cela rend possible un jeton soutenu par BCH. Alors que le témoin serait verrouillé dans l’alliance (P2SH), notez que les jetons eux-mêmes seraient des citoyens P2PKH gratuits et utiliseraient des adresses BCH « normales » ! Peut-être qu’un pont SmartBCH simple pourrait également être créé de cette façon ! L’ajout d’un peu plus de contenu genesis TX à la pré-image tokenID pourrait permettre à une autorité de jeton de prouver qu’il a été créé par l’autorité d’un autre jeton.
Modèle d’engagement de script utilisant l’introspection et l’autorité du jeton de groupe
L’exemple ci-dessous nécessite CHIP-2021-02 : Native Introspection Opcodes.
Il suppose également que les opcodes d’introspection pour la lecture des annotations de groupe seront ajoutés :
Rappelez-vous qu’à la genèse de tout token, un tokenID unique est généré en hachant une pré-image composée de :
li comment= »_ »>L’indice de vout de la sortie Genesis en cours de génération ;
avec tokenID omis ;
Rappelons que le consensus impose également que :
li comment= »_ »>La sortie de genèse doit être de type jeton d’autorité ;
elle peut créer n’importe quel nombre de sorties de jeton ordinaires, mais une seule sortie d’autorité.
En raison des règles de consensus placées sur les autorités des jetons, il en faut très peu pour prouver qu’un pubKeyScript défini à la genèse n’a pas pu être modifié depuis la genèse.
Échanger le script :
.
. avec le même tokenID que moi.
mon pubKeyScript.
.doit être le même que celui défini sur la genèse de mon token.
. // toute autre condition.
Écriture de signature :
Ce contrat « header » prouve la rigidité du contrat, et est de taille fixe (24 opcodes + signature). Toute autre fonctionnalité de contrat intelligent (comme un contrat pour contrôler le ratio BCH/jeton, ou simplement le solde BCH de la sortie d’autorité pour un coffre-fort BCH intelligent) peut être ajoutée par dessus.
Approche PMv3
Voici la clé pour le comprendre :
« Les preuves détachées permettent de fournir le bytecode de déverrouillage d’une entrée particulière sous forme de hachage dans la pré-image de hachage de transaction (calcul TXID/Outpoint Transaction Hash). »
Il compresse les scripts de signature de la pré-image TXID car les scripts de signature cessent d’en faire partie, seul leur hachage sera là. Cela permettra au prochain TX de reconstruire l’ensemble du TX parent et de vérifier par rapport au TXID du précédent. Étant donné que le TXID du grand-parent fait partie de la pré-image, une reconstruction réussie prouvera quel TXID était le grand-parent. Pour que la reconstruction soit petite, elle doit être conçue pour être petite : toutes les entrées doivent être petites ou utiliser des preuves détachées, et les sorties sont accessibles à partir de la portée locale. Avec cette approche, il n’y a pas d’autre choix que d’introduire un nouveau format TX, car pour le moment, il n’y a pas de place pour cacher le script de signature où il ne sera pas haché pour le TXID.
