Solidity Compiler (solc)

Apa Itu Solidity Compiler (solc)?

Solidity Compiler, yang umum disebut solc, adalah alat yang mengubah source code smart contract Solidity menjadi output yang dapat dibaca mesin dan dapat di-deploy, diverifikasi, dianalisis, serta diinteraksikan pada jaringan blockchain bergaya Ethereum.

Solidity adalah bahasa pemrograman smart contract tingkat tinggi yang dirancang untuk Ethereum Virtual Machine, dan situs web Solidity resmi menjelaskannya sebagai bahasa statically typed dengan kurung kurawal untuk mengembangkan smart contract yang berjalan di Ethereum.

Solc penting karena blockchain tidak menjalankan kode Solidity yang dapat dibaca manusia secara langsung.

Developer menulis file sumber Solidity, lalu compiler mengubah file tersebut menjadi bytecode EVM, data ABI, metadata, representasi perantara, peringatan, error, dan output build lainnya.

Dokumentasi compiler Solidity resmi menjelaskan bahwa compiler dapat menghasilkan output mulai dari binary dan assembly hingga abstract syntax tree dan estimasi gas.

Dalam pengembangan kripto, solc berada di antara developer smart contract dan kontrak on-chain yang telah di-deploy.

Jika versi compiler, pengaturan, library, opsi optimizer, atau target EVM salah, bytecode yang di-deploy dapat berbeda dari yang diharapkan developer.

Inilah sebabnya solc bukan sekadar alat praktis bagi developer.

Solc merupakan bagian penting dari keamanan smart contract, keandalan deployment, verifikasi source code, dan kepercayaan pengguna.

Sederhananya, Solidity Compiler adalah program yang mengubah smart contract Solidity menjadi bytecode dan data antarmuka yang diperlukan untuk menjalankannya di jaringan blockchain yang mendukung EVM.

Mengapa solc Penting dalam Kripto

Solc penting karena smart contract sering mengelola token, sistem staking, pasar pinjaman, bridge, logika governance, koleksi NFT, kontrol treasury, dan protokol DeFi.

Kesalahan dalam kompilasi dapat memengaruhi aset nyata karena smart contract yang telah di-deploy sulit atau tidak mungkin diubah setelah deployment, kecuali mekanisme upgrade telah dirancang sebelumnya.

Dokumentasi smart contract Ethereum resmi menjelaskan bahwa smart contract adalah program yang disimpan di blockchain dan berjalan ketika transaksi memicunya.

Artinya, bytecode hasil kompilasi adalah logika program sebenarnya yang dieksekusi jaringan.

Pengguna dapat membaca file Solidity yang rapi di situs web, tetapi blockchain hanya menerapkan bytecode yang telah di-deploy.

Jika source code dan bytecode hasil kompilasi tidak cocok, pengguna tidak dapat dengan aman mengasumsikan bahwa source code yang dipublikasikan merepresentasikan kontrak aktif.

Dokumentasi verifikasi kontrak Ethereum resmi menjelaskan bahwa verifikasi kontrak membandingkan source code dengan bytecode hasil kompilasi untuk mendeteksi apakah keduanya cocok.

Solc juga penting karena versi compiler dapat menghadirkan fitur bahasa baru, peringatan baru, perbaikan bug, peningkatan optimizer, perubahan target EVM, dan perubahan perilaku.

Proyek yang menggunakan versi compiler salah dapat gagal dikompilasi, dikompilasi dengan perilaku berbeda, atau menghasilkan bytecode yang lebih sulit diverifikasi.

Bagi pengguna kripto, memahami solc membantu menjelaskan mengapa source code terverifikasi, pengaturan compiler, dan metadata deployment merupakan sinyal kepercayaan yang penting.

Cara Kerja solc

Solc menerima source code Solidity sebagai input dan memprosesnya melalui beberapa tahap kompilasi.

Compiler pertama-tama melakukan parsing kode dan memeriksa apakah sintaksnya valid.

Kemudian, compiler menganalisis ketepatan tipe, hubungan inheritance, visibilitas fungsi, storage layout, import, dan aturan bahasa lainnya.

Jika kode memiliki error, solc berhenti dan melaporkan error tersebut.

Jika kode memiliki masalah yang mungkin berisiko tetapi tidak fatal, solc dapat melaporkan peringatan.

Setelah analisis, solc dapat menghasilkan representasi perantara yang membantu optimasi dan pembuatan kode.

Compiler kemudian menghasilkan bytecode deployment, bytecode runtime, data ABI, metadata, dan output lain yang diminta.

Bytecode deployment digunakan ketika kontrak dibuat di blockchain.

Bytecode runtime adalah kode yang tetap berada di alamat kontrak setelah deployment.

ABI menjelaskan cara pengguna eksternal, wallet, skrip, dan kontrak lain memanggil fungsi kontrak serta mendekode data yang dikembalikan.

Source Code Solidity

Source code Solidity adalah kode yang dapat dibaca manusia dan ditulis developer sebelum kompilasi.

