شوكة Toccata الصلبة لـ Kaspa: المواثيق، ورموز تشغيل ZK، وهدف جديد لشهر يونيو

كاسباسيضيف التحديث الصلب القادم لـ Toccata مسارين جديدين للبرمجة إلى الشبكة: برمجة العهد الأصلية من الطبقة الأولى وبنية التطبيقات القائمة على المعرفة الصفرية (zk)، مع تحديد موعد تفعيل الشبكة الرئيسية الآن في الفترة من 5 إلى 20 يونيو 2026، بعد تأجيله من الموعد الأصلي في 5 مايو.

نشر مايكل ساتون من شركة كاسبا كور مقالاً بعنوان: تحديث مفصل حول ما يتضمنه التحديث الجذري، وسبب تغيير موعده، وكيف يُتوقع أن تسير الأمور خلال الأشهر القليلة القادمة. بدأ التحديث الجذري في الأصل من قِبل أوري نيومان كمحاولة لإدخال العهود في محرك نصوص كاسبا، جزئيًا كرد فعل على نقاش OP_CAT في أوساط البيتكوين. ومنذ ذلك الحين، تطور إلى شيء أكبر بكثير.

ما هي شوكة توكاتا الصلبة؟

تُعدّ توكاتا تحديثًا جذريًا مُجدولًا لشبكة كاسبا، يُضيف إمكانيات جديدة مباشرةً إلى الطبقة الأساسية. التحديث الجذري، لمن لا يعرفه جيدًا، هو ترقية بروتوكول غير متوافقة مع الإصدارات السابقة. يجب على جميع العُقد الترقية لمواصلة المشاركة في الشبكة.

يتبع هذا الاسم تقليد كاسبا في استخدام المراجع الموسيقية للتحديثات الرئيسية. ويستمد هذا الإصدار اسمه من شكل موسيقي كلاسيكي، وهو التوكاتا، وهي مقطوعة موسيقية مصممة لعرض المهارة التقنية على آلة مفاتيح.

على مستوى عالٍ، تضيف توكاتا شيئين إلى كاسبا:

• برمجة العهد الأصلي من المستوى الأول عبر مترجم جديد يسمى Silverscript
• بنية تطبيقات zk القائمة، مبنية على نفس أسس العهد

هذه ليست أنظمة قابلة للتبديل. فهي تخدم حالات استخدام مختلفة وتستهدف فئات مختلفة من المطورين.

ما هي العهود ولماذا هي مهمة بالنسبة لكاسبا؟

الشروط هي قيود تُفرض على كيفية إنفاق الأموال الناتجة عن المعاملة في المستقبل. في معاملات البيتكوين أو كاسبا التقليدية، بمجرد إرسال العملات، يمكن للمستلم التصرف بها كما يشاء. أما الشروط فتُغير ذلك من خلال تضمين قواعد الإنفاق مباشرةً في البرنامج النصي.

تستخدم كاسبا نموذج UTXO، على غرار بيتكوين، حيث تستهلك كل معاملة مخرجات موجودة وتنشئ مخرجات جديدة. تسمح العهود في نظام UTXO للمطورين ببناء تدفقات معقدة بشكل مدهش متعددة العقود ذات حالة، على الرغم من أن الحساب الأساسي يظل محليًا لكل UTXO.

لتسهيل عملية تطوير العهود، تعمل Kaspa Core حاليًا على وضع اللمسات الأخيرة على Silverscript، وهو مُترجم برمجي بدأ تطويره كل من أوري نيومان، ومايكل ساتون، وإيزيو ديف، وماني فست. صُمم Silverscript لتسهيل كتابة ونشر العهود المعقدة مباشرةً على Kaspa L1، وجعلها أكثر أمانًا، دون الحاجة إلى أن يعمل المطورون على مستوى محرك البرمجة النصية الخام.

ما هي تطبيقات ZK القائمة؟

يعتمد الركن الثاني من أركان قابلية البرمجة المُقدمة في توكاتا على تطبيقات zk. وهذا الركن هو الأكثر تعقيدًا من الناحية التقنية بين الركنين، ويستحق شرحه بتأنٍّ.

