Lompat ke konten
Financial Context Wiki

Tanda tangan bertipe EIP-712: domain, digest, dan verifikasi aman

EIP-712 membuat pesan terstruktur Ethereum deterministik dan dapat dibaca, tetapi penandatanganan aman tetap memerlukan pemeriksaan domain, tipe, nilai, nonce, tenggat, eksekusi, dan kebijakan penanda tangan.

Diperbarui

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

Jawaban langsung

EIP-712 menstandarkan cara aplikasi Ethereum mendeskripsikan, melakukan hash, dan meminta tanda tangan atas data terstruktur bertipe. Permintaan memuat types, primaryType, domain, dan message; digest-nya adalah keccak256("\x19\x01" || domainSeparator || hashStruct(message)). Pengodean menjadi deterministik dan dompet yang mendukungnya dapat menampilkan setiap bidang lebih jelas daripada hash yang tidak transparan.

Namun, standar ini tidak membuat pesan benar, aman, dapat dicabut, atau kebal replay. Aplikasi harus mengikat kewenangan ke jaringan dan verifikator yang tepat, mendefinisikan setiap bidang tanpa ambigu, memberlakukan nonce serta batas waktu, memvalidasi penanda tangan yang benar, dan membatasi eksekusi. Tanda tangan valid hanya membuktikan persetujuan atas digest yang tepat menurut aturan verifikasi; bukan identitas, niat yang dipahami, atau keamanan situs dan kontrak.

Tanda tangan bertipe EIP-712
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. Identifikasi tindakan dan jalur verifikasi

Tentukan apakah permintaan mengizinkan login, order, voting, allowance token, transfer, panggilan melalui relayer, atau tindakan lain. Temukan kode yang membangun ulang digest dan menggunakan tanda tangan. Untuk akun yang dimiliki secara eksternal, verifikasi biasanya memulihkan alamat dari tanda tangan ECDSA; untuk akun kontrak, aplikasi mungkin perlu memanggil ERC-1271 isValidSignature(hash, signature) dan memeriksa nilai sukses 0x1626ba7e.

2. Tetapkan domain

Periksa tipe EIP712Domain yang tepat beserta nilainya. Bidang standar adalah name, version, chainId, verifyingContract, dan salt, tetapi hanya bidang yang disertakan yang masuk hash. Konfirmasikan jaringan aktif, kode yang diterapkan, dan verifikator yang dimaksud secara independen; nama, simbol, label proxy, atau alamat checksum yang familier tidak cukup. ERC-5267 eip712Domain() dapat mengekspos domain, tetapi dukungan bersifat opsional dan perilaku proxy atau upgrade tetap perlu diperiksa.

3. Bangun ulang graf tipe

Mulai dari primaryType, pertahankan urutan anggota, dan kumpulkan struct yang dirujuk secara rekursif. encodeType menambahkan definisinya yang diurutkan berdasarkan nama tipe. EIP-712 mendukung integer lebar tetap, address, bool, bytes1 sampai bytes32, bytes dan string dinamis, array, dan struct; alias uint dan int, tipe fixed-point, serta nilai siklik tidak didefinisikan.

4. Uraikan setiap nilai dan satuan

Cocokkan nilai dengan tipe yang dideklarasikan dan makna aplikasinya. Periksa alamat lengkap, satuan integer mentah, tanda, urutan array, penerima, spender, aset, jumlah, biaya, batas, tujuan, hash calldata, dan string yang dapat dibaca. bytes dan string dinamis direpresentasikan dalam encodeData sebagai hash Keccak-256 atas isinya; array memakai hash pengodean elemen yang digabung dan struct bersarang memakai hashStruct sendiri.

5. Hitung ulang digest secara independen

Hitung typeHash = keccak256(encodeType(primaryType)), lalu hashStruct(message) = keccak256(typeHash || encodeData(message)). Hitung pemisah domain dengan cara yang sama dan gabungkan dengan byte versi ERC-191 0x19 0x01. Bandingkan hasil frontend, pustaka penandatanganan, kontrak verifikator, dan implementasi independen; tampilan JSON yang sama tidak membuktikan pengodean bertipe yang sama.

6. Audit replay, waktu, dan kontrol eksekusi

EIP-712 sendiri tidak mencakup perlindungan replay. Pastikan verifikator memeriksa penanda tangan yang dimaksud, menggunakan atau membatalkan nonce yang benar, memberlakukan deadline atau jendela validitas, mengikat semua parameter kritis, dan tetap menghasilkan maksud yang sama bila relayer atau frontrunner mengirim lebih dahulu. Pemisahan domain hanya mencegah benturan antar-domain yang benar-benar dikodekan; bidang yang hilang atau salah dapat membuka penggunaan ulang antar-kontrak atau jaringan.

7. Tanda tangani seminimal mungkin dan rekonsiliasi hasil

Tolak bidang tersembunyi, tipe tanpa penjelasan, nilai tak terbatas, tenggat jauh, kontrak tak dikenal, chain ID yang tidak cocok, layar blind signing, atau konteks eksekusi tak lengkap. Simpan JSON bertipe dan digest yang tepat, gunakan akun khusus bila memungkinkan, lalu periksa transaksi, receipt, event, saldo, allowance, nonce, status order, dan finalitas. Memutus koneksi situs tidak mencabut tanda tangan yang masih dapat dipakai atau kewenangan yang sudah terbentuk.

