Optimasi Gas

Apa Itu Optimasi Gas?

Optimasi gas adalah proses mengurangi sumber daya blockchain yang diperlukan untuk men-deploy atau mengeksekusi smart contract mata uang kripto.

Di Ethereum, setiap transaksi dan operasi Ethereum Virtual Machine menggunakan jumlah gas yang terukur.

Pengirim transaksi biasanya membayar biaya jaringan berdasarkan gas yang dikenakan dan harga efektif setiap unit gas.

Perhitungan dasarnya adalah Biaya Transaksi = Gas yang Dikenakan × Harga Gas Efektif.

Optimasi gas mengurangi jumlah gas yang dikenakan dengan membuat kode kontrak, penggunaan storage, data transaksi, dan jalur eksekusi lebih efisien.

Optimasi ini tidak secara langsung mengendalikan harga gas, yang berubah sesuai permintaan kapasitas blockchain.

Kontrak yang dioptimalkan dengan baik dapat membuat transfer token, operasi keuangan terdesentralisasi, tindakan tata kelola, aktivitas NFT, dan transaksi kripto lainnya lebih terjangkau.

Namun, optimasi gas tidak boleh menghapus pemeriksaan keamanan atau membuat perilaku kontrak sulit dipahami.

Tujuannya adalah melakukan jumlah minimum pekerjaan on-chain yang aman dan dapat diverifikasi sesuai kebutuhan aplikasi.

Cara Kerja Optimasi Gas

Ethereum mengenakan jumlah gas yang berbeda untuk berbagai jenis pekerjaan komputasi dan perubahan state.

Perhitungan sederhana umumnya murah, sedangkan perubahan storage persisten, pembuatan kontrak, operasi kriptografi, dan pemanggilan eksternal dapat jauh lebih mahal.

Dokumentasi gas Ethereum resmi menjelaskan bahwa gas mengukur upaya komputasi yang diperlukan untuk memproses transaksi blockchain.

Optimasi gas dimulai dengan mengidentifikasi operasi yang paling banyak menggunakan gas dan menentukan apakah aplikasi dapat mengurangi pekerjaan tanpa mengubah perilaku yang diinginkan.

Developer dapat mengurangi pembacaan storage berulang, menggabungkan perubahan state, memperpendek data transaksi, menghapus perhitungan duplikat, atau menggunakan fitur EVM yang lebih efisien.

Compiler juga dapat mengubah kode sumber Solidity menjadi bytecode yang lebih efisien.

Beberapa optimasi mengurangi biaya deployment kontrak, sedangkan yang lain mengurangi biaya setiap interaksi pengguna.

Pendekatan yang paling sesuai bergantung pada seberapa sering kontrak akan di-deploy dan seberapa sering fungsinya akan dipanggil.

Optimasi Gas vs. Optimasi Harga Gas

Optimasi gas dan optimasi harga gas menangani bagian biaya transaksi yang berbeda.

Optimasi gas mengurangi jumlah unit gas yang digunakan transaksi.

Optimasi harga gas berupaya mengirim transaksi saat biaya setiap unit gas lebih rendah.

Kontrak yang menggunakan 100,000 gas tetap lebih mahal secara komputasi daripada kontrak yang melakukan tugas aman yang sama dengan 60,000 gas.

Namun, kontrak yang lebih murah tetap dapat menghasilkan biaya tinggi dalam mata uang nasional ketika jaringan padat atau nilai ETH tinggi.

Pengguna terkadang dapat menurunkan harga gas dengan menunggu sampai permintaan jaringan berkurang, tetapi developer mengendalikan penggunaan gas melalui desain kontrak dan aplikasi.

Menggabungkan kedua pendekatan dapat mengurangi total biaya transaksi dengan lebih efektif daripada hanya mengandalkan salah satunya.

Mengapa Optimasi Gas Penting dalam Kripto

Biaya transaksi yang tinggi dapat menghalangi pengguna berinteraksi dengan aplikasi mata uang kripto, meskipun layanan yang mendasarinya bermanfaat.

Pengurangan gas yang kecil dapat memberi dampak ekonomi signifikan ketika fungsi yang sama dijalankan ribuan atau jutaan kali.

Penggunaan gas yang lebih rendah dapat meningkatkan aksesibilitas bagi pengguna dengan saldo kripto yang lebih kecil.

Hal ini juga dapat membantu transaksi yang sensitif terhadap waktu bersaing untuk dimasukkan ke blok tanpa memerlukan total biaya yang terlalu tinggi.

