---
title: "Mengurai Calldata di Dompet"
description: "Panduan berorientasi verifikasi untuk calldata transaksi, word dan offset ABI, tabrakan selector, proxy, batch, persetujuan, permit berbasis typed data, simulasi, dan rekonsiliasi pascatransaksi."
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.
# Mengurai Calldata di Dompet
> Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.
## Jawaban langsung
Calldata adalah rangkaian byte yang tidak dapat diubah dan diberikan sebagai input kepada transaksi Ethereum tingkat atas atau message call internal. Panggilan fungsi Solidity konvensional dimulai dengan selector `4-byte`, lalu argumen yang dikodekan dengan ABI. Namun, calldata tidak mendeskripsikan dirinya sendiri: byte yang sama dapat berarti hal berbeda untuk runtime code, implementasi proxy, atau skema yang berbeda. Fungsi fallback, assembly mentah, dan protokol non-Solidity bahkan tidak harus mengikuti ABI fungsi konvensional.
Karena itu, dompet harus menampilkan lebih dari sekadar kandidat nama fungsi. Peninjauan yang aman mengikat byte tersebut ke `chainId`, suatu blok, `from`, `to`, `value` native, `codeHash` runtime, implementasi aktif, dan ABI tepercaya; mengurai setiap panggilan bersarang secara ketat; membedakan calldata on-chain dari tanda tangan EIP-712; melakukan simulasi dalam state yang dinyatakan; lalu merekonsiliasi receipt serta perubahan state aktual setelah transaksi dimasukkan.
## Cara kerjanya
1. Kunci signing envelope dan titik observasi: `chainId`, nomor serta hash blok, `from`, `to`, `value` native, byte input, nonce, dan field biaya. Simpan sumber dompet atau RPC; payload yang diurai dari chain atau blok lain bukanlah klaim yang sama.
2. Klasifikasikan objek sebelum mengurainya. Transaksi, permintaan typed data EIP-712, permit ERC-2612, UserOperation ERC-4337, dan pesan personal-sign mentah memakai domain serta skema berbeda; jangan memaksakan semuanya melalui ABI transaksi.
3. Tentukan target pada blok yang dikunci. Baca runtime bytecode dan `codeHash`; identifikasi proxy, beacon, atau implementasi bila relevan; catat slot implementasi dan admin; serta dapatkan ABI yang cocok dengan versi kode tersebut. Registry selector hanya memberi kandidat, bukan otoritas.
4. Urai secara ketat. Selector adalah `4 bytes` pertama Keccak-256 atas signature fungsi kanonis tanpa tipe return. Nilai statis menempati word `32-byte`, sedangkan head dinamis memuat offset dari blok argumen setelah selector. Tolak data terpotong, offset di luar batas, panjang yang mustahil, padding tidak valid, dan byte tambahan yang tidak dapat dijelaskan.
5. Buka multicall, calldata bersarang, dan eksekusi terdelegasi secara rekursif. Untuk setiap child call, tampilkan target, nilai native, selector, argumen, tipe panggilan, dan setiap flag `allowFailure`. Dengan `delegatecall`, kode implementasi berjalan dalam konteks alamat, saldo, dan storage pemanggil, sementara `msg.sender` serta `msg.value` tetap dipertahankan.
6. Susun ledger otoritas dan nilai secara terpisah, lalu lakukan simulasi. Catat penerima, spender, operator NFT, unit token mentah, decimals, deadline, batas slippage, dan nilai native. Simulasikan menggunakan blok, pengirim, dan nilai yang tepat, tetapi perlakukan hasilnya sebagai snapshot bersyarat karena state, harga, waktu, kode, dan urutan transaksi dapat berubah.
7. Konfirmasikan setiap field material sebelum menandatangani. Setelah transaksi masuk, periksa status receipt, log, trace jika tersedia, serta delta saldo, allowance, dan status operator; bedakan kegagalan child call yang ditangkap dari keberhasilan tingkat atas; perhitungkan gas meski transaksi revert; tunggu finalitas yang diperlukan; dan berhenti alih-alih menandatangani ulang kegagalan yang tidak dapat dijelaskan.
## Contoh terhitung
- **Transfer ERC-20 statis.** `transfer(address,uint256)` lazim memakai selector `0xa9059cbb`. Satu selector ditambah dua word ABI adalah `4 + 2 * 32 = 68 bytes`. Jumlah mentah `1,500,000` untuk token yang telah diverifikasi secara independen menggunakan `6 decimals` ditampilkan sebagai `1.5 tokens`. Decimals adalah metadata kontrak eksternal, bukan bagian yang dikodekan dalam argumen tersebut, dan selector saja tidak mengidentifikasi kontrak atau fungsi secara unik.
- **Offset byte dinamis.** Untuk `f(address,bytes)` dengan payload `3-byte`, head dua word menempati `64 bytes`. Offset dinamisnya `0x40`, diukur dari awal blok argumen dan tidak mencakup selector. Tail berisi satu word panjang `32-byte` dan satu word data ber-padding `32-byte`, sehingga total calldata adalah `4 + 64 + 32 + 32 = 132 bytes`. Menganggap offset absolut dari byte nol akan meleset empat byte ke belakang.
- **Nilai batch bergantung pada implementasi.** Panggilan luar membawa `1.00 ETH`; tiga child call yang diurai secara eksplisit meminta `0.20 ETH`, `0.30 ETH`, dan `0.10 ETH`, dengan total `0.60 ETH`. Sisa `0.40 ETH` dapat dikembalikan, ditahan, diteruskan, atau menyebabkan revert, tergantung kode batch. Jika child ketiga gagal dengan `allowFailure=true`, child sebelumnya mungkin tetap committed; implementasi atomik dapat memilih me-revert semuanya.
- **Permit bukan calldata relayer saat penandatanganan.** Pemilik dengan `1,000 USDC` menandatangani permit ERC-2612 sebesar `300 USDC` pada nonce `41`. Tanda tangan saja tidak mengubah saldo maupun allowance. Setelah relayer berhasil mengirimkannya, nonce menjadi `42` dan allowance menjadi `300`; setelah spender memakai `180`, saldo menjadi `820` dan sisa allowance `120`. Memutus koneksi situs tidak mencabut izin tersebut.
## Risiko
- Mengurai berdasarkan chain, fork, block tag, atau transaction envelope yang salah.
- Menandatangani untuk domain, alamat target, atau penerima palsu.
- Menganggap selector `4-byte` unik meski tabrakan dapat terjadi.
- Menggunakan ABI tebakan, usang, atau diverifikasi secara keliru.
- Memercayai label source terverifikasi tanpa mencocokkannya dengan `codeHash` runtime saat ini.
- Melewatkan upgrade implementasi, beacon, atau admin antara peninjauan dan eksekusi.
- Mengabaikan fungsi proxy yang selectornya bertabrakan dengan implementasi.
- Lupa bahwa `delegatecall` menulis dalam konteks storage pemanggil.
- Menerima offset, panjang, padding dinamis, atau byte tambahan yang malformed.
- Gagal membuka batch bersarang yang menyembunyikan target, nilai, atau izin.
- Mengasumsikan atomisitas ketika implementasi menangkap atau mengizinkan kegagalan child call.
- Mengabaikan `value` native tingkat atas karena argumen token tampak tidak berbahaya.
- Menerapkan decimals yang salah atau menganggap token fee-on-transfer dan rebasing sebagai ERC-20 standar.
- Memberikan allowance ERC-20 tanpa batas atau salah menangani race saat memperbaruinya.
- Mengabaikan cakupan seluruh koleksi dari `setApprovalForAll` NFT.
- Mengira typed data EIP-712 atau permit ERC-2612 sebagai calldata transaksi.
- Melewatkan batas nonce, deadline, verifying contract, domain chain, atau replay.
- Menganggap simulasi stabil meski oracle, timestamp, pending state, MEV, atau kode berubah.
- Menganggap status receipt, log, atau trace penyedia sebagai bukti lengkap state ekonomi.
- Menandatangani ulang secara buta melalui UI terkompromi atau mengabaikan risiko inclusion, reorg, dan finalitas.
## Kesalahpahaman umum
- Selector fungsi secara unik menentukan apa yang akan dieksekusi kontrak.
- Ringkasan front-end terverifikasi identik dengan byte serta implementasi aktif yang ditandatangani.
- Transaksi dengan `value=0` tidak dapat memindahkan token, NFT, atau aset terdelegasi.
- Simulasi atau receipt yang berhasil membuktikan keamanan dan hasil ekonomi yang dimaksud.
- Memutus koneksi dapp mencabut persetujuan, permit, dan izin operator NFT.
## Topik terkait
- [Simulasi transaksi](/id/crypto/transaction-simulation/)
- [Persetujuan dompet](/id/crypto/wallet-approval/)
- [Tanda tangan dompet](/id/crypto/wallet-signature/)
## Sumber
- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (diakses: 2026-08-12)
- [Introduction to Smart Contracts](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-and-libraries) - Solidity Documentation (diakses: 2026-08-12)
- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (diakses: 2026-08-12)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (diakses: 2026-08-12)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (diakses: 2026-08-12)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (diakses: 2026-08-12)
- [ERC-721: Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) - Ethereum Improvement Proposals (diakses: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (diakses: 2026-08-12)
Source: https://wiki.fcontext.com/id/crypto/calldata-decoding-wallet/index.mdx