Espansione Cross-chain via Wormhole

[OmarOneKenobi]

Panoramica
Wormhole è entusiasta di presentare la sua proposta per consentire depositi e prestiti cross-chain. Il team di Wormhole ha già creato un esempio di riferimento per Venus e si impegna ad aiutare a costruire la soluzione completa fornendo allo stesso tempo supporto continuo su prodotti e smart contracts a Venus e alla sua comunità. (Github 10)

Prima di ciò, una rapida introduzione a Wormhole: Wormhole è il principale protocollo di interoperabilità cross-chain, che consente la messaggistica generica su 15 blockchain eterogenee e presto ne saranno molte di più. In effetti, abbiamo appena annunciato il nostro lancio su Aptos devnet.

Dal lancio sulla rete principale nell’agosto 2021, sono stati trasmessi 1,2 milioni di messaggi. Alcuni sono messaggi regolari (ad es. Dati di Pyth Oracle), altri sono token bridge e tutto l’utilizzo è avvenuto in modo organico, senza correzioni.

Venus è un progetto fondamentale per l’ecosistema BNB. Crediamo che Wormhole sia la migliore soluzione a catena incrociata per Venere per 3 ragioni chiave:

1. Progettazione e implementazione robuste: i dettagli contano, in particolare nel contesto di un protocollo complesso che fungerà da livello fondamentale per lo sviluppo futuro e le applicazioni componibili. Il team di Wormhole ha riflettuto a fondo su questo nuovo paradigma e successivamente ha costruito un esempio di riferimento, in particolare per Venere.

2. Modello di sicurezza e decentramento — Wormhole ha diciannove tutori composti dai principali validatori PoS che attestano congiuntamente i messaggi. Ogni tutore ha lo stesso peso nella governance e nel consenso. Wormhole richiede che oltre due terzi dei 19 guardiani ottengano consenso e superino la verifica, quindi assumiamo che almeno un terzo del nostro set di guardiani sia degno di fiducia.
   Wormhole ha un piano di sicurezza completo, uno dei più grandi programmi di bug bounty ($ 10 milioni e oltre), inclusi 5 audit di qualità (ad es. Neodyme, Kudelski, Ottersec) della sua base di codice completa (audit di Certik , Trial Bit, ecc. in corso).

3. Stack di integrazione semplificato e consolidato: Pyth andrà a cross-chain tramite Wormhole; quindi l’integrazione pianificata di Venus con Pyth 2 comporterà la dipendenza da Wormhole. Con questa dipendenza in atto, sarà ottimale utilizzare Wormhole per altri elementi degli obiettivi cross-chain di Venus invece di introdurre una nuova serie di dipendenze ponte(bridging) e ipotesi di fiducia(trust assumption). L’integrazione di Wormhole semplificherebbe anche la futura manutenzione del meccanismo dell’oracolo, poiché l’oracolo e la messaggistica generica a catena incrociata sarebbero dettati dagli stessi standard di interoperabilità sottostanti.

Considerazioni sul design
La qualità del design conta molto. Ci sono una serie di dettagli importanti che determinano la dinamica del deposito-prestito cross-chain; riflettere e definire in anticipo questi dettagli è vitale per qualsiasi proposta di integrazione.
Wormhole ha passato molti cicli a pensare a questa genere di applicazioni cross chain e prevediamo diverse opzioni che bilanciano complessità e funzionalità.

Lo status quo è semplice: per quasi tutti i protocolli di prestito, non ci sono capacità cross-chain. Ogni catena è isolata e gli utenti che desiderano prendere in prestito e prestare su blockchain diverse devono gestire e monitorare saldi separati su contratti e protocolli diversi. Il mutuatario nello scenario seguente non è in grado di depositare ETH su Ethereum e prendere in prestito SOL da Solana.

Come può Venus andare cross-chain ? Esistono numerose possibilità e il team di Wormhole è aperto a collaborare con Venus per sviluppare implementazioni sequenziali o mirare allo sviluppo dell’implementazione più complessa sin dall’inizio. Suggeriamo di lasciare questa decisione ai possessori di XVS e incoraggiare i delegati di Venus a discutere i meriti di ogni approccio. Esistono due varianti principali: volte a cross-chain e multi-chain.

Vault in single-chain

Nell’implementazione di base, Wormhole potrebbe abilitare pool di garanzie a single-chain, in cui un utente può depositare garanzie su una qualsiasi catena e prendere in prestito su qualsiasi altra catena e viceversa. Pyth trasmetterebbe contemporaneamente i prezzi al protocollo, consentendo il monitoraggio delle garanzie sulla catena di origine. Gli utenti rimborseranno il prestito sulla catena da cui hanno preso in prestito i token e quindi ritireranno la loro garanzia sulla catena di origine. Illustriamo il flusso di lavoro di seguito.

Vault multi-chain

Passando a una resa più sofisticata: un mutuatario può cercare di depositare due o più forme separate di garanzia su due o più catene distinte. Qui abbiamo pool di garanzie multi-chain su qualsiasi catena supportata che consente agli utenti di prendere in prestito su una catena designata. Gli utenti rimborseranno il prestito sulla catena di prestito designata e quindi ritireranno ogni forma di garanzia sulle rispettive catene. Illustriamo il flusso di lavoro di seguito.

