Bitcoin confirme propriété et ordre des UTXO anchor, tandis que l’historique, les witness data et les proofs sont transmis hors blockchain au destinataire, qui valide toute la filiation depuis le genesis point.
Taproot Assets, d’abord annoncé sous le nom Taro, utilise une sortie Taproot comme anchor Bitcoin des commitments d’actifs. Les règles complètes et witness data de l’actif ne constituent pas un état global Bitcoin ; les participants les conservent et les valident. [1]
L’émission crée une minting transaction ; l’outpoint qu’elle consomme devient le genesis point et une partie de l’identité unique. Lors d’un transfert, le witness antérieur est recommité dans une ou plusieurs sorties Taproot et le proof nécessaire est remis au destinataire. [2]
Un Sparse Merkle Tree fournit des preuves sélectives de branches d’actifs dans une sortie et un Merkle-Sum Tree vérifie la conservation des quantités. Un UTXO Bitcoin peut engager plusieurs actifs sans que le full node connaisse leurs noms, soldes ou règles de transfert. [1]
Le destinataire valide la filiation depuis la sortie genesis contre les transactions Bitcoin. Un Universe peut indexer et distribuer proofs et metadata, sans rendre valide un actif invalide ; le client peut comparer ses données à un autre Universe ou à son propre stockage. [1]
Une adresse Taproot Assets contient asset ID ou group key, montant, clés et information de livraison du proof. Un group key peut désigner un groupe auquel l’émetteur ajoutera des émissions ; une offre fixe ou extensible doit donc être examinée pour l’actif précis. [3]
L’implémentation publique tapd prend en charge mainnet et la série actuelle v0.8.4, mais le dépôt la qualifie toujours de logiciel alpha. Des commandes ou un sélecteur mainnet ne garantissent donc ni sauvegardes complètes, ni compatibilité, ni sûreté en production. [5]
La restauration exige plus qu’un seed Bitcoin : tapd conserve un tweak et des données clientes nécessaires pour dépenser sûrement la sortie anchor et prouver l’historique. Perdre base ou proofs peut supprimer l’accès à l’actif et parfois menacer les bitcoins de la même sortie. [2]
Nom, ticker et metadata libres n’établissent pas la fiabilité économique. Avant acceptation, vérifier asset ID ou group key, genesis, proof complet, règles d’offre, contrôle de l’émetteur, état des transactions anchor et version exacte du client. [4]
Pour une vision complète, lisez aussi Taproot, Client-Side Validation, Lightning Network, UTXO, RGB Protocol, Hash. Cette entrée est également citée par Runes.
01Les full nodes Bitcoin valident-ils Taproot Assets ?+
Ils valident la transaction Taproot et la dépense de l’UTXO anchor, pas les règles, quantités ou l’historique de l’actif. Le destinataire les valide avec les proofs dans un client Taproot Assets.
02Un seed Bitcoin suffit-il pour restaurer Taproot Assets ?+
Non. L’implémentation officielle exige explicitement une sauvegarde des données tapd ; le seed lnd seul ne contient pas tous les tweaks, proofs et états clients nécessaires à une restauration sûre.