Smart Contract ABI (Application Binary Interface)

Apa Itu Smart Contract ABI?

Smart Contract ABI, atau Application Binary Interface, adalah antarmuka terstruktur yang memberi tahu wallet, aplikasi, skrip, dan perangkat lunak lain cara mengenkode panggilan ke smart contract serta mendekode data yang dikembalikan olehnya.

Spesifikasi resmi Solidity Contract ABI menjelaskan ABI sebagai cara standar untuk berinteraksi dengan kontrak dalam ekosistem Ethereum.

Dalam kripto, ABI berfungsi seperti lapisan penerjemah antara fungsi smart contract yang dapat dibaca manusia dan data biner tingkat rendah yang dapat dipahami Ethereum Virtual Machine.

Developer dapat menulis fungsi Solidity bernama transfer dengan address dan jumlah sebagai input, tetapi transaksi harus mengirim permintaan tersebut sebagai calldata heksadesimal yang telah dienkode.

ABI menentukan cara nama fungsi, jenis input, jenis output, event, error, input constructor, fungsi receive, dan fungsi fallback direpresentasikan untuk alat perangkat lunak.

Tanpa ABI, pengguna dan aplikasi akan jauh lebih sulit mengetahui fungsi yang tersedia, parameter yang diperlukan, dan cara mendekode hasil.

Smart contract ABI tidak menyimpan dana, menjalankan kode, atau membuktikan bahwa kontrak aman.

ABI menjelaskan cara berkomunikasi dengan kontrak yang sudah ada atau sedang di-deploy.

Sederhananya, Smart Contract ABI adalah panduan yang digunakan perangkat lunak untuk memanggil dan memahami fungsi smart contract.

Mengapa Smart Contract ABI Penting dalam Kripto

Smart Contract ABI penting karena sebagian besar pengguna tidak berinteraksi dengan smart contract dengan menulis calldata mentah secara manual.

Wallet, aplikasi terdesentralisasi, blockchain explorer, skrip, bot, platform analitik, dan alat developer menggunakan ABI untuk mengubah tindakan yang mudah dibaca menjadi panggilan blockchain yang valid.

Dokumentasi kompilasi smart contract Ethereum menjelaskan bahwa compiler menghasilkan ABI agar aplikasi dapat memahami kontrak dan memanggil fungsinya.

Hal ini penting untuk transfer token, deposit DeFi, mint NFT, tindakan staking, voting governance, interaksi bridge, penarikan vault, dan aktivitas smart contract lainnya.

Misalnya, wallet dapat menggunakan ABI untuk menampilkan bahwa transaksi memanggil approve, alih-alih hanya menampilkan kolom input heksadesimal panjang.

Blockchain explorer dapat menggunakan ABI untuk mendekode data input transaksi dan menampilkan parameter yang mudah dibaca.

Skrip developer dapat menggunakan ABI untuk memanggil fungsi kontrak tanpa menyusun setiap byte calldata secara manual.

Smart contract ABI juga membantu pengguna memahami event karena log menjadi lebih berguna saat perangkat lunak dapat mendekode nama event dan nilai yang diindeks.

Tanpa ABI, interaksi smart contract akan kurang mudah dibaca, kurang ramah pengguna, dan lebih rentan kesalahan.

Oleh karena itu, ABI merupakan salah satu lapisan kegunaan terpenting pada aplikasi kripto berbasis EVM.

Cara Kerja Smart Contract ABI

Smart Contract ABI bekerja dengan menentukan skema untuk mengenkode dan mendekode data smart contract.

ABI mencantumkan fungsi yang dapat dipanggil dan menjelaskan nama, jenis input, jenis output, state mutability, serta detail antarmuka terkait untuk setiap fungsi.

Saat pengguna memanggil fungsi, perangkat lunak wallet atau aplikasi membaca ABI dan mengenkode function selector serta argumen input menjadi calldata.

Calldata tersebut ditempatkan ke dalam kolom data transaksi atau digunakan dalam panggilan read-only.

Kontrak menerima calldata dan EVM menjalankan fungsi yang sesuai dengan selector jika didukung oleh logika kontrak.

Jika fungsi mengembalikan data, ABI memberi tahu perangkat lunak cara mendekode byte yang dikembalikan menjadi nilai yang mudah dibaca.

Jika transaksi menghasilkan event, ABI membantu perangkat lunak mendekode log menjadi nama dan kolom event.

Jika panggilan revert dengan custom error, ABI dapat membantu mendekode jenis error dan argumennya.

ABI tidak menentukan apakah transaksi berhasil karena keberhasilan bergantung pada kode kontrak, state blockchain, gas, izin, dan nilai input.

ABI hanya menentukan cara komunikasi dengan kontrak tersebut harus dienkode dan didekode.

Format JSON ABI

Smart contract ABI biasanya direpresentasikan sebagai array JSON.

Spesifikasi ABI Solidity menjelaskan bahwa format JSON untuk antarmuka kontrak adalah array berisi deskripsi fungsi, event, dan error.

Setiap item fungsi dapat mencakup kolom seperti type, name, inputs, outputs, stateMutability, dan informasi terkait payable, bergantung pada format ABI dan versi compiler.

Input dan output mencakup informasi jenis seperti address, uint256, bool, bytes, string, array, dan tuple.

Item event menjelaskan nama event, parameter yang diindeks, dan parameter yang tidak diindeks.

Item error menjelaskan custom error dan parameter inputnya.

Item constructor menjelaskan parameter pada waktu deployment.

Item receive dan fallback menjelaskan perilaku khusus untuk transfer aset native biasa atau panggilan yang tidak cocok.

Karena ABI adalah JSON terstruktur, alat developer dapat menguraikannya dan membuat objek kontrak yang dapat digunakan.

Inilah alasan banyak aplikasi dapat membuat tombol, formulir, pratinjau transaksi, dan decoder event yang mudah dibaca dari ABI.

Function Selector

Function selector adalah empat byte pertama yang digunakan untuk mengidentifikasi fungsi kontrak yang harus dipanggil.

Spesifikasi ABI Solidity menjelaskan bahwa empat byte pertama calldata untuk panggilan fungsi menentukan fungsi yang akan dipanggil.

Selector dihitung dari signature fungsi kanonis, yang mencakup nama fungsi dan jenis input yang tepat.

Misalnya, signature fungsi dapat terlihat seperti transfer(address,uint256).

