Belajar Solidity - Solidity 0.8.36 & Fitur Terbaru

#Pendahuluan

Setelah di episode 15 kalian memahami kerentanan dan pola pertahanan, pada episode ini kita berhenti sejenak dari pola kontrak dan meninjau jalur rilis Solidity 0.8.x — khususnya versi terbaru 0.8.36 dan fitur-fitur yang menyertainya.

Mengapa episode ini penting? Karena versi Solidity bergerak cepat dan tiap rilis bisa membawa perbaikan keamanan atau perubahan perilaku yang memengaruhi kontrak produksi. Mengetahui apa yang berubah di tiap rilis — dan deprecation yang menandai arah 0.9.0 — akan membuat kalian tetap relevan dan aman di dunia kerja.

#Solidity 0.8.36 (9 Juli 2026)

Rilis stabil terbaru ini hadir dengan tiga hal utama:

• 2 perbaikan keamanan (severity medium) — perbaikan yang patut mendorong semua proyek untuk upgrade ke versi ini.
• Fitur eksperimental: SSA CFG stack-to-memory spilling — pendekatan baru untuk mengatasi error klasik "Stack too deep" (kehabisan slot stack EVM saat fungsi terlalu kompleks). Dengan mengorbankan sedikit gas, variabel di-spill ke memory sehingga kompilasi kontrak kompleks berhasil.
• Backend EOF eksperimental dihapus — karena proposal EOF ditolak di upgrade Fusaka, backend yang mengincarnya tidak lagi dikembangkan.

forge build --via-ir --experimental-specify-solc-version

Proyek yang memakai --via-ir bisa menguji fitur baru ini untuk kode yang selama ini terkena stack too deep.

#0.8.35 (29 April 2026): Builtin erc7201

• Builtin erc7201 — helper untuk menghitung storage namespace sesuai ERC-7201, memudahkan pengorganisasian slot storage pada kontrak upgradeable yang memakai namespace.
• Pengenalan siklus hidup flag --experimental yang lebih terstruktur — fitur eksperimental kini punya jalur yang jelas dari penambahan sampai stabilisasi/penghapusan.

// Menghitung lokasi slot namespace untuk modul tertentu
bytes32 constant LOCATION = erc7201("myproject.module");

#0.8.34 (18 Februari 2026): Bugfix Kritis

• Perbaikan bug high severity terkait lost storage array write — bug yang bisa membuat penulisan array ke storage tidak tercatat pada kondisi tertentu. Ini contoh klasik mengapa mengikuti changelog itu penting: bug di kompiler bisa memengaruhi perilaku semua kontrak yang meng-compile dengannya.

#0.8.31 (3 Desember 2025): Fondasi Upgrade Baru

• Support upgrade Fusaka dan default EVM menjadi osaka — kontrak baru dikompilasi menargetkan rule set EVM terbaru.
• ARM Linux builds resmi — memudahkan development di perangkat ARM (termasuk banyak laptop dan CI berbasis ARM).
• Dimulainya deprecations untuk 0.9.0 — tanda bahwa breaking release sudah di depan mata.

#Ringkasan Jalur Rilis

#Memverifikasi Versi Solidity

Selalu tahu versi compiler yang dipakai proyek kalian:

solc --version
forge --version
npx hardhat compile

solc --version menunjukkan versi global; forge --version versi Foundry yang membawa kompilernya sendiri; dan di Hardhat, versi dipilih lewat solidity di hardhat.config.js atau pragma di file kontrak.

#Mengelola Versi Compiler di Proyek

Ada tiga level pengaturan versi yang perlu kalian pahami:

#Pragma di File Kontrak

pragma menentukan batas versi yang boleh meng-compile file itu:

// Hanya tepat 0.8.36
pragma solidity 0.8.36;
 
// 0.8.36 ke atas, tetapi di bawah 0.9.0 (paling umum)
pragma solidity ^0.8.36;
 
// Rentang fleksibel
pragma solidity >=0.8.20 <0.9.0;

#Setting di Hardhat

Hardhat memilih versi kompiler dari konfigurasi:

module.exports = {
  solidity: {
    version: "0.8.36",
    settings: {
      optimizer: { enabled: true, runs: 200 },
    },
  },
};

#Di Foundry

Foundry mengambil versi dari foundry.toml:

[profile.default]
solc_version = "0.8.36"
optimizer = true
optimizer_runs = 200

Konsistensi penting: versi compiler dan setting optimizer saat deploy harus sama persis dengan saat verifikasi — itulah yang membuat kontrak kalian bisa diverifikasi di Etherscan/Sourcify (episode 17).

#Persiapan Menuju 0.9.0

Rilis 0.9.0 akan menjadi breaking release — beberapa perilaku lama akan dihapus. Tanda-tanda yang sudah mulai muncul sejak 0.8.31:

• Deprecation warnings untuk sintaks/pola lama di compile.
• Perilaku yang mengarah ke aturan baru (misal EVM osaka, block.slotnum di EIP-7843 — kita bahas di episode 20).

Strategi yang aman:

1. Jangan takut membaca warnings saat compile — itu peta jalan menuju 0.9.0.
2. Hindari menumpuk utang sintaks lama; refactor bertahap.
3. Upgrade ke 0.8.36 sekarang agar perbaikan keamanan langsung dinikmati, dan kontrak kalian berada di jalur paling mulus menuju 0.9.0.

#Penutup

Inti yang harus dibawa pulang:

• 0.8.36 (9 Jul 2026): 2 security fix medium, SSA stack-to-memory spilling eksperimental untuk stack too deep, dan EOF backend dihapus.
• 0.8.35: builtin erc7201; 0.8.34: perbaikan bug high severity.
• 0.8.31: support Fusaka, default EVM osaka, build ARM Linux, awal deprecation 0.9.0.
• Ikuti changelog, tes penuh sebelum upgrade, dan persiapkan migrasi menuju 0.9.0.

Di episode 17 selanjutnya kita akan membahas deployment & verification — deploy dengan forge create dan npx hardhat run, mengelola private key dan RPC via env variable, deploy ke testnet Sepolia, lalu verifikasi kontrak di Etherscan/Sourcify dengan metadata-nya. Sampai jumpa di episode 17!