Kaspa สรุปมาตรฐาน 3 ประการสำหรับโทเค็นพื้นเมืองและแอปพลิเคชัน Covenant

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

สรุป

• KCC-1 กำหนดอินเทอร์เฟซร่วมสำหรับกระเป๋าเงิน, คอมไพเลอร์, ตัวจัดทำดัชนี และเครื่องมืออื่น ๆ ที่ทำงานกับ Covenant
• KCC-2 ระบุแผนการอนุญาตมาตรฐานห้าประการ รวมถึงกุญแจสาธารณะ, สคริปต์ และตัวระบุ Covenant
• KCC-20 กำหนดกฎการโอนโทเค็นและสนับสนุนการรับโทเค็นผ่านผลลัพธ์ที่เข้ากันได้ที่มีอยู่
• การสรุปนี้กำหนดข้อตกลงในระบบนิเวศโดยไม่เปลี่ยนแปลงกฎฉันทามติหรือกำหนดให้ผู้เข้าร่วมทุกคนต้องนำไปใช้

ฟอรัมการประสานงาน KCC กล่าวในประกาศเมื่อวันที่ 21 ตุลาคมว่า KCC-1, KCC-2 และ KCC-20 ได้รับการสรุปและพร้อมสำหรับการนำไปใช้ในระบบนิเวศ ฟอรัมเชิญชวนผู้สร้างให้เข้าร่วมช่องสาธารณะเพื่อสอบถาม, หารือเกี่ยวกับการนำไปใช้ และขอรับการสนับสนุน

สวัสดี $KAS. KCC-1, KCC-2 และ KCC-20 ตอนนี้เป็นมาตรฐานสุดท้าย ซึ่งหมายความว่าพร้อมสำหรับการนำไปใช้ในระบบนิเวศอย่างเต็มที่

เราขอเชิญนักพัฒนา Kaspa เข้าร่วมช่อง KCC สาธารณะเพื่อสอบถาม, รับการสนับสนุน, หารือเกี่ยวกับการนำไปใช้ และแบ่งปันสิ่งที่คุณสร้าง

มาร่วมสร้างกับเรา --- ฟอรัมการประสานงาน KCC (@kccforum) 21 ตุลาคม 2026

คลังมาตรฐานของ Kaspa ระบุเอกสารทั้งสามฉบับว่าเป็นมาตรฐานสุดท้าย ดัชนีของมันระบุ KCC-1 ว่าเป็นข้อกำหนดของ Covenant, KCC-2 ว่าเป็นข้อกำหนดของอำนาจ และ KCC-20 ว่าเป็นมาตรฐานแอปพลิเคชันสำหรับ Covenant โทเค็นที่สามารถใช้แทนกันได้

คลังนี้อธิบายว่า KCC เป็นข้อตกลงร่วมสำหรับการดำเนินการที่เป็นอิสระ เอกสารของมันแยกข้อตกลงเหล่านั้นออกจากการเปลี่ยนแปลงในฉันทามติหรือพฤติกรรมของโหนดหลัก ซึ่งอยู่ในข้อเสนอการปรับปรุง Kaspa

มาตรฐานของ Kaspa ครอบคลุมส่วนต่าง ๆ ของการพัฒนาแอปพลิเคชัน

KCC-1 กำหนดคำศัพท์ทั่วไป, รูปแบบข้อมูล และอินเทอร์เฟซไบนารีของแอปพลิเคชัน หรือ ABI สำหรับ Covenant ข้อกำหนดนี้อธิบายว่าโปรแกรมซอฟต์แวร์เข้ารหัสข้อมูลอย่างไร, เรียกใช้ฟังก์ชันโปรแกรม และระบุสถานะที่ถูกส่งระหว่างธุรกรรม

ผู้เขียนของมัน, Romain Billot, Michael Sutton และ Ori Newman, ระบุว่าคอมไพเลอร์, กระเป๋าเงิน, ตัวจัดทำดัชนี และผู้สร้างธุรกรรมเป็นเครื่องมือที่ต้องตกลงกันในรายละเอียดเหล่านั้น เอกสารระบุว่าการดำเนินการที่เป็นอิสระต้องการรูปแบบร่วมที่เกินกว่าการผลิตสคริปต์ที่ผ่านการตรวจสอบฉันทามติ

ข้อกำหนด KCC-1 ปล่อยให้นักพัฒนามีอิสระในการเลือกภาษาการเขียนโปรแกรม, คอมไพเลอร์, และเฟรมเวิร์ก อินเทอร์เฟซร่วมของมันครอบคลุมจุดเข้าถึงโปรแกรม, เทมเพลตสถานะ, และกฎสำหรับการจัดการธุรกรรมที่เกี่ยวข้องกับหลาย ๆ ข้อมูลนำเข้า

ภายในเอกสารเดียวกัน, ผู้เขียนแยกกฎอินเทอร์เฟซพื้นฐานออกจากฟีเจอร์ที่ขึ้นอยู่กับตัวระบุ Covenant โปรแกรมที่ไม่มีการผูกพัน Covenant สามารถปฏิบัติตาม KCC-1 ได้ แต่ข้อกำหนดระบุว่าพวกเขาจะไม่ได้รับการรับประกันเกี่ยวกับสายพันธุ์และการอนุญาตที่จัดเตรียมโดย KIP-20