اكتشف المشاريع الواعدة...

مشاريع واعدة...

(إعلان)

تستمر المقالة...

يشير اختصار ZK إلى "المعرفة الصفرية"، وهي طريقة تشفيرية تُمكّن أحد الأطراف من إثبات صحة معلومة ما دون الكشف عن البيانات الأساسية. وتُستخدم إثباتات ZK بشكل متزايد في توسيع نطاق تقنية البلوك تشين لأنها تسمح بالتحقق من صحة العمليات الحسابية خارج السلسلة داخل السلسلة بتكلفة منخفضة وبشكل آمن.

يشير مصطلح "مبني على" في هذا السياق إلى أن نظام zk يتبع تسلسل الطبقة الأولى (L1) بشكل كامل. لا يمكن لتطبيق zk المبني على هذا النظام إضافة أو حذف المعاملات بشكل مستقل، فهو مرتبط بترتيب معاملات Kaspa الخاص، وهذا ما يجعله موثوقًا دون الحاجة إلى مُسلسل منفصل.

يقدم برنامج توكاتا عدة مكونات لدعم ذلك:

• رموز عمليات التحقق ZK، بما في ذلك مدقق Groth16 المرن ومدقق RISC Zero STARK
• رمز عملية الوصول إلى التزام التسلسلمما يُمكّن التطبيقات القائمة على البيانات من ربط نفسها بترتيب الطبقة الأولى (L1).
• كيب -21بنية التزام تسلسل مجزأة تضمن أن تتناسب تكاليف إثبات تطبيق المعرفة الصفرية مع نشاطه الخاص، وليس مع نشاط الرسم البياني الموجه غير الدوري (DAG) الإجمالي.

تم بالفعل تنفيذ وتفعيل مدقق RISC Zero STARK على شبكة الاختبار 12. أما ما إذا كان سيتم تفعيله على الشبكة الرئيسية فلا يزال قيد الدراسة.

لماذا تُعدّ تكاليف الإثبات مهمة؟

لكي يكون أي تطبيق للمعرفة الصفرية عمليًا، يجب أن تتناسب تكلفة إنشاء البراهين مع ما يقوم به التطبيق نفسه. إذا كان على تطبيق المعرفة الصفرية إثبات العمل بالنسبة لجميع الأنشطة على الرسم البياني الموجه غير الدوري الأوسع، فستصبح التكاليف غير قابلة للتنبؤ والإدارة. يحل KIP-21 هذه المشكلة من خلال تقسيم التزامات التسلسل، مما يحافظ على استقلالية عبء عمل كل تطبيق.

ما هي الأمور الموجودة بالفعل؟

تم بالفعل تنفيذ جزء كبير من التحديث الجذري. الميزات التالية متوفرة بالفعل:

• دعم موسع لرموز عمليات محرك البرمجة النصية، وهو العمود الفقري للعهود الأساسية، بموجب KIP-17
• معرّفات العهد لإدارة النسب كميزة توافقية ومحرك، بموجب KIP-20
• رموز ZK مع نظام فرعي للترجمة المسبقة للتحقق من zk، ضمن KIP-16، من تأليف ألكسندر سافستروم
• رمز عملية الوصول إلى التزام التسلسل
• KIP-21، من تأليف ساتون وتنفيذ مكسيم بيريوكوف، تم تنفيذه بالكامل وهو قيد المراجعة

كما أن ماكسيم قد أكملت مراحل إثبات المفهوم، بما في ذلك عهود zk المضمنة وعهود zk القائمة على جسر KAS المتعارف عليه، وكانت هذه المراحل أساسية في تشكيل التصميم النهائي للشوكة.

لماذا تم تأجيل موعد الانقسام الصلب إلى شهر يونيو؟

كان الهدف الأصلي للشبكة الرئيسية هو 5 مايو 2026. ومنذ ذلك الحين تم نقله إلى نافذة من 5 إلى 20 يونيو 2026.