Contoh perhitungan

Contoh 1: Konstruksi tipe dan digest

Untuk Order(address maker,address token,uint256 amount,uint256 nonce,uint256 deadline), typeHash adalah hash Keccak-256 dari string yang persis sama, termasuk urutan bidang. Hash pesan adalah keccak256(typeHash || maker || token || amount || nonce || deadline) dan setiap anggota yang dikodekan memakai 32 byte. Digest akhir menambahkan 0x1901, pemisah domain, dan hash pesan; mengubah amount dari 250000000 menjadi 250000001 mengubah digest dan membatalkan tanda tangan lama.

Contoh 2: Satuan dan tenggat

Jumlah 250 USDC untuk token enam desimal dikodekan sebagai nilai mentah 250000000, bukan 250. Jika timestamp saat ini 1727000000 dan tenggat 1727000900, jendelanya 900 seconds = 15 minutes. Tampilan desimal dompet dan jam lokal hanya alat bantu; verifikator menggunakan integer mentah dan aturan waktu on-chain pilihannya.

Contoh 3: Kontrol replay

Sebuah order membawa nonce 41 dan maksimum 5 ETH. Setelah verifikator menandai nonce 41 telah digunakan, pengiriman kedua harus gagal meski tanda tangan masih valid secara kriptografis. Jika kontrak tidak menggunakan nonce dan eksekusi tidak idempoten, tanda tangan yang sama dapat mengizinkan 5 ETH lagi; pemisah domain saja tidak menghentikan replay tersebut.

Contoh 4: Validitas dompet kontrak

Dompet kontrak 2-dari-3 menyetujui digest saat penanda tangan A, B, dan C dikonfigurasi. Tanda tangan A dan B dapat membuat ERC-1271 mengembalikan 0x1626ba7e hari ini. Bila upgrade modul mengganti B dengan D, byte tanda tangan yang sama dapat menjadi tidak valid: validitas ERC-1271 dapat bergantung pada state, kebijakan, waktu, dan panggilan eksternal saat ini; pemulihan alamat saja tidak menentukan validitas akun kontrak.

Risiko

  • chainId salah atau tidak ada
  • verifyingContract palsu atau tidak diharapkan
  • name atau version domain yang menyesatkan
  • Implementasi proxy atau domain berubah setelah upgrade
  • primaryType salah atau tipe bayangan berlabel mirip
  • Urutan anggota, dependensi, atau encoder tidak cocok
  • Alamat dipotong, diganti, atau diberi label menyesatkan
  • Kesalahan desimal token atau integer signed versus unsigned
  • Entri array, struct bersarang, atau payload bytes tersembunyi
  • Jumlah tak terbatas, cakupan luas, atau penerima dikendalikan penyerang
  • Nonce hilang, kedaluwarsa, dibagi, atau digunakan secara salah
  • Tenggat hilang, terlalu jauh, overflow, atau ditafsirkan ambigu
  • Replay antar-jaringan, kontrak, akun, atau tindakan
  • Relayer menahan, menyensor, front-running, atau mengalihkan eksekusi
  • Malleability tanda tangan atau pemulihan ECDSA terlalu permisif
  • Perubahan penanda tangan, modul, ambang, state, atau kode ERC-1271
  • Kegagalan rendering dompet, blind signing, atau tipe tak didukung
  • JSON frontend berbeda dari digest verifikator
  • Pencabutan atau pembatalan kalah dalam balapan urutan
  • Prompt tanda tangan disangka receipt, perubahan state, atau finalitas

Kesalahpahaman umum

Mitos 1: Tanda tangan EIP-712 adalah transaksi

Ini adalah pesan yang ditandatangani off-chain. Relayer dapat mengirimkannya ke kontrak kemudian; transaksi yang dihasilkan dapat memakai Gas dan mengubah state tanpa dikirim oleh penanda tangan.

Mitos 2: Tampilan terstruktur berarti permintaan aman

Bidang bertipe memudahkan pemeriksaan, tetapi skema, nilai, kontrak, label, susunan tersembunyi, atau rendering dompet yang jahat masih dapat menipu.

Mitos 3: Pemisah domain mencegah semua replay

Ia hanya memisahkan domain yang dikodekan. Replay dalam domain yang sama tetap membutuhkan nonce, tenggat, pembatalan, pencatatan fill, atau idempotensi; bidang yang dihilangkan tidak menciptakan batas.

Mitos 4: Memulihkan alamat yang diharapkan membuktikan otorisasi

Pemulihan hanya membuktikan tanda tangan EOA atas digest, bukan semantik aplikasi. Akun kontrak memerlukan kebijakan ERC-1271, bukan pemulihan alamat biasa.

Mitos 5: Menutup halaman atau memutus dompet membatalkan tanda tangan

Tanda tangan yang disalin tetap dapat digunakan sampai nonce, tenggat, pembatalan, state, atau kebijakan verifikator membatalkannya. Periksa state on-chain yang relevan, bukan status sesi.

Topik terkait

Sumber

Navigasi

Cari di wiki...