Fallback Function

Apa Itu Fallback Function?

Fallback function adalah fungsi khusus Solidity yang menangani panggilan eksternal yang tidak cocok dengan fungsi lain yang didefinisikan oleh smart contract.

Fungsi ini menjadi opsi terakhir untuk mengarahkan panggilan ketika Solidity tidak dapat mengidentifikasi fungsi biasa dari data transaksi yang diberikan.

Fallback function juga dapat dijalankan ketika panggilan tidak berisi data dan kontrak tidak memiliki fungsi receive terpisah.

Fungsi ini banyak digunakan dalam aplikasi mata uang kripto, termasuk smart contract yang dapat di-upgrade, sistem proxy, wallet modular, kontrak pembayaran, dan router panggilan khusus.

Menurut dokumentasi resmi Solidity, sebuah kontrak hanya dapat memiliki maksimal satu fallback function.

Fallback function harus memiliki visibilitas external karena dirancang untuk merespons panggilan yang datang dari luar kontrak.

Fungsi ini dapat bersifat payable jika kontrak perlu menerima mata uang kripto native melalui panggilan yang tidak cocok dengan fungsi mana pun.

Fungsi ini juga dapat memeriksa seluruh data transaksi dan mengembalikan data respons mentah ketika menggunakan bentuk lanjutan.

Fallback function bukan penangan error umum untuk setiap operasi smart contract yang gagal.

Fungsi ini hanya berjalan dalam kondisi pengalihan panggilan tertentu yang ditetapkan oleh Solidity dan Ethereum Virtual Machine.

Mengapa Disebut Fallback Function?

Kata fallback menggambarkan tindakan alternatif yang digunakan ketika tindakan yang diutamakan atau diharapkan tidak tersedia.

Ketika pengguna memanggil fungsi smart contract biasa, Solidity terlebih dahulu mencoba mencocokkan data transaksi yang diberikan dengan salah satu fungsi yang dideklarasikan oleh kontrak.

Jika tidak ada kecocokan, kontrak akan beralih ke fallback function.

Perilaku ini memungkinkan developer menentukan tindakan yang harus dilakukan ketika wallet, smart contract, atau aplikasi mengirim panggilan yang tidak didukung.

Fallback function dapat menolak panggilan, menerima pembayaran, mencatat event, mengembalikan data, atau meneruskan panggilan ke kontrak lain.

Jika kontrak tidak memiliki fallback function yang sesuai, panggilan yang tidak didukung biasanya akan dibatalkan (revert).

Kapan Fallback Function Dipanggil?

Fallback function dipanggil ketika panggilan eksternal mencapai smart contract dan tidak ada fungsi biasa yang cocok dengan function selector yang diberikan.

Fungsi ini juga dipanggil ketika panggilan tidak berisi calldata dan kontrak tidak mendefinisikan fungsi receive.

Panggilan dengan data tidak kosong dapat mencapai fallback function, baik mengirim maupun tidak mengirim mata uang kripto native.

Fallback function harus bersifat payable jika panggilan menyertakan nilai mata uang kripto bukan nol.

Fallback function nonpayable menolak panggilan yang tidak cocok jika panggilan tersebut mencoba mentransfer nilai.

Panggilan dengan data kosong akan mencapai fungsi receive jika kontrak mendefinisikannya.

Karena itu, tugas fallback function berbeda bergantung pada apakah kontrak juga memiliki fungsi receive.

Bagaimana Pengalihan Fungsi Smart Contract Bekerja

Panggilan smart contract eksternal biasanya berisi data transaksi yang dienkode dan dikenal sebagai calldata.

Empat byte pertama dari panggilan fungsi standar berisi function selector.

Spesifikasi Solidity ABI menetapkan selector sebagai empat byte pertama dari hash Keccak-256 atas signature kanonis suatu fungsi.

Signature kanonis menggabungkan nama fungsi dengan jenis parameternya.

Solidity membandingkan selector yang masuk dengan selector fungsi public dan external milik kontrak.

Jika terdapat selector yang cocok, fungsi terkait akan memproses panggilan tersebut.

Jika tidak ada selector yang cocok, Solidity mengarahkan panggilan ke fallback function jika tersedia.

Calldata yang lebih pendek dari empat byte biasanya tidak dapat mengidentifikasi fungsi Solidity biasa sehingga dapat mencapai fallback function.

Calldata kosong mengikuti aturan pengalihan terpisah yang mengutamakan fungsi receive.

Fallback Function vs. Receive Function

Fallback function dan receive function adalah entry point Solidity yang terpisah dengan tujuan berbeda.

Receive function dirancang khusus untuk panggilan dengan calldata kosong.

Fallback function terutama menangani panggilan berisi data yang tidak cocok dengan fungsi yang dideklarasikan.

Receive function selalu bersifat payable karena tujuan utamanya adalah menerima mata uang kripto native.