File Solidity biasanya menggunakan ekstensi file .sol.

File sumber dapat mencakup pernyataan pragma, import, definisi kontrak, interface, library, struct, enum, event, error, fungsi, modifier, dan komentar.

Compiler membaca file-file ini dan menerapkan aturan versi bahasa Solidity yang dipilih.

Pernyataan pragma biasanya memberi tahu alat mengenai versi compiler yang diizinkan untuk file tersebut.

Contohnya, pragma dapat mengizinkan hanya versi compiler dalam rentang 0.8.x tertentu.

Hal ini penting karena perilaku bahasa Solidity dapat berubah antarversi.

File sumber yang dikompilasi dengan aman menggunakan satu versi mungkin tidak dikompilasi dengan cara yang sama menggunakan versi lain.

Developer perlu memilih versi compiler secara sengaja, bukan mengandalkan versi apa pun yang kebetulan terinstal.

Dalam proyek kripto produksi, source code, versi dependensi, versi compiler, dan pengaturan compiler harus dikunci serta dapat direproduksi.

Bytecode

Bytecode adalah kode tingkat rendah yang dapat dibaca mesin dan berjalan di Ethereum Virtual Machine.

Solc menghasilkan bytecode dari source code Solidity.

Bytecode deployment digunakan untuk membuat kontrak dan dapat mencakup logika constructor serta argumen constructor yang dikodekan.

Bytecode runtime adalah kode yang disimpan di alamat kontrak setelah pembuatan.

Wallet dan blockchain explorer biasanya tidak menampilkan bytecode sebagai logika bisnis yang mudah dibaca karena bytecode sulit dipahami manusia secara langsung.

Inilah alasan source code terverifikasi berguna untuk transparansi.

Namun, EVM mengeksekusi bytecode, bukan teks Solidity asli.

Perbedaan ini penting karena dua file sumber yang tampak serupa dapat dikompilasi menjadi bytecode berbeda jika pengaturan compiler berbeda.

Hal ini juga penting karena pengaturan optimizer dapat mengubah struktur bytecode secara signifikan.

Untuk peninjauan smart contract yang serius, developer dan auditor perlu memahami bahwa bytecode yang di-deploy adalah sumber kebenaran terakhir.

ABI

ABI adalah singkatan dari Application Binary Interface.

Spesifikasi ABI Solidity resmi menjelaskan bahwa ABI kontrak adalah cara standar untuk berinteraksi dengan kontrak dalam ekosistem Ethereum dari luar blockchain dan melalui pemanggilan antarkontrak.

ABI memberi tahu alat cara mengodekan pemanggilan fungsi dan mendekode nilai yang dikembalikan.

ABI mencakup nama fungsi, tipe input, tipe output, event, error, dan detail antarmuka lainnya.

Wallet atau skrip menggunakan ABI untuk mengetahui cara memanggil fungsi smart contract dengan benar.

Contohnya, jika kontrak token memiliki fungsi transfer, ABI memberi tahu perangkat lunak cara mengodekan alamat penerima dan jumlahnya.

Tanpa ABI, pengguna masih dapat mengirim calldata mentah, tetapi prosesnya jauh lebih sulit dan rentan error.

ABI tidak sama dengan source code kontrak.

ABI juga tidak sama dengan bytecode.

ABI adalah deskripsi antarmuka yang membantu manusia dan perangkat lunak berinteraksi dengan smart contract yang telah dikompilasi.

Metadata Compiler

Solc dapat menyertakan metadata yang menjelaskan cara sebuah kontrak dikompilasi.

Dokumentasi metadata Solidity resmi menjelaskan bahwa compiler secara default menambahkan hash metadata ke bytecode runtime agar file metadata dapat diambil dengan cara terautentikasi jika dipublikasikan.

Metadata dapat mencakup informasi file sumber, versi compiler, pengaturan, konfigurasi optimizer, ABI, dan detail kompilasi lainnya.

Informasi ini membantu blockchain explorer dan alat verifikasi membuat ulang output kompilasi.

Metadata juga penting karena bahkan perbedaan kecil dalam pengaturan compiler dapat mengubah bytecode.

Jika proyek ingin pengguna memverifikasi kontrak, proyek harus menyimpan file sumber dan konfigurasi compiler yang tepat yang digunakan saat deployment.

Metadata juga dapat mengungkap informasi berguna bagi peneliti dan auditor.

Namun, metadata saja tidak membuktikan bahwa kontrak aman.

Metadata terutama membantu menetapkan apakah source code dan pengaturan yang dipublikasikan sesuai dengan bytecode yang di-deploy.

Pengguna perlu memperlakukan metadata terverifikasi sebagai sinyal transparansi, bukan jaminan keamanan.

Input dan Output Standard JSON

Antarmuka Standard JSON adalah cara terstruktur yang direkomendasikan untuk menggunakan solc dalam sistem build otomatis.

Dokumentasi compiler Solidity menjelaskan bahwa solc dapat menerima input Standard JSON melalui standard input dan mengembalikan output JSON melalui standard output.

