التحدي الجوهري في الحوسبة الموثوقة على السلسلة يكمن في الإجابة على سؤال: "لماذا يمكن الوثوق بالنتيجة؟" رغم أن الإثباتات التشفيرية توفر أعلى درجات الحتمية، إلا أن توليدها يتطلب أجهزة متخصصة ومعدل تجزئة مرتفع، ما يحد من الكفاءة ويرفع التكاليف. لتحقيق توازن بين الحتمية والكفاءة، قدمت Brevis (BREV) نموذج الأمان الاقتصادي التشفيري coChain، مستفيدة من آليات تخزين إثبات الحصة (PoS) وslashing لتوفير مصدر بديل وموثوق للنتائج المتفائلة القابلة للطعن.
في هذا الإطار، يُستخدم BREV كأصل للدفع، والضمان، والحوكمة. وتُشكل هذه الخصائص، مع دورة عمل coChain، أساس أمان Brevis الاقتصادي التشفيري.
BREV هو رمز المنفعة والحوكمة الأصلي في شبكة Brevis. يتجاوز كونه رمزًا لرسوم المعاملات، إذ يمثل أداة اقتصادية تربط بشكل مباشر جودة توفير الإثباتات بأمان الشبكة.
في منظومة Brevis، يربط BREV بين ثلاثة أطراف رئيسية: طالب الحوسبة، والمُثبت (Prover) الذي ينتج إثباتات المعرفة الصفرية، والمُدقِّق المسؤول عن الحفاظ على إجماع coChain. يدفع الطالبون مقابل الإثباتات، بينما يجب على المُثبتين والمُدقِّقين قفل BREV كضمان لضمان التنفيذ، مع تطبيق slashing على أي خرق، ما يضمن ارتباط تداول BREV بنشاط الشبكة.
يخدم BREV ثلاث وظائف رئيسية: الدفع، الضمان، والحوكمة. هذه الأدوار تدعم اقتصاد توفير الإثباتات في Brevis، لتحقيق هدف "إنتاج حوسبة دقيقة ومعاقبة السلوك الخاطئ".
| الوظيفة | الدور | الوصف |
|---|---|---|
| دفع رسوم الإثباتات | الطالب | استخدام BREV لدفع تكلفة الحوسبة خارج السلسلة وتوليد الإثباتات |
| تخزين المُثبت كضمان | المُثبت | قفل BREV كضمان للتخزين لاستلام المهام؛ ويطبق slashing عند عدم الالتزام |
| حوكمة البروتوكول | حامل الرمز | المشاركة في اتخاذ قرارات الحوكمة للمعايير الحيوية للبروتوكول |
تشكل هذه الوظائف الثلاثة دائرة مغلقة: يسدد الطالبون رسوم الإثباتات بـBREV؛ يجب على المُثبتين تخزين BREV لقبول المهام، ما يجعل التزامهم الخدمي قابلًا للتنفيذ اقتصاديًا؛ ويساعد الحاملون في تعديل معايير البروتوكول، مما يسمح للشبكة بالتطور بأمان.