KCC-2 กำหนดว่าใครสามารถอนุญาตการดำเนินการ

KCC-2 ซึ่งเขียนโดย Billot และ Sutton กำหนดว่าโปรแกรมระบุอำนาจอย่างไรและการตรวจสอบขั้นต่ำที่จำเป็นในการจัดตั้งการอนุมัติของมัน อำนาจสามารถเป็นกุญแจสาธารณะ, การมอบหมายให้กับกุญแจ, สคริปต์, หรือสายพันธุ์ Covenant ที่ต่อเนื่อง

ข้อกำหนดนี้กำหนดตัวระบุมาตรฐานให้กับแผนการอนุญาตห้าประการ ตัวเลือกกุญแจสาธารณะของมันครอบคลุมลายเซ็น Schnorr และ ECDSA ในขณะที่ตัวเลือกอื่น ๆ ของมันอนุญาตให้สคริปต์หรือสายพันธุ์ Covenant มีส่วนร่วมในฐานะอำนาจ

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

ทะเบียนอำนาจสงวนช่วงแยกสำหรับแผนการมาตรฐานและกำหนดเอง KCC-2 อนุญาตให้ผู้เข้าร่วมสามารถนำแผนการกำหนดเองไปใช้ได้โดยไม่ต้องรอการมาตรฐาน ตราบใดที่การกำหนดของพวกเขาระบุรูปแบบ, ความหมาย, และการตรวจสอบการอนุมัติ

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

KCC-20 กำหนดกฎการโอนและรับโทเค็น

KCC-20 สร้างขึ้นจากมาตรฐานสองข้อแรก โดยกำหนดจำนวนโทเค็น ความเป็นเจ้าของ และอินเทอร์เฟซการโอนเอกสารระบุชื่อ Sivan Helfer, Sutton, Newman และ Billot เป็นผู้เขียน

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

ฟีเจอร์ที่เรียกว่า borrowed receive ช่วยให้ผู้ส่งสามารถใช้ข้อมูลส่งออกโทเค็นที่เข้ากันได้ที่มีอยู่ของผู้รับเป็นจุดหมายปลายทาง KCC-20 กล่าวว่าการทำธุรกรรมจะสร้างข้อมูลส่งออกนั้นขึ้นใหม่ด้วยโทเค็นเพิ่มเติม รักษาความเป็นเจ้าของและสถานะที่ขยายออกไป และไม่สามารถลดมูลค่า KAS ของมันได้

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

มาตรฐานเชื่อมโยงการใช้งานอ้างอิง Argent กับสัญญา SilverScript ที่สร้างขึ้นและการทดสอบความสอดคล้อง Rust

สถานะสุดท้ายมีข้อกำหนดในการดำเนินการ

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

การพึ่งพาต้องเป็น Final สำหรับ KCC อื่น ๆ หรือ Active สำหรับ KIPs ตามกฎเดียวกัน KCC-0 กล่าวว่าการเปลี่ยนแปลงสถานะเกิดขึ้นผ่านคำขอการดึงและดัชนีที่เก็บต้องได้รับการอัปเดตด้วยพวกเขา

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

เอกสารที่กำกับดูแลระบุว่าการทำให้เสร็จสิ้นไม่ต้องการให้ผู้เข้าร่วมในระบบนิเวศทุกคนดำเนินการตามข้อตกลง การเปลี่ยนแปลงที่สำคัญโดยทั่วไปต้องการ KCC แทนที่ ในขณะที่การแก้ไขและการชี้แจงจะปฏิบัติตามกฎการแก้ไขของเอกสาร

การพัฒนาแอปพลิเคชันของ Kaspa ก่อนหน้านี้รวมถึงโครงสร้างพื้นฐาน Layer 2 แยกต่างหาก Gate ประกาศการรวม Kasplex Layer 2 ในเดือนเมษายน ทำให้สามารถฝากและถอน KAS ผ่านเครือข่ายที่เข้ากันได้กับ EVM ตามที่ crypto.news รายงาน

ในการประกาศการรวมก่อนหน้านี้ Gate กล่าวว่า ลูกค้าสามารถโอน KAS จากเครือข่ายหลักไปยังกระเป๋าเงิน Kasplex เอกสารโครงการของ Kasplex อธิบายถึงสะพานสองทางและกล่าวว่านักพัฒนาที่คุ้นเคยกับเครื่องมือ Ethereum สามารถปรับใช้สัญญาโดยการเปลี่ยนจุดสิ้นสุดการเรียกกระบวนการระยะไกลของพวกเขา

Kasplex อธิบายการออกแบบของตนว่าเป็น rollup ที่เบา ซึ่งวาง EVM bytecode ในธุรกรรมของ Kaspa และดำเนินการนอกเชน เอกสารของมันกล่าวว่า Kaspa จัดหาลำดับธุรกรรมและความพร้อมใช้งานของข้อมูล ในขณะที่ KAS ที่เชื่อมโยงทำหน้าที่เป็นโทเค็นก๊าซ Layer 2