Hashi teste 25 institutions sur « BTC ne quitte pas le réseau principal » : où doit-on écrire la programmabilité ? TBC a donné une autre réponse

Le marché passe de « faut-il être programmable » à « où doit-on écrire la programmabilité ?

Rédigé par : utxo_compiler

Le testnet de Hashi sur Sui est en ligne, avec plus de 25 institutions participant aux tests de pression, l'objectif étant de permettre à BTC de rester sur le réseau Bitcoin tout en participant à DeFi. Ce n'est pas un autre pont emballé. C'est la première reconnaissance à grande échelle dans l'industrie : emballer BTC sur d'autres chaînes pour faire DeFi n'est plus la réponse privilégiée par les institutions. Mais la question est passée de « faut-il être programmable » à « où doit-on écrire la programmabilité ?

I. Des milliards de BTC endormis et des fissures de confiance

La capitalisation boursière de Bitcoin dépasse 1 trillion de dollars. Les ETF au comptant et les stratégies de coffre-fort ont fait grimper les positions des institutions, mais la grande majorité des BTC reste « endormie ». Ce n'est pas que les institutions ne veulent pas utiliser, mais qu'elles n'ont pas trouvé de moyen sûr.

wBTC et cbBTC ont résolu le « pouvoir utiliser », mais au prix des risques de pont et de garde. Les utilisateurs échangent BTC contre des actifs emballés, faisant confiance à un gardien centralisé, et les actifs quittent le réseau principal Bitcoin. Ce n'est pas la finance native de Bitcoin, c'est « la finance d'une autre chaîne empruntant le nom de Bitcoin ».

Le progrès de Hashi réside dans le fait que lorsque les utilisateurs déposent BTC, les fonds entrent dans une adresse Bitcoin multisignature 2-of-2 générée pour ce compte, les BTC sous-jacents ne quittent pas le réseau Bitcoin. Le comité de validateurs de Hashi (MPC) et la couche Guardian détiennent chacun une signature, aucune des parties ne peut déplacer les BTC seule. La couche Guardian peut également configurer des protections, les dépôts ou retraits importants ou suspects peuvent être ralentis ou interceptés.

Cela résout le problème de la « sécurité des actifs ». Mais qu'en est-il de la programmabilité ? Les actifs sont dans le multisig Bitcoin, la logique programmable s'exécute sur Sui. Cela signifie que les utilisateurs font confiance à deux systèmes simultanément : la sécurité du multisig Bitcoin et l'environnement d'exécution de Sui. Le coût de confiance et de coordination des deux systèmes est une nouvelle fissure de confiance.

Un ensemble de données peut illustrer le problème : la date de lancement du mainnet de Hashi n'a pas encore été annoncée, il est actuellement en période de test de pression. Sur le marché, il y a plus de 75 projets L2 qui répondent à la même question : comment transformer le BTC inutilisé en une base financière programmable. Mais la plupart des solutions séparent les actifs et la programmabilité sur deux chaînes différentes.

II. Le véritable goulet d'étranglement n'est pas le slogan de vitesse, mais si les actifs et les contrats sont isomorphes au UTXO

Les projets SVM sur Bitcoin L2 crient « vitesse sub-seconde ». Le PoX-5 de Stacks promeut « auto-gardé, rendement basé sur BTC ». Ces directions ont chacune de la valeur, mais ne peuvent pas contourner le même problème structurel : les actifs sont dans le modèle UTXO, les contrats intelligents dans le modèle de compte.

Ce n'est pas un détail technique. C'est une divergence architecturale fondamentale.

L'avantage du modèle UTXO réside dans la parallélisation et la décentralisation. Chaque transaction est indépendante, ne dépend pas de l'état global, soutient naturellement une haute concurrence. Mais le prix à payer est : la capacité d'expression des scripts UTXO traditionnels est limitée, incapable de réaliser des logiques commerciales complexes.

Le modèle de compte (EVM) a l'avantage de l'expressivité des contrats intelligents. Les développeurs peuvent facilement réaliser DeFi, NFT, protocoles de prêt. Mais le prix à payer est : la concurrence sur l'état global ralentit la vitesse des transactions, les frais de Gas explosent aux heures de pointe.

La plupart des projets choisissent de « relier » les deux mondes : les actifs restent sur la chaîne UTXO, les contrats fonctionnent sur la chaîne du modèle de compte. Cela a engendré de nouveaux problèmes :

• Risque de pont : les actifs inter-chaînes nécessitent de faire confiance au mécanisme de validation du pont
• Risque d'exécution : le résultat de l'exécution du contrat doit être renvoyé à la chaîne où se trouvent les actifs
• Coût de coordination : le consensus, le temps de confirmation et le mécanisme de retour en arrière des deux chaînes sont différents