Efisiensi gas sangat penting bagi strategi mata uang kripto otomatis karena biaya eksekusi dapat melebihi potensi profit dari trading atau likuidasi.

Kontrak yang efisien juga menggunakan lebih sedikit kapasitas blok yang terbatas sehingga lebih banyak transaksi dapat masuk dalam sumber daya jaringan yang tersedia.

Karena itu, optimasi dapat bermanfaat bagi pengguna individu maupun ekosistem blockchain secara luas.

Ukur Gas Sebelum Mengubah Kode

Developer sebaiknya mengukur penggunaan gas sebelum memutuskan bagian kontrak yang perlu dioptimalkan.

Kode sumber yang tampak tidak efisien mungkin sudah disederhanakan oleh compiler.

Pintasan pada tingkat kode sumber juga dapat menghasilkan bytecode yang lebih mahal daripada implementasi yang lebih jelas.

Laporan gas sebaiknya mencakup deployment kontrak, transaksi yang berhasil, transaksi yang dibatalkan, input berukuran maksimum, dan cabang eksekusi yang jarang digunakan.

Fungsi yang murah untuk satu pengguna dapat menjadi tidak terjangkau ketika memproses array besar atau banyak entri storage.

Snapshot gas otomatis dapat membandingkan biaya antarversi perangkat lunak dan mendeteksi kenaikan yang tidak diharapkan.

Execution trace dapat mengidentifikasi opcode mahal, slot storage, perluasan memory, dan pemanggilan kontrak eksternal.

Dokumentasi compiler Solidity menjelaskan output compiler, pengaturan optimasi, dan estimasi gas yang tersedia.

Developer sebaiknya memperlakukan estimasi sebagai panduan karena loop dinamis dan pemanggilan eksternal dapat membuat penggunaan gas yang tepat bergantung pada state blockchain.

Optimalkan Arsitektur Smart Contract

Penghematan gas terbesar sering berasal dari perubahan arsitektur kontrak, bukan menulis ulang ekspresi satu per satu.

Kontrak yang menyimpan informasi yang tidak diperlukan akan tetap mahal meskipun aritmetikanya sangat dioptimalkan.

Developer sebaiknya menentukan informasi yang harus ditegakkan secara on-chain dan informasi yang dapat dihitung atau diindeks di luar kontrak.

Saldo penting, izin, catatan kepemilikan, dan data kolateral biasanya memerlukan state on-chain persisten.

Informasi tampilan, aktivitas historis, dan analitik mungkin cocok dicatat dalam event log jika eksekusi kontrak di masa mendatang tidak perlu membacanya.

Developer juga sebaiknya mempertimbangkan apakah beberapa pembaruan state dapat direpresentasikan dengan satu nilai akumulasi atau indeks akuntansi.

Model state yang lebih sederhana biasanya memerlukan lebih sedikit operasi storage dan lebih mudah diaudit.

Kurangi Penulisan ke Penyimpanan Persisten

Storage persisten merupakan salah satu sumber daya termahal yang tersedia bagi smart contract Ethereum.

Data storage tetap menjadi bagian dari state Ethereum setelah transaksi selesai.

Setiap nilai storage yang baru atau diubah harus diproses dan dipertahankan oleh node jaringan.

Kontrak sebaiknya menghindari penulisan informasi yang dapat dihitung dengan aman dari state yang sudah ada.

Kontrak juga sebaiknya tidak menulis nilai jika nilai yang diminta sudah tersimpan.

Beberapa pembaruan perantara terkadang dapat diganti dengan satu penulisan storage final setelah semua perhitungan selesai.

Developer sebaiknya tidak menyimpan salinan duplikat data yang sama kecuali duplikasi tersebut memberikan manfaat keamanan atau kinerja yang diperlukan.

Mengurangi penulisan storage sering kali menghasilkan penghematan lebih besar daripada perubahan aritmetika kecil.

Cache Pembacaan Storage Berulang

Memuat nilai yang sama dari storage berulang kali dapat membuang gas jika nilainya tidak berubah selama eksekusi.

Kontrak sering kali dapat memuat nilai tersebut sekali ke variabel lokal dan menggunakannya kembali dalam perhitungan berikutnya.

Ethereum menerapkan biaya berbeda untuk akses state cold dan warm berdasarkan EIP-2929.

Akses pertama ke akun atau slot storage selama transaksi umumnya lebih mahal daripada akses berikutnya ke lokasi yang sama.

