Artikel übernommen aus: Runes Chinese Community
Als BTCFi in vollem Gange war, hat Omnity das brandneue Bitcoin Layer 1 programmierbare Erweiterungsprotokoll REE veröffentlicht. Zusammen mit den jahrelangen Erfahrungen des Teams im Bereich der Cross-Chain-Interoperabilität (Omnity Hub) hat sich Omnity zu einem der bedeutendsten und innovativsten Akteure im BTCFi-Bereich entwickelt.
Offizielle Website: https://www.omnity.network/
Meiner Ansicht nach erkundet das Omnity Network eine effiziente, hochgradig komposierbare und fehlertolerante technische Lösung zur "Skalierung und Verbesserung der Programmierbarkeit" des Bitcoin-Ökosystems.
1. Für Hochfrequenzhandelsszenarien, durch Trustless-Level Bitcoin-Asset-Cross-Chain-Lösungen wie Omnity Hub, gehen sie zu Hochgeschwindigkeits-Smart-Contract-Blockchains mit besserer ökologischer Entwicklung wie Bitlayer, Solana und Base.
2. Für große Geldszenarien und normale Handelsfrequenzen wird DeFi-Geschäft direkt auf Bitcoin Layer unter Verwendung von REE aufgebaut.
Hub und REE sind unabhängig, bieten flexible Komposierbarkeit und bilden eine solide Grundlage für die Innovation der Entwickler. Wir hoffen auf disruptive Innovationen im Bereich BTCFi!
Interessierte können diesen Artikel lesen, um mehr zu erfahren. Für die englische Originalversion siehe den Link ⬇️
REE Whitepaper: https://x.com/louisliubj/status/1861588938475086166
Hier ist die chinesische Übersetzung, viel Spaß!
REE: Turing-vollständige, cross-chain-freie Bitcoin-Ausführungsschicht
REE führt eine dezentrale Bitcoin-Ausführungsschicht ein, die Turing-vollständige Smart Contracts für BTCFi-Anwendungen aktiviert. Ohne Cross-Chain-Assets verbessert REE die Programmierbarkeit des Bitcoin-Hauptnetzes und bewahrt dabei die native Benutzererfahrung von Bitcoin.
Was ist REE?
Das Runes Exchange Environment (REE) ist eine dezentrale Ausführungsschicht von Bitcoin, die programmierbare Smart Contracts für Bitcoin Layer 1 bereitstellt, ohne dass eine Cross-Chain-Übertragung von Vermögenswerten erforderlich ist. REE verbessert die Mechanismen für Multisignaturtransaktionen von Bitcoin, indem es Smart Contracts auf einer dezentralen Ausführungsschicht einführt, die direkt an den Transaktionen im Bitcoin-Hauptnetz teilnimmt.
Abbildung 0. Bitcoin-Multisignaturtransaktion
Multisignaturtransaktionen sind Bitcoin-Transaktionen, die mehrere Teilnehmer-Eingaben enthalten, eine Technik, die im Bitcoin-Ökosystem seit vielen Jahren verwendet wird. In der Regel fungiert ein Teilnehmer als Koordinator und verwendet PSBT (Partially Signed Bitcoin Transaction), um die Signaturen jedes Beteiligten zu aggregieren, bevor die Transaktion ins Bitcoin-Netzwerk gesendet wird. Einige bemerkenswerte Anwendungsfälle für Multisignaturtransaktionen sind CoinJoin, Multisignatur-Wallets und Treuhänder.
In Multisignatur-Szenarien können die Teilnehmer neben Menschen auch Programme sein. In der DeFi-Umgebung handeln Händler normalerweise mit Protokollen (Smart Contracts) als ihren Geschäftspartnern. Die Idee von REE besteht darin, BTCFi-Protokolle in Bitcoin-Multisignaturtransaktionen einzubeziehen und den gesamten Signaturprozess auf die öffentliche Blockchain zu verlagern, um Dezentralisierung zu erreichen.
Abbildung 1. Dezentrale Multisignaturkoordination (DMSC)
Abbildung 1 zeigt den allgemeinen Ablauf der dezentralen Multisignaturkoordination (DMSC). Diese Einrichtung umfasst einen Händler, mehrere BTCFi-Protokolle (A, B und C) und einen Koordinator auf einer öffentlichen Blockchain. Der Koordinator aggregiert die Signaturen und sendet die endgültige Transaktion.
Der DMSC-Prozess ist wie folgt:
1. Verhandlungsphase
Der Händler initiiert eine Transaktion, indem er die Bedingungen mit mehreren Protokollen verhandelt. Jedes Protokoll repräsentiert eine Entität, die Bitcoin-Vermögenswerte hält und bereit ist, eine Transaktion basierend auf bestimmten Regeln durchzuführen. Beispiele für Protokolle sind dezentrale Börsen, Kreditprotokolle, Stablecoins usw.
2. Signaturphase
Nach den Verhandlungen wird eine PSBT erstellt, die die Transaktion widerspiegelt. Der Koordinator ruft anschließend jedes Protokoll auf, um die PSBT zu signieren. Jedes Protokoll (A, B und C) überprüft seinen Transaktionsanteil und genehmigt dessen Aufnahme durch seine Signatur.
3. Broadcast-Phase
Sobald die PSBT vollständig unterzeichnet ist, wandelt der Koordinator/Koordinator sie in eine Bitcoin-Transaktion um und sendet sie ins Netzwerk. Damit ist die Transaktion auf Bitcoin abgeschlossen.
REE wählt ICP (Internet Computer Protocol) als öffentliche Blockchain für DMSC. Mit anderen Worten, REE ist die Bitcoin DMSC-Infrastruktur auf ICP.
Warum REE?
Bitcoin ist die sicherste und dezentralste Blockchain der Welt, aber seine begrenzte Programmierbarkeit schränkt seine Verwendung in komplexen Finanzanwendungen ein. REE ergänzt bestehende Bitcoin L2-Lösungen, indem es eine fortschrittliche Programmierbarkeit und Turing-vollständige Smart Contracts anbietet und dabei Selbstverwahrung und minimalisierte Vertrauensannahmen beibehält.
Abbildung 2. REE ist kein Bitcoin-L2.
Im Gegensatz zu den meisten L2 interagieren REE-Smart Contracts direkt mit dem UTXO-Modell von Bitcoin und ermöglichen eine fortschrittliche Programmierbarkeit, während sie die Selbstverwahrung aufrechterhalten. Händler müssen ihre Bitcoin-Vermögenswerte nicht über eine Cross-Chain-Brücke sperren. Sie interagieren mit den Smart Contracts, indem sie die PSBT mit ihrer Bitcoin-Wallet signieren und die Transaktionsabrechnung sofort auf Bitcoin abschließen.
Auf der anderen Seite hat DMSC im Vergleich zu anderen bekannten Lösungen zur Verbesserung der Programmierbarkeit von Bitcoin L1 signifikante Vorteile. Es nutzt moderne öffentliche Blockchains, um die Programmierbarkeit von Bitcoin zu verbessern, anstatt sich auf neue OP-Codes zu verlassen. Darüber hinaus kann DMSC mit allen UTXO-basierten Meta-Protokoll-Assets kompatibel sein, ohne dass ein Upgrade der Meta-Protokolle und Indexer erforderlich ist.
Tabelle 1. Vergleich der technischen Lösungen zur Programmierbarkeit von Bitcoin L1.
Schließlich könnte ICP die am besten geeignete Blockchain für DMSC sein. REE nutzt die Chain Fusion-Technologie von ICP, um private Schlüssel und Bitcoin-Signaturen sicher zu verwalten und gleichzeitig das Sicherheitsmodell von Bitcoin zu aktivieren. Durch die native Bitcoin-Integration von ICP und den On-Chain-Indexer ist REE auf eine minimal vertrauensvolle Weise mit Runes (dem am weitesten verbreiteten UTXO-basierten Bitcoin-Meta-Protokoll) kompatibel.
Wie funktioniert REE?
Unter dem Einfluss von Ethereum basiert das Zustandsmodell der überwiegenden Mehrheit der Smart Contract-Plattformen auf Konten, was auch die Denkweise der Smart Contract-Entwickler beeinflusst. Im Gegensatz dazu basiert der On-Chain-Zustand von Bitcoin auf UTXO. REE führt das Exchange-Pool-Modell ein, um die Unterschiede zu überbrücken. Das Exchange-Pool-Modell passt sich dem UTXO-Zustandsmanagement von Bitcoin an und kann auf einer kontobasierten öffentlichen Chain wie ICP leicht implementiert werden. Dieses Modell besteht aus drei einfachen Konzepten:
1. Coin ist die Einheit für Bitcoin-Vermögenswerte, die auf UTXO basieren. BTC und Runes werden in REE als Coin akzeptiert.
2. Die Exchange ist ein BTCFi-Protokollbeispiel, das auf der REE-Plattform arbeitet und den Austausch von Coins erleichtert.
3. Ein Fonds (pool) ist der öffentliche Schlüssel (Chain Key), den die Exchange verwendet, um Coin zu halten und Bitcoin-Transaktionen zu signieren. Gemäß der Exchange-Logik gibt der Benutzer eine Tasche Coin in den Pool und erhält eine andere Tasche Coin daraus. In der Regel verwaltet eine Exchange mehrere Pools, wobei jeder Pool Daten zu Coin und Zustand enthält.
Bitcoin-Bauer können nun mit der REE-Exchange vielfältige BTCFi-Protokolle erstellen – mehrere öffentliche Methoden werden in ICP-Smart Contracts realisiert.
Abbildung 3. REE-Architektur
Abbildung 3 zeigt den Prozess der Durchführung von Bitcoin-Transaktionen auf REE, an dem mehrere Komponenten wie zwei Exchanges, der REE-Koordinator und die Frontend-Oberfläche beteiligt sind. Hier ist der Prozess Schritt für Schritt aufgeschlüsselt:
1. Preisabfrage: Der Händler initiiert den Prozess über die Frontend-Oberfläche und fragt nach dem Preis für die Transaktion. Dies kann die Auswahl der Transaktion oder der Operationstypen beinhalten, die er ausführen möchte, z. B. einen Austausch auf ExchangeA und anschließend das Staking auf ExchangeB.
2. PSBT erstellen: Sobald der Händler den Handelsbedingungen zustimmt, erstellt das Frontend mit Hilfe des REE Typescript SDK die PSBT.
3. Händler signiert PSBT: Der Händler überprüft und signiert die PSBT mit seiner Bitcoin-Wallet und genehmigt somit die Transaktion für die nachfolgende Bearbeitung.
4. Aufruf des Orchestrators/Koordinators: Das Frontend sendet die PSBT an den REE Orchestrator/Koordinator. Der REE Orchestrator/Koordinator fungiert als Koordinator und überwacht die Ausführung der Transaktion.
5. Überprüfen der Eingaben: Bevor der Orchestrator/Koordinator die REE-Transaktion ausführt, müssen alle PSBT-Eingaben überprüft werden, um sicherzustellen, dass sie ausgabefähig sind und tatsächlich die Vermögenswerte enthalten, die sie beanspruchen. Der Orchestrator/Koordinator verlässt sich dabei auf den Ord Canister (On-Chain-Runes-Indexer), um dies zu gewährleisten.
6. Exchange signiert PSBT: Nach der Validierung kommuniziert der REE Orchestrator/Koordinator mit der relevanten Exchange, um die PSBT zu unterzeichnen. Die Exchange validiert, dass die PSBT-Daten den Handelsbedingungen entsprechen, und signiert sie nacheinander.
7. Broadcast-Transaktion: Nachdem alle relevanten Exchanges die PSBT unterzeichnet haben, sendet der REE-Koordinator die vollständig signierte Transaktion in das Bitcoin-Netzwerk. Die Transaktion wird dann auf der Bitcoin-Blockchain bestätigt und der gesamte Prozess ist abgeschlossen.
Der REE Orchestrator/Koordinator ist dafür verantwortlich, die Konsistenz des Zustands sicherzustellen, indem er die Exchange benachrichtigt, um den Zustand zurückzurollen, wenn eine Exchange das Signieren verweigert.
Bevor jemand die Exchange nutzt, muss sie von ihrem Erbauer initialisiert werden:
1. Bereitstellung (Schritt 0.1): Der Erbauer stellt den Exchange-Canister im selben ICP-Subnetz wie den REE Orchestrator/Koordinator bereit. Obwohl Canister über Subnetze hinweg aufgerufen werden können, kann dies unnötige Verzögerungen mit sich bringen.
2. Registrierung (Schritt 0.2): Der Erbauer registriert die Exchange beim REE Orchestrator/Koordinator.
Die Exchange-Bauer sind für die Wartung der Exchange verantwortlich, einschließlich Upgrades und dem Aufladen von Zyklen, um den Betrieb aufrechtzuerhalten. Omnity wird den Exchange-Bauern allgemeine Einrichtungen zur Verfügung stellen, um die Nutzung zu erleichtern, diese sind jedoch optional und ersetzbar.
Systemmerkmale
Programmability
Die REE-Exchange ist ein unabhängiger ICP-Smart Contract, der die Funktionen der zugrunde liegenden Blockchain vollständig nutzen kann. Wir empfehlen den Lesern, die technischen Dokumente von ICP zu besuchen, um mehr über die Entwicklung von ICP-Smart Contracts zu erfahren.
ICP technische Dokumente:
https://internetcomputer.org/docs/current/home
Hier sind einige Tipps:
1. Intensive Berechnungen wie Gesichtserkennung können innerhalb von ICP-Smart Contracts ausgeführt werden:
https://medium.com/dfinity/the-next-step-for-deai-on-chain-inference-enabling-face-recognition-589183203fc2
2. Der Bitcoin-Container von ICP könnte der größte Smart Contract der Welt sein und 500 GB On-Chain-Speicher belegen, wobei die jährlichen Kosten nur 2500 USD betragen.
https://github.com/dfinity/bitcoin-canister
3. Omnity Hub ist ein vollständig on-chain Interoperabilitätsstack auf ICP, was bedeutet, dass keine Off-Chain-Relays oder Indexer erforderlich sind. Omnity Hub verbindet direkt Dutzende von heterogenen Blockchains über RPC-Schnittstellen.
https://explorer.omnity.network/
Komposierbarkeit
Die Komposierbarkeit der REE-Smart Contracts gewährleistet nahtlose Integration über Protokolle hinweg, indem Liquidität und logische Einheiten in einem minimal vertrauensvollen Rahmen kombiniert werden, um innovative Finanzprotokolle zu schaffen.
REE bietet Bitcoin-ähnliche Komposierbarkeit. Jede Exchange kümmert sich nur darum, was sie erhält (Eingabe) und was sie bereitstellt (Ausgabe); solange die Eingaben/Ausgaben sinnvoll sind, stimmt sie der Teilnahme an der Transaktion zu. REE-Transaktionen können mehrere Exchanges umfassen, wobei jede Exchange einige Coins erhält und beiträgt. In Zusammenarbeit mit den Exchanges ist der Koordinator dafür verantwortlich, die Atomizität der Multisignaturtransaktionen sicherzustellen. Atomare Komposierbarkeit bedeutet, dass Multisignaturtransaktionen entweder vollständig erfolgreich sind oder bei einem Misserfolg in jedem Teil vollständig zurückgerollt werden. Dies ist entscheidend in DeFi-Anwendungen.
Normalerweise bietet der Händler dem ersten Exchange die anfänglichen Eingaben an; die Ausgaben des ersten Exchanges gelangen zum zweiten Exchange, und so geht es weiter, bis die endgültige Ausgabe des letzten Exchanges an den Händler geht. Die Signaturreihenfolge der PSBT folgt dieser Logik: Der erste Exchange wird nur dann zustimmen, seine Eingaben bereitzustellen und die PSBT zu signieren, wenn der Händler seine Eingaben bereits signiert hat, und so weiter.
Konzeptionell sieht die Komposierbarkeit der Exchanges wie pipelined Unix-Befehle aus. Aber es ist nicht nur das. Jede Entität (Händler oder Exchange) kann anderen Entitäten Eingaben bereitstellen, ohne die Reihenfolge zu beachten. Zum Beispiel werden die Eingaben des Händlers an den zweiten oder späteren Exchange gegeben; der Exchange bietet anstelle des Händlers die anfänglichen Eingaben und die Bitcoin-Netzwerkkosten an.
Darüber hinaus ist der Händler nicht unbedingt eine Einzelperson; er kann ein Off-Chain-Prozess oder ein ICP-Smart Contract sein. Dies eröffnet Möglichkeiten für On-Chain- oder Off-Chain-Ertragsaggregatoren oder Arbitragebots. Durch den leistungsstarken Chain Fusion-Stack kann die REEExchange mit anderen Blockchains interagieren. Zum Beispiel können Statusänderungen auf Ethereum oder Solana REE-Transaktionen auslösen und umgekehrt.
Risikoprofil
Der Empfänger (der Händler, der mit dem Fonds handelt) prüft die PSBT, die alle Handelsbedingungen enthält, bevor er sie signiert. Nach der Signatur kann niemand, einschließlich des Händlers selbst, der Exchange, REE, ICP-Knoten und Bitcoin-Miner, die Transaktion ändern. Mit anderen Worten, der Empfänger trägt kein Treuhandrisiko.
Normalerweise führt die Ausführung jeder REE-Transaktion zu Änderungen des Zustands eines bestimmten Fonds, wodurch die Transaktionsbedingungen, die aus vorherigen Abfragen erhalten wurden, ungültig werden. Angesichts der Verzögerung der Ausführung von REE-Transaktionen (in Sekunden) im Vergleich zu Bitcoin (in Minuten) werden REE-Transaktionen normalerweise sequenziell verarbeitet. Bei gleichzeitigen Transaktionen mehrerer Händler mit demselben Fonds können jedoch Transaktionsfehler auftreten.
Transaktionsfehler führen nicht zu Vermögensverlusten; der Händler muss lediglich die Abfrage erneut durchführen und es erneut versuchen.
Market Maker (Händler, die Liquidität in den Fonds bereitstellen) tragen das Treuhandrisiko, wenn sie die Kontrolle über Vermögenswerte an die Exchange abgeben. Daher sind sie den intelligenten Vertragsrisiken im Zusammenhang mit der Exchange-Logik ausgesetzt, was die Bedeutung von Audits und den Ruf der Exchange-Bauer unterstreicht.
Die Sicherheitsannahmen der Market Maker umfassen die ICP- und REE-Plattform. Die Sicherheit von ICP (im Wert von mehreren Milliarden Dollar) erfüllt in allen bekannten Fällen die Sicherheitsanforderungen für BTCFi-Protokolle.
Bitcoin-Zustandskonsistenz
Die Einschränkungen des Bitcoin-Skripts bei der Unterstützung von BTCFi ergeben sich nicht nur aus den funktionalen Einschränkungen der Opcodes, sondern auch in hohem Maße daraus, dass sie keinen komplexen On-Chain-Zustand verwalten können. Im Gegensatz dazu kann die Exchange in REE den Zustand bequem verwalten und pflegen. Der Zustand der REE-Exchange muss jedoch letztendlich mit Bitcoin synchronisiert werden; andernfalls kann die REE-Transaktion nicht auf Bitcoin abgerechnet werden.
Um Abrechnungsfehler zu vermeiden, überprüft der Koordinator alle Transaktionsinputs, um sicherzustellen, dass sie nicht ausgegeben wurden. Jede Exchange überprüft auch, ob die Transaktionseingaben und -ausgaben ihren Standards entsprechen. Dieser Ansatz gewährleistet, dass nur gültige und verifizierte Eingaben für die Abrechnung von Transaktionen verwendet werden.
Allerdings kann, selbst wenn diese Eingaben vor der Ausführung der Transaktion verifiziert werden, die Abrechnung danach nicht garantiert werden. Händler könnten absichtlich oder unbeabsichtigt dieselben Eingaben für eine andere Bitcoin-Transaktion verwenden.
REE muss Echtzeitänderungen im Bitcoin-Netzwerk wahrnehmen und entsprechend reagieren. Mit der Unterstützung der nativen Bitcoin-Integration und der On-Chain-Runes-Indexer könnte REE die einzige Bitcoin-Ausführungsschicht sein, die dies ohne Abhängigkeit von zentralisierten Off-Chain-Prozessen erreicht.
Abbildung 4. REE Tx-Zustand
Der REE Orchestrator/Koordinator ist ein Bestandteil, der den gesamten Lebenszyklus aller REE-Transaktionen verwaltet. Er ist verantwortlich für die Benachrichtigung über statusverändernde Ereignisse, die für die Exchange relevant sind.
Abbildung 5. Zustandsmanagement des Fonds
Exchanges verwalten den Zustand basierend auf Fonds. Genauer gesagt, der Zustand des Fonds sollte als eine Kette von Zuständen organisiert werden, die durch eine Sequenz von Transaktionen, die auf diesem Fonds ausgeführt werden, verbunden sind. Der Fonds verarbeitet Anfragen und führt neue Transaktionen stets gemäß dem Kopf der Zustandskette aus. Basierend auf Ereignisbenachrichtigungen vom Orchestrator/Koordinator führt der Fonds die Bestätigung oder Rückabwicklung durch.
Außerdem gibt es angesichts der hohen Volatilität der Bitcoin-Netzwerkkosten keine wirtschaftlich tragfähige Methode, um sicherzustellen, dass Transaktionen innerhalb eines bestimmten Zeitrahmens in einen Block aufgenommen werden. Bei einem Anstieg der Bitcoin-Netzwerkkosten gibt es zwei Möglichkeiten, die Abrechnung zu beschleunigen: RBF (Replace-By-Fee) und CPFP (Child Pays for Parent). RBF erfordert den Neuaufbau der Transaktion, was zu einem schlechten Benutzererlebnis führt.
REE verwendet CPFP, was bedeutet, dass, wenn die Bitcoin-Netzwerkkosten ansteigen, nachfolgende Transaktionen die vorherigen, die nicht in einen Block aufgenommen wurden, aus dem selben Fonds subventionieren müssen. Die Kostenunterstützung bleibt ein Mechanismus des freien Marktes: Nur wenn Händler erwarten, trotz der steigenden Kosten profitabel zu sein, werden sie nachfolgende Transaktionen initiieren.
Leistung
Die Leistung der Ausführungsschicht wird in der Regel anhand zweier Kennzahlen bewertet: Durchsatz (gemessen in TPS) und Latenz. Auf REE können Händler Transaktionen mit nur wenigen Sekunden Latenz nacheinander ausführen, ohne auf die Bestätigung eines Blocks warten zu müssen, um den nächsten Schritt zu tun. In Bezug auf die Latenz verbessert REE die Leistung von Bitcoin um das 100-Fache.
Die seriellen Transaktionen von REE werden in Bulk auf der Bitcoin-Blockchain abgerechnet. Da eine Transaktion im Memory Pool maximal 25 nachfolgende Transaktionen haben kann, können höchstens 25 Transaktionen pro Bitcoin-Block für ein einzelnes REE-Transaktionspool abgerechnet werden. Daher kann 25 als die Durchsatzobergrenze eines einzelnen REE-Transaktionspools betrachtet werden.
Unterschiedliche Transaktionspools können parallele Transaktionsausführungen ermöglichen. Wenn Preiskonkurrenz nicht notwendig ist, können Exchange-Bauer redundante Pools hinzufügen, um die Parallelität zu erhöhen. Beispielsweise kann die Verteilung von Token auf 10 Pools für einen Airdrop mit 100.000 Empfängern die Wahrscheinlichkeit verringern, dass Transaktionen aufgrund gleichzeitiger Abholungen mehrerer Benutzer fehlschlagen.
In einem einzelnen Transaktionspool kann die Pool-internen Parallelität durch die Verwaltung mehrerer UTXOs, die denselben Typ von Münzen halten, erreicht werden. Dies erfordert jedoch komplexere UTXO-Auswahl-, Split- und Zusammenführungsalgorithmen. Zukünftige Exchanges könnten diese fortgeschrittenen Techniken erforschen, um ein besseres Benutzererlebnis zu bieten.
Kosten
Die Hauptkosten der REE-Transaktion für die Benutzer stammen von den Bitcoin-Netzwerkkosten. REE minimiert die Größe der Abrechnungstransaktionen durch die Verwendung des P2TR-Adresse Typs.
Die Erbauer tragen die Betriebskosten der Exchange auf ICP (Zyklen). Obwohl ICP äußerst kosteneffektiv ist, müssen die Erbauer Einnahmen intern oder extern generieren, um die wirtschaftliche Nachhaltigkeit ihrer Exchange sicherzustellen.
MEV
REE ist eine Ausführungsschicht, die die Transaktionssortierung dem ICP-Subnetz anvertraut, in dem sich der REE Orchestrator/Koordinator befindet. Obwohl es theoretisch möglich ist, ist es unbekannt, dass ICP-Subnetzknoten MEV durch das Neusortieren von Transaktionen extrahieren.
Wichtiger ist, dass es im REE kein Konzept von Slippage gibt; wenn der Händler die PSBT unterzeichnet, sind alle Transaktionseingänge und -ausgänge bereits festgelegt. Wenn ein Eingangsbeitrag aus dem Exchange-Fondsbecken bereits ausgegeben wurde, schlägt die Transaktion fehl. Daher wird eine REE-Transaktion automatisch fehlschlagen, wenn sie vorrangig ist, und der Vorrangnehmer trägt allein das Preisrisiko.
Governance
REE wird von der Omnity SNS DAO verwaltet, die für die Überwachung von Protokoll-Upgrades, Parameteranpassungen und Entwicklungs-Roadmaps verantwortlich ist. Die On-Chain-Governance der SNS gewährleistet die Transparenz und die gemeinschaftsgetriebenen Entscheidungsprozesse für die nachhaltige Entwicklung des REE-Ökosystems.
Anwendungsfälle
Das Kopieren von DeFi-Protokollen von Ethereum oder Solana auf Bitcoin ist ein direkter Weg, um REE zu nutzen. Im Folgenden sind einige Beispiele aufgeführt, um dies im Detail zu erläutern.
AMM DEX (Automated Market Maker Decentralized Exchange)
RichSwap, ein AMM DEX, der von Omnity gebaut wurde, wird gleichzeitig mit dem REE-Hauptnetz gestartet. Als die erste Exchange auf REE dient RichSwap folgenden Zwecken:
1. RichSwap validiert die Funktionalität und Leistung der REE-Plattform.
2. RichSwap ist Open Source und bietet vollständige Beispiele für BTCFi-Baumeister.
3. Andere BTCFi-Protokolle können RichSwap zur Beschleunigung der Liquiditäts-Self-Bootstrapping nutzen.
4. RichSwap ist mit einem integrierten Token-Wert-Erfassungsmechanismus ausgestattet, den andere BTCFi-Protokolle nutzen können.
Obwohl RichSwap die erste Exchange ist, hat sie keine Privilegien. Nach dem Start des Hauptnetzes wird REE schnell zu einer offenen Plattform übergehen, die die Genehmigung für die Registrierung beliebiger BTCFi-Protokolle (einschließlich AMM DEX) gemäß den technischen Spezifikationen akzeptiert.
Kredite
Auf Basis von REE können Kreditprotokolle mehrere Fonds unterstützen, wobei jeder Fonds unterschiedliche Konfigurationen, Risikoparameter und Arten von unterstützten Vermögenswerten aufweist. Jeder Fonds, der mit Blue-Chip-Runes BTC verleiht, kann unterschiedliche Zinssätze, Beleihungsquoten und Liquidationsschwellen haben. Es könnte entscheiden, den Liquiditätsanbietern (LPs) ein atoken zurückzugeben. Durch die Integration mit Orakeln auf ICP kann das Kreditprotokoll dezentral den Wert des Sicherheiten oder den Liquidationsprozess auslösen.
Liquiditäts-Staking-Token
Die Implementierung von Bitcoin L1 Staking auf REE ist möglich, aber die Integration bestehender Staking-Protokolle (wie Babylon) ist eine interessantere Möglichkeit. Benutzer hinterlegen Bitcoin bei Exchanges und erhalten LST im Runes-Format. Dann kombiniert LSTExchange mit dem Staking-Protokoll von Babylon auf Bitcoin L1 und verwaltet gleichzeitig die Delegation und Staking-Belohnungen auf der Babylon-Chain über ein vertrauensloses Cross-Chain-Protokoll. Omnity Hub hat bereits mit einer vollständigen Kettenarchitektur und leichten Client-Verifizierung mit Osmosis integriert. Daher gibt es keine technischen Hindernisse mehr für die Interaktion zwischen ICP-Smart Contracts und Cosmos-Anwendungs-Chain.
Roadmap
1. Im vierten Quartal 2024 wird das REE-Whitepaper veröffentlicht.
2. Im ersten Quartal 2025 wird das REE-Hauptnetz zusammen mit RichSwap gestartet.
3. Im zweiten Quartal 2025 wird die Exchange-Registrierung für Omnity-Partner geöffnet.
4. Im zweiten Halbjahr 2025 wird die vollständige Öffnung der Exchange-Registrierung stattfinden.
Fazit
REE stellt einen Durchbruch in der Programmierbarkeit von Bitcoin dar und ermöglicht sichere, Turing-vollständige Smart Contracts, ohne auf Cross-Chain-Assets oder Forks angewiesen zu sein. Dieses Modell der Ausführung ohne Cross-Chain hat das Potenzial, ein BTCFi-Ökosystem zu fördern, das die Liquidität und Sicherheit von Bitcoin in einer vollständig vertrauenslosen und genehmigungsfreien Umgebung nutzt.
