يشكل المعالج المشترك لبيانات ZK العنصر الجوهري في Brevis، حيث يتيح للعقود الذكية الوصول الآمن والموثوق إلى البيانات التاريخية وبيانات عبر السلسلة. يقوم باسترجاع بيانات أصلية على السلسلة، وينفذ العمليات الحسابية خارج السلسلة، ثم يعيد النتائج مرفقة بدليل معرفة صفرية (ZK) للتحقق على السلسلة. وبصفته الطبقة الأكثر ارتباطًا بالتطبيقات في Brevis (BREV)، يحوّل إشكالية "عدم قدرة العقود على الحساب أو قراءة البيانات التاريخية" إلى "الحساب خارج السلسلة والتحقق على السلسلة".
تتطلب آليات الإجماع في البلوكشين من كل مُدقِّق تكرار نفس العمليات الحسابية، ما يجعل الوصول المباشر على السلسلة إلى كميات ضخمة من المعاملات التاريخية مكلفًا للغاية. لذا، تظل العقود الذكية شبه عمياء عن البيانات التاريخية.
استنادًا إلى مبدأ Brevis "إثبات العمل بدلًا من تكراره"، ينقل المعالج المشترك لبيانات ZK عمليات القراءة الكثيفة والحساب خارج السلسلة، بينما يصبح التحقق على السلسلة سريعًا للغاية. يتيح ذلك للعقود اتخاذ قرارات مستندة إلى السلوك طويل الأجل على السلسلة دون الحاجة إلى وسطاء مركزيين.
ما هو المعالج المشترك لبيانات ZK؟
المعالج المشترك لبيانات ZK هو محرك حساب متخصص خارج السلسلة، مصمم للوصول إلى الحالات التاريخية للبلوكشين وبيانات عبر السلسلة، وتنفيذ العمليات التي لا يمكن للعقود إجراؤها بكفاءة على السلسلة، مع إرفاق دليل تشفير لكل عملية. ينتج بيانات اعتماد قابلة للتحقق—"النتيجة + الدليل على أن النتيجة مشتقة من بيانات أصلية وتم حسابها بدقة".
ضمن منظومة Brevis التقنية، يُعد المعالج المشترك لبيانات ZK مثالًا رئيسيًا على Pico zkVM "المعالج المشترك على مستوى التطبيق". يعمل Pico zkVM كطبقة ربط توجه البيانات بين النواة العامة والوحدات المتخصصة، بينما يركز المعالج المشترك للبيانات على "قراءة التاريخ، إجراء التحليلات، وإرفاق الأدلة"، ليعتمد العقد على الرياضيات بدلًا من الوسطاء المركزيين.
لماذا لا تستطيع العقود الذكية قراءة البيانات التاريخية؟
بحكم التصميم، تتيح العقود الذكية الوصول فقط إلى حالة الكتلة الحالية، وتبقى شبه عمياء عن بيانات الكتل السابقة. رغم أن شبكات مثل Ethereum تحتفظ بكامل التاريخ، إلا أن العقود التي تصل إلى تخزين الكتل السابقة أو المعاملات على السلسلة تتطلب أدلة إضافية مكلفة وغالبًا ما تفتقر إلى واجهات أصلية.
السبب الجوهري يكمن في التكلفة والإجماع: إعادة حساب حجم معاملات عنوان خلال ستة أشهر ماضية على السلسلة يتطلب من كل مُدقِّق معالجة بيانات ضخمة، ما يتجاوز حدود الغاز لكل معاملة بسرعة. لذا، تظل البيانات التاريخية "موجودة" ولكن "غير متاحة". ميزات مثل رسوم التداول المتدرجة أو مكافآت الولاء المبنية على السلوك التاريخي اعتمدت تقليديًا على الحساب خارج السلسلة وإعادة الدمج، مما يعيد الثقة للوسطاء المركزيين.
كيف يصل المعالج المشترك لبيانات ZK إلى بيانات على السلسلة خارج السلسلة؟
يصل المعالج المشترك لبيانات ZK إلى الحالات التاريخية الكاملة عبر عقد أرشيف البلوكشين، التي تخزن لقطات لكل كتلة تاريخية. يمكّن ذلك المعالج من قراءة الأرصدة، وخانات التخزين، وسجلات المعاملات في أي وقت—سواء لحالات أحادية أو متعددة السلاسل—دون الحاجة لإعادة البيانات على السلسلة.
بعد استرجاع البيانات الخام، ينفذ المعالج منطق الحساب المخصص من قبل المستخدم خارج السلسلة، مثل التجميع أو التصفية أو التوزين أو التقييم الشرطي. بخلاف الحساب التقليدي خارج السلسلة، يتم تضمين كل نقطة بيانات في الدليل اللاحق، ما يضمن "وجود البيانات" و"صحة الحساب".
من الطلب إلى التحقق: كيف يعمل تدفق البيانات الكامل؟
يتكون تدفق بيانات المعالج المشترك لبيانات ZK من أربع مراحل تشكل حلقة مغلقة من طلب التطبيق إلى اعتماد العقد الذكي على السلسلة. في سير العمل القائم كليًا على ZK، يعتمد توليد الدليل في كل مرحلة على طبقة تنفيذ zkVM. يوضح الجدول التالي كل مرحلة:
| الخطوة |
المرحلة |
ما يحدث |
المخرجات |
| ① |
طلب التطبيق |
يحدد dApp منطق الحساب ونطاق البيانات ثم يرسل الطلب |
مهمة حساب |
| ② |
الوصول إلى البيانات والحساب خارج السلسلة |
يقرأ المعالج البيانات الأصلية عبر عقد الأرشيف وينفذ الحساب |
نتيجة خام |
| ③ |
توليد دليل ZK |
يولد دليل ZK على صحة تنفيذ الحساب على بيانات حقيقية |
نتيجة + دليل |
| ④ |
التحقق على السلسلة |
يتحقق العقد الذكي من الدليل خلال أجزاء من الثانية ويعتمد النتيجة |
استنتاج موثوق |
تشكل هذه المراحل الأربع خط أنابيب "الحساب خارج السلسلة، التحقق على السلسلة": تتم عمليات القراءة والحساب المكثفة خارج السلسلة، بينما تقتصر السلسلة على التحقق من دليل موجز بأقل تكلفة، دون الحاجة لنقل البيانات الخام على السلسلة.
الشكل 1. تدفق بيانات المعالج المشترك لبيانات ZK بأربع مراحل: طلب التطبيق → الوصول إلى البيانات خارج السلسلة (عقدة الأرشيف) → الحساب → توليد دليل ZK (وجود البيانات وصحة الحساب) → التحقق على السلسلة → إعادة النتيجة.
لماذا تعتبر الأدلة المولدة موثوقة؟
تعتمد موثوقية أدلة المعالج المشترك لبيانات ZK على ثلاث ضمانات: النتيجة نفسها، أصالة البيانات، وصحة الحساب. أي تلاعب في أي مرحلة يؤدي إلى فشل التحقق على السلسلة.
تفصل أدلة المعرفة الصفرية تكلفة التحقق عن حجم العمليات الحسابية: بغض النظر عن عدد الكتل التاريخية التي تتم معالجتها خارج السلسلة، يتطلب التحقق على السلسلة فقط فحص دليل موجز بحجم ثابت، عادة خلال أجزاء من الثانية. يوضح الجدول أدناه أنواع الحقائق التي يضمنها الدليل.
| نوع الضمان |
الحقيقة التي يضمنها الدليل |
ما يمنع الغش |
| النتيجة |
القيمة المعادة هي المخرج الحقيقي للحساب |
التلاعب بالنتيجة النهائية |
| وجود البيانات |
المدخلات مستمدة من الحالة التاريخية الأصلية للسلسلة المستهدفة |
تزوير أو استبدال بيانات الإدخال |
| صحة الحساب |
الحساب يتبع المنطق المعلن بدقة |
تخطي خطوات أو تعديل المنطق |
يوضح هذا الهيكل لماذا يمكن للعقود "عدم الثقة، بل التحقق فقط": النتيجة والمدخلات والعملية كلها مضمنة في الدليل، مما يمنع التلاعب في أي مرحلة. هذه الخاصية قليلة الثقة تميزها عن الحلول التي تعتمد على أطراف موثوقة لإعادة دمج البيانات.
الشكل 2. هيكل دليل المعالج المشترك لبيانات ZK: دليل واحد يؤمن النتيجة ووجود البيانات وصحة الحساب في آن واحد، يتم التحقق منه بواسطة عقد ذكي على السلسلة خلال أجزاء من الثانية.
ما هي الحالات المناسبة لاستخدام المعالج المشترك لبيانات ZK؟
يعد المعالج المشترك لبيانات ZK مثاليًا لأي سيناريو على السلسلة يتطلب "نتائج موثوقة مستندة إلى بيانات تاريخية أو عبر السلسلة". يمكن الآن للحالات التي اعتمدت سابقًا على الحساب خارج السلسلة وإعادة الدمج الاستفادة من الحساب القابل للتحقق. يبرز الجدول أدناه بعض السيناريوهات الشائعة:
| السيناريو |
القدرة المطلوبة |
الوصف |
| الحوافز المعتمدة على البيانات |
تجميع حجم التداول/السلوك التاريخي |
مكافآت تصدر بناءً على نشاط حقيقي؛ النتائج غير قابلة للتلاعب |
| الولاء والتصنيف |
مدة الاحتفاظ/لقطات تاريخية |
مزايا متدرجة بناءً على سجلات الاحتفاظ أو التداول |
| التحكم في المخاطر على السلسلة |
التصنيف التاريخي للعناوين |
تقييم المخاطر استنادًا إلى السلوك التاريخي قبل تنفيذ منطق العقد |
| قراءة الحالة عبر السلاسل |
بيانات أرشيف متعددة السلاسل |
اعتماد الحالة التاريخية من سلسلة أخرى |
القاسم المشترك في هذه السيناريوهات أن القرارات تعتمد على "أحداث سابقة"، وهذه البيانات لا يمكن إعادة تشغيلها بكفاءة على السلسلة. وعلى عكس الأوركلز التي تستورد البيانات فقط من خارج السلسلة، فإن الفرق بين Brevis والأوركلز هو أن المعالج لا يقدم البيانات فقط، بل يقدم أيضًا "الحساب ودليل صحة الحساب"، محولًا الثقة من مصدر البيانات إلى التحقق الرياضي.
ما هي مزايا وقيود استخدام المعالج المشترك لبيانات ZK؟
تتمثل القوة الأساسية للمعالج المشترك لبيانات ZK في تقليل الثقة وقابلية التوسع. يزيل التنفيذ خارج السلسلة القيود الحسابية التي تفرضها حدود الغاز في الكتل، وتتيح أدلة المعرفة الصفرية التحقق من النتائج دون الاعتماد على أطراف ثالثة. يمكّن ذلك العقود من اتخاذ قرارات آمنة استنادًا إلى نشاط طويل الأجل على السلسلة.
أما القيود الرئيسية فتنشأ من الحساب المعتمد على ZK نفسه: توليد الأدلة يتطلب أجهزة متخصصة ومعدل تجزئة، كما أن الأدلة للمنطق المعقد تفرض عبئًا وتباطؤًا أكبر من التنفيذ الأصلي، مما يجعلها أقل ملاءمة للحالات التي تتطلب زمن استجابة منخفض للغاية. كما تعتمد موثوقية النتائج على سلامة مصدر البيانات—أي نقص أو خطأ في بيانات عقدة الأرشيف يؤثر مباشرة على أصالة المدخلات.
لذا، فإن المعالج المشترك لبيانات ZK الأنسب للحالات التي تكون فيها "صحة النتيجة أهم من الفورية"، ما يجعل الحسابات التاريخية واسعة النطاق موثوقة وقابلة للاستخدام، ولكن ليس دون تكلفة. أما للحالات الأكثر حساسية للزمن وتكلفة الأدلة، يوفر نموذج BREV token وcoChain التفاؤلي بديلًا. جميع ما سبق هي قيود موضوعية على مستوى الآلية ولا تشكل نصيحة استثمارية.
الملخص
يشكل المعالج المشترك لبيانات ZK الطبقة التطبيقية في Brevis، ويعالج التحديات المتعلقة بوصول العقود الذكية المحدود إلى البيانات التاريخية وارتفاع تكلفة إعادة التشغيل على السلسلة. يصل إلى بيانات تاريخية أصلية وبيانات عبر السلسلة عبر عقد الأرشيف خارج السلسلة، وينفذ العمليات الحسابية، ويعيد دليل معرفة صفرية—"النتيجة + وجود البيانات وصحة الحساب"—للتحقق من العقود خلال أجزاء من الثانية. تنقل العملية المؤلفة من أربع مراحل—الطلب، الحساب خارج السلسلة، توليد الدليل، والتحقق على السلسلة—الثقة من الوسطاء المركزيين إلى التشفير، ما يمكّن الحوافز المعتمدة على البيانات، وبرامج الولاء، والتحكم في المخاطر، وقراءة الحالة عبر السلاسل بشكل موثوق.
الأسئلة الشائعة
ما هو المعالج المشترك لبيانات ZK؟
بصفته محرك حساب خارج السلسلة، يصل المعالج المشترك لبيانات ZK إلى بيانات البلوكشين التاريخية وبيانات عبر السلسلة، وينفذ عمليات لا يمكن للعقود تنفيذها على السلسلة، ويرفق دليل معرفة صفرية بالنتيجة. تحتاج العقود فقط إلى التحقق من دليل موجز على السلسلة لاعتماد النتيجة، دون الحاجة لإعادة البيانات الخام.
من أين تأتي بيانات المعالج المشترك لبيانات ZK؟
تستمد البيانات من عقد أرشيف البلوكشين التي تخزن لقطات كاملة لكل كتلة تاريخية. يستخدم المعالج هذه اللقطات لقراءة الأرصدة والتخزين وسجلات المعاملات في أي وقت، ويغطي بذلك الحالات التاريخية عبر عدة سلاسل. يتم تضمين كل نقطة بيانات في الدليل اللاحق.
لماذا تعتبر نتائج المعالج المشترك لبيانات ZK موثوقة؟
يؤمن دليل المعرفة الصفرية المعاد ثلاث حقائق في آن واحد: النتيجة نفسها، وأن بيانات الإدخال موجودة فعليًا على السلسلة المستهدفة، وأن الحساب يتبع المنطق المعلن بدقة. أي تلاعب سيؤدي إلى فشل الدليل في التحقق على السلسلة، مما يمكّن العقود من "عدم الثقة، بل التحقق فقط".
كيف يختلف المعالج المشترك لبيانات ZK عن الأوركلز؟
تستورد الأوركلز بشكل أساسي البيانات من خارج السلسلة إلى البلوكشين، ولا تزال تتطلب الثقة بمصدر البيانات. بالمقابل، ينفذ المعالج المشترك لبيانات ZK الحسابات خارج السلسلة استنادًا إلى بيانات أصلية على السلسلة أو تاريخية، ويرفق دليل معرفة صفرية على صحة الحساب، محولًا الثقة من مصدر البيانات إلى التحقق الرياضي.