Namun, pembacaan storage warm sekalipun dapat lebih mahal daripada menggunakan nilai stack atau memory yang sudah tersedia.

Hindari caching jika pemanggilan eksternal dapat mengubah state kontrak terkait sebelum nilai yang di-cache digunakan.

Perilaku reentrancy dan callback harus ditinjau setiap kali state di-cache melintasi interaksi eksternal.

Kemas Variabel State

Storage Ethereum dibagi menjadi slot selebar 32 byte.

Solidity dapat menempatkan beberapa variabel bertipe nilai kecil dalam slot yang sama jika ukuran dan urutannya memungkinkan.

Dokumentasi tata letak storage Solidity resmi menjelaskan cara penetapan variabel ke slot storage.

Pengurutan variabel yang cermat dapat mengurangi jumlah slot yang diperlukan kontrak.

Misalnya, beberapa integer kecil atau nilai Boolean dapat dimuat dalam satu slot, bukan menempati slot terpisah.

Penggunaan integer yang lebih kecil tidak otomatis mengurangi gas runtime karena EVM biasanya melakukan operasi aritmetika dengan word 256-bit.

Pengemasan paling bermanfaat ketika beberapa nilai yang dikemas sering dibaca atau ditulis bersama.

Memperbarui hanya satu kolom dalam slot yang dikemas dapat memerlukan operasi masking dan penggabungan tambahan.

Developer tidak boleh mengubah urutan variabel storage yang sudah ada dalam kontrak yang dapat di-upgrade karena dapat merusak data yang telah tersimpan.

Gunakan Variabel Constant dan Immutable

Nilai yang tidak pernah berubah sebaiknya tidak disimpan sebagai variabel state biasa yang dapat diubah.

Solidity memungkinkan nilai waktu kompilasi dinyatakan dengan kata kunci

.

Nilai yang dipilih saat konstruksi kontrak dan kemudian tetap dapat menggunakan kata kunci

.

Konstanta dan immutable menghindari pembacaan storage biasa karena nilainya disematkan dalam atau dirujuk melalui bytecode kontrak.

Dokumentasi Solidity untuk variabel constant dan immutable menjelaskan perbedaan deklarasi tersebut.

Contoh umum mencakup alamat permanen, batas tetap, nilai matematika, dan konfigurasi yang tidak dapat diubah setelah deployment.

Variabel sebaiknya tetap dapat diubah jika aplikasi memang memerlukan tata kelola atau administrasi berwenang untuk memperbaruinya.

Pilih Lokasi Data yang Tepat

Data Solidity dapat berada di storage, memory, calldata, atau transient storage, bergantung pada cara penggunaannya.

Storage bertahan di antara transaksi dan umumnya merupakan lokasi yang paling mahal.

Memory bersifat sementara dan hanya tersedia selama eksekusi saat ini.

Calldata berisi input eksternal hanya-baca yang disertakan bersama transaksi atau pemanggilan kontrak.

Transient storage bertahan selama pemanggilan dalam satu transaksi, tetapi otomatis dihapus ketika transaksi berakhir.

Memilih lokasi data yang lebih mahal daripada yang diperlukan meningkatkan biaya transaksi tanpa menambah fungsi.

Dokumentasi lokasi data Solidity menjelaskan pengaruh lokasi ini terhadap penyalinan, kemampuan perubahan, dan masa berlaku data.

Gunakan Calldata untuk Input Eksternal Hanya-Baca

Parameter fungsi eksternal yang tidak perlu diubah sering kali dapat tetap berada di calldata.

Penggunaan calldata dapat menghindari penyalinan array besar, string, urutan byte, atau struct ke memory.

Hal ini dapat mengurangi gas ketika fungsi hanya perlu memeriksa nilai yang dikirimkan.

Memory tetap sesuai ketika kontrak perlu mengubah input atau membuat nilai baru di dalam memory.

Developer juga sebaiknya meminimalkan data transaksi yang tidak diperlukan karena setiap byte calldata menambah biaya gas intrinsik.

Nilai berulang terkadang dapat diganti dengan ID ringkas jika kontrak telah menyimpan konfigurasi lengkapnya.

Kompresi harus diukur dengan cermat karena komputasi untuk mengurai data dapat melebihi penghematan yang diperoleh.

Perhitungkan Penetapan Harga Calldata Saat Ini

Upgrade Ethereum Pectra diaktifkan pada 7 Mei 2025 dan mencakup perubahan yang memengaruhi biaya transaksi padat data.

