Avec l'essor du BTCFi, Omnity a lancé le tout nouveau protocole d'extension programmabilité Bitcoin L1 REE. Avec l'accumulation d'années de travail sur l'interopérabilité inter-chaînes (Omnity hub), Omnity est désormais l'un des acteurs les plus importants et les plus explorateurs 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'« évolutivité et l'amélioration de la programmabilité » de l'écosystème Bitcoin :
1. Pour les scénarios de trading à haute fréquence, via le niveau sans confiance des actifs Bitcoin à travers le hub Omnity, vers des chaînes de contrats intelligents à haute vitesse comme Bitlayer, Solana, Base qui ont une construction écosystémique plus solide ;
2. Pour les scénarios de gros volumes et des fréquences de transaction normales, le DeFi est construit directement sur Bitcoin L1 via REE.
Le Hub et REE sont indépendants, offrant une combinabilité flexible, jetant les bases d'une innovation disruptive attendue dans le domaine BTCFi !
Les personnes intéressées peuvent lire cet article pour commencer, pour la version anglaise, veuillez consulter le lien ci-dessous ⬇️
Livre blanc REE : https://x.com/louisliubj/status/1861588938475086166
Voici la version traduite en français, profitez-en～
REE : Couche d'exécution Bitcoin sans interopérabilité croisée et Turing-complete.
REE introduit une couche d'exécution Bitcoin décentralisée, permettant aux applications BTCFi d'utiliser des contrats intelligents Turing-complets. Sans interopérabilité d'actifs, REE améliore la programmabilité de la chaîne principale Bitcoin tout en conservant l'expérience utilisateur native de Bitcoin.
Qu'est-ce que REE ?
L'environnement d'échange de Runes (REE) est une couche d'exécution décentralisée pour Bitcoin, fournissant des contrats intelligents combinables pour Bitcoin L1 sans interopérabilité d'actifs. REE renforce le mécanisme des transactions à signature multiple de Bitcoin grâce à des contrats intelligents sur une couche d'exécution décentralisée, participant directement aux transactions sur la blockchain principale Bitcoin.
Figure 0. Transactions Bitcoin à signature multiple
Les transactions à signature multiple sont des transactions Bitcoin contenant les inputs de plusieurs participants, une technique utilisée dans l'écosystème Bitcoin depuis des années. En général, un participant agit en tant que coordinateur, utilisant PSBT (transaction Bitcoin partiellement signée) pour agréger les signatures de chaque partie, puis diffuse la transaction sur le réseau Bitcoin. Certains cas d'utilisation notables des transactions à signature multiple incluent CoinJoin, les portefeuilles à signatures multiples et les custodians.
Dans les scénarios de signature multiple, les participants peuvent être des programmes en plus des humains. Dans l'environnement DeFi, les traders négocient généralement avec le protocole (contrat intelligent) comme contrepartie. L'idée de REE est d'impliquer les protocoles BTCFi dans les transactions Bitcoin à signature multiple et de déplacer l'ensemble du processus de signature sur la blockchain publique, réalisant ainsi une décentralisation.
Figure 1. Coordination de signatures multiples décentralisée (DMSC)
La figure 1 montre le processus général de coordination multi-signatures décentralisée (DMSC). Ce dispositif implique un trader, plusieurs protocoles BTCFi (A, B et C) et un coordinateur sur la blockchain publique. Le coordinateur agrège les signatures et diffuse la transaction finale.
Le processus DMSC est le suivant :
1. Phase de négociation
Les traders initient des transactions en négociant les termes avec plusieurs protocoles. Chaque protocole représente une entité possédant des actifs Bitcoin et prête à échanger 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 négociation, 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 transaction et approuve son inclusion par une signature.
3. Phase de diffusion
Une fois le PSBT complètement signé, le coordinateur le convertit en transaction Bitcoin et la diffuse sur le réseau. Ainsi, la transaction est réglée sur Bitcoin.
REE choisit ICP (Internet Computer Protocol) comme blockchain publique pour DMSC. En d'autres termes, REE est l'infrastructure DMSC de Bitcoin sur ICP.
Pourquoi REE ?
Bitcoin est la blockchain la plus sécurisée et décentralisée au monde, mais sa programmabilité limitée limite son utilisation dans des applications financières complexes. REE complète les solutions Bitcoin L2 existantes en offrant une programmabilité avancée et des contrats intelligents Turing-complets tout en maintenant l'auto-garde et en minimisant les hypothèses de confiance.
Figure 2. REE n'est pas un 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-garde. Les traders n'ont pas besoin de verrouiller leurs actifs Bitcoin sur des ponts inter-chaînes. Ils interagissent avec les contrats intelligents en signant le PSBT avec leur portefeuille Bitcoin, complétant instantanément le règlement des transactions sur Bitcoin.
D'autre part, parmi les solutions connues d'amélioration de la programmabilité de Bitcoin L1, DMSC a un avantage significatif par rapport à d'autres solutions. Elle exploite des blockchains publiques modernes pour améliorer la programmabilité de Bitcoin, sans dépendre de nouveaux opcodes. De plus, DMSC peut être compatible avec tous les actifs de protocole UTXO sans nécessiter de mise à niveau des protocoles 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 en toute sécurité les clés privées et les signatures Bitcoin, permettant DMSC tout en maintenant le modèle de sécurité de Bitcoin. Grâce à l'intégration natale de Bitcoin d'ICP et à l'indexeur en chaîne, REE est compatible avec Runes (le protocole UTXO Bitcoin le plus largement accepté) d'une manière minimisant la confiance.
Comment fonctionne REE ?
Influencés par Ethereum, la plupart des plateformes de contrats intelligents ont un modèle d'état basé sur des comptes, ce qui influence également le mode de pensée des développeurs de contrats intelligents. Cependant, l'état on-chain de Bitcoin est basé sur UTXO. REE introduit le modèle Exchange-Pool pour combler cette différence. Le modèle Exchange-Pool s'adapte à la gestion de l'é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é des actifs Bitcoin basés sur UTXO. BTC et Runes sont acceptés en tant que Coin dans REE.
2. L'échange est une instance de protocole BTCFi fonctionnant sur la plateforme REE, facilitant l'échange de coins.
3. Le pool de fonds (pool) est utilisé par l'échange pour détenir les coins et signer les transactions Bitcoin avec une clé publique (clés de chaîne). Selon la logique de l'échange, les utilisateurs déposent un sac de coins dans le pool et reçoivent un autre sac de coins en retour. En général, un échange gère plusieurs pools, chacun ayant une logique pour les coins et les données d'état.
Les constructeurs de Bitcoin peuvent maintenant créer des protocoles BTCFi diversifiés avec l'échange REE - réalisant plusieurs méthodes publiques des contrats intelligents ICP.
Figure 3. Architecture REE
La figure 3 montre le processus de réalisation des transactions Bitcoin sur REE, impliquant plusieurs composants comme deux échanges, le coordinateur REE et l'interface frontale. Voici le décompte étape par étape du processus :
1. Demande de prix : Le trader initie le processus via l'interface frontale, demandant un prix pour la transaction. Cela peut impliquer de choisir le type de transaction ou d'opération qu'il souhaite exécuter, comme échanger sur ExchangeA puis staker sur ExchangeB.
2. Construction du PSBT : Une fois que le trader a accepté les termes de la transaction, l'interface frontale 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 la transaction pour un traitement ultérieur.
4. Appel à l'Orchestrateur : L'interface frontale envoie le PSBT à l'Orchestrateur REE. L'Orchestrateur REE agit en tant que coordinateur, supervisant l'exécution de la transaction.
5. Vérification des entrées : Avant d'exécuter les transactions REE, l'Orchestrateur doit vérifier toutes les entrées PSBT pour s'assurer qu'elles sont dépensables et contiennent réellement les actifs qu'elles prétendent avoir. L'Orchestrateur s'appuie sur Ord Canister (indexeur de Runes en chaîne) pour cela.
6. L'échange signe le PSBT : Après vérification, l'Orchestrateur REE communique avec l'échange concerné pour signer le PSBT. L'échange vérifie que les données du PSBT correspondent à ses conditions de transaction et signe l'un après l'autre.
7. Diffusion de la transaction : Après que tous les échanges concernés aient 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 l'ensemble du processus.
L'Orchestrateur REE est responsable de garantir la cohérence de l'état, en notifiant l'échange de revenir en arrière en cas de refus de signature par un échange.
Avant que quiconque n'utilise l'échange, il doit être initialisé par son constructeur :
1. Déploiement (étape 0.1) : Le constructeur déploie l'Exchangecanister sur le même sous-réseau ICP que l'Orchestrateur REE. Bien que le canister puisse appeler à travers les sous-réseaux, cela introduit des délais inutiles.
2. Inscription (étape 0.2) : le constructeur s'inscrit à l'échange auprès de l'Orchestrateur REE.
Les constructeurs d'échange sont responsables de la maintenance de l'échange, y compris les mises à niveau et le rechargement des cycles pour le faire fonctionner. Omnity fournira aux constructeurs d'échange des installations universelles pour faciliter l'utilisation, mais tout cela est optionnel et remplaçable.
Caractéristiques du système
Programmabilité
REE Exchange est un contrat intelligent ICP indépendant capable de tirer pleinement parti des fonctionnalités de la blockchain sous-jacente. Les lecteurs sont invités à consulter la documentation technique d'ICP pour plus d'informations sur le développement de contrats intelligents sur ICP.
Documentation technique ICP :
https://internetcomputer.org/docs/current/home
Voici quelques conseils :
1. Les calculs intensifs comme la reconnaissance faciale peuvent être exécutés dans les 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 en chaîne, avec 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 en chaîne sur ICP, ce qui signifie qu'aucun relais ou indexeur hors chaîne n'est nécessaire. 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 fluide entre les protocoles à travers l'union de la liquidité et des unités logiques dans un cadre minimisant la confiance.
REE offre une combinabilité de style Bitcoin. Chaque échange 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 échanges, chaque échange recevant et contribuant à certains coins. Avec la coopération des échanges, le coordinateur est responsable de garantir l'atomicité des transactions à signature multiple. La combinabilité atomique signifie que les transactions à signature multiple réussissent complètement ou sont complètement annulées en cas d'échec de n'importe quelle partie. Cela est crucial dans les applications DeFi.
En général, le trader fournit le premier input à l'échange ; la sortie du premier échange va au deuxième échange, et cela continue jusqu'à ce que la sortie finale du dernier échange soit donnée au trader. L'ordre de signature du PSBT suit cette logique : le premier échange n'acceptera de fournir son input et de signer le PSBT que si le trader a signé son input, et ainsi de suite.
Conceptuellement, la combinabilité des échanges ressemble à des commandes Unix pipelinées. Cependant, ce n'est pas tout. Toute entité (trader ou échange) peut fournir des inputs à d'autres entités sans tenir compte de l'ordre. Par exemple, l'input du trader va au deuxième ou à un échange ultérieur ; l'échange fournit l'input initial et les frais du réseau Bitcoin à la place du trader.
De plus, les traders ne sont pas nécessairement des individus ; cela peut être des processus hors chaîne ou des contrats intelligents ICP. Cela ouvre la possibilité pour des agrégateurs de revenus on-chain ou des 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 receveur (le trader traitant avec le pool de fonds) passe en revue le PSBT contenant tous les termes de la transaction avant de signer, ces termes étant représentés par les inputs et les outputs. Une fois signé, personne, y compris le trader lui-même, l'échange, REE, les nœuds ICP et les mineurs de Bitcoin, ne peut modifier la transaction. En d'autres termes, le receveur ne prend aucun risque de garde.
En général, l'exécution de chaque transaction REE entraîne un changement d'état d'un pool de fonds spécifique, rendant les termes de transaction obtenus lors d'une requête précédente 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 en série. Cependant, des échecs de transaction peuvent se produire 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 essayer de réexécuter.
Les market makers (traders fournissant de la liquidité au pool de fonds) prennent des risques de garde en transférant le contrôle des actifs à l'échange. Par conséquent, ils sont confrontés à des risques de contrats intelligents liés à la logique de l'échange, ce qui souligne l'importance de l'audit et de la réputation des constructeurs d'échange.
Les hypothèses de sécurité des market makers incluent ICP et la plateforme REE. Cependant, la sécurité d'ICP (valant des milliards de dollars) satisfait aux exigences de sécurité des protocoles BTCFi dans tous les cas connus.
Cohérence de l'état Bitcoin
Les limitations du script Bitcoin en matière de soutien à BTCFi ne sont pas seulement dues aux limitations fonctionnelles des opcodes, mais aussi en grande partie à leur incapacité à maintenir des états complexes on-chain. En revanche, les échanges dans REE peuvent facilement maintenir et gérer l'état. Cependant, l'état de l'échange REE doit finalement être cohérent avec Bitcoin ; sinon, les transactions REE ne peuvent pas être réglées sur Bitcoin.
Pour éviter les échecs de règlement, l'Orchestrateur vérifie que toutes les entrées de transaction n'ont pas été dépensées. Chaque échange vérifie également que les entrées et sorties de transaction répondent à ses normes. Cette approche garantit que seules les entrées valides et vérifiées sont utilisées pour les transactions de règlement.
Cependant, même si ces inputs sont vérifiés 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 inputs pour une autre transaction Bitcoin.
REE doit percevoir les changements en temps réel dans le réseau Bitcoin et y réagir en conséquence. Avec l'intégration native de Bitcoin et l'indexeur Runes en chaîne, REE pourrait être la seule couche d'exécution Bitcoin à atteindre cet objectif sans dépendre de processus centralisés hors chaîne.
Figure 4. État de la Tx REE
L'Orchestrateur REE est le composant qui gère le cycle de vie de toutes les transactions REE. Il est responsable de notifier les échanges des événements de changement d'état associés.
Figure 5. Gestion de l'état du pool de fonds
Les échanges gèrent l'état basé sur les pools de fonds. Plus précisément, l'état du pool doit être organisé en une chaîne d'état liée à une séquence de transactions exécutées sur ce pool. Le pool traite toujours les requêtes de consultation et exécute de nouvelles transactions en fonction de l'état de la chaîne. Selon les notifications d'événements de l'Orchestrateur, le pool 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 aucune méthode économiquement viable pour garantir qu'une transaction soit incluse dans un bloc dans un cadre temporel spécifique. En cas de flambée des frais du réseau Bitcoin, il existe deux méthodes pour accélérer le règlement : RBF (Remplacer par les frais) et CPFP (L'enfant paie pour le parent). RBF nécessite la reconstruction de la transaction, ce qui entraîne une mauvaise expérience utilisateur.
REE utilise CPFP, ce qui signifie que lorsque les frais du réseau Bitcoin flambent, les transactions suivantes doivent subventionner les transactions précédentes non incluses dans le bloc sur le même pool de fonds. Les subventions de frais restent un mécanisme de marché libre : les traders ne lanceront des transactions suivantes que s'ils s'attendent à ce qu'il y ait un profit malgré l'augmentation des coûts.
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 seulement quelques secondes de latence, sans attendre la confirmation des blocs pour passer à l'étape suivante. En termes de latence, REE améliore les performances de Bitcoin par un facteur de 100.
Les transactions en série de REE seront réglées sous forme de lots sur la chaîne Bitcoin. Étant donné qu'une transaction dans le pool mémoire peut avoir jusqu'à 25 transactions suivantes, chaque bloc Bitcoin peut régler jusqu'à 25 transactions pour un seul pool de transactions REE. Par conséquent, 25 peut être considéré comme la limite de débit d'un seul pool de transactions REE.
Différents pools de transactions peuvent permettre une exécution parallèle des transactions. Lorsque la concurrence des prix n'est pas nécessaire, les constructeurs d'échanges peuvent ajouter des pools redondants pour améliorer la simultanéité. Par exemple, distribuer des jetons sur 10 pools pour un airdrop à 100 000 bénéficiaires peut considérablement réduire la probabilité d'échecs de transaction dus à plusieurs utilisateurs réclamant simultanément.
Dans un seul pool de transactions, la simultanéité interne peut être réalisée en gérant plusieurs UTXO de la même monnaie. Cependant, cela nécessite des algorithmes de sélection, de fragmentation et de fusion de UTXO plus complexes. Les échanges futurs pourraient explorer ces technologies avancées pour offrir une meilleure expérience utilisateur.
Coût
Les coûts principaux 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 le coût de fonctionnement de l'échange 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 garantir la viabilité économique de leur échange.
MEV
REE est une couche d'exécution qui délègue le tri des transactions au sous-réseau ICP où se trouve le conteneur de l'Orchestrateur REE. Bien que cela soit théoriquement possible, le fait que les nœuds du sous-réseau ICP extraient MEV en réorganisant les transactions est sans précédent.
Plus important encore, il n'y a pas de concept de glissement sur REE ; lorsque le trader signe le PSBT, toutes les entrées et sorties de transaction sont déjà définies. Si une entrée du pool d'échange a déjà été dépensée, la transaction échouera. Ainsi, si une transaction REE est devancée, elle échouera automatiquement, laissant le devanceur assumer seul le risque de prix.
Gouvernance
REE sera géré par Omnity SNS DAO, responsable de la supervision des mises à niveau de protocole, des ajustements de paramètres et de la feuille de route de développement. La gouvernance en chaîne de SNS garantit la transparence du développement durable de l'écosystème REE et la prise de décisions communautaires.
Cas d'utilisation
Reproduire les protocoles DeFi d'Ethereum ou de Solana sur Bitcoin est une manière directe d'exploiter REE. Voici quelques exemples pour détailler cela.
AMM DEX (échange décentralisé de market makers automatiques)
RichSwap, un AMM DEX construit par Omnity, sera lancé en même temps que le mainnet REE. En tant que premier échange sur REE, RichSwap sert les objectifs suivants :
1. RichSwap valide la fonctionnalité et la performance de la plateforme REE.
2. RichSwap est open-source, fournissant des exemples complets aux constructeurs BTCFi.
3. D'autres protocoles BTCFi peuvent utiliser RichSwap pour accélérer la liquidité.
4. RichSwap intègre un mécanisme de capture de valeur de jeton, que d'autres protocoles BTCFi peuvent exploiter.
Bien que RichSwap soit le premier échange, il n'a aucun privilège. Après le lancement du mainnet, REE deviendra rapidement une plateforme ouverte, acceptant l'enregistrement sans permission de tous les protocoles BTCFi conformes 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, chacun ayant des configurations, des paramètres de risque et des types d'actifs de soutien différents. Chaque pool soutenant l'emprunt de BTC en utilisant des Runes de premier ordre peut avoir des taux d'intérêt, des taux de collatéral et des seuils de liquidation différents. Il peut choisir de rendre un atoken aux fournisseurs de liquidité (LP). En intégrant des oracle sur ICP, les protocoles de prêt peuvent déterminer de manière décentralisée la valeur des collatéraux ou déclencher des processus de liquidation.
Jetons de staking liquide
Le staking de Bitcoin L1 sur REE est réalisable, 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'échange et reçoivent des LST au format Runes. Puis LSTExchange combine avec le protocole de staking Babylon sur Bitcoin L1 tout en gérant les délégations et les récompenses de staking sur la chaîne Babylon via un protocole sans confiance inter-chaînes. Omnity Hub a déjà été intégré à Osmosis par une architecture entièrement en chaîne et une vérification par client léger. Ainsi, l'interaction entre les contrats intelligents ICP et les chaînes d'applications Cosmos n'est plus confrontée à des obstacles techniques.
Feuille de route
1. Au quatrième trimestre 2024, publication du livre blanc REE
2. Au premier trimestre 2025, lancement du mainnet REE avec RichSwap.
3. Au deuxième trimestre 2025, ouverture des inscriptions Exchange aux partenaires d'Omnity.
4. Au second semestre 2025, ouverture complète des inscriptions Exchange.
Conclusion
REE représente une avancée dans la programmabilité de Bitcoin, réalisant des contrats intelligents sécurisés et Turing-complets sans dépendre de l'interopérabilité d'actifs ou de forks. Ce modèle d'exécution sans interopérabilité a le potentiel de cultiver un écosystème BTCFi exploitant la liquidité et la sécurité de Bitcoin dans un environnement totalement sans confiance et sans autorisation.
