Vai al contenuto
Financial Context Wiki

Bridge canonico

Una guida orientata alla verifica dei bridge designati dal protocollo, della copertura degli asset, degli stati dei messaggi cross-domain, dei prelievi con fault proof o validity proof, dei controlli di upgrade, delle commissioni e del confronto con i bridge rapidi.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Un bridge canonico è la rotta per asset o messaggi designata da uno specifico rollup o ecosistema blockchain. Di norma collega contratti che pongono un asset in escrow o lo bruciano su una rete, trasmettono un messaggio riconosciuto dal protocollo e coniano, sbloccano o rilasciano l’asset corrispondente sull’altra rete. Il termine canonico è un’etichetta dell’ecosistema, non uno standard universale, una garanzia crittografica o la prova che sito e indirizzo siano autentici.

La sua sicurezza non è una formula additiva. Dipende congiuntamente da finalità della rete di origine, disponibilità dei dati, verifica dello stato o del messaggio, contabilità del bridge, esecuzione a destinazione, protezione dai replay, poteri di upgrade e pausa e disponibilità di un percorso di uscita. Un bridge rapido può pagare prima gli utenti con liquidità e regolare in seguito attraverso la rotta canonica, ma ciò aggiunge ipotesi su fornitore di liquidità, solver, verificatore ed esecuzione, anziché accelerare gratuitamente la stessa macchina a stati.

1
Blocca o brucia

Il contratto della catena di origine deposita in garanzia o distrugge la rappresentazione della fonte.

Come funziona

  1. Fissa l’istantanea della rotta: chainId di origine e destinazione, direzione, stack e versione del rollup, indirizzi di bridge, portal, messenger, inbox o gateway, indirizzi dei token, destinatario, importo, riferimenti ai blocchi e documentazione ufficiale. Non affidarti mai solo a un risultato di ricerca o all’etichetta ufficiale.
  2. Determina il modello di sicurezza e controllo. Registra regole di fault proof ottimistiche o validity proof, modalità di disponibilità dei dati, sequencer e percorso forzato, implementazione del proxy, amministratore o security council, timelock, stato di pausa, limiti di frequenza e ritardo di upgrade. Canonico non significa immutabile.
  3. Classifica il registro dell’asset. Distingui il valore nativo dai token ERC-20 e identifica il comportamento lock-and-mint, burn-and-release o burn-and-mint. Verifica coppia di token registrata, unità grezze, decimali, custom gateway e supporto per asset fee-on-transfer, rebasing o soggetti a denylist.
  4. Costruisci la macchina a stati dei messaggi specifica per la direzione. Un deposito può attraversare approvazione, escrow o burn all’origine, finalità all’origine, derivazione o relay e mint o sblocco a destinazione. Un prelievo può richiedere burn o escrow a destinazione, inclusione del messaggio, state commitment, prova, contestazione o accettazione della prova, finalizzazione e rilascio all’origine.
  5. Segui separatamente tre orologi: inclusione della transazione, regolamento del protocollo o finalità dello stato e disponibilità dell’asset per l’uso o il prelievo. Registra hash della transazione di origine, hash del messaggio o del prelievo, riferimento a output o prova e ogni transazione di relay, prove, finalize, claim, retry o refund.
  6. Costruisci il registro economico. Separa capitale trasferito, gas su origine e destinazione, gas di prova o finalizzazione, commissione del protocollo o del relayer, commissione del fornitore di liquidità, slippage e costo opportunità dell’attesa. Confronta bridge rapido e rotta canonica come diritti e modelli di fiducia diversi.
  7. Riconcilia la rotta completata con ricevute, eventi, saldi in escrow, offerta della rappresentazione, diritti pendenti, saldi del destinatario e allowance residue. Attendi la finalità richiesta, mantieni gas di emergenza, prova i percorsi permissionless o forzati quando applicabile e fermati invece di ripetere un deposito il cui stato del messaggio non è spiegato.

