อัปเดต Bitcoin Core v32.0rc1 ปรับโปรโตคอลวอลเล็ต เสี่ยงกระทบการทำงานของแอป

Bitcoin Core v32.0rc1 กำลังทำให้ช่วงเวลา 14 ก.ย.–10 ต.ค. กลายเป็นสนามทดสอบความเข้ากันได้แบบเร่งด่วนสำหรับผู้ดูแลโหนด ผู้ให้บริการวอลเล็ต และบริการต่างๆ ที่พึ่งพาอินเทอร์เฟซ RPC ของ Bitcoin Core โดยรุ่นผู้สมัคร (release candidate) ถูกแท็กพร้อมลายเซ็นที่ยืนยันแล้วเมื่อ 14 ก.ย. ขณะที่กำหนดการปล่อยเวอร์ชันระบุเป้าหมายแท็กสุดท้าย v32.0 ในวันที่ 10 ต.ค. รวมช่วงห่าง 26 วัน CryptoSlate เคยพรีวิวในเดือนส.ค. ว่าจะตั้งเป้า RC1 วันที่ 10 ก.ย. แต่กำหนดการล่าสุดขยับเป็น 14 ก.ย. ทำให้ต่างกัน 4 วัน โดยยังไม่ใช่หลักฐานว่าพลาดเดดไลน์เดิม และแท็ก v32.0rc1 เป็นซอฟต์แวร์ก่อนปล่อยจริง ไม่ใช่อัปเกรด production ขั้นสุดท้าย อีกทั้งไม่ได้บ่งชี้การเปิดใช้กฎคอนเซนซัสใหม่ การเปลี่ยนแปลงหนึ่งที่ผูกกับร่าง BIP 323 กระทบวิธีที่ Bitcoin Core จัดการบิตการส่งสัญญาณ (signaling bits) และคำเตือนการดีพลอยที่ไม่รู้จัก (unknowndeployment warnings) แต่ข้อเสนอยังอยู่สถานะ Draft ผู้ดูแลระบบสามารถเริ่มทดสอบตามแนวทางในคู่มือทดสอบ RC ล่าสุดของ Bitcoin Core โดยทดลองฟีเจอร์ที่ใช้งานประจำในไดเร็กทอรีข้อมูลชั่วคราวที่แยกกัน และเปรียบเทียบกับรุ่นก่อนหน้า หน้าโหลดอย่างเป็นทางการยังระบุ 31.1 เป็นฐานปัจจุบัน การเปรียบเทียบจะช่วยจับความต่างด้านการสตาร์ตโหนด พฤติกรรมวอลเล็ต และการตอบกลับ RPC โดยไม่ปฏิบัติต่อ RC เสมือนอัปเดต production ทั่วไป ในร่างบันทึกการเปลี่ยนแปลง v32 ประเด็นด้านประสิทธิภาพที่เด่นสุดคือการ prefetch เอาต์พุตธุรกรรมแบบขนานระหว่างเชื่อมบล็อก (block connection) ค่าเริ่มต้นตั้งไว้ 8 worker ปรับได้สูงสุด 16 และปิดได้ ผู้ดูแลโหนดควรทดลองตรวจสอบบล็อกแบบผูกกับดิสก์ (disk-bound validation) ด้วยหลายค่าตั้ง เพื่อดูว่าความเร็วที่เพิ่มขึ้นแลกกับต้นทุน CPU หน่วยความจำ หรือความหน่วงสตอเรจที่สูงเกินรับไหวบนฮาร์ดแวร์ของตนหรือไม่ ด้านวอลเล็ตและการเชื่อมต่อบริการภายนอกมีความเสี่ยง "พัง" แยกต่างหาก RPC 4 รายการจะเปลี่ยนไปใช้ PSBTv2 เป็นค่าเริ่มต้น ขณะที่อินเทอร์เฟซอื่นๆ ตัดฟิลด์ที่เลิกใช้ หรือปฏิเสธอาร์กิวเมนต์ที่เวอร์ชันเก่าเคยยอมรับ ทีมที่สร้าง แปลง หรือทำ feebump ให้ PSBT จึงควรไล่เส้นทางธุรกรรมผ่านตัวแยก (parser) และตัวลงนาม (signer) ที่อยู่ปลายทางทั้งหมด การจัดการค่าธรรมเนียมก็ต้องทดสอบเส้นทางล้มเหลว (failure path) ด้วย ค่าเริ่มต้นของ estimatesmartfee จะรวมตัวประมาณการจาก blockpolicy และ mempool อาจได้ค่าประมาณที่ต่ำลง และอาจเกิดข้อผิดพลาดหากองค์ประกอบใดองค์ประกอบหนึ่งล้มเหลว ผู้ดูแลควรสังเกตทั้งตอนเริ่มระบบและช่วง mempool เบาบางหรือมีปัญหา แล้วตรวจว่าระบบมอนิเตอร์และ fallback ไปใช้ blockpolicy แบบกำหนดชัดทำงานตามคาด การเขียนใหม่ของ HTTP server ทำให้ขอบเขตการทดสอบกว้างกว่าแค่ตัวโหนด โดยเพิ่มเพดานขนาดเฮดเดอร์ 8,192 ไบต์ เข้มงวดขึ้นกับเฮดเดอร์ที่ผิดรูปแบบ กำหนดเพดานเริ่มต้นการเชื่อมต่อ RPC ไว้ 16 เพิ่มการควบคุมแคชสำหรับ REST และตัดการเชื่อมต่อทันทีสำหรับไคลเอนต์ที่ไม่มีสิทธิ์ การเปลี่ยนแปลงเหล่านี้อาจโผล่ในรีเวิร์สพร็อกซี ระบบตรวจสุขภาพ (health check) พูลไคลเอนต์ และตัวจัดการข้อผิดพลาด ประเด็นการโรลแบ็กก็สำคัญไม่แพ้กัน ดัชนีธุรกรรมที่สร้างใหม่ใช้พื้นที่ดิสก์น้อยกว่าครึ่ง แต่รีลีสเก่าอ่านฟอร์แมตใหม่ไม่ได้ ทำให้การดาวน์เกรดอาจบังคับให้สร้างใหม่อีกครั้งและใช้เวลาหลายชั่วโมง ผู้ดูแลที่เน้นความเป็นส่วนตัวควรทดสอบซ้ำเส้นทางล้มเหลวของ private broadcast ที่เกี่ยวกับการแก้ Tor fallback รวมถึงคิว 10,000 รายการ เพดานความพยายาม 1,000 ครั้ง และพฤติกรรมการรีเลย์ภายใต้โหลด เมื่อแท็กสุดท้ายยังเป็นเพียงเป้าหมาย กรณีขอบ (edge cases) เหล่านี้จึงเป็นงานหลักในหน้าต่าง RC ที่ควรเก็บให้ครบถ้วน