Fallback function hanya bersifat payable jika developer secara eksplisit mengizinkannya untuk menerima nilai.

Jika kontrak mendefinisikan kedua fungsi, transfer dengan data kosong akan mencapai receive function.

Panggilan dengan data yang tidak cocok akan mencapai fallback function.

Jika kontrak tidak memiliki receive function, fallback function yang bersifat payable dapat memproses transfer dengan data kosong.

Panduan Solidity terbaru tentang penerimaan mata uang kripto menyarankan agar receive function didefinisikan jika terdapat fallback function yang bersifat payable.

Pemisahan ini membantu membedakan pembayaran yang disengaja dari panggilan fungsi dengan pengodean yang keliru.

Fallback Function vs. Fungsi Biasa

Fungsi Solidity biasa memiliki nama yang dideklarasikan dan biasanya memiliki function selector sendiri.

Aplikasi dapat memanggil fungsi biasa melalui antarmuka kontrak yang diketahui.

Fallback function tidak memiliki nama yang dapat dipanggil seperti fungsi biasa.

Fungsi ini tidak memiliki selector khusus yang dapat dipanggil pengguna secara langsung.

Sebaliknya, fungsi ini menangani panggilan yang tidak cocok dengan antarmuka biasa kontrak.

Kontrak dapat memiliki banyak fungsi biasa, tetapi hanya satu fallback function.

Fungsi biasa umumnya sebaiknya berisi logika bisnis utama aplikasi terdesentralisasi.

Fallback function sebaiknya memiliki tujuan yang terbatas dan terdokumentasi dengan jelas, kecuali jika memang digunakan sebagai router proxy.

Fallback Function vs. Penanganan Error

Fallback function tidak berjalan setiap kali fungsi smart contract lain gagal.

Jika calldata cocok dengan fungsi biasa dan fungsi tersebut kemudian mengalami revert, fallback function tidak akan dipanggil.

Jika fungsi yang cocok menolak pembayaran karena tidak bersifat payable, Solidity tidak mengalihkan pembayaran tersebut ke fallback function.

Jika function selector benar tetapi argumennya tidak terbentuk dengan benar, panggilan yang cocok biasanya mengalami revert saat proses decoding.

Kegagalan pada requirement, pemeriksaan aritmetika, aturan kontrol akses, panggilan eksternal, atau custom error juga tidak mengaktifkan fallback function.

Developer harus menangani kegagalan ini melalui penanganan error biasa, pemeriksaan nilai return, custom error, atau logika try-and-catch yang sesuai.

Fallback function menangani panggilan yang tidak cocok, bukan kegagalan di dalam panggilan yang cocok.

Apa Itu Fallback Function Payable?

Fallback function payable dapat menerima mata uang kripto native yang disertakan dalam panggilan eksternal yang tidak cocok.

Jumlah yang dikirim melalui panggilan tersedia melalui kolom nilai transaksi.

Alamat pengirim juga tersedia bagi fallback function.

Fallback function payable dapat memperbarui state, memancarkan event, meneruskan panggilan, atau melakukan tindakan lain yang diizinkan jika tersedia cukup gas.

Menjadikan fallback function payable menimbulkan tanggung jawab finansial bagi kontrak.

Kontrak mungkin memerlukan pencatatan saldo yang andal, penarikan yang terkendali, prosedur darurat, dan perlindungan terhadap reentrancy.

Kontrak yang tidak dirancang untuk menyimpan mata uang kripto biasanya sebaiknya menolak pembayaran yang tidak diharapkan.

Status payable sebaiknya ditambahkan hanya jika mendukung tujuan protokol yang jelas.

Apa Itu Fallback Function Nonpayable?

Fallback function nonpayable dapat memproses panggilan yang tidak cocok dan tidak mentransfer mata uang kripto native.

Panggilan yang tidak cocok dan membawa nilai bukan nol akan mengalami revert jika fallback function tidak bersifat payable.

Desain ini berguna ketika kontrak memerlukan pengalihan atau pencatatan khusus, tetapi tidak boleh menerima dana.

Fallback function nonpayable juga dapat secara eksplisit menolak function selector yang tidak didukung.

Penolakan terhadap panggilan yang tidak dikenal dapat membantu pengguna dan aplikasi mendeteksi penggunaan antarmuka yang keliru.

Informasi Apa yang Dapat Dibaca Fallback Function?

Fallback function dapat mengakses alamat yang memulai panggilan saat ini.

Fungsi ini dapat mengakses jumlah mata uang kripto native yang disertakan dalam panggilan jika bersifat payable.

Fungsi ini dapat memeriksa seluruh calldata yang diberikan oleh pemanggil.

Calldata lengkap mencakup kemungkinan selector dan nilai tambahan yang dienkode.

Bentuk fallback function berparameter dapat menerima data ini sebagai rangkaian byte.