Input Standard JSON dapat menentukan file sumber, pengaturan compiler, pengaturan optimizer, versi EVM, library, remapping, dan output yang diminta.

Output Standard JSON dapat mencakup error, peringatan, ABI, bytecode, bytecode yang di-deploy, metadata, estimasi gas, storage layout, dan hasil lain yang diminta.

Format ini berguna karena proyek smart contract modern sering memiliki banyak file dan dependensi.

Format ini juga membuat kompilasi lebih dapat direproduksi karena pengaturan dapat dicatat dalam satu objek terstruktur.

Alat build dan layanan verifikasi sering bergantung pada Standard JSON atau data konfigurasi compiler serupa.

Developer sebaiknya menyimpan input compiler final yang digunakan untuk deployment jika memungkinkan.

Hal ini membantu audit di masa depan, investigasi insiden, dan verifikasi source code.

Untuk smart contract produksi, kompilasi yang dapat direproduksi merupakan praktik terbaik untuk keamanan dan transparansi.

Versi Compiler

Versi compiler Solidity penting karena aturan bahasa dan perilaku compiler dapat berubah seiring waktu.

Halaman rilis Solidity resmi memublikasikan pengumuman rilis compiler yang menjelaskan fitur baru, perbaikan bug, perubahan kompatibilitas, dan pembaruan target EVM.

Berdasarkan informasi rilis 2026 dari situs web Solidity resmi, Solidity Compiler v0.8.35 adalah rilis terbaru yang menambahkan fungsionalitas compiler baru dan mempratinjau perubahan di masa depan.

Kontrak yang ditulis untuk satu versi compiler mungkin tidak dapat dikompilasi dengan versi lain tanpa perubahan.

Bahkan jika dapat dikompilasi, bytecode yang dihasilkan dapat berbeda.

Inilah alasan sebagian besar proyek Solidity menetapkan versi compiler dalam konfigurasi build.

Pernyataan pragma dapat menyatakan rentang versi yang kompatibel, tetapi build produksi sering mengunci versi compiler yang tepat secara terpisah.

Menggunakan compiler yang lebih baru dapat memberikan perbaikan bug dan peringatan yang lebih baik.

Menggunakan compiler yang lebih baru tanpa peninjauan juga dapat menimbulkan perubahan yang memerlukan pengujian.

Developer perlu membaca catatan rilis sebelum meningkatkan solc untuk kontrak produksi.

Pragma Solidity

Pernyataan pragma memberi tahu compiler versi Solidity yang dimaksudkan untuk file sumber.

Pragma bukan compiler itu sendiri.

Pragma adalah instruksi source code yang membantu alat menolak versi compiler yang tidak kompatibel.

Contohnya, proyek dapat menggunakan pragma yang mengizinkan rentang versi Solidity 0.8.x.

Ini dapat memudahkan library, tetapi berisiko bagi deployment jika versi tepatnya tidak dikunci di tempat lain.

Pragma yang luas dapat memungkinkan developer berbeda mengompilasi kode yang sama dengan versi patch berbeda.

Hal ini dapat membuat verifikasi bytecode lebih sulit jika versi deployment akhir tidak dicatat.

Untuk kontrak aplikasi, tim sering menggabungkan pragma yang wajar dengan versi compiler tepat dalam build tool mereka.

Hal ini menciptakan kompatibilitas untuk file sumber sambil menjaga build deployment tetap dapat direproduksi.

Pengguna yang meninjau kontrak terverifikasi harus memeriksa pragma dan versi compiler aktual yang digunakan untuk verifikasi.

Optimizer

Optimizer Solidity adalah fitur compiler yang berupaya membuat kode yang dihasilkan lebih efisien.

Dokumentasi optimizer Solidity resmi menjelaskan bahwa optimizer berupaya menyederhanakan ekspresi yang rumit dan dapat mengurangi ukuran kode maupun biaya eksekusi.

Optimasi dapat mengurangi gas deployment, gas runtime, atau keduanya, bergantung pada pengaturan dan perilaku kontrak.

Optimizer juga dapat mengubah struktur bytecode secara signifikan.

Hal ini penting karena kontrak yang dikompilasi dengan optimizer aktif tidak akan cocok dengan kontrak yang sama yang dikompilasi dengan optimizer nonaktif.

Optimizer runs adalah pengaturan yang memberi tahu compiler seberapa besar prioritas efisiensi runtime dibandingkan biaya deployment.

Nilai runs rendah dapat mendukung biaya deployment yang lebih rendah untuk kode yang jarang dipanggil.

Nilai runs tinggi dapat mendukung biaya runtime yang lebih rendah untuk kode yang sering dipanggil.

Developer perlu menguji perilaku gas dalam pola penggunaan realistis sebelum memilih pengaturan.

Auditor perlu meninjau konfigurasi optimizer tepat yang digunakan saat deployment karena memengaruhi bytecode akhir.

via-IR