Perangkat lunak melakukan hash pada signature tersebut dan menggunakan empat byte pertama sebagai function selector.

Selector penting karena calldata tidak menyertakan nama fungsi yang mudah dibaca dalam teks biasa.

Kontrak membaca selector dan meneruskan panggilan ke fungsi yang sesuai jika bytecode mendukungnya.

Fungsi berbeda dapat di-overload jika memiliki nama sama tetapi jenis input berbeda karena signature kanonisnya berbeda.

Developer harus berhati-hati dengan fungsi yang di-overload karena pengguna dan alat dapat membingungkannya jika antarmuka tidak jelas.

Function selector berukuran kecil, efisien, dan menjadi bagian utama cara kerja panggilan smart contract berbasis ABI.

Calldata

Calldata adalah data input yang telah dienkode dan dikirim bersama panggilan smart contract.

Dokumentasi resmi transaksi Ethereum menjelaskan data transaksi sebagai bagian dari cara aplikasi mengirim informasi kepada kontrak.

Untuk panggilan fungsi kontrak biasa, calldata dimulai dengan function selector empat byte, lalu diikuti argumen yang dienkode ABI.

Jika pengguna memanggil fungsi transfer token, calldata berisi selector untuk fungsi tersebut serta address penerima dan jumlah token yang telah dienkode.

Jika pengguna memanggil fungsi swap, calldata dapat berisi path, jumlah, penerima, tenggat waktu, dan parameter lain yang dienkode sesuai desain kontrak.

Calldata terlihat pada blockchain publik karena data input transaksi merupakan bagian dari catatan transaksi publik.

Blockchain explorer dapat mendekode calldata jika memiliki ABI yang tepat untuk kontrak tersebut.

Jika ABI tidak ada atau salah, calldata yang sama dapat terlihat sebagai data heksadesimal yang tidak dapat dibaca atau didekode secara keliru.

Pengguna harus mengingat bahwa calldata dapat mengotorisasi tindakan yang kuat saat ditandatangani dalam transaksi.

Memahami ABI calldata membantu pengguna melihat tindakan yang sebenarnya ingin dilakukan transaksi smart contract.

Return Data

Return data adalah output yang telah dienkode dan dikirim kembali oleh fungsi kontrak setelah eksekusi.

Panggilan read-only sering mengembalikan nilai seperti saldo, allowance, nama token, alamat owner, total suplai, cadangan pool, state proposal governance, atau harga saham vault.

ABI memberi tahu perangkat lunak klien cara mendekode byte yang dikembalikan menjadi nilai bermakna.

Jika fungsi mengembalikan uint256, ABI memberi tahu perangkat lunak untuk mendekode return data sebagai bilangan bulat tanpa tanda.

Jika fungsi mengembalikan beberapa nilai, ABI menentukan urutan dan jenis setiap nilai.

Jika fungsi mengembalikan tuple atau array, ABI menentukan struktur bertingkat yang diperlukan untuk mendekodenya dengan benar.

Return data dapat membingungkan apabila ABI yang digunakan salah karena byte dapat ditafsirkan sebagai jenis yang salah.

Penafsiran yang salah dapat menyebabkan tampilan aplikasi yang buruk, skrip gagal, atau analitik yang tidak akurat.

Developer harus memastikan front end dan skrip menggunakan ABI yang sesuai dengan versi kontrak yang di-deploy.

Dekode return data yang benar sangat penting bagi dashboard, antarmuka DeFi, dan tampilan wallet yang andal.

Event dan Log

Event adalah log terstruktur yang dihasilkan smart contract selama eksekusi transaksi.

ABI menjelaskan nama event, jenis parameter, dan apakah parameter tersebut diindeks.

Parameter event yang diindeks dapat dicari dengan lebih efisien oleh node dan indexer.

Parameter yang tidak diindeks disimpan dalam data event dan didekode berdasarkan ABI.

Event banyak digunakan untuk transfer token, approval, deposit, penarikan, swap, likuidasi, mint NFT, voting governance, dan perubahan konfigurasi.

Blockchain explorer dan alat analitik menggunakan ABI untuk menampilkan event log dalam bentuk yang mudah dibaca.

Event Transfer token jauh lebih mudah dipahami ketika didekode menjadi kolom pengirim, penerima, dan jumlah.

Event penting bagi sistem off-chain karena aplikasi sering mengindeksnya untuk membangun riwayat, grafik, notifikasi, dan tampilan portofolio.

Namun, event tidak sama dengan state kontrak karena event adalah log yang dihasilkan oleh eksekusi kontrak.

Developer dan pengguna harus menafsirkan event bersama dengan perubahan state nyata dan logika kontrak.

Error dan Revert Data

Smart contract dapat melakukan revert ketika kondisi gagal, dan kontrak Solidity modern dapat menggunakan custom error.

ABI dapat menyertakan deskripsi error agar alat dapat mendekode revert data dengan lebih jelas.

Custom error yang didekode dapat menunjukkan bahwa panggilan gagal akibat saldo tidak mencukupi, akses tidak sah, tenggat waktu berakhir, signature tidak valid, atau kondisi lain yang ditentukan kontrak.

Tanpa dekode error berbasis ABI, pengguna mungkin hanya melihat pesan transaksi gagal yang samar atau nilai revert heksadesimal mentah.

Custom error juga dapat mengurangi gas dibandingkan revert string yang panjang dalam beberapa kasus.

Bagi developer, definisi error yang jelas memudahkan debugging.

Bagi pengguna, error yang mudah dibaca dapat mengurangi kebingungan ketika simulasi transaksi gagal.

Namun, error yang didekode tidak selalu menjelaskan alasan ekonomi sepenuhnya mengapa transaksi gagal.

Swap dapat gagal akibat slippage, tetapi penyebab lebih dalamnya mungkin pergerakan pasar, batas likuiditas, atau pengaturan tenggat waktu.

Dekode error ABI membantu, tetapi pengguna tetap harus meninjau konteks transaksi secara menyeluruh.

Constructor

Constructor adalah fungsi khusus yang berjalan selama deployment kontrak.

ABI dapat menyertakan input constructor agar alat deployment mengetahui cara mengenkode argumen deployment.

Argumen constructor dapat mencakup nama token, simbol, owner awal, alamat oracle, alamat treasury, parameter governance, atau nilai konfigurasi awal.