Fungsi ini juga dapat langsung mengembalikan byte mentah kepada pemanggil.

Solidity tidak secara otomatis menerapkan pengodean ABI biasa pada data return mentah dari fallback.

Perilaku ini sangat berguna bagi kontrak proxy yang perlu mengembalikan persis seperti data yang dikembalikan kontrak implementasi.

Haruskah Fallback Function Mendekode Calldata?

Fallback function dapat memeriksa dan mendekode calldata secara manual.

Empat byte pertama dapat dibandingkan dengan selector yang diharapkan.

Byte sisanya dapat didekode menjadi jenis parameter yang diharapkan.

Namun, dokumentasi Solidity menyarankan agar decoding manual dalam fallback hanya digunakan sebagai pilihan terakhir.

Fungsi biasa bernama menyediakan antarmuka yang lebih jelas, decoding otomatis yang lebih aman, dan integrasi yang lebih mudah.

Decoding manual harus memverifikasi panjang calldata, offset, jenis data, dan selector yang didukung.

Data yang tidak terbentuk dengan benar harus ditolak sebelum perubahan state yang sensitif dilakukan.

Decoding yang salah dapat menyebabkan perilaku tak terduga, transaksi gagal, atau kerentanan keamanan.

Fallback Function pada Kontrak Proxy yang Dapat Di-upgrade

Kontrak proxy yang dapat di-upgrade merupakan salah satu penggunaan fallback function terpenting dalam aplikasi mata uang kripto.

Proxy memisahkan alamat kontrak dan state tersimpan dari kode yang memuat logika bisnis aplikasi.

Pengguna mengirim transaksi ke alamat proxy.

Proxy menyimpan alamat kontrak implementasi yang memuat logika aktif.

Panggilan yang tidak cocok dengan fungsi yang didefinisikan langsung oleh proxy akan mencapai fallback function-nya.

Fallback function meneruskan panggilan tersebut ke kontrak implementasi melalui delegatecall.

Dokumentasi Ethereum tentang upgrade proxy menjelaskan bahwa struktur ini memungkinkan logika bisnis diubah sementara pengguna tetap berinteraksi dengan alamat proxy yang sama.

Proxy mempertahankan saldo dan penyimpanan aplikasi setelah implementasi diubah.

Pendekatan ini dapat mendukung perbaikan bug dan fitur baru tanpa memindahkan semua pengguna ke alamat kontrak baru.

Apa Itu Delegatecall?

Delegatecall adalah operasi Ethereum Virtual Machine yang menjalankan kode dari kontrak lain dalam konteks kontrak pemanggil.

Dalam sistem proxy, kontrak implementasi menyediakan kode.

Proxy menyediakan alamat, saldo mata uang kripto, dan penyimpanan permanen.

Pengirim awal dan nilai transaksi tetap tersedia selama eksekusi terdelegasi.

Karena itu, implementasi bertindak seolah-olah logikanya merupakan bagian dari proxy.

EIP-7 memperkenalkan delegatecall sebagai operasi tingkat rendah untuk menjalankan kode eksternal sambil mempertahankan konteks pengirim dan nilai milik pemanggil.

Delegatecall sangat kuat karena implementasi dapat membaca dan mengubah penyimpanan proxy.

Alasan yang sama juga membuatnya berbahaya.

Implementasi yang berbahaya atau tidak kompatibel dapat merusak saldo, izin, data kepemilikan, atau state penting lainnya.

Bagaimana Fallback Function Proxy Mengarahkan Panggilan

Proxy terlebih dahulu menerima seluruh calldata dari pengguna.

Fallback function-nya mengidentifikasi alamat implementasi saat ini.

Proxy meneruskan calldata asli ke implementasi tersebut melalui delegatecall.

Implementasi menjalankan logikanya menggunakan penyimpanan proxy.

Proxy menerima data respons dari implementasi.

Jika panggilan terdelegasi berhasil, proxy mengembalikan respons yang sama kepada pemanggil awal.

Jika panggilan terdelegasi gagal, proxy sebaiknya meneruskan informasi kegagalan asli kepada pemanggil.

Penerusan yang keliru dapat menyembunyikan error, mengubah data return, atau menyebabkan integrasi menafsirkan hasil secara salah.

Slot Penyimpanan Proxy

Proxy harus menyimpan alamat implementasinya di suatu lokasi dalam penyimpanan kontrak permanen.

Lokasi penyimpanan tersebut tidak boleh bertabrakan dengan variabel yang digunakan kontrak implementasi.

ERC-1967 menetapkan slot penyimpanan terstandar untuk informasi implementasi, beacon, dan administrator proxy.

Lokasi ini dipilih agar tidak bertabrakan dengan slot penyimpanan biasa yang ditetapkan compiler Solidity.

Slot terstandar juga membantu blockchain explorer dan alat pengembangan mengidentifikasi hubungan proxy.