EIP-7623 menetapkan batas bawah gas lebih tinggi untuk transaksi yang membawa banyak calldata tetapi hanya melakukan sedikit eksekusi EVM.

Aturan ini dirancang untuk membatasi ukuran maksimum blok padat data dan meningkatkan ketahanan jaringan.

Developer sebaiknya tidak berasumsi bahwa transaksi dengan komputasi minimal selalu murah jika memuat payload calldata besar.

Aplikasi yang mengirim proof, tanda tangan, batch, atau informasi transaksi terkompresi sebaiknya menguji kinerja berdasarkan perilaku protokol saat ini.

Upgrade jaringan baru dapat mengubah biaya relatif calldata, komputasi, storage, dan sumber daya lainnya.

Gunakan Transient Storage Ketika State Bersifat Sementara

Transient storage dirancang untuk informasi yang harus tetap tersedia selama satu transaksi, tetapi tidak perlu bertahan setelahnya.

Ethereum memperkenalkan opcode

dan melalui EIP-1153.

Nilai transient otomatis dihapus pada akhir transaksi.

Hal ini membuat transient storage lebih murah daripada storage persisten karena data tidak perlu disimpan secara permanen.

Salah satu contoh penggunaan umum adalah kunci reentrancy yang digunakan bersama di beberapa pemanggilan internal atau eksternal dalam satu transaksi.

Transient storage juga dapat mendukung akuntansi sementara, callback, dan izin yang hanya berlaku selama transaksi.

Transient storage tidak dapat menggantikan storage untuk saldo atau informasi yang harus tersedia dalam transaksi berikutnya.

Developer harus memahami perilakunya dalam pemanggilan biasa dan delegate call sebelum menggunakannya pada aplikasi kripto yang dapat dikomposisikan.

Gunakan Optimizer Solidity

Optimizer Solidity dapat menyederhanakan ekspresi, menghapus operasi yang tidak perlu, menggabungkan perhitungan, dan mengurangi ukuran bytecode.

Dokumentasi optimizer Solidity resmi menjelaskan beberapa tahap optimasi yang diterapkan pada kode hasil kompilasi.

Optimizer dapat mengurangi gas deployment, gas runtime, atau keduanya.

Pengaturan runs menunjukkan perkiraan seberapa sering kode yang di-deploy akan dieksekusi.

Nilai runs yang lebih rendah umumnya mengutamakan bytecode deployment yang lebih kecil.

Nilai runs yang lebih tinggi umumnya memungkinkan deployment yang lebih besar dengan imbalan biaya eksekusi berulang yang lebih rendah.

Tidak ada pengaturan runs yang ideal untuk semua smart contract.

Developer sebaiknya membandingkan konfigurasi sesuai perkiraan deployment dan penggunaan kontrak yang sebenarnya.

Pipeline kompilasi berbasis IR dapat menghasilkan hasil berbeda dari pipeline lama dan perlu dievaluasi melalui pengujian menyeluruh.

Gunakan Compiler Terkini dan Terverifikasi

Rilis compiler Solidity dapat mencakup peningkatan gas, dukungan EVM baru, perbaikan bug, dan koreksi keamanan.

Developer sebaiknya meninjau situs resmi Solidity sebelum memilih compiler untuk deployment produksi.

Dokumentasi Solidity umumnya menyarankan penggunaan compiler rilis terkini, kecuali proyek memiliki alasan kompatibilitas khusus untuk tidak menggunakannya.

Developer juga sebaiknya meninjau daftar resmi bug compiler Solidity yang diketahui.

Versi compiler dan pengaturan optimasi sebaiknya ditetapkan dalam proses build.

Mengompilasi ulang kode sumber yang sama dengan compiler berbeda dapat menghasilkan bytecode dan perilaku gas yang berbeda.

Gunakan Custom Error

Custom error umumnya lebih hemat gas daripada string revert panjang.

String revert meningkatkan bytecode deployment dan menghasilkan teks terenkode ketika transaksi gagal.

Custom error menggunakan selector ringkas dan dapat menyertakan parameter terstruktur.

Dokumentasi custom error Solidity menjelaskan cara kontrak mendefinisikan dan mengembalikan custom error.

Error tetap harus menyampaikan informasi yang cukup agar wallet, pengguna, dan developer dapat memahami kegagalannya.

Menghapus informasi kegagalan yang berguna demi menghemat sedikit gas dapat membuat aplikasi lebih sulit didukung dan diaudit.

Optimalkan Loop

Loop dapat menjadi sangat mahal dan berbahaya jika jumlah iterasinya bergantung pada koleksi yang dapat terus bertambah tanpa batas ketat.

