Teknik Optimasi Gas

Apa Itu Teknik Optimasi Gas?

Teknik optimasi gas adalah metode untuk mengurangi sumber daya komputasi dan penyimpanan blockchain yang diperlukan oleh transaksi mata uang kripto atau smart contract.

Di Ethereum dan jaringan lain yang kompatibel dengan EVM, setiap operasi yang dilakukan Ethereum Virtual Machine memiliki biaya gas.

Membaca penyimpanan kontrak, mengubah state blockchain, menyalin data, memanggil kontrak lain, menerbitkan event, dan men-deploy bytecode dapat menggunakan gas.

Pengguna yang mengirim transaksi biasanya membayar biaya berdasarkan gas yang dikenakan dan harga gas efektif transaksi tersebut.

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

Optimasi gas mengurangi bagian gas yang dikenakan dalam rumus tersebut.

Optimasi ini tidak secara langsung mengendalikan harga pasar setiap unit gas, yang berubah mengikuti permintaan ruang blok.

Kontrak yang dioptimalkan dengan baik dapat menurunkan biaya pengguna, memungkinkan lebih banyak aktivitas masuk ke setiap blok, meningkatkan keandalan transaksi, dan membuat aplikasi terdesentralisasi lebih praktis saat permintaan jaringan tinggi.

Namun, optimasi gas tidak boleh melemahkan kontrol akses, keamanan aritmetika, perlindungan reentrancy, akurasi akuntansi, atau aspek keamanan lainnya.

Optimasi terbaik biasanya berupa desain lebih sederhana yang melakukan lebih sedikit pekerjaan, bukan kode rumit yang hanya dibuat untuk menghemat sedikit unit gas.

Mengapa Optimasi Gas Penting dalam Kripto

Setiap operasi on-chain yang tidak diperlukan menimbulkan biaya bagi orang atau aplikasi yang mengirim transaksi.

Perbedaan kecil mungkin tampak tidak penting untuk satu transaksi, tetapi dapat menjadi signifikan ketika smart contract memproses ribuan atau jutaan interaksi.

Penggunaan gas yang lebih rendah dapat membuat transfer token, operasi keuangan terdesentralisasi, aktivitas NFT, voting tata kelola, dan game blockchain lebih terjangkau.

Kontrak yang efisien juga dapat lebih mudah diproses validator dan node karena memerlukan lebih sedikit pembacaan dan penulisan penyimpanan serta langkah komputasi.

Optimasi gas sangat penting bagi aplikasi yang menjalankan loop berulang, memperbarui banyak saldo, membuat kontrak baru, atau memanggil beberapa sistem eksternal dalam satu transaksi.

Optimasi ini juga penting bagi strategi mata uang kripto otomatis karena biaya eksekusi yang tinggi dapat menghapus potensi profit dari trading atau likuidasi.

Optimasi gas tidak menjamin transaksi akan murah dalam mata uang nasional karena harga gas dan harga pasar mata uang kripto native tetap dapat naik.

Optimasi mengurangi jumlah pekerjaan jaringan yang harus dibayar pengguna.

Pahami Penggunaan Gas

Developer harus memahami sumber utama penggunaan gas sebelum mengubah kode smart contract.

Penyimpanan persisten biasanya menjadi salah satu sumber daya paling mahal karena data yang dihasilkan harus tetap menjadi bagian dari state blockchain.

Memory adalah data sementara yang digunakan selama satu eksekusi dan umumnya lebih murah daripada penyimpanan persisten, meskipun biayanya meningkat seiring bertambahnya area memori yang dialokasikan.

Calldata berisi input transaksi atau fungsi eksternal dan tidak menjadi memori kontrak yang dapat diubah kecuali disalin.

Deployment kontrak menggunakan gas untuk menjalankan kode inisialisasi dan menyimpan bytecode runtime yang dihasilkan.

Pemanggilan kontrak eksternal menimbulkan biaya tambahan untuk akses akun, pengodean argumen, penanganan data hasil, dan pekerjaan yang dilakukan kontrak yang dipanggil.

Perhitungan kriptografi, event log, pembuatan kontrak, dan loop besar juga dapat berkontribusi secara signifikan terhadap total penggunaan gas.

Dokumentasi gas Ethereum resmi menjelaskan bagaimana gas mengukur upaya komputasi yang diperlukan oleh transaksi dan operasi EVM.

Ukur Gas Sebelum Melakukan Optimasi

Optimasi gas sebaiknya dimulai dengan pengukuran, bukan asumsi.

Developer sebaiknya mencatat biaya deployment dan biaya runtime fungsi-fungsi penting sebelum mengubah kode.