Il caso due introduce ulteriore complessità nel progetto poiché ora dobbiamo sincronizzare più di due catene. I mutuatari potrebbero prendere in prestito da una catena designata mentre forniscono garanzie su catene eterogenee. Qui dobbiamo solo tenere conto della garanzia fornita su tutte le altre catene della catena selezionata su cui gli utenti prendono in prestito risorse, ma ogni altra catena deve solo tenere traccia della garanzia fornita sulla rispettiva catena. L’utente avvia quindi il prestito su ciascuna catena di prestito, suddividendo il prestito totale del mutuatario su base per garanzia. Questo design ci consente di mantenere le liquidazioni su ciascuna catena di mutuatari poiché il liquidatore potrebbe verificare se il rapporto tra le garanzie su quella catena e l’importo preso in prestito originato da quella catena è inferiore al rapporto di liquidazione.

Esempio di riferimento
Forniamo un esempio di riferimento su come i depositi a single-chain potrebbero funzionare con BNB ed Ethereum. (Si prega di notare che questa è una prova di concetto poco testata e non dovrebbe essere utilizzata nella produzione). Consentiamo di utilizzare 1 token ERC-20 come garanzia su BNB e un altro token ERC-20 da prendere in prestito su Ethereum e viceversa. Questo design potrebbe quindi essere adattato per integrarsi con la base di codice Venus esistente.

Nel nostro esempio, un utente può depositare BUSD su BNB come garanzia e prendere in prestito WETH su Ethereum utilizzando le seguenti funzioni:

1. L’utente chiama prima addCollateral(collateralAmount) nel contratto BNB con l’importo di BUSD che vorrebbe fornire. Questo trasferisce l’importo della garanzia al contratto e quindi questo importo si riflette nelle attività depositate del loro conto e nella liquidità totale in BUSD nel contratto.
2. Quindi l’utente chiama initialBorrow(borrowAmount) nel contratto BNB con l’importo di WETH che vorrebbe prendere in prestito su Ethereum. Questo calcolerà l’importo massimo di WETH che possono prendere in prestito in base al rapporto di garanzia per BUSD/WETH e quindi invierà un messaggio al contratto Wormhole su BNB.
3. Quindi l’utente chiama initialBorrow(borrowAmount) nel contratto BNB con l’importo di WETH che vorrebbe prendere in prestito su Ethereum. Questo calcolerà l’importo massimo di WETH che possono prendere in prestito in base al rapporto di garanzia per BUSD/WETH e quindi invierà un messaggio al contratto Wormhole su BNB.

L’utente può quindi rimborsare il prestito WETH su Ethereum e riavere la propria garanzia BUSD su BNB come segue

1. L’utente chiama prima initialRepay(borrowAmount) nel contratto Ethereum con l’importo del prestito che desidera rimborsare. Per rimborsare l’intero prestito l’utente può anche chiamare initialRepayInFull(). Ciascuna di queste funzioni trasferirà il rimborso al contratto e aggiornerà le attività prese in prestito del conto e la liquidità WETH totale nel contratto. Verrà quindi inviato un messaggio al contratto Wormhole su Ethereum, indicando quanto del prestito è stato rimborsato.

2. Infine, l’utente chiama completeRepay(signedWormholeMessage) nel contratto BNB con il messaggio Wormhole firmato prodotto nel passaggio 1. Il messaggio viene quindi decodificato e verificato se il prestito è stato completamente rimborsato. Se è stato richiamato e completeRepay è stato richiamato entro il periodo di grazia definito, le attività prese in prestito del conto verranno impostate a zero e la liquidità WETH nel contratto BNB verrà ridotta dell’importo rimborsato. Se completeRepay non è stato chiamato entro il periodo di grazia, verrà inviato un messaggio al contratto Wormhole su BNB, identificando che il prestito non è stato rimborsato in tempo. Se il prestito non è stato completamente rimborsato, le attività prese in prestito dal conto e la liquidità WETH tracciata nel contratto BNB verranno ridotte dell’importo rimborsato.

Sebbene non implementiamo le liquidazioni nel nostro esempio di riferimento (forniamo un flusso di lavoro di esempio), il liquidatore dovrebbe:

1. Call initiateLiquidationOnTargetChain on the BNB contract which should determine if a particular position is undercollateralized by querying the accountAssets state variable for the passed account. If an account is undercollateralized, this method should generate a Wormhole message sent to the Wormhole contract on BNB.
2. call completeRepayOnBehalf(signedMessage) su Ethereum con il messaggio Wormhole firmato prodotto quando chiami initialLiquidationOnTargetChain. Se il mutuatario non ha ancora rimborsato il prestito entro il momento in cui il messaggio Wormhole arriva sulla catena target, questa funzione trasferirà i fondi presi in prestito dovuti dal liquidatore al contratto e invierà un altro messaggio Wormhole al contratto Wormhole su Ethereum. Come con la funzione completeReplay, dovrebbe esserci la funzionalità di ripristino con un messaggio di ritorno alla catena di origine se il mutuatario ha già rimborsato il prestito.
3. call completeLiquidation(signedMessage) su BNB con il messaggio Wormhole firmato, prodotto quando chiami completeRepayOnBehalf. La garanzia del mutuatario verrebbe quindi inviata al liquidatore meno le spese di liquidazione determinate dal protocollo.
4. Nota: affinché un liquidatore possa vedere lo stato delle posizioni, una funzione dovrebbe restituire l’elenco di indirizzi con posizioni aperte e un’altra funzione che consente di interrogare la variabile di stato accountAssets per un determinato conto.