Bytecode deployment dan argumen constructor bersama-sama membentuk kontrak akhir yang di-deploy.

Verifikasi kode sumber sering mengharuskan argumen constructor yang sesuai bersama file sumber dan pengaturan compiler.

Dokumentasi resmi verifikasi smart contract Ethereum menjelaskan bahwa verifikasi membandingkan kode sumber dan bytecode hasil kompilasi yang digunakan selama pembuatan kontrak.

Jika argumen constructor salah, kontrak yang di-deploy dapat berperilaku berbeda dari desain yang dimaksudkan.

Untuk sistem proxy yang dapat di-upgrade, initializer sering menggantikan pengaturan bergaya constructor untuk storage proxy.

Pengguna yang meninjau kontrak harus memahami apakah pengaturan kritis dilakukan melalui constructor atau initializer terpisah.

Informasi constructor ABI membantu membuat deployment lebih transparan dan dapat direproduksi.

Fungsi Receive dan Fallback

Fungsi receive dan fallback adalah titik masuk kontrak khusus yang dapat menangani transfer aset native biasa atau panggilan yang tidak cocok dengan function selector lain.

Format JSON ABI Solidity dapat menyertakan deskripsi receive dan fallback.

Fungsi receive dapat berjalan ketika kontrak menerima aset native dengan calldata kosong.

Fungsi fallback dapat berjalan ketika calldata tidak sesuai dengan fungsi yang ada atau ketika tidak ada fungsi receive untuk transfer tertentu.

Fungsi-fungsi ini dapat penting bagi kontrak pembayaran, kontrak proxy, wrapper, lelang, dan penanganan darurat.

Fungsi tersebut juga dapat menciptakan risiko keamanan jika developer lupa bahwa kontrak dapat menerima panggilan atau dana yang tidak terduga.

Pengguna tidak selalu melihat nama fungsi yang mudah dikenali ketika berinteraksi dengan perilaku receive atau fallback.

Wallet dan explorer dapat menampilkan interaksi ini secara berbeda dari panggilan fungsi ABI biasa.

Developer harus mendokumentasikan perilaku fallback dengan jelas karena logika fallback tersembunyi dapat mengejutkan pengguna.

Fungsi fallback dan receive menunjukkan bahwa ABI dapat menjelaskan lebih dari sekadar fungsi bernama biasa.

Jenis Statis dan Dinamis

ABI menentukan cara jenis statis dan dinamis dienkode.

Jenis statis memiliki encoding berukuran tetap, seperti address, bool, bytes32, dan uint256.

Jenis dinamis dapat memiliki ukuran yang berubah, seperti string, bytes, array dinamis, dan beberapa struktur tuple bertingkat.

Spesifikasi ABI Solidity menjelaskan aturan encoding untuk nilai statis dan dinamis.

Nilai dinamis sering memerlukan offset yang menunjuk ke lokasi awal data sebenarnya.

Encoding bergaya head-and-tail ini memungkinkan argumen fungsi kompleks dikemas menjadi calldata yang deterministik.

Developer biasanya tidak perlu mengenkode ini secara manual karena library dan alat menanganinya.

Namun, memahami encoding statis dan dinamis berguna untuk debugging calldata mentah dan transaksi yang gagal.

Peneliti keamanan sering memeriksa encoding ABI ketika menganalisis eksploitasi, calldata malformed, atau interaksi kontrak yang tidak biasa.

Jenis ABI statis dan dinamis merupakan dasar komunikasi kontrak yang andal.

Array dan Tuple

Smart contract ABI dapat menjelaskan array dan tuple.

Array dapat menyimpan beberapa nilai dengan jenis yang sama, seperti daftar address atau jumlah.

Tuple dapat mengelompokkan beberapa kolom berbeda menjadi satu nilai terstruktur.

Tuple berguna untuk posisi DeFi kompleks, struktur order, data proposal governance, dan nilai konfigurasi bertingkat.

Encoding ABI harus mempertahankan urutan dan jenis tepat dari setiap kolom.

Jika urutan kolom tuple salah, transaksi dapat gagal atau menghasilkan hasil yang tidak diinginkan.

Jika panjang array salah, kontrak dapat menolak panggilan atau menafsirkan data secara keliru.

Wallet dan front end harus menampilkan input ABI kompleks dengan jelas agar pengguna memahami hal yang mereka tandatangani.

Developer harus menghindari antarmuka publik yang terlalu kompleks apabila struktur lebih sederhana dapat digunakan.

Jenis ABI kompleks sangat kuat, tetapi meningkatkan kebutuhan akan desain antarmuka pengguna dan pengujian yang cermat.

ABI dan Bytecode Smart Contract

ABI berbeda dari bytecode smart contract.

Bytecode adalah kode tingkat rendah yang dijalankan EVM.

ABI adalah deskripsi antarmuka yang digunakan perangkat lunak eksternal untuk mengenkode panggilan dan mendekode data.

Kontrak yang di-deploy menyimpan runtime bytecode secara on-chain, tetapi ABI lengkap yang mudah dibaca manusia biasanya tidak disimpan sebagai logika eksekusi kontrak.

Aplikasi sering memperoleh ABI dari artefak yang dikompilasi, kode sumber terverifikasi, metadata, file package, repositori developer, atau database blockchain explorer.

Perbedaan ini penting karena kontrak dapat ada secara on-chain walaupun ABI publik tidak mudah ditemukan.

Ketika ABI tidak tersedia, pengguna tetap dapat mengirim calldata mentah jika mengetahui encodingnya, tetapi hal ini sulit dan berisiko bagi kebanyakan orang.

Ketika ABI salah, alat dapat menampilkan nama fungsi atau parameter yang menyesatkan.

Bytecode adalah yang berjalan, sedangkan ABI adalah cara perangkat lunak memahami cara berkomunikasi dengan yang berjalan.

Keduanya penting, tetapi memiliki tujuan yang berbeda.

ABI dan Verifikasi Kode Sumber

Verifikasi kode sumber sering membantu alat memperoleh atau mengonfirmasi ABI kontrak.

Ketika kode sumber dan pengaturan compiler kontrak diverifikasi, blockchain explorer dapat menampilkan fungsi, event, dan panel interaksi kontrak dengan lebih jelas.

Dokumentasi verifikasi Ethereum menjelaskan bahwa verifikasi membantu mendeteksi apakah kode kontrak yang diiklankan berbeda dengan yang berjalan secara on-chain.