Pengujian harus mencakup ukuran transaksi yang realistis, perilaku pengguna normal, input maksimum yang didukung, jalur kegagalan, dan kondisi blockchain yang tidak umum.

Fungsi yang murah dengan satu elemen array dapat menjadi tidak aman atau terlalu mahal dengan seribu elemen.

Snapshot gas dapat membandingkan biaya fungsi antarversi kode dan mendeteksi kenaikan yang tidak disengaja.

Execution trace dapat menunjukkan opcode, slot penyimpanan, pemanggilan internal, dan pemanggilan eksternal yang paling banyak menggunakan gas.

Compiler Solidity dapat menghasilkan estimasi gas, sebagaimana dijelaskan dalam dokumentasi compiler, tetapi beberapa estimasi tidak tersedia atau kurang andal jika eksekusi bergantung pada loop dinamis atau perilaku kontrak eksternal.

Pengujian di blockchain lokal atau testnet publik yang dikelola dapat memberikan pengukuran yang lebih realistis.

Developer sebaiknya mengoptimalkan jalur mahal yang benar-benar digunakan pengguna, bukan menghabiskan waktu untuk kode yang jarang dipanggil.

Gunakan Compiler Solidity Terkini

Rilis compiler Solidity yang lebih baru sering mencakup peningkatan pembuatan kode, perbaikan optimasi, dukungan instruksi EVM baru, dan perbaikan keamanan.

Situs resmi Solidity mencantumkan versi 0.8.36 sebagai compiler terbaru yang dirilis pada Juli 2026.

Developer sebaiknya memeriksa situs resmi Solidity dan daftar bug compiler yang diketahui sebelum memilih compiler untuk produksi.

Versi yang dipilih sebaiknya ditetapkan secara tetap dalam konfigurasi build agar setiap developer, sistem pengujian, dan pipeline deployment menghasilkan bytecode yang konsisten.

Menggunakan pragma yang luas tanpa mengendalikan lingkungan build aktual dapat menyebabkan rilis compiler berbeda menghasilkan kode yang berbeda.

Compiler yang lebih baru tetap perlu diuji secara menyeluruh karena optimasi dan perubahan bahasa dapat memengaruhi bytecode, biaya deployment, dan perilaku kontrak.

Aktifkan dan Konfigurasikan Optimizer Solidity

Optimizer Solidity menyederhanakan ekspresi, menghapus operasi yang tidak diperlukan, menggabungkan perhitungan berulang, serta dapat mengurangi bytecode deployment dan penggunaan gas runtime.

Dokumentasi optimizer Solidity menjelaskan bahwa optimasi dapat mengurangi ukuran kode dan biaya eksekusi.

Pengaturan runs pada optimizer menunjukkan seberapa sering developer memperkirakan kode yang di-deploy akan dijalankan.

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

Nilai runs yang lebih tinggi umumnya memungkinkan compiler membuat kode yang mungkin lebih besar saat deployment, tetapi lebih murah dalam pemanggilan runtime berulang.

Tidak ada nilai runs universal yang terbaik untuk setiap kontrak mata uang kripto.

Kontrak yang sering di-deploy tetapi jarang dipanggil mungkin memerlukan pengaturan berbeda dari satu kontrak yang diperkirakan memproses jutaan transaksi.

Developer sebaiknya membandingkan beberapa konfigurasi menggunakan pengujian nyata dan mengevaluasi total biaya sepanjang siklus hidup, bukan hanya biaya deployment atau runtime.

Pipeline kompilasi via-IR dapat menghasilkan optimasi yang berbeda dari pipeline lama, tetapi perubahan pipeline harus diperlakukan sebagai perubahan build yang signifikan dan diuji sepenuhnya.

Kurangi Penulisan ke Penyimpanan Persisten

Penulisan ke penyimpanan persisten sering kali menjadi peluang terbesar untuk menghemat gas.

Kontrak sebaiknya tidak menyimpan informasi yang dapat dihitung dengan aman dari state yang sudah ada atau diberikan pengguna saat diperlukan.

Penulisan nilai yang sama berulang kali sebaiknya dihindari jika kontrak dapat memastikan terlebih dahulu bahwa tidak ada perubahan yang diperlukan.

Kontrak yang memperbarui lima variabel state terpisah mungkin lebih mahal daripada kontrak dengan model akuntansi lebih sederhana yang memerlukan lebih sedikit penulisan.

Developer juga sebaiknya mempertimbangkan apakah informasi perlu tersedia bagi smart contract lain atau hanya bagi aplikasi off-chain.

Data yang harus memengaruhi eksekusi kontrak di masa mendatang umumnya perlu disimpan dalam storage.

Informasi yang hanya diperlukan wallet, antarmuka, atau analitik terkadang dapat dicatat dalam event.