Integrazione con Venere
Venus potrebbe potenzialmente integrare Wormhole con le seguenti aggiunte al codebase:

• mantenere l’infrastruttura esistente attorno all’ingresso e all’uscita dai mercati poiché questi metodi consentono esclusivamente all’utente di provare a prendere in prestito queste attività
• poiché stiamo monitorando i depositi sulla catena di origine (nel primo modello), possiamo mantenere la funzione mintFresh così com’è
• aggiungi la logica di initialBorrow in una nuova funzione loanFreshXChain che imita la logica di loanFresh 1 ma invece di trasferire l’importo del token preso in prestito all’utente, la funzione invierà un messaggio al contratto Wormhole su BNB come mostrato nella funzione initialBorrow nell’esempio di riferimento
• aggiungi la logica completeBorrow in una funzione completeBorrowXChain che consente a un relayer/utente di inviare il messaggio Wormhole firmato al contratto VToken.sol su Ethereum che trasferirà effettivamente i fondi presi in prestito all’utente
• aggiunge la logica di rimborso in una funzione repayBorrowFreshXChain che imita la logica di repayBorrow ma invece di trasferire i token presi in prestito più gli interessi al contratto, la funzione invierà un messaggio al contratto Wormhole su Ethereum come mostrato nella funzione di rimborso nell’esempio di riferimento
• aggiungi la logica completeReplay in una funzione completeReplayXChain che consente a un relayer/utente di inviare il messaggio Wormhole firmato al contratto VToken.sol su BNB che restituirà il collaterale all’utente

Decentramento e sicurezza
Wormhole si basa su un consenso PoA con 19 tutori. Ogni tutore gestisce il proprio nodo per ciascuna catena e ha lo stesso peso nella governance e nel voto. Dei 19 guardiani, Wormhole richiede più di due terzi per raggiungere il consenso e superare la verifica, quindi presumiamo che almeno un terzo del nostro set di guardiani sia onesto. Il nostro set di guardiani comprende i principali validatori PoS con miliardi di delegazioni attive nelle più grandi catene PoS: P2P, Chorus One, Everstake, Staked.us solo per citarne alcuni.

Tuttavia, nonostante l’alto grado di decentramento di Wormhole, rimaniamo risoluti nel migliorare i nostri presupposti di fiducia: in quanto tali, stiamo investendo ingenti investimenti nel passaggio a un sistema completamente senza fiducia basato su prove di conoscenza zero 1.

Solo negli ultimi 90 giorni, Wormhole ha trasmesso oltre 300.000 messaggi. Wormhole ha gestito con facilità alcuni dei recenti periodi di volatilità della DeFi, facilitando 44.000 messaggi in un solo giorno. Il nostro collaudato protocollo senza autorizzazione si è guadagnato la fiducia di alcuni degli sviluppatori più rinomati del settore.

Infine, riconosciamo che Wormhole ha guadagnato un po’ di stampa per l’hacking nel febbraio di quest’anno: crediamo che Wormhole sia più forte per questo. Wormhole, ad esempio, ha i programmi di ricompense dei bug più generosi in criptovalute - oltre $ 10 milioni e oltre - inclusi 5 audit di qualità 1 (ad es. Neodyme, Kudelski, Ottersec) della sua base di codice completa (audit di Certik, Trail of Bits, ecc. in corso). Wormhole continuerà su entrambi questi fronti in modo da mantenere elevati standard di sicurezza per i suoi utenti e protocolli negli ecosistemi supportati.

Dipendenza esistente
Venus si integrerà presto con Pyth per fornire dati sui prezzi di alta qualità ai suoi feed di prezzo e garantire liquidazioni tempestive e precise. Poiché Pyth su BNB prevede lo streaming dei prezzi da Pythnet tramite Wormhole, tale integrazione creerebbe già un’integrazione a valle tra Venus e Wormhole. Con questa dipendenza in atto, ha senso usare Wormhole per altri elementi degli obiettivi a catena incrociata di Venus, incluso il prestito cross-chain. Oltre a rimuovere la necessità di un diverso insieme di presupposti di attendibilità del bridge, l’integrazione di Wormhole potrebbe anche semplificare la futura manutenzione del meccanismo dell’oracolo, poiché i requisiti fondamentali di interoperabilità regolerebbero sia l’oracolo che la messaggistica a catena incrociata.

Non vediamo l’ora di impegnarci con la comunità di Venus sulla nostra proposta.

Hendrik

• Fondazione Wormhole