Article réimprimé de : Communauté chinoise Runes
Alors que BTCFi connaît une croissance fulgurante, Omnity a lancé un tout nouveau protocole d'extension de programmabilité Bitcoin de couche 1, REE. Avec des années d'accumulation d'expérience en interopérabilité cross-chain (Omnity Hub), Omnity est devenu l'un des acteurs les plus importants et les plus innovants dans le domaine BTCFi.
Site officiel : https://www.omnity.network/
À mon avis, Omnity Network explore une solution technique efficace, hautement combinable et très tolérante aux pannes pour « l'extensibilité et l'amélioration de la programmabilité » de l'écosystème Bitcoin :
1. Pour des scénarios de trading à haute fréquence, via un schéma de cross-chain d'actifs Bitcoin de niveau sans confiance, Omnity Hub, se diriger vers des chaînes de contrats intelligents à haute vitesse comme Bitlayer, Solana, Base, etc.
2. Pour les scénarios de gros fonds et une fréquence normale de transactions DeFi, il est donc préférable d'utiliser REE pour construire directement sur Bitcoin Layer 1.
Hub et REE sont indépendants, possédant une combinabilité flexible, ce qui constitue une base solide pour l'innovation des développeurs, en espérant que des innovations disruptives apparaîtront dans le domaine BTCFi !
Les personnes intéressées peuvent d'abord lire cet article, pour voir l'original en anglais, veuillez consulter le lien ci-dessous ⬇️
Livre blanc REE : https://x.com/louisliubj/status/1861588938475086166
Voici la version traduite en chinois, Enjoy~
REE : couche d'exécution Bitcoin sans cross-chain, Turing-complete
REE introduit une couche d'exécution Bitcoin décentralisée, permettant aux applications BTCFi d'activer des contrats intelligents Turing-complets. Sans nécessiter d'actifs cross-chain, REE améliore la programmabilité sur le réseau principal Bitcoin tout en préservant l'expérience utilisateur native de Bitcoin.
Qu'est-ce que REE ?
L'environnement d'échange Runes (REE) est une couche d'exécution décentralisée pour Bitcoin, permettant des contrats intelligents combinables sans besoin d'actifs cross-chain pour Bitcoin Layer 1 (Bitcoin L1). REE renforce le mécanisme des transactions multi-signatures de Bitcoin en participant directement aux transactions du réseau principal Bitcoin via des contrats intelligents sur une couche d'exécution décentralisée.
Figure 0. Transactions multi-signatures Bitcoin
Les transactions multi-signatures sont des transactions Bitcoin qui contiennent les entrées de plusieurs participants, une technique utilisée dans l'écosystème Bitcoin depuis des années. En général, un participant agit comme coordinateur, utilisant PSBT (Partially Signed Bitcoin Transaction) pour agréger les signatures de chaque partie, puis diffuse la transaction sur le réseau Bitcoin. Quelques exemples notables d'utilisation des transactions multi-signatures incluent CoinJoin, les portefeuilles multi-signatures et les custodians.
Dans un scénario multi-signatures, les participants peuvent être des programmes en plus des humains. Dans un environnement DeFi, les traders échangent généralement avec des protocoles (contrats intelligents) en tant que contreparties. L'idée de REE est d'impliquer les protocoles BTCFi dans des transactions multi-signatures Bitcoin et de déplacer l'ensemble du processus de signature sur une blockchain publique pour réaliser une décentralisation.
Figure 1. Coordination multi-signatures décentralisées (DMSC)
La figure 1 montre le processus général de coordination multi-signatures décentralisées (DMSC). Ce paramètre implique un trader, plusieurs protocoles BTCFi (A, B et C) et un coordinateur sur une blockchain publique. Le coordinateur agrège les signatures et diffuse la transaction finale.
Le processus DMSC est le suivant :
1. Phase de négociation
Le trader lance une transaction en négociant les termes avec plusieurs protocoles. Chaque protocole représente une entité détenant des actifs Bitcoin et prête à effectuer une transaction selon des règles spécifiques. Des exemples de protocoles incluent des échanges décentralisés, des protocoles de prêt, des stablecoins, etc.
2. Phase de signature
Après les négociations, construire un PSBT pour refléter la transaction. Le coordinateur appelle ensuite chaque protocole pour signer le PSBT. Chaque protocole (A, B et C) vérifie sa partie de la transaction et approuve son inclusion par signature.
3. Phase de diffusion
Une fois que le PSBT est entièrement signé, le coordinateur le convertit en transaction Bitcoin et le diffuse sur le réseau. Par conséquent, la transaction est finalisée sur Bitcoin.
REE choisit ICP (Internet Computer Protocol) comme blockchain publique pour DMSC. En d'autres termes, REE est l'infrastructure Bitcoin DMSC sur ICP.
Pourquoi REE ?
Bitcoin est la blockchain la plus sécurisée et la plus décentralisée au monde, mais sa programmabilité limitée limite son utilisation dans des applications financières complexes. REE complémente les solutions Bitcoin L2 existantes en offrant une programmabilité avancée et des contrats intelligents Turing-complets, tout en restant en auto-gestion et en minimisant les hypothèses de confiance.
Figure 2. REE n'est pas Bitcoin L2.
Contrairement à la plupart des L2, les contrats intelligents REE interagissent directement avec le modèle UTXO de Bitcoin, réalisant une programmabilité avancée tout en maintenant l'auto-gestion. Les traders n'ont pas besoin de verrouiller leurs actifs Bitcoin sur un pont inter-chaînes. Ils interagissent avec les contrats intelligents en signant le PSBT avec leur portefeuille Bitcoin, et finalisent instantanément le règlement des transactions sur Bitcoin.
D'un autre côté, parmi les solutions d'amélioration de la programmabilité Bitcoin L1 connues, DMSC présente des avantages significatifs par rapport aux autres solutions. Elle utilise des blockchains publiques modernes pour améliorer la programmabilité de Bitcoin, au lieu de dépendre de nouveaux codes OP. De plus, DMSC peut être compatible avec tous les actifs des protocoles de métadonnées basés sur UTXO, sans nécessiter de mise à niveau des métadonnées et des indexeurs.
Tableau 1. Comparaison des solutions techniques de programmabilité Bitcoin L1.
Enfin, ICP pourrait être la blockchain la plus appropriée pour DMSC. REE utilise la technologie Chain Fusion d'ICP pour gérer de manière sécurisée les clés privées et les signatures Bitcoin, tout en activant DMSC tout en maintenant le modèle de sécurité de Bitcoin. Grâce à l'intégration native de Bitcoin d'ICP et à l'indexeur on-chain, REE est compatible avec Runes (le protocole de métadonnées Bitcoin basé sur UTXO le plus largement accepté) de manière minimale en termes de confiance.
Comment fonctionne REE ?
Influencés par Ethereum, la grande majorité des plateformes de contrats intelligents ont un modèle d'état basé sur les comptes, ce qui a également influencé la façon de penser des développeurs de contrats intelligents. Cependant, l'état on-chain de Bitcoin est basé sur UTXO. REE introduit un modèle Exchange-Pool pour combler les différences. Le modèle Exchange-Pool s'adapte à la gestion d'état UTXO de Bitcoin et peut être facilement réalisé sur une chaîne publique basée sur des comptes comme ICP. Ce modèle se compose de trois concepts simples :
1. Coin est l'unité d'actifs Bitcoin basée sur UTXO. BTC et Runes sont acceptés comme Coin dans REE.
2. L'Exchange est une instance de protocole BTCFi fonctionnant sur la plateforme REE, utilisée pour faciliter les échanges de Coin.
3. Le pool de fonds est la clé publique (Chain Key) utilisée par l'Exchange pour détenir des Coins et signer des transactions Bitcoin. Selon la logique de l'Exchange, l'utilisateur dépose un sac de Coins dans le pool et en retire un autre sac de Coins. En général, un Exchange gère plusieurs pools, chaque pool étant destiné à des données de Coins et d'état.
Les constructeurs Bitcoin peuvent maintenant créer des protocoles BTCFi diversifiés avec l'Exchange de REE, réalisant plusieurs méthodes publiques pour les contrats intelligents ICP.
Figure 3. Architecture REE
La figure 3 montre le processus de réalisation d'une transaction Bitcoin sur REE, impliquant plusieurs composants comme deux Exchanges, le coordinateur REE et l'interface frontale. Voici la décomposition pas à pas du processus :
1. Demande de prix : le trader lance le processus via l'interface frontale pour demander un prix de transaction. Cela peut impliquer de choisir le type de transaction ou d'opération qu'il souhaite exécuter, comme échanger sur ExchangeA puis miser sur ExchangeB.
2. Construction du PSBT : une fois que le trader accepte les conditions de la transaction, le front-end construit le PSBT avec l'aide du SDK Typescript REE.
3. Le trader signe le PSBT : le trader examine et signe le PSBT avec son portefeuille Bitcoin, approuvant essentiellement que la transaction soit traitée par la suite.
4. Appel au coordinateur : le front-end envoie le PSBT au coordinateur REE. Le coordinateur REE agit en tant que coordinateur, supervisant l'exécution des transactions.
5. Vérification des entrées : avant que le coordinateur n'exécute la transaction REE, toutes les entrées PSBT doivent être vérifiées pour s'assurer qu'elles sont dépensables et qu'elles contiennent effectivement les actifs qu'elles prétendent contenir. Le coordinateur dépend du Canister Ord (indexeur on-chain Runes) pour accomplir cela.
6. L'Exchange signe le PSBT : après vérification, le coordinateur REE communique avec l'Exchange concerné pour signer le PSBT. L'Exchange vérifie que les données PSBT répondent à ses conditions de transaction et signe un par un.
7. Diffusion de la transaction : une fois que tous les Exchanges concernés ont signé le PSBT, le coordinateur REE diffuse la transaction entièrement signée sur le réseau Bitcoin. La transaction est ensuite confirmée sur la blockchain Bitcoin, complétant tout le processus.
Le coordinateur REE est responsable de la garantie de la cohérence de l'état, en notifiant l'Exchange de revenir à l'état si un Exchange refuse de signer.
Avant que quiconque n'utilise l'Exchange, il doit être initialisé par son constructeur :
1. Déploiement (étape 0.1) : le constructeur déploie le canister d'Exchange sur le même sous-réseau ICP que le coordinateur REE. Bien que le canister puisse être appelé entre sous-réseaux, cela entraînera des délais inutiles.
2. Inscription (étape 0.2) : le constructeur s'inscrit auprès du coordinateur REE pour l'Exchange.
Les constructeurs d'Exchange sont responsables de la maintenance de l'Exchange, y compris des mises à niveau et de la recharge des cycles pour le faire fonctionner. Omnity fournira aux constructeurs d'Exchange des installations génériques pour faciliter leur utilisation, mais tout cela est optionnel et remplaçable.
Caractéristiques du système
Programmabilité
REE Exchange est un contrat intelligent ICP indépendant qui peut tirer pleinement parti des fonctionnalités de la blockchain sous-jacente. Il est conseillé aux lecteurs de consulter la documentation technique d'ICP pour plus d'informations sur le développement de contrats intelligents ICP.
Documentation technique ICP :
https://internetcomputer.org/docs/current/home
Voici quelques conseils :
1. Les calculs intensifs comme la reconnaissance faciale peuvent être réalisés dans des contrats intelligents ICP :
https://medium.com/dfinity/the-next-step-for-deai-on-chain-inference-enabling-face-recognition-589183203fc2
2. Le conteneur Bitcoin d'ICP pourrait être le plus grand contrat intelligent au monde, occupant 500 Go de stockage on-chain, pour un coût annuel de seulement 2500 dollars.
https://github.com/dfinity/bitcoin-canister
3. Omnity Hub est une pile d'interopérabilité entièrement on-chain sur ICP, ce qui signifie qu'il n'est pas nécessaire d'avoir des relais ou des indexeurs hors chaîne. Omnity Hub se connecte directement à des dizaines de blockchains hétérogènes via une interface RPC.
https://explorer.omnity.network/
Combinabilité
La combinabilité des contrats intelligents REE assure une intégration transparente entre protocoles, en réalisant des protocoles financiers innovants en combinant liquidités et unités logiques dans un cadre de confiance minimale.
REE fournit une combinabilité de style Bitcoin. Chaque exchange ne se soucie que de ce qu'il reçoit (entrée) et de ce qu'il fournit (sortie) ; tant que l'entrée/sortie est raisonnable, il accepte de participer à la transaction. Les transactions REE peuvent impliquer plusieurs exchanges, chaque exchange recevant et contribuant certaines pièces. Avec la coopération des exchanges, le coordinateur est responsable de garantir l'atomicité des transactions multi-signatures. L'atomicité combinable signifie que les transactions multi-signatures réussissent complètement ou sont entièrement annulées en cas d'échec d'une partie. Cela est crucial dans les applications DeFi.
En général, le trader fournit l'entrée initiale au premier exchange ; la sortie du premier exchange entre dans le deuxième exchange, et cela continue jusqu'à ce que la sortie finale du dernier exchange soit donnée au trader. L'ordre de signature du PSBT suit cette logique : le premier exchange n'acceptera de fournir son entrée et signer le PSBT que si le trader a déjà signé ses entrées, et ainsi de suite.
Conceptuellement, la combinabilité des exchanges ressemble à des commandes Unix pipelinées. Cependant, ce n'est pas seulement cela. Toute entité (trader ou exchange) peut fournir des entrées à d'autres entités sans tenir compte de l'ordre. Par exemple, l'entrée du trader donnée au deuxième exchange ou à un exchange ultérieur ; l'exchange fournit à la place le coût initial et les frais de réseau Bitcoin.
De plus, le trader n'est pas nécessairement une personne ; cela peut être un processus hors chaîne ou un contrat intelligent ICP. Cela ouvre la possibilité d'agrégateurs de revenus on-chain ou hors chaîne ou de robots d'arbitrage. Grâce à la puissante pile Chain Fusion, REEExchange peut interagir avec d'autres blockchains. Par exemple, les changements d'état sur Ethereum ou Solana peuvent déclencher des transactions REE, et vice versa.
Profil de risque
Le destinataire (trader traitant avec le pool de fonds) examine le PSBT contenant tous les termes de la transaction avant de signer, ces termes étant représentés par les entrées et les sorties. Une fois signé, personne, y compris le trader lui-même, l'exchange, REE, les nœuds ICP et les mineurs de Bitcoin, ne peut modifier la transaction. En d'autres termes, le destinataire n'assume aucun risque de garde.
En général, l'exécution de chaque transaction REE entraîne un changement d'état du pool de fonds spécifique, ce qui rend les termes de transaction obtenus d'une requête antérieure obsolètes. Étant donné que le délai d'exécution des transactions REE (en secondes) est bien inférieur à celui de Bitcoin (en minutes), les transactions REE sont généralement traitées de manière séquentielle. Cependant, des échecs de transactions peuvent survenir lorsque plusieurs traders échangent simultanément avec le même pool de fonds.
L'échec d'une transaction ne conduit pas à une perte d'actifs ; le trader doit simplement reconsulter et tenter de l'exécuter à nouveau.
Les teneurs de marché (traders fournissant de la liquidité au pool de fonds) assument des risques de garde lorsqu'ils transfèrent le contrôle des actifs à l'exchange. Par conséquent, ils sont confrontés à des risques de contrats intelligents liés à la logique de l'Exchange, ce qui souligne l'importance des audits et de la réputation des constructeurs d'Exchange.
Les hypothèses de sécurité des teneurs de marché incluent les plateformes ICP et REE. Cependant, la sécurité d'ICP (valeur de plusieurs milliards de dollars) satisfait aux exigences de sécurité des protocoles BTCFi dans toutes les situations connues.
Cohérence des états Bitcoin
Les limites du script Bitcoin dans le soutien à BTCFi ne sont pas seulement dues aux limitations fonctionnelles des codes d'opération, mais en grande partie parce qu'ils ne peuvent pas maintenir un état on-chain complexe. En revanche, les exchanges dans REE peuvent maintenir et gérer l'état de manière pratique. Cependant, l'état de l'exchange REE doit finalement être en phase avec Bitcoin ; sinon, les transactions REE ne pourront pas être réglées sur Bitcoin.
Pour éviter les échecs de règlement, le coordinateur vérifie que toutes les entrées de transaction n'ont pas encore été dépensées. Chaque exchange vérifie également que les entrées et sorties de transaction répondent à ses normes. Cette approche garantit que seules des entrées valides et vérifiées sont utilisées pour régler les transactions.
Cependant, même si ces entrées sont vérifiées avant l'exécution de la transaction, il n'y a aucune garantie de règlement par la suite. Les traders peuvent intentionnellement ou non utiliser les mêmes entrées pour une autre transaction Bitcoin.
REE doit percevoir les changements en temps réel dans le réseau Bitcoin et réagir en conséquence. Avec le soutien de l'intégration native de Bitcoin et de l'indexeur on-chain Runes, REE pourrait être le seul niveau d'exécution Bitcoin à réaliser cet objectif sans dépendre de processus centralisés hors chaîne.
Figure 4. État des transactions REE
Le coordinateur REE est le composant qui gère le cycle de vie de toutes les transactions REE. Il est responsable de la notification des événements de changement d'état liés à l'Exchange.
Figure 5. Gestion des états du pool de fonds
Les Exchanges gèrent l'état basé sur des pools de fonds. Plus précisément, l'état du pool de fonds doit être organisé en une chaîne d'état liée à une série de transactions exécutées sur ce pool de fonds. Le pool de fonds traite toujours les requêtes de consultation et exécute de nouvelles transactions en fonction du sommet de la chaîne d'état. En fonction des notifications d'événements provenant du coordinateur, le pool de fonds exécute des confirmations ou des retours en arrière.
De plus, compte tenu de la forte volatilité des frais du réseau Bitcoin, il n'existe pas de moyen économiquement viable de garantir qu'une transaction soit incluse dans un bloc dans un cadre temporel spécifique. En cas d'envolée des frais du réseau Bitcoin, il existe deux méthodes pour accélérer les règlements : RBF (Replace-By-Fee) et CPFP (Child Pays for Parent). RBF nécessite de reconstruire la transaction, ce qui peut entraîner une mauvaise expérience utilisateur.
REE utilise CPFP, ce qui signifie que lorsque les frais du réseau Bitcoin augmentent, les transactions suivantes doivent subventionner les transactions précédentes non incluses dans le bloc sur le même pool de fonds. La subvention des frais reste un mécanisme de marché libre : seuls les traders s'attendant à ce qu'il y ait encore un bénéfice malgré l'augmentation des coûts lanceront des transactions suivantes.
Performance
Les performances de la couche d'exécution sont généralement mesurées par deux indicateurs : le débit (en TPS) et la latence. Sur REE, les traders peuvent exécuter des transactions successivement avec une latence de seulement quelques secondes, sans avoir à attendre la confirmation des blocs pour passer à l'étape suivante. En termes de latence, REE améliore la performance de Bitcoin d'un facteur de 100.
Les transactions en série de REE seront réglées par lots sur la chaîne Bitcoin. Comme une transaction dans le pool de mémoire peut avoir jusqu'à 25 transactions suivantes, chaque bloc Bitcoin peut régler jusqu'à 25 transactions pour un seul pool de transactions REE. Ainsi, 25 peut être considéré comme la limite de capacité pour un seul pool de transactions REE.
Différents pools de transactions peuvent permettre une exécution parallèle des transactions. Lorsque la concurrence sur les prix n'est pas nécessaire, les constructeurs d'Exchange peuvent ajouter des pools redondants pour améliorer la simultanéité. Par exemple, répartir des jetons dans 10 pools pour un airdrop ayant 100 000 bénéficiaires peut réduire considérablement le risque d'échec des transactions dû à plusieurs utilisateurs réclamant en même temps.
Dans un seul pool de transactions, la concurrence au sein du pool peut être réalisée en gérant plusieurs UTXO détenant le même type de pièces. Cependant, cela nécessite des algorithmes de sélection, de division et de fusion des UTXO plus complexes. Les futurs Exchanges pourraient explorer ces technologies avancées pour offrir une meilleure expérience utilisateur.
Coût
Les principaux coûts des transactions REE pour les utilisateurs proviennent des frais du réseau Bitcoin. REE minimise la taille des transactions de règlement en utilisant le type d'adresse P2TR.
Les constructeurs assument les coûts d'exploitation de l'Exchange sur ICP (cycles). Bien qu'ICP soit très rentable, les constructeurs doivent générer des revenus à l'intérieur ou à l'extérieur du protocole pour assurer la durabilité économique de leur Exchange.
MEV
REE est une couche d'exécution qui confie le tri des transactions au sous-réseau ICP où se trouve le coordinateur. Bien qu'il soit théoriquement possible, les cas où les nœuds du sous-réseau ICP extraient le MEV en réorganisant les transactions sont inconnus.
Plus important encore, il n'y a pas de concept de glissement sur REE ; lorsque le trader signe PSBT, toutes les entrées et sorties de la transaction sont déjà définies. Si l'entrée provenant du pool de fonds de l'Exchange a été dépensée, la transaction échouera. Par conséquent, si une transaction REE est exécutée en avance, elle échouera automatiquement, laissant l'exécutant assumer seul le risque de prix.
Gouvernance
REE sera géré par Omnity SNS DAO, responsable de la supervision des mises à jour de protocole, des ajustements de paramètres et de la feuille de route de développement. La gouvernance on-chain de SNS assure la transparence du développement durable de l'écosystème REE et une prise de décision communautaire.
Cas d'utilisation
Dupliquer les protocoles DeFi d'Ethereum ou de Solana sur Bitcoin est un moyen direct d'exploiter REE. Voici quelques exemples détaillés.
AMM DEX (échange décentralisé à teneur automatique)
RichSwap, un AMM DEX construit par Omnity, sera lancé simultanément avec le mainnet REE. En tant que premier échange sur REE, RichSwap sert les objectifs suivants :
1. RichSwap vérifie la fonctionnalité et la performance de la plateforme REE.
2. RichSwap est open-source, fournissant des exemples complets pour les constructeurs BTCFi.
3. D'autres protocoles BTCFi peuvent utiliser RichSwap pour accélérer le bootstrap de liquidité.
4. RichSwap intègre un mécanisme de capture de valeur de jeton, que d'autres protocoles BTCFi peuvent utiliser.
Bien que RichSwap soit le premier échange, il ne bénéficie d'aucun privilège. Après le lancement de la mainnet, REE passera rapidement à une plateforme ouverte, acceptant l'enregistrement sans autorisation de tout protocole BTCFi conforme aux spécifications techniques (y compris AMM DEX).
Prêt
Les protocoles de prêt basés sur REE peuvent prendre en charge plusieurs pools de fonds, chaque pool ayant différentes configurations, paramètres de risque et types d'actifs soutenus. Chaque pool soutenu par des Runes blue-chip pour emprunter des BTC pourrait avoir différents taux d'intérêt, ratios de garantie et seuils de liquidation. Il peut choisir de retourner un atoken aux fournisseurs de liquidité (LPs). En intégrant avec des oracles sur ICP, le protocole de prêt peut déterminer décentralisé la valeur des garanties ou déclencher le processus de liquidation.
Jetons de staking de liquidité
Il est possible de mettre en œuvre le staking Bitcoin L1 sur REE, mais l'intégration des protocoles de staking existants (comme Babylon) est une possibilité plus intéressante. Les utilisateurs déposent des Bitcoins dans l'Exchange et reçoivent LST au format Runes. Ensuite, LSTExchange est combiné avec le protocole de staking Babylon sur Bitcoin L1, tout en gérant de manière non fiable les délégations et les récompenses de staking sur la chaîne Babylon via un protocole inter-chaînes sans confiance. Omnity Hub a déjà été intégré à Osmosis grâce à une architecture entièrement on-chain et une vérification légère des clients. Par conséquent, l'interaction entre les contrats intelligents ICP et les chaînes d'applications Cosmos ne rencontre plus d'obstacles techniques.
Feuille de route
1. Quatrième trimestre 2024, publication du livre blanc REE.
2. Premier trimestre 2025, lancement de la mainnet REE avec RichSwap.
3. Deuxième trimestre 2025, ouverture des inscriptions d'Exchange aux partenaires Omnity.
4. Deuxième semestre 2025, ouverture complète des inscriptions d'Exchange
Conclusion
REE représente une percée en matière de programmabilité de Bitcoin, réalisant des contrats intelligents sécurisés et Turing-complets sans dépendre d'actifs cross-chain ou de forks. Ce modèle d'exécution sans cross-chain a le potentiel de favoriser un écosystème BTCFi exploitant la liquidité et la sécurité de Bitcoin dans un environnement entièrement sans confiance et sans autorisation.