Kontrak terverifikasi biasanya memudahkan interaksi berbasis ABI karena pengguna dapat memeriksa fungsi dan event yang mudah dibaca.

Namun, verifikasi tidak menjamin kontrak aman.

ABI terverifikasi hanya membantu pengguna melihat cara berinteraksi dengan kontrak.

Kontrak tetap dapat berisi bug, kontrol admin tidak aman, risiko upgrade, logika berbahaya, atau ekonomi yang cacat.

Pengguna harus memperlakukan ABI terverifikasi sebagai sinyal transparansi, bukan jaminan keamanan.

Developer harus memverifikasi kode sumber dan memublikasikan data ABI agar pengguna serta alat dapat berinteraksi dengan aman.

Kontrak yang tidak terverifikasi dengan ABI tidak diketahui memerlukan kehati-hatian ekstra ketika meminta approval atau deposit.

ABI dan Metadata Kontrak

Metadata kontrak Solidity dapat mencakup informasi ABI, pengaturan compiler, referensi sumber, dan detail build lainnya.

Dokumentasi resmi metadata kontrak Solidity menjelaskan bahwa metadata berisi informasi tentang kontrak saat ini dan dapat digunakan untuk menanyakan versi compiler, sumber, ABI, serta dokumentasi NatSpec.

Metadata membantu menghubungkan bytecode yang di-deploy dengan file sumber dan konteks kompilasi.

Hal ini penting karena perubahan kecil dalam file sumber, opsi compiler, atau metadata dapat mengubah bytecode akhir.

Developer harus menyimpan artefak build agar dapat memverifikasi kontrak dan mereproduksi deployment di kemudian hari.

Aplikasi harus menghindari penggunaan file ABI lama setelah upgrade atau redeployment kontrak.

Metadata dapat meningkatkan transparansi, tetapi pengguna biasanya mengandalkan blockchain explorer dan alat developer untuk mengaksesnya.

Ketika metadata dan data ABI tersedia, interaksi kontrak menjadi lebih mudah diperiksa dan diotomatisasi.

Ketika metadata tidak tersedia, pengguna mungkin harus bergantung pada ABI yang disediakan proyek atau reverse engineering manual.

Pengelolaan metadata yang baik merupakan bagian dari pengembangan smart contract profesional.

ABI dan Wallet

Wallet menggunakan informasi ABI untuk membuat interaksi smart contract lebih mudah dibaca.

Wallet dapat mendekode transaksi sebagai approve, transfer, swap, stake, mint, claim, vote, atau withdraw apabila memiliki ABI yang benar atau data dekode terkait.

Tanpa dekode, wallet mungkin hanya menampilkan data heksadesimal mentah.

Prompt transaksi yang mudah dibaca dapat membantu pengguna menghindari signature berbahaya.

Namun, dekode wallet tidak sempurna karena bergantung pada data ABI yang tersedia, pengenalan kontrak, simulasi transaksi, dan kualitas antarmuka.

Website berbahaya tetap dapat meminta wallet menandatangani transaksi merugikan yang terlihat membingungkan atau tidak lengkap.

Pengguna harus memverifikasi alamat kontrak, jumlah token, alamat spender, dan perubahan izin sebelum menandatangani.

Wallet harus menampilkan detail hasil dekode ABI dalam bahasa sederhana jika memungkinkan.

Developer harus merancang fungsi kontrak dan event yang membantu wallet menyampaikan makna transaksi dengan jelas.

ABI meningkatkan keterbacaan wallet, tetapi kehati-hatian pengguna tetap penting.

ABI dan Aplikasi Terdesentralisasi

Aplikasi terdesentralisasi menggunakan ABI untuk menghubungkan tombol dan formulir front end dengan fungsi smart contract.

Ketika pengguna mengklik tombol deposit, aplikasi menggunakan ABI untuk mengenkode panggilan fungsi deposit.

Ketika dashboard menampilkan saldo pengguna, aplikasi dapat menggunakan ABI untuk memanggil fungsi saldo read-only.

Ketika aplikasi memantau event, aplikasi menggunakan ABI untuk mendekode log yang dihasilkan kontrak.

Hal ini menjadikan ABI sebagai bridge antara antarmuka web dan kontrak on-chain.

ABI yang salah dapat merusak aplikasi meskipun kontraknya sendiri berfungsi dengan benar.

ABI lama dapat menyebabkan panggilan front end gagal setelah upgrade kontrak.

ABI tidak lengkap dapat menyembunyikan fungsi atau event yang diperlukan aplikasi.

Developer harus menjaga artefak ABI tetap sinkron dengan versi kontrak yang di-deploy.

Pengguna harus berhati-hati ketika website meminta transaksi yang tidak sesuai dengan tindakan yang ditampilkan pada antarmuka.

ABI dan Panggilan Read-Only

Panggilan read-only menggunakan encoding ABI untuk meminta data kontrak tanpa mengubah state blockchain.

Dokumentasi resmi Ethereum JSON-RPC API menjelaskan metode seperti eth_call, yang dapat menjalankan message call tanpa membuat transaksi biasa yang mengubah state.

Panggilan read-only digunakan untuk memeriksa saldo, allowance, cadangan, rate, state proposal, alamat owner, metadata token, dan posisi pengguna.

Panggilan ini tetap memerlukan informasi ABI agar perangkat lunak dapat mengenkode permintaan fungsi dan mendekode data yang dikembalikan.

Panggilan read-only biasanya tidak memerlukan signature pengguna karena tidak mengubah state.

Namun, front end tetap harus jujur mengenai data yang ditampilkan dan sumbernya.

Hasil read-only dapat kedaluwarsa jika endpoint RPC terlambat atau antarmuka menyimpan data lama dalam cache.

Panggilan read-only juga dapat gagal jika fungsi revert dalam kondisi state saat ini.

ABI membuat data kontrak read-only dapat diakses oleh pengguna dan aplikasi.

Inilah salah satu alasan ABI sangat penting bagi dashboard dan alat portofolio.

ABI dan Transaksi yang Mengubah State

Transaksi yang mengubah state menggunakan encoding ABI untuk meminta perubahan pada state kontrak.

Contohnya mencakup transfer token, approval spender, deposit collateral, peminjaman, pembayaran kembali, staking, voting, minting, listing NFT, atau claim reward.