Esempi svolti

  • Registro del deposito di un asset nativo. Un utente parte con 5.0000 ETH, deposita 2.5000 ETH e paga 0.0042 ETH di gas sulla rete di origine. Il wallet di origine termina con 5.0000 - 2.5000 - 0.0042 = 2.4958 ETH; l’escrow aumenta di 2.5000 ETH; e, dopo un relay riuscito uno a uno, la rappresentazione a destinazione aumenta di 2.5000 ETH. Il rapporto di copertura è 2.5000 / 2.5000 = 100%. Escrow e rappresentazione sono copertura e diritto, non 5 ETH di nuovo valore economico.
  • Unità grezze e mappatura del token. Un utente deposita 1,250.000000 USDC. Il contratto di origine verificato usa 6 decimals, quindi l’importo grezzo è 1,250 * 10^6 = 1,250,000,000. Con una mappatura verificata uno a uno e senza commissioni del token, l’escrow all’origine e il mint a destinazione variano ciascuno di 1,250,000,000 raw units, visualizzati a destinazione come 1,250.000000 USDC. Un token con lo stesso simbolo a un altro indirizzo non costituisce una prova equivalente.
  • Gli orologi di prelievo sono distinti. Supponiamo che un deployment registri un prelievo alle 2026-08-01 12:00:00 UTC e applichi un periodo di contestazione di 604,800-second = 7-day a partire da quell’inizio definito dal protocollo. La soglia temporale è 2026-08-08 12:00:00 UTC; una transazione di prove o finalize, il gas e la politica scelta di conferma della rete di origine possono aggiungere altro tempo. Questo esempio parametrico non afferma che ogni bridge attenda sette giorni e la finalità della transazione a destinazione non rilascia da sola i fondi all’origine.
  • Quotazione della rotta rapida rispetto al costo di attesa. Per 10,000 USDC, un bridge rapido addebita 0.08% più 3 USDC, ignorando gas e slippage. Il costo è 10,000 * 0.0008 + 3 = 11 USDC e il ricavo immediato è 9,989 USDC. Rispetto a un’attesa canonica ipotetica di 7-day, il prezzo annualizzato semplice dell’accesso anticipato è (11 / 9,989) * (365 / 7) = 5.7420305193%. Il confronto non è un rendimento né un tasso privo di rischio ed esclude rischi di solver, liquidità, insolvenza e regolamento.

Rischi

  • Usare un’interfaccia di phishing o un dominio di documentazione non verificato.
  • Selezionare rete di origine o destinazione e chainId sbagliati.
  • Inviare a bridge, portal, messenger, gateway o destinatario contraffatti.
  • Accettare un token con lo stesso simbolo ma una mappatura di controparte registrata diversa.
  • Interpretare male decimali, unità grezze o comportamento di trasferimento non standard.
  • Confondere asset nativi, wrapped gas token e rappresentazioni trasferite tramite bridge.
  • Esporre un’allowance eccessiva o approvare lo spender errato.
  • Non rilevare upgrade del proxy, compromissione dell’amministratore, intervento del security council o modifica del timelock.
  • Incontrare una pausa, denylist, limite di frequenza o rotta di prelievo bloccata.
  • Trattare una ricevuta all’origine come prova che l’esecuzione a destinazione sia riuscita.
  • Finanziare insufficientemente il gas di esecuzione, retry, prove, claim o refund a destinazione.
  • Perdere un messaggio per scadenza del retry, gestione errata del refund o address aliasing.
  • Ignorare una riorganizzazione della rete di origine o una finalità insufficiente.
  • Dipendere da un sequencer che censura o non è disponibile senza un percorso forzato funzionante.
  • Perdere la disponibilità dei dati necessaria per provare, ricostruire o abbandonare lo stato.
  • Accettare una state root, prova del messaggio, nullifier o condizione di replay non validi.
  • Dipendere da proposer, prover, challenger o finalizer permissioned non disponibili.
  • Interpretare male un parametro di contestazione, maturità o accettazione della prova dopo un upgrade.
  • Subire insolvenza dell’escrow, divergenza contabile, depeg del token o illiquidità a destinazione.
  • Aggiungere rischi di bridge rapido, aggregatore, verificatore, LP, solver, slippage, imposte e sanzioni.

Idee errate comuni

  • Canonico è uno standard universale e significa automaticamente trustless o privo di rischio.
  • Una transazione riuscita all’origine o un saldo apparso nella UI dimostrano il regolamento definitivo.
  • Ogni prelievo da rollup prevede lo stesso periodo di attesa di sette giorni.
  • Escrow all’origine e rappresentazioni a destinazione possono essere sommati come TVL indipendente.
  • Un bridge rapido è semplicemente lo stesso bridge canonico con un’impostazione di velocità.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...