Menghapus storage dapat menghasilkan pengembalian gas terbatas berdasarkan aturan Ethereum saat ini, tetapi pengembalian yang diterapkan dibatasi dan tidak boleh dianggap membuat storage gratis.

Kontrak sebaiknya menghapus state usang demi desain yang baik, bukan membuat data yang tidak perlu dengan harapan memperoleh pengembalian di kemudian hari.

Cache Pembacaan Storage Berulang

Membaca slot storage berulang kali lebih mahal daripada membacanya sekali lalu menggunakan kembali nilai lokal jika state yang mendasarinya tidak perlu berubah di antara pembacaan.

Ethereum membedakan akses state cold dan warm berdasarkan EIP-2929.

Akses pertama ke slot storage yang belum disentuh dalam transaksi bersifat cold dan dikenai biaya lebih tinggi.

Akses berikutnya ke slot yang sama dalam transaksi tersebut bersifat warm dan biayanya lebih rendah.

Bahkan pembacaan storage warm dapat lebih mahal daripada menggunakan nilai stack atau memory yang sudah tersedia bagi fungsi.

Fungsi sering kali dapat menyalin variabel state yang sering digunakan ke variabel lokal, melakukan perhitungan, lalu menulis hasil akhirnya satu kali.

Metode ini tidak boleh digunakan jika pemanggilan eksternal dapat mengubah state terkait atau jika nilai yang di-cache akan menjadi usang.

Developer sebaiknya mengikuti prinsip checks-effects-interactions dan menganalisis reentrancy dengan cermat sebelum melakukan caching state di sekitar pemanggilan eksternal.

Kemas Variabel State dengan Cermat

Penyimpanan Ethereum diatur dalam slot berukuran 32 byte.

Beberapa variabel bertipe nilai kecil dapat berbagi satu slot jika urutan dan ukuran totalnya memungkinkan pengemasan.

Misalnya, beberapa nilai integer atau Boolean yang lebih kecil dapat menempati satu slot, bukan beberapa slot terpisah.

Dokumentasi tata letak storage Solidity menjelaskan bagaimana variabel, struct, array, pewarisan, dan pengemasan memengaruhi penetapan slot.

Karena itu, urutan variabel dapat mengubah jumlah slot yang diperlukan kontrak.

Namun, penggunaan integer sekecil mungkin tidak selalu lebih murah.

EVM biasanya melakukan operasi aritmetika dengan word 256-bit, sehingga tipe integer yang lebih kecil mungkin memerlukan operasi masking atau konversi tambahan.

Pengemasan memberikan manfaat paling jelas ketika beberapa nilai yang dikemas biasanya dibaca atau ditulis bersama.

Memperbarui hanya satu nilai di dalam slot yang dikemas mungkin mengharuskan pembacaan slot, pengubahan sebagian word, dan penulisan kembali nilai gabungan.

Tata letak storage juga menjadi bagian dari kompatibilitas kontrak yang dapat di-upgrade, sehingga developer sebaiknya tidak mengubah urutan variabel state yang sudah ada hanya untuk menghemat gas setelah deployment.

Gunakan Variabel Constant dan Immutable

Nilai yang tidak pernah berubah setelah kompilasi biasanya sebaiknya dinyatakan sebagai

jika Solidity mengizinkannya.

Nilai yang dipilih saat konstruksi kontrak tetapi tetap setelahnya dapat dinyatakan sebagai

.

Konstanta dan immutable menghindari akses storage persisten biasa karena nilainya disisipkan atau disimpan bersama kode kontrak.

Dokumentasi kontrak Solidity resmi menjelaskan perbedaan variabel ini dari variabel state biasa.

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

Variabel tidak sebaiknya dibuat immutable jika aplikasi memang memerlukan tata kelola atau proses lain yang berwenang untuk memperbaruinya.

Menghilangkan fleksibilitas yang diperlukan hanya demi menghemat gas dapat menimbulkan masalah operasional yang lebih besar di kemudian hari.

Gunakan Calldata untuk Input Eksternal Hanya-Baca

Argumen fungsi eksternal yang tidak perlu diubah sering kali dapat menggunakan lokasi data

.

Calldata bersifat hanya-baca dan menghindari penyalinan seluruh input ke memory pada awal eksekusi.

Panduan lokasi data Solidity menyarankan penggunaan calldata jika memungkinkan karena menghindari penyalinan dan mencegah perubahan.

Teknik ini sangat berguna untuk array, urutan byte, string, dan struct yang diberikan ke fungsi eksternal.

Memory tetap sesuai jika kontrak perlu mengubah data atau membuat nilai baru di dalam memory.

Developer tidak boleh berasumsi bahwa mengubah parameter fungsi dari