via-IR adalah pipeline kompilasi Solidity yang mengarahkan kompilasi melalui representasi perantara compiler.

Representasi perantara dapat membantu compiler melakukan optimasi dan transformasi tertentu sebelum menghasilkan bytecode EVM.

Menggunakan via-IR dapat menghasilkan bytecode yang berbeda dari pipeline lama.

Artinya, kontrak harus diuji secara menyeluruh jika build berubah antara kompilasi non-via-IR dan via-IR.

Beberapa proyek menggunakan via-IR untuk meningkatkan hasil optimasi atau mendukung kebutuhan kompilasi yang kompleks.

Namun, mengubah pipeline kompilasi menjelang deployment dapat berisiko jika proyek belum menguji semua jalur.

Developer perlu menjaga pengaturan via-IR tetap konsisten dalam pengembangan lokal, pengujian, audit, deployment, dan verifikasi.

Auditor perlu mengetahui apakah via-IR diaktifkan karena dapat mengubah bytecode dan terkadang perilaku gas.

Bagi pengguna, via-IR sebagian besar tidak terlihat, tetapi penting bagi build yang dapat direproduksi dan verifikasi.

Praktik paling aman adalah memperlakukan pipeline compiler sebagai bagian dari konfigurasi produksi kontrak.

Versi EVM

Pengaturan versi EVM memberi tahu solc aturan dan fitur Ethereum Virtual Machine mana yang harus ditargetkan.

Catatan rilis Solidity dapat mengubah versi EVM default ketika upgrade jaringan Ethereum memperkenalkan opcode atau perilaku baru.

Catatan rilis Solidity untuk Solidity 0.8.30 menjelaskan bahwa versi EVM default berubah dari Cancun menjadi Prague untuk upgrade jaringan Ethereum Pectra.

Hal ini penting karena bytecode yang menargetkan versi EVM lebih baru dapat menggunakan instruksi yang tidak didukung jaringan lama.

Jika developer melakukan deployment ke chain yang tidak mendukung versi EVM terpilih, kontrak dapat gagal atau berperilaku tidak terduga.

Developer yang membangun untuk beberapa jaringan kompatibel EVM perlu memverifikasi fitur EVM yang didukung masing-masing jaringan.

Versi EVM harus dicatat bersama versi compiler dan pengaturan optimizer.

Kontrak terverifikasi dapat gagal cocok jika versi EVM yang salah digunakan saat verifikasi.

Bagi pengguna kripto, versi EVM adalah bagian tersembunyi tetapi penting dari keamanan deployment kontrak.

Bagi developer, ini adalah pengaturan yang tidak boleh ditebak.

Import dan Remapping

Proyek Solidity sering menggunakan import untuk memakai kembali interface, library, dan modul kontrak bersama.

Solc harus menyelesaikan import tersebut sebelum dapat mengompilasi kontrak secara penuh.

Remapping memberi tahu compiler cara memetakan jalur import ke direktori lokal atau direktori dependensi.

Hal ini umum pada proyek yang menggunakan package manager atau framework smart contract.

Penyelesaian import penting karena kompilasi dengan versi dependensi yang salah dapat menghasilkan bytecode berbeda atau perilaku tidak aman.

Proyek dapat terlihat benar dalam file kontrak utama, tetapi diam-diam bergantung pada library yang diimpor dan berbeda dari yang diharapkan.

Developer perlu mengunci versi dependensi dan meninjau kode yang diimpor dengan cermat.

Auditor perlu memeriksa seluruh pohon dependensi, bukan hanya file sumber utama.

Pengguna yang meninjau kontrak terverifikasi perlu mengingat bahwa file yang diimpor merupakan bagian dari source code yang diverifikasi.

File utama yang rapi tidak menjadikan kontrak aman jika dependensi yang diimpor berbahaya atau usang.

Library dan Linking

Library Solidity dapat dikompilasi dan di-link ke dalam deployment kontrak.

Beberapa library disematkan langsung ke dalam bytecode, sedangkan library eksternal dapat memerlukan linking alamat.

Dokumentasi compiler Solidity memperingatkan bahwa linking manual setelah kompilasi dapat memengaruhi metadata dan kecocokan bytecode.

Hal ini penting karena verifikasi dapat gagal jika alamat library tidak dicatat dengan benar.

Hal ini juga penting karena penggunaan alamat library yang salah dapat menyebabkan kontrak yang di-deploy memanggil kode yang tidak diharapkan.

Linking library harus ditangani oleh alat build dan deployment yang andal.

Developer perlu mencatat alamat library yang digunakan saat deployment.

Auditor perlu memverifikasi bahwa library yang di-link cocok dengan source code yang telah ditinjau.

Pengguna perlu memeriksa apakah kontrak terverifikasi bergantung pada library eksternal.

Keamanan kontrak dapat bergantung pada bytecode kontraknya sendiri dan bytecode library yang di-link.

Verifikasi Source Code

Verifikasi source code adalah proses untuk membuktikan bahwa source code yang dipublikasikan dikompilasi menjadi bytecode yang di-deploy di blockchain.