Transaksi ini biasanya memerlukan signature wallet dan biaya jaringan.

ABI memberi tahu wallet atau aplikasi cara mengenkode panggilan, tetapi signature pengguna mengotorisasi transaksi sebenarnya.

ABI yang benar tidak membuat transaksi aman apabila kontrak yang dipanggil berbahaya atau parameternya berisiko.

Pengguna tetap dapat menyetujui spender berbahaya, mengirim aset ke alamat salah, atau berinteraksi dengan kontrak palsu melalui calldata yang dienkode ABI.

Pengguna harus membandingkan tindakan yang didekode dengan tindakan yang mereka maksudkan.

Developer harus menggunakan nama fungsi, event, dan input berjenis yang jelas untuk mengurangi kebingungan pengguna.

Panggilan ABI yang mengubah state harus diperlakukan sebagai instruksi finansial.

Setelah dikonfirmasi, blockchain mungkin tidak menyediakan cara sederhana untuk membatalkannya.

ABI dan Token ERC-20

Token ERC-20 menggunakan antarmuka umum yang dipahami banyak wallet dan aplikasi.

Standar resmi token ERC-20 mendefinisikan fungsi dan event seperti totalSupply, balanceOf, transfer, allowance, approve, transferFrom, Transfer, dan Approval.

ABI untuk token bergaya ERC-20 memungkinkan perangkat lunak memanggil fungsi tersebut dan mendekode eventnya.

Inilah alasan banyak wallet dapat menampilkan saldo dan approval token tanpa integrasi khusus untuk setiap token.

Namun, tidak setiap token berperilaku sama persis dalam praktiknya.

Beberapa token mungkin memiliki biaya, logika rebasing, pause, blacklist, upgradeability, atau perilaku return yang tidak biasa.

ABI dapat menjelaskan antarmuka yang dapat dipanggil, tetapi tidak menjelaskan setiap risiko ekonomi atau izin.

ABI token membantu perangkat lunak berinteraksi dengan token, tetapi pengguna tetap harus meninjau perilaku kontrak token.

Developer tidak boleh mengasumsikan setiap token dengan ABI yang familier aman untuk setiap integrasi DeFi.

Kompatibilitas ABI berguna, tetapi kompatibilitas perilaku juga harus diuji.

ABI dan NFT

Kontrak NFT juga mengandalkan antarmuka berbasis ABI untuk kepemilikan, approval, transfer, metadata, dan event.

Standar resmi ERC-721 mendefinisikan antarmuka untuk non-fungible token.

Standar resmi ERC-1155 mendefinisikan antarmuka multi-token yang dapat merepresentasikan aset fungibel dan nonfungibel.

Wallet dan marketplace menggunakan ABI untuk memanggil ownerOf, tokenURI, safeTransferFrom, balanceOf, setApprovalForAll, dan fungsi NFT terkait jika didukung.

ABI juga membantu mendekode event transfer NFT dan event approval.

Namun, ABI tidak membuktikan bahwa gambar, koleksi, atau metadata NFT autentik.

Kontrak NFT palsu dapat mengekspos fungsi ABI yang familier sambil menyalin nama atau karya seni proyek lain.

Pengguna harus memverifikasi alamat kontrak, detail koleksi, metadata, konteks marketplace, dan sumber proyek resmi sebelum mempercayai NFT.

ABI membantu berinteraksi dengan NFT, tetapi tidak mensertifikasi nilai budaya, legal, atau pasar.

Keamanan NFT memerlukan dekode teknis dan pemeriksaan autentisitas.

ABI dan Proxy

Kontrak proxy yang dapat di-upgrade membuat penggunaan ABI lebih kompleks.

Alamat proxy dapat menjadi alamat yang diinteraksikan pengguna, sementara kontrak implementasi saat ini berisi logika dan ABI yang diharapkan pengguna.

Dokumentasi resmi upgrade smart contract Ethereum menjelaskan bahwa pola upgrade dapat mengubah perilaku smart contract setelah deployment.

Jika proxy di-upgrade, ABI yang diperlukan untuk berinteraksi dengannya dapat berubah.

Aplikasi yang menggunakan ABI lama dapat gagal atau menampilkan fungsi yang salah setelah upgrade.

Pengguna yang meninjau kontrak yang dapat di-upgrade harus memeriksa proxy dan implementasinya.

Blockchain explorer dapat menampilkan deteksi proxy, alamat implementasi, dan data ABI apabila tersedia.

Developer harus memublikasikan dan memverifikasi ABI untuk setiap implementasi baru.

Pengumuman upgrade harus menjelaskan apakah fungsi, event, atau izin yang dihadapi pengguna berubah.

Dalam sistem yang dapat di-upgrade, pengelolaan ABI merupakan bagian dari keamanan upgrade.

ABI vs API

ABI tidak sama dengan API web biasa.

API web biasanya menjelaskan cara perangkat lunak berkomunikasi dengan server melalui internet.

Smart contract ABI menjelaskan cara perangkat lunak mengenkode dan mendekode panggilan ke bytecode kontrak blockchain.

API web dapat diubah operator server tanpa mengubah state blockchain.

Smart contract ABI biasanya berkaitan dengan fungsi dan event kontrak yang telah di-deploy.

API web sering mengembalikan JSON langsung dari server.

Smart contract ABI menentukan cara data biner dikemas ke dalam calldata, return data, dan log.

Kedua konsep berkaitan karena keduanya membantu perangkat lunak berkomunikasi dengan sistem lain.

Perbedaannya adalah smart contract ABI terikat pada eksekusi on-chain yang deterministik dan data transaksi publik.

Bagi pengguna kripto, ABI berarti komunikasi kontrak, bukan akses API layanan pelanggan.

ABI vs Kode Sumber

ABI tidak sama dengan kode sumber smart contract.

Kode sumber menunjukkan logika internal, variabel state, modifier, inheritance, kondisi, dan perhitungan yang menentukan perilaku.

ABI menunjukkan antarmuka eksternal yang dapat dipanggil atau didekode perangkat lunak.

Kontrak dapat memiliki ABI sederhana tetapi perilaku internal yang kompleks.

Token dapat mengekspos fungsi transfer dan approve sambil menyembunyikan biaya atau aturan admin yang rumit dalam kode sumber.

Vault DeFi dapat mengekspos fungsi deposit dan withdraw sambil menggunakan pencatatan saham yang kompleks secara internal.

