ผู้จัดการสินทรัพย์เตรียมพร้อมสำหรับ XRPL Batch: ฟีเจอร์นี้ทำอะไรได้บ้าง?

คำมั่นสัญญาหลักนั้นเรียบง่าย: ทำให้ขั้นตอนที่เกี่ยวข้องกันชำระภายในรอบปิดบัญชีเดียว ผู้จัดการสินทรัพย์ที่ต้องส่งมอบโทเค็นและรับการชำระเงินอาจต้องการการแลกเปลี่ยนแบบทั้งหมดหรือไม่มีเลย มากกว่าการส่งสินทรัพย์ก่อนแล้วหวังว่าเงินจะมาถึง RippleX ได้อธิบายถึงผู้จัดการสินทรัพย์และโครงการเชิงพาณิชย์ที่เตรียมพร้อมสำหรับฟีเจอร์นี้ ตามที่กล่าวถึงในรายงานความสนใจจากสถาบันก่อนหน้านี้ แต่ไม่ได้เปิดเผยชื่อผู้จัดการสินทรัพย์ที่ใช้งานจริงซึ่งมีธุรกรรม Batch บนเมนเน็ตที่ใช้งานจริงในบัญชีของ RippleX

สถานะเปลี่ยนไปก่อนความคาดหมายเดิมในช่วงปลายเดือนกันยายน ประกาศการเปิดตัวของมูลนิธิ XRPL เรียกเวอร์ชัน 3.4.1 ว่าเป็นการอัปเดตเร่งด่วนสำหรับปัญหาที่เกี่ยวข้องกับความปลอดภัย โดยเพิ่ม fixBatchV1_2 ขอให้เซิร์ฟเวอร์อัปเกรดโดยเร็ว และระบุว่าการแก้ไขคาดว่าจะเปิดใช้งานในวันที่ 9 ตุลาคม หากการสนับสนุนแบบเสียงข้างมากยังคงอยู่ นั่นเป็นความคาดหวังแบบมีเงื่อนไข ไม่ใช่คำสัญญาเปิดตัวที่แน่นอน

Batch ประสานการดำเนินการภายในรอบการปิดบัญชีแยกประเภทเดียว

ข้อกำหนด XLS-0056 อธิบายธุรกรรมภายนอกที่บรรจุธุรกรรมภายในระหว่างสองถึงแปดรายการ บัญชีที่เกี่ยวข้องอนุมัติชุดธุรกรรม โหมดที่เลือกจะควบคุมสิ่งที่เกิดขึ้นเมื่อการดำเนินการภายในล้มเหลว บัญชีแยกประเภทประมวลผลชุดธุรกรรมในรอบการปิดบัญชีเดียว หลีกเลี่ยงช่องว่างระหว่างการส่งที่ไม่เกี่ยวข้องกันซึ่งอาจทำให้ผู้เข้าร่วมรายหนึ่งเหลือเพียงครึ่งหนึ่งของข้อตกลง

สมมติว่ากองทุนโอนสิทธิเรียกร้องพันธบัตรที่แปลงเป็นโทเค็นและรับโทเค็นดอลลาร์ ธุรกรรมปกติสองรายการสามารถส่งแยกกันได้ หากรายการแรกสำเร็จและรายการที่สองล้มเหลว คู่สัญญาจะมีข้อพิพาทด้านปฏิบัติการและอาจสูญเสีย ด้วยโหมดทั้งหมดหรือไม่มีเลย การดำเนินการภายในทั้งสองรายการต้องสำเร็จเพื่อให้การแลกเปลี่ยนที่ตั้งใจไว้เสร็จสมบูรณ์ นั่นคือกรณีการใช้งานของสถาบันที่น่าสนใจ โดยสมมติว่าโทเค็น เครื่องมือการชำระเงิน คู่สัญญา และสิทธิ์อนุญาตมีอยู่แล้ว

