Lompat ke konten
Financial Context Wiki

Cara mengoperasikan transfer lintas chain dengan aman

Runbook tingkat akun untuk memverifikasi rute bridge, kuotasi, allowance, transfer uji, state pesan, jalur retry atau refund, token yang diterima, dan ledger ekonomi akhir.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Transfer lintas chain yang aman adalah jejak bukti, bukan satu konfirmasi dompet. Tentukan dahulu aset yang tepat dan state akhir yang dapat digunakan; verifikasi rute dan kuotasi yang dapat dieksekusi; berikan hanya kewenangan yang diperlukan; selesaikan pengujian terbatas; kirim satu kali; lacak state sumber, pesan, dan tujuan secara terpisah; lalu rekonsiliasi kontrak yang benar-benar diterima, izin, serta hasil ekonominya.

Arsitektur protokol dibahas dalam analisis bridge lintas chain. Checklist ini memakai dokumentasi terkini dari rute yang dipilih dan mengubahnya menjadi runbook tingkat akun. Debit di bursa kustodian yang diikuti penarikan pada jaringan lain adalah alur kerja counterparty yang berbeda, bukan otomatis bridge onchain. Tidak ada rute, pengujian kecil, atau label resmi yang membuat transfer bebas risiko.

Checklist transfer lintas chain
0 / 5
0 item yang ditinjau; 5 item yang masih belum terselesaikan

Menyelesaikan tinjauan ini tidak membuktikan suatu aset, transaksi, atau sistem aman.

Cara kerja

  1. Tentukan otorisasi dan state akhir yang dapat digunakan. Catat aset sumber, aset dan protokol tujuan yang diinginkan, penerima, jumlah, batas kerugian, batas waktu tunggu, serta apakah token akhir harus dapat ditebus, diperdagangkan, atau diterima sebagai agunan. Jangan mulai hanya dari ticker.
  2. Kunci snapshot rute dari sumber resmi yang independen: protokol dan versi, chainId atau domain sumber dan tujuan, gateway, router, messenger, proxy, spender, pasangan token, format penerima, desimal, jumlah mentah, blok, dan timestamp. Verifikasi lagi chain dan akun aktif di dompet setelah setiap event provider chainChanged.
  3. Tinjau aturan kepercayaan dan pemulihan yang khusus untuk arah rute. Catat finality sumber yang diwajibkan, verifier atau attester, kontrol admin dan upgrade, pause dan rate limit, executor tujuan, keunikan pesan, serta jalur retry, claim, timeout, dan refund. Kaitkan semua ini dengan arsitektur bridge, bukan menyimpulkan keamanan dari namanya.
  4. Susun kuotasi yang dapat dieksekusi dan ledger pendanaan. Pisahkan pokok serta biaya protokol atau LP dalam denominasi token dari gas native di sumber dan tujuan, slippage, dampak harga, dan biaya menunggu. Catat timestamp, kedaluwarsa, kapasitas, output minimum, dan deadline kuotasi; pastikan token yang diterima dapat dipakai untuk langkah berikutnya.
  5. Batasi kewenangan dan jalankan pengujian terbatas. Verifikasi spender ERC-20 yang tepat dan allowance saat ini, permit, atau cakupan operator; simpan gas di kedua chain; tinjau value dan calldata; serta uji rute dan penerima yang sama dengan batas kerugian absolut yang telah ditetapkan. Keberhasilan kecil tidak membuktikan kapasitas rute besar atau keamanan masa depan.
  6. Sebelum transfer penuh, perbarui chain, akun, kontrak, saldo, nonce, kuotasi, allowance, state pause, dan batas. Kirim tindakan sumber satu kali dan simpan receipt, ID pesan atau nonce, referensi proof atau attestasi, serta transaksi tujuan. Lacak signed, submitted, included, finalized, ready, relayed, executed, acknowledged, failed, expired, dan refundable sebagai state yang berbeda.
  7. Diagnosis berdasarkan state dan rekonsiliasi hasilnya. Retry hanya langkah tujuan terdokumentasi yang idempoten setelah membuktikan tindakan sumber dan pesan ada, penerima belum memperoleh kredit, dan pesan belum digunakan; jangan pernah mengulang deposit atau burn secara buta. Konfirmasi token tujuan yang tepat, saldo dan jalur keluar aktual, semua biaya, sisa allowance, serta claim tertunda atau refund, kemudian cabut kewenangan berlebih dan arsipkan bukti.

Contoh perhitungan

  • Gerbang identitas unit mentah. Transfer 2,500.000000 USDC dari token terverifikasi dengan 6 decimals dikodekan sebagai 2,500 * 10^6 = 2,500,000,000 raw units. Penggunaan 18 decimals akan mengodekan 2,500,000,000,000,000,000,000, yaitu 10^12 kali jumlah mentah yang dimaksud. Alamat token sumber, spender, token tujuan, dan penerima harus diverifikasi sebelum menandatangani.
  • Ledger output dan ekonomi. Pokoknya 12,000 units; biaya protokol 18 units; dan biaya LP 24 units, sehingga output token tujuan 12,000 - 18 - 24 = 11,958 units. Gas sumber 0.004 ETH dan gas tujuan 0.0015 ETH; pada 2,500 USD/ETH, biayanya $10 dan $3.75. Jika satu unit bernilai $1, total biaya ekonomi adalah $18 + $24 + $10 + $3.75 = $55.75 dan kekayaan bersih yang diterima $11,944.25, sedangkan saldo token tetap 11,958 units.
  • Batch berurutan hanya mengubah eksposur terbatas. Memindahkan 12,000 units sekaligus menempatkan 12,000 units dalam operasi saat ini dan secara hipotetis memerlukan biaya gas tetap $9. Tiga batch berurutan berukuran 4,000-unit, dengan rekonsiliasi sebelum batch berikutnya, membatasi pokok yang sedang diproses menjadi 4,000 units, tetapi biayanya 3 * $9 = $27, atau $18 lebih mahal. Representasi bridge yang telah diterima tetap terekspos hingga ditebus atau dijual.
  • Retry tujuan yang khusus untuk produk. Dalam contoh CCTP, pengguna membakar 2,500 USDC dengan nonce pesan 41; attestasi selesai, tetapi mint tujuan pertama mengalami revert setelah menghabiskan 0.0024 ETH. Pada 2,500 USD/ETH, biayanya $6. Setelah memastikan penerima belum mendapat kredit dan nonce belum digunakan, pengguna mendanai 0.002 ETH dan mengikuti retry mint CCTP yang terdokumentasi, menambah $5; satu mint mengkreditkan 2,500 USDC, dan total gas tujuan menjadi $11. Batas retry idempoten ini tidak boleh digeneralisasi ke bridge lain.

Risiko

  • Memilih sumber, tujuan, chainId, atau domain yang salah.
  • Menggunakan rute, deployment protokol, atau versi yang salah.
  • Mengikuti antarmuka, halaman dokumentasi, atau akun dukungan phishing.
  • Memberikan approval kepada gateway, router, messenger, proxy, atau spender palsu.
  • Menerima pemetaan token yang salah atau representasi dengan simbol sama.
  • Mengirim kepada penerima, format alamat, memo, atau akun tujuan yang salah.
  • Salah membaca desimal atau unit mentah.
  • Memberikan approval, permit, atau kewenangan operator yang berlebihan.
  • Menandatangani calldata berbahaya atau native value yang tidak dimaksudkan.
  • Menggunakan kuotasi kedaluwarsa, tanpa output minimum, atau melewati deadline.
  • Melebihi kapasitas rute, rate limit, atau slippage yang dapat diterima.
  • Kekurangan gas pada chain sumber.
  • Kekurangan gas untuk claim, retry, atau refund di tujuan.
  • Mengandalkan finality sumber yang belum memadai atau blok yang direorganisasi.
  • Menunggu proof, attestasi, relayer, atau executor yang terlambat.
  • Menghadapi revert di tujuan atau akun maupun hook token yang tidak didukung.
  • Mengulang deposit, burn, atau pesan yang sudah digunakan secara buta.
  • Tidak mengetahui pause, upgrade, perubahan admin, atau configuration drift.
  • Menerima token yang tidak likuid, kehilangan patokan, tidak dapat ditebus, atau tidak didukung.
  • Salah menangani privasi, dukungan palsu, pajak, sanksi, kustodi, atau bukti pemulihan.

Kesalahpahaman umum

  • Transaksi sumber yang berhasil berarti transfer lintas chain telah selesai.
  • Token dengan ticker yang sama adalah aset dan klaim yang sama.
  • Pengujian kecil yang berhasil membuktikan transfer besar atau mendatang aman dan likuid.
  • Kanonik, resmi, cepat, atau telah diaudit berarti tanpa risiko.
  • Transfer macet seharusnya diperbaiki dengan mengulang deposit atau menghubungi admin grup.

Topik terkait

Sumber

Navigasi

Cari di wiki...