الشكل 1. الوظائف الثلاث الأساسية لرمز BREV: دفع رسوم الإثباتات، تخزين المُثبت كضمان، وحوكمة البروتوكول.
coChain هو نموذج الأمان الاقتصادي التشفيري الخاص بـBrevis—بلوكشين إثبات الحصة مع تخزين وslashing على Ethereum، صُمم لتقديم حوسبة قابلة للتحقق بزمن استجابة منخفض وتكلفة فعالة وثقة مصغرة.
تم تطوير coChain لمعالجة قيود نموذج المعرفة الصفرية الخالص (pure-ZK). في إعداد pure-ZK، يجب أن يرافق كل نتيجة إثبات معرفة صفرية قبل التسليم، ما يحقق أعلى درجات الحتمية، لكنه يفرض تكاليف كبيرة في الأجهزة ومعدل التجزئة وزمن الاستجابة، خاصةً في العمليات المعقدة والتطبيقات اللحظية. تدعم طبقة التنفيذ العامة Pico zkVM هذه العملية.
يعالج coChain هذا التحدي عبر نهج "اقتراح متفائل + طعن": تُعتمد نتائج المُدقِّقين افتراضيًا، ولا يُطلب إثبات معرفة صفرية إلا عند وجود طعن. في أغلب الحالات، يُلغي ذلك تكاليف توليد الإثباتات، مع الاحتفاظ بخيار تشفيري لتصحيح الأخطاء. يركز هذا النموذج، كما في الفارق بين Brevis و oracles، على الحوسبة القابلة للتحقق على السلسلة، حيث ترتكز الثقة على التخزين وslashing.
يعمل نموذج coChain عبر ثلاث مراحل: الاقتراح، الطعن، وslashing. يرسخ ذلك موثوقية النتائج في ضمان قابل للخصم، بدءًا من الحوسبة خارج السلسلة حتى الحسم النهائي على Ethereum.
تخطط Brevis أيضًا لدمج EigenLayer، ما يتيح للمطورين تعديل مستويات الأمان ديناميكيًا خلال مرحلة الاقتراح، جامعًا بين الحوافز الاقتصادية التشفيرية وإثباتات المعرفة الصفرية لتقديم أمان مرن وتوازن في التكلفة.