Batch ไม่ได้สร้างพันธบัตร ตรวจสอบความเป็นเจ้าของนอกเชน หรือบังคับให้ธนาคารไถ่ถอนโทเค็นการชำระเงิน แต่มันประสานการดำเนินการบนบัญชีแยกประเภท ความสมบูรณ์ทางกฎหมายของการชำระราคา ข้อจำกัดการโอน การดูแลรักษา และการไถ่ถอนยังคงขึ้นอยู่กับเครื่องมือและสถาบันที่เกี่ยวข้อง ความแตกต่างนี้สำคัญเพราะการโอนแบบอะตอมมิกทางเทคนิคเป็นเพียงส่วนหนึ่งของการส่งมอบเทียบกับการชำระเงิน (DvP)

คู่มือแบบบัญชีเดียวแสดงกรณีที่ตรงไปตรงมากว่า การดำเนินการหลายรายการจากบัญชีเดียวสามารถบรรจุในโหมดที่ระบุได้ ธุรกรรมหลายบัญชีเพิ่มลายเซ็นจากบัญชีที่ยอดคงเหลือหรือสิทธิ์ได้รับผลกระทบ คู่มือแบบหลายบัญชีอธิบายกระบวนการลงนามที่ประสานกันนั้น

สี่โหมดสร้างข้อตกลงที่แตกต่างกันสี่แบบ

"ALLORNOTHING" คือการค้าสองฝ่ายที่สะอาด การดำเนินการภายในที่จำเป็นทุกรายการต้องสำเร็จ มิฉะนั้นกลุ่มที่ตั้งใจไว้จะไม่ชำระ "ONLYONE" ลองทางเลือกและหยุดหลังจากสำเร็จครั้งแรก เช่น คำสั่งที่ค่าความคลาดเคลื่อนต่างกัน "UNTILFAILURE" ประมวลผลลำดับจนกว่าจะล้มเหลว "INDEPENDENT" อนุญาตให้การดำเนินการใน wrapper เดียวกันสำเร็จหรือล้มเหลวอย่างอิสระ การเรียกทั้งสี่โหมดว่าอะตอมมิกในความหมายทั่วไปจะซ่อนความเป็นไปได้ของการเสร็จสมบูรณ์บางส่วน

โหมดเหล่านี้เปลี่ยนแปลงการออกแบบผลิตภัณฑ์ กองทุนที่ย้ายสินทรัพย์สองรายการเทียบกับการชำระเงินหนึ่งรายการต้องตัดสินใจว่าการโอนที่ล้มเหลวรายการเดียวควรยกเลิกแพ็คเกจทั้งหมดหรือไม่ ผู้ดูแลสภาพคล่องที่ส่งข้อเสนอสำรองอาจชอบ "ONLYONE" ผู้ออกที่กระจายการจ่ายเงินหลายรายการอาจยอมรับผลลัพธ์อิสระ แต่ทีมปฏิบัติการต้องกระทบยอดว่าผู้รับรายใดได้รับเงิน โหมดนี้เป็นการตัดสินใจด้านความเสี่ยง ไม่ใช่ตัวเลือกการจัดรูปแบบ

ขีดจำกัดแปดแอคชันเป็นข้อจำกัดจริงอีกประการหนึ่ง ผู้จัดการที่พยายามชำระการโอนของผู้ลงทุน 1,000 รายไม่สามารถรวมทั้งหมด 1,000 รายการไว้ใน Batch เดียวภายใต้ข้อเสนอปัจจุบัน ที่ขั้นต่ำทางทฤษฎี 125 แพ็คเกจแปดแอคชัน กลุ่มเหล่านั้นจะไม่เป็นอะตอมมิกต่อกัน ค่าธรรมเนียม ลายเซ็น การจัดการลำดับบัญชี และความจุของบริการกลายเป็นข้อจำกัดในทางปฏิบัติก่อนที่จะพิจารณากระบวนการทางธุรกิจนอกเชน

