---
title: "Tanda tangan bertipe EIP-712: domain, digest, dan verifikasi aman"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Tanda tangan bertipe EIP-712: domain, digest, dan verifikasi aman
> 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.
## 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
- [ID jaringan](/id/crypto/chain-id/)
- [Nonce dan tenggat ERC-2612 Permit](/id/crypto/erc2612-permit-nonce-deadline/)
- [Risiko tanda tangan Permit2](/id/crypto/permit2-signature-risk/)
- [Otorisasi dompet](/id/crypto/wallet-approval/)
- [Tanda tangan dompet](/id/crypto/wallet-signature/)
## Sumber
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (diakses: 2026-08-19)
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (diakses: 2026-08-19)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (diakses: 2026-08-19)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (diakses: 2026-08-19)
- [ERC-5267: Retrieval of EIP-712 domain](https://eips.ethereum.org/EIPS/eip-5267) - Ethereum Improvement Proposals (diakses: 2026-08-19)
- [EIP-2: Homestead Hard-fork Changes](https://eips.ethereum.org/EIPS/eip-2) - Ethereum Improvement Proposals (diakses: 2026-08-19)
- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (diakses: 2026-08-19)
- [ERC-7730: Structured Data Clear Signing Format](https://eips.ethereum.org/EIPS/eip-7730) - Ethereum Improvement Proposals (diakses: 2026-08-19)
Source: https://wiki.fcontext.com/id/crypto/eip712-typed-signature/index.mdx