Pengembang Inti Ethereum Classic – Seri Pengembangan Olympia (Bagian Pertama)
Mengimplementasikan ECIP-1111 dan ECIP-1112: Pengalihan Biaya Dasar dan Vault yang Tidak Dapat Diubah
1. Pendahuluan – Dari Konsep ke Kode
Bagian ini memberikan gambaran umum tentang arsitektur Olympia secara keseluruhan: tujuannya, perjalanan pengembangannya, dan bagaimana ECIP 1111-1115 masuk ke dalam jalur peningkatan berlapis modular. Tulisan ini akan menyelami lebih dalam praktik teknikal saat ini untuk dua ECIP, yang bersama-sama mendefinisikan batas konsensus Olympia:
ECIP-1111 – Peningkatan EVM dan Protokol
ECIP-1112 – Kontrak Vault yang Tidak Dapat Diubah
Kedua proposal ini adalah satu-satunya komponen dalam kerangka Olympia yang memodifikasi perilaku konsensus. Bagian lain dalam kerangka – tata kelola (ECIP-1113), proposal pendanaan (ECIP-1114), dan mekanisme pelicinan opsional (ECIP-1115) – semuanya beroperasi di lapisan kontrak, tidak memengaruhi validitas blok atau pemilihan fork. Pada 11 November 2025, Pengembang Inti Ethereum Classic memulai fase implementasi, mempersiapkan logika konsensus dan infrastruktur klien referensi untuk potensi penerapan di testnet Mordor.
Ringkasan artikel ini:
Apa yang diperkenalkan oleh ECIP-1111
Bagaimana ECIP-1112 mendefinisikan alamat target vault
Bagaimana komponen-komponen ini bekerja sama
Apa yang sedang diprototipekan dalam pengembangan klien referensi saat ini
Artikel ini hanya menggambarkan desain dan pekerjaan implementasi, dan tidak menandakan bahwa ini akan diaktifkan atau diadopsi di masa depan melalui proses ECIP-1000. Sebelum menerapkan perubahan lapisan konsensus ECIP-1111 atau ECIP-1112 ke Mordor atau mainnet, klien ETC harus terlebih dahulu memvalidasi stabilitas dan kompatibilitasnya dalam kondisi baseline.
2. ECIP-1111 – Mekanisme Biaya Modern, Minimalisasi Gangguan Jaringan
ECIP-1111 mengintegrasikan dua peningkatan EVM yang telah banyak diadopsi:
Mekanisme biaya ala EIP-1559 (Biaya Dasar + Tip Opsional) Mekanisme ini memperkenalkan:
Biaya Dasar (BASEFEE) yang disesuaikan secara dinamis,
Biaya prioritas tinggi opsional (tip) yang masih dibayarkan langsung ke penambang
serta pasar biaya yang lebih dapat diprediksi untuk alat-alat modern.
2. Dukungan untuk transaksi Tipe-2 (ala 1559): Fitur ini telah menjadi standar bagi sebagian besar dompet dan infrastruktur.
3. Opcode BASEFEE (0x48): Fitur ini memaparkan BASEFEE blok saat ini ke logika kontrak (penaksir gas, router DEX, rantai alat, dll.).
Apa yang Berubah di Ethereum Classic (ETC)?
Hanya ada satu perilaku yang berbeda dengan Ethereum mainnet:
Yayasan Ethereum (ETH): BASEFEE dihancurkan.
Ethereum Classic (ETC): BASEFEE dialihkan ke vault yang didefinisikan oleh ECIP-1112. Semantik EIP-1559 lainnya tetap tidak berubah.
Apa yang Tetap Sama?
Tip penambang tetap sama.
Hadiah blok tetap tidak berubah.
Kebijakan moneter (ECIP-1017) tetap tidak berubah.
Tipe transaksi tradisional (Tipe-0 dan Tipe-1) sepenuhnya valid.
Kontrak yang ada tidak akan terputus; aplikasi yang ada tidak perlu dimodifikasi.
Tidak memperkenalkan asumsi kepercayaan tambahan atau mekanisme izin.
ECIP-1111 bersifat tambahan, minimalis, dan secara ketat terbatas pada mekanisme biaya modern dan mengaktifkan fungsi pengalihan BASEFEE.
3. ECIP-1112 – Vault Deterministik yang Tidak Dapat Diubah
ECIP-1112 mendefinisikan alamat penerima biaya dasar yang dialihkan: sebuah kontrak pintar minimalis dan tidak dapat diubah yang diterapkan pada alamat deterministik. Definisi ini masih bersifat teoretis hingga perangkat lunak klien menunjukkan perilaku yang konsisten dalam lingkungan multi-klien, sebuah pencapaian yang memerlukan pengujian menyeluruh sebelum komponen Olympia dapat dinilai dengan aman.
Fitur Inti
Tidak Dapat Diubah: Tidak ada kunci peningkatan, tidak ada administrator, tidak ada pola proksi.
Alamat Deterministik (misalnya, melalui CREATE2): Semua klien menyetujui tujuan vault yang sama.
Hanya Menerima saat Diaktifkan: Vault dapat mengakumulasi nilai, tetapi tidak dapat melepaskan dana hingga tata kelola berikutnya diaktifkan.
Tidak Ada Logika Tata Kelola Internal: Murni berfungsi sebagai lapisan penampung, bukan lapisan pengambilan keputusan.
Saat diaktifkan (testnet atau mainnet):
Vault hanya dapat menerima dana.
Mekanisme penarikan apa pun tidak akan diaktifkan hingga ECIP-1113 dan ECIP-1114 diterapkan, diaudit, dan sengaja diaktifkan. Pemisahan ini memastikan prediktabilitas peningkatan konsensus dan membuatnya independen dari implementasi skema tata kelola masa depan.
4. Batas Konsensus yang Jelas
Meskipun Olympia mencakup lima proposal ECIP, hanya ECIP-1111 dan ECIP-1112 yang mengubah perilaku konsensus.
Ringkasan Batas Konsensus
ECIP-1111 — Lapisan Protokol. Memperkenalkan perubahan konsensus: mekanisme biaya dasar baru, transaksi tipe-2, dan opcode biaya dasar.
ECIP-1112 — Lapisan Protokol/Kontrak. Memperkenalkan perubahan konsensus: mendefinisikan alamat penerima vault deterministik untuk biaya dasar yang dialihkan.
ECIP-1113 — Lapisan Kontrak/Aplikasi. Tidak ada perubahan konsensus.
ECIP-1114 — Lapisan Kontrak/Aplikasi. Tidak ada perubahan konsensus.
ECIP-1115 — Lapisan Kontrak/Aplikasi. Tidak ada perubahan konsensus.
Struktur modular ini memastikan:
Logika kritis konsensus tetap ramping dan dapat diaudit,
Mekanisme tata kelola dan pendanaan dapat berevolusi di lapisan kontrak,
Peningkatan pada ECIP-1113 hingga 1115 tidak memerlukan perubahan konsensus tambahan.
Jika diadopsi, klien yang mengimplementasikan ECIP-1111 dan ECIP-1112 akan menjaga kompatibilitas konsensus, terlepas dari penerapan lapisan tata kelola berikutnya. Implementasi referensi dapat memulai prototipe logika konsensus pada tahap draf, tetapi perubahan ini harus melalui pengujian menyeluruh (termasuk validasi klien baseline seperti verifikasi Gorgoroth yang dijelaskan di Bagian Dua) sebelum digabungkan ke dalam klien produksi.
5. Mengapa Aktivasi Tata Kelola Ditunda
Jika ECIP-1111 dan ECIP-1112 diaktifkan, biaya dasar akan mulai mengalir ke vault — tetapi pengeluaran vault akan tetap dinonaktifkan.
Mekanisme penerapan bertahap ini memungkinkan:
Pengujian independen biaya dasar
Audit menyeluruh terhadap ECIP-1113 dan ECIP-1114
Koordinasi presisi antara implementor klien dan penyedia infrastruktur
Prediktabilitas perilaku operator node
Jika kontrak tata kelola kemudian diaktifkan, vault akan terhubung sepenuhnya di lapisan kontrak (bukan lapisan konsensus) dengan pelaksana yang diberi wewenang.
6. Transaksi Tipe-2 dan Interoperabilitas EVM Jangka Panjang
Dukungan transaksi Tipe-2 sangat penting bagi Ethereum Classic untuk menjaga kompatibilitas, mencakup:
Dompet modern
Bursa dan layanan kustodian
Infrastruktur RPC
Kerangka kerja alat (Hardhat, Foundry, dll.)
Penjelajah blok
Interoperabilitas lintas rantai
Transaksi Tipe-2 tidak mengubah kebutuhan pengguna atau memperkenalkan mekanisme izin. Tipe transaksi tradisional akan tetap didukung sepenuhnya.
Tipe-2, sebagai fitur tambahan, memastikan ETC tetap dapat dioperasikan dengan format transaksi utama di ekosistem EVM.
7. Konteks yang Lebih Luas – Mempertahankan Lapisan Dasar Proof-of-Work yang Dapat Diprogram
ECIP-1111 dan ECIP-1112 bersama-sama merupakan langkah dasar menuju model operasi Proof-of-Work yang dapat diprogram dan didanai secara berkelanjutan untuk Ethereum Classic — dengan syarat komunitas memilih untuk mengadopsi proposal ini.
Skema ini mencapai tujuannya tanpa:
Memodifikasi insentif penambang
Memperkenalkan inflasi
Mengubah kebijakan moneter
Menambahkan lapisan tata kelola ke dalam konsensus
Mengubah asumsi keamanan Ethereum Classic
Tujuannya semata-mata untuk:
Memodernisasi pasar biaya
Membangun mekanisme atribusi nilai tingkat protokol yang transparan
Jika diadopsi, perubahan ini akan membuka jalan bagi sistem tata kelola dan pendanaan lapisan kontrak dalam proposal Olympia berikutnya, tanpa menambahkan aturan konsensus baru.
8. Kesimpulan – Minimalis, Aman, dan Kompatibel ke Depan
ECIP-1111 dan ECIP-1112 mendefinisikan komponen lapisan konsensus yang diusulkan dalam kerangka Olympia. Mereka:
Menambahkan mekanisme tipe-2 dan biaya dasar
Mengalihkan biaya dasar ke vault deterministik
Mempertahankan semua perilaku pengguna dan penambang yang ada tidak berubah
Mempersiapkan ETC untuk komponen lapisan kontrak masa depan
Skema ini tidak membawa logika tata kelola ke dalam mekanisme konsensus, juga tidak menambahkan asumsi kepercayaan baru di atas semantik EIP-1559/EIP-3198 yang ada. Tujuannya adalah untuk menjaga konservatisme protokol inti ETC dan kompatibilitas ekosistem EVM, sambil memungkinkan aliran nilai yang berkelanjutan di lapisan kontrak.
9. Kejelasan Prosedur ECIP
Spesifikasi ECIP Olympia (1111–1115) saat ini berada dalam tahap draf dan masih dalam diskusi aktif. Pekerjaan implementasi awal untuk ECIP-1111 dan ECIP-1112 telah dimulai pada klien referensi, yang sepenuhnya sesuai dengan ketentuan tahap draf ECIP-1000. Implementasi referensi akan dipertimbangkan untuk aktivasi mainnet hanya setelah pengujian di testnet Mordor selesai. Setelah hasil testnet memenuhi syarat, pengusul ECIP dapat mengajukan pembaruan spesifikasi. Keputusan apa pun untuk maju ke "status diterima" atau menjadwalkan aktivasi mainnet akan memerlukan tinjauan komunitas dan prosedur penilaian ECIP-1000 yang lengkap. Artikel ini menguraikan desain dan pekerjaan implementasi yang sedang berlangsung pada tahap draf.
10. Kelanjutan Seri
Dengan kerangka desain konsensus ditetapkan, edisi berikutnya akan berfokus pada lapisan klien – rencana pengujian alpha Fukuii akan segera dimulai, bertujuan untuk memvalidasi interoperabilitas klien ETC sebelum integrasi terkait Olympia.
Penafian: Konten ini bukan merupakan saran investasi atau keuangan apa pun. Konten dipinjam dari EthereumClassic, hanya untuk referensi informasi industri. Jika ada pertanyaan atau masalah hak cipta, silakan hubungi kami untuk penghapusan.
