Bitcoin sering digambarkan sebagai uang digital yang dijalankan oleh kode. Ini benar, tetapi mengabaikan elemen krusial: siapa yang mengendalikan kode tersebut? Berbeda dengan korporasi tradisional yang beroperasi di bawah manajemen hierarkis, atau pemerintah yang bergantung pada pemungutan suara parlementer, perubahan protokol Bitcoin diatur oleh proses politik yang unik, berantakan, dan sangat terdesentralisasi. Sistem ini dirancang khusus untuk membuat perubahan besar sulit dilakukan, memastikan stabilitas dan prediktabilitas mata uang dalam jangka panjang.
Memahami tata kelola Bitcoin sangat penting untuk menangkap ketahanan sejatinya. Ini menjelaskan mengapa perubahan radikal, bahkan yang berpotensi bermanfaat, membutuhkan waktu bertahun-tahun untuk diimplementasikan, memerlukan perdebatan yang meluas ke daftar email pengembang, kolam penambangan, dan rumah-rumah pengguna individu yang menjalankan node validasi. Ekonomi politik dengan gesekan tinggi ini berfungsi sebagai pengaman konstitusional, melindungi jaringan dari keputusan tergesa-gesa dan pelaku jahat.
Analisis ini menyelami mekanisme perubahan protokol, memeriksa siklus hidup sebuah ide—dari proposal awalnya sebagai Bitcoin Improvement Proposal (BIP) hingga adopsi akhirnya melalui mekanisme konsensus seperti Soft Forks. Kami mengeksplorasi keseimbangan kekuasaan yang rapuh antara pengembang, penambang, dan pengguna yang menjalankan node penuh, yang pada akhirnya mengungkap mengapa ketahanan Bitcoin terhadap perubahan adalah fitur paling kuatnya.
Fondasi Perubahan: Sistem Bitcoin Improvement Proposal (BIP)
Karena Bitcoin tidak memiliki otoritas terpusat, diperlukan proses formal dan publik untuk mengusulkan, mendiskusikan, dan mendokumentasikan perubahan protokol. Mekanisme ini dikenal sebagai Bitcoin Improvement Proposal, atau BIP. Sistem BIP menyediakan struktur yang diperlukan untuk mengelola konsensus teknis, mengubah ide abstrak menjadi proposal formal yang siap untuk pengawasan komunitas.
Bayangkan sistem BIP sebagai ruang penyusunan konstitusi untuk Bitcoin. Ini adalah titik awal wajib untuk setiap perubahan signifikan yang tidak sepele, mulai dari penyesuaian kecil pada perhitungan biaya hingga perubahan besar dalam cara validasi transaksi.
Anatomi BIP
BIP adalah dokumen terstruktur yang menggambarkan perubahan, fitur, atau peningkatan desain spesifik untuk Bitcoin. Setiap BIP diberi nomor berurutan (misalnya, BIP 1, BIP 341) dan harus memenuhi persyaratan ketat agar dianggap valid. Persyaratan ini memastikan kejelasan, kekokohan teknis, dan pertimbangan menyeluruh terhadap efek samping.
Secara umum ada tiga jenis BIP, meskipun yang paling relevan untuk tata kelola adalah BIP "Standards Track", yang mengusulkan perubahan yang memengaruhi protokol itu sendiri (seperti format transaksi atau aturan konsensus). BIP yang berhasil harus secara jelas mendefinisikan:
- Motivasi: Mengapa perubahan ini diperlukan? Masalah apa yang dipecahkan?
- Spesifikasi: Detail teknis tentang bagaimana perubahan akan diimplementasikan dalam kode. Ini harus cukup presisi sehingga pengembang di seluruh dunia dapat mengkodekannya.
- Kesesuaian Mundur: Apakah perubahan ini akan merusak kompatibilitas dengan versi perangkat lunak yang lebih lama? (Ini menentukan apakah perubahan memerlukan Soft Fork atau Hard Fork.)
Keberadaan proses BIP memastikan transparansi. Ini menjamin bahwa setiap penyesuaian teknis krusial tunduk pada pengawasan open-source, sering kali oleh ratusan kriptografer dan pengembang independen yang menganalisis kode untuk cacat, efek samping ekonomi, dan kerentanan keamanan. Fase tinjauan publik ini adalah gesekan esensial yang melindungi sistem.
Peran Pengembang Inti dan Pemelihara
Meskipun siapa pun dapat mengusulkan BIP, pengembangannya, penyempurnaan, dan akhirnya penggabungan ke implementasi referensi (Bitcoin Core) diawasi oleh kelompok kecil yang berdedikasi yang dikenal sebagai pengembang dan pemelihara Bitcoin Core. Individu-individu ini bukan badan penguasa resmi; sebaliknya, mereka adalah sukarelawan tepercaya yang fungsi utamanya adalah tinjauan kode, pemeliharaan, dan penilaian risiko.
Bitcoin Core adalah perangkat lunak dasar yang dijalankan oleh sebagian besar node dan layanan infrastruktur, menjadikan basis kode-nya sangat berpengaruh. Pemelihara bertanggung jawab untuk menilai apakah BIP sudah siap secara teknis dan apakah telah memperoleh konsensus sosial yang cukup dalam komunitas pengembangan.
Yang krusial, pengembang tidak dapat memaksa adopsi. Mereka menulis perangkat lunak, tetapi penambang dan, yang lebih penting, pengguna harus secara sukarela mengunduh dan menjalankan perangkat lunak yang diperbarui. Jika pengembang mengimplementasikan perubahan yang dibenci komunitas, pengguna akan menolak kode tersebut dan mencari perangkat lunak alternatif, secara efektif menghilangkan pengaruh pengembang. Kekuasaan mereka hanya bergantung pada kepercayaan, keahlian, dan netralitas teknis.
Mengapa Proses BIP adalah Gesekan yang Diperlukan
Di perusahaan teknologi terpusat yang bergerak cepat, kelincahan adalah yang terutama. Perubahan didorong dengan cepat. Untuk Bitcoin, kebalikannya benar. Proses BIP sengaja lambat dan argumentatif karena nilai utama jaringan adalah ketidakberubahannya dan prediktabilitasnya.
Jika Bitcoin mudah diubah, ia akan kehilangan kredibilitasnya sebagai penyimpan nilai yang tidak berubah. Diskusi lambat selama beberapa tahun yang melekat pada proses BIP berfungsi sebagai filter politik:
- Pemeriksaan Dampak Ekonomi: Penyebaran lambat memungkinkan ekonom dan analis mempelajari dampak potensial, seperti perubahan biaya transaksi atau insentif penambangan.
- Mencegah Sentralisasi: Dengan memerlukan kesepakatan luas di berbagai kepentingan politik, ekonomi, dan geografis, proses ini mencegah entitas kuat tunggal (seperti kolam penambangan besar atau bursa terpusat) mendikte kebijakan secara sepihak.
- Memastikan Kualitas: Waktu memungkinkan kode ditinjau, diuji tekanan, dan diaudit berulang kali, mengurangi risiko bug katastrofik memasuki protokol inti.
Kesulitan untuk melewati BIP adalah fitur, bukan bug, memastikan bahwa hanya perubahan dengan dukungan teknis dan sosial yang luar biasa yang maju.
Dua Jalur Perubahan Protokol: Soft Forks vs. Hard Forks
Setelah BIP dirancang dan didiskusikan, pengembang harus memutuskan cara mengimplementasikannya. Strategi implementasi ini menentukan tingkat koordinasi jaringan yang diperlukan dan, yang krusial, risiko potensial memecah komunitas. Pilihan ini mereduksi menjadi dua jenis utama peningkatan protokol: Soft Forks dan Hard Forks.
Fork ini bukan sekadar pembaruan perangkat lunak; mereka mewakili pendekatan mendasar yang berbeda untuk mencapai konsensus dan mempertahankan kompatibilitas mundur.
Soft Forks: Peningkatan Kompatibel Mundur
Soft Fork adalah perubahan pada protokol Bitcoin yang memperketat aturan, artinya aturan baru kompatibel dengan aturan lama.
Bayangkan meningkatkan aplikasi perangkat lunak sehingga versi baru dapat membaca semua file lama, tetapi versi lama tidak selalu dapat membaca semua file baru. Dalam konteks Bitcoin:
- Aturan Baru: Node yang menjalankan perangkat lunak yang ditingkatkan (Soft Fork) memberlakukan set aturan baru yang lebih ketat.
- Aturan Lama: Node yang menjalankan perangkat lunak lama (pra-peningkatan) masih menerima transaksi yang divalidasi oleh node yang ditingkatkan, karena node yang ditingkatkan mengikuti subset dari aturan asli.
Misalnya, jika Soft Fork menyatakan bahwa semua blok sekarang harus sedikit lebih kecil daripada sebelumnya (memperketat aturan), node lama masih akan menganggap blok yang lebih kecil ini valid, karena masih mematuhi batas ukuran maksimum asli.
Soft Forks adalah metode peningkatan yang disukai untuk Bitcoin karena hanya memerlukan mayoritas jaringan (biasanya penambang yang mewakili 95% daya hash atau mayoritas node) untuk mengadopsi perubahan. Minoritas node lama yang tersisa dapat terus beroperasi tanpa memutus rantai, meskipun mereka mungkin tidak dapat memvalidasi sepenuhnya atau menggunakan fitur baru. Kompatibilitas mundur yang melekat ini sangat mengurangi risiko pemisahan rantai yang berantakan.
Hard Forks: Opsi Nuklir
Hard Fork adalah perubahan mendasar pada protokol yang membuat aturan baru tidak kompatibel dengan aturan lama. Ini memerlukan setiap peserta—penambang, node, dan dompet—untuk meningkatkan perangkat lunak mereka agar mengikuti konsensus baru.
Jika Hard Fork diaktifkan, jaringan secara harfiah terbelah menjadi dua rantai terpisah:
- Rantai Baru: Mengikuti set aturan baru (misalnya, ukuran blok yang jauh lebih besar).
- Rantai Lama: Melanjutkan mengikuti aturan asli.
Node yang belum ditingkatkan akan menolak blok apa pun yang dibuat di bawah aturan baru, menganggapnya tidak valid. Jika kelompok signifikan terus menambang dan memvalidasi rantai lama, dua versi Bitcoin terpisah akan ada secara bersamaan.
Hard Forks sangat mengganggu dan membawa risiko ekonomi yang sangat besar. Karena pemisahan bersifat permanen kecuali satu rantai sepenuhnya ditinggalkan, komunitas harus hampir bulat sebelum Hard Fork dicoba. Jika berhasil, pengguna di rantai lama tiba-tiba menemukan diri mereka memegang aset yang berpotensi tidak berharga, sementara rantai baru menjadi versi dominan Bitcoin. Ancaman pemisahan ekonomi berarti Hard Forks hanya disediakan untuk perbaikan krusial atau perubahan di mana kompatibilitas mundur tidak mungkin.
Ujian Tata Kelola: Mengapa Hard Forks Ditakuti
Fungsi utama Hard Fork dalam tata kelola Bitcoin adalah berfungsi sebagai pencegah besar terhadap konflik. Potensi pemisahan memaksa kepentingan yang bersaing—seperti penambang yang menginginkan biaya lebih tinggi versus pengguna yang memprioritaskan desentralisasi—untuk berkompromi.
Contoh klasik yang mengilustrasikan ketakutan ini terjadi selama perdebatan penskalaan 2017. Sebuah kelompok mencoba memaksa Hard Fork (dikenal sebagai SegWit2x) untuk meningkatkan batas ukuran blok secara signifikan. Usulan tersebut akhirnya gagal karena komunitas pengguna dan pengembang inti menolak risiko memecah merek dan likuiditas Bitcoin. Pasar membuat jelas bahwa mempertahankan identitas terpadu Bitcoin lebih berharga daripada mengakomodasi perubahan teknis yang kurang konsensus luar biasa.
Dinamika ini menunjukkan bahwa nilai ekonomi jaringan—kombinasi kepercayaan dan likuiditas—berfungsi sebagai batasan utama pada tata kelola. Kelompok apa pun yang mendorong Hard Fork berisiko kehilangan semua dukungan ekonomi jika komunitas yang lebih luas memutuskan untuk tetap pada rantai yang mapan dan terbukti.
Mencapai Konsensus: Penandaan, Audit, dan Penegakan
Meskipun pengembang menyusun kode dan memilih jenis fork, tindakan politik adopsi memerlukan proses tiga tahap yang kompleks yang melibatkan penambang, node penuh, dan mekanisme berbasis waktu. Interaksi penandaan (niat voting), audit (memeriksa kode), dan penegakan (menolak blok tidak valid) adalah jantung tata kelola terdesentralisasi.
Wawasan kunci di sini adalah bahwa kekuasaan terdistribusi: penambang mengusulkan, tetapi pengguna yang membuang.
Penambang vs. Node: Dua Bentuk Kekuatan Validasi
Dalam tata kelola Bitcoin, penting untuk membedakan antara dua jenis pemegang kekuasaan:
1. Penambang (Daya Hash)
Penambang, yang menjalankan algoritma Proof-of-Work (PoW), memiliki kekuasaan untuk membuat blok. Ketika Soft Fork diusulkan, pengembang mendefinisikan mekanisme bagi penambang untuk memberi sinyal dukungan mereka. Penandaan ini biasanya dilakukan dengan menanamkan data spesifik ("flag") ke dalam header blok yang mereka hasilkan.
Jika 95% dari semua blok yang ditambang dalam periode yang ditentukan memberi sinyal dukungan untuk Soft Fork, perubahan dianggap siap untuk diaktifkan. Penandaan penambang penting karena merekalah yang memberlakukan aturan baru saat membuat blok. Namun, penandaan penambang hanyalah niat untuk patuh, bukan otoritas akhir. Penambang dapat ditekan oleh insentif ekonomi untuk memberi sinyal dukungan, bahkan jika mereka tidak menyukai perubahan tersebut.
2. Node Penuh (Kekuatan Penegakan)
Node penuh adalah komputer yang menjalankan seluruh perangkat lunak Bitcoin, mengunduh dan memvalidasi setiap transaksi dan blok sejak awal jaringan. Node terutama dijalankan oleh pengguna, bursa, bisnis, dan dompet. Node tidak memberi sinyal dukungan seperti penambang; mereka memberlakukan aturan.
Jika penambang mengaktifkan perubahan yang dianggap tidak dapat diterima oleh mayoritas node, node akan menolak blok apa pun yang dibuat di bawah aturan baru yang tidak diinginkan. Dengan menolak blok tersebut, node secara efektif menghilangkan imbalan penambang, karena blok tersebut terlantun dan biaya transaksi hilang.
Intinya, penambang harus mengikuti aturan yang ditetapkan oleh node, karena jika node menolak blok mereka, upaya penambangan mereka sia-sia secara ekonomi. Node penuh berfungsi sebagai auditor dan penjaga gerbang utama kebijakan moneter.
Mekanisme Aktivasi: Peran Penandaan
Untuk mengelola proses aktivasi terdesentralisasi yang kacau, Soft Forks menggunakan mekanisme aktivasi terkunci waktu yang dirancang untuk memastikan kesiapan jaringan yang memadai.
Pendekatan umum melibatkan fase penandaan multi-periode, sering disebut penandaan "Flag Day":
- Awal Penandaan: Kode baru dirilis, dan penambang mulai memberi sinyal kesiapan mereka melalui header blok.
- Periode Ambang: Jaringan memantau jumlah blok tetap (misalnya, 2.016 blok, atau sekitar dua minggu).
- Aktivasi: Jika ambang yang diperlukan (misalnya, 95%) dari blok tersebut memberi sinyal kesiapan, jam mulai berdetak untuk lock-in sebenarnya. Beberapa ribu blok kemudian (memberikan periode tenggang), aturan baru diaktifkan secara permanen.
Mekanisme ini memastikan bahwa perubahan diterapkan secara dapat diprediksi dan hanya setelah demonstrasi dukungan yang jelas dan terukur dari sektor penambangan yang kuat secara ekonomi. Proses ini memformalisasikan kompromi politik: pengembang menulis kode, penambang memilih untuk aktivitasnya, dan pengguna menyiapkan node mereka untuk memberlakukannya.
User Activated Soft Forks (UASF): Saat Pengguna Mengambil Kendali
Keseimbangan kekuasaan diuji secara terkenal selama perdebatan seputar Segregated Witness (SegWit), sebuah Soft Fork yang dirancang untuk meningkatkan efisiensi transaksi. Ketika penambang menolak memberi sinyal untuk aktivasi SegWit, mengutip kekhawatiran ekonomi, komunitas harus membuktikan bahwa node penuh memegang kekuasaan utama.
Ini mengarah pada konsep User Activated Soft Fork (UASF).
UASF adalah Soft Fork di mana pemicu aktivasi didasarkan pada waktu, bukan penandaan penambang. Dalam UASF, node (pengguna) secara sepihak memutuskan tanggal mendatang untuk mulai memberlakukan aturan baru, terlepas dari apa yang disinyalkan oleh penambang.
Contoh paling terkenal adalah BIP 148, yang mengusulkan mengaktifkan SegWit pada tanggal tertentu. Node yang menjalankan BIP 148 menyatakan: "Setelah Tanggal X, kami hanya akan menerima blok yang memberi sinyal kesiapan SegWit."
Teori permainan di sini sangat krusial. Jika 51% daya hash menolak memberi sinyal, tetapi sebagian besar node yang relevan secara ekonomi (bursa, prosesor pembayaran, dompet utama) menjalankan perangkat lunak UASF, penambang akan menghadapi pilihan sulit:
- Terus menambang blok non-sinyal: Blok ini akan ditolak oleh node UASF, menyebabkan kerugian finansial.
- Mulai memberi sinyal dan mengadopsi aturan: Melestarikan pendapatan penambangan mereka dan selaras dengan konsensus pengguna.
Ancaman UASF berhasil memaksa kolam penambangan mengadopsi perubahan, menunjukkan bahwa dalam ekonomi politik terdesentralisasi Bitcoin, preferensi pengguna dan penegakan node mengalahkan penandaan penambang ketika situasi memanas. UASF memperkuat prinsip bahwa menjalankan node penuh adalah kekuatan veto akhir dalam ekosistem Bitcoin.
Studi Kasus dalam Tata Kelola Bitcoin: Pelajaran yang Dipelajari
Memeriksa peristiwa tata kelola yang berhasil dan penuh gejolak memberikan konteks krusial untuk memahami lingkungan gesekan tinggi perubahan protokol. Peristiwa ini adalah pertempuran ekonomi yang dilakukan melalui kode, membuktikan bahwa konsensus mahal dan memerlukan upaya politik yang signifikan.
SegWit (BIP 141): Studi tentang Gesekan dan Kompromi
Segregated Witness, atau SegWit, mungkin merupakan Soft Fork paling panas dalam sejarah Bitcoin. Diusulkan pada 2015 dan akhirnya diaktifkan pada 2017, perdebatan dua tahun menyoroti kesulitan luar biasa dalam membuat perubahan non-sepele.
Konflik: SegWit dirancang untuk memperbaiki malleability transaksi dan meningkatkan kapasitas transaksi secara tidak langsung. Namun, banyak kepentingan penambangan besar menentangnya, lebih memilih peningkatan Hard Fork langsung pada ukuran blok (usulan SegWit2x). Konflik ini secara mendasar bersifat politik: kepentingan penambangan terpusat versus kepentingan pengembang dan pengguna terdesentralisasi.
Resolusi: Resolusi melibatkan tiga strategi tata kelola paralel:
- Konsensus Pengembang (Pilihan Soft Fork): Pengembang bersikeras pada Soft Fork (BIP 141) untuk menghindari risiko pemisahan rantai.
- Konsensus Ekonomi (Perjanjian New York): Kompromi, terutama dengan bisnis terpusat, dicoba (SegWit2x), tetapi akhirnya gagal karena kurangnya adopsi pengguna.
- Kekuatan Pengguna (UASF/BIP 148): Ancaman UASF adalah faktor penentu. Dengan memberi sinyal kemauan pengguna untuk menolak blok non-kompatibel, pengguna menunjukkan bahwa mereka memegang kekuasaan utama atas aturan jaringan.
Keberhasilan SegWit membuktikan bahwa meskipun penambang dapat memperlambat aktivasi, mereka tidak dapat memblokir secara sepihak perubahan yang memiliki dukungan teknis dan pengguna yang luar biasa, terutama ketika infrastruktur krusial bergantung pada pembaruan tersebut.
Taproot (BIPs 340, 341, 342): Keberhasilan Tenang dari Speedy Trial
Bandingkan aktivasi SegWit yang penuh gejolak dengan Taproot, peningkatan utama yang diaktifkan pada 2021. Taproot memberikan peningkatan signifikan pada privasi, efisiensi, dan kemampuan smart contract. Berkat pelajaran dari SegWit, proses tata kelola untuk Taproot disederhanakan menggunakan metode aktivasi baru: Speedy Trial.
Mekanisme Speedy Trial: Alih-alih lock-in waktu tetap tipikal, Speedy Trial menetapkan ambang penandaan 90% selama periode dua minggu, tetapi juga menyertakan tanggal kedaluwarsa.
- Jika 90% penambang memberi sinyal dukungan dalam jendela tersebut, perubahan akan lock-in dengan cepat (keberhasilan Speedy Trial).
- Jika ambang tidak tercapai, proses akan gagal, memaksa komunitas kembali ke papan gambar—berpotensi mempertimbangkan pendekatan UASF yang kontroversial nanti.
Pendekatan terstruktur dan terbatas waktu ini memberikan tekanan pada penambang untuk mencapai konsensus dengan cepat, mengetahui bahwa kegagalan memberi sinyal akan memaksa kembali ke negosiasi tata kelola yang sulit. Taproot mencapai ambang penandaan 90% relatif cepat, menunjukkan bahwa ketika perubahan secara teknis solid, tidak kontroversial, dan didukung kuat oleh pengembang, jaringan dapat meningkatkan secara efisien.
Taproot membuktikan bahwa tata kelola Bitcoin sedang berevolusi. Meskipun masih berantakan, komunitas belajar menyusun insentif politik untuk mendorong aktivasi tepat waktu, sambil tetap mempertahankan persyaratan konsensus ambang tinggi.
Inti Desentralisasi: Mengapa Tata Kelola Harus Berantakan
Kami telah menetapkan bahwa tata kelola Bitcoin tidak ramping atau efisien. Ia sering lambat, menyiksa, dan sangat argumentatif. Ketidakefisienan ini, secara paradoksal, adalah sumber kekuatannya dan daya tariknya sebagai aset uang keras. Ketahanan terhadap perubahan memastikan integritas proposisi nilai inti: penerbitan yang andal, dapat diprediksi, dan terbatas.
Model tata kelola gesekan tinggi memastikan bahwa Bitcoin tetap terdesentralisasi secara politik, tidak mampu diarahkan oleh entitas korporat atau pemerintah tunggal yang kuat.
Biaya Perubahan vs. Nilai Prediktabilitas
Di dunia keuangan, ketidakpastian sama dengan risiko. Proposisi nilai Bitcoin didasarkan pada kebijakan moneter yang dikode keras—batas pasokan 21 juta koin. Jika aturan protokol mudah diubah, janji batas tetap ini akan dirusak.
Proses tata kelola memerlukan perubahan potensial untuk melewati rintangan besar pemeriksaan sosial, teknis, dan ekonomi. "Biaya perubahan" ini menjamin:
- Integritas Kebijakan Moneter: Hampir tidak mungkin mengubah batas pasokan 21 juta atau jadwal penerbitan tanpa menyebabkan pemisahan rantai katastrofik yang akan menghancurkan nilai ekonomi koin tersebut.
- Prediktabilitas: Bisnis, bursa, dan investor institusional dapat mengalokasikan modal ke ekosistem Bitcoin mengetahui bahwa aturan mendasar tidak akan berubah secara tidak terduga.
- Tanpa Kepercayaan: Pengguna tidak perlu mempercayai CEO atau Dewan Direksi untuk mempertahankan aturan; mereka mempercayai inersia politik dan pencegah ekonomi yang tertanam dalam model tata kelola.
Ketidakefisienan tata kelola adalah harga yang dibayar untuk mencapai finalitas moneter dan kepercayaan terdesentralisasi.
Teori Permainan Kepatuhan Protokol
Keamanan tata kelola Bitcoin pada akhirnya bergantung pada Teori Permainan—studi pengambilan keputusan strategis di antara entitas yang bersaing.
Setiap peserta dalam jaringan Bitcoin (penambang, pengembang, dan pengguna) memiliki insentif yang berbeda:
- Pengembang: Termotivasi untuk mengusulkan kode berkualitas tinggi dan aman yang melestarikan reputasi jaringan.
- Penambang: Termotivasi untuk memaksimalkan keuntungan, artinya mereka harus memilih rantai yang akan diterima oleh mayoritas pengguna (node), memastikan blok yang ditambang mereka mendapatkan imbalan.
- Pengguna (Node): Termotivasi untuk mempertahankan aturan yang mereka daftarkan awalnya, melestarikan integritas investasi mereka.
Ini menciptakan Nash Equilibrium di mana strategi optimal bagi setiap pihak adalah mematuhi aturan yang diberlakukan oleh node penuh. Jika entitas kuat apa pun mencoba memecah konsensus (misalnya, kolam penambangan yang mencoba mendorong Hard Fork kontroversial), hukuman ekonomi (memfork rantai dan menghancurkan likuiditas) sangat parah sehingga melebihi keuntungan teknis jangka pendek apa pun.
Oleh karena itu, proses berantakan tata kelola Bitcoin, yang ditandai oleh BIP, perdebatan kontroversial, dan ancaman User Activated Soft Forks yang selalu ada, bukan kegagalan desain. Ini adalah implementasi sukses keamanan kriptoekonomi, memastikan bahwa desentralisasi politik dipertahankan bersama desentralisasi teknis. Kode menjalankan uang, tetapi konsensus menjalankan kode.