Lompat ke konten
Financial Context Wiki

Hard Fork vs. Soft Fork: Kompatibilitas Aturan, Aktivasi, dan Perpecahan Rantai

Hard fork dan soft fork menggambarkan hubungan kompatibilitas yang berbeda antara aturan konsensus lama dan baru. Analisis secara terpisah kumpulan blok valid, aktivasi, penegakan node, perilaku produsen, kesiapan operasional, risiko replay, dan setiap perpecahan rantai.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Hard fork dan soft fork mengelompokkan perubahan aturan konsensus berdasarkan cara node yang sudah dan belum ditingkatkan menilai blok. Misalkan V_old adalah kumpulan blok yang diterima aturan lama dan V_new kumpulan yang diterima aturan baru. Soft fork mempersempit validitas sehingga V_new subset V_old: setiap blok yang valid menurut aturan baru juga valid menurut aturan lama, tetapi node lama tidak menegakkan batasan tambahan. Hard fork mengizinkan setidaknya satu blok valid baru yang ditolak node lama: exists b: b in V_new and b not in V_old. Kumpulan aturan hard fork dapat berupa perluasan atau tidak dapat dibandingkan; “hard” bukan sekadar blok lebih besar atau fitur lebih radikal.

Kompatibilitas ini tidak simetris. Dalam soft fork yang berhasil, node lama dapat tetap berada di rantai yang sama karena menerima blok dari penambang atau validator yang telah ditingkatkan. Namun, node lama dapat menerima sesuatu yang ditolak node baru sehingga jaminannya lebih lemah. Dalam hard fork, setelah produsen yang diperbarui membuat blok di luar kumpulan lama, node lama tidak dapat mengikutinya. Jika peserta yang penting secara ekonomi mempertahankan kedua aturan, dua jaringan dapat bertahan; jika satu sisi tidak memiliki dukungan efektif, dua aset tidak harus muncul.

Label tersebut menjelaskan aturan, bukan legitimasi tata kelola, keamanan, dukungan ekonomi, atau metode aktivasi. Proposal dapat disebut hard fork sebelum aktif, perubahan aktif dapat tidak menghasilkan perpecahan permanen, dan ketidakcocokan implementasi yang tidak disengaja dapat memecah rantai tanpa pemungutan suara. Sinyal produsen dapat mengoordinasikan kesiapan, tetapi tidak membuat blok yang ditolak aturan full node menjadi valid.

Jangan samakan fork konsensus dengan fork sementara di bawah aturan yang sama, reorganisasi rantai, fork repositori perangkat lunak, atau peningkatan aplikasi. Pertanyaan operasionalnya adalah jaringan, kumpulan aturan, syarat aktivasi, dan riwayat rantai mana yang diakui setiap node, dompet, bursa, kustodian, oracle, dan kontrak.

Cara menganalisis fork protokol

  1. Tetapkan identitas dan cakupan. Catat chain, network, client version, proposal aktivasi, genesis atau checkpoint terfinalisasi, hash blok terkini, dan lapisan terdampak. Nama yang sama pada testnet, mainnet, eksekusi, konsensus, atau aplikasi dapat berarti aturan berbeda.
  2. Bandingkan validitas konsensus. Daftar setiap aturan blok, transaksi, tanda tangan, transisi status, gas, stempel waktu, finalitas, atau fork choice yang berubah. Klasifikasikan objek perwakilan sebagai valid, invalid, atau unknown pada kedua versi; jangan simpulkan kompatibilitas dari catatan rilis saja.
  3. Buktikan hubungan kumpulan. Uji apakah semua objek valid baru tetap valid di bawah aturan lama. Jika ya, perubahan dapat kompatibel sebagai soft fork; jika satu blok valid baru tidak valid bagi aturan lama, node tersebut memerlukan transisi hard fork. Uji juga objek valid lama yang menjadi tidak valid.
  4. Reproduksi aktivasi. Verifikasi ketinggian, epoch, median waktu, ambang sinyal, jeda lock-in, syarat total difficulty, atau pemicu tata kelola dari spesifikasi dan kode yang digunakan. Sinyal, lock-in, aktivasi, dan penegakan adalah keadaan berbeda.
  5. Petakan perilaku peserta. Ukur bobot produksi yang telah diperbarui dan identifikasi full node, relay, dompet, bursa, kustodian, bridge, penerbit stablecoin, oracle, dan kontrak di setiap sisi. Hashrate atau stake saja tidak menentukan penerimaan ekonomi.
  6. Lacak perpecahan dan transaksi. Ikuti hash induk dan validitas di bawah kedua aturan. Periksa kebijakan konfirmasi, perbedaan mempool, perlindungan replay, format alamat, pengenal rantai, domain tanda tangan, jalur penarikan, dan apakah transaksi dapat berjalan di kedua cabang.
  7. Tetapkan kontrol operasional. Hentikan atau perpanjang penyelesaian ketika leluhur blok ambigu; lakukan peningkatan dan pencadangan dengan sengaja; rekonsiliasi saldo dan kewajiban per cabang; uji tanda tangan dan pemulihan secara offline; lanjutkan hanya setelah kriteria rantai, node, pihak lawan, dan finalitas terpenuhi.

Metode ini memisahkan empat peristiwa yang sering disatukan sebagai “fork”: proposal aturan, syarat aktivasi, divergensi rantai yang diamati, dan kelangsungan ekonomi satu atau beberapa cabang. Tidak ada yang otomatis membuktikan tahap berikutnya.

Contoh perhitungan

1. Kompatibilitas kumpulan valid

Misalkan aturan lama menerima 100 bentuk calon blok dan aturan baru hanya menerima 80. Jika seluruh 80 berada dalam kumpulan lama, hubungannya adalah soft fork; 20 bentuk lama lainnya ditolak node baru. Angka ini menjelaskan kumpulan, bukan probabilitas atau ambang pemungutan suara.

Sekarang anggap aturan baru menerima bentuk blok yang ditolak setiap node lama. Walaupun sebagian besar blok lain valid menurut kedua aturan, satu contoh tandingan itu memutus penerimaan mundur dan membuat transisi tidak kompatibel sebagai hard fork. Keberlanjutan perpecahan setelah blok muncul bergantung pada produsen, pengguna, dan infrastruktur ekonomi.

2. Aktivasi BIP 34 bukan definisinya

BIP 34 mewajibkan ketinggian blok dalam transaksi coinbase dan memakai mekanisme kesiapan bergulir. Ketika 750 of 1,000 blok sebelumnya adalah versi 2 atau lebih tinggi, node menolak blok versi 2 yang tidak valid; setelah 950 of 1,000, node menolak versi 1. BIP mencatat blok 227,835 sebagai blok versi 1 terakhir.

Ambang tersebut mengoordinasikan penerapan, tetapi bukan alasan perubahan itu soft fork. Kompatibilitas berasal dari node baru yang mempersempit penerimaan sementara klien lama tetap menerima blok yang patuh. Kemudian BIP 9 menetapkan status penerapan dan bit versi secara terpisah, menegaskan bahwa hubungan aturan dan mekanisme aktivasi adalah dua masalah.

3. Segregated Witness sebagai soft fork

BIP 141 memperkenalkan data witness dan memasukkan komitmen pohonnya melalui transaksi coinbase ke struktur komitmen blok yang ada. Node lama dapat menerima blok yang patuh tanpa memahami atau memvalidasi aturan witness baru, sedangkan node baru menegakkannya.

Itu adalah penerimaan mundur, bukan validasi setara. Node lama dapat melihat output yang diatur aturan baru sebagai kurang terbatas; pengguna yang mengandalkan properti keamanan baru memerlukan validasi yang diperbarui. “Perangkat lunak lama tetap berjalan” bukan analisis risiko lengkap.

4. DAO Fork Ethereum

EIP-779 mendokumentasikan DAO Fork pada blok mainnet 1,920,000. Perubahan status tidak reguler ini memindahkan saldo dari daftar akun L ke kontrak WithdrawDAO tanpa mengubah opcode EVM, format transaksi, atau struktur blok.

Node yang menerapkan transisi dan yang menolaknya menghitung status berbeda setelah batas. Hard fork tidak harus memperbesar blok atau menambah opcode: aturan transisi satu kali sudah dapat menimbulkan ketidakcocokan, dan dukungan berkelanjutan bagi kedua riwayat dapat mempertahankan jaringan terpisah.

Risiko dan kegagalan peninjauan

Kesalahan klasifikasi dan spesifikasi

  • Menyebut setiap ujung rantai pesaing sementara sebagai hard fork walaupun semua node memakai aturan sama dan fork choice biasa menyelesaikannya.
  • Mendefinisikan semua pelonggaran sebagai hard fork dan semua pembatasan sebagai soft fork tanpa menguji kumpulan blok nyata.
  • Menyamakan penerimaan mundur dengan keamanan penuh; node lama tidak menegakkan batasan soft fork baru.
  • Menyimpulkan konsensus dari nama merek, roadmap, catatan rilis, atau cabang repositori alih-alih kode dan parameter yang digunakan.
  • Mencampur peningkatan mainnet, testnet, eksekusi, konsensus, bridge, rollup, dan aplikasi.
  • Menganggap proposal, rilis klien, ambang sinyal, lock-in, dan aktivasi sebagai satu peristiwa.
  • Menganggap sinyal produsen sebagai suara yang mengikat pengguna, bursa, kustodian, atau full node.

Risiko perpecahan dan transaksi

  • Menganggap aktivasi menjamin perpecahan atau perpecahan menjamin dua aset likuid dan bertahan lama.
  • Hanya memakai ketinggian walau cabang dapat memiliki blok berbeda pada ketinggian sama; periksa hash dan leluhur.
  • Mengirim saat perpecahan tanpa memeriksa replay, pengenal rantai, domain tanda tangan, dan konstruksi khusus cabang.
  • Mengkredit setoran di satu cabang tetapi menyelesaikan kewajiban atau penarikan di cabang lain.
  • Mengandalkan satu explorer, RPC, atau label kustodian ketika penyedia dapat mengikuti aturan berbeda atau tertinggal.
  • Mengabaikan reorganisasi, finalitas macet, partisi peer, penambangan minoritas, equivocation, atau ketidaktersediaan data.
  • Menganggap ticker, kontrak, saldo stablecoin, harga oracle, atau klaim bridge mendapat dukungan penerbit yang sama di kedua cabang.

Risiko tata kelola dan operasional

  • Menyajikan kompatibilitas sebagai bukti legitimasi, desentralisasi, keamanan, atau dukungan ekonomi.
  • Meningkatkan node produksi tanpa binary reproducible, cadangan, batas rollback, uji migrasi, dan pemeriksaan hash independen.
  • Menganggap downgrade selalu aman setelah data status, format dompet, atau syarat slashing baru diperkenalkan.
  • Memindahkan kunci atau “mengklaim koin fork” dengan perangkat lunak tak terverifikasi yang dapat membocorkan rahasia atau mengulang tanda tangan.
  • Menganggap saldo snapshot langsung tersedia tanpa memeriksa maturitas, penguncian, status kontrak, dan kebijakan kustodi.
  • Menyimpulkan pajak, akuntansi, atau nilai sebelum kepemilikan, kendali, likuiditas, dan aturan setempat ditetapkan.

Kesalahpahaman umum

  • Hard fork selalu menciptakan koin baru. Aset kedua memerlukan produksi berkelanjutan, pengguna, infrastruktur, dan pasar; banyak peningkatan berakhir pada satu riwayat.
  • Soft fork bebas risiko karena node lama tetap bekerja. Node dapat mengikuti rantai, tetapi tidak menegakkan aturan baru dan validasinya lebih lemah.
  • Mayoritas hashrate atau stake dapat mengubah aturan apa pun sendiri. Full node menolak blok yang tidak valid menurut aturannya; bobot hanya bekerja di antara blok yang diterima.
  • Hard berarti kontroversial dan soft berarti bulat. Istilah mengklasifikasikan kompatibilitas, bukan konsensus sosial, mutu tata kelola, atau kontroversi.
  • Setiap fork di explorer adalah peningkatan protokol. Blok pesaing dengan aturan sama dan reorganisasi terjadi tanpa perubahan konsensus.

Topik terkait

Sumber

Navigasi

Cari di wiki...