Dokumentasi verifikasi Ethereum menjelaskan bahwa verifikasi membandingkan source code smart contract dan bytecode hasil kompilasi yang digunakan saat pembuatan kontrak.

Untuk memverifikasi kontrak, verifier biasanya memerlukan file sumber yang tepat, versi compiler, pengaturan optimizer, argumen constructor, alamat library, versi EVM, dan pengaturan terkait metadata.

Jika salah satu input ini berbeda, bytecode hasil kompilasi mungkin tidak cocok dengan bytecode yang di-deploy.

Source code terverifikasi membantu pengguna membaca apa yang seharusnya dilakukan kontrak.

Verifikasi juga membantu wallet, explorer, auditor, dan peneliti mendekode transaksi serta event.

Namun, source code terverifikasi tidak berarti kontrak aman atau telah diaudit.

Verifikasi hanya berarti source code dan pengaturan yang dipublikasikan tampak cocok dengan bytecode yang di-deploy.

Pengguna perlu memperlakukan verifikasi sebagai langkah transparansi minimum.

Peninjauan keamanan tetap memerlukan pemahaman mengenai kode, desain, izin, kemampuan upgrade, dan risiko ekonomi.

Bug Compiler

Compiler adalah perangkat lunak, dan perangkat lunak dapat mengandung bug.

Dokumentasi bug Solidity yang diketahui resmi melacak bug compiler yang diketahui dan versi yang terdampak.

Hal ini penting karena smart contract dapat ditulis dengan benar pada level source code, tetapi tetap terdampak bug compiler pada versi atau pengaturan tertentu.

Bug compiler biasanya jarang dibandingkan bug smart contract pada level aplikasi, tetapi dampaknya dapat serius.

Developer perlu memeriksa apakah versi compiler yang dipilih memiliki bug serius yang diketahui.

Tim juga perlu menggunakan versi compiler stabil terbaru jika praktis dan setelah pengujian yang tepat.

Auditor perlu memasukkan peninjauan versi compiler dalam proses audit.

Alat verifikasi juga dapat memperingatkan ketika kontrak dikompilasi dengan versi yang terdampak masalah yang diketahui.

Menggunakan versi compiler lama tanpa alasan dapat meningkatkan risiko.

Proses pengembangan yang aman memperlakukan compiler sebagai bagian dari codebase tepercaya.

Peringatan dan Error

Solc melaporkan error ketika kode tidak dapat dikompilasi secara aman berdasarkan aturan bahasa.

Solc melaporkan peringatan ketika kode dapat dikompilasi, tetapi mungkin mengandung perilaku berisiko, usang, membingungkan, atau tidak disengaja.

Developer tidak boleh mengabaikan peringatan compiler dalam proyek produksi.

Peringatan dapat mengungkap variabel tidak digunakan, deklarasi yang tertutupi, pengenal SPDX yang hilang, saran mutabilitas, fitur usang, atau pola berbahaya.

Beberapa peringatan bersifat kecil, tetapi yang lain dapat menunjukkan bug nyata atau logika yang membingungkan.

Sistem build produksi perlu memperlakukan peringatan serius sebagai masalah yang memerlukan peninjauan.

Auditor sering memeriksa peringatan compiler karena peringatan dapat mengungkap asumsi yang terlewat oleh developer.

Pengguna biasanya tidak dapat melihat semua peringatan dari kontrak yang di-deploy kecuali output build dipublikasikan.

Ini adalah salah satu alasan proyek open-source perlu memublikasikan artefak build jika memungkinkan.

Kompilasi yang bersih tidak membuktikan keamanan, tetapi peringatan yang diabaikan adalah tanda buruk.

Estimasi Gas

Solc dapat menghasilkan estimasi gas untuk beberapa fungsi dan output deployment.

Dokumentasi compiler Solidity memasukkan estimasi gas sebagai salah satu kemungkinan output compiler.

Estimasi gas dapat membantu developer memahami biaya deployment atau pemanggilan kontrak.

Namun, estimasi mungkin tidak sepenuhnya mencerminkan kondisi jaringan nyata atau semua jalur runtime.

Penggunaan gas aktual dapat bergantung pada nilai storage, ukuran input, jalur branch, pemanggilan eksternal, akses akun cold dan warm, serta aturan jaringan.

Developer perlu menguji perilaku gas dengan kasus pengujian realistis dan tidak hanya mengandalkan estimasi compiler.

Gas penting dalam kripto karena fungsi yang mahal dapat mengganggu pengalaman pengguna atau membuat tindakan protokol penting tidak praktis saat terjadi kemacetan.

Kode yang membutuhkan banyak gas juga dapat meningkatkan biaya deployment dan tekanan ukuran kontrak.

Optimizer dapat mengurangi gas dalam beberapa kasus, tetapi juga dapat mengubah pertukaran antara biaya deployment dan runtime.

Peninjauan gas harus menjadi bagian dari analisis engineering dan keamanan.

Storage Layout