Pengguna tidak boleh menilai keamanan hanya dari ABI.

Developer dan auditor memerlukan kode sumber, bytecode, pengujian, pengaturan deployment, dan dokumentasi protokol untuk meninjau keamanan dengan tepat.

ABI memberi tahu pengguna cara berinteraksi, sedangkan kode sumber menjelaskan hal yang terjadi setelah interaksi.

Keduanya berguna, tetapi menjawab pertanyaan yang berbeda.

Risiko Keamanan ABI

Smart Contract ABI dapat menciptakan risiko keamanan apabila salah, lama, tidak lengkap, atau sengaja menyesatkan.

ABI yang salah dapat membuat perangkat lunak mengenkode panggilan secara keliru.

ABI lama dapat memanggil fungsi yang tidak lagi ada setelah upgrade.

Antarmuka berbahaya dapat menampilkan tindakan yang tampak tidak berbahaya sambil mengenkode panggilan kontrak yang berbahaya.

Website palsu dapat menggunakan ABI untuk meminta approval atau transfer dari wallet yang sah.

Blockchain explorer dapat mendekode data secara salah jika ABI tidak sesuai dengan bytecode yang di-deploy.

Pengguna tidak boleh mempercayai transaksi hanya karena nama fungsinya terlihat familier.

Mereka harus memverifikasi alamat kontrak, alamat spender, jumlah token, dan izin sebelum menandatangani.

Developer harus menyimpan file ABI di bawah version control dan memublikasikan artefak yang benar setelah deployment.

Keamanan ABI bergantung pada data antarmuka yang akurat dan peninjauan transaksi yang cermat.

Selector Collision

Selector collision terjadi ketika dua signature fungsi berbeda menghasilkan selector empat byte yang sama.

Karena function selector hanya terdiri dari empat byte, collision mungkin terjadi meskipun tidak umum dalam desain kontrak biasa.

Selector collision paling penting dalam sistem proxy, sistem plugin, arsitektur bergaya diamond, dan kontrak dengan banyak fungsi.

Jika routing selector dirancang dengan buruk, panggilan dapat mencapai logika yang tidak dimaksudkan.

Developer harus menggunakan alat untuk mendeteksi konflik selector dalam sistem yang kompleks.

Mereka juga harus menghindari overload fungsi yang tidak perlu dalam antarmuka pengguna ketika kejelasan lebih penting daripada kekompakan.

Pengguna jarang perlu menghitung selector secara manual, tetapi mereka mendapat manfaat ketika developer merancang antarmuka yang bersih.

Peninjau keamanan harus memperhatikan selector saat mengaudit proxy dan sistem kontrak modular.

Selector collision mengingatkan bahwa detail ABI dapat menjadi detail keamanan.

Nama fungsi yang mudah dibaca hanyalah label untuk selector tingkat rendah dan data yang dienkode.

ABI dan Antarmuka yang Mudah Dibaca Manusia

Banyak alat developer dapat mengekspresikan ABI dalam format yang mudah dibaca manusia alih-alih JSON lengkap.

ABI yang mudah dibaca manusia dapat berisi string sederhana seperti function transfer(address,uint256) returns (bool).

Format ini dapat lebih mudah ditulis developer dalam skrip dan pengujian.

ABI JSON lengkap tetap umum dalam artefak compiler dan build aplikasi produksi.

String ABI yang mudah dibaca manusia berguna ketika developer hanya memerlukan sebagian kecil dari antarmuka kontrak.

Misalnya, skrip mungkin hanya memerlukan balanceOf dan transfer, bukan ABI token keseluruhan.

Namun, ABI parsial dapat menyembunyikan fungsi dan event yang penting untuk peninjauan.

Developer harus menggunakan ABI lengkap saat membangun aplikasi penuh atau alur kerja verifikasi.

Pengguna harus mengetahui bahwa aplikasi dapat berinteraksi dengan kontrak hanya menggunakan fungsi yang diketahuinya.

ABI parsial praktis untuk pengembangan, tetapi bukan deskripsi kontrak lengkap.

ABI dan NatSpec

NatSpec adalah format spesifikasi bahasa alami Solidity untuk mendokumentasikan kontrak, fungsi, parameter, nilai yang dikembalikan, dan catatan developer.

Dokumentasi resmi Solidity NatSpec menjelaskan cara developer menyediakan dokumentasi pengguna dan developer langsung dalam komentar kode sumber.

NatSpec berbeda dari ABI, tetapi dapat melengkapi interaksi berbasis ABI.

ABI memberi tahu perangkat lunak jenis fungsi dan aturan encoding.

NatSpec dapat menjelaskan tujuan fungsi dan makna parameternya.

Wallet dan antarmuka dapat menggunakan metadata seperti dokumentasi untuk menampilkan prompt penandatanganan yang lebih jelas jika didukung.

Developer harus mendokumentasikan fungsi berisiko, izin, dan dampak yang dihadapi pengguna dengan jelas.

ABI dapat menampilkan fungsi bernama approve, tetapi dokumentasi dapat menjelaskan alasan spender dan jumlahnya penting.

Dokumentasi yang lebih baik dapat mengurangi kesalahan pengguna dan meningkatkan keterbacaan audit.

ABI ditambah NatSpec menciptakan bridge yang lebih kuat antara interaksi kontrak tingkat rendah dan pemahaman manusia.

ABI dan Panggilan Lintas Kontrak

Smart contract dapat menggunakan antarmuka untuk memanggil kontrak lain.

Dalam Solidity, antarmuka dapat menentukan signature fungsi yang diharapkan akan dipanggil kontrak lain.

Hal ini berkaitan dengan konsep ABI karena pemanggil harus mengenkode function selector dan argumen dengan benar.

Panggilan lintas kontrak merupakan inti composability DeFi karena protokol memanggil kontrak token, kontrak oracle, kontrak vault, kontrak governance, dan kontrak aplikasi lainnya.

Namun, antarmuka hanya menjelaskan fungsi yang diharapkan dapat dipanggil.

Antarmuka tidak membuktikan bahwa kontrak pada address tujuan berperilaku aman.

Kontrak berbahaya dapat mengekspos ABI yang diharapkan sambil melakukan hal tidak terduga secara internal.

Developer harus memvalidasi address kontrak eksternal dan asumsi sebelum mengintegrasikannya.

Mereka juga harus menangani panggilan gagal dan nilai return tidak terduga dengan cermat.

