المطابقة القابلة للتحقق من ZK هي طريقة لتشغيل دفتر طلبات خاص وسريع مع منح المستخدمين ضمانا تشفيريا بأن محرك المطابقة يتبع القواعد. المشكلة التي يحلها بسيطة: يحتاج CLOB إلى مشغل (أو مجموعة صغيرة من المشغلات) لمطابقة الأوامر بسرعة، لكن هذا المشغل يمكنه أيضا الغش (إعادة الترتيب، التخطي، أو التعبئة الانتقائية). ZK يغير نموذج الثقة: يمكن للمشغل البقاء سريعا، لكنه لا يستطيع إنهاء تحديث ما لم يثبت أنه تم حسابه بشكل صحيح. كيف يعمل (من الناحية المفاهيمية) ➤ يتم جمع الأوامر ومطابقتها خارج السلسلة (بحيث يمكنك الحصول على تنفيذ منخفض التأخير). ➤ بدلا من نشر تدفق الطلب الكامل، ينشر النظام: - الالتزام بالانتقال بين الدفعة / الحالة (غالبا ما يكون جذر حالة) - دليل ZK على أن تحديثات المطابقة + فحوصات المخاطر + التوازن تم وفقا لقواعد البروتوكول، - توفر بيانات كاف بحيث يمكن للمستخدمين الخروج حتى لو اختفى المشغل. هذا "توفر البيانات الكافية" هو ما يجعل اختيار التصميم @hibachi_xyz مثيرا للاهتمام: Hibachi يشغل جهاز CLOB عالي الأداء وينشر بيانات الحالة / التداول المشفرة إلى @Celestia (لذا الاستراتيجيات والمواقف ليست عامة)، مع الاستمرار في نشر البراهين لتبقى التحديثات قابلة للتحقق، باستخدام SP1 (zkVM الخاص ب Succinct) لإثبات CLOB. لكن ماذا يعني "المطابقة كانت صحيحة" في مصطلحات الإثبات؟ يمكن لاختبار zk أن يفرض نفس الثوابت التي عادة ما تعتمد على مشغل التبادل اتباعها، على سبيل المثال: ➤ كانت الأوامر تطابق فقط عند تقاطع الأسعار (بدون حشوات مستحيلة). ➤ تسلسل التعبئة احترم قاعدة أولوية المكان (مثل أولوية السعر والوقت، أو أيا كان ما يحدده المكان). ➤ تم تحديث الأرصدة/الهوامش بشكل صحيح (بدون تعديلات على الرصيد المخفي). ...