รายงานทางเทคนิคก่อนหน้านี้กล่าวถึงการพัฒนาและประวัติการตรวจสอบที่ยาวนานของการอัปเกรด ภูมิหลังนั้นเกี่ยวข้องกับกำหนดเวลา แต่ไม่ควรสับสนกับการอ้างว่าแอปพลิเคชันทุกตัวที่สร้างขึ้นบนนั้นได้รับการตรวจสอบแล้ว

รหัสความสำเร็จภายนอกเป็นกับดักทางบัญชี

ข้อกำหนดระบุว่าธุรกรรม Batch ภายนอกสามารถรายงาน "tesSUCCESS" ได้แม้ว่าธุรกรรมภายในจะล้มเหลว ผลลัพธ์ภายนอกครอบคลุมการประมวลผลลำดับและค่าธรรมเนียม เพื่อทราบว่าการชำระเงินหรือการส่งมอบเกิดขึ้นหรือไม่ ซอฟต์แวร์ต้องตรวจสอบเมทาดาทาของธุรกรรมภายในและรหัสผลลัพธ์แต่ละรายการ นี่เป็นอันตรายต่อการบูรณาการที่ชัดเจนผิดปกติสำหรับสถาบันใดก็ตามที่ฝ่ายปฏิบัติการแปลสถานะความสำเร็จทั่วไปเป็นการเคลื่อนไหวของสินทรัพย์ที่บันทึกไว้

ลองนึกภาพฟีดการค้าที่อ่านเฉพาะผลลัพธ์ภายนอกและเครดิตลูกค้าด้วยหลักทรัพย์ที่แปลงเป็นโทเค็น หากการโอนภายในที่เกี่ยวข้องไม่สำเร็จ ฟีดและบัญชีแยกประเภทจะแยกออกจากกัน ระบบต้องเชื่อมโยงการดำเนินการภายในทุกรายการกับ parent และผลลัพธ์ของตนเอง ข้อกำหนดแนะนำให้ใช้ความสัมพันธ์ "ParentBatchID" ใน explorer และ indexer แผนกควรทดสอบความล้มเหลวในทุกโหมด ไม่ใช่เฉพาะเส้นทางที่สำเร็จ

ข้อผิดพลาดสามารถอยู่รอดจากการควบคุมปกติได้เพราะธุรกรรมภายนอกเป็นของจริงและมี ID ธุรกรรม ระบบการกระทบยอดที่สร้างขึ้นสำหรับหนึ่งธุรกรรมเท่ากับหนึ่งการดำเนินการทางธุรกิจอาจผ่านการตรวจสอบครั้งแรก การควบคุมที่เหมาะสมเชื่อมโยงคำสั่งทางธุรกิจกับโหมด แพ็คเกจที่ลงนามครบถ้วน ผลลัพธ์ภายในทุกรายการ และยอดคงเหลือสินทรัพย์ในที่สุด นั่นคืองานที่ผู้จัดการสินทรัพย์ต้องทำแม้ว่าเลเยอร์เครือข่ายจะถูกต้อง

เลขคณิตนั้นเรียบง่ายแต่เปิดเผย Batch สูงสุดที่มีธุรกรรมภายในแปดรายการคือการส่งภายนอกหนึ่งรายการ แต่ต้องมีการตรวจสอบผลลัพธ์อย่างน้อยแปดรายการ บวกกับการตรวจสอบค่าธรรมเนียมภายนอกและลำดับ สำหรับ 125 แพ็คเกจเต็มที่เป็นตัวแทนของการดำเนินการภายใน 1,000 รายการ ฝ่ายปฏิบัติการต้องการผลลัพธ์ระดับการดำเนินการ 1,000 รายการ ไม่ใช่ไฟสถานะสีเขียว 125 ดวง

การแก้ไขด้านความปลอดภัยเปลี่ยนเรื่องราวการเปิดใช้งาน