menjadi integer yang lebih kecil otomatis mengurangi ukuran calldata.

Pengodean ABI standar umumnya menempatkan nilai statis dalam word 32-byte, dan tipe yang lebih kecil dapat menimbulkan pekerjaan konversi atau validasi.

Penghematan gas sebaiknya dipastikan melalui pengukuran, bukan disimpulkan hanya dari nama tipe pada tingkat kode sumber.

Minimalkan Calldata Transaksi

Setiap byte dalam calldata transaksi menambah biaya intrinsik transaksi.

Array yang tidak diperlukan, kolom duplikat, string teks panjang, dan pengodean yang tidak efisien dapat membuat transaksi pengguna lebih mahal.

Developer terkadang dapat mengganti nilai lengkap yang berulang dengan ID ringkas yang dipetakan kontrak ke konfigurasi tersimpan.

Developer juga dapat menghindari pengiriman informasi yang dapat dihitung kontrak secara aman dari state yang ada atau pengirim transaksi.

Kompresi dapat membantu dalam sistem khusus, tetapi dekompresi sendiri menggunakan gas dan dapat menghilangkan penghematan yang diharapkan.

Pectra mengaktifkan EIP-7623, yang menetapkan batas bawah gas lebih tinggi untuk transaksi padat data.

Hal ini membuat efisiensi calldata sangat relevan bagi transaksi yang membawa banyak data tetapi hanya melakukan sedikit eksekusi EVM.

Developer sebaiknya membandingkan biaya calldata ringkas dengan eksekusi tambahan yang diperlukan untuk menguraikannya.

Gunakan Transient Storage untuk State yang Terbatas pada Transaksi

Transient storage memungkinkan kontrak menyimpan nilai yang tetap tersedia selama pemanggilan internal dalam satu transaksi, tetapi otomatis dihapus saat transaksi berakhir.

Ethereum memperkenalkan opcode

dan melalui EIP-1153.

Transient storage lebih murah daripada storage persisten karena tidak menjadi bagian dari state blockchain permanen.

Salah satu penggunaan umum adalah kunci reentrancy yang hanya diperlukan selama satu transaksi berlangsung.

Versi Solidity saat ini mendukung variabel state bertipe nilai transient ketika kontrak menargetkan EVM Cancun atau versi kompatibel yang lebih baru.

Transient storage tidak boleh digunakan untuk informasi yang harus bertahan hingga transaksi berikutnya.

Perilakunya dalam pemanggilan biasa, delegate call, dan kontrak yang dapat dikomposisikan juga harus dipahami dengan saksama.

Dokumentasi transient storage Solidity memperingatkan bahwa state transient hanya berlaku selama transaksi dan memiliki perilaku kepemilikan tertentu pada berbagai jenis pemanggilan.

Developer sebaiknya tidak mengganti mekanisme keamanan yang telah teruji dengan transient storage sebelum implementasi baru diuji dan diaudit secara menyeluruh.

Gunakan Custom Error, Bukan String Revert Panjang

Custom error menyediakan cara yang hemat gas untuk mengembalikan informasi kegagalan yang terstruktur.

String revert yang panjang menjadi bagian dari bytecode kontrak yang di-deploy dan menghasilkan data respons terenkode ketika kondisi gagal.

Custom error menggunakan selector empat byte beserta parameter yang dideklarasikan, sehingga dapat mengurangi ukuran deployment dan biaya jalur kegagalan.

Dokumentasi custom error Solidity menjelaskan bahwa custom error merupakan mekanisme kesalahan yang praktis dan hemat gas.

Nama dan parameter error harus tetap jelas agar wallet, developer, dan sistem pemantauan dapat mendiagnosis masalah.

Menghapus seluruh informasi error yang berguna dapat menghemat sedikit gas, tetapi membuat transaksi kripto yang gagal jauh lebih sulit diselidiki.

Optimalkan Loop dan Pemrosesan Array

Loop dapat menjadi sangat mahal ketika jumlah iterasinya bergantung pada array atau koleksi storage yang dapat terus bertambah tanpa batas ketat.

Loop tanpa batas dapat pada akhirnya memerlukan gas melebihi kapasitas satu transaksi sehingga fungsi kontrak penting tidak dapat digunakan.

Jika memungkinkan, beban kerja besar sebaiknya dibagi ke dalam batch yang memiliki batas.

Loop yang berulang kali membaca panjang array dari storage terkadang dapat menyimpan panjang tersebut dalam variabel lokal.

Nilai storage yang digunakan pada setiap iterasi juga dapat di-cache jika aman.

Developer dapat menggunakan aritmetika

untuk penghitung loop hanya jika dapat membuktikan overflow tidak mungkin terjadi.