Storage layout menjelaskan cara variabel status disusun dalam slot storage kontrak.

Solc dapat menghasilkan informasi storage layout untuk kontrak.

Hal ini sangat penting bagi smart contract yang dapat di-upgrade.

Jika proyek meng-upgrade logika implementasi tetapi mengubah storage layout secara salah, kontrak dapat mengalami kerusakan status.

Kerusakan storage dapat merusak saldo, kepemilikan, pengaturan governance, akuntansi token, atau kontrol akses.

Developer perlu menjaga kompatibilitas storage layout saat menggunakan pola upgrade berbasis proxy.

Auditor perlu meninjau output storage layout dan rencana upgrade secara bersama-sama.

Pengguna perlu berhati-hati dengan kontrak yang dapat di-upgrade karena proxy yang di-deploy dapat kemudian menunjuk ke bytecode implementasi baru.

Solc sendiri tidak mencegah setiap desain upgrade yang buruk.

Solc menyediakan output yang dapat digunakan developer dengan cermat untuk mengurangi risiko upgrade.

Ukuran Kontrak

Output solc dapat membantu developer memantau ukuran bytecode kontrak.

Jaringan EVM sering menerapkan ukuran kontrak maksimum untuk bytecode runtime yang di-deploy.

Kontrak besar dapat gagal di-deploy jika melampaui batas ukuran.

Optimizer terkadang dapat mengurangi ukuran bytecode dengan menghilangkan redundansi dan menyederhanakan kode.

Developer juga dapat membagi sistem besar ke beberapa kontrak, library, atau modul.

Ukuran kontrak penting karena kontrak yang terlalu kompleks dapat lebih sulit diaudit dan lebih mahal untuk di-deploy.

Kontrak yang lebih kecil tidak otomatis lebih aman, tetapi kompleksitas yang tidak perlu meningkatkan kesulitan peninjauan.

Solc membantu menampilkan ukuran kode sebelum deployment.

Sistem build perlu gagal lebih awal jika ukuran bytecode terlalu besar untuk jaringan target.

Memantau ukuran bytecode merupakan bagian dari engineering smart contract profesional.

Solc dalam Framework Pengembangan

Banyak developer smart contract tidak menjalankan solc secara manual untuk setiap build.

Mereka menggunakan framework yang memanggil solc di balik layar.

Alat ini dapat mengelola struktur proyek, dependensi, kompilasi, pengujian, deployment, dan verifikasi.

Bahkan ketika framework menyembunyikan perintah compiler langsung, pengaturan solc tetap penting.

Framework harus memilih versi compiler, pengaturan optimizer, versi EVM, jalur import, dan opsi output.

Developer yang tidak memahami pengaturan ini dapat tanpa sengaja melakukan deployment bytecode yang berbeda dari build yang diaudit.

Tim perlu melakukan commit pada file konfigurasi compiler ke version control.

Mereka juga perlu membuat deployment dapat direproduksi dari lingkungan yang bersih.

Auditor perlu meninjau pengaturan compiler framework sebagai bagian dari codebase.

Solc mungkin tersembunyi dalam alur kerja, tetapi tetap merupakan alat yang menghasilkan bytecode akhir.

solc-js

Solc-js adalah versi atau wrapper JavaScript dari Solidity compiler yang digunakan dalam banyak alur kerja web dan Node.js.

Dokumentasi instalasi Solidity resmi menjelaskan berbagai cara untuk menginstal compiler command-line dan paket compiler.

Solc-js berguna untuk alat berbasis browser, sistem build JavaScript, compiler online, dan alur kerja verifikasi kontrak otomatis.

Developer tetap perlu memeriksa versi compiler yang digunakan solc-js.

Menggunakan paket JavaScript tidak menghilangkan kebutuhan untuk mengunci versi dan pengaturan.

Lingkungan berbeda dapat secara tidak sengaja menyelesaikan build compiler yang berbeda jika versi dependensi longgar.

Hal ini dapat merusak reproduktibilitas dan verifikasi.

Untuk kontrak produksi, build compiler yang tepat harus diketahui dan dicatat.

Solc-js memang praktis, tetapi kemudahan tidak menggantikan build deterministik.

Artefak compiler harus cocok persis dengan artefak deployment.

Peran Keamanan solc

Solc bukan auditor keamanan, tetapi memainkan peran penting dalam keamanan smart contract.

Compiler menerapkan aturan bahasa, melaporkan peringatan, menghasilkan bytecode, dan dapat menghasilkan informasi yang berguna untuk analisis.

Solc dapat mendeteksi error sintaks, error tipe, peringatan kode yang tidak dapat dijangkau, dan beberapa pola berbahaya.

Namun, solc tidak dapat membuktikan bahwa desain ekonomi suatu protokol aman.

Solc tidak dapat menjamin bahwa kontrol akses sudah benar.

Solc tidak dapat menjamin bahwa governance upgrade dapat dipercaya.

Solc tidak dapat menjamin bahwa desain oracle, logika likuidasi, atau tokenomics aman.