ประกาศของมูลนิธิเมื่อวันที่ 25 กันยายนระบุว่า fixBatchV1_2 ปฏิเสธธุรกรรมภายในที่มี wrapper ผิด และรวมการแก้ไขด้านความปลอดภัยและเสถียรภาพเพิ่มเติม โดยระงับซอร์สโค้ดชั่วคราวเนื่องจากลักษณะที่เกี่ยวข้องกับความปลอดภัยของการเปลี่ยนแปลง โดยสัญญาว่าจะเผยแพร่และ retrospective ในภายหลัง นั่นจำกัดความสามารถของบุคคลภายนอกในการตรวจสอบแพตช์ที่แน่นอนก่อนการเปิดเผย เป็นเหตุผลสำหรับการระบุแหล่งที่มาอย่างแม่นยำ ไม่ใช่เหตุผลที่จะคาดเดาเกี่ยวกับความสามารถในการโจมตีที่ยังไม่เปิดเผย

ประกาศระบุว่าเซิร์ฟเวอร์ที่ต่ำกว่า 3.4.1 จะถูกบล็อกการแก้ไขหากการแก้ไขเปิดใช้งานในขณะที่ยังไม่ได้อัปเกรด การโหวตของผู้ตรวจสอบและการอัปเกรดโหนดจึงมีความสำคัญต่อการเข้าถึงการใช้งานจริง องค์ประชุมที่ส่งสัญญาณสนับสนุนไม่เหมือนกับทุกกระเป๋าเงิน ผู้ดูแล สินทรัพย์ ผู้ให้บริการ API และเครื่องมือบัญชีพร้อมสำหรับ Batch การรายงานการอัปเกรดโหนด XRPL ก่อนหน้านี้แสดงให้เห็นผลกระทบเชิงปฏิบัติการของการบล็อกการแก้ไขในรุ่นก่อนหน้า

ยังมีประวัติที่นักข่าวไม่สามารถละเว้นได้ การเปิดเผยช่องโหว่ในเดือนกุมภาพันธ์อธิบายข้อบกพร่องในการออกแบบ Batch ก่อนหน้านี้ที่อาจข้ามการตรวจสอบการอนุญาตสำหรับผู้ลงนามรายอื่นเมื่อผู้ลงนามที่ไม่มีเงินปรากฏก่อน การแก้ไขยังไม่ได้เปิดใช้งาน บัญชีการตรวจสอบความปลอดภัยตรวจสอบว่าการตรวจสอบอิสระจับปัญหาก่อนการใช้งานจริงได้อย่างไร แพตช์เดือนกันยายนเกี่ยวข้องกับปัญหา wrapper ที่อธิบายแยกต่างหาก ทั้งสองเหตุการณ์ไม่ได้พิสูจน์ว่าการออกแบบปัจจุบันไม่ปลอดภัย แต่ทั้งคู่อธิบายว่าทำไมกำหนดการปรับใช้จึงสมควรได้รับการตรวจสอบ

สิ่งที่สถาบันอาจได้รับ และสิ่งที่ยังต้องการ

การส่งมอบแบบอะตอมมิกเทียบกับการชำระเงินเป็นกรณีที่แข็งแกร่งที่สุด ผู้จัดการสามารถประสานการโอนโทเค็นกับการชำระเงินบนบัญชีแยกประเภทเดียวกัน จำกัดความเสี่ยงชั่วคราวที่เกิดจากการโอนตามลำดับ ผู้ออกสามารถรวมขั้นตอนการตั้งค่าบัญชี การอนุญาต และการออกในที่ที่โปรโตคอลอนุญาตประเภทธุรกรรมเหล่านั้น บริษัทการค้าสามารถใช้เส้นทางการดำเนินการทางเลือก นี่คือความสามารถ ไม่ใช่หลักฐานของสินทรัพย์และการค้าจริง