Compiler Solidity modern sudah mengoptimalkan beberapa pola loop umum, sehingga perubahan manual harus diuji kinerjanya sebelum diterapkan.

Memproses pekerjaan melalui beberapa transaksi dapat meningkatkan keandalan, tetapi kontrak harus melacak progres dengan aman dan mencegah pekerjaan terlewat, terduplikasi, atau berubah urutan.

Hindari Pemanggilan Eksternal yang Berulang

Memanggil kontrak lain menggunakan gas dan membuat transaksi bergantung pada perilaku eksekusi kontrak yang dipanggil.

Fungsi sebaiknya tidak meminta nilai eksternal yang sama berulang kali jika dapat memanggilnya sekali dengan aman lalu menggunakan kembali hasilnya.

Beberapa tindakan terkait terkadang dapat digabungkan dalam satu pemanggilan kontrak.

Namun, batching meningkatkan jumlah pekerjaan yang dapat gagal bersama dan dapat menghasilkan payload calldata yang lebih besar.

Pemanggilan eksternal juga dapat membuka kemungkinan reentrancy, mengembalikan data yang tidak terduga, menggunakan banyak gas, atau membatalkan seluruh transaksi.

Penghematan gas tidak boleh menjadi alasan untuk menghapus pemeriksaan nilai yang dikembalikan atau penanganan pemanggilan yang aman.

Developer sebaiknya menentukan apakah nilai eksternal yang di-cache tetap valid sepanjang eksekusi dan apakah sistem eksternal dapat mengubahnya melalui callback.

Gunakan Event, Bukan Storage, Jika Sesuai

Event mencatat informasi dalam log transaksi dan dapat diindeks oleh aplikasi off-chain.

Event sering kali lebih murah daripada menyimpan informasi setara dalam state kontrak.

Event sesuai untuk riwayat aktivitas, notifikasi antarmuka pengguna, analitik, dan catatan yang tidak perlu dibaca oleh eksekusi smart contract di masa mendatang.

Event bukan pengganti state yang menentukan saldo, kepemilikan, izin, utang, kolateral, atau perilaku kontrak lainnya.

Smart contract umumnya tidak dapat mengambil log historis selama eksekusi EVM biasa.

Sistem yang hanya menyimpan informasi akuntansi penting dalam event memerlukan layanan off-chain untuk merekonstruksinya dan tidak dapat menegakkannya secara langsung on-chain.

Parameter event juga perlu dirancang dengan cermat karena topik terindeks dan data log memiliki biaya gas serta karakteristik pencarian yang berbeda.

Kurangi Ukuran Deployment Kontrak

Deployment kontrak dikenai biaya untuk menjalankan logika inisialisasi dan menyimpan bytecode runtime.

Fungsi yang tidak digunakan, logika duplikat, string revert panjang, dan data yang disematkan dapat meningkatkan biaya deployment.

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

Library eksternal dapat mengurangi bytecode duplikat di beberapa deployment, tetapi pemanggilannya dapat menambah overhead runtime dan ketergantungan operasional.

Pola factory dan clone dapat menurunkan biaya deployment banyak instance kontrak serupa dengan berbagi kode implementasi.

Pola proxy dapat mendukung upgrade dan deployment berulang, tetapi menambah overhead delegate call serta pertimbangan serius terkait tata letak storage, tata kelola, dan keamanan.

Ethereum membatasi bytecode runtime biasa yang di-deploy berdasarkan EIP-170, sedangkan EIP-3860 mengukur dan membatasi kode inisialisasi.

Memecah kode hanya agar tetap di bawah batas ukuran dapat meningkatkan biaya pemanggilan, sehingga arsitektur perlu dievaluasi sepanjang siklus hidup kontrak.

Targetkan Versi EVM yang Tepat

Output compiler bergantung pada target EVM yang dipilih.

Compiler yang menargetkan EVM lebih baru dapat menggunakan instruksi yang tidak tersedia di jaringan lama.

Contohnya, Shanghai memperkenalkan instruksi

melalui EIP-3855, yang memungkinkan nilai nol dimasukkan dengan instruksi lebih kecil dan murah.

Dencun memperkenalkan

melalui EIP-5656, yang menyediakan metode penyalinan memory yang lebih efisien.

Compiler modern dapat menggunakan instruksi ini secara otomatis jika dikonfigurasi untuk jaringan yang kompatibel.

Developer biasanya tidak perlu menulis ulang optimasi compiler semacam itu secara manual dalam assembly.

Kontrak yang dikompilasi untuk upgrade protokol yang belum diaktifkan di jaringan tujuan dapat gagal di-deploy atau dieksekusi.

Karena itu, sistem build harus menetapkan versi EVM yang tepat untuk setiap chain tujuan.

