Con l'emergere di BTCFi, Omnity ha rilasciato un nuovo protocollo di espansione della programmabilità per Bitcoin L1 chiamato REE. In aggiunta, grazie all'esperienza pluriennale del team nella interoperabilità cross-chain (Omnity Hub), Omnity è diventato uno dei giocatori più significativi e innovativi nel campo BTCFi.
Sito ufficiale: https://www.omnity.network/
A mio avviso, la Omnity Network sta esplorando una soluzione tecnologica per l'ecologia Bitcoin che è efficiente, altamente combinabile e con un'alta tolleranza agli errori, "espansione e miglioramento della programmabilità".
1. In scenari di trading ad alta frequenza, utilizzare Omnity Hub per la soluzione cross-chain di asset Bitcoin a livello di fiducia, per passare a catene di contratti intelligenti ad alta velocità come Bitlayer, Solana, Base dove l'ecosistema è più sviluppato.
2. Negli scenari di grandi capitali e frequenze di transazione normali, l'attività DeFi viene costruita direttamente su Bitcoin L1 utilizzando REE.
Hub e REE sono indipendenti, con un'ottima combinabilità, ponendo così solide basi per l'innovazione degli sviluppatori, in attesa di innovazioni dirompenti nel campo BTCFi!
Gli interessati possono prima leggere questo articolo, per la versione originale in inglese vedere il link ⬇️
White paper di REE: https://x.com/louisliubj/status/1861588938475086166
Ecco la versione tradotta in cinese, Enjoy～
REE: un layer di esecuzione Bitcoin Turing-completo senza cross-chain
REE introduce un layer di esecuzione decentralizzato per Bitcoin, abilitando contratti intelligenti Turing-completi per le applicazioni BTCFi. Senza necessità di cross-chain, REE migliora la programmabilità della mainnet di Bitcoin, mantenendo l'esperienza utente nativa di Bitcoin.
Che cos'è REE?
L'ambiente di trading Runes Exchange Environment (REE) è un layer di esecuzione decentralizzato per Bitcoin, che offre contratti intelligenti combinabili per Bitcoin L1 senza necessità di cross-chain. REE migliora il meccanismo delle transazioni di firma multipla di Bitcoin tramite contratti intelligenti su un layer trustless, partecipando direttamente alle transazioni live della mainnet di Bitcoin.
Figura 0. Transazioni di firma multipla di Bitcoin
Le transazioni di firma multipla sono transazioni Bitcoin che includono input da più partecipanti, una tecnica utilizzata nell'ecosistema Bitcoin per anni. Di solito, un partecipante funge da coordinatore, utilizzando PSBT (transazioni Bitcoin parzialmente firmate) per aggregare le firme di ciascun partecipante, quindi trasmette la transazione alla rete Bitcoin. Alcuni casi d'uso significativi delle transazioni di firma multipla includono CoinJoin, portafogli di firma multipla e custodi.
In scenari di firma multipla, i partecipanti possono essere programmi oltre agli esseri umani. In un ambiente DeFi, i trader di solito operano con i protocolli (contratti intelligenti) come controparti. L'idea di REE è di consentire al protocollo BTCFi di partecipare a transazioni di firma multipla di Bitcoin, spostando l'intero processo di firma sulla blockchain pubblica, realizzando così la decentralizzazione.
Figura 1. Coordinazione decentralizzata delle firme multiple (DMSC)
La Figura 1 mostra il flusso generale della Coordinazione Decentralizzata delle Firme Multipla (DMSC). Questa configurazione coinvolge un trader, più protocolli BTCFi (A, B e C) e un coordinatore sulla blockchain pubblica. Il coordinatore aggrega le firme e trasmette la transazione finale.
Il processo DMSC è il seguente:
1. Fase di negoziazione
I trader avviano transazioni negoziando i termini con più protocolli. Ogni protocollo rappresenta un entità che possiede asset Bitcoin e si prepara a scambiare secondo regole specifiche. Esempi di protocolli includono exchange decentralizzati, protocolli di prestito, stablecoin, ecc.
2. Fase di firma
Dopo la negoziazione, costruire una PSBT per riflettere la transazione. Il coordinatore quindi chiama ciascun protocollo per firmare la PSBT. Ogni protocollo (A, B e C) verifica la propria parte della transazione e approva la sua inclusione con la firma.
3. Fase di broadcast
Una volta che la PSBT è completamente firmata, il Coordinatore la converte in una transazione Bitcoin e la trasmette alla rete. Così, la transazione si completa su Bitcoin.
REE ha scelto ICP (Internet Computer Protocol) come blockchain pubblica per DMSC. In altre parole, REE è l'infrastruttura DMSC per Bitcoin su ICP.
Perché REE?
Bitcoin è la blockchain più sicura e decentralizzata al mondo, ma la sua limitata programmabilità ne limita l'uso in applicazioni finanziarie complesse. REE integra la programmabilità avanzata e contratti intelligenti Turing-completi, completando le esistenti soluzioni L2 di Bitcoin, mantenendo l'auto-custodia e minimizzando le ipotesi di fiducia.
Figura 2. REE non è Bitcoin L2
A differenza della maggior parte delle L2, i contratti intelligenti di REE interagiscono direttamente con il modello UTXO di Bitcoin, realizzando un'alta programmabilità mentre mantengono l'auto-custodia. I trader non devono bloccare i loro asset Bitcoin su ponti cross-chain. Interagiscono con i contratti intelligenti firmando la PSBT con il loro wallet Bitcoin e completando immediatamente la liquidazione delle transazioni su Bitcoin.
D'altra parte, tra le soluzioni conosciute di miglioramento della programmabilità di Bitcoin L1, DMSC ha un vantaggio significativo rispetto ad altre soluzioni. Utilizza blockchain pubbliche moderne per migliorare la programmabilità di Bitcoin, anziché dipendere da nuovi codici operativi. Inoltre, DMSC può essere compatibile con tutti gli asset basati su metaprotocollo UTXO senza necessità di aggiornare metaprotocollo e indicizzatori.
Tabella 1. Confronto delle soluzioni tecniche per la programmabilità di Bitcoin L1
Infine, ICP potrebbe essere la blockchain più adatta per DMSC. REE sfrutta la tecnologia Chain Fusion di ICP per gestire in sicurezza le chiavi private e le firme Bitcoin, abilitando DMSC mantenendo il modello di sicurezza di Bitcoin. Grazie all'integrazione nativa di Bitcoin di ICP e all'indicizzatore on-chain, REE è compatibile in modo trustless con Runes (il metaprotocollo Bitcoin basato su UTXO più ampiamente accettato).
Come funziona REE?
Influenzati da Ethereum, la stragrande maggioranza dei modelli di stato delle piattaforme di contratti intelligenti è basata su account, il che influenza anche il modo di pensare degli sviluppatori di contratti intelligenti. Tuttavia, lo stato on-chain di Bitcoin è basato su UTXO. REE introduce il modello Exchange-Pool per colmare questa differenza. Il modello Exchange-Pool si adatta alla gestione dello stato UTXO di Bitcoin e può essere facilmente implementato su blockchain pubbliche basate su account come ICP. Questo modello è composto da tre semplici concetti:
1. Coin è l'unità degli asset Bitcoin basati su UTXO. BTC e Runes sono accettati come Coin in REE.
2. Exchange è un'istanza del protocollo BTCFi che opera sulla piattaforma REE, utilizzata per facilitare lo scambio di Coin.
3. Un pool di fondi è la chiave pubblica (Chain Key) utilizzata dall'Exchange per detenere Coin e firmare transazioni Bitcoin. In base alla logica dell'Exchange, l'utente inserisce un sacchetto di Coin nel pool e riceve un altro sacchetto di Coin. Di solito, un Exchange gestisce più pool, ognuno con dati sui Coin e sullo stato.
I costruttori di Bitcoin possono ora creare protocolli BTCFi diversificati utilizzando l'Exchange di REE, realizzando contratti intelligenti ICP di diversi metodi pubblici.
Figura 3. Architettura di REE
La Figura 3 illustra il processo di completamento di una transazione Bitcoin su REE, coinvolgendo più componenti come due Exchange, il coordinatore REE e l'interfaccia frontend. Di seguito è riportata una suddivisione passo-passo del processo:
1. Richiesta di prezzo: il trader avvia il processo tramite l'interfaccia frontend, effettuando una richiesta di transazione. Questo può comportare la scelta del tipo di transazione o operazione che desidera eseguire, come scambiare su ExchangeA e poi mettere in stake su ExchangeB.
2. Costruire PSBT: una volta che il trader accetta i termini della transazione, il frontend costruisce la PSBT con l'aiuto del SDK Typescript di REE.
3. I trader firmano la PSBT: i trader esaminano e firmano la PSBT con il loro wallet Bitcoin, approvando essenzialmente la transazione per il successivo trattamento.
4. Chiamata all'Orchestrator/Coordinatore: il frontend invia la PSBT all'Orchestrator/Coordinatore REE. L'Orchestrator/Coordinatore REE funge da coordinatore, supervisionando l'esecuzione delle transazioni.
5. Controllo degli input: prima che l'Orchestrator/Coordinatore esegua una transazione REE, tutti gli input PSBT devono essere verificati per garantire che siano spendibili e contengano effettivamente gli asset dichiarati. L'Orchestrator/Coordinatore si affida all'Ord Canister (indicizzatore on-chain di Runes) per completare questa operazione.
6. L'Exchange firma la PSBT: dopo la verifica, l'Orchestrator/Coordinatore REE comunica con l'Exchange pertinente per firmare la PSBT. L'Exchange verifica che i dati PSBT soddisfino le proprie condizioni di transazione e firma uno dopo l'altro.
7. Broadcast della transazione: dopo che tutti gli Exchange pertinenti hanno firmato la PSBT, il coordinatore REE trasmette la transazione completamente firmata alla rete Bitcoin. La transazione viene quindi confermata sulla blockchain di Bitcoin, completando l'intero processo.
L'Orchestrator/Coordinatore REE è responsabile di garantire la coerenza dello stato, notificando l'Exchange di fare rollback dello stato qualora qualsiasi Exchange rifiuti di firmare.
Prima che chiunque utilizzi l'Exchange, deve essere inizializzato dal suo costruttore:
1. Distribuzione (passo 0.1): i costruttori distribuiscono il canister Exchange nella stessa sottorete ICP dell'Orchestrator/Coordinatore REE. Sebbene il canister possa chiamare cross-subnet, ciò comporta ritardi non necessari.
2. Registrazione (passo 0.2): i costruttori registrano l'Exchange presso l'Orchestrator/Coordinatore REE.
I costruttori di Exchange sono responsabili della manutenzione dell'Exchange, inclusi aggiornamenti e cicli di ricarica per mantenerne il funzionamento. Omnity fornirà ai costruttori di Exchange strutture generiche per facilitare l'uso, ma sono tutte opzionali e sostituibili.
Caratteristiche del sistema
Programmabilità
L'Exchange REE è un contratto intelligente ICP indipendente, in grado di sfruttare appieno le funzionalità della blockchain sottostante. Si consiglia ai lettori di consultare la documentazione tecnica di ICP per ulteriori informazioni sullo sviluppo di contratti intelligenti ICP.
Documentazione tecnica ICP:
https://internetcomputer.org/docs/current/home
Ecco alcuni suggerimenti:
1. Calcoli intensivi come il riconoscimento facciale possono essere eseguiti all'interno dei contratti intelligenti di ICP:
https://medium.com/dfinity/the-next-step-for-deai-on-chain-inference-enabling-face-recognition-589183203fc2
2. Il contenitore di Bitcoin su ICP potrebbe essere il contratto intelligente più grande al mondo, occupando 500 GB di storage on-chain, con un costo annuale di soli 2500 dollari.
https://github.com/dfinity/bitcoin-canister
3. Omnity Hub è un stack di interoperabilità on-chain completamente on-chain su ICP, il che significa che non è necessario alcun relay o indicizzatore off-chain. Omnity Hub si connette direttamente a decine di blockchain eterogenee tramite un'interfaccia RPC.
https://explorer.omnity.network/
Combinabilità
La combinabilità dei contratti intelligenti di REE garantisce un'integrazione fluida tra protocolli, realizzando protocolli finanziari innovativi combinando liquidità e unità logiche in un framework di fiducia minimizzata.
REE offre combinabilità in stile Bitcoin. Ogni exchange si preoccupa solo di cosa riceve (input) e cosa offre (output); finché gli input/output sono ragionevoli, accetta di partecipare alla transazione. Le transazioni REE possono coinvolgere più exchange, ognuno dei quali riceve e contribuisce con alcune monete. Con la collaborazione degli exchange, il coordinatore è responsabile di garantire l'atomicità delle transazioni di firma multipla. La combinabilità atomica significa che le transazioni di firma multipla devono avere successo completamente o tornare completamente indietro in caso di fallimento di qualsiasi parte. Questo è fondamentale nelle applicazioni DeFi.
Di solito, i trader forniscono l'input iniziale al primo exchange; l'output del primo exchange entra nel secondo exchange, e così via fino all'output finale dell'ultimo exchange dato al trader. L'ordine delle firme PSBT segue questa logica: il primo exchange accetterà di fornire il proprio input e firmare la PSBT solo se il trader ha già firmato il proprio input, e così via.
Concettualmente, la combinabilità degli exchange appare come comandi Unix pipelined. Tuttavia, non è solo questo. Qualsiasi entità (trader o exchange) può fornire input ad altre entità senza considerare l'ordine. Ad esempio, l'input del trader può andare al secondo o successivi exchange; l'exchange fornisce input iniziali e commissioni di rete Bitcoin al posto del trader.
Inoltre, i trader non devono necessariamente essere individui; possono essere processi off-chain o contratti intelligenti ICP. Questo apre possibilità per aggregatori di rendimento on-chain o off-chain o bot di arbitraggio. Con il potente stack Chain Fusion, l'Exchange REE può interagire con altre blockchain. Ad esempio, i cambiamenti di stato su Ethereum o Solana possono attivare transazioni REE e viceversa.
Profilo di rischio
Il ricevente (il trader che transaziona con il pool di fondi) esamina la PSBT che contiene tutti i termini della transazione, rappresentati dagli input e output, prima della firma. Dopo la firma, nessuno, inclusi il trader stesso, l'exchange, REE, i nodi ICP e i minatori Bitcoin, può modificare la transazione. In altre parole, il ricevente non assume alcun rischio di custodia.
Di solito, l'esecuzione di ogni transazione REE comporta una modifica dello stato di un pool di fondi specifico, rendendo obsoleti i termini di transazione ottenuti da query precedenti. Considerando che il ritardo nell'esecuzione delle transazioni REE (in secondi) è molto inferiore a quello di Bitcoin (in minuti), le transazioni REE vengono generalmente elaborate in sequenza. Tuttavia, quando più trader negoziano contemporaneamente con lo stesso pool di fondi, possono verificarsi fallimenti delle transazioni.
Il fallimento di una transazione non comporta perdite di asset; il trader deve solo rieseguire la query e tentare nuovamente l'esecuzione.
I market maker (trader che forniscono liquidità ai pool di fondi) assumono rischi di custodia quando trasferiscono il controllo degli asset all'exchange. Pertanto, affrontano rischi legati ai contratti intelligenti dell'Exchange, il che sottolinea l'importanza dell'audit e della reputazione dei costruttori di Exchange.
Le ipotesi di sicurezza per i market maker includono ICP e la piattaforma REE. Tuttavia, la sicurezza di ICP (valore di miliardi di dollari) soddisfa i requisiti di sicurezza del protocollo BTCFi in tutte le circostanze conosciute.
Coerenza dello stato di Bitcoin
Le limitazioni degli script di Bitcoin nel supportare BTCFi non derivano solo dalle limitazioni funzionali dei codici operativi, ma in larga misura dalla loro incapacità di mantenere stati complessi on-chain. Al contrario, gli exchange in REE possono mantenere e gestire facilmente lo stato. Tuttavia, lo stato dell'exchange REE deve alla fine essere coerente con Bitcoin; altrimenti, le transazioni REE non possono essere liquidate su Bitcoin.
Per prevenire il fallimento della liquidazione, il coordinatore verifica che tutti gli input di transazione non siano stati già spesi. Ogni exchange verifica anche che gli input e gli output delle transazioni soddisfino i propri standard. Questo approccio garantisce che solo input validi e verificati vengano utilizzati per liquidare le transazioni.
Tuttavia, anche se questi input vengono verificati prima dell'esecuzione della transazione, non c'è garanzia di liquidazione dopo. I trader possono intenzionalmente o involontariamente utilizzare gli stessi input per un'altra transazione Bitcoin.
REE deve percepire i cambiamenti in tempo reale nella rete Bitcoin e rispondere di conseguenza. Con l'integrazione nativa di Bitcoin e il supporto di un indicizzatore Runes on-chain, REE potrebbe essere l'unico layer di esecuzione Bitcoin a realizzare questo obiettivo senza dipendere da processi centralized off-chain.
Figura 4. Stato delle transazioni REE
L'Orchestrator/Coordinatore REE è il componente che gestisce l'intero ciclo di vita delle transazioni REE. È responsabile della notifica degli eventi di cambiamento di stato pertinenti all'Exchange.
Figura 5. Gestione dello stato del pool di fondi
Gli Exchanges gestiscono lo stato dei pool di fondi. In particolare, lo stato del pool di fondi dovrebbe essere organizzato come una catena di stati collegati da una sequenza di transazioni eseguite su quel pool di fondi. I pool di fondi elaborano sempre le richieste di query e eseguono nuove transazioni in base all'intestazione della catena di stati. I pool di fondi eseguono la chiusura o il rollback in base alle notifiche di eventi provenienti dall'Orchestrator/Coordinatore.
Inoltre, data l'alta volatilità delle commissioni della rete Bitcoin, non esiste un metodo economicamente fattibile per garantire che le transazioni vengano incluse in un determinato intervallo temporale. In caso di aumento delle commissioni della rete Bitcoin, ci sono due metodi per accelerare la liquidazione: RBF (Replace-By-Fee) e CPFP (Child Pays for Parent). RBF richiede di ricostruire la transazione, il che porta a una cattiva esperienza utente.
REE utilizza CPFP, il che significa che quando le commissioni della rete Bitcoin aumentano, le transazioni successive devono sovvenzionare le transazioni precedenti non incluse nello stesso pool di fondi. La sovvenzione delle commissioni rimane un meccanismo di mercato libero: i trader avvieranno transazioni successive solo se si aspettano di guadagnare nonostante l'aumento dei costi.
Prestazioni
Le prestazioni di un layer di esecuzione sono solitamente misurate da due metriche: throughput (in termini di TPS) e latenza. Su REE, i trader possono eseguire transazioni in sequenza con solo pochi secondi di latenza, senza dover attendere la conferma del blocco per procedere. In termini di latenza, REE ha migliorato le prestazioni di Bitcoin di 100 volte.
Le transazioni seriali di REE saranno liquidate in forma batch sulla catena di Bitcoin. Poiché una transazione nel mempool può avere al massimo 25 transazioni successive, ogni blocco di Bitcoin può liquidare fino a 25 transazioni per un singolo pool di transazioni REE. Pertanto, 25 può essere considerato il limite massimo di throughput per un singolo pool di transazioni REE.
Diverse piscine di transazione possono realizzare esecuzioni parallele delle transazioni. Quando la concorrenza di prezzo non è necessaria, i costruttori di Exchange possono aggiungere piscine ridondanti per aumentare la concorrenza. Ad esempio, distribuire token su 10 piscine per un airdrop con 100.000 destinatari può ridurre significativamente la probabilità di fallimento delle transazioni dovuto a più utenti che richiedono allo stesso tempo.
In un singolo pool di transazioni, è possibile ottenere concorrenza interna gestendo più UTXO che detengono lo stesso tipo di moneta. Tuttavia, ciò richiede algoritmi di selezione, suddivisione e fusione UTXO più complessi. Gli exchange futuri potrebbero esplorare queste tecnologie avanzate per fornire una migliore esperienza utente.
Costi
I principali costi per gli utenti di REE derivano dalle commissioni della rete Bitcoin. REE minimizza le dimensioni delle transazioni di liquidazione utilizzando il tipo di indirizzo P2TR.
I costi di gestione dell'Exchange su ICP ricadono sui costruttori (cicli). Sebbene ICP sia molto conveniente, i costruttori devono generare entrate all'interno o all'esterno del protocollo per garantire la sostenibilità economica del loro Exchange.
MEV
REE è un layer di esecuzione che delega l'ordinamento delle transazioni al contenitore dell'Orchestrator/Coordinatore REE situato nella sottorete ICP. Sebbene possa essere teoricamente possibile, è inusuale che i nodi della sottorete ICP estraggano MEV riordinando le transazioni.
È importante notare che non esiste il concetto di slippage su REE; quando il trader firma la PSBT, tutti gli input e output della transazione sono già impostati. Se l'input dal pool di fondi dell'Exchange è stato speso, la transazione fallirà. Pertanto, se una transazione REE viene frontrun, fallirà automaticamente, lasciando il frontrunner a sopportare il rischio di prezzo da solo.
Governance
REE sarà gestita dal DAO SNS di Omnity, responsabile della supervisione degli aggiornamenti dei protocolli, dell'aggiustamento dei parametri e della roadmap di sviluppo. La governance on-chain di SNS assicura la trasparenza dello sviluppo sostenibile dell'ecosistema REE e decisioni guidate dalla comunità.
Casi d'uso
Copiare protocolli DeFi da Ethereum o Solana a Bitcoin è un modo diretto per sfruttare REE. Ecco alcuni esempi per dettagliarlo.
AMM DEX (scambio decentralizzato di market maker automatici)
RichSwap, un AMM DEX costruito da Omnity, sarà lanciato insieme alla mainnet REE. In quanto primo exchange su REE, RichSwap serve ai seguenti scopi:
1. RichSwap verifica la funzionalità e le prestazioni della piattaforma REE.
2. RichSwap è open-source e fornisce esempi completi per i costruttori di BTCFi.
3. Altri protocolli BTCFi possono utilizzare RichSwap per accelerare il bootstrap della liquidità.
4. RichSwap ha un meccanismo di cattura del valore dei token integrato, che può essere sfruttato da altri protocolli BTCFi.
Sebbene RichSwap sia il primo exchange, non gode di alcun privilegio. Dopo il lancio della mainnet, REE transiterà rapidamente verso una piattaforma aperta, accettando registrazioni BTCFi senza permesso per qualsiasi protocollo conforme alle specifiche tecniche (incluso AMM DEX).
Prestiti
I protocolli di prestito basati su REE possono supportare più pool di fondi, ciascuno con configurazioni, parametri di rischio e tipi di supporto degli asset diversi. Ogni pool di fondi, supportato da blue-chip Runes per prendere in prestito BTC, può avere tassi di interesse, tassi di collateralizzazione e soglie di liquidazione diversi. Potrebbe scegliere di restituire un atoken ai fornitori di liquidità (LPs). Integrandosi con oracoli su ICP, il protocollo di prestito può determinare decentralmente il valore dei collaterali o attivare il processo di liquidazione.
Token di staking liquido
Implementare staking di Bitcoin L1 su REE è fattibile, ma l'integrazione di protocolli di staking esistenti (come Babylon) è una possibilità molto più interessante. Gli utenti depositano Bitcoin nell'Exchange e ricevono LST in formato Runes. Poi l'Exchange LST viene combinato con il protocollo di staking Babylon su Bitcoin L1, gestendo contemporaneamente deleghe e ricompense di staking sulla catena Babylon tramite protocolli cross-chain trustless. Omnity Hub è già integrato con Osmosis tramite architettura completamente on-chain e verifica client leggeri. Pertanto, le interazioni tra contratti intelligenti ICP e le applicazioni della catena Cosmos non affrontano più barriere tecniche.
Roadmap
1. Nel quarto trimestre del 2024, rilascio del white paper REE.
2. Nel primo trimestre del 2025, lancio della mainnet REE insieme a RichSwap.
3. Nel secondo trimestre del 2025, apertura della registrazione per Exchange ai partner di Omnity.
4. Nella seconda metà del 2025, registrazione completa aperta per Exchange
Conclusione
REE rappresenta una svolta nella programmabilità di Bitcoin, realizzando contratti intelligenti sicuri e Turing-completi senza dipendere da asset cross-chain o fork. Questo modello di esecuzione senza cross-chain ha il potenziale di coltivare un ecosistema BTCFi che sfrutta la liquidità e la sicurezza di Bitcoin in un ambiente completamente trustless e permissionless.