Loop tanpa batas pada akhirnya dapat membutuhkan gas melebihi kapasitas satu transaksi.

Jika memungkinkan, beban kerja besar sebaiknya dibagi menjadi batch yang dapat diprediksi.

Loop dapat menyimpan panjang array atau nilai yang sering digunakan jika informasi yang di-cache tidak dapat berubah selama eksekusi.

Developer terkadang dapat menggunakan aritmetika unchecked untuk penghitung loop jika overflow secara matematis mustahil.

Kode unchecked harus disertai pengujian dan penjelasan keamanan yang jelas.

Compiler modern sudah mengoptimalkan banyak pola loop umum, sehingga perubahan manual sebaiknya diukur, bukan dianggap otomatis lebih murah.

Kurangi Pemanggilan Kontrak Eksternal

Pemanggilan kontrak eksternal menimbulkan biaya gas untuk akses akun, pengodean argumen, pemrosesan data hasil, dan eksekusi kontrak yang dipanggil.

Kontrak sebaiknya tidak memanggil fungsi eksternal yang sama berulang kali jika satu pemanggilan yang aman dapat memberikan nilai yang diperlukan.

Beberapa tindakan terkait terkadang dapat digabungkan dalam satu pemanggilan atau transaksi.

Namun, batching dapat menambah calldata, kompleksitas eksekusi, dan jumlah pekerjaan yang dibatalkan jika satu langkah gagal.

Pemanggilan eksternal juga menimbulkan pertimbangan keamanan terkait reentrancy, data hasil yang berbahaya, penggunaan gas, dan kegagalan yang tidak terduga.

Optimasi gas tidak boleh menghapus pemeriksaan nilai hasil atau pola interaksi yang aman.

Gunakan Event, Bukan Storage, Jika Sesuai

Event dapat mencatat aktivitas blockchain untuk wallet, antarmuka, sistem analitik, dan indexer off-chain.

Event sering kali lebih murah daripada menyimpan informasi yang sama sebagai state kontrak persisten.

Event sesuai jika eksekusi smart contract di masa mendatang tidak perlu membaca atau menegakkan informasi tersebut.

Riwayat transaksi, notifikasi aktivitas, dan metadata deskriptif dapat dicatat dalam log.

Saldo, izin, utang, kolateral, dan kepemilikan tidak boleh hanya disimpan dalam event karena eksekusi EVM biasa tidak dapat mencari log historis.

Kontrak harus menyimpan state yang dapat diakses untuk setiap informasi yang diperlukan dalam pengambilan keputusan di masa mendatang.

Kurangi Biaya Deployment Kontrak

Deployment kontrak menggunakan gas untuk logika inisialisasi dan penyimpanan bytecode runtime.

Fungsi yang tidak digunakan, kode duplikat, data yang disematkan, dan pesan error panjang dapat meningkatkan biaya deployment.

Developer sebaiknya menghapus kode yang tidak dapat dijangkau dan menghindari impor library besar jika hanya sebagian kecil yang diperlukan.

Library dapat mengurangi bytecode duplikat di beberapa kontrak, meskipun pemanggilan library eksternal menimbulkan biaya runtime dan dependensinya sendiri.

Pola factory dan clone dapat mengurangi biaya deployment jika banyak instance kontrak serupa diperlukan.

Pola proxy juga dapat berbagi kode implementasi, tetapi menimbulkan overhead delegate call, izin upgrade, dan risiko tata letak storage.

Arsitektur sebaiknya dipilih berdasarkan kebutuhan keamanan dan siklus hidup, bukan hanya biaya gas deployment.

Targetkan Versi EVM yang Tepat

Compiler Solidity dapat menghasilkan bytecode berbeda, bergantung pada versi EVM yang dipilih.

Versi EVM yang lebih baru mungkin mendukung instruksi lebih efisien yang tidak dapat dijalankan jaringan lama.

Contohnya, EIP-3855 memperkenalkan instruksi ringkas

untuk menempatkan nilai nol di stack.

EIP-5656 memperkenalkan

untuk penyalinan memory yang lebih efisien.

Compiler saat ini dapat menggunakan instruksi yang didukung secara otomatis jika dikonfigurasi untuk jaringan yang tepat.

Kontrak yang dikompilasi untuk EVM lebih baru dapat gagal di jaringan yang belum mengaktifkan upgrade terkait.

Karena itu, developer harus memilih target EVM yang kompatibel dengan chain tujuan deployment.