Kompatibilitas ABI membantu kontrak berkomunikasi, tetapi kepercayaan dan perilaku tetap harus ditinjau.

ABI dan Blockchain Explorer

Blockchain explorer menggunakan ABI untuk menampilkan interaksi kontrak yang mudah dibaca.

Ketika ABI tersedia, explorer dapat mendekode data input transaksi, event log, serta fungsi baca atau tulis kontrak.

Hal ini membantu pengguna melihat apakah transaksi memanggil transfer, approve, mint, stake, withdraw, atau fungsi lain.

Hal ini juga membantu developer melakukan debugging transaksi gagal dan memeriksa riwayat event.

Jika kontrak terverifikasi, explorer sering dapat membuat halaman interaksi kontrak dari ABI.

Jika kontrak tidak terverifikasi, explorer dapat menampilkan calldata mentah atau mengandalkan ABI yang dikirimkan.

Pengguna harus berhati-hati ketika berinteraksi langsung melalui panel tulis blockchain explorer karena setiap tindakan yang ditandatangani tetap memengaruhi aset nyata.

Formulir ABI yang mudah dibaca tidak membuat kontrak aman.

Formulir tersebut hanya membuat interaksi lebih mudah dipahami.

Blockchain explorer adalah alat riset yang berguna, tetapi keamanan wallet dan due diligence kontrak tetap diperlukan.

Kesalahan Umum pada Smart Contract ABI

Kesalahan umum pertama adalah mengasumsikan ABI membuktikan kontrak aman.

Kesalahan kedua adalah menggunakan ABI dari versi kontrak lain.

Kesalahan ketiga adalah menggunakan ABI implementasi tanpa memahami address proxy.

Kesalahan keempat adalah mempercayai nama fungsi yang didekode tanpa memverifikasi address kontrak.

Kesalahan kelima adalah menggunakan ABI parsial dan melewatkan event atau error penting.

Kesalahan keenam adalah mengabaikan fungsi yang di-overload dan memilih signature yang salah.

Kesalahan ketujuh adalah lupa memperbarui file ABI front end setelah upgrade kontrak.

Kesalahan kedelapan adalah memperlakukan kompatibilitas ABI token sebagai bukti bahwa token berperilaku aman.

Kesalahan kesembilan adalah berinteraksi dengan kontrak yang tidak terverifikasi melalui calldata mentah tanpa memahami risikonya.

Kesalahan kesepuluh adalah mengasumsikan dekode wallet selalu lengkap dan akurat.

Cara Mengevaluasi Smart Contract ABI

Mulailah dengan mengonfirmasi bahwa ABI berasal dari address kontrak tepat yang akan Anda interaksikan.

Periksa apakah kontrak adalah proxy dan apakah ABI seharusnya berasal dari kontrak implementasi.

Periksa apakah kode sumber telah diverifikasi dan apakah ABI sesuai dengan sumber terverifikasi.

Periksa apakah ABI mencakup fungsi, event, error, detail constructor, serta fungsi receive atau fallback khusus jika relevan.

Periksa apakah versi ABI sesuai dengan versi kontrak yang di-deploy setelah upgrade.

Periksa apakah ABI lengkap atau hanya antarmuka parsial yang digunakan skrip.

Tinjau fungsi sensitif seperti approve, transferFrom, mint, burn, pause, upgradeTo, setOracle, withdraw, dan setRole.

Periksa apakah aplikasi yang dihadapi pengguna menampilkan detail transaksi hasil dekode ABI dengan jelas.

Gunakan artefak developer tepercaya, data explorer terverifikasi, atau repositori proyek resmi jika memungkinkan.

Peninjauan ABI yang baik menanyakan apakah antarmuka benar, lengkap, terbaru, dan terhubung ke address yang tepat.

Manfaat Smart Contract ABI

Manfaat pertama Smart Contract ABI adalah interaksi smart contract yang mudah dibaca.

Manfaat kedua adalah encoding panggilan fungsi yang andal.

Manfaat ketiga adalah dekode return data dan event log.

Manfaat keempat adalah tampilan transaksi wallet yang lebih baik.

Manfaat kelima adalah pengembangan dApp yang lebih mudah karena front end dapat memanggil kontrak melalui antarmuka terstruktur.

Manfaat keenam adalah kegunaan blockchain explorer yang lebih baik karena pengguna dapat memeriksa fungsi dan event dengan lebih jelas.

Manfaat ketujuh adalah otomatisasi yang lebih baik untuk skrip, bot, indexer, dan sistem pemantauan.

Manfaat kedelapan adalah pengujian kontrak yang lebih mudah karena alat dapat membuat objek kontrak dari definisi ABI.

Manfaat kesembilan adalah integrasi yang lebih lancar dengan standar token dan protokol aplikasi.

Manfaat kesepuluh adalah transparansi yang lebih besar ketika data ABI terhubung dengan kode sumber terverifikasi.

Risiko dan Keterbatasan Smart Contract ABI

Keterbatasan pertama adalah ABI tidak membuktikan keamanan kontrak.

Keterbatasan kedua adalah ABI tidak menunjukkan seluruh logika internal.

Keterbatasan ketiga adalah ABI yang salah dapat mengenkode atau mendekode data secara keliru.

Keterbatasan keempat adalah ABI lama dapat merusak aplikasi setelah upgrade.

Keterbatasan kelima adalah ABI parsial dapat menyembunyikan fungsi atau event penting.

Keterbatasan keenam adalah dekode ABI dapat membuat transaksi berbahaya terlihat lebih familier daripada kondisi sebenarnya.

Keterbatasan ketujuh adalah function selector collision dapat penting dalam sistem kompleks.

Keterbatasan kedelapan adalah kompatibilitas ABI tidak menjamin kompatibilitas perilaku.

Keterbatasan kesembilan adalah pengguna tetap dapat salah memahami prompt transaksi yang didekode.

Keterbatasan kesepuluh adalah data ABI biasanya memerlukan verifikasi kode sumber, dokumentasi, dan peninjauan keamanan agar benar-benar berguna.

Praktik Terbaik untuk Developer

Hasilkan ABI dari artefak compiler tepat yang digunakan untuk deployment.

Simpan file ABI di bawah version control dengan versi kontrak dan address deployment yang jelas.

Publikasikan kode sumber terverifikasi agar blockchain explorer dan pengguna dapat mengonfirmasi data ABI.