สินทรัพย์ที่แปลงเป็นโทเค็นต้องการผู้ออก ตัวแทนโอน หรือหน่วยงานที่รับผิดชอบอื่นๆ กฎเกี่ยวกับผู้ถือที่มีสิทธิ์ ขั้นตอนการดูแลรักษา และเครื่องมือการชำระเงินที่มีเงื่อนไขการไถ่ถอนที่ยอมรับได้ Batch สามารถทำให้ขา on-chain ดำเนินการภายใต้กฎที่เลือกได้ แต่ไม่สามารถทำให้หลักทรัพย์ถูกต้องตามกฎหมายในเขตอำนาจศาลอื่น ได้รับความยินยอมจากลูกค้าสำหรับการดำเนินการที่ไม่เกี่ยวข้อง หรือรับประกันขาเงินสดภายนอกที่ธนาคารพาณิชย์

กรณีของ Ripple สมควรได้รับเวอร์ชันที่แข็งแกร่งที่สุด กลไกระดับบัญชีแยกประเภทสามารถลดงานประสานงานสำหรับนักพัฒนาและขจัดกลุ่มความล้มเหลวในการชำระบางส่วนที่แท้จริง ภาพรวมฟีเจอร์ XRPL อธิบาย Batch ควบคู่กับฟังก์ชันสถาบันอื่นๆ แม้ว่าการแก้ไขแต่ละรายการจะดำเนินตามกระบวนการของตนเอง หากผู้จัดการที่มีชื่อแสดงการชำระจริงซ้ำๆ ของสินทรัพย์ที่แปลงเป็นโทเค็นจริงพร้อมผลลัพธ์ภายในที่กระทบยอดอย่างถูกต้องในภายหลัง ข้ออ้างการนำไปใช้จะมีหลักฐานที่ชัดเจนรองรับ

ขีดจำกัดก็ชัดเจนเท่าเทียมกัน บริษัทที่เตรียมโครงการนำร่องไม่ใช่ผู้จัดการสินทรัพย์ที่ใช้ Batch ในการใช้งานจริง ไม่มีข้ออ้างการเตรียมการสาธารณะบอกเราถึงปริมาณ ค่าธรรมเนียมที่ประหยัดได้ ข้อพิพาทการชำระที่ป้องกันได้ หรือสถาบันใดรับภาระผูกพันนอกเชน ประกาศอาจเป็นจริงแต่ยังเร็วเกินไปที่จะสนับสนุนข้อสรุปที่ใหญ่กว่านั้น

การโหวตของบัญชีแยกประเภทเป็นเพียงการทดสอบความพร้อมแรก

การเปิดใช้งาน fixBatchV1_2 ที่คาดไว้ในวันที่ 9 ตุลาคมขึ้นอยู่กับการสนับสนุนจากผู้ตรวจสอบอย่างต่อเนื่อง ผู้ปฏิบัติงานต้องใช้ซอฟต์แวร์ที่เข้ากันได้ กระเป๋าเงินต้องแสดงการดำเนินการภายในทั้งหมดและโหมดที่เลือกให้ผู้ใช้เห็นก่อนรวบรวมลายเซ็น ตามที่ข้อกำหนดแนะนำ Indexer ต้องเปิดเผยผลลัพธ์ parent และ child ผู้ดูแลสินทรัพย์ต้องตรวจสอบนโยบายสำหรับลายเซ็นหลายบัญชี ผู้จัดการสินทรัพย์ต้องการการกระทบยอดและเอกสารทางกฎหมาย

ไม่มีเปอร์เซ็นต์เดียวที่แสดงความพร้อมทั้งหมดนั้น การโหวตของผู้ตรวจสอบวัดข้อตกลงต่อการเปลี่ยนแปลงโปรโตคอล การทดสอบการใช้งานจริงคือผู้ใช้จริงสามารถเตรียม ลงนาม ส่ง ตรวจสอบ และกู้คืนจาก Batch ที่ล้มเหลวโดยไม่มีบันทึกที่ไม่ตรงกันหรือไม่ คำถามเชิงพาณิชย์ที่ยังไม่มีคำตอบคือสถาบันใดที่มีชื่อจะแสดงกรณีการใช้งานที่ทำซ้ำได้เมื่อการแก้ไขและเครื่องมือเปิดใช้งานแล้ว