ร่างแก้รัฐธรรมนูญคาร์ดาโนห้ามตั้ง Leios เป็น 0 ขัดแผนปิดฉุกเฉิน

ข้อห้ามตั้งค่าพารามิเตอร์ Leios เป็น 0 ในร่างแก้รัฐธรรมนูญของคาร์ดาโน (Cardano) ขัดกับข้อเสนอปิดระบบฉุกเฉิน โดยประเด็นอยู่ที่การปิดช่องทางประมวลผลธุรกรรมเพิ่มเติม ไม่ใช่การหยุดผลิตบล็อกทั้งเครือข่าย

อินเตอร์เซกต์ (Intersect) องค์กรในระบบนิเวศคาร์ดาโน ระบุในอัปเดตรายสัปดาห์เมื่อวันที่ 6 พฤศจิกายนว่า ข้อเสนอแก้รัฐธรรมนูญ CAP-12 ฉบับที่ 5 ไม่อนุญาตให้ตั้งค่าพารามิเตอร์ของลิเนียร์ ลีออส (Linear Leios) เป็น 0 ฉบับที่ 5 เผยแพร่เมื่อวันที่ 30 ตุลาคม และตัดข้อกำหนดการปิดระบบบนเชนออกจากเนื้อหารัฐธรรมนูญ ส่วนวิธีปิดการใช้งานยังอยู่ในแผนฮาร์ดฟอร์ก ขณะที่ค่าพารามิเตอร์ราว 30 ค่ายังอยู่ระหว่างการพิจารณา

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

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

คริปโตสเลต (CryptoSlate) รายงานว่า เควิน แฮมมอนด์ (Kevin Hammond) เสนอขั้นตอนปิดระบบเมื่อวันที่ 6 พฤศจิกายน โดยให้ตั้งค่า maxEndorserBlockTxsSize ซึ่งกำหนดขนาดธุรกรรมสูงสุดในบล็อก Endorser เป็น 0 เมื่อเกิดปัญหาเครือข่ายระดับความรุนแรง 1 หรือ 2 ข้อเสนอยังระบุให้ผ่อนปรนข้อกำหนดการแจ้งล่วงหน้าและข้อจำกัดความถี่ในการเปลี่ยนแปลง

อย่างไรก็ตาม ขั้นตอนขออนุมัติด้านธรรมาภิบาลและการใช้การเปลี่ยนแปลง ณ จุดแบ่งยุค (epoch) ยังคงเดิม ส่วนการเปิดลีออสอีกครั้งจะใช้ขั้นตอนเปลี่ยนพารามิเตอร์ตามปกติ

ข้อ PARAM-04a ในรัฐธรรมนูญคาร์ดาโนฉบับปัจจุบันกำหนดให้แจ้งล่วงหน้าโดยทั่วไป 90 วัน ก่อนเปลี่ยนพารามิเตอร์สำคัญต่อการทำงานของเครือข่าย โดยลดระยะเวลาดังกล่าวได้ในกรณีปัญหาระดับความรุนแรง 1 หรือ 2 ที่ผ่านการทบทวนทางเทคนิคอย่างรอบคอบ

ข้อยกเว้นนี้เกี่ยวข้องกับระยะเวลาแจ้งล่วงหน้า แต่ไม่ได้ยกเลิกข้อห้ามตั้งค่าเป็น 0 ใน CAP-12 ฉบับที่ 5 การใช้แผนปิดระบบฉุกเฉินจึงต้องปรับทั้งข้อยกเว้นเรื่องการแจ้งล่วงหน้าและการอนุญาตให้ตั้งค่าเป็น 0

ความคืบหน้าการพัฒนาและขั้นตอนปิดระบบฉุกเฉินเป็นคนละประเด็น ทีมฉันทามติของคาร์ดาโนระบุในรายงานการพัฒนาเมื่อวันที่ 3 พฤศจิกายนว่า ได้เพิ่มการสร้างบล็อก Endorser การตรวจสอบใบรับรอง และการส่งต่อการลงคะแนนเข้าในสาขาพัฒนาแล้ว

อินเตอร์เซกต์อธิบายว่า DijkstraNet เปลี่ยนไปใช้โปรโตคอลเวอร์ชัน 12 เมื่อวันที่ 2 พฤศจิกายน แต่โหนดเวอร์ชัน 11.2 ที่ใช้ยังไม่มีฟังก์ชันลีออสครบทั้งหมด การทดสอบรวมระยะแรกจะใช้ต้นแบบ Musashi 11.3 แยกต่างหาก

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

เงื่อนไขที่เสนอสำหรับการปิดระบบฉุกเฉินประกอบด้วยการยืนยันเป็นลายลักษณ์อักษรจากทีมพัฒนาลีออส การทดสอบปิดและเปิดระบบบนเครือข่ายทดสอบ Preview และ Preprod และการตรวจสอบความสอดคล้องของการติดตั้งในโหนดทุกชุด โดยเสนอให้ตรวจสอบเงื่อนไขเหล่านี้ก่อนใช้ขั้นตอนปิดระบบ

ฟอรัมคาร์ดาโนระบุในประกาศเมื่อวันที่ 2 พฤศจิกายนว่า ขณะนั้น CAP-12 ผ่านการแก้ไขมาแล้ว 20 ครั้ง และมีหัวข้ออภิปราย 32 รายการ พร้อมเชิญผู้ดำเนินการ Stake Pool (SPO) ผู้แทนรับมอบอำนาจ (DRep) และคณะกรรมการรัฐธรรมนูญเข้าร่วมพิจารณา

ข้อเสนอปิดระบบฉุกเฉินยังไม่ได้รับการรับรอง อินเตอร์เซกต์มีกำหนดจัดประชุมทบทวน CAP ครั้งถัดไปในวันที่ 12 พฤศจิกายน เวลา 14.00 น. (เวลาไทย)