Pahami Pengembalian Gas

Pengembalian gas dapat mengurangi gas final yang dikenakan setelah operasi storage tertentu yang memenuhi syarat.

Aturan Ethereum saat ini membatasi pengembalian di tingkat protokol hingga 20% dari penggunaan gas bruto.

EIP-3529 mengurangi pengembalian untuk penghapusan storage yang memenuhi syarat dan menghapus pengembalian sebelumnya untuk

.

Penghapusan storage masih dapat memberikan manfaat terbatas, tetapi tidak membuat pembuatan dan penghapusan state menjadi gratis.

Developer sebaiknya tidak menulis data yang tidak perlu hanya untuk menghapusnya nanti demi memperoleh pengembalian.

Pengembalian juga diterapkan setelah eksekusi sehingga tidak dapat mencegah kegagalan kehabisan gas.

bukan metode optimasi gas modern dan perilakunya dibatasi berdasarkan EIP-6780.

Pertimbangkan Batching dengan Cermat

Menggabungkan beberapa tindakan dalam satu transaksi dapat menghindari pembayaran overhead transaksi berulang.

Batching juga dapat meningkatkan pengalaman pengguna dengan mengurangi jumlah konfirmasi wallet.

Namun, setiap tindakan tetap menggunakan gas untuk komputasi dan perubahan state yang diperlukan.

Batch besar dapat mendekati batas gas transaksi atau menimbulkan kegagalan all-or-nothing yang mahal.

Aplikasi sebaiknya menetapkan apakah sub-tindakan yang gagal akan membatalkan seluruh batch atau memungkinkan penyelesaian sebagian.

Otorisasi harus dirancang dengan cermat karena tanda tangan batch yang cakupannya luas dapat mengizinkan aktivitas melebihi yang diperkirakan pengguna.

EIP-7702 dari Pectra memungkinkan akun milik eksternal mendelegasikan eksekusi ke kode smart contract dan mendukung fitur wallet seperti batching serta sponsor gas.

Logika akun yang didelegasikan harus ditinjau secermat kontrak lain yang mengendalikan mata uang kripto.

Gunakan Jaringan Layer 2 untuk Penghematan Tambahan

Optimasi smart contract mengurangi jumlah komputasi yang diperlukan aplikasi.

Deployment di jaringan Layer 2 yang sesuai dapat lebih lanjut mengurangi harga yang dibayarkan untuk komputasi dan data terkait.

Rollup memproses transaksi di luar Ethereum mainnet dan memublikasikan data atau proof kembali ke Ethereum.

Upgrade Dencun memperkenalkan blob melalui EIP-4844, yang memberikan pasar data sementara terpisah bagi rollup.

Biaya Layer 2 yang lebih rendah tidak menghilangkan kebutuhan optimasi gas karena kontrak yang tidak efisien tetap membuang kapasitas dan lebih mahal daripada kontrak efisien di jaringan yang sama.

Developer juga harus mengevaluasi keamanan bridge, aturan penarikan, likuiditas, finalitas, dan perhitungan biaya khusus jaringan.

Hindari Optimasi Tingkat Rendah Terlalu Dini

Developer sebaiknya tidak memulai dengan inline assembly atau manipulasi bit kompleks sebelum mengukur kode Solidity biasa.

Compiler mungkin sudah menghasilkan bytecode efisien dari implementasi tingkat tinggi yang jelas.

Assembly terkadang dapat mengurangi gas untuk operasi khusus, tetapi melewati beberapa perlindungan tingkat bahasa.

Kesalahan dalam assembly dapat menyebabkan kerusakan memory, pengodean yang salah, pemanggilan tidak aman, atau hilangnya dana pengguna.

Optimasi tingkat rendah sebaiknya memiliki implementasi acuan yang mudah dibaca dan pengujian yang membuktikan perilaku setara.

Peninjauan keamanan independen sangat penting, terutama jika assembly menangani saldo, tanda tangan, izin, atau pemanggilan eksternal.

Jangan Korbankan Keamanan demi Gas

Kontrak termurah tidak berguna jika penyerang dapat mencuri mata uang kriptonya.

Kontrol akses, validasi input, perlindungan reentrancy, pemeriksaan slippage, tenggat waktu, dan pemeriksaan akuntansi tidak boleh dihapus hanya untuk mengurangi penggunaan gas.

Aritmetika unchecked hanya boleh digunakan jika overflow dan underflow mustahil terjadi dalam setiap kondisi yang dapat dicapai.