Pertimbangkan Access List Hanya Setelah Pengujian

Access list memungkinkan transaksi mencantumkan akun dan key storage yang diperkirakan akan diakses.

Item yang tercantum dianggap warm saat eksekusi dimulai, sehingga biaya akses cold berikutnya berkurang.

EIP-2930 mengenakan biaya untuk setiap alamat dan key storage yang dimasukkan ke daftar.

Access list yang akurat dapat mengurangi biaya untuk transaksi tertentu yang alurnya dapat diprediksi.

Daftar yang tidak lengkap atau tidak diperlukan dapat meningkatkan total biaya karena pengguna membayar item yang manfaatnya terlalu kecil atau tidak digunakan.

Access list sulit dibuat ketika jalur eksekusi yang tepat bergantung pada state blockchain yang berubah.

Developer sebaiknya menyimulasikan seluruh transaksi dengan dan tanpa access list, bukan berasumsi bahwa memuat state terlebih dahulu selalu lebih murah.

Gabungkan Tindakan Pengguna dengan Cermat

Menggabungkan beberapa tindakan dalam satu transaksi dapat menghindari pembayaran biaya dasar transaksi berulang kali.

Misalnya, aplikasi dapat memungkinkan pengguna menyetujui dan menjalankan suatu tindakan melalui satu alur kerja yang terkoordinasi.

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

Batching tidak otomatis mengurangi setiap bagian biaya eksekusi karena tiap tindakan tetap menjalankan pekerjaan kontrak yang diperlukan.

Batch besar dapat melampaui batas gas praktis, menambah calldata, atau menyebabkan seluruh tindakan dibatalkan jika satu langkah gagal.

Aplikasi sebaiknya menetapkan apakah penyelesaian sebagian diperbolehkan dan bagaimana sub-tindakan yang gagal dilaporkan.

Otorisasi wallet dan kode yang didelegasikan harus diperiksa dengan cermat karena sistem batching dapat memiliki kendali luas atas aset pengguna.

Gunakan Jaringan Layer 2 Jika Sesuai

Optimasi di tingkat aplikasi mengurangi jumlah unit gas yang digunakan, sedangkan jaringan Layer 2 dapat mengurangi harga yang dibayar pengguna untuk eksekusi dan data.

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

Dencun memperkenalkan transaksi pembawa blob melalui EIP-4844, yang menyediakan jalur data sementara yang lebih khusus bagi rollup.

Pectra dan Fusaka kemudian memperluas kemampuan penskalaan dan ketersediaan data Ethereum.

Panduan builder Ethereum saat ini menjelaskan bagaimana upgrade terbaru mengubah biaya mainnet, kemampuan akun, dan ekonomi rollup.

Deployment ke jaringan Layer 2 tidak menghilangkan kebutuhan akan kontrak yang efisien karena penyimpanan dan komputasi yang tidak perlu tetap meningkatkan biaya pengguna dan mengurangi kapasitas.

Developer juga sebaiknya mengevaluasi kebutuhan bridge, penarikan, likuiditas, keamanan, dan interoperabilitas sebelum memilih jaringan.

Gunakan Inline Assembly Hanya Jika Diperlukan

Inline assembly dapat memberi developer kendali presisi atas operasi EVM dan terkadang mengurangi gas.

Namun, inline assembly juga menghilangkan atau melewati sebagian pemeriksaan tipe, perlindungan memory, dan fitur keamanan tingkat tinggi Solidity.

Rutinitas assembly singkat mungkin sulit dipahami peninjau dan dapat menyebabkan kerusakan memory, pengodean yang salah, atau perilaku pemanggilan yang tidak aman.

Compiler mungkin sudah mengoptimalkan Solidity biasa menjadi kode yang sama efisiennya dengan implementasi manual.

Karena itu, assembly sebaiknya hanya digunakan untuk bottleneck yang telah diukur, kriptografi khusus, pemrosesan data tingkat rendah, atau fungsi yang tidak dapat dinyatakan secara efisien dalam Solidity.

Setiap optimasi assembly harus disertai pengujian yang membandingkan hasilnya dengan implementasi acuan yang jelas.

Peninjauan keamanan independen sangat penting, terutama ketika assembly mengendalikan saldo token, tanda tangan, izin, atau pemanggilan eksternal.

Jangan Korbankan Keamanan demi Penghematan Gas

Smart contract yang lebih murah tidak lebih baik jika dapat menyebabkan hilangnya mata uang kripto pengguna.

Developer tidak boleh menghapus pemeriksaan kontrol akses, validasi input, perlindungan reentrancy, verifikasi tenggat waktu, perlindungan slippage, atau pemeriksaan akuntansi hanya demi menghemat gas.

