Stripe และ Paradigm ร่วมพัฒนาเครือข่ายบล็อกเชนเลเยอร์ 1 ชื่อ Tempo โดยเมื่อวันที่ 31 พฤษภาคม ได้นำเสนอข้อเสนอ TIP-1061 สำหรับบัญชีมัลติซิกแบบเนทีฟ มีแผนจะนำมัลติซิกมาเป็นประเภทบัญชีหลักของเลเยอร์โปรโตคอลในเครือข่าย โดยไม่จำเป็นต้องติดตั้งกระเป๋าเงินสัญญาอัจฉริยะอย่าง Safe เพื่อให้ควบคุมมัลติซิกได้ TIP-1061 มุ่งเป้าไปที่กรณีใช้งานอย่าง DAO ภาคสถาบัน และโหนดตรวจสอบ (verification nodes) โดยยังอยู่ในขั้นร่าง
สเปกทางเทคนิคที่ยืนยันแล้ว
การออกแบบหลักของ TIP-1061 ประกอบด้วยรายละเอียดทางเทคนิคที่ยืนยันแล้วดังต่อไปนี้ ที่อยู่ของบัญชีมัลติซิกได้มาจากแฮชของการกำหนดค่าเริ่มต้น (config_id) และเมื่อมีการปรับเปลี่ยนรายชื่อสมาชิก ค่าน้ำหนักลายเซ็น หรือเกณฑ์ (threshold) ในภายหลัง ที่อยู่ของบัญชียังคงไม่เปลี่ยนแปลง
รองรับประเภทลายเซ็น 3 แบบ ได้แก่ Secp256k1, P256 และ WebAuthn รองรับมัลติซิกแบบ M-of-N (โดยผู้ถือแต่ละรายมี weight=1) และมัลติซิกแบบถ่วงน้ำหนัก (การให้สิทธิแบบไม่สมมาตร) เช่น ผู้ถือที่มีน้ำหนักสูง (weight=100) อนุญาตได้ลำพัง หรือผู้ถือที่มีน้ำหนักระดับกลางสองราย (แต่ละราย weight=50) ต้องร่วมกันจึงจะอนุญาตได้ บัญชีมัลติซิกแต่ละบัญชีอนุญาตผู้ถือสูงสุด 10 ราย (MAX_MULTISIG_OWNERS=10)
ข้อจำกัดด้านการออกแบบ: ไม่รองรับ AccountKeychain และ EIP-7702
TIP-1061 ระบุชัดว่า บัญชีมัลติซิกแบบเนทีฟไม่รองรับการเข้าถึงคีย์ผ่าน AccountKeychain หาก msg.sender เป็นบัญชีมัลติซิกแบบเนทีฟ ตัวปรับเปลี่ยน (modifier) การเรียกด้วย AccountKeychain จะต้องถูกปฏิเสธ ข้ออธิบายด้านการออกแบบของข้อเสนอนี้คือ: การอนุญาตให้คีย์ผู้ได้รับสิทธิ์รายเดียวทำการเรียกในฐานะบัญชีพ่อ (parent account) จะทำให้คีย์ส่วนตัวดั้งเดิมกลายเป็นความสามารถถาวรที่ใช้ทำหน้าที่เป็นที่อยู่มัลติซิกได้ภายในขอบเขตการอนุญาตใด ๆ ซึ่งไม่สอดคล้องกับหลักการออกแบบของ “ตัวตนที่ควบคุมด้วยจำนวนผู้มีสิทธิ์ตามที่กฎหมายกำหนด”
นอกจากนี้ หลังจากการบูตสแตรป (Bootstrap) แล้ว บัญชีมัลติซิกแบบเนทีฟจะติดตั้งโค้ดไบต์ EVM หรือโค้ดมอบหมาย (delegate) ตาม EIP-7702 ไม่ได้
สถานะของร่าง: ยังรอการยืนยันในประเด็นที่ยังไม่ชัดเจน
ข้อเสนอยังคงเป็นร่าง โดยแผนการคำนวณ gas (เอกสารระบุว่า “สิ่งที่ต้องดำเนินการ”) และที่อยู่สัญญาแบบคอมไพล์ล่วงหน้าของมัลติซิก (จะถูกกำหนดก่อนที่ข้อเสนอจะหลุดพ้นจากสถานะร่าง) ยังไม่ได้ข้อสรุปขั้นสุดท้าย ข้อเสนอกำหนดว่า ก่อนที่ TIP-1061 จะเริ่มใช้งานและมีผลบังคับใช้ ธุรกรรมทั้งหมดที่มี TempoSignature::Multisig ต้องถูกปฏิเสธ และธุรกรรมทั้งหมดที่มีฟิลด์ multisig_init ต้องถูกปฏิเสธเช่นกันก่อนเริ่มทำงานของข้อเสนอ
คำถามที่พบบ่อย
ความแตกต่างโดยแก่นแท้ของมัลติซิกแบบเนทีฟของ TIP-1061 กับกระเป๋าเงินแบบสัญญา เช่น Safe คืออะไร?
TIP-1061 ยกระดับการตรวจสอบมัลติซิกขึ้นสู่ระดับโปรโตคอล ทำให้ไม่จำเป็นต้องติดตั้งกระเป๋าเงินแบบสัญญาอัจฉริยะอย่าง Safe บนเชนเพื่อให้ได้ความสามารถควบคุมด้วยเกณฑ์ (threshold) ที่เทียบเท่ากัน ช่วยขจัดต้นทุนการติดตั้งสัญญา และเมื่อที่อยู่บัญชีถูกได้มาจากการกำหนดค่าเริ่มต้นแล้ว ที่อยู่จะคงเสถียรไม่เปลี่ยนตามการอัปเดตสมาชิก
เหตุใดที่อยู่ของบัญชีมัลติซิกจึงยังคงไม่เปลี่ยนหลังอัปเดตสมาชิก?
ที่อยู่ของบัญชีมัลติซิกได้มาจากแฮชของ config_id โดย config_id คำนวณจากชุดผู้ถือเริ่มต้น (รวมถึงที่อยู่ ประเภทลายเซ็น และน้ำหนัก) และเกณฑ์ เมื่อบัญชียังอยู่ ที่อยู่จะไม่เปลี่ยนแปลง การเรียก updateMultisigConfig ในภายหลังจะอัปเดตเฉพาะค่าการกำหนดค่าปัจจุบันที่จัดเก็บไว้เท่านั้น ไม่ได้เปลี่ยนตัว config_id เองหรือที่อยู่บัญชีที่ถูกได้มาจากมัน
กรณีใช้งานเป้าหมายหลักของ TIP-1061 คืออะไร?
ส่วนแรงจูงใจของข้อเสนอระบุชัดว่ากรณีใช้งานเป้าหมายคือผู้ที่ต้องการ “ความสามารถที่ไม่ทำให้คีย์ส่วนตัวเพียงคีย์เดียวสามารถโอนเงินหรือเปลี่ยนแปลงการตั้งค่าการทำงานได้โดยลำพัง” โดยตัวอย่างได้แก่ ทีม (Teams), ฝ่ายการเงิน (Treasury), โหนดตรวจสอบ (Validators) และผู้ดำเนินการระดับสถาบัน (Institutional Operators)