Perbarui file ABI front end setelah setiap upgrade atau redeployment kontrak.

Gunakan ABI lengkap untuk aplikasi penuh dan tandai ABI parsial dengan jelas dalam skrip.

Hindari overload yang membingungkan pada kontrak yang dihadapi pengguna ketika kejelasan lebih berharga daripada kekompakan.

Dokumentasikan fungsi sensitif dengan komentar NatSpec yang jelas.

Uji panggilan berbasis ABI dalam skrip deployment, front end, dan alat pemantauan sebelum peluncuran.

Periksa perilaku ABI proxy dan implementasi dengan cermat selama upgrade.

Perlakukan akurasi ABI sebagai bagian dari keamanan produksi dan keselamatan pengguna.

Praktik Terbaik untuk Pengguna

Periksa bahwa address kontrak benar sebelum mempercayai informasi hasil dekode ABI.

Gunakan halaman blockchain explorer terverifikasi atau sumber proyek resmi saat meninjau ABI kontrak.

Jangan mengasumsikan nama fungsi yang mudah dibaca berarti transaksi aman.

Tinjau jumlah token, address spender, address penerima, tenggat waktu, dan izin sebelum menandatangani.

Berhati-hatilah ketika website meminta signature terkait approval, transfer, permit, mint, claim, atau upgrade.

Ingat bahwa ABI menjelaskan cara berinteraksi dengan kontrak, bukan apakah kontrak tersebut jujur atau aman.

Periksa apakah kontrak dapat di-upgrade dan apakah ABI berubah setelah pembaruan implementasi.

Hindari menandatangani transaksi calldata mentah kecuali Anda memahami dengan tepat tindakan panggilan tersebut.

Gunakan simulasi transaksi dan peringatan wallet sebagai sinyal yang membantu, bukan jaminan sempurna.

Perlakukan setiap transaksi hasil dekode ABI sebagai instruksi finansial nyata sebelum menyetujuinya.

FAQ

Apa arti Smart Contract ABI?

Smart Contract ABI berarti Application Binary Interface, yaitu antarmuka terstruktur yang digunakan untuk mengenkode panggilan smart contract dan mendekode output kontrak, log, serta error.

Apakah ABI sama dengan kode smart contract?

Tidak, ABI menjelaskan antarmuka eksternal, sedangkan kode smart contract menentukan logika internal yang benar-benar dieksekusi secara on-chain.

Mengapa wallet memerlukan ABI?

Wallet menggunakan data ABI untuk mendekode panggilan transaksi dan menampilkan informasi yang lebih mudah dibaca kepada pengguna mengenai fungsi kontrak yang dipanggil.

Apakah ABI membuktikan bahwa kontrak aman?

Tidak, ABI hanya menjelaskan cara berinteraksi dengan kontrak dan tidak membuktikan bahwa logika kontrak aman, telah diaudit, atau jujur.

Dari mana smart contract ABI berasal?

Smart contract ABI biasanya berasal dari artefak compiler, kode sumber terverifikasi, metadata kontrak, file developer resmi, atau database blockchain explorer.

Apa itu calldata terkait ABI?

Calldata adalah data input yang dienkode ABI dan dikirim ke fungsi smart contract dalam transaksi atau panggilan read-only.

Apa itu function selector?

Function selector adalah empat byte pertama calldata yang mengidentifikasi fungsi smart contract yang harus dipanggil.

Apakah ABI dapat salah?

Ya, ABI dapat salah, lama, tidak lengkap, atau dicocokkan dengan kontrak yang salah, sehingga dapat menyebabkan panggilan gagal atau data hasil dekode yang menyesatkan.

Mengapa ABI penting bagi blockchain explorer?

Blockchain explorer menggunakan ABI untuk mendekode data input transaksi, event log, error, dan panel interaksi kontrak menjadi informasi yang mudah dibaca.

Bagaimana upgradeability memengaruhi ABI?

Upgradeability dapat mengubah logika kontrak dan fungsi yang dihadapi pengguna, sehingga aplikasi mungkin memerlukan ABI baru ketika proxy menunjuk ke implementasi baru.

Kesimpulan

Smart Contract ABI (Application Binary Interface) adalah deskripsi antarmuka standar yang memungkinkan perangkat lunak berkomunikasi dengan smart contract melalui panggilan fungsi yang dienkode, return data, event, dan error.

ABI sangat penting bagi wallet, aplikasi terdesentralisasi, blockchain explorer, skrip developer, indexer, sistem analitik, dan otomatisasi kontrak.

ABI mengubah fungsi kontrak yang mudah dibaca manusia menjadi calldata tingkat rendah dan mengubah return data atau log tingkat rendah kembali menjadi nilai yang mudah dibaca.

ABI mendukung function selector, parameter berjenis, array, tuple, event, custom error, constructor, fungsi receive, dan fungsi fallback.

Smart Contract ABI meningkatkan kegunaan, transparansi, dan produktivitas developer, tetapi tidak membuktikan kontrak aman.

Pengguna tetap harus memverifikasi address kontrak, meninjau detail transaksi, memeriksa verifikasi kode sumber, memahami approval, dan berhati-hati terhadap sistem yang dapat di-upgrade.

Developer harus memublikasikan artefak ABI yang akurat, menjaganya tetap sinkron dengan deployment, memverifikasi kode sumber, mendokumentasikan fungsi sensitif, dan memperbarui data ABI setelah upgrade.

Bagi pemula, smart contract ABI paling mudah dipahami sebagai antarmuka yang mudah dibaca dan membantu aplikasi serta wallet berkomunikasi dengan kontrak blockchain.

Bagi pengguna tingkat lanjut, ABI adalah skema encoding dan decoding ketat yang menghubungkan antarmuka JSON, selector, calldata, return data, log, implementasi proxy, dan alat developer.

Dalam konteks glosarium kripto, Smart Contract ABI berarti spesifikasi antarmuka kontrak yang memungkinkan interaksi terstruktur dan mudah dibaca dengan smart contract berbasis EVM.

Poin utamanya adalah ABI merupakan bridge antara pengguna, perangkat lunak, dan bytecode on-chain, tetapi interaksi kripto yang aman tetap memerlukan verifikasi address, peninjauan kode sumber, kehati-hatian dalam menggunakan wallet, serta pemahaman bahwa data antarmuka tidak sama dengan keamanan.