Keamanan tetap memerlukan pengujian, audit, metode formal jika sesuai, threat modeling, pemantauan, dan prosedur deployment yang cermat.

Karya akademik seperti paper analisis statis Slither menunjukkan bagaimana alat tambahan dapat menganalisis smart contract di luar kompilasi dasar.

Solc adalah fondasi proses build, tetapi perlu menjadi bagian dari alur kerja keamanan yang lebih luas.

Output solc Umum

Output solc yang paling umum adalah bytecode kontrak.

Output umum lainnya adalah ABI.

Metadata juga umum dihasilkan untuk verifikasi dan tooling.

Estimasi gas dapat membantu developer memahami perkiraan biaya eksekusi.

Storage layout dapat membantu developer mengelola kontrak yang dapat di-upgrade.

Abstract syntax tree dapat membantu alat analisis memahami struktur source code.

Output representasi perantara dapat membantu developer tingkat lanjut memeriksa transformasi compiler.

Output assembly dapat membantu optimasi dan debugging mendalam.

Output error dan peringatan membantu developer memperbaiki kode sebelum deployment.

Output ini menjadikan solc berguna bukan hanya untuk deployment, tetapi juga untuk audit, pengujian, verifikasi, dokumentasi, dan analitik.

Kesalahan Umum dengan solc

Satu kesalahan umum adalah melakukan kompilasi dengan versi compiler yang berbeda dari versi yang digunakan saat audit.

Kesalahan lainnya adalah mengubah pengaturan optimizer setelah pengujian selesai.

Kesalahan ketiga adalah melakukan deployment bytecode tanpa mencatat input compiler yang tepat.

Kesalahan keempat adalah menggunakan pragma luas dan mengasumsikan setiap versi compiler yang kompatibel menghasilkan output yang identik.

Kesalahan kelima adalah mengabaikan peringatan compiler.

Kesalahan keenam adalah menargetkan versi EVM yang salah untuk jaringan deployment.

Kesalahan ketujuh adalah melakukan linking library secara manual dan merusak verifikasi berbasis metadata.

Kesalahan kedelapan adalah tidak menyertakan semua file import saat verifikasi.

Kesalahan kesembilan adalah menganggap source code terverifikasi berarti source code telah diaudit.

Kesalahan kesepuluh adalah meningkatkan compiler tepat sebelum deployment tanpa pengujian penuh.

Cara Pengguna Membaca Informasi solc di Explorer

Pengguna sering dapat menemukan informasi compiler pada halaman kontrak terverifikasi di blockchain explorer.

Informasi ini dapat mencakup versi compiler, status optimasi, optimizer runs, versi EVM, pengenal lisensi, argumen constructor, dan file sumber terverifikasi.

Pengguna perlu memeriksa apakah kontrak terverifikasi sebelum mempercayai tampilan source code.

Jika kontrak tidak terverifikasi, pengguna mungkin hanya melihat bytecode dan informasi yang didekode secara terbatas.

Jika kontrak terverifikasi, pengguna dapat memeriksa source code dan ABI dengan lebih mudah.

Pengguna tetap perlu mengingat bahwa kode terverifikasi dapat mengandung bug, backdoor, izin admin, kemampuan upgrade, atau logika ekonomi berisiko.

Informasi compiler membantu menjawab apakah kode yang terlihat cocok dengan bytecode yang di-deploy.

Informasi tersebut tidak menjawab apakah kode aman digunakan.

Untuk interaksi bernilai tinggi, pengguna juga perlu meninjau audit, izin, timelock, kontrol upgrade, dan dokumentasi proyek.

Data solc adalah salah satu bagian dari due diligence kontrak.

Praktik Terbaik untuk Developer

Kunci versi solc yang tepat untuk build produksi.

Lakukan commit pada pengaturan compiler ke version control.

Gunakan lingkungan build yang dapat direproduksi untuk pengujian, audit, deployment, dan verifikasi.

Tinjau catatan rilis Solidity sebelum mengubah versi compiler.

Periksa bug compiler yang diketahui untuk versi yang dipilih.

Jaga pengaturan optimizer tetap konsisten setelah audit dimulai.

Tetapkan versi EVM yang tepat untuk jaringan target.

Simpan artefak input dan output Standard JSON untuk kontrak yang di-deploy.

Verifikasi kontrak setelah deployment menggunakan source code dan pengaturan yang tepat.

Perlakukan peringatan compiler sebagai item yang perlu ditinjau, bukan gangguan yang tidak berbahaya.

Praktik Terbaik untuk Pengguna

Periksa apakah kontrak telah terverifikasi source code-nya sebelum berinteraksi dengannya.

Tinjau versi dan pengaturan compiler saat tersedia.

Ingat bahwa source code terverifikasi tidak sama dengan source code yang diaudit.

Berhati-hatilah terhadap kontrak tidak terverifikasi yang meminta persetujuan token atau deposit aset.

Periksa apakah kontrak menggunakan proxy yang dapat di-upgrade atau library yang di-link.

