ข่าว 
ข้อมูลเหรียญ 
แนะนำสื่อ 
วง XRP Ledger (XRPL) เดินหน้าสู่ขั้นตอนโหวตของผู้ตรวจสอบเครือข่าย (validator) สำหรับข้อเสนอแก้ไข ‘PermissionDelegationV1_1’ โดยข้อเสนอนี้ถูกบรรจุไว้ในเวอร์ชัน xrpld 3.3.0 แล้ว แต่ยังไม่มีการยืนยันว่าจะถูกเปิดใช้งานบนเมนเน็ต
มูลนิธิ XRPL (XRPL Foundation) เปิดตัว xrpld 3.3.0 เมื่อวันที่ 6 สิงหาคมที่ผ่านมา โดยบรรจุ ‘PermissionDelegationV1_1’ เข้าไปด้วย ข้อเสนอแก้ไขใหม่นี้จะเข้ามาแทนที่ ‘PermissionDelegation’ เดิม และออกแบบมาเพื่อให้เจ้าของบัญชีสามารถมอบสิทธิ์ในการทำธุรกรรมบางส่วนให้กับบัญชีอื่นได้
การมอบสิทธิ์ในลักษณะนี้ใกล้เคียงกับระบบควบคุมการเข้าถึงตามบทบาท (role-based access control) ที่แบ่งสิทธิ์ตามบัญชีแต่ละราย เจ้าของบัญชีสามารถมอบสิทธิ์ให้บัญชีที่ใช้ในการปฏิบัติงานประจำ (operating account) ทำธุรกรรมเฉพาะบางประเภทเท่านั้น ขณะที่ ‘มาสเตอร์คีย์’ (master key) ซึ่งมีสิทธิ์เต็มสามารถเก็บไว้แบบออฟไลน์ได้
วิธีนี้ช่วยจำกัดขอบเขตสิทธิ์ของกุญแจที่ต้องเชื่อมต่อออนไลน์ตลอดเวลา ผู้มอบสิทธิ์สามารถกำหนดสิทธิ์ที่แตกต่างกันให้บัญชีตัวแทนหลายบัญชี หรือเพิกถอนสิทธิ์เมื่อจำเป็นได้เช่นกัน
ผู้ออกสเตเบิลคอยน์ (stablecoin) ถูกยกมาเป็นตัวอย่างการใช้งานด้วย งานที่ทำซ้ำบ่อย เช่น การอนุมัติ trustline ของผู้ใช้แต่ละราย สามารถมอบให้บัญชีปฏิบัติงานที่มีสิทธิ์จำกัดจัดการ ส่วนงานที่มีความอ่อนไหวสูง เช่น การออกโทเคน จะแยกไว้ให้มาสเตอร์คีย์ดูแลโดยเฉพาะ
เหตุผลที่ข้อเสนอแก้ไขใหม่ต้องผ่านการตรวจสอบความปลอดภัยอย่างละเอียด มาจากข้อบกพร่องของฟังก์ชันเดิม มูลนิธิ XRPL ระบุในรายงานช่องโหว่เมื่อเดือนกันยายน 2025 ว่า ระบบเคยประมวลผลข้อผิดพลาดด้านสิทธิ์ก่อนการตรวจสอบลายเซ็น ทำให้ธุรกรรมมอบสิทธิ์ที่ไม่ได้รับอนุญาตยังสามารถเรียกเก็บค่าธรรมเนียมจากบัญชีผู้เสียหายได้
ฟังก์ชันเดิมยังไม่เคยถูกเปิดใช้งานบนเมนเน็ต และมูลนิธิได้ขอให้ผู้ตรวจสอบเครือข่ายลงคะแนน ‘คัดค้าน’ ข้อเสนอแก้ไขเดิม ปัญหานี้ถูกตรวจพบในสภาพแวดล้อมพัฒนา (development environment) เมื่อวันที่ 15 กันยายน 2025
หัวใจของข้อบกพร่องนี้อยู่ที่ลำดับการประมวลผลระหว่างการตรวจสอบสิทธิ์กับการยืนยันลายเซ็น หากระบบตรวจสอบสิทธิ์ก่อนยืนยันลายเซ็น ธุรกรรมที่ไม่ได้รับอนุมัติแม้จะล้มเหลว ก็ยังอาจถูกหักค่าธรรมเนียมอยู่ดี ข้อเสนอแก้ไขใหม่จึงถูกผลักดันขึ้นมาเพื่อแก้โครงสร้างนี้โดยเฉพาะ
ในโค้ดปัจจุบัน ‘PermissionDelegationV1_1’ ถูกระบุว่าเป็นฟีเจอร์ที่รองรับแล้ว แต่ค่าการโหวตเริ่มต้นยังตั้งไว้ที่ ‘DefaultNo’ การที่ฟีเจอร์ถูกใส่เข้าไปในโค้ดกับการที่ฟีเจอร์ถูกเปิดใช้งานจริงบนเครือข่าย เป็นคนละขั้นตอนกัน
ข้อเสนอแก้ไขของ XRPL ทุกฉบับต้องผ่านการโหวตของผู้ตรวจสอบเครือข่ายเสมอ รายงานก่อนหน้านี้ของโทเคนโพสต์ก็เคยนำเสนอว่าข้อเสนอมอบสิทธิ์นี้ยังอยู่ระหว่างขั้นตอนของผู้ตรวจสอบเครือข่าย
ผู้ตรวจสอบเครือข่ายรายหนึ่งในชื่อ ‘Vet’ โพสต์ทาง X เมื่อวันที่ 8 ที่ผ่านมาว่า “โหวตสนับสนุน Permission Delegation” ทั้งนี้เป็นเพียงการแสดงจุดยืนของผู้ตรวจสอบเครือข่ายรายเดียว ไม่ได้สะท้อนผลโหวตรวมของเครือข่ายทั้งหมด หรือหมายความว่าเงื่อนไขการเปิดใช้งานครบถ้วนแล้วแต่อย่างใด
ด้านการควบคุมคุณภาพ ทีมพัฒนา RippleX ระบุว่าได้ทดสอบฟังก์ชันมอบสิทธิ์โดยเฉพาะ 179 รายการ และทดสอบการถดถอย (regression test) ของ xrpld ทั้งระบบอีก 5,088 รายการ รายงานระบุว่าในช่วงเวลาดังกล่าวไม่พบบั๊กร้ายแรงที่ยังแก้ไม่ได้ แต่ผลทดสอบนี้เป็นผลของโค้ดที่ถูกทดสอบเท่านั้น ไม่ใช่การยืนยันความเสถียรระยะยาวบนเมนเน็ตหรือการรับประกันว่าข้อเสนอแก้ไขจะถูกเปิดใช้งาน
ประเด็นนี้มีนัยสำคัญตรงที่เป็นการออกแบบโมเดลมอบสิทธิ์ที่เคยถูกระงับเพราะช่องโหว่ด้านความปลอดภัยขึ้นใหม่ มากกว่าจะเป็นการเพิ่มฟีเจอร์ใหม่เข้ามา การแบ่งสิทธิ์บัญชีให้ละเอียดขึ้นช่วยแยกงานปฏิบัติการทั่วไปออกจากงานที่ต้องใช้สิทธิ์สูงได้ก็จริง แต่การนำไปใช้งานจริงยังขึ้นอยู่กับขั้นตอนโหวตของเครือข่ายเป็นหลัก
เช่นเดียวกับข้อเสนอแก้ไขอื่น ๆ ที่บรรจุอยู่ใน XRP Ledger เวอร์ชัน 3.3.0 การที่ฟีเจอร์ถูกลงทะเบียนไว้ในโค้ด กับการที่ฟีเจอร์ถูกนำไปใช้จริงบนเมนเน็ต ไม่ควรถูกตีความว่าเป็นขั้นตอนเดียวกัน โทเคนโพสต์เคยรายงานถึงขั้นตอนตรวจสอบของข้อเสนอแก้ไขชุด 3.3.0 และช่วงก่อนเปิดใช้งานบนเมนเน็ตมาแล้วก่อนหน้านี้
ความคืบหน้าที่ยืนยันได้ในขณะนี้คือ ‘PermissionDelegationV1_1’ ถูกบรรจุอยู่ใน xrpld 3.3.0 แล้ว และผู้ตรวจสอบเครือข่ายบางส่วนแสดงจุดยืนสนับสนุน ส่วนผลโหวตทั้งหมดและการเปิดใช้งานจริงบนเมนเน็ตจะต้องรอดูขั้นตอนของผู้ตรวจสอบเครือข่ายที่ยังดำเนินต่อไป
ความคิดเห็น 0