Aritmetika unchecked hanya boleh digunakan jika overflow dan underflow secara matematis mustahil terjadi pada setiap kondisi yang mungkin dicapai.

Menggabungkan beberapa variabel ke dalam satu nilai terkompresi dapat menghemat storage, tetapi meningkatkan kemungkinan kesalahan manipulasi bit.

Penggunaan proxy dapat mengurangi biaya deployment, tetapi menimbulkan risiko kewenangan upgrade dan benturan storage.

Tanda tangan off-chain dapat mengurangi transaksi, tetapi memerlukan nonce, masa berlaku, pemisahan domain, dan perlindungan replay yang benar.

Setiap optimasi harus dievaluasi dari sisi keterbacaan, kemudahan audit, risiko operasional, dan pemeliharaan di masa mendatang, selain biaya gas.

Kesalahan Umum dalam Optimasi Gas

Salah satu kesalahan umum adalah memilih tipe integer yang lebih kecil tanpa mengemasnya dengan nilai lain.

EVM beroperasi dengan word 256-bit, sehingga tipe yang lebih kecil mungkin tidak mengurangi biaya runtime dengan sendirinya.

Kesalahan lainnya adalah menyalin seluruh calldata ke memory meskipun fungsi hanya perlu membacanya.

Kesalahan ketiga adalah menghapus storage hanya untuk mengejar pengembalian biaya, lalu berencana membuat ulang state yang sama.

Kesalahan keempat adalah menggunakan loop tanpa batas pada array storage yang terus bertambah.

Kesalahan kelima adalah memilih nilai optimizer runs tinggi tanpa membandingkan biaya deployment dan perilaku runtime.

Kesalahan keenam adalah menulis assembly manual sebelum melakukan profiling kontrak.

Kesalahan ketujuh adalah menganggap suatu optimasi tetap valid setelah upgrade compiler atau jaringan mengubah perilaku opcode.

Kesalahan kedelapan adalah hanya mengukur transaksi yang berhasil dan mengabaikan jalur revert yang mahal.

Kesalahan kesembilan adalah menganggap estimasi gas lebih rendah sebagai bukti bahwa dua implementasi memiliki logika bisnis dan keamanan yang identik.

Cara Membangun Proses Optimasi Gas

Proses yang andal dimulai dengan menetapkan perilaku dan properti keamanan kontrak yang diwajibkan.

Tim sebaiknya membuat pengujian fungsional sebelum mencoba optimasi tingkat rendah.

Selanjutnya, tim perlu mengukur biaya deployment dan gas yang digunakan setiap jalur transaksi penting.

Penulisan storage, loop, input calldata, dan pemanggilan eksternal yang paling mahal harus diidentifikasi melalui profiling.

Developer dapat menyederhanakan arsitektur, mengurangi perubahan state, memilih lokasi data yang sesuai, dan mengaktifkan pengaturan optimasi compiler yang telah diuji.

Setiap perubahan harus diukur terhadap versi asli dan ditinjau untuk mengidentifikasi risiko keamanan baru.

Pengujian regresi gas sebaiknya dipertahankan dalam proyek agar pengembangan selanjutnya tidak diam-diam menghapus penghematan.

Bytecode produksi final harus dikompilasi dengan compiler yang versinya ditetapkan, konfigurasi terverifikasi, target EVM yang tepat, dan versi dependensi yang telah ditinjau.

Kontrak mata uang kripto bernilai tinggi sebaiknya menjalani audit keamanan independen sekalipun kode yang dioptimalkan telah lolos pengujian internal.

FAQ

Apa teknik optimasi gas terbaik?

Teknik yang paling efektif biasanya adalah mengurangi operasi penyimpanan persisten dan menyederhanakan pekerjaan on-chain yang dilakukan setiap transaksi.

Apakah optimizer Solidity selalu mengurangi gas?

Tidak, pengaturan optimizer dapat mengurangi gas runtime sekaligus meningkatkan biaya deployment, sehingga developer sebaiknya menguji seluruh siklus hidup kontrak.

Apa arti pengaturan optimizer runs?

Pengaturan ini memberi tahu compiler seberapa sering developer memperkirakan kode runtime akan dieksekusi dan memengaruhi kompromi antara ukuran deployment dan biaya eksekusi berulang.

Apakah storage lebih mahal daripada memory?

Ya, storage persisten umumnya jauh lebih mahal karena datanya 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 kontrak dapat mengaksesnya tanpa terlebih dahulu menyalin seluruh data ke memory.

Apakah tipe integer yang lebih kecil selalu menghemat gas?

Tidak, tipe ini paling berguna ketika beberapa nilai dapat dikemas dalam satu slot storage, sedangkan integer kecil yang berdiri sendiri mungkin memerlukan operasi konversi tambahan.