Penggunaan slot penyimpanan yang sudah mapan mengurangi risiko tabrakan yang tidak disengaja, tetapi tidak menghilangkan semua risiko upgrade.

Versi implementasi tetap harus mempertahankan tata letak penyimpanan yang kompatibel.

Risiko Tata Letak Penyimpanan

Proxy mempertahankan data yang sudah ada ketika kontrak implementasi di-upgrade.

Implementasi baru harus menafsirkan data tersimpan tersebut dengan cara yang sama seperti implementasi sebelumnya.

Mengubah urutan variabel state yang sudah ada dapat menyebabkan satu nilai dibaca sebagai nilai lainnya.

Mengubah jenis variabel dapat merusak maknanya atau membuatnya tidak dapat diakses.

Mengubah inheritance juga dapat mengubah tata letak penyimpanan yang diharapkan.

Variabel state baru harus ditambahkan sesuai aturan penyimpanan arsitektur proxy yang dipilih.

Upgrade dapat berhasil pada tingkat transaksi, tetapi diam-diam merusak penyimpanan kontrak.

Karena itu, kompatibilitas penyimpanan harus diperiksa sebelum setiap pembaruan implementasi.

Tabrakan Function Selector

Function selector hanya terdiri dari empat byte.

Dua signature fungsi yang berbeda secara teoretis dapat menghasilkan selector yang sama.

Peristiwa ini dikenal sebagai tabrakan selector.

Tabrakan menjadi sangat penting ketika proxy dan implementasinya sama-sama mendefinisikan fungsi yang dapat dipanggil.

Proxy dapat mengambil alih selector yang diharapkan pengguna untuk diteruskan ke implementasi.

ERC-1967 menjelaskan bahwa tabrakan selector dapat menyebabkan respons tak terduga dan bahkan menyembunyikan perilaku proxy yang berbahaya.

Developer sebaiknya menguji semua selector di antara fungsi proxy, fungsi implementasi, fungsi administratif, dan upgrade yang direncanakan.

Nama fungsi saja tidak cukup untuk membuktikan bahwa selectornya unik di beberapa kontrak.

Risiko Wewenang Upgrade

Proxy yang dapat di-upgrade biasanya memiliki akun atau mekanisme tata kelola yang berwenang mengubah alamat implementasinya.

Pihak yang mengendalikan wewenang tersebut dapat mengubah kode yang dijalankan melalui fallback function.

Upgrade key yang diretas dapat memasang implementasi yang mentransfer aset atau mengubah saldo akun.

Administrator yang berniat jahat juga dapat mengganti logika yang sah dengan logika berbahaya.

Pengguna sebaiknya memeriksa alamat administrator, ambang batas penanda tangan, proses tata kelola, jeda eksekusi, wewenang darurat, dan riwayat upgrade.

Fallback function proxy yang kode sumbernya telah diverifikasi tidak menjamin bahwa setiap implementasi di masa mendatang aman.

Kemampuan upgrade menimbulkan kebutuhan akan kepercayaan berkelanjutan terhadap tata kelola dan operasional.

Fallback Function pada Kontrak Diamond

Kontrak diamond mengarahkan function selector yang berbeda ke beberapa kontrak implementasi yang dikenal sebagai facet.

Fallback function memeriksa selector yang masuk dan menentukan facet yang bertanggung jawab atas fungsi tersebut.

Fungsi ini kemudian meneruskan panggilan ke facet yang dipilih melalui delegatecall.

ERC-2535 menetapkan arsitektur proxy multifacet untuk sistem smart contract modular.

Desain ini dapat mendukung aplikasi dengan logika yang terlalu besar untuk ditampung secara praktis dalam satu kontrak implementasi.

Kelompok fungsi tertentu juga dapat ditambahkan, diganti, atau dihapus.

Fleksibilitas ini menambah kompleksitas selector, penyimpanan, inisialisasi, izin, dan upgrade.

Meninjau satu facet saja tidak akan menunjukkan semua perilaku yang dapat diakses melalui alamat diamond.

Fallback Function pada Smart Account Modular

Akun smart contract dapat menggunakan fallback handler untuk menambahkan fitur modular.

Handler dapat mendukung tanda tangan, callback token, pemulihan akun, izin sesi, atau antarmuka khusus aplikasi.

ERC-7579 menjelaskan fallback handler sebagai modul yang dapat memperluas fungsi smart account.

Akun harus mengendalikan handler mana yang dapat dipasang, diganti, dan dihapus.

Handler tanpa izin dapat menciptakan jalur menuju perilaku akun yang tidak diharapkan.

Pengguna wallet sebaiknya memahami bahwa perubahan modul fallback dapat mengubah respons akun terhadap panggilan eksternal.

Gas dan Fallback Function

Fallback function dapat melakukan operasi kompleks jika pemanggil menyediakan gas yang cukup.

Fungsi ini tidak boleh berasumsi bahwa setiap pemanggil menyediakan jumlah gas yang sama.

Beberapa metode transfer mata uang kripto yang lebih lama hanya meneruskan sedikit gas kepada kontrak penerima.

Dokumentasi Solidity saat ini memperingatkan bahwa send dan transfer tidak lagi disarankan dan dijadwalkan untuk dihapus.

Stipend kecil mungkin tidak cukup untuk memperbarui penyimpanan, melakukan transfer tambahan, membuat kontrak, atau menjalankan panggilan eksternal yang mahal.

Biaya gas juga dapat berubah akibat upgrade jaringan.

Karena itu, jalur pembayaran sebaiknya tidak bergantung pada logika fallback yang rumit.

Developer tidak boleh menganggap alokasi gas kecil sebagai satu-satunya perlindungan terhadap callback berbahaya.

Risiko Reentrancy pada Fallback Function

Fallback function dapat memanggil kontrak lain jika tersedia cukup gas.

Fungsi ini dapat memanggil kembali kontrak yang semula mengirim mata uang kripto atau memulai interaksi.

Perilaku ini dapat menimbulkan reentrancy jika kontrak pengirim belum menyelesaikan akuntansinya sebelum panggilan eksternal.

Panduan keamanan Solidity tentang reentrancy menjelaskan bahwa panggilan kontrak eksternal dapat mengembalikan kendali sebelum operasi awal selesai.

Kontrak sebaiknya memvalidasi kondisi sebelum melakukan panggilan eksternal.

Kontrak sebaiknya memperbarui state internal yang penting sebelum menyerahkan kendali kepada kontrak yang tidak tepercaya.

Perlindungan reentrancy yang sesuai dapat memberikan lapisan pertahanan tambahan.

Setiap panggilan eksternal sebaiknya dianggap sebagai kemungkinan eksekusi kode yang tidak tepercaya.

Risiko Denial-of-Service

Fallback function dapat gagal secara sengaja atau tidak sengaja.

Jika kontrak lain mensyaratkan pembayaran berhasil sebelum menyelesaikan operasi yang lebih besar, penerima dapat menghalangi operasi tersebut.

Fallback function juga dapat menghabiskan terlalu banyak gas atau melakukan panggilan eksternal yang mahal.

Hal ini sangat berbahaya ketika satu pembayaran yang gagal menyebabkan seluruh perulangan distribusi mengalami revert.

Panduan Solidity tentang pengiriman mata uang kripto menyarankan desain berbasis penarikan untuk banyak sistem pembayaran.

Model penarikan memungkinkan setiap penerima mengklaim dana secara mandiri.

Dengan demikian, perilaku fallback satu penerima tidak mudah menghalangi pembayaran milik pengguna lain.

Keberhasilan Tak Terduga pada Panggilan Tingkat Rendah

Panggilan tingkat rendah melaporkan apakah eksekusi target berhasil atau mengalami revert.

Hasil yang berhasil tidak membuktikan bahwa fungsi bernama yang dimaksud benar-benar ada.

Selector yang tidak dikenal dapat mencapai fallback function yang permisif dan berhasil diproses.

Kontrak pemanggil yang hanya memeriksa status keberhasilan dapat keliru menganggap bahwa operasi yang diminta telah dilakukan.

Developer sebaiknya memvalidasi data return dan perubahan state yang diharapkan ketika menggunakan panggilan tingkat rendah.

Antarmuka bertipe umumnya lebih aman jika fungsi target sudah diketahui.

Fallback Function dan Mata Uang Kripto Native

Fallback function payable dapat menerima mata uang kripto native melalui panggilan yang tidak cocok.

Jika tidak ada receive function, fallback function juga dapat menangani transfer biasa dengan calldata kosong.

Kontrak tanpa receive atau fallback function payable biasanya menolak transfer langsung biasa.

Namun, kontrak tidak dapat menjamin bahwa saldonya akan selalu nol.

EVM memiliki cara khusus yang dapat meningkatkan saldo kontrak tanpa menjalankan logika receive atau fallback.

Akuntansi internal kontrak tidak boleh mengasumsikan bahwa saldo aktualnya selalu sama dengan total yang dicatat oleh fungsi penanganan pembayaran.

Fallback Function dan Token ERC-20

Transfer token ERC-20 biasa tidak memanggil fallback function kontrak penerima.

Kontrak token mengubah saldo di dalam penyimpanannya sendiri.

Kontrak penerima dapat menerima saldo token tanpa menjalankan kode apa pun.

ERC-20 menetapkan bahwa transfer dilakukan melalui kontrak token, bukan melalui callback penerima yang wajib.

Kontrak tidak boleh bergantung pada eksekusi fallback untuk mendeteksi setiap deposit token.

Aplikasi biasanya menggunakan fungsi deposit eksplisit atau aturan akuntansi saldo terpisah.

Fallback Function dan NFT

Beberapa metode transfer NFT yang aman memanggil fungsi penerima tertentu pada kontrak tujuan.

Fungsi penerima ini terpisah dari fallback function umum.

Jika fungsi penerima yang diharapkan tidak ada, panggilan dapat mencapai fallback karena selectornya tidak cocok.

Fallback yang permisif tidak sebaiknya meniru dukungan penerima NFT kecuali kontrak memang menerapkan perilaku yang diperlukan.

Respons yang keliru dapat menyebabkan transfer gagal atau menimbulkan masalah pemulihan aset.

Bisakah Fallback Function Memancarkan Event?

Fallback function dapat memancarkan event ketika menerima pembayaran atau panggilan yang tidak didukung.

Event dapat mencatat pengirim, jumlah yang ditransfer, selector, atau nilai lain yang berguna.

Informasi ini dapat membantu developer memantau integrasi dan menyelidiki aktivitas yang tidak terduga.

Pemancaran event menggunakan gas dan dapat gagal jika pemanggil memberikan alokasi yang sangat terbatas.

Event on-chain bersifat publik dan tidak boleh dianggap sebagai catatan rahasia.

Mencatat seluruh calldata juga dapat menimbulkan biaya yang tidak perlu karena data transaksi sudah dapat diamati secara publik.

Bisakah Fallback Function Mengubah Penyimpanan?

Fallback function dapat mengubah penyimpanan kontrak jika tersedia cukup gas.

Fungsi ini dapat memperbarui penghitung, catatan pembayaran, izin, informasi pengalihan, atau state lainnya.

Perubahan penyimpanan meningkatkan penggunaan gas dan memperluas dampak keamanan fungsi tersebut.

Fallback yang mengubah state penting sebaiknya memiliki kontrol akses yang jelas dan kondisi yang telah diuji dengan cermat.

Perilaku penerimaan pembayaran sebaiknya tidak bergantung pada penulisan penyimpanan jika pemanggil mungkin hanya menyediakan gas terbatas.

Bisakah Fallback Function Diwariskan?

Fallback function dapat berpartisipasi dalam inheritance Solidity.

Fungsi ini dapat dideklarasikan sebagai virtual dan diganti oleh kontrak turunan.

Fungsi ini juga dapat menggunakan modifier.

Inheritance dapat membuat perilaku panggilan akhir sulit dipahami ketika beberapa kontrak menyumbangkan logika terkait.

Auditor sebaiknya meninjau struktur inheritance hasil kompilasi secara keseluruhan, bukan hanya membaca satu file sumber.

Cara Menguji Fallback Function

Developer sebaiknya menguji panggilan yang berisi function selector empat byte yang tidak dikenal.

Developer sebaiknya menguji calldata yang lebih pendek dari empat byte.

Developer sebaiknya menguji calldata kosong tanpa mata uang kripto yang disertakan.

Developer sebaiknya menguji calldata kosong dengan mata uang kripto yang disertakan.

Developer sebaiknya menguji calldata tidak kosong yang tidak cocok, dengan maupun tanpa nilai yang disertakan.

Developer sebaiknya memverifikasi perbedaan pengalihan ketika receive function tersedia.

Proxy sebaiknya diuji untuk memastikan penerusan data return dan data revert yang benar.

Pengujian upgrade harus memastikan bahwa seluruh penyimpanan yang sudah ada tetap valid.

Pengujian keamanan sebaiknya mencakup reentrancy, tabrakan selector, calldata yang salah format, upgrade tanpa izin, dan gas yang tidak mencukupi.

Cara Mengaudit Fallback Function

Audit terlebih dahulu harus mengidentifikasi setiap jenis panggilan yang dapat mencapai fallback function.

Auditor harus menentukan apakah fungsi tersebut bersifat payable.

Kontrak harus diperiksa untuk mengetahui apakah memiliki receive function terpisah.

Setiap pembaruan penyimpanan, panggilan eksternal, modifier, operasi assembly, dan pemeriksaan hak istimewa harus ditinjau.

Audit proxy harus memverifikasi cara pemilihan alamat implementasi.

Target delegatecall tidak boleh dapat diubah oleh pengguna yang tidak berwenang.

Data return dan data revert harus diteruskan secara akurat.

Upgrade implementasi harus mempertahankan kompatibilitas penyimpanan.

Peninjauan juga harus memeriksa administrator, proses tata kelola, jeda upgrade, dan kontrol darurat.

Praktik Terbaik Fallback Function

Gunakan fungsi biasa bernama untuk perilaku aplikasi umum jika memungkinkan.

Definisikan receive function terpisah jika kontrak memang menerima transfer mata uang kripto native biasa.

Tolak selector yang tidak didukung jika pengalihan khusus tidak diperlukan.

Jaga agar perilaku fallback terkait pembayaran tetap sederhana.

Perlakukan semua calldata dan pemanggil sebagai pihak yang tidak tepercaya.

Validasi selector dan panjang data sebelum decoding manual.

Gunakan standar proxy yang telah ditinjau, bukan logika penerusan yang belum diuji.

Lindungi lokasi penyimpanan implementasi, administrator, dan beacon.

Pertahankan tata letak penyimpanan selama upgrade.

Terapkan kontrol akses yang jelas pada setiap fungsi upgrade.

Kembalikan data keberhasilan dan data kegagalan secara akurat saat meneruskan panggilan.

Gunakan urutan pembaruan state yang aman dan perlindungan reentrancy yang sesuai.

Uji panggilan tidak biasa yang mungkin tidak pernah dibuat oleh antarmuka wallet biasa.

Gunakan compiler Solidity stabil versi terbaru dan tinjau daftar resmi bug compiler yang diketahui.

Kesalahan Umum Fallback Function

Salah satu kesalahan umum adalah menganggap fallback berjalan setelah fungsi yang cocok mengalami revert.

Kesalahan lainnya adalah menjadikan fungsi ini payable tanpa sistem penarikan yang aman.

Beberapa kontrak menerima pembayaran biasa melalui fallback tanpa mendefinisikan receive function yang lebih jelas.

Decoding calldata manual dapat dilakukan tanpa memeriksa panjang data.

Pemanggil tingkat rendah dapat keliru menganggap eksekusi fallback yang berhasil sebagai keberhasilan eksekusi fungsi yang diminta.

Proxy dapat menyimpan alamat implementasi di lokasi yang bertabrakan dengan state aplikasi.

Upgrade dapat mengubah urutan variabel dan merusak saldo atau izin.

Tujuan delegatecall yang tidak dibatasi dapat memungkinkan kode apa pun dijalankan dalam konteks proxy.

Fallback yang kompleks dapat gagal jika menerima gas lebih sedikit daripada perkiraan.

Developer dapat keliru mengharapkan transfer ERC-20 memicu eksekusi fallback.

Kesalahpahaman Umum tentang Fallback Function

Fallback function bukan penangan error universal untuk smart contract.

Fungsi ini tidak dipanggil setelah setiap transaksi yang gagal.

Fungsi ini tidak otomatis bersifat payable.

Fungsi ini tidak selalu tepat untuk menerima pembayaran mata uang kripto biasa.

Kontrak hanya dapat memiliki satu fallback function.

Fallback function tidak memiliki function selector biasa.

Fungsi ini dapat memproses calldata yang tidak cocok meskipun tidak ada mata uang kripto yang ditransfer.

Fallback yang berhasil tidak membuktikan bahwa pemanggil menggunakan antarmuka kontrak yang benar.

Fallback proxy dapat membuat pengguna terpapar kode yang tidak disimpan di alamat proxy.

Memverifikasi kode sumber proxy saja tidak membuktikan bahwa implementasinya saat ini aman.

Pertanyaan Umum

Apa itu fallback function dalam Solidity?

Fallback function adalah fungsi external khusus yang menangani panggilan yang tidak cocok dengan fungsi lain dalam smart contract.

Kapan fallback function berjalan?

Fungsi ini berjalan ketika tidak ada fungsi yang dideklarasikan cocok dengan selector yang diberikan, atau ketika calldata kosong dan tidak ada receive function.

Bisakah kontrak memiliki beberapa fallback function?

Tidak. Kontrak Solidity hanya dapat memiliki maksimal satu fallback function.

Apakah fallback function memiliki nama?

Tidak. Fungsi ini dideklarasikan menggunakan kata kunci fallback, bukan nama fungsi biasa.

Apakah fallback function harus bersifat external?

Ya. Fallback function harus menggunakan visibilitas external.

Apakah fallback function otomatis bersifat payable?

Tidak. Fungsi ini hanya menerima mata uang kripto native jika secara eksplisit ditandai sebagai payable.

Apa yang terjadi jika nilai dikirim ke fallback nonpayable?

Panggilan yang tidak cocok akan mengalami revert jika mencoba mentransfer jumlah bukan nol.

Apa perbedaan fallback dan receive?

Receive menangani calldata kosong, sedangkan fallback terutama menangani panggilan yang tidak cocok dengan fungsi yang dideklarasikan.

Fungsi mana yang menangani transfer mata uang kripto biasa?

Receive menanganinya jika tersedia. Jika tidak ada receive function, fallback payable yang dapat menanganinya.

Apakah fallback berjalan setelah fungsi lain gagal?

Tidak. Kegagalan di dalam fungsi yang cocok tidak mengalihkan eksekusi ke fallback.

Bisakah fallback memeriksa data transaksi?

Ya. Fungsi ini dapat mengakses seluruh calldata yang diberikan pemanggil.

Bisakah fallback mengembalikan data?

Ya. Bentuk lanjutannya dapat langsung mengembalikan byte mentah kepada pemanggil.

Mengapa kontrak proxy menggunakan fallback?

Kontrak proxy menggunakannya untuk meneruskan panggilan pengguna ke kontrak implementasi melalui delegatecall.

Apa yang dipertahankan oleh delegatecall?

Delegatecall mempertahankan pengirim dan nilai asli sambil menjalankan kode implementasi terhadap penyimpanan dan saldo proxy.

Apakah delegatecall mengubah penyimpanan implementasi?

Tidak. Kode implementasi yang dijalankan melalui delegatecall biasanya membaca dan menulis penyimpanan proxy pemanggil.

Apa itu kontrak implementasi?

Kontrak implementasi memuat logika bisnis yang dijalankan melalui proxy yang dapat di-upgrade.

Apa itu tabrakan selector?

Tabrakan selector terjadi ketika signature fungsi yang berbeda menghasilkan selector empat byte yang sama.

Mengapa tata letak penyimpanan penting?

Tata letak penyimpanan yang tidak kompatibel dapat menyebabkan implementasi yang di-upgrade salah membaca atau menimpa data proxy yang sudah ada.

Bisakah fallback menyebabkan reentrancy?

Ya. Jika tersedia cukup gas, fallback dapat memanggil kembali kontrak lain.

Bisakah fallback menolak pembayaran?

Ya. Fallback nonpayable atau fallback yang secara eksplisit mengalami revert dapat menolak pembayaran biasa melalui message-call.

Bisakah kontrak mencegah setiap kemungkinan kenaikan saldo?

Tidak. Beberapa mekanisme EVM dapat meningkatkan saldo kontrak tanpa menjalankan logika receive atau fallback.

Apakah transfer ERC-20 memicu fallback?

Biasanya tidak, karena kontrak token memperbarui saldo tanpa memanggil kontrak penerima.

Bisakah fallback memancarkan event?

Ya, asalkan panggilan menyediakan gas yang cukup untuk operasi event tersebut.

Bisakah fallback memperbarui penyimpanan?

Ya, tetapi pembaruan penyimpanan menambah biaya dan dapat gagal jika gas yang tersedia terbatas.

Bisakah fallback menggunakan modifier?

Ya. Fallback function dapat menggunakan modifier Solidity.

Bisakah fallback diwariskan?

Ya. Fallback dapat bersifat virtual dan ditimpa oleh kontrak turunan.

Apakah panggilan tingkat rendah yang berhasil membuktikan bahwa fungsi yang diminta tersedia?

Tidak. Selector yang tidak dikenal mungkin telah diterima oleh fallback function.

Haruskah setiap smart contract memiliki fallback function?

Tidak. Kontrak hanya perlu mendefinisikannya jika membutuhkan penanganan khusus untuk panggilan yang tidak cocok.

Apakah fallback function aman dalam kontrak yang dapat di-upgrade?

Fungsi ini dapat aman jika logika penerusan, tata letak penyimpanan, implementasi, dan wewenang upgrade dirancang serta diaudit dengan benar.

Apa risiko terbesar fallback function?

Risiko terbesarnya bergantung pada tujuan fungsi, tetapi delegasi proxy, panggilan eksternal tanpa batasan, upgrade yang tidak aman, dan perilaku pembayaran yang tak terduga dapat menjadi masalah kritis.

Kesimpulan

Fallback function adalah entry point Solidity khusus untuk panggilan eksternal yang tidak cocok dengan fungsi smart contract lain yang dideklarasikan.

Fungsi ini juga dapat menangani calldata kosong jika kontrak tidak mendefinisikan receive function.

Fallback payable dapat menerima mata uang kripto native, sedangkan fallback nonpayable menolak panggilan tak cocok yang membawa nilai.

Receive function umumnya merupakan pilihan yang lebih jelas untuk menerima transfer mata uang kripto biasa yang disengaja.

Fallback function penting bagi proxy yang dapat di-upgrade karena fungsi ini dapat meneruskan panggilan ke kontrak implementasi melalui delegatecall.

Proses ini mempertahankan pengirim dan nilai asli sambil menjalankan kode implementasi terhadap penyimpanan proxy.

Pengalihan fallback berbasis proxy menimbulkan risiko tata letak penyimpanan, tabrakan selector, wewenang upgrade, dan delegatecall.

Fallback function juga dapat menimbulkan masalah reentrancy, denial-of-service, gas, decoding, dan keberhasilan panggilan yang tidak terduga.

Developer sebaiknya menjaga agar perilaku fallback tetap terbatas, menolak panggilan yang tidak didukung jika sesuai, dan menggunakan fungsi biasa bernama untuk logika aplikasi umum.

Memahami fallback function sangat penting untuk mengevaluasi smart contract mata uang kripto karena entry point tanpa nama ini dapat mengendalikan pembayaran, pengalihan proxy, perilaku akun modular, dan eksekusi seluruh aplikasi terdesentralisasi.