الشكل 2. تدفق أمان coChain الاقتصادي التشفيري: نتيجة حوسبة إثبات الحصة → اقتراح (مع تواقيع النصاب المجمعة) → نافذة الطعن → طعن ZK يؤدي إلى slashing على Ethereum، أو اعتماد النتيجة من قبل التطبيق إذا لم يتم الطعن.
الاختلاف الأساسي بين pure-ZK وcoChain هو مصدر الثقة: يعتمد pure-ZK فقط على الإثباتات التشفيرية، بينما يضيف coChain حوافز اقتصادية عبر التخزين وslashing. هذه النماذج ليست متعارضة، بل تلبي احتياجات مختلفة من حيث الحتمية والتكلفة.
| البعد | pure-ZK | coChain (نموذج OP) |
|---|---|---|
| مصدر الثقة | إثبات تشفيري | تخزين، slashing، وطعن ZK اختياري |
| زمن النتيجة | انتظار الإثبات | قابل للاستخدام بعد نافذة الطعن |
| تكلفة الحوسبة | إثبات مطلوب دائمًا | لا توجد تكلفة إثبات إذا لم يتم الطعن |
| مستوى الأمان | مضمون بإثبات ZK | قابل للتعديل ديناميكيًا عبر EigenLayer |
| حالات الاستخدام | أعلى حتمية | سيناريوهات حساسة للتكلفة أو زمن الاستجابة |
خلاصة القول: يوفر pure-ZK البساطة والحتمية القصوى مع تكلفة وزمن استجابة أعلى، بينما يحقق coChain زمن استجابة وتكلفة أقل عبر اقتراحات متفائلة، ويعتمد الأمان على عملية الطعن وحجم التخزين. باستخدام Brevis SDK، يمكن للمطورين كتابة منطق الأعمال مرة واحدة ونشره على كلا النموذجين.
تضمن آلية تخزين وslashing BREV التزام المُثبتين بتقديم الإثباتات في الوقت المحدد. لقبول مهمة، يجب على المُثبتين قفل BREV كضمان، ما يجعل التزامهم المالي بالتسليم في الوقت قابلًا للتنفيذ.
تُطبق هذه الآلية عبر ProverNet، سوق إثبات ZK اللامركزي الخاص بـBrevis، والذي يعمل على الشبكة الرئيسية عبر رول أب Brevis Chain مخصص لتنسيق المزادات. يشارك المُثبتون في مزادات المهام الإثباتية عبر تخزين BREV.
القيد الرئيسي هو الموعد النهائي: إذا لم يلتزم المُثبت بالموعد النهائي أو فشل في تقديم إثبات مؤهل في الوقت، يُخصم BREV المخزن. يربط ذلك موثوقية توفير الإثباتات بضمان حقيقي، ويحفز المُثبتين على قبول المهام التي يمكنهم تنفيذها في الوقت، ما يحافظ على جودة سوق الإثباتات.
تستند قيمة BREV إلى فائدة الشبكة: كأصل للتسوية، الضمان، والحوكمة في اقتصاد الإثباتات، يرتبط الطلب عليه بالاستخدام الفعلي لحوسبة Brevis القابلة للتحقق. ووفقًا للمدونة الرسمية لـBrevis (2025)، أنتجت الشبكة أكثر من 340 مليون إثبات، غطت أكثر من 50 بروتوكولًا على أكثر من 8 بلوكشينات، مع قاعدة تشغيلية قوية.
القيود الأساسية متعلقة بتصميم الآلية. تعتمد أمان coChain على وجود طاعنين نشطين وتخزين كافٍ من المُدقِّقين؛ إذا غاب الطاعنون أو كان التخزين منخفضًا، تضعف قدرة التصحيح الذاتي للاقتراحات المتفائلة. تحدد الحوكمة معايير مهمة مثل مدة نافذة الطعن ونسب slashing، وتؤثر ملاءمتها مباشرة على الأمان.
تشمل المخاطر اعتماد BREV على تبني منظومة Brevis وطلب الإثباتات، واعتماد ProverNet على مشاركة المُثبتين، وإمكانية وجود عيوب في العقود الذكية وتكامل SDK. هذه قيود آلية موضوعية وليست نصيحة استثمارية أو توقعات سعرية.
BREV هو رمز المنفعة والحوكمة الأصلي لشبكة Brevis، يربط جودة توفير الإثباتات بأمان الشبكة عبر ثلاث وظائف رئيسية: دفع رسوم الإثباتات، تخزين المُثبت كضمان، وحوكمة البروتوكول. يوفر coChain، وهو بلوكشين إثبات الحصة مع تخزين وslashing على Ethereum، مسار "اقتراح متفائل + طعن": تؤدي الاقتراحات الخاطئة إلى slashing على Ethereum، بينما تتجنب النتائج غير المطعون فيها تكاليف الإثبات. يمكن نشر كلا النموذجين حسب الحاجة عبر Brevis SDK، لتشكيل إطار أمني مرن يوازن بين الحتمية والكفاءة.
بصفته رمز المنفعة والحوكمة الأصلي لشبكة Brevis، يمتلك BREV ثلاث حالات استخدام رئيسية: يستخدم الطالبون BREV لدفع رسوم الإثباتات، ويخزن المُثبتون BREV كضمان لتلقي المهام ويخضعون لـslashing في حال المخالفات، ويشارك الحاملون في حوكمة البروتوكول.
يعتمد pure-ZK بالكامل على الإثباتات التشفيرية للثقة، حيث يتطلب إثبات معرفة صفرية لكل نتيجة، ما يوفر أعلى حتمية مقابل تكلفة وزمن استجابة أعلى. يضيف coChain طبقة نظرية الألعاب عبر التخزين وslashing، مستخدمًا اقتراحات متفائلة وآلية طعن لتقليل التكاليف وزمن الاستجابة عند عدم وجود طعن.
يتطلب coChain من المُدقِّقين تخزين ضمان على Ethereum وتقديم نتائج الحوسبة كاقتراحات للسلسلة الطالبة، ما يفعّل نافذة طعن. يمكن لأي طرف تقديم إثبات معرفة صفرية للطعن في اقتراح خاطئ خلال هذه النافذة؛ وإذا نجح الطعن، يُخصم ضمان المُدقِّق على Ethereum، ما يردع السلوك الضار بفعالية.
يقوم المُثبتون بتخزين BREV في ProverNet للفوز بمهام الإثبات. إذا لم يلتزم المُثبت بالموعد النهائي أو فشل في تقديم إثبات معرفة صفرية مؤهل في الوقت المحدد، سيتم خصم BREV المخزن، ما يضمن موثوقية التسليم في سوق الإثباتات اللامركزي.





