
Tata Kelola Solana: Analisis Komprehensif
Daftar Isi
- Wawasan yang Dapat Ditindaklanjuti
- Pendahuluan
- Elemen Tata Kelola Solana
- Aktivasi Feature Gate
- Solana Improvement Documents (SIMD)
- Pemungutan Suara Tata Kelola
- Batas Tata Kelola On-Chain
- Analisis Pemungutan Suara Tata Kelola
- Tata Kelola Awal Solana: 2020–2022
- Tata Kelola Solana Saat Ini: 2023 dan Seterusnya
- Pemungutan Suara Konsultatif Awal
- Pola Pemungutan Suara Tata Kelola
- Tingkat Partisipasi
- Masalah dan Rekomendasi
- Kurangnya Partisipasi Staker
- Tantangan dalam Diskursus Tata Kelola
- Penggabungan Proposal Tata Kelola
- Kuorum Pemungutan Suara
- Dampak SFDP
- Kejelasan Kriteria Pelaksanaan Pemungutan Suara
- Masalah Keamanan
- Perbandingan dengan Jaringan Alternatif
- Cosmos
- Ethereum
- Kesimpulan
- Sumber Daya Tambahan
Wawasan yang Dapat Ditindaklanjuti
- Pemungutan suara tata kelola di Solana tidak mengikat dan bersifat konsultatif, serta berfungsi sebagai sinyal sentimen komunitas. Dengan memungkinkan validator menyampaikan sikap sebelum implementasi penuh, proses ini membantu mengarahkan pengembangan dan meminimalkan perselisihan. Keputusan akhir terjadi saat validator memilih perangkat lunak yang akan dijalankan. Proposal dapat berubah bahkan setelah pemungutan suara, dan pada akhirnya tata kelola mencerminkan konsensus, bukan pemaksaan.
- Pemegang token SOL berpartisipasi secara tidak langsung dengan mendelegasikan SOL yang mereka staking kepada validator yang pilihan suaranya selaras dengan nilai atau preferensi mereka. Ini merupakan sistem perwakilan proporsional, dengan validator dapat dianggap sebagai wakil terpilih. Staker Solana mendelegasikan stake mereka kepada validator, dan kekuatan suara setiap validator didasarkan pada stake yang didelegasikan kepadanya.
- Pemungutan suara tata kelola Solana dilakukan menggunakan token SPL. Validator menerima alokasi token yang proporsional dengan stake aktif dan mengirimkan token tersebut ke alamat tertentu yang mewakili berbagai opsi suara. Validator bebas membagi suara mereka ke beberapa opsi. Setelah dikirimkan, suara bersifat final dan tidak dapat diubah.
- Semua pembaruan protokol yang memutus konsensus diaktifkan melalui feature gate, yaitu hard fork yang tidak kompatibel dengan versi sebelumnya. Berbeda dengan Bitcoin atau Ethereum, yang hard fork-nya dapat mengakibatkan pemisahan chain permanen jika terjadi ketidaksepakatan, pendekatan Solana memastikan feature gate diaktifkan di seluruh cluster pada slot tertentu. Validator melakukan upgrade terlebih dahulu sehingga pemisahan chain dapat dicegah.
- Beberapa perubahan ekonomi pada tahap awal pengembangan Solana—terutama penerapan priority fee dengan burn 50%—diterapkan tanpa pemungutan suara tata kelola formal karena sistem tata kelola saat itu masih belum matang.
- Model pemungutan suara tata kelola saat ini—hanya validator yang memberikan suara—ditetapkan setelah pemungutan suara konsultatif pada Oktober 2023. Lebih dari 170 validator berpartisipasi, mewakili 14,3% dari total stake, dan lebih dari 70% stake tersebut memilih pemungutan suara khusus validator sebagai titik awal yang paling praktis dan efisien.
- Pemungutan suara terbaru untuk SIMD-228 mencapai rekor tingkat partisipasi sebesar 74,3%, menjadikannya peristiwa tata kelola blockchain terbesar dalam sejarah berdasarkan jumlah peserta dan kapitalisasi pasar, dengan 281 juta SOL (~$35 miliar) dan lebih dari 900 validator memberikan lebih dari 1.000 suara. Pemungutan suara ini menandai partisipasi aktif pertama dari validator bursa besar seperti Coinbase, Kraken, dan Bybit, yang menunjukkan meningkatnya keterlibatan institusional di Solana.
- Salah satu kekhawatiran yang terus muncul dalam proses tata kelola Solana adalah terbatasnya peran delegator dalam pengambilan keputusan. Saat ini tidak ada mekanisme formal bagi delegator untuk menyampaikan preferensi atau membatalkan keputusan validator, sehingga suara validator dapat bertentangan dengan preferensi delegator mereka.
- Peran kuorum yang ditetapkan dalam pemungutan suara tata kelola Solana juga menimbulkan kekhawatiran. Dalam praktiknya, kuorum dapat menciptakan insentif yang menyimpang karena peserta secara strategis menahan suara agar proposal tidak mencapai ambang batas yang diperlukan. Hal ini terlihat dalam pola pemungutan suara SIMD-228.
- Solana Foundation Delegation Program mendelegasikan 10% dari total SOL yang di-staking (41,01 juta) kepada 897 validator, sehingga memperbesar kekuatan suara mereka. Analisis terhadap pemungutan suara SIMD-288 terbaru menunjukkan bahwa stake SFDP terutama digunakan untuk menolak proposal. Jika stake ini memilih YA, proposal tersebut akan disetujui. Jika stake yang didelegasikan SFDP abstain, proposal tetap akan gagal, tetapi dengan selisih yang lebih kecil—64,77% dibandingkan hasil aktual sebesar 61,39%.
- Masih ada ketidakpastian mengenai hal yang memenuhi syarat untuk menjalani pemungutan suara tata kelola. Pada Maret 2025, rencana pemungutan suara untuk SIMD-218 (IVC) dibatalkan setelah tercapai konsensus bahwa proposal tersebut tidak memerlukan persetujuan tata kelola. Demikian pula, meskipun disetujui, SIMD-123 tidak jelas merupakan perubahan ekonomi dan dapat dikatakan tidak memerlukan pemungutan suara formal.
Pendahuluan
Tata kelola merupakan komponen penting dalam desentralisasi yang memengaruhi segala hal, mulai dari upgrade protokol dan kebijakan ekonomi hingga perilaku validator dan standar komunitas. Sistem tata kelola yang berfungsi dengan baik meningkatkan transparansi, keadilan, dan kepercayaan, sedangkan tata kelola yang buruk dapat menyebabkan kebingungan, stagnasi, atau sentralisasi kekuasaan.
Tata kelola Solana masih berada pada tahap awal pengembangan. Seperti banyak jaringan blockchain, Solana tidak diluncurkan dengan kerangka tata kelola yang sepenuhnya matang atau formal. Kerangka tersebut berkembang secara bertahap, dibentuk oleh praktik komunitas, kendala teknis, dan pelajaran yang diperoleh. Penyempurnaan tata kelola Solana merupakan proses berkelanjutan dan iteratif.
Ekosistem Solana terdiri atas beragam kelompok pemangku kepentingan yang saling tumpang tindih: pemegang token, staker, pengguna, validator, operator RPC, developer aplikasi, dan engineer protokol inti. Setiap kelompok membawa perspektif, insentif, dan tujuan yang berbeda. Meskipun insentif ini dapat selaras dalam beberapa hal, sering kali terdapat perbedaan, terutama terkait distribusi sumber daya, kendali protokol, dan kebijakan ekonomi.
Dalam sistem terdesentralisasi, tata kelola berkaitan dengan konsensus sosial sama besarnya dengan kode. Meskipun blockchain sering digambarkan dengan ungkapan “kode adalah hukum”, sejarah menunjukkan bahwa ketika konsensus komunitas menuntutnya, kode dapat—dan memang—berubah. Karena itu, desain mekanisme tata kelola dan kemampuannya untuk berkembang dari waktu ke waktu sama pentingnya dengan arsitektur teknis awal.
Laporan ini bertujuan memperjelas struktur, evolusi, dan kondisi tata kelola Solana saat ini. Laporan ini menyajikan pandangan komprehensif tentang cara keputusan dibuat dalam jaringan dan perbandingan tata kelolanya dengan ekosistem blockchain lain. Laporan ini disusun menjadi empat bagian utama:
- Elemen Tata Kelola Solana – Membahas komponen inti proses tata kelola Solana, termasuk SIMD, aktivasi feature gate, dan pemungutan suara on-chain formal.
- Analisis Pemungutan Suara Tata Kelola – Gambaran terperinci tentang seluruh pemungutan suara tata kelola formal hingga saat ini, termasuk hasil, perilaku pemilih, dan metrik partisipasi.
- Tantangan dan Rekomendasi – Pembahasan masalah utama yang dihadapi model tata kelola Solana saat ini, disertai rekomendasi yang dapat ditindaklanjuti jika relevan.
- Perbandingan dengan Jaringan Alternatif – Tinjauan tentang cara kerja tata kelola di ekosistem sejawat Cosmos dan Ethereum, dengan menyoroti praktik yang dapat menjadi acuan untuk meningkatkan Solana.
Meskipun alur laporan paling mudah dipahami jika dibaca secara berurutan, setiap bagian dirancang agar dapat berdiri sendiri dan dibaca secara terpisah.
Elemen Tata Kelola Solana
Tabel di bawah ini memberikan gambaran umum sistem tata kelola Solana, yang disusun menggunakan kerangka analisis hasil adaptasi dari makalah Menganalisis Pengambilan Keputusan dalam Tata Kelola Blockchain oleh Schädler, Lustenberger, dan Spychiger (2023). Kami telah menyesuaikan kerangka ini agar mencerminkan mekanisme dan dinamika khusus dalam ekosistem Solana.
| Off-chain | On-chain | |
| Pengambil Keputusan | Tim klien (Anza, Firedancer) | Operator validator |
| Insentif | Meningkatkan adopsi jaringan Peningkatan teknis: IBRL | Meningkatkan adopsi jaringan Komisi inflasi Imbalan blok Komisi MEV |
| Akses | Publik / Terbuka | Validator Mainnet |
| Koordinasi | GitHub SIMD Discord Solana Tech Forum Solana Kanal sosial | Tidak ada |
| Ketentuan Persetujuan | Tidak ada | Mencapai kuorum suara |
Modifikasi protokol Solana mengikuti proses bertahap yang berbeda-beda sesuai sifat dan dampak perubahan. Faktor utamanya mencakup apakah perubahan tersebut memutus konsensus, dampaknya terhadap pemangku kepentingan, serta tingkat perselisihan atau kompleksitasnya. Perubahan yang memutus konsensus mengacu pada pembaruan protokol apa pun yang menyebabkan node dengan versi perangkat lunak berbeda tidak sepakat mengenai status blockchain.
Tabel berikut menguraikan langkah-langkah umum untuk perubahan dengan berbagai tingkat cakupan. ‘Perubahan besar’ adalah perubahan yang berpotensi menimbulkan dampak ekonomi.
| Skala Perubahan | Perubahan Kecil | Perubahan Menengah | Perubahan Besar |
| Contoh | Refactoring kode | Program inti baru | Modifikasi ekonomi |
| Memutus konsensus | Tidak | Ya | Ya |
| Memerlukan SIMD | Tidak | Ya | Ya |
| Memerlukan pemungutan suara tata kelola | Tidak | Tidak | Ya |
| Memerlukan implementasi lintas klien | Tidak | Ya | Ya |
| Memerlukan aktivasi feature gate | Tidak | Ya | Ya |
Di bawah ini, kami akan menjelaskan secara terperinci proses aktivasi feature gate, SIMD, dan pemungutan suara tata kelola.
Aktivasi Feature Gate
Tim developer inti Anza dan Firedancer sering merilis fitur baru, termasuk syscall, program native, dan perubahan ekonomi yang memutus konsensus. Fitur-fitur ini dibuat, disertakan dalam rilis perangkat lunak klien baru, dan secara default dinonaktifkan di balik feature flag. Feature Gate Program, yang baru-baru ini dimigrasikan menjadi program Core BPF, melacak setiap fitur baru sebagai account. Private key unik untuk setiap feature gate dimiliki oleh kontributor inti yang terkait dengan feature gate tersebut. Setelah cukup banyak validator dengan stake melakukan upgrade ke rilis baru dan rilis tersebut dianggap stabil, sakelar fitur runtime diaktifkan secara manual melalui sebuah instruction. Fitur tersebut kemudian aktif di semua node jaringan pada awal epoch berikutnya. Urutan dan waktu aktivasi yang tepat dapat dipantau melalui jadwal feature gate. Aktivasi fitur tidak bergantung pada cluster. Aktivasi dilakukan terlebih dahulu di Testnet, kemudian Devnet, dan terakhir Mainnet, sehingga keandalan versi baru dapat dibuktikan sebelum aktivasi final di Mainnet.
‘Version floor’ adalah versi perangkat lunak minimum yang saat ini didukung oleh sebuah cluster. Saat feature gate baru diaktifkan, version floor dinaikkan agar sesuai dengan rilis perangkat lunak yang menyertakan fitur tersebut. Aktivasi fitur baru di Solana mengikuti jadwal rutin, biasanya pada batas epoch yang jatuh dalam jam kerja pada hari kerja. Aktivasi dihentikan sementara selama transisi versi dan dilanjutkan sekitar dua epoch setelah 95% stake melakukan upgrade ke rilis minor baru (misalnya, dari versi 2.2 ke 2.3).
Aktivasi feature gate merupakan hard fork yang tidak kompatibel dengan versi sebelumnya dan memerlukan adopsi universal agar dapat berlaku. Jika validator tidak melakukan upgrade ke versi yang mengenali feature gate yang telah diaktifkan, validator tersebut tidak dapat terus memvalidasi status global dan akan menyimpang dari jaringan.
Berbeda dengan Bitcoin atau Ethereum, yang hard fork-nya dapat mengakibatkan pemisahan chain permanen jika terjadi ketidaksepakatan, pendekatan Solana memastikan feature gate diaktifkan di seluruh cluster pada slot tertentu. Validator harus melakukan upgrade terlebih dahulu sehingga pemisahan chain dapat dicegah. Jadi, meskipun feature gate merupakan hard fork karena mengubah aturan konsensus, mekanisme ini tidak dapat menimbulkan chain yang saling bersaing.
Versi klien baru juga akan menyertakan banyak perubahan yang tidak memutus konsensus, seperti refactoring kode dan pengoptimalan efisiensi, yang tidak memerlukan feature gate.
Solana Improvement Documents (SIMD)
Proposal Solana Improvement Document (SIMD) adalah dokumentasi formal yang diperlukan untuk setiap perubahan substansial pada komponen inti Solana. Perubahan "substansial" didefinisikan sebagai perubahan yang biasanya mengubah protokol jaringan, validitas transaksi, atau interoperabilitas. Perubahan yang tidak substansial, seperti refactoring kode minor atau peningkatan performa yang objektif, tidak memerlukan proposal. Proposal harus mendokumentasikan alasan fitur tersebut dan menyediakan dokumentasi yang memadai untuk memahami implementasinya.
Meskipun pengajuan SIMD bersifat permissionless, sebagian besar SIMD diajukan oleh developer tim klien yang bekerja penuh waktu untuk meningkatkan protokol inti.
Ada dua jenis proposal:
- Proposal Standar: memengaruhi fitur inti Solana (misalnya, konsensus, jaringan, dan antarmuka API)
- Proposal Meta: membahas proses atau pedoman di luar codebase
SIMD biasanya melewati tahap pemeriksaan ide, penyusunan draf, peninjauan, dan penerimaan. Peninjauan formal berlangsung secara terbuka di GitHub. Penulis proposal bertanggung jawab mengumpulkan masukan dari kontributor inti terkait dari tim klien Agave dan Firedancer, yang menentukan apakah proposal diterima, direvisi, atau ditarik dengan mempertimbangkan keamanan, trade-off, dan kompatibilitas dengan versi sebelumnya.
Penulis tidak diwajibkan mengimplementasikan proposal mereka, tetapi umumnya disarankan untuk melakukannya karena ini merupakan cara terbaik untuk memastikan penyelesaian yang berhasil. Jika diterima, proposal sering menyertakan issue pelacakan terkait untuk implementasi fitur dan biasanya memerlukan aktivasi melalui mekanisme feature gate Solana.
Meskipun tidak semua aktivasi feature gate memerlukan SIMD, sebagian besar disertai SIMD untuk memberikan konteks, justifikasi, dan catatan terstandar mengenai perubahan yang diusulkan.
Pemungutan Suara Tata Kelola
SIMD yang mengubah protokol secara signifikan, terutama yang memengaruhi parameter ekonomi, memerlukan pemungutan suara tata kelola. Proses tata kelola Solana, yang dipimpin oleh anggota komunitas validator berpengalaman, hanya berfokus pada persoalan penting untuk mempertahankan keterlibatan dan mencegah kejenuhan tata kelola. Karena itu, hanya ada beberapa pemungutan suara setiap tahun.
Pemungutan suara tata kelola terutama berfungsi sebagai mekanisme untuk mengukur sentimen terhadap perubahan yang diusulkan. Dengan memungkinkan validator menyampaikan sikap sebelum implementasi penuh, proses ini membantu mengarahkan pengembangan dan meminimalkan perselisihan. Menerapkan perubahan tanpa konsensus luas dapat menimbulkan gesekan, terutama jika lebih dari sepertiga jaringan menolak adopsinya.
Pemungutan suara dilakukan menggunakan token SPL. Account identitas setiap validator aktif menerima alokasi token yang proporsional dengan stake aktifnya yang diukur dalam lamport. Validator kemudian dapat mengirimkan token ini ke alamat tertentu yang mewakili berbagai opsi suara, termasuk opsi abstain. Validator bebas membagi suara ke beberapa opsi—misalnya, mengalokasikan 80% untuk YA dan 20% untuk TIDAK—sehingga mereka memiliki fleksibilitas untuk mencerminkan beragam preferensi para staker. Setelah dikirimkan, suara bersifat final dan tidak dapat diubah.
Dalam struktur ini, pemegang token SOL berpartisipasi secara tidak langsung dengan mendelegasikan SOL yang mereka staking kepada validator yang pilihan suaranya selaras dengan nilai atau preferensi mereka. Ini merupakan sistem perwakilan proporsional, dengan validator dapat dianggap sebagai wakil terpilih. Staker Solana mendelegasikan stake mereka kepada validator, dan kekuatan suara setiap validator didasarkan pada stake aktifnya.
Batas Tata Kelola On-Chain
Tata kelola di Solana pada akhirnya tidak mengikat dan bersifat konsultatif. Dalam praktiknya, pemungutan suara sebenarnya terjadi ketika validator memilih versi perangkat lunak yang akan dijalankan. Meskipun pemungutan suara tata kelola dapat menunjukkan dukungan atau penolakan luas dari komunitas, pemungutan suara tersebut tidak memaksa validator mengadopsi kode tertentu. Proposal bahkan dapat berubah setelah pemungutan suara, dan validator tetap memegang kendali penuh atas apa yang berjalan di infrastruktur mereka. Dinamika ini berarti tata kelola lebih berfungsi untuk menandai konsensus daripada memaksakan hasil.
Kontributor inti seperti Anza, Jump, dan Jito serta penyedia infrastruktur seperti Helius dan Triton memiliki pengaruh informal yang signifikan dalam konteks ini. Karena validator cenderung tidak menentang kelompok tersebut dan mengambil risiko kehilangan stake atau tidak lagi selaras dengan jaringan, entitas-entitas ini dapat secara efektif membentuk hasil upgrade—terlepas dari apakah mereka memiliki wewenang formal untuk mengambil keputusan.
Fork dapat terjadi dalam skenario ekstrem ketika validator menolak upgrade. DAO Fork Ethereum pada 2016, yang menghasilkan Ethereum Classic, tetap menjadi contoh peringatan. Seiring berkembangnya proses tata kelola Solana, memperjelas hubungan antara pemungutan suara sebagai sinyal, rilis perangkat lunak, dan adopsi validator yang sebenarnya akan memastikan transparansi serta menghindari risiko ekstrem pemisahan chain.
Analisis Pemungutan Suara Tata Kelola
Tata Kelola Awal Solana: 2020–2022
Pendekatan awal Solana terhadap tata kelola sangat berbeda dari kerangka saat ini. Tata kelola awal berpusat pada Feature Proposal Program, yang memungkinkan validator memberikan suara atas perubahan protokol menggunakan token SPL berbobot stake. Setelah rilis fitur baru tersedia untuk diaktifkan, validator menerima alokasi token suara yang proporsional dengan stake aktif mereka. Dengan mengembalikan token ini ke account tertentu dalam periode dua minggu, validator dapat menandakan persetujuan atas aktivasi fitur yang diusulkan. Setelah mencapai ambang batas 67% stake, perubahan akan langsung diaktifkan secara on-chain pada epoch berikutnya.
Feature Proposal Program digunakan beberapa kali untuk menyelenggarakan pemungutan suara tata kelola validator di Testnet dan Mainnet, terutama untuk mengaktifkan jadwal inflasi saat ini.
| Proposal | Tanggal | Cluster | Detail Proposal |
| Inflasi PICO | Des 2020 | Testnet & Mainnet | Mengaktifkan inflasi 0,01% untuk keperluan validasi sebelum inflasi penuh |
| Inflasi Penuh | Jan/Feb 2021 | Testnet & Mainnet | Mengaktifkan inflasi penuh sesuai jadwal inflasi |
| Delegasi stake minimum | Sep 2022 | Testnet | Memperkenalkan delegasi stake minimum sebesar 1 SOL |
Catatan online mengenai pemungutan suara tata kelola awal ini sangat terbatas karena Forum Solana asli telah dinonaktifkan dan kini hanya dapat diakses melalui versi arsip di Wayback Machine.
Meskipun mekanisme ini memperkenalkan koordinasi on-chain hingga taraf tertentu, mekanisme tersebut banyak dikritik. Validator tidak memiliki cara untuk menyatakan ketidaksetujuan—hanya suara YA yang dihitung, dan tidak ada metode formal untuk menyatakan penolakan atau abstain. Sistem ini juga menciptakan tekanan sosial untuk menyetujui perubahan, terutama setelah upaya engineering yang besar telah dicurahkan untuk implementasinya.
Yang lebih penting, sistem ini tidak menyediakan sinyal awal. Artinya, fitur kompleks dapat dikembangkan tanpa mengetahui apakah fitur tersebut akan diterima, sehingga menimbulkan inefisiensi dan menyia-nyiakan waktu pengembangan.
Secara keseluruhan, meskipun Feature Proposal Program merupakan langkah awal yang penting dalam perjalanan tata kelola Solana, keterbatasannya membantu membentuk pengembangan mekanisme tata kelola yang lebih fleksibel dan digunakan saat ini.
Perlu dicatat bahwa beberapa perubahan ekonomi besar pada periode awal ini—seperti penerapan priority fee dengan burn 50%—diterapkan tanpa pemungutan suara tata kelola formal. Hal ini mencerminkan periode ketika sistem tata kelola masih berada pada tahap awal.
Tata Kelola Solana Saat Ini: 2023 dan Seterusnya
Setelah menggunakan Feature Proposal Program, Solana berkembang hingga mencapai sistem pemungutan suara tata kelola saat ini. Sejauh ini, lima pemungutan suara tata kelola resmi telah dilaksanakan:
- Pemungutan Suara Konsultatif Awal pada Oktober 2023
- SIMD-33 Timely Vote Credits pada April 2024 oleh Bryan Ischo dan Zantetsu, Shinobi Systems
- SIMD-96 Priority Fee Penuh untuk Validator pada Mei 2024 oleh Tao Zhu, Anza
- SIMD-123 Distribusi Imbalan Blok dalam Protokol oleh Justin Starry, Anza
- SIMD-228 Mekanisme Emisi Berbasis Pasar oleh Tushar Jain dan Vishal Kankani, Multicoin Capital, Max Resnick, Anza pada Maret 2025
Pemungutan Suara Konsultatif Awal
Keputusan awal yang sangat penting dalam membentuk kerangka tata kelola Solana saat ini adalah menentukan pihak yang harus berpartisipasi dalam proses pemungutan suara. Tiga opsi diajukan kepada komunitas:
- Pemungutan suara khusus validator, dengan bobot suara berdasarkan stake
- Validator dan stake account, sehingga delegator dapat membatalkan suara validator mereka
- Validator, stake account, dan pemangku kepentingan lain, seperti operator RPC dan developer
Pemungutan suara konsultatif ini diikuti oleh lebih dari 170 validator yang mewakili 14,3% dari total stake. Dari stake yang memberikan suara, lebih dari 70% mendukung pemungutan suara khusus validator, sementara 24% memilih model validator dan delegator. Tidak ada ambang batas partisipasi minimum yang diberlakukan untuk pemungutan suara ini.
Pemungutan suara khusus validator dipilih sebagai titik awal yang paling praktis dan efisien karena infrastrukturnya telah tersedia dan teruji dalam praktik. Sistem lebih kompleks yang melibatkan delegator atau pemangku kepentingan lain dianggap terlalu dini dan berpotensi membebani proses tata kelola yang masih baru. Komunitas mengakui bahwa model pemungutan suara alternatif dapat diperkenalkan dan disempurnakan melalui proposal mendatang seiring matangnya tata kelola.
Pola Pemungutan Suara Tata Kelola
Sejak pemungutan suara konsultatif awal, telah berlangsung empat pemungutan suara tata kelola lainnya dengan tiga opsi suara yang sama: YA, TIDAK, dan Abstain. Opsi ini menunjukkan persetujuan terhadap SIMD yang diusulkan. Agar disetujui, setidaknya dua pertiga dari gabungan suara YA dan TIDAK harus mendukung proposal (yaitu, YA).
SIMD-33: Timely Vote Credits disetujui dengan dukungan luar biasa, yaitu 98,4% suara YA. Perubahan konsensus yang tidak kontroversial ini mengatasi ketidakselarasan insentif dengan menghilangkan manfaat yang sebelumnya diperoleh validator dari pengiriman suara terlambat, sehingga meningkatkan perilaku jaringan dan keadilan.
SIMD-96: Priority Fee Penuh untuk Validator disetujui dengan 77,7% suara YA. Proposal ekonomi ini bertujuan mencegah pemrosesan transaksi melalui kanal samping dengan mengarahkan 100% priority fee kepada validator. Meskipun efektif dalam menyelaraskan insentif, proposal ini cukup kontroversial karena sedikit meningkatkan inflasi dan dianggap lebih menguntungkan validator daripada pemegang SOL.
SIMD-123: Distribusi Imbalan Blok dalam Protokol disetujui dengan 74,91% suara YA. Proposal ini memperkenalkan mekanisme opsional dan terstandar bagi validator untuk mendistribusikan imbalan blok secara langsung kepada staker. Meskipun beberapa validator telah melakukannya melalui metode yang lebih manual, penerapannya dalam protokol memicu perdebatan mengenai tekanan persaingan karena dikhawatirkan dapat memicu "perlombaan menuju nol" dalam tingkat komisi imbalan blok.
SIMD-228: Mekanisme Emisi Berbasis Pasar gagal disetujui karena hanya memperoleh 61,39% suara YA. Proposal ini bertujuan membuat tingkat inflasi Solana lebih responsif terhadap partisipasi staking, dengan argumen bahwa emisi saat ini terlalu tinggi, tidak responsif terhadap permintaan imbal hasil, dan menyebabkan jaringan membayar terlalu mahal untuk keamanan.
Para penentang mengkhawatirkan kelayakan ekonomi validator yang lebih kecil dan ketidakpastian tambahan yang dapat ditimbulkannya terhadap imbal hasil staking. Pemungutan suara ini terbukti sangat kontroversial, memicu perdebatan luas, dan menyoroti perbedaan pandangan mengenai model ekonomi jangka panjang Solana.
Untuk melihat perilaku pemungutan suara secara terperinci, pembaca dianjurkan merujuk ke dashboard suara sumber terbuka untuk SIMD-96, SIMD-123, dan SIMD-228. Selain itu, kami menyediakan spreadsheet berisi data pemungutan suara yang tersedia di sini.
Ambang kuorum sebesar 33% partisipasi stake—termasuk suara abstain—diberlakukan untuk SIMD-228 dan SIMD-123. Sebaliknya, proposal terdahulu seperti SIMD-96 dan SIMD-33 tidak memiliki persyaratan partisipasi minimum, sehingga dapat disetujui tanpa memperhitungkan berapa besar total stake yang memberikan suara.
Tingkat Partisipasi
Tingkat partisipasi pemungutan suara menunjukkan tren peningkatan dari waktu ke waktu. Pemungutan Suara Konsultatif Awal pada Oktober 2023 mencatat keterlibatan yang sangat rendah, dengan hanya 14,3% stake berpartisipasi. Sejak saat itu, partisipasi terus meningkat hingga mencapai puncaknya pada pemungutan suara SIMD-228 pada Maret 2025, yaitu Mekanisme Emisi Berbasis Pasar, dengan tingkat partisipasi sebesar 74,3%. Tiga pemungutan suara lainnya hingga saat ini memiliki tingkat partisipasi yang relatif konsisten, berkisar antara 51,2% hingga 57,1%.
Pemungutan suara SIMD-228 menjadi peristiwa tata kelola terbesar dalam sejarah kripto, baik berdasarkan jumlah peserta maupun total kapitalisasi pasar yang diwakili. Pada saat perdebatan berlangsung, kapitalisasi pasar Solana sebanding dengan Bitcoin pada masa perang ukuran blok pertengahan 2017, yang menegaskan pentingnya keputusan ini. Sebanyak 281 juta SOL senilai $35 miliar berpartisipasi dalam pemungutan suara, dengan lebih dari 900 validator mengirimkan lebih dari 1.000 suara. Perlu dicatat bahwa ini adalah pertama kalinya validator bursa besar—termasuk Coinbase, Kraken, dan Bybit—secara aktif terlibat dalam tata kelola on-chain Solana, yang menandakan meningkatnya kehadiran institusional dalam proses pengambilan keputusan jaringan. Peningkatan partisipasi baru-baru ini, terutama dari entitas yang berbasis di AS, juga mungkin sebagian dipengaruhi oleh iklim regulasi blockchain yang lebih mendukung di bawah pemerintahan saat ini.
Masalah dan Rekomendasi
Pada bagian berikutnya, kami akan membahas tantangan utama dalam proses pemungutan suara tata kelola dan, jika relevan, memberikan rekomendasi untuk meningkatkan transparansi, keamanan, dan efisiensi.
Kurangnya Partisipasi Staker
Salah satu kekhawatiran yang terus muncul dalam proses tata kelola Solana adalah terbatasnya peran delegator dalam pengambilan keputusan. Meskipun validator memberikan suara atas proposal menggunakan kekuatan tata kelola berbobot stake, tidak ada mekanisme formal bagi delegator untuk menyampaikan preferensi atau membatalkan keputusan validator. Hal ini dapat menyebabkan suara validator bertentangan dengan kepentingan delegator mereka, sehingga staker tidak memiliki cara langsung untuk memengaruhi hasil tata kelola.
Validator dengan ribuan delegator kesulitan mengumpulkan preferensi suara setiap individu, dan tingkat keterlibatan staker biasanya rendah. Beberapa validator menanganinya sebagian dengan berkonsultasi kepada delegator terbesar sebelum memberikan suara dan membagi suara berdasarkan preferensi mereka. Validator lain bereksperimen dengan alat khusus yang meniru sistem pemungutan suara token yang ada—menerbitkan token tata kelola baru kepada staker berdasarkan proporsi stake mereka. Namun, ini masih menjadi solusi khusus validator dan bukan fitur terstandar di seluruh protokol.
Pihak yang menentang partisipasi staker menyatakan bahwa sebagian besar delegator tidak memiliki latar belakang teknis, jarang mengikuti keputusan tata kelola dengan saksama, dan tidak memiliki pemahaman mendalam tentang mekanisme serta trade-off blockchain yang diperlukan untuk mengambil keputusan berdasarkan informasi yang memadai. Namun, para pendukung berpendapat bahwa hanya mengandalkan validator menciptakan konflik kepentingan—tidak realistis mengharapkan mayoritas validator memilih proposal yang menguntungkan jaringan jika proposal tersebut merugikan insentif ekonomi mereka sendiri.
Potensi peningkatan mencakup kanal komunikasi yang lebih baik antara validator dan delegator, seperti dashboard tata kelola, alat pelacak sentimen, atau bahkan notifikasi wallet untuk peristiwa tata kelola. Bagian selanjutnya dalam laporan ini akan membahas kembali topik tersebut dengan mengulas pendekatan ekosistem Cosmos.
Tantangan dalam Diskursus Tata Kelola
Tata kelola yang efektif dalam ekosistem terdesentralisasi bergantung pada komunikasi yang jelas dan bernilai informasi tinggi. Namun, selama proposal SIMD-288 baru-baru ini, perdebatan sengit, serangan personal, dan faksionalisme menciptakan lingkungan tata kelola yang tidak sehat dan pada akhirnya menghambat diskusi produktif. Diskusi mengenai proposal penting di Solana dapat mengalami inefisiensi dan penurunan kualitas informasi di berbagai platform. Meskipun diskusi teknis di GitHub dan forum resmi Solana menghadirkan perdebatan yang terstruktur dan matang, ketika percakapan beralih ke Discord dan Twitter, diskusi yang bermakna terkadang berubah menjadi perang komentar dan serangan ad hominem sehingga menurunkan kualitas pengambilan keputusan secara keseluruhan.
Selain itu, sebagian besar peserta baru terlibat pada hari-hari terakhir sebelum pemungutan suara, alih-alih memanfaatkan seluruh periode diskusi. Mendorong partisipasi lebih awal dan menyusun linimasa tata kelola dengan lebih baik—misalnya memastikan diskusi penting berlangsung jauh sebelum periode pemungutan suara final—dapat membantu mengurangi masalah ini.
Panggilan tata kelola terbukti efektif karena memungkinkan interaksi langsung, klarifikasi cepat, serta mengurangi peluang trolling atau penyesatan. Memperkuat moderasi, mendorong diskusi terstruktur, dan menekankan analisis berbasis fakta daripada perdebatan konfrontatif sangat penting untuk mempertahankan proses tata kelola yang konstruktif.
Penggabungan Proposal Tata Kelola
Keputusan tata kelola sering kali paling efektif jika setiap proposal diputuskan secara terpisah, sehingga pemilih dapat mempertimbangkan setiap isu berdasarkan bobotnya masing-masing. Kekhawatiran utama dalam menggabungkan proposal adalah bias bawah sadar—pemilih yang memiliki pandangan kuat terhadap satu isu mungkin secara tidak sengaja membiarkannya memengaruhi sikap terhadap isu lain, meskipun keduanya tidak terkait. Hal ini mengurangi kemungkinan pengambilan keputusan yang bernuansa dan dapat mencegah penerapan perubahan yang sebenarnya bermanfaat.
Risiko lainnya adalah penggabungan meningkatkan kompleksitas operasional sehingga kesalahan lebih mungkin terjadi. Hal ini terlihat selama periode pemungutan suara bersama untuk SIMD-228 dan SIMD-123 ketika sejumlah kecil token yang ditujukan untuk SIMD-123 secara keliru dikirim ke alamat abstain SIMD-228. Meskipun jarang terjadi, kesalahan tersebut mendistorsi hasil pemungutan suara dan mengurangi kepercayaan terhadap proses tata kelola.
Namun, argumen yang mendukung penggabungan proposal adalah bahwa menyatukan beberapa keputusan ke dalam lebih sedikit periode pemungutan suara dapat membantu mengurangi kejenuhan pemilih dan mendorong tingkat partisipasi yang lebih tinggi. Meskipun dapat meningkatkan keterlibatan, langkah ini mengorbankan kejelasan dan ketepatan dalam pengambilan keputusan. Selain itu, ketika proposal gabungan bersifat kompleks, proposal tersebut sering memerlukan periode diskusi dan peninjauan yang lebih panjang sebelum pemungutan suara dimulai agar pemilih—terutama mereka yang biasanya baru terlibat pada saat-saat terakhir—memiliki cukup waktu untuk memahami dan mengevaluasi setiap komponen secara menyeluruh.
Pendekatan yang lebih efektif mungkin berupa pemisahan proposal tata kelola jika memungkinkan, sehingga setiap isu dapat dievaluasi secara independen. Jika penggabungan diperlukan, alasannya harus dijelaskan dengan jelas.
Kuorum Pemungutan Suara
Peran kuorum yang ditetapkan dalam pemungutan suara tata kelola Solana telah menimbulkan kekhawatiran. Dalam praktiknya, kuorum dapat menciptakan insentif yang menyimpang karena peserta secara strategis menahan suara agar proposal tidak mencapai ambang batas yang diperlukan. Dalam pemungutan suara SIMD-228 baru-baru ini, hal ini sangat terlihat di kalangan pemilih TIDAK. Selama dua epoch pertama pemungutan suara, mereka menganggap abstain sebagai strategi yang lebih efektif daripada secara aktif menolak proposal.
Visibilitas jumlah suara yang sedang berlangsung memengaruhi partisipasi. Sebagian validator mungkin memilih untuk tidak memberikan suara jika hasil yang diperkirakan telah sesuai dengan preferensi mereka. Untuk mencegah manipulasi kuorum, salah satu potensi peningkatan adalah menunda visibilitas suara hingga periode pemungutan suara berakhir.
Mengingat tantangan ini, dukungan untuk mengevaluasi ulang atau menghapus persyaratan kuorum semakin meningkat agar partisipasi tata kelola menjadi lebih lugas dan transparan.
Dampak SFDP
Saat laporan ini ditulis, Solana Foundation Delegation Program mendelegasikan SOL kepada 897 validator, yang mewakili 66% dari seluruh validator aktif di jaringan. Total yang didelegasikan adalah 41,01 juta SOL, atau 10% dari total SOL yang di-staking. Pembaca dapat merujuk pada laporan sebelumnya di blog Helius mengenai SFDP untuk memperoleh detail lengkap tentang program dan strategi delegasinya.
Dalam model tata kelola saat ini, validator dalam program ini secara efektif memperoleh penguatan kekuatan suara dan memberikan suara atas nama Solana Foundation. Analisis internal kami dan dashboard publik terkait pemungutan suara tata kelola SIMD-288 baru-baru ini mengonfirmasi bahwa stake SFDP memainkan peran penting dalam hasil pemungutan suara. Dalam pemungutan suara ini, stake SFDP terutama digunakan untuk memilih TIDAK terhadap proposal. Jika stake yang dikendalikan SFDP dan digunakan untuk memilih TIDAK atau abstain beralih memilih YA, proposal tersebut akan disetujui. Jika seluruh stake yang dikendalikan SFDP tetap netral dan abstain, proposal tersebut tetap akan gagal, tetapi dengan selisih lebih kecil—64,77% dibandingkan hasil aktual sebesar 61,39% (dengan 66,6% diperlukan agar disetujui).
Kejelasan Kriteria Pelaksanaan Pemungutan Suara
Pemungutan suara tata kelola pada Maret 2025 awalnya mencakup tiga proposal, yaitu SIMD-228, SIMD-123, dan SIMD-218: Intermediate Vote Credits (IVC). IVC menghilangkan kebutuhan akan mod yang dijalankan validator untuk mengoptimalkan kredit pemungutan suara Tower BFT (varian algoritma konsensus pBFT milik Solana) dengan secara otomatis mengisi ulang kredit untuk semua blok induk saat validator memberikan suara pada blok anak.
Selama periode diskusi, konsensus bahwa SIMD-218 tidak seharusnya memerlukan persetujuan tata kelola semakin menguat. Perubahan ini secara luas dianggap sebagai perbaikan bug, bukan perubahan protokol yang substantif, karena hanya meningkatkan atau memperbaiki upgrade Timely Vote Credits (TVC). TVC telah disetujui melalui pemungutan suara tata kelola dan menunjukkan dukungan komunitas yang kuat. Jajak pendapat informal di kalangan validator dalam Discord Solana Tech memperkuat pandangan ini dengan kesepakatan yang hampir bulat.
Selain itu, para engineer dari Anza menyatakan bahwa SIMD-123: Distribusi Imbalan Blok dalam Protokol bukan merupakan perubahan ekonomi seperti yang tersirat dari namanya. Proposal tersebut memperkenalkan metode opsional dalam protokol untuk mendistribusikan imbalan blok kepada staker, memformalkan praktik yang telah dilakukan beberapa validator melalui metode alternatif, serta menstandardisasi aktivitas yang sebelumnya berlangsung di luar protokol.
Hal ini menimbulkan sejumlah pertanyaan penting terkait tata kelola:
- Siapa yang menentukan apakah suatu proposal memerlukan pemungutan suara? Saat ini tidak ada badan resmi atau proses terstruktur untuk menentukan apakah proposal harus melalui tata kelola atau diterapkan secara langsung.
- Hal yang dapat dianggap sebagai “perubahan protokol substantif” masih ambigu. Batas antara upgrade rutin dan perubahan yang memerlukan intervensi tata kelola formal tidak jelas, dengan definisi saat ini sangat bergantung pada gagasan “dampak ekonomi” yang cukup samar.
Masalah Keamanan
Proses pemungutan suara proposal tata kelola saat ini bergantung pada alat pihak ketiga, solgov-distributor, yang dikembangkan dan di-host oleh Laine, seorang anggota komunitas. Alat ini merupakan fork dari distributor token berbasis Merkle yang awalnya dikembangkan oleh Jito. Meskipun Laine adalah anggota komunitas yang sangat dihormati, ketergantungan pada alat yang dikendalikan secara eksternal menimbulkan asumsi kepercayaan dan risiko keamanan.
- Mutabilitas – alat dan dokumentasinya dapat diubah, yang berarti keduanya dapat dimodifikasi secara sepihak kapan saja.
- Penggunaan Keypair Identitas Validator – Validator diwajibkan membangun CLI dan mengeklaim token menggunakan keypair identitas validator yang sangat sensitif. Setiap proses yang bergantung pada perangkat lunak eksternal untuk berinteraksi dengan kredensial sepenting ini menimbulkan risiko keamanan.
- Ketergantungan pada Pengelola Individu – Proses tata kelola resmi tidak boleh memiliki ketergantungan kritis pada pihak ketiga eksternal tanpa jaminan keamanan formal atau audit independen.
Mekanisme Pemungutan Suara Alternatif
Terdapat alat SPL Feature Proposal yang sudah tersedia (dokumentasi di sini), yang awalnya dirancang untuk memfasilitasi tata kelola on-chain. Namun, proses tata kelola terbaru tidak mengikuti pendekatan ini. Sebagai gantinya, solgov-distributor digunakan, sehingga menimbulkan pertanyaan apakah alat tambahan ini memang diperlukan.
Pada prinsipnya, sistem token SPL sudah menyediakan metode native untuk mendistribusikan kekuatan suara tata kelola. Pemrakarsa proses dapat langsung mendistribusikan token SPL kepada semua validator, sehingga mereka dapat memberikan suara menggunakan CLI spl-token standar tanpa bergantung pada alat eksternal. Langkah ini akan menghilangkan ketergantungan yang tidak diperlukan dan meningkatkan sifat trustless dalam proses pemungutan suara.
Alat Tata Kelola On-Chain Mendatang: SIMD-133
SIMD-133: Get Epoch Stakes yang akan datang dan dijadwalkan segera diaktifkan di Mainnet memperkenalkan alat tata kelola baru yang memungkinkan program mengambil bobot stake secara on-chain. Saat ini, program on-chain tidak mengetahui distribusi stake pada epoch berjalan dan jumlah stake yang didelegasikan ke setiap vote account.
Dengan SIMD-133, program tata kelola dapat mengambil snapshot on-chain atas jumlah stake validator melalui sysvar baru, sehingga menghilangkan kebutuhan akan proses verifikasi stake secara off-chain atau manual. Hal ini secara signifikan menyederhanakan alur tata kelola yang ada dan menghilangkan kebutuhan akan rekonsiliasi stake manual.
Perbandingan dengan Jaringan Alternatif
Cosmos
Chain Cosmos SDK menawarkan model tata kelola yang berpusat pada delegator, dengan staker dapat langsung membatalkan suara validator mereka melalui wallet populer seperti Keplr dan Leap. Artinya, meskipun validator awalnya memberikan suara dengan seluruh bobot stake-nya, delegator yang tidak setuju dapat mengalokasikan ulang bagian stake mereka ke opsi suara lain. Misalnya, jika validator memegang 2% dari total stake, tetapi delegator dengan bobot stake 1% tidak setuju, delegator tersebut dapat memberikan suara secara terpisah, sehingga suara efektif validator berkurang menjadi 1% dan 1% milik delegator dialihkan ke opsi lain.
Sistem ini memastikan delegator selalu memiliki keputusan akhir, sehingga menciptakan proses tata kelola yang transparan, mudah digunakan, dan efisien. Partisipasi tata kelola di Cosmos sangat mudah terlihat karena pemungutan suara diintegrasikan langsung ke dalam wallet dan block explorer, sehingga mudah diakses oleh semua pemangku kepentingan.
Contoh relevan mengenai perbedaan perilaku pemilih antara staker dan validator terjadi selama pemungutan suara Halving ATOM Cosmos (Proposal 848, Nov 2023), ketika proposal tersebut berupaya menurunkan tingkat inflasi maksimum menjadi 10%:
- 94,93% staker memilih YA, mendukung batas inflasi tersebut.
- Hanya 53,44% validator memilih YA karena banyak validator ingin mempertahankan aliran pendapatan yang lebih tinggi.
Perbedaan ini menyoroti pentingnya partisipasi langsung staker untuk memastikan keputusan tata kelola mencerminkan sentimen komunitas yang lebih luas, bukan hanya preferensi validator.
Modul tata kelola Cosmos tertanam pada tingkat protokol, yang memperkuat perannya sebagai fitur inti blockchain. Keputusan tata kelola tertentu dapat dijalankan secara otomatis secara on-chain sehingga meningkatkan transparansi dan akuntabilitas.
Meskipun model ini menawarkan struktur tata kelola yang demokratis, model tersebut bergantung pada partisipasi aktif dan mengasumsikan bahwa delegator memiliki waktu serta pengetahuan untuk mengambil keputusan berdasarkan informasi yang memadai. Cosmos menawarkan kerangka tata kelola alternatif yang menarik dan dapat dipelajari Solana untuk menentukan potensi peningkatan.
Ethereum
Tata kelola Ethereum mengikuti proses sosial secara off-chain, bukan pemungutan suara langsung berbasis stake. Proses pengambilan keputusan terutama mengandalkan Ethereum Improvement Proposals (EIP), developer inti, dan konsensus komunitas.
Perubahan pada Ethereum diusulkan melalui EIP, yang setara dengan SIMD di Solana. EIP ini menguraikan fitur, standar, atau upgrade baru untuk protokol Ethereum. Ethereum Request for Comments (ERC) menetapkan standar untuk fitur pada lapisan aplikasi, seperti token ERC-20 dan NFT ERC-721. Proposal ini dibahas secara terbuka dalam forum riset Ethereum (Ethereum Magicians), acara Ethereum populer (misalnya, Devcon, ETHDenver, ETHCC), GitHub, dan panggilan developer inti. Komunitas yang lebih luas berperan dalam tata kelola dengan memperdebatkan proposal di platform seperti Discord, Farcaster, dan X.
Berbeda dengan Cosmos atau Solana, Ethereum tidak menggunakan tata kelola berbasis stake atau pemungutan suara token untuk keputusan protokol. Sejak Ethereum beralih ke Proof-of-Stake, validator berperan lebih aktif dalam konsensus, tetapi tidak memberikan suara secara formal. Sebagai gantinya, konsensus umum dicapai melalui perdebatan teknis dan dukungan komunitas yang luas. Perubahan protokol Ethereum sangat bergantung pada developer inti yang memelihara klien eksekusi dan konsensus Ethereum (misalnya, Geth, Nethermind, Prysm).
Upgrade besar diaktifkan melalui hard fork yang mengharuskan validator dan operator node melakukan upgrade perangkat lunak. Validator menegakkan aturan jaringan dengan memilih apakah akan mengadopsi upgrade baru. Meskipun jarang terjadi, jika perubahan yang diusulkan bersifat kontroversial dan tidak memperoleh konsensus, perubahan tersebut dapat menyebabkan pemisahan chain, seperti yang terlihat pada fork sebelumnya, yaitu DAO Fork (2016, Ethereum Classic) dan, dalam skala lebih kecil, transisi Ethereum ke Proof-of-Stake (2022, EthereumPoW).
Model tata kelola sosial Ethereum memprioritaskan konsensus teknis dan diskusi komunitas daripada mekanisme pemungutan suara formal. Meskipun pendekatan ini menjaga Ethereum tetap fleksibel dan terdesentralisasi, perubahan memerlukan diskusi panjang dan berlarut-larut serta koordinasi sosial, bukan tata kelola langsung berbasis token. Selain itu, tidak ada cara formal bagi pemegang ETH atau staker untuk memberikan suara atas proposal, sehingga membatasi pengaruh langsung pengguna.
Kesimpulan
Sistem tata kelola Solana masih berkembang dan dibentuk oleh eksperimen dunia nyata serta masukan komunitas. Laporan ini membahas komponen intinya—SIMD, aktivasi fitur, dan pemungutan suara on-chain—serta meninjau seluruh pemungutan suara formal hingga saat ini, tantangan utama, dan perbandingannya dengan jaringan sejawat seperti Cosmos dan Ethereum.
Ekosistem Solana berakar pada budaya kuat yang digerakkan oleh engineering dan lebih menghargai iterasi serta eksekusi cepat daripada perdebatan berkepanjangan. Meskipun laju upgrade yang tinggi ini membedakan Solana dari banyak jaringan sejawat, hal tersebut juga menimbulkan ketegangan dengan model tata kelola yang mengandalkan diskusi komunitas panjang dan koordinasi sosial yang luas. Ini menghadirkan tantangan unik dalam menyeimbangkan kecepatan dengan pengambilan keputusan yang inklusif.
Tata kelola Solana masih terus terbentuk, tetapi satu hal sudah jelas: keterlibatan komunitas belum pernah setinggi ini. Seiring semakin banyak pemangku kepentingan yang aktif membentuk jaringan, Solana memiliki peluang unik untuk membangun model tata kelola yang sejalan dengan ambisi, kecepatan, dan pertumbuhan ekosistemnya.
Sumber Daya Tambahan
Artikel Terkait
Berlangganan Helius
Ikuti perkembangan terbaru dalam pengembangan Solana dan dapatkan pembaruan saat kami memublikasikan postingan