Mengapa developer sebaiknya melakukan caching nilai storage?

Cache dapat menghindari pembacaan storage berulang ketika nilai tidak berubah dan dapat digunakan kembali dengan aman dari stack atau memory.

Apa itu transient storage?

Transient storage adalah storage EVM yang hanya berlaku selama transaksi, dihapus secara otomatis, dan dapat mendukung state sementara berbiaya lebih rendah seperti kunci reentrancy.

Apakah custom error lebih murah daripada string revert?

Custom error umumnya lebih hemat gas karena menggunakan selector ringkas dan parameter terenkode, bukan menyimpan serta mengembalikan string teks panjang.

Bisakah event menggantikan storage kontrak?

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

Apakah penghapusan storage mengembalikan seluruh biaya gasnya?

Tidak, pengembalian untuk penghapusan storage terbatas dan tunduk pada batas pengembalian gas di tingkat protokol.

Haruskah developer menggunakan aritmetika unchecked untuk menghemat gas?

Aritmetika unchecked hanya boleh digunakan jika overflow atau underflow terbukti mustahil terjadi serta alasan keamanannya didokumentasikan dan diuji.

Apakah batching transaksi selalu menghemat gas?

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

Bisakah jaringan Layer 2 menggantikan optimasi kontrak?

Tidak, biaya jaringan yang lebih rendah dapat mengurangi biaya pengguna, tetapi kontrak yang tidak efisien tetap membuang kapasitas eksekusi dan lebih mahal daripada kontrak teroptimasi di jaringan yang sama.

Apakah access list selalu mengurangi gas?

Tidak, setiap item access list memiliki biaya sendiri dan dapat meningkatkan biaya jika tidak akurat atau tidak diperlukan.

Apakah inline assembly selalu menggunakan lebih sedikit gas?

Tidak, compiler mungkin menghasilkan kode yang sama efisiennya, sedangkan assembly yang tidak aman dapat menimbulkan masalah serius pada keamanan dan pemeliharaan.

Bagaimana developer dapat mengukur penggunaan gas?

Developer dapat menggunakan estimasi compiler, snapshot gas otomatis, pengujian transaksi lokal, execution trace, dan alat profiling.

Mengapa biaya gas dapat berubah setelah upgrade jaringan?

Upgrade Ethereum dapat menambahkan opcode, mengubah harga operasi yang sudah ada, mengubah aturan calldata, atau memperkenalkan fitur storage dan memory yang lebih efisien.

Bisakah optimasi gas mencegah biaya jaringan yang tinggi?

Optimasi mengurangi unit gas yang digunakan, tetapi tidak dapat mencegah kenaikan harga gas pasar ketika banyak pengguna bersaing untuk mendapatkan ruang blok.

Apakah kontrak dengan biaya terendah selalu yang terbaik?

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

Kesimpulan

Teknik optimasi gas mengurangi sumber daya komputasi, penyimpanan, calldata, dan deployment yang diperlukan smart contract mata uang kripto.

Penghematan terbesar sering berasal dari meminimalkan penulisan storage persisten, melakukan cache pembacaan storage yang aman, memilih lokasi data yang tepat, mengurangi calldata yang tidak perlu, dan menghindari pemanggilan eksternal berulang.

Compiler Solidity modern dapat mengoptimalkan bytecode secara otomatis, tetapi pengaturan optimizer harus dipilih melalui pengukuran realistis, bukan tebakan.

Fitur Ethereum terkini seperti transient storage,

, , kode akun yang didelegasikan, dan penetapan harga calldata yang diperbarui telah mengubah pendekatan optimasi yang perlu digunakan developer.

Developer sebaiknya menargetkan versi EVM yang tepat serta selalu memperbarui compiler, pengujian, dan pemahaman tentang aturan protokol.

Teknik seperti pengemasan variabel, custom error, loop berbatas, batching, event, library, dan deployment Layer 2 dapat mengurangi biaya jika sesuai dengan desain aplikasi.

Access list, proxy, inline assembly, aritmetika unchecked, dan storage terkompresi memerlukan kehati-hatian ekstra karena manfaat gas kecil dapat menimbulkan kompleksitas atau risiko signifikan.

Setiap optimasi harus diukur pada deployment, eksekusi yang berhasil, jalur kegagalan, dan penggunaan kontrak jangka panjang.

Pemeriksaan keamanan tidak boleh dihapus hanya untuk menurunkan hasil laporan gas.

Strategi optimasi gas terbaik adalah melakukan hanya pekerjaan on-chain minimum yang diperlukan agar operasi mata uang kripto tetap aman dan dapat diverifikasi.