Hashi garde les actifs dans le multisig Bitcoin, les contrats sur Sui. SVM L2 fait passer les actifs dans L2, les contrats dans la machine virtuelle Solana. Stacks utilise PoX pour staker BTC sur la chaîne Stacks. Chaque voie travaille sur « l'emballage » ou « le pont », personne ne touche au modèle UTXO lui-même.

III. Le chemin de TBC : écrire la complétude de Turing directement dans le UTXO lui-même

TuringBitChain (TBC) a choisi un autre chemin : ne pas séparer les actifs et les contrats, mais écrire directement des contrats intelligents Turing-complets dans le modèle UTXO.

Ce n'est pas un L2. C'est à partir du protocole original de Bitcoin, réaliser des contrats intelligents UTXO Turing-complets sur Layer-1. La différence fondamentale réside dans trois éléments :

OP_PUSH_META permet au script de « voir » pour la première fois lui-même. Le script peut lire les métadonnées internes de la transaction : version, temps de verrouillage, quantité d'entrées et de sorties, empreintes de hachage des transactions en amont et en aval. Cela signifie que le script peut répondre à « d'où je viens, où je vais ».

OP_PARTIAL_HASH permet au script de « vérifier » lui-même. Le script peut recalculer le hachage par segments sur un flux de données de longueur arbitraire dans un espace de pile limité. Ce n'est pas « je crois que le hachage est vrai », mais « j'ai calculé moi-même segment par segment ».

Le TXID hiérarchique permet l'auto-réflexion et l'auto-preuve à un coût constant entre les générations. Chaque génération n'a besoin d'hériter de l'empreinte TXID de son ancêtre, cette empreinte de 32 octets, indépendamment de la quantité de données transportées et de la profondeur. C'est un « contrat héréditaire » sous le modèle UTXO.

Ces trois éléments résolvent ensemble le problème : ne pas dépendre de l'état global, réaliser un niveau d'expression de contrat équivalent à l'EVM.

Les données de performance peuvent corroborer la faisabilité du chemin : le TPS du mainnet TBC a déjà dépassé 13 000, la limite de bloc initiale est de 4 Go, les frais diminuent avec l'augmentation des utilisateurs. Cela contraste avec le dilemme des blockchains traditionnelles où « plus il y a d'utilisateurs, plus les frais sont élevés ».

Bien sûr, ce chemin a aussi un coût. L'écosystème des applications TBC est encore à un stade précoce. Hashi a publié une liste de plus de 25 partenaires institutionnels, y compris BitGo, Cumberland, la banque agréée OCC Erebor, et le conseiller enregistré de la SEC Wave Digital Assets - la maturité de ces produits conformes et de la chaîne d'outils institutionnels ne peut actuellement pas être égalée par TBC. Le coût d'apprentissage pour les développeurs UTXO est réel, les développeurs habitués à l'EVM doivent s'adapter à un nouveau paradigme de contrat. La montée en température de la compétition signifie une intensification de la concurrence, TBC doit rapidement combler les lacunes de l'écosystème et de la couche d'application.

IV. Quand « ne pas quitter le réseau Bitcoin » devient un consensus, quelle est la prochaine étape ?

Le lancement de Hashi est un signal : le marché passe de « faut-il être programmable » à « où doit-on écrire la programmabilité ? ». Les institutions ne se contentent plus d'emballer des actifs pour faire DeFi, elles veulent un point d'ancrage de sécurité natif BTC tout en ayant la flexibilité programmable.

La revendication de TBC est : les actifs et la logique des contrats ne devraient pas être séparés en deux chaînes. Écrire la complétude de Turing directement dans le UTXO lui-même, faire en sorte que la transaction elle-même devienne le support de l'état, l'état se transmette le long de la lignée UTXO. Ce n'est pas pour la démonstration technique, mais pour résoudre un problème pratique : lorsque BTC devient un collatéral DeFi, chaque exécution de contrat de prêt, de liquidation, de mise en gage devrait se faire dans le même modèle de sécurité que les actifs.

À l'avenir, si BTC devient vraiment la base financière programmable, le marché posera la question : où écrivez-vous votre programmabilité ? Est-ce écrit dans une VM externe ou dans le UTXO lui-même ?

Les 25 institutions de Hashi testent la faisabilité de « ne pas quitter le réseau Bitcoin ». TBC teste la programmabilité de « ne pas quitter le modèle UTXO ». Les deux voies répondent à la même question, mais la profondeur des réponses est différente.

Les 25 institutions testent la sécurité des actifs. Le véritable test est : lorsque la logique des contrats et la sécurité des actifs doivent être réalisées sur la même chaîne, quel chemin peut réussir.