السبب معماري. بمجرد ربط دوائر zk وبيئات التشغيل ببنية تجزئة التزام التسلسل، تصبح أي تغييرات هيكلية لاحقة تغييرات جذرية. إن تصميمًا خاطئًا ثم إصلاحه لاحقًا سيكون أكثر إرباكًا بكثير من استثمار الوقت الإضافي الآن.

صُممت KIP-21 لتكون متوافقةً مستقبلاً مع آلية الالتزام التي ستُطلب لاحقاً من قِبل vprogs، وهي خارطة طريق Kaspa طويلة الأمد للبرامج القابلة للتحقق والتركيب المتزامن. ويُجنّب تثبيت البنية الصحيحة قبل تفعيل الشبكة الرئيسية عمليات الترحيل المكلفة لاحقاً.

من المتوقع تجميد الميزات في 15 أبريل 2026.

ماذا يحدث بين تجميد الميزات والشبكة الرئيسية؟

بعد تجميد الميزات في 15 أبريل، تخطط كاسبا كور لإعادة تشغيل شبكة الاختبار المخصصة، TN12، بشكل كامل مع تضمين مجموعة الميزات النهائية. هذا ليس محاكاة لعملية التحديث الجذري، بل هو شبكة نظيفة لاختبار مجموعة الميزات الكاملة في شكلها النهائي.

ومن ثم، سيقوم الفريق بدمج العمل المتراكم على مدى أشهر من فرع معلق طويل الأمد في قاعدة البيانات الرئيسية. تتضمن هذه العملية التدقيق النهائي، وإغلاق البنود المفتوحة، وتحسين منطق تفعيل التفرع الصلب، ومعالجة إمكانية ترقية قاعدة البيانات.

بمجرد اكتمال هذا العمل، سيتم تشغيل نسخة تجريبية من الشبكة الرئيسية على شبكة الاختبار طويلة الأمد TN10، لمحاكاة الانتقال الكامل إلى الشبكة الرئيسية. ولن يتم تحديد تاريخ إطلاق الشبكة الرئيسية إلا بعد أن يجتاز هذا الاختبار التجريبي بنجاح ويرضي الفريق.

ما الذي ينبغي لمشغلي العقد أن يتوقعوه

بالنسبة للمعدنين ومشغلي العُقد، صُممت عملية الترقية لتكون سهلة ومباشرة. يلزم تحديث العُقد، ومن المفترض أن تستمر الوظائف الحالية بالعمل. من المتوقع أن تزداد متطلبات مساحة القرص بنسبة تتراوح بين 20 و50 بالمئة تقريبًا. لا يُتوقع حدوث تغييرات جذرية في البنية التحتية.

ما الذي تقدمه توكاتا فعلياً لكاسبا

يُضيف نظام توكاتا نظامي برمجة عمليين إلى الطبقة الأساسية لكاسبا: برمجة العهد الأصلية من الطبقة الأولى باستخدام سيلفر سكريبت، وبنية تطبيقات zk الأساسية من خلال KIP-16 وKIP-20 وKIP-21. وقد أُنجز جزء كبير من العمل التقني بالفعل. وما تبقى هو وضع اللمسات الأخيرة على الواجهات، ودمج الفرع المُعلق في الفرع الرئيسي، وإجراء بروفة كاملة على TN10 قبل تأكيد تاريخ إطلاق الشبكة الرئيسية.

تم تحديد الفترة الزمنية من 5 إلى 20 يونيو 2026 لأن الفريق اختار ضمان صحة بنية التزام التسلسل من البداية بدلاً من إصلاحها لاحقاً أثناء التشغيل الفعلي. بالنسبة لمشغلي العقد، صُممت عملية الترقية لتكون سهلة ومباشرة، دون أي تغييرات جوهرية في البنية التحتية باستثناء زيادة طفيفة في مساحة القرص.

المصادر

1. كاسبا على X: منشور (أبريل 2026)

2. مقال مدونة بقلم مايكل ساتون: Kaspa Covenants++ "Toccata" Hard-Fork Outlook