Tinjau apakah ABI cocok dengan fungsi yang diminta antarmuka untuk Anda panggil.

Berhati-hatilah ketika situs web meminta Anda menandatangani transaksi untuk kontrak yang tidak dapat diperiksa.

Gunakan wallet tepercaya yang menampilkan pemanggilan kontrak dan data fungsi yang telah didekode jika memungkinkan.

Untuk transaksi besar, bandingkan dokumentasi resmi proyek dengan alamat kontrak terverifikasi.

Jangan memperlakukan metadata compiler sebagai jaminan keamanan atau nilai di masa depan.

FAQ

Apa arti solc?

Solc berarti Solidity Compiler, yaitu compiler yang mengubah source code Solidity menjadi bytecode EVM, data ABI, metadata, dan output build smart contract lainnya.

Apakah solc sama dengan Solidity?

Tidak, Solidity adalah bahasa pemrograman, sedangkan solc adalah compiler yang memproses kode Solidity.

Apa yang dihasilkan solc?

Solc dapat menghasilkan bytecode, bytecode yang di-deploy, data ABI, metadata, estimasi gas, storage layout, abstract syntax tree, assembly, representasi perantara, error, dan peringatan.

Mengapa versi solc penting?

Versi solc penting karena versi compiler yang berbeda dapat mendukung fitur bahasa, peringatan, perbaikan bug, default EVM, dan output bytecode yang berbeda.

Apa itu bytecode dalam kompilasi Solidity?

Bytecode adalah kode tingkat rendah yang dihasilkan solc dan dapat dieksekusi oleh Ethereum Virtual Machine.

Apa itu ABI dalam kompilasi Solidity?

ABI adalah deskripsi antarmuka yang memberi tahu wallet, skrip, dan aplikasi cara mengodekan pemanggilan serta mendekode respons dari smart contract.

Apakah solc membuat smart contract aman?

Tidak, solc menerapkan aturan bahasa dan menghasilkan bytecode, tetapi keamanan smart contract tetap memerlukan pengujian, audit, threat modeling, dan desain yang cermat.

Apa itu optimizer di solc?

Optimizer adalah fitur compiler yang berupaya mengurangi ukuran kode, biaya deployment, atau biaya gas runtime berdasarkan pengaturan dan pola penggunaan.

Apa itu Standard JSON di solc?

Standard JSON adalah format input dan output compiler terstruktur yang digunakan untuk kompilasi otomatis yang andal, artefak build, dan verifikasi kontrak.

Mengapa verifikasi kontrak memerlukan pengaturan solc?

Verifikasi kontrak memerlukan pengaturan solc karena source code harus dikompilasi menggunakan versi, pengaturan optimizer, library, versi EVM, dan pengaturan metadata yang sama agar cocok dengan bytecode yang di-deploy.

Kesimpulan

Solidity Compiler, atau solc, adalah salah satu alat terpenting dalam pengembangan smart contract Ethereum.

Solc mengubah source code Solidity menjadi bytecode EVM, data ABI, metadata, storage layout, estimasi gas, dan output lain yang diandalkan developer, auditor, wallet, dan explorer.

Pengaturan solc sangat penting karena versi compiler, opsi optimizer, versi EVM, linking library, import, metadata, dan pilihan pipeline kompilasi dapat memengaruhi bytecode akhir yang di-deploy.

Bagi developer, solc harus diperlakukan sebagai bagian dari batas keamanan produksi, bukan sekadar alat build di latar belakang.

Bagi pengguna, informasi solc membantu menjelaskan mengapa source code terverifikasi, pengaturan compiler, dan kecocokan bytecode penting sebelum berinteraksi dengan smart contract.

Namun, kompilasi dan verifikasi tidak menjamin kontrak aman, adil, diaudit, atau memiliki kondisi ekonomi yang sehat.

Kontrak terverifikasi tetap dapat mengandung bug, kontrol admin berisiko, jalur upgrade, tokenomics buruk, atau logika berbahaya.

Praktik smart contract yang baik menggabungkan kompilasi yang benar dengan pengujian, audit, build yang dapat direproduksi, deployment aman, pemantauan, dan verifikasi transparan.

Bagi pemula, solc paling tepat dipahami sebagai alat yang mengubah Solidity menjadi kode yang dapat dieksekusi blockchain.

Bagi pengguna tingkat lanjut, solc adalah komponen sistem build deterministik yang secara langsung memengaruhi bytecode, verifikasi, perilaku gas, keamanan storage, dan keandalan deployment.

Dalam konteks glosarium kripto, Solidity Compiler (solc) berarti alat kompilasi Solidity resmi yang digunakan untuk mengubah source code smart contract menjadi artefak EVM yang dapat di-deploy dan diverifikasi.

Poin utamanya, solc adalah jembatan antara kode smart contract yang ditulis manusia dan bytecode yang benar-benar berjalan di blockchain, sehingga versi, pengaturan, dan outputnya harus ditangani dengan presisi.