Toccata Hard Fork ของ Kaspa: Covenants, ZK Opcodes และเป้าหมายใหม่ในเดือนมิถุนายน

คาสปาการอัปเกรด Toccata ที่กำลังจะเกิดขึ้นจะเพิ่มเส้นทางการเขียนโปรแกรมใหม่สองเส้นทางให้กับเครือข่าย ได้แก่ การเขียนโปรแกรมแบบ L1 covenant ดั้งเดิม และโครงสร้างพื้นฐานแอปพลิเคชันแบบ zero-knowledge (zk) โดยกำหนดการเปิดใช้งาน mainnet อยู่ระหว่างวันที่ 5-20 มิถุนายน 2026 ซึ่งเลื่อนมาจากเป้าหมายเดิมในวันที่ 5 พฤษภาคม

ไมเคิล ซัตตัน จาก Kaspa Core ได้เผยแพร่บทความหนึ่ง การอัปเดตโดยละเอียด บทความนี้จะกล่าวถึงสิ่งที่การฮาร์ดฟอร์กครั้งนี้ครอบคลุม เหตุผลที่เลื่อนวัน และคาดการณ์ว่าอีกไม่กี่เดือนข้างหน้าจะเป็นอย่างไร การฮาร์ดฟอร์กครั้งนี้เริ่มต้นโดย Ori Newman โดยมีจุดประสงค์เพื่อนำข้อตกลง (covenants) เข้ามาในกลไกสคริปต์ของ Kaspa ซึ่งส่วนหนึ่งเป็นการตอบสนองต่อการพูดคุยเรื่อง OP_CAT ในแวดวง Bitcoin และต่อมาได้ขยายใหญ่ขึ้นอย่างมาก

Toccata Hard Fork คืออะไร?

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

ชื่อนี้สืบทอดธรรมเนียมของ Kaspa ในการใช้ชื่อที่อ้างอิงถึงดนตรีเพื่อการอัปเกรดครั้งสำคัญ โดยชื่อของรุ่นนี้มาจากรูปแบบดนตรีคลาสสิกอย่าง โทคคาตา (toccata) ซึ่งเป็นบทเพลงที่ออกแบบมาเพื่อแสดงทักษะทางเทคนิคในการเล่นเครื่องดนตรีประเภทคีย์บอร์ด

โดยสรุปแล้ว Toccata เพิ่มสิ่งสองอย่างให้กับ Kaspa:

• การเขียนโปรแกรมพันธสัญญา L1 ดั้งเดิม โดยใช้คอมไพเลอร์ตัวใหม่ที่เรียกว่า Silverscript
• โครงสร้างพื้นฐานแอปพลิเคชัน zkสร้างขึ้นบนรากฐานแห่งพันธสัญญาเดียวกันนั้น

ระบบเหล่านี้ไม่สามารถใช้ทดแทนกันได้ เนื่องจากมีวัตถุประสงค์การใช้งานที่แตกต่างกันและกลุ่มเป้าหมายนักพัฒนาซอฟต์แวร์ก็แตกต่างกันด้วย

พันธสัญญาคืออะไร และเหตุใดจึงมีความสำคัญต่อคาสปา?

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

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

เพื่อให้การพัฒนาข้อตกลง (covenant) เข้าถึงได้ง่ายยิ่งขึ้น Kaspa Core กำลังดำเนินการขั้นสุดท้ายสำหรับ Silverscript ซึ่งเป็นคอมไพเลอร์ที่ริเริ่มโดย Ori Newman, Michael Sutton, IzioDev และ Manyfest Silverscript ได้รับการออกแบบมาเพื่อให้การเขียนและใช้งานข้อตกลงที่ซับซ้อนบน Kaspa L1 ทำได้ง่ายและปลอดภัยยิ่งขึ้น โดยไม่ต้องให้ผู้พัฒนาทำงานในระดับสคริปต์เอนจินโดยตรง

แอปพลิเคชัน ZK ที่ใช้พื้นฐานคืออะไร?

เสาหลักด้านการเขียนโปรแกรมข้อที่สองที่นำเสนอใน Toccata นั้นใช้แอปพลิเคชัน zk เป็นพื้นฐาน ส่วนนี้มีความซับซ้อนทางเทคนิคมากกว่าและควรค่าแก่การอธิบายอย่างละเอียดถี่ถ้วน

ค้นพบโครงการอันน่าตื่นเต้น...

โครงการอันน่าสัญญา...

(โฆษณา)

บทความต่อ...

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

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

Toccata ได้นำเสนอส่วนประกอบหลายอย่างเพื่อสนับสนุนสิ่งนี้:

• รหัสยืนยัน ZKรวมถึงตัวตรวจสอบ Groth16 ที่ยืดหยุ่น และตัวตรวจสอบ RISC Zero STARK
• รหัสปฏิบัติการการเข้าถึงข้อผูกพันลำดับทำให้แอปพลิเคชันพื้นฐานสามารถยึดโยงตัวเองกับลำดับ L1 ได้
• คิป-21สถาปัตยกรรมการยืนยันลำดับแบบแบ่งส่วนที่ช่วยให้มั่นใจได้ว่าต้นทุนการพิสูจน์ของแอป zk จะปรับขนาดตามกิจกรรมของแอปเอง ไม่ใช่ตามกิจกรรมโดยรวมของ DAG

ตัวตรวจสอบ RISC Zero STARK ได้ถูกนำไปใช้งานและเปิดใช้งานแล้วบน testnet 12 ส่วนว่าจะเปิดใช้งานบน mainnet หรือไม่นั้นยังอยู่ระหว่างการพิจารณา

เหตุใดการพิสูจน์ต้นทุนจึงมีความสำคัญ

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

สิ่งที่มีอยู่แล้วมีอะไรบ้าง?

ส่วนสำคัญของการฮาร์ดฟอร์กได้ถูกนำไปใช้งานแล้ว ฟีเจอร์ต่อไปนี้ได้ถูกสร้างเสร็จแล้ว:

• การสนับสนุนเพิ่มเติมสำหรับโอเปอเรเตอร์โค้ดของสคริปต์เอ็นจิ้น ซึ่งเป็นแกนหลักของพันธสัญญาหลัก ภายใต้ KIP-17
• รหัสพันธสัญญาสำหรับการจัดการลำดับวงศ์ตระกูลในฐานะคุณลักษณะฉันทามติและกลไก ภายใต้ KIP-20
• โอเปรนด์ ZK พร้อมระบบย่อยพรีคอมไพล์ zk-verifier ภายใต้ KIP-16 เขียนโดย Alexander Safstrom
• รหัสปฏิบัติการการเข้าถึงการยืนยันลำดับ
• KIP-21 ซึ่งเขียนโดย Sutton และดำเนินการโดย Maxim Biryukov ได้ดำเนินการเสร็จสมบูรณ์แล้วและอยู่ระหว่างการตรวจสอบ

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

เหตุใดวันกำหนด Hard Fork จึงเลื่อนไปเป็นเดือนมิถุนายน?

เดิมทีเป้าหมายการเปิดใช้งานเมนเน็ตคือวันที่ 5 พฤษภาคม 2026 แต่ได้เลื่อนไปเป็นช่วงวันที่ 5-20 มิถุนายน 2026 แทน

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

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

คาดว่าจะยุติการพัฒนาฟีเจอร์ใหม่ในวันที่ 15 เมษายน 2026

เกิดอะไรขึ้นระหว่างช่วงหยุดพัฒนาฟีเจอร์ใหม่และการเปิดใช้งาน Mainnet?

หลังจากวันที่ 15 เมษายน ซึ่งเป็นวันหยุดการพัฒนาฟีเจอร์ใหม่ Kaspa Core วางแผนที่จะรีสตาร์ทเครือข่ายทดสอบเฉพาะ TN12 อย่างสะอาดหมดจด โดยมีฟีเจอร์ครบชุดในเวอร์ชันสุดท้าย นี่ไม่ใช่การจำลองการเปลี่ยนผ่านแบบฮาร์ดฟอร์ก แต่เป็นเครือข่ายที่สะอาดหมดจดสำหรับการทดสอบฟีเจอร์ครบชุดในรูปแบบสุดท้าย

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

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

สิ่งที่ผู้ดูแลระบบโหนดควรคาดหวัง

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

สิ่งที่ Toccata มอบให้ Kaspa อย่างแท้จริง

Toccata เพิ่มระบบการเขียนโปรแกรมที่ใช้งานได้สองระบบให้กับเลเยอร์พื้นฐานของ Kaspa ได้แก่ การเขียนสคริปต์ข้อตกลง L1 ดั้งเดิมผ่าน Silverscript และโครงสร้างพื้นฐานแอปพลิเคชัน zk ผ่าน KIP-16, KIP-20 และ KIP-21 งานทางเทคนิคส่วนใหญ่เสร็จสมบูรณ์แล้ว สิ่งที่เหลืออยู่คือการสรุปอินเทอร์เฟซ การรวมสาขาที่รอการดำเนินการเข้ากับ master และการทดสอบเต็มรูปแบบบน TN10 ก่อนที่จะยืนยันวันเปิดตัว mainnet

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

แหล่งข้อมูล

1. Kaspa บน X: โพสต์ (เมษายน 2026)

2. บทความในบล็อกโดย ไมเคิล ซัตตัน: Kaspa Covenants++ “Toccata” แนวโน้มแบบฮาร์ดฟอร์ก