Bitcoin Magazine
The Core Issue: Cluster Mempool, Masalah Lebih Mudah dalam Bagian-Bagian
Cluster Mempool1 adalah pengerjaan ulang lengkap tentang bagaimana mempool menangani pengorganisasian dan penyortiran transaksi, dikonseptualisasikan dan diimplementasikan oleh Suhas Daftuar dan Pieter Wuille. Desain ini bertujuan untuk menyederhanakan arsitektur secara keseluruhan, menyelaraskan logika penyortiran transaksi dengan insentif penambang, dan meningkatkan keamanan untuk protokol lapisan kedua. Ini digabungkan ke dalam Bitcoin Core dalam PR #336292 pada 25 November 2025.
Mempool adalah kumpulan besar transaksi tertunda yang harus dilacak oleh node Anda karena beberapa alasan: estimasi biaya, validasi penggantian transaksi, dan konstruksi blok jika Anda adalah penambang.
Ini adalah banyak tujuan berbeda untuk satu fungsi node Anda. Bitcoin Core hingga versi 30.0 mengatur mempool dengan dua cara berbeda untuk membantu fungsi-fungsi ini, keduanya dari sudut pandang relatif dari setiap transaksi yang diberikan: feerate gabungan melihat ke depan dari transaksi dan anak-anaknya (descendant feerate), dan feerate gabungan melihat ke belakang dari transaksi dan induknya (ancestor feerate).
Ini digunakan untuk memutuskan transaksi mana yang akan dikeluarkan dari mempool Anda ketika penuh, dan mana yang akan disertakan terlebih dahulu saat membuat template blok baru.
Ketika penambang memutuskan apakah akan menyertakan transaksi dalam blok mereka, node mereka melihat transaksi itu, dan semua ancestor yang harus dikonfirmasi terlebih dahulu agar valid dalam blok, dan melihat rata-rata feerate per byte di semua transaksi tersebut bersama-sama dengan mempertimbangkan biaya individu yang mereka bayarkan secara keseluruhan. Jika kelompok transaksi itu sesuai dengan batas ukuran blok sambil mengungguli yang lain dalam biaya, itu disertakan dalam blok berikutnya. Ini dilakukan untuk setiap transaksi.
Ketika node Anda memutuskan transaksi mana yang akan dikeluarkan dari mempool ketika penuh, ia melihat setiap transaksi dan anak-anak yang dimilikinya, mengeluarkan transaksi dan semua anak-anaknya jika mempool sudah penuh dengan transaksi (dan keturunannya) yang membayar feerate lebih tinggi.
Lihat grafik contoh transaksi di atas, feerate ditampilkan seperti dalam tanda kurung (ancestor feerate, descendant feerate). Penambang yang melihat transaksi E kemungkinan akan menyertakannya dalam blok berikutnya, transaksi kecil yang membayar biaya sangat tinggi dengan satu ancestor kecil. Namun, jika mempool node terisi, ia akan melihat transaksi A dengan dua anak besar yang membayar biaya relatif rendah, dan kemungkinan akan mengeluarkannya atau tidak menerima dan menyimpannya jika baru saja diterima.
Kedua peringkat, atau pengurutan, ini sepenuhnya bertentangan satu sama lain. Mempool harus secara andal menyebarkan apa yang akan ditambang penambang, dan pengguna harus yakin bahwa mempool lokal mereka secara akurat memprediksi apa yang akan ditambang penambang.
Mempool yang berfungsi dengan cara ini penting untuk:
Perilaku mempool saat ini tidak sepenuhnya selaras dengan realitas insentif penambangan, yang menciptakan titik buta yang dapat bermasalah untuk keamanan lapisan kedua dengan menciptakan ketidakpastian apakah transaksi akan sampai ke penambang, serta tekanan untuk saluran penyiaran non-publik ke penambang, yang berpotensi memperburuk masalah pertama.
Ini terutama bermasalah ketika mengganti transaksi yang belum dikonfirmasi, baik hanya untuk memberi insentif kepada penambang untuk menyertakan penggantian lebih cepat, atau sebagai bagian dari protokol lapisan kedua yang diterapkan on-chain.
Penggantian menurut perilaku yang ada menjadi tidak dapat diprediksi tergantung pada bentuk dan ukuran jaringan transaksi tempat transaksi Anda terjebak. Dalam situasi fee-bumping sederhana, ini dapat gagal menyebarkan dan mengganti transaksi, bahkan ketika menambang penggantian akan lebih baik bagi penambang.
Dalam konteks protokol lapisan kedua, logika saat ini memungkinkan peserta untuk berpotensi mengeluarkan transaksi ancestor yang diperlukan dari mempool, atau membuat tidak mungkin bagi peserta lain untuk mengirimkan transaksi anak yang diperlukan ke mempool di bawah aturan saat ini karena transaksi anak yang dibuat peserta jahat, atau pengeluaran transaksi ancestor yang diperlukan.
Semua masalah ini adalah hasil dari peringkat inklusi dan pengeluaran yang tidak konsisten dan ketidakselarasan insentif yang mereka ciptakan. Memiliki peringkat global tunggal akan memperbaiki masalah ini, tetapi mengurutkan ulang seluruh mempool secara global untuk setiap transaksi baru tidak praktis.
Transaksi yang saling bergantung adalah grafik, atau serangkaian "jalur" terarah. Ketika transaksi membelanjakan output yang dibuat oleh transaksi lain di masa lalu, ia terhubung dengan transaksi masa lalu itu. Ketika ia juga membelanjakan output yang dibuat oleh transaksi masa lalu kedua, ia menghubungkan kedua transaksi historis bersama-sama.
Ketika belum dikonfirmasi, rantai transaksi seperti ini harus memiliki transaksi sebelumnya dikonfirmasi terlebih dahulu agar yang kemudian valid. Lagi pula, Anda tidak dapat membelanjakan output yang belum dibuat.
Ini adalah konsep penting untuk memahami mempool, itu secara eksplisit diurutkan secara terarah.
Ini semua hanya grafik.
Dalam cluster mempool, konsep cluster adalah kelompok transaksi yang belum dikonfirmasi yang terkait langsung satu sama lain, yaitu membelanjakan output yang dibuat oleh yang lain dalam cluster atau sebaliknya. Ini menjadi unit fundamental dari arsitektur mempool baru. Menganalisis dan mengurutkan seluruh mempool adalah tugas yang tidak praktis, tetapi menganalisis dan mengurutkan cluster jauh lebih mudah dikelola.
Setiap cluster dipecah menjadi chunk, kumpulan kecil transaksi dari cluster, yang kemudian diurutkan berdasarkan feerate tertinggi per byte ke terendah, menghormati dependensi terarah. Jadi misalnya, katakanlah dari feerate tertinggi ke terendah, chunk dalam cluster (A) adalah: [A,D], [B,E], [C,F], [G, J], dan terakhir [I, H].
Ini memungkinkan pra-penyortiran semua chunk dan cluster ini, dan penyortiran yang lebih efisien dari seluruh mempool dalam prosesnya.
Penambang sekarang dapat dengan mudah mengambil chunk feerate tertinggi dari setiap cluster dan memasukkannya ke dalam template mereka, jika masih ada ruang mereka dapat turun ke chunk feerate tertinggi berikutnya, melanjutkan sampai blok kira-kira penuh dan hanya perlu mencari tahu beberapa transaksi terakhir yang dapat dimasukkan. Ini kira-kira metode konstruksi template blok yang optimal dengan asumsi akses ke semua transaksi yang tersedia.
Ketika mempool node penuh, mereka dapat dengan mudah mengambil chunk feerate terendah dari setiap cluster, dan mulai mengeluarkannya dari mempool mereka sampai tidak melebihi batas yang dikonfigurasi. Jika itu tidak cukup, ia pindah ke chunk feerate terendah berikutnya, dan seterusnya, sampai berada dalam batas mempoolnya. Dilakukan dengan cara ini menghilangkan kasus tepi aneh yang tidak selaras dengan insentif penambangan.
Logika penggantian juga sangat disederhanakan. Bandingkan cluster (A) dengan cluster (B) di mana transaksi K telah menggantikan G, I, J, dan H. Satu-satunya kriteria yang perlu dipenuhi adalah chunk baru [K] harus memiliki chunk feerate lebih tinggi dari [G, J] dan [I, H], [K] harus membayar lebih banyak dalam total biaya daripada [G, J, I, H], dan K tidak dapat melebihi batas atas berapa banyak transaksi yang digantikannya.
Dalam paradigma cluster, semua penggunaan yang berbeda ini selaras satu sama lain.
Arsitektur baru ini memungkinkan kami menyederhanakan batas kelompok transaksi, menghapus batasan sebelumnya tentang berapa banyak ancestor yang belum dikonfirmasi yang dapat dimiliki transaksi di mempool dan menggantinya dengan batas cluster global 64 transaksi dan 101 kvB per cluster.
Batas ini diperlukan untuk menjaga biaya komputasi pra-penyortiran cluster dan chunk mereka cukup rendah agar praktis bagi node untuk dilakukan secara konstan.
Ini adalah wawasan kunci sebenarnya dari cluster mempool. Dengan menjaga chunk dan cluster relatif kecil, Anda secara bersamaan membuat konstruksi template blok optimal menjadi murah, menyederhanakan logika penggantian transaksi (fee-bumping) dan karena itu meningkatkan keamanan lapisan kedua, dan memperbaiki logika pengeluaran, semuanya sekaligus.
Tidak ada lagi komputasi on the fly yang mahal dan lambat untuk pembangunan template, atau perilaku yang tidak dapat diprediksi dalam fee-bumping. Dengan memperbaiki ketidakselarasan insentif dalam cara mempool mengelola organisasi transaksi dalam situasi yang berbeda, mempool berfungsi lebih baik untuk semua orang.
Cluster mempool adalah proyek yang telah dikerjakan selama bertahun-tahun, dan akan membuat dampak material pada memastikan template blok yang menguntungkan terbuka untuk semua penambang, bahwa protokol lapisan kedua memiliki perilaku mempool yang sehat dan dapat diprediksi untuk dibangun, dan bahwa Bitcoin dapat terus berfungsi sebagai sistem moneter terdesentralisasi.
Bagi mereka yang tertarik untuk menyelami lebih dalam detail tentang bagaimana cluster mempool diimplementasikan dan bekerja di balik layar, berikut adalah dua thread Delving Bitcoin yang dapat Anda baca:
Tinjauan Implementasi Tingkat Tinggi (Dengan Rasional Desain): https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393
Cara Kerja Diagram Feerate Cluster Mempool: https://delvingbitcoin.org/t/mempool-incentive-compatibility/553
Dapatkan salinan The Core Issue Anda hari ini!
Jangan lewatkan kesempatan Anda untuk memiliki The Core Issue — menampilkan artikel yang ditulis oleh banyak Core Developer yang menjelaskan proyek yang mereka kerjakan sendiri!
Artikel ini adalah Surat dari Editor yang ditampilkan dalam edisi Cetak terbaru Bitcoin Magazine, The Core Issue. Kami membagikannya di sini sebagai pandangan awal tentang ide-ide yang dijelajahi di seluruh edisi lengkap.
[1] https://github.com/bitcoin/bitcoin/issues/27677
[2] https://github.com/bitcoin/bitcoin/pull/33629
Postingan ini The Core Issue: Cluster Mempool, Masalah Lebih Mudah dalam Bagian-Bagian pertama kali muncul di Bitcoin Magazine dan ditulis oleh Shinobi.