Storage terkompresi dapat menghemat gas, tetapi meningkatkan kemungkinan kesalahan pada tingkat bit.

Proxy dapat mengurangi biaya deployment, tetapi menimbulkan kendali upgrade terpusat atau risiko benturan storage.

Tanda tangan off-chain dapat menghilangkan transaksi, tetapi menambah persyaratan nonce, kedaluwarsa, replay, dan pemisahan domain.

Keputusan optimasi sebaiknya ditinjau dari sisi keamanan, keterbacaan, kemampuan upgrade, dan risiko operasional.

Pengujian Optimasi Gas

Setiap optimasi harus diuji terhadap implementasi aslinya.

Pengujian fungsional harus memastikan kedua versi menghasilkan perubahan state dan output yang sama.

Pengujian gas sebaiknya mengukur penggunaan rata-rata, penggunaan maksimum yang didukung, dan kondisi kegagalan.

Fuzz testing dapat mengeksplorasi input yang tidak biasa dan mengungkap jalur eksekusi yang mahal atau salah.

Invariant testing dapat memastikan properti penting akuntansi dan keamanan tetap berlaku setelah optimasi.

Developer juga sebaiknya menguji dengan versi compiler, pengaturan optimizer, dan target EVM yang persis akan digunakan untuk produksi.

Snapshot gas sebaiknya disimpan agar pengembangan berikutnya tidak diam-diam membatalkan peningkatan yang dicapai.

Kesalahan Umum dalam Optimasi Gas

Kesalahan umum adalah menganggap setiap tipe integer yang lebih kecil mengurangi gas.

Kesalahan lainnya adalah menyalin data eksternal hanya-baca dari calldata ke memory tanpa kebutuhan fungsional.

Developer juga dapat membuat loop tanpa batas pada koleksi storage yang menjadi tidak mungkin dieksekusi seiring aplikasi berkembang.

Beberapa tim mengoptimalkan fungsi yang jarang digunakan sambil mengabaikan biaya kecil yang berulang dalam setiap transaksi pengguna.

Tim lain memilih pengaturan optimizer tanpa menguji kompromi antara deployment dan runtime.

Assembly yang ditulis manual mungkin ditambahkan sebelum operasi yang benar-benar mahal diidentifikasi.

Developer juga dapat mengandalkan jadwal gas yang sudah usang setelah upgrade Ethereum mengubah biaya suatu operasi.

Kesalahan paling berbahaya adalah menghapus pemeriksaan keamanan yang diperlukan demi menghasilkan tolok ukur gas yang tampak mengesankan.

Cara Menyusun Strategi Optimasi Gas

Strategi optimasi gas sebaiknya dimulai dengan perilaku kontrak dan persyaratan keamanan yang didefinisikan secara jelas.

Tim pengembangan sebaiknya membuat pengujian lengkap sebelum mengubah implementasi.

Selanjutnya, tim perlu mengukur biaya deployment dan transaksi dalam kondisi realistis.

Operasi storage, loop, payload calldata, dan pemanggilan eksternal yang paling mahal harus diprioritaskan.

Penyederhanaan arsitektur sebaiknya dipertimbangkan sebelum penulisan ulang kode tingkat rendah.

Pengaturan compiler dan target versi EVM harus diuji serta dicatat.

Setiap optimasi harus menjalani tinjauan fungsional, gas, dan keamanan.

Deployment final sebaiknya menggunakan bytecode yang dapat direproduksi, dibangun dari tool dan dependensi dengan versi yang ditetapkan.

FAQ

Apa itu optimasi gas secara sederhana?

Optimasi gas berarti mengurangi komputasi blockchain, storage, dan data transaksi yang diperlukan untuk mengeksekusi smart contract dengan aman.

Apakah optimasi gas mengurangi harga gas?

Tidak, optimasi mengurangi penggunaan gas, sedangkan harga gas ditentukan oleh permintaan jaringan dan pengaturan biaya transaksi.

Apa optimasi gas yang paling efektif?

Mengurangi operasi storage persisten yang tidak perlu dan menyederhanakan arsitektur kontrak biasanya memberikan penghematan terbesar.

Apakah storage lebih mahal daripada memory?

Ya, storage persisten umumnya lebih mahal karena tetap menjadi bagian dari state blockchain setelah transaksi berakhir.

Apakah calldata lebih murah daripada memory?

Calldata dapat lebih murah untuk input eksternal hanya-baca karena seluruh nilai tidak perlu disalin ke memory.

Apakah tipe integer kecil selalu menghemat gas?

