Lompat ke konten
Financial Context Wiki

Risiko tanda tangan Permit2

Permit2 memisahkan allowance yang dapat digunakan berulang kali dari transfer tanda tangan sekali pakai; penandatanganan yang aman memerlukan verifikasi deployment, domain, spender, penerima, jumlah, nonce, tenggat, witness, dan calldata eksekusi secara tepat.

Diperbarui

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

Jawaban langsung

Permit2 menggabungkan dua sistem otorisasi yang berbeda. AllowanceTransfer menyimpan allowance yang dapat digunakan kembali untuk owner-token-spender beserta jumlah, masa berlaku, dan nonce berurutan. SignatureTransfer menghabiskan maksimum yang ditandatangani untuk satu kali penggunaan dengan nonce bitmap tak berurutan dan tidak membuat allowance downstream yang persisten. Keduanya tetap bergantung pada allowance ERC-20 dari pemilik token kepada Permit2.

Tanda tangan tanpa gas dapat memindahkan aset ketika spender atau relayer membayar eksekusi. Verifikasi chain yang tepat, kode Permit2 yang diterapkan, domain EIP-712, modul, token, spender, maksimum bertanda tangan, calldata penerima, nonce, dan seluruh tenggat. Kontrak Permit2 yang sah tidak membuat spender, penerima, router, atau witness berbahaya menjadi aman.

Risiko tanda tangan Permit2
0 / 5
0 item yang ditinjau; 5 item yang masih belum terselesaikan

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

Cara kerjanya

  1. Tetapkan chainId, jaringan, verifyingContract Permit2, runtime code yang diterapkan, alamat dan decimals token, jenis wallet pemilik, serta aplikasi yang dimaksud. Gunakan catatan deployment resmi; alamat atau label yang dikenal tidak cukup.
  2. Baca allowance ERC-20 upstream dari pemilik ke Permit2 dan saldonya. Identifikasi approval terbatas atau tak terbatas serta perilaku transfer khusus token; ledger ini tetap ada setelah tanda tangan Permit2 atau allowance downstream tersimpan berakhir.
  3. Identifikasi jalur dan primary type yang ditandatangani secara tepat: PermitSingle atau PermitBatch pada AllowanceTransfer, atau PermitTransferFrom maupun varian batch dan witness pada SignatureTransfer. Jangan perlakukan transferFrom sebagai signed type.
  4. Dekode domain EIP-712 dan setiap entri pesan. Untuk AllowanceTransfer, periksa token, uint160 amount, expiration, nonce berurutan, spender, dan sigDeadline. Untuk SignatureTransfer, periksa token dan jumlah yang diizinkan, nonce tak berurutan, deadline, dan spender yang terikat dari konteks pemanggil.
  5. Dekode calldata eksekusi secara terpisah. Dalam SignatureTransfer dasar, SignatureTransferDetails.to dan requestedAmount adalah parameter eksekusi, bukan field di dalam permit dasar yang ditandatangani; jumlah yang diminta hanya perlu berada dalam maksimum bertanda tangan. Verifikasi setiap indeks batch dan hash witness serta type string yang tepat.
  6. Kueri nonce allowance berurutan saat ini atau word dan bit bitmap tak berurutan, lalu simulasikan pemanggil, calldata, chain, dan state yang tepat. Rekonsiliasi penerima, tindakan router, karakteristik token, saldo, serta kedua ledger allowance; simulasi dapat berubah akibat state, pengurutan, atau reorganisasi.
  7. Minimalkan jumlah dan masa berlaku. Jika mencurigakan, simpan typed data dan kirim revoke approval upstream, revoke allowance downstream, atau invalidasi nonce yang benar melalui jalur tepercaya sebagai perlombaan mempool; tunggu konfirmasi lalu rekonsiliasi transfer, saldo, allowance, dan bit bitmap.

Pada AllowanceTransfer, sigDeadline membatasi kapan permit bertanda tangan boleh menetapkan atau memperbarui otoritas tersimpan; expiration membatasi berapa lama otoritas itu dapat digunakan. Deadline SignatureTransfer membatasi eksekusi sekali pakainya. EIP-712 menyediakan hashing bertipe dan pemisahan domain, bukan perlindungan replay atau keamanan intensi; aturan nonce dan deadline Permit2 menyediakan batas tersebut.

Untuk wallet kontrak, validitas ERC-1271 bergantung pada kebijakan isValidSignature, modul, threshold, dan kode wallet saat ini. Label wallet, layar hardware wallet yang terpotong, dan simulasi berhasil merupakan masukan bukti, bukan jaminan. Memutus koneksi frontend tidak mencabut approval atau tanda tangan.

Contoh

  • Dua ledger allowance. Allowance token terbatas kepada Permit2 bermula pada 1,000 USDC; sebuah PermitSingle menyimpan 600 USDC untuk spender S. Setelah S mentransfer 225 USDC, jumlah tersimpan menjadi 600 - 225 = 375 USDC, sementara allowance token upstream terbatas standar menjadi 1,000 - 225 = 775 USDC. Berakhir atau dicabutnya 375 tidak otomatis menghapus 775; token nonstandar dapat berbeda.
  • Penerima dan jumlah sekali pakai. SignatureTransfer menandatangani maksimum 250 USDC; calldata meminta 180 USDC kepada merchant. Jika saldo dan allowance upstream mencukupi, eksekusi dapat mentransfer 180. Nonce telah dipakai sehingga sisa 70 USDC tidak dapat digunakan kembali. Jika calldata menunjuk penyerang sebagai penerima, permit dasar sendiri tidak mencegah pengalihan oleh spender terikat tersebut.
  • Bitmap nonce tak berurutan. Untuk nonce 513, nilainya wordPos = 513 >> 8 = 2, bitPos = 513 & 255 = 1, dan mask = 1 << 1 = 2. Eksekusi menetapkan bit 1 pada word 2; replay 513 gagal, sedangkan nonce 512 pada bit 0 tetap independen.
  • Perlombaan pencabutan. Allowance tersimpan adalah 400 USDC. Pemilik menyiarkan pencabutan ke nol, tetapi transfer 300 USDC dieksekusi lebih dulu sehingga tersisa 100 USDC; pencabutan berikutnya menetapkan sisanya menjadi 0. Allowance akhir nol tidak membatalkan kerugian terealisasi 300 USDC, sehingga urutan transaksi dan saldo harus direkonsiliasi.

Risiko

  • ID chain, deployment, atau runtime code yang salah
  • Verifying contract palsu atau tidak diharapkan
  • Kebingungan antara AllowanceTransfer dan SignatureTransfer
  • Spender atau pemanggil berbahaya maupun keliru
  • Penerima dipilih melalui calldata eksekusi
  • Jumlah yang diminta mendekati maksimum bertanda tangan
  • Alamat, simbol, decimals, atau unit mentah token yang salah
  • Approval ERC-20 upstream yang persisten atau tak terbatas
  • Jumlah downstream atau masa berlaku yang berlebihan
  • Kebingungan deadline, sigDeadline, dan expiration
  • Nonce berurutan yang usang atau terlibat perlombaan
  • Bit bitmap digunakan ulang atau mask invalidasi terlalu luas
  • Hash witness atau type string tepat tidak cocok
  • Entri batch tersembunyi, duplikat, atau salah indeks
  • Tampilan frontend atau calldata berbeda dari intensi
  • Revoke kalah dalam perlombaan mempool atau MEV
  • Perubahan modul, penanda tangan, threshold, atau upgrade ERC-1271
  • Token fee-on-transfer, rebasing, paused, blocked, atau callback
  • State simulasi bergeser, gagal, atau mengalami reorganisasi
  • Konfirmasi hardware wallet atau pemutusan koneksi disalahartikan sebagai aman

Kesalahpahaman umum

  • Tanda tangan tanpa permintaan gas tidak dapat memindahkan token. Pihak lain dapat membayar gas eksekusi.
  • Alamat Permit2 resmi membuktikan spender dan penerima aman. Permit2 dapat menjalankan otoritas berbahaya dengan tepat.
  • SignatureTransfer dan AllowanceTransfer membuat izin persisten yang sama. Yang pertama sekali pakai; yang kedua menyimpan allowance yang dapat digunakan berulang kali.
  • Memutus koneksi atau mencabut satu lapisan membatalkan semua jalur dan tanda tangan tertunda. State upstream, downstream, dan nonce terpisah serta perlombaan tetap ada.
  • EIP-712, hardware wallet, atau simulasi berhasil membuktikan intensi dan finality. Masing-masing meningkatkan visibilitas atau pengujian, tetapi tidak menggantikan verifikasi field, calldata, dan state terkonfirmasi.

Topik terkait

Sumber

Navigasi

Cari di wiki...