Ini ialah editorial pendapat oleh Shinobi, seorang pendidik otodidak dalam ruang Bitcoin dan hos podcast Bitcoin yang berorientasikan teknologi.
Sangat mengejutkan, Bitcoiners berdebat hebat tentang cadangan perubahan ditetapkan untuk dimasukkan dalam keluaran Bitcoin Core yang seterusnya. Ikut serta ganti-dengan-yuran (RBF) ialah ciri dasar mempool yang dicadangkan pada tahun 2015 untuk memberi pengguna alat untuk menangani lonjakan cepat dalam yuran yang menyebabkan transaksi mereka tersekat tanpa disahkan dalam mempool untuk jangka masa yang panjang.
Jelas sekali, ini akan menjadi masalah untuk sebarang penggunaan Bitcoin jika volum urus niaga meningkat secara purata menjadi lebih tinggi secara konsisten daripada bilangan urus niaga yang boleh diproses dalam rantaian blok, jadi melainkan anda fikir perkara itu tidak akan berlaku. ini adalah fungsi yang diperlukan pada rangkaian.
Penggantian transaksi sebenarnya telah disertakan dan mungkin dalam keluaran asal perisian sebelum Satoshi Nakamoto hilang. Dia akhirnya melumpuhkan ciri itu kerana cara dia melaksanakannya pada asalnya mencipta vektor untuk serangan penafian perkhidmatan terhadap nod. Pelaksanaannya membenarkan penggantian mana-mana transaksi tanpa membayar yuran yang lebih tinggi, yang pada asasnya akan membolehkan pengguna menghantar transaksi dan kemudian mula menyiarkan jumlah penggantian tanpa had ke rangkaian. Ini jelas akan membenarkan spamming nod dengan jumlah data yang besar yang tidak memerlukan bukti kerja dan akan meningkatkan kos menjalankan nod.
Sejak beberapa tahun cadangan yang berbeza untuk penggantian transaksi yang diubah suai dan lebih selamat skim telah dibincangkan. Kami akan segera melalui semua ini.
RBF Penuh
Varian RBF yang paling mudah. Sebarang urus niaga boleh diganti selagi penggantian urus niaga asal membayar yuran yang lebih tinggi daripada yang digantikannya. Dengan cara itu, semua urus niaga boleh diganti, tetapi keperluan untuk membayar yuran yang lebih tinggi setiap kali anda menggantikannya menghalang spam yang tidak terhingga bagi versi baharu nod terlebih muatan transaksi.
First-Seen-Safe RBF
Ini dicadangkan membenarkan semua urus niaga diganti dalam mempool, dengan satu kaveat khas; semua output dalam urus niaga asal juga mesti disertakan dalam urus niaga gantian, termasuk output perubahan. Ia masih memerlukan peningkatan yuran untuk menggantikan transaksi, tetapi keperluan untuk mengekalkan output yang sama bermakna anda perlu menambah input baharu dan output perubahan kedua, kerana tiada output asal boleh diubah. Ini mengakibatkan transaksi yang lebih besar yang perlu membayar lebih dalam jumlah yuran untuk memastikan penggantian membayar kadar yuran yang lebih tinggi.
RBF tertunda
Berikut ialah cadangan untuk membenarkan sebarang transaksi digantikan dalam mempool, tetapi hanya selepas bilangan blok tertentu telah berlalu sejak nod melihat transaksi asal. Ideanya ialah ini akan membolehkan urus niaga yang tersekat dalam persekitaran bayaran tinggi diganti dan disahkan dengan lebih cepat, tetapi kelewatan masa dalam tempoh berapa lama ia boleh diganti akan menghalang percubaan perbelanjaan dua kali pengesahan sifar.
RBF Ikut serta
Inilah yang telah dilaksanakan pada tahun 2016 seperti yang ditakrifkan dalam BIP 125. Urus niaga hanya boleh digantikan jika mereka menetapkan bendera tertentu dalam urus niaga memilih untuk menggantikan, atau jika salah seorang daripada nenek moyang mereka melakukan dalam kes rantaian urus niaga yang tidak disahkan, untuk membolehkan orang yang menerima dana mengetahui sama ada urus niaga yang tidak disahkan akan berlaku atau tidak. boleh diganti dalam mempool.
Kontroversi besar hari ini ialah keluaran Teras seterusnya, 0.24, ditetapkan untuk memperkenalkan bendera dasar mempool RBF penuh. Apakah maksud ini? Ia akan memberi pengguna pilihan boleh dikonfigurasikan untuk menukar dasar mempool tempatan mereka daripada RBF ikut serta kepada RBF penuh; secara lalai pilihan akan dihentikan (nod akan menggunakan RBF penuh). Jadi mengapa orang ramai bertelagah dengan perubahan ini? Perniagaan yang menerima urus niaga pengesahan sifar bergantung pada majoriti terbanyak mempool nod yang enggan menggantikan urus niaga yang belum mengikut serta RBF dengan bendera transaksi. Mereka melakukan ini dengan menyambung secara taktikal nod mereka kepada sejumlah besar nod lain yang tersebar di seluruh rangkaian. Ini membolehkan mereka dengan cepat mengesan kehadiran transaksi perbelanjaan dua kali pada rangkaian, kerana ia perlu dilakukan hampir serta-merta jika transaksi tidak dibenderakan sebagai RBF untuk mempunyai peluang yang baik untuk membuatnya kepada pelombong. Perlu diingatkan juga bahawa setiap perniagaan di rangkaian tidak boleh melakukan ini tanpa menyibil rangkaian dengan berkesan. Perniagaan ini mendakwa bahawa RBF penuh”memecahkan”model perniagaan mereka menggunakan RBF. Malah ada yang mengkritik pembangun teras sebagai”memaksa”perubahan yang memberi kesan negatif kepada perniagaan ini.
Realiti mudahnya ialah perbelanjaan berganda telah dan sentiasa boleh dilakukan, ikut serta RBF atau RBF penuh tidak melakukan apa-apa untuk mengubahnya. Tambahan pula, hanya mencipta pilihan untuk menukar dasar mempool tempatan anda sendiri (yang dimatikan secara lalai) sama sekali tidak menentukan perubahan kepada sesiapa sahaja, ia adalah pilihan yang diberikan kepada pengguna untuk membuat pilihan sendiri. Pada penghujung hari apabila urus niaga mana yang sebenarnya akan dimasukkan ke dalam blok seterusnya, satu-satunya mempool yang penting ialah pelombong. Mempool nod pengguna individu tidak lain hanyalah rangkaian storan memori daisy dengan matlamat utama untuk menyebarkan semua transaksi yang belum disahkan itu kepada pelombong supaya mereka boleh dimasukkan ke dalam blok akhirnya.
Dasar Mempool digunakan sebagai sejenis mekanisme keselamatan lembut untuk menghalang serangan penafian perkhidmatan pada nod dan melindungi pengguna daripada menembak diri mereka sendiri dengan transaksi dan skrip yang rumit. Banyak jenis urus niaga adalah sah melalui konsensus, dibenarkan untuk dimasukkan ke dalam blok, tetapi tidak akan disampaikan oleh dasar mempool lalai nod. Walau bagaimanapun, ini tidak melakukan apa-apa untuk menghalang pengguna yang ditentukan daripada menyampaikan transaksi yang akan diabaikan oleh nod pada rangkaian terus kepada pelombong.
Itulah pokok persoalannya. Apa yang diperlukan ialah pelombong menyediakan API untuk menyerahkan urus niaga secara langsung kepada mereka, yang mana ramai sudah ada, dan sekatan dasar mempool merentas rangkaian tidak penting. Anda hanya boleh memberikan transaksi terus kepada pelombong dan memintas setiap peraturan apabila sesuatu boleh digantikan dalam mempool nod lain. Fikirkan tentang insentif itu — jika ada wang yang perlu dibuat dengan melombong kelas transaksi tertentu, tetapi mempool di seluruh rangkaian tidak akan menyampaikannya, apakah yang akan anda lakukan sebagai pelombong? Hanya terima mereka secara langsung. Lebih banyak subsidi dikurangkan dan yuran urus niaga berkembang sebagai peratusan hasil pelombong, semakin tidak dapat dielakkan bahawa pelombong hanya akan terus menerima penggantian yang membayar yuran yang lebih tinggi jika nod pada rangkaian tidak akan menyampaikannya secara tidak langsung. Ia tidak dapat dielakkan.
Perubahan ini tidak mengubah dasar mempool lalai untuk Bitcoin Core, ia hanya memberikan pilihan untuk pengendali nod individu untuk mengubah dasar mempool tempatan mereka jika mereka memilihnya.
Dan saya mungkin menambah, ini adalah pilihan yang sentiasa tersedia jika pengguna memilih untuk mengubah suai pelanggan mereka. Apa yang dilakukannya ialah membuat pilihan yang sentiasa tersedia kepada pengguna dengan lebih mudah untuk dilakukan. Insentif tidak dapat dielakkan membawa kepada keadaan di mana semua urus niaga akan diganti jika pelombong bertindak dengan cara yang rasional dari segi ekonomi — ia tidak dapat dielakkan. Satu-satunya persoalan mengenai perkara ini ialah, sekiranya perisian itu mencerminkan insentif tersebut, dengan cara membenarkan pengguna individu memutuskan sendiri dasar apa yang akan digunakan untuk mempool mereka, atau sekiranya orang hanya duduk dan membiarkan penyebaran urus niaga berpusat di sekitar penyerahan terus kepada pelombong diri mereka sendiri?
Keputusan akhir adalah sama, tetapi menunggu pelombong tertarik kepada penyerahan transaksi langsung akan mempunyai akibat yang sangat negatif. Ia akan mempunyai implikasi privasi untuk orang yang menyiarkan urus niaga ke rangkaian, dan ia boleh mempunyai akibat yang sangat negatif untuk keupayaan pengguna untuk memutuskan yuran yang perlu dibayar untuk transaksi. Jika sebahagian besar urus niaga yang belum selesai tidak lagi disiarkan secara terbuka merentas rangkaian, maka pengguna akan mempunyai pandangan yang tidak lengkap tentang siapa yang mereka bidaan untuk dimasukkan ke dalam blok. Pelombong juga boleh berbohong tentang pengagihan yuran untuk memberi insentif kepada pengguna untuk membayar lebih daripada yang mereka perlu.
Satu-satunya kelemahan sebenar untuk menyediakan pilihan ini ialah RBF penuh mungkin tidak berfungsi secara konsisten jika hanya sejumlah kecil rangkaian, termasuk pelombong, memilih untuk mendayakan RBF penuh. Walau bagaimanapun, ini pada asasnya tidak berbeza dari segi peralihan daripada peningkatan kepada SegWit. Dalam tempoh peralihan itu, nod yang tidak dinaik taraf tidak akan menyampaikan urus niaga SegWit kerana ia tidak dapat mengesahkannya, jadi dalam tempoh itu terdapat dinamik penyebaran yang sama yang tidak konsisten sehingga cukup pengguna dinaik taraf. Tetapi akhirnya, itu tidak mengubah fakta bahawa peningkatan adalah keputusan yang perlu dibuat oleh pengguna individu.
Akhirnya melawan RBF sepenuhnya hanyalah menafikan realiti insentif pada rangkaian. Tiada apa-apa yang ditentukan kepada sesiapa, pilihan konfigurasi hanya memberikan pengguna individu pilihan untuk dibuat sendiri. Saya merasa aneh bahawa pada masa yang sama, ramai orang mengabaikan realiti insentif untuk berhujah bahawa cara menerima pembayaran yang tidak selamat boleh disimpan selamat dengan menentang insentif, sama seperti orang yang berhujah bahawa pengguna perisian tidak boleh dibenarkan memilih cara untuk mengkonfigurasi perisian mereka sendiri.
Nod saya, peraturan saya, bukan?
Ini ialah siaran tetamu oleh Shinobi. Pendapat yang dinyatakan adalah milik mereka sepenuhnya dan tidak semestinya mencerminkan pendapat BTC Inc atau Majalah Bitcoin.