Tidak, tipe tersebut biasanya memberikan penghematan storage yang berarti hanya jika beberapa nilai dapat dikemas dalam satu slot storage.

Apa itu transient storage?

Transient storage adalah storage EVM yang hanya berlaku selama transaksi dan dihapus secara otomatis sehingga dapat mengurangi biaya state kontrak sementara.

Apakah optimizer Solidity selalu mengurangi biaya?

Tidak, konfigurasi optimizer dapat mengurangi gas runtime sekaligus meningkatkan biaya deployment, sehingga setiap konfigurasi perlu diukur.

Apa arti optimizer runs?

Pengaturan runs memengaruhi kompromi compiler antara bytecode deployment yang lebih kecil dan biaya eksekusi berulang yang lebih rendah.

Apakah custom error lebih murah daripada string revert?

Custom error umumnya lebih efisien karena menggunakan selector ringkas dan parameter terenkode, bukan string teks panjang.

Bisakah event menggantikan storage?

Event hanya dapat menggantikan storage jika informasi tersebut tidak perlu dibaca atau ditegakkan oleh eksekusi smart contract di masa mendatang.

Apakah penghapusan storage menghasilkan pengembalian gas?

Penghapusan storage yang memenuhi syarat dapat menghasilkan pengembalian terbatas, tetapi pengembaliannya dibatasi dan tidak memulihkan seluruh biaya storage semula.

Bisakah pengembalian gas mencegah kegagalan kehabisan gas?

Tidak, pengembalian gas dihitung setelah eksekusi dan tidak dapat menyediakan gas tambahan saat transaksi sedang berjalan.

Apakah batching selalu menghemat gas?

Tidak, batching dapat mengurangi overhead transaksi berulang, tetapi mungkin menambah calldata, kompleksitas, dan risiko kegagalan.

Haruskah developer menggunakan inline assembly untuk optimasi?

Inline assembly hanya boleh digunakan untuk bottleneck yang telah diukur karena dapat menimbulkan risiko serius terhadap keamanan dan pemeliharaan.

Bisakah jaringan Layer 2 menggantikan optimasi gas?

Tidak, jaringan Layer 2 dapat menurunkan biaya, tetapi kontrak yang tidak efisien tetap menggunakan lebih banyak sumber daya daripada kontrak teroptimasi di jaringan yang sama.

Mengapa biaya gas dapat berubah dari waktu ke waktu?

Upgrade Ethereum dapat memperkenalkan opcode baru, mengubah biaya operasi yang ada, mengubah aturan calldata, atau memperluas kapasitas jaringan.

Bagaimana developer dapat mengukur penggunaan gas?

Developer dapat menggunakan laporan gas, receipt transaksi, execution trace, output compiler, snapshot otomatis, dan pengujian realistis.

Apakah implementasi dengan gas terendah selalu yang terbaik?

Tidak, keamanan, kebenaran, keterbacaan, dan kemudahan pemeliharaan kontrak lebih penting daripada penghematan gas kecil.

Bisakah pengguna mengoptimalkan gas tanpa mengubah kontrak?

Pengguna dapat memilih periode dengan permintaan lebih rendah atau jaringan yang sesuai, tetapi hanya developer kontrak yang dapat mengubah efisiensi eksekusi mendasar aplikasi.

Kesimpulan

Optimasi gas adalah proses rekayasa untuk mengurangi sumber daya yang digunakan smart contract dan transaksi mata uang kripto.

Optimasi ini menurunkan penggunaan gas, bukan secara langsung mengubah harga pasar setiap unit gas.

Optimasi paling efektif biasanya berasal dari arsitektur yang lebih sederhana, lebih sedikit operasi storage, lokasi data yang efisien, loop berbatas, dan pemanggilan eksternal yang lebih sedikit.

Optimasi compiler, konstanta, nilai immutable, custom error, pengemasan variabel, transient storage, dan batching yang sesuai dapat memberikan penghematan tambahan.

Developer sebaiknya menggunakan compiler terkini, meninjau bug compiler yang diketahui, dan menargetkan versi EVM yang tepat.

Setiap optimasi harus diuji pada transaksi yang berhasil, kegagalan, input besar, dan jalur eksekusi yang tidak biasa.

Kontrol keamanan tidak boleh dihapus hanya untuk mengurangi laporan gas.

Kontrak yang dioptimalkan dengan baik hanya melakukan pekerjaan on-chain yang diperlukan untuk menyediakan fungsi mata uang kripto yang aman, transparan, dan andal.