المؤلف: زيكي، YBB Capital المصدر: ترجمة متوسطة: شان أوبا، Golden Finance

الملخص

• يمكن اعتبار المعالج المساعد ZK بمثابة مكون إضافي للحوسبة خارج السلسلة مشتق من المفهوم المعياري، مشابه إلى التقليدية تقوم وحدة معالجة الرسومات (GPU) في الكمبيوتر بتفريغ مهام حوسبة الرسومات من وحدة المعالجة المركزية (CPU) ومعالجة مهام حوسبة محددة.

• يمكن استخدامها للتعامل مع الحسابات المعقدة وكميات كبيرة من البيانات، وتقليل رسوم الغاز وتوسيع وظائف العقود الذكية.

• خلافًا للمجموعات المجمعة، فإن المعالج المساعد ZK عديم الحالة ويمكن استخدامه عبر السلاسل، مما يجعله مناسبًا لسيناريوهات الحوسبة المعقدة.

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

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

1. فرع آخر من البنية التحتية المعيارية: المعالج المساعد ZK

1.1 نظرة عامة على المعالج الثانوي ZK

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

في الوقت الحالي، تتمتع التطبيقات الشائعة مثل AI وSocialFi وDEX وGameFi باحتياجات ملحة للأداء العالي والتحكم في التكلفة. في الحلول التقليدية، غالبًا ما تختار هذه "التطبيقات الثقيلة" ذات متطلبات الأداء العالية للغاية نموذج تطبيق الأصول الموجود على السلسلة + خارج السلسلة، أو تصمم سلسلة تطبيقات منفصلة. ومع ذلك، فإن كلا الطريقتين لهما مشاكل متأصلة: فالأول لديه "صندوق أسود"، بينما يواجه الأخير مشاكل مثل ارتفاع تكاليف التطوير، والانفصال عن بيئة السلسلة الأصلية، والسيولة المجزأة. بالإضافة إلى ذلك، تفرض الآلة الافتراضية للسلسلة الرئيسية أيضًا قيودًا كبيرة على تطوير وتشغيل مثل هذه التطبيقات (مثل الافتقار إلى معايير طبقة التطبيق، ولغات التطوير المعقدة، وما إلى ذلك).

تم تصميم المعالج المساعد ZK لحل هذه المشكلات. ولإعطاء مثال أكثر تحديدًا، يمكننا أن نتخيل blockchain كمحطة طرفية لا يمكنها الاتصال بالإنترنت (مثل الهاتف المحمول أو الكمبيوتر). في هذا السيناريو، يمكننا تشغيل تطبيقات بسيطة نسبيًا بالكامل على السلسلة، مثل Uniswap أو تطبيقات التمويل اللامركزي. ولكن عندما تظهر تطبيقات أكثر تعقيدًا، مثل تشغيل تطبيقات مثل ChatGPT، سيكون أداء السلسلة العامة وتخزينها غير كافٍ تمامًا، مما يؤدي إلى انفجار الغاز. في سيناريو Web2، عندما نقوم بتشغيل ChatGPT، لا تستطيع المحطة العادية نفسها التعامل مع نموذج اللغة الكبير GPT-4o، نحتاج إلى الاتصال بخادم OpenAI لنقل السؤال، بعد أن يحسب الخادم النتيجة ويستنتجها مباشرة. يشبه المعالج المساعد ZK خادمًا بعيدًا لـ blockchain. قد تحتوي مشاريع المعالج المساعد المختلفة على اختلافات طفيفة في التصميم اعتمادًا على نوع المشروع، ولكن المنطق الأساسي هو نفسه تقريبًا - الحساب خارج السلسلة + إثبات ZK أو إثبات التخزين للتحقق.

خذ نشر Rise Zero's Bonsai كمثال. هذه البنية بديهية للغاية. يتكامل المشروع بسلاسة مع zkVM الخاصة بشركة Rise Zero، مما يسمح للمطورين باستخدام Bonsai كمعالج مساعد في خطوتين بسيطتين فقط:

• اكتب تطبيق zkVM للتعامل مع منطق التطبيق.

• اكتب عقد Solidity الذي يطلب من Bonsai تشغيل تطبيق zkVM الخاص بك ومعالجة النتائج.

الفرق بين 1.2 وrollups

من التعريف أعلاه يبدو أن منطق تنفيذ وأهداف Rollups وZK Coprocessors متداخلة إلى حد كبير، لكن Rollups أشبه بامتداد متعدد النواة للسلسلة الرئيسية. الاختلافات المحددة بين الاثنين هي كما يلي:

1 .الغرض الرئيسي:

• المجموعات: تعزيز إنتاجية معاملات blockchain وتقليل رسوم المعاملات.

• المعالج المساعد ZK: يعمل على توسيع قدرات الحوسبة التعاقدية الذكية للتعامل مع المنطق الأكثر تعقيدًا وكميات أكبر من البيانات.

2 مبدأ العمل:

• < p style="text-align: left;">المجموعات: تجميع المعاملات على السلسلة وإرسالها إلى السلسلة الرئيسية مع إثبات الاحتيال أو إثبات ZK.

• المعالج المساعد ZK: مشابه لـ ZK Rollups، ولكنه مصمم لسيناريوهات تطبيق مختلفة. لا تعد ZK Rollups مناسبة لمهام المعالج الثانوي بسبب القيود والقواعد الخاصة بالسلسلة.

3. إدارة الحالة:

• < p style="text-align: left;">المجموعات: تحافظ على حالتها وتتزامن مع السلسلة الرئيسية بانتظام.

• المعالج المساعد ZK: عديم الحالة، كل عملية حسابية عديمة الحالة.

4.سيناريوهات التطبيق:

• < p style="text-align: left;">المجموعات: تخدم بشكل أساسي المستخدمين النهائيين، ومناسبة للتداول عالي التردد.

• المعالج المساعد ZK: يخدم المؤسسات بشكل أساسي وهو مناسب للسيناريوهات التي تتطلب حسابات معقدة، مثل النماذج المالية المتقدمة وانتظار تحليل البيانات الضخمة .

5. العلاقة مع السلسلة الرئيسية:

< li>

المجموعات: تعتبر امتدادًا للسلسلة الرئيسية، وتركز عادةً على شبكة blockchain محددة.

• المعالج المشترك ZK: يمكن أن يخدم سلاسل كتل متعددة، ولا يقتصر على سلسلة رئيسية محددة، ويمكنه أيضًا خدمة Rollups.

وبالتالي، فإن الاثنين ليسا متنافيين ولكنهما متكاملان. حتى لو كان Rollup موجودًا في شكل سلسلة تطبيق، فإن معالجات ZK المساعدة لا يزال من الممكن تقديم الخدمات.

1.3 حالات الاستخدام

من الناحية النظرية، نطاق تطبيق المعالج المساعد ZK واسع جدًا، ويغطي مشاريع في مجالات مختلفة من blockchain. يمكّن المعالج المساعد ZK التطبيقات اللامركزية من الحصول على وظائف أقرب إلى تطبيقات Web2 المركزية. فيما يلي بعض أمثلة حالات الاستخدام التي تم جمعها من مصادر عبر الإنترنت:

تطوير التطبيقات اللامركزية المستندة إلى البيانات:

يُمكّن المعالج المساعد ZK المطورين من إنشاء تطبيقات Dapps تعتمد على البيانات والتي تستفيد من البيانات التاريخية الكاملة على السلسلة لإجراء حسابات معقدة دون افتراضات ثقة إضافية. وهذا يفتح إمكانيات غير مسبوقة لتطوير التطبيقات اللامركزية، مثل:

• تحليل البيانات المتقدم: مماثل قيد التشغيل - وظيفة تحليل البيانات المتسلسلة في Dune Analytics.

• منطق الأعمال المعقد: تنفيذ خوارزميات معقدة ومنطق الأعمال في التطبيقات المركزية التقليدية.

• التطبيقات عبر السلسلة: إنشاء تطبيقات Dapps عبر السلسلة استنادًا إلى بيانات متعددة السلاسل.

خطة المتداول VIP من DEX:

خطة نموذجية سيناريو التطبيق هو تنفيذ برنامج خصم يعتمد على حجم التداول في DEX، أي "برنامج ولاء المتداولين VIP". مثل هذه الخطط شائعة في بورصات CEX ولكنها نادرة في بورصات DEX.

باستخدام المعالج المساعد ZK، يمكن لـ DEX:

• تتبع حجم المعاملات التاريخية للمستخدم.

• احسب مستوى VIP الخاص بالمستخدم.

• اضبط رسوم المعاملات ديناميكيًا بناءً على مستوى VIP. تساعد هذه الميزة بورصات DEX على تحسين الاحتفاظ بالمستخدمين، وزيادة السيولة، وزيادة الإيرادات في النهاية.

تحسين بيانات العقود الذكية:

رابطة ZK يمكن أن يكون المعالج بمثابة برنامج وسيط قوي يوفر خدمات التقاط البيانات وحسابها والتحقق منها للعقود الذكية، وبالتالي تقليل التكاليف وتحسين الكفاءة. يتيح ذلك للعقود الذكية:

• الوصول إلى كميات كبيرة من البيانات التاريخية ومعالجتها.

• إجراء عمليات حسابية معقدة خارج السلسلة.

• تنفيذ منطق أعمال أكثر تقدمًا.

تقنية الجسور عبر السلسلة:

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

1.4 المعالج المساعد ZK ليس مثاليًا

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

1. التطوير: يصعب على العديد من المطورين إتقان مفهوم ZK. يتطلب التطوير معرفة التشفير ذات الصلة وإتقان لغات وأدوات تطوير محددة.

2. تكلفة الأجهزة المرتفعة: يجب أن يتحمل طرف المشروع أجهزة ZK المستخدمة للحوسبة خارج السلسلة بالكامل، كما أن أجهزة ZK باهظة الثمن إنه يتطور بسرعة ويمكن التخلص منه في أي وقت. أما ما إذا كان يمكن أن يشكل حلقة عمل مغلقة فهو سؤال يستحق التفكير فيه.

3. حقل مزدحم: من الناحية الفنية، لن يكون هناك اختلاف كبير في التنفيذ ومن المرجح أن تكون النتيجة النهائية مشابهة للنتيجة A الحالية منظر طبيعي للطبقة الثانية يبرز فيه عدد قليل من المشاريع البارزة بينما يتم تجاهل الباقي إلى حد كبير.

4. دوائر ZK: يتطلب إجراء العمليات الحسابية خارج السلسلة في معالج مساعد ZK تحويل برامج الكمبيوتر التقليدية إلى دوائر ZK. تعد كتابة دوائر مخصصة لكل تطبيق أمرًا مرهقًا، وتتحمل كتابة الدوائر باستخدام zkVM في جهاز افتراضي أعباء حسابية كبيرة بسبب اختلاف نماذج الحوسبة.

II. العناصر الأساسية للتبني الجماعي

( المحتوى الموجود في هذا القسم شخصي للغاية ويمثل فقط وجهات النظر الشخصية للمؤلف.)

تقود هذه الدورة بشكل أساسي البنية التحتية المعيارية. إذا كانت النمطية هي المسار الصحيح، فقد تكون هذه الدورة هي الخطوة الأخيرة نحو التبني الشامل. ومع ذلك، في هذه المرحلة، لدينا جميعًا شعور مشترك: لماذا نرى فقط بعض التطبيقات القديمة يتم إعادة تجميعها، ولماذا يوجد سلاسل أكثر من التطبيقات، ولماذا يتم الترحيب بمعايير الرموز الجديدة مثل Inscription باعتبارها أعظم ابتكار في الدورة؟

السبب الأساسي لعدم وجود روايات جديدة هو أن البنية التحتية المعيارية الحالية ليست كافية لدعم التطبيقات الفائقة، وخاصة عدم وجود بعض المتطلبات الأساسية (عبر السلسلة قابلية التشغيل البيني، وحواجز المستخدم، وما إلى ذلك)، مما يؤدي إلى أشد تجزئة في تاريخ blockchain. وباعتبارها جوهر العصر المعياري، فقد أدت عمليات التجميع إلى تسريع العملية بالفعل، ولكنها جلبت أيضًا العديد من المشكلات، مثل تجزئة السيولة، وتشتت المستخدمين، والقيود المفروضة على ابتكار التطبيقات بواسطة السلسلة أو الجهاز الظاهري نفسه. بالإضافة إلى ذلك، شقت "سيليستيا"، "لاعبًا رئيسيًا" آخر في مجال الوحدات النمطية، طريقًا حيث لا يوجد DA بالضرورة على إيثريوم، مما يزيد من تفاقم التجزئة. سواء كانت مدفوعة بالأيديولوجية أو بتكلفة DA، فإن النتيجة هي أن BTC تضطر إلى أن تصبح DA، وتهدف السلاسل العامة الأخرى إلى توفير حلول DA أكثر فعالية من حيث التكلفة. الوضع الحالي هو أن كل سلسلة عامة لديها ما لا يقل عن واحد أو حتى عشرات من مشاريع الطبقة الثانية. بالإضافة إلى ذلك، تعلمت جميع مشاريع البنية التحتية والبيئة بعمق استراتيجية التوقيع على الرموز المميزة التي ابتكرتها Blur، والتي تتطلب من المستخدمين التعهد بالرموز المميزة داخل المشروع. يسمح هذا النموذج للحيتان بالاستفادة من ثلاثة جوانب (الفائدة، وارتفاع قيمة ETH أو BTC، والرموز المجانية)، مع زيادة ضغط السيولة على السلسلة أيضًا.

في السوق الصاعدة الماضية، كانت الأموال تتدفق فقط في عدد قليل إلى اثنتي عشرة من السلاسل العامة، حتى أنها كانت تركز بشكل أساسي على Ethereum. وتنتشر الأموال الآن عبر مئات السلاسل العامة وتراهن على آلاف المشاريع المماثلة، مما يؤدي إلى انخفاض النشاط على السلسلة. حتى Ethereum يعاني من نقص النشاط على السلسلة. لذا، فإن اللاعبين الشرقيين يتنافسون مع لاعب ضد لاعب في نظام BTC البيئي، بينما يتنافس اللاعبون الغربيون مع لاعب ضد لاعب في Solana بدافع الضرورة.

لذلك، ينصب تركيزي الحالي على كيفية تعزيز السيولة الإجمالية لجميع السلاسل ودعم ظهور طرق لعب جديدة وتطبيقات فائقة. في مجال قابلية التشغيل البيني عبر السلاسل، كان أداء المشاريع الرائدة التقليدية ضعيفًا ولا تزال مشابهة للجسور التقليدية عبر السلاسل. تهدف حلول التشغيل البيني الجديدة التي ناقشناها في التقارير السابقة في المقام الأول إلى تجميع سلاسل متعددة في سلسلة واحدة. تشمل الأمثلة AggLayer وSuperchain وElastic Chain وJAM وما إلى ذلك، والتي لن يتم تقديمها واحدة تلو الأخرى هنا. بشكل عام، يعد التجميع عبر السلاسل عقبة ضرورية أمام البنية التحتية المعيارية، لكن التغلب عليها سيستغرق وقتًا طويلاً.

يعد المعالج المساعد ZK جزءًا أساسيًا من المرحلة الحالية. أنها تعزز Layer2 وتكمل Layer1. هل هناك طريقة للتغلب مؤقتًا على السلسلة المتقاطعة والمعضلة الثلاثية، مما يسمح لنا بتنفيذ بعض تطبيقات العصر الحالي على بعض الطبقة 1 أو الطبقة 2 بسيولة واسعة النطاق؟ ففي نهاية المطاف، تفتقر تطبيقات البلوكتشين إلى روايات جديدة. بالإضافة إلى ذلك، فإن تمكين أوضاع اللعب المتنوعة، والتحكم في الغاز، والتطبيقات واسعة النطاق، وقدرات السلسلة المتقاطعة، وخفض حواجز المستخدم من خلال حلول المعالجات المشتركة المتكاملة، قد يكون أكثر مثالية من الاعتماد على المركزية.

3. نظرة عامة على المشروع

ظهر مجال المعالج المشترك ZK في عام 2023 تقريبًا. في هذه المرحلة، أنها ناضجة نسبيا. وفقًا لتصنيف مساري، يغطي هذا المجال حاليًا ثلاثة قطاعات رئيسية (الحوسبة العامة، وقابلية التشغيل البيني والسلسلة المتقاطعة، والذكاء الاصطناعي والتدريب الآلي) بإجمالي 18 مشروعًا. يتم دعم معظم هذه المشاريع من قبل شركات رأس المال الاستثماري الرائدة. نقدم أدناه عدة مشاريع من مجالات رأسية مختلفة.

p>

3.1 الجيزة 

تكمل الجيزة سير العمل في ثلاث خطوات:

• تحويل النموذج: تقوم جيزة بتحويل نماذج الذكاء الاصطناعي بتنسيق ONNX شائعة الاستخدام إلى تنسيق يمكن تشغيله في نظام إثبات المعرفة الصفرية. يتيح ذلك للمطورين تدريب النماذج باستخدام أدوات مألوفة ثم نشرها على شبكة الجيزة.

• الاستدلال خارج السلسلة: عندما يطلب العقد الذكي استدلال نموذج الذكاء الاصطناعي، ستقوم جيزة بإجراء الحسابات الفعلية خارج السلسلة. وهذا يتجنب التكلفة العالية لتشغيل نماذج الذكاء الاصطناعي المعقدة مباشرة على blockchain.

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

يسمح نهج الجيزة لنماذج الذكاء الاصطناعي بالعمل كمصادر إدخال موثوقة للعقود الذكية دون الاعتماد على أوراكل مركزية أو بيئة تنفيذ موثوقة. وهذا يفتح إمكانيات جديدة لتطبيقات blockchain مثل إدارة الأصول القائمة على الذكاء الاصطناعي واكتشاف الاحتيال والتسعير الديناميكي. إنه أحد المشاريع القليلة في مجال Web3 x AI الحالي الذي يحتوي على حلقة مغلقة منطقية ويستخدم بذكاء المعالجات المشتركة في مجال الذكاء الاصطناعي.

3.2 Risc Zero

Risc Zero عبارة عن منصة رائدة مدعومة من قبل العديد من أفضل المعالجين المساعدين لرأس المال الاستثماري مشروع. إنه يركز على تمكين تنفيذ أي حساب بشكل يمكن التحقق منه ضمن عقد ذكي لـ blockchain. يمكن للمطورين كتابة البرامج بلغة Rust ونشرها على شبكة RISC Zero. يقوم RISC Zero بعد ذلك بالتحقق من صحة تنفيذ البرنامج من خلال إثباتات المعرفة الصفرية وتقديم النتائج إلى العقد الذكي بطريقة غير موثوقة. يتيح ذلك للمطورين إنشاء تطبيقات معقدة على السلسلة مع الحفاظ على لامركزية blockchain وإمكانية التحقق منها.

لقد ذكرنا بإيجاز النشر وسير العمل سابقًا. نوضح هنا بالتفصيل مكونين رئيسيين:

• Bonsai: Bonsai هو RISC Zero، مكون المعالج المساعد يعمل بسلاسة مدمجة في zkVM لبنية مجموعة التعليمات RISC-V. فهو يسمح للمطورين بدمج براهين المعرفة الصفرية عالية الأداء بسرعة في Ethereum وL1 blockchains وCosmos Application Chain وL2 Rollups وdApps في أيام. وهو يوفر استدعاءًا مباشرًا للعقد الذكي، وحسابًا خارج السلسلة يمكن التحقق منه، وقابلية التشغيل البيني عبر السلسلة، ووظيفة التجميع الشاملة، مع اعتماد بنية موزعة تعتمد اللامركزية أولاً. إلى جانب البراهين العودية، ومترجم الدوائر المخصصة، واستمرارية الحالة، وخوارزميات الإثبات دائمة التحسين، فإنه يمكّن أي شخص من إنشاء براهين عالية الأداء بدون معرفة لمجموعة متنوعة من التطبيقات.

• zkVM: zkVM هو جهاز كمبيوتر يمكن التحقق منه ويعمل مثل معالج دقيق RISC-V مضمن حقيقي. يعتمد على بنية مجموعة تعليمات RISC-V ويسمح للمطورين بكتابة برامج يمكنها إنشاء إثباتات المعرفة الصفرية باستخدام لغات برمجة عالية المستوى مثل Rust وC++ وSolidity وGo. وهو يدعم أكثر من 70% من حزم Rust الشائعة، ويجمع بسلاسة بين الحوسبة العامة وإثباتات المعرفة الصفرية، ويمكنه إنشاء براهين فعالة للمعرفة الصفرية لحسابات التعقيد التعسفي مع الحفاظ على خصوصية عملية الحساب وإمكانية التحقق من النتائج. تستخدم zkVM تقنيات المعرفة الصفرية مثل STARK وSNARK لتحقيق توليد إثبات فعال والتحقق من خلال مكونات مثل Recursion Prover وSTARK-to-SNARK Prover، مما يدعم التنفيذ خارج السلسلة والتحقق عبر السلسلة.

لقد تم دمج Risc Zero مع العديد من حلول ETH Layer2 وأظهر حالات استخدام متنوعة لـ Bonsai. مثال مثير للاهتمام هو Bonsai Pay. يستخدم هذا العرض التوضيحي خدمات إثبات zkVM وBonsai من RISC Zero للسماح للمستخدمين بإرسال أو سحب ETH والرموز المميزة على Ethereum باستخدام حساب Google الخاص بهم. وهو يوضح كيف يمكن لـ RISC Zero دمج التطبيقات الموجودة على السلسلة بسلاسة مع OAuth2.0، وهو المعيار المستخدم من قبل موفري الهوية الرئيسيين مثل Google، مما يوفر حالة استخدام لخفض الحواجز لمستخدمي Web3 عبر تطبيقات Web2 التقليدية. تتضمن الأمثلة الأخرى التطبيقات المستندة إلى DAO.

3.3 =nil;

=nil عبارة عن منصة مكونة من Mina وPolychain و Starkware، مشاريع استثمارية مدعومة من مؤسسات معروفة مثل Blockchain Capital. ومن الجدير بالذكر أن رواد تقنية zk مثل Mina وStarkware هم أيضًا من الداعمين، مما يشير إلى أن المشروع يحظى بتقدير كبير من الناحية الفنية. =nil; تم ذكره أيضًا في تقريرنا "Hash Power Market"، مع التركيز بشكل أساسي على سوق الإثبات (سوق توليد الإثبات اللامركزي). بالإضافة إلى ذلك، يحتوي =nil; على منتج فرعي آخر يسمى zkLLVM.

تم تطوير zkLLVM بواسطة مؤسسة =nil; وهو عبارة عن مترجم دوائر مبتكر يمكنه تحويل رموز التطبيقات المكتوبة بلغات البرمجة السائدة مثل C++ و Rust قم بالتحويل إلى دوائر فعالة وقابلة للإثبات لـ Ethereum دون الحاجة إلى لغات متخصصة خاصة بمجال المعرفة الصفرية (DSLs). يؤدي هذا إلى تبسيط عملية التطوير إلى حد كبير، ويقلل من حاجز الدخول، ويحسن الأداء عن طريق تجنب zkVM. وهو يدعم تسريع الأجهزة لتسريع عملية إنشاء الأدلة، مما يجعله مناسبًا لمختلف سيناريوهات تطبيقات ZK، مثل عمليات التجميع والجسور عبر السلاسل والأوراكل والتعلم الآلي والألعاب. إنه متكامل بشكل وثيق مع سوق إثبات =nil; Foundation، مما يوفر للمطورين دعمًا شاملاً بدءًا من إنشاء الدوائر وحتى إنشاء الأدلة.

3.4 Brevis

Brevis هو مشروع فرعي لشبكة Celer وهو الصفر الذكي لـ معالج مشترك لـ blockchain Knowledge (ZK) يمكّن التطبيقات اللامركزية من الوصول إلى البيانات التعسفية وحسابها واستخدامها عبر سلاسل كتل متعددة بطريقة غير موثوقة تمامًا. مثل المعالجات المشتركة الأخرى، لدى Brevis مجموعة واسعة من حالات الاستخدام مثل DeFi المستندة إلى البيانات، وzkBridges، واكتساب المستخدمين على السلسلة، وzkDID، وتجريد الحسابات الاجتماعية.

p>

تتكون بنية Brevis من ثلاثة أجزاء رئيسية:

• zkFabric: zkFabric هو مكون الترحيل في بنية Brevis. وتتمثل مهمته الرئيسية في جمع ومزامنة معلومات رأس الكتلة من جميع سلاسل الكتل المتصلة، ثم إنشائها لكل رأس كتلة تم جمعها من خلال عميل ZK Light الدائرة إثبات الإجماع.

• zkQueryNet: zkQueryNet هو سوق محركات استعلام ZK مفتوح يمكنه قبول استعلامات البيانات مباشرة من العقود الذكية على السلسلة وتمرير ZK تقوم دائرة محرك الاستعلام بإنشاء نتائج الاستعلام وإثباتات استعلام ZK المقابلة. تتراوح هذه المحركات من المتخصصة للغاية (على سبيل المثال، حساب حجم المعاملات على DEX خلال فترة محددة) إلى تجريدات فهرس البيانات ذات الأغراض العامة للغاية ولغات الاستعلام عالية المستوى لتلبية مجموعة متنوعة من احتياجات التطبيقات.

• zkAggregatorRollup: باعتبارها طبقة التجميع والتخزين لـ zkFabric وzkQueryNet، فهي مسؤولة عن التحقق من اعتماد هذين المكونين وتخزينهما. البيانات المعتمدة، وإرسال جذر الحالة الذي أثبت كفاءته ZK إلى جميع سلاسل الكتل المتصلة، مما يسمح للتطبيقات اللامركزية بالوصول مباشرة إلى نتائج الاستعلام المثبتة في منطق أعمال العقد الذكي الخاص بها على السلسلة.

من خلال هذه البنية المعيارية، يمكن لـ Brevis توفير وصول غير موثوق به وفعال ومرن إلى جميع العقود الذكية المدعومة للسلسلة العامة. يعتمد إصدار V4 من UNI أيضًا هذا الحل ويدمجه مع Hooks (نظام لدمج مختلف المنطق المحدد من قبل المستخدم) لتسهيل قراءة بيانات blockchain التاريخية، وتقليل تكاليف الغاز، وضمان اللامركزية. هذا مثال على المعالج المساعد zk الذي يقوم بتشغيل DEX.

3.5 Lagrange 

Lagrange هي مبادرة للتشغيل البيني بقيادة 1kx وصندوق المؤسسين المعرفة تم تصميم بروتوكول المعالج المشترك بشكل أساسي لتوفير إمكانية التشغيل البيني عبر السلاسل غير الموثوقة ودعم التطبيقات التي تتطلب حسابات معقدة على بيانات واسعة النطاق. على عكس جسور العقدة التقليدية، يتم تحقيق قابلية التشغيل البيني عبر سلسلة Lagrange بشكل أساسي من خلال البيانات الضخمة المبتكرة التي لا تعتمد على المعرفة الصفرية وآليات اللجنة الوطنية.

• ZK Big Data: هذا هو المنتج الأساسي لـ Lagrange، وهو المسؤول عن معالجة البيانات المتقاطعة والتحقق منها. -سلسلة البيانات وإنشاء أدلة المعرفة الصفرية ذات الصلة. يشتمل هذا المكون على معالج ZK متوازي للغاية لإجراء حسابات معقدة خارج السلسلة وإنشاء إثباتات المعرفة الصفرية؛ وقاعدة بيانات مصممة خصيصًا يمكن التحقق منها تدعم فتحات تخزين غير محدودة واستعلامات SQL المباشرة من العقود الذكية؛ وهي آلية تحديث ديناميكية للتغيير فقط ونقاط البيانات لتقليل وقت الإثبات، وميزة متكاملة تسمح للمطورين بالوصول إلى البيانات التاريخية باستخدام استعلامات SQL مباشرة من العقود الذكية دون كتابة دوائر معقدة. إنهم يشكلون معًا نظامًا واسع النطاق لمعالجة البيانات والتحقق منها.

• لجنة الحالة: هذا المكون عبارة عن شبكة تحقق لامركزية تتكون من عدة عقد مستقلة تتعهد كل عقدة بـ ETH كضمان. تعمل هذه العقد كعملاء ZK light وهي متخصصة في التحقق من حالة بعض مجموعات التحسين. تم دمج لجنة الدولة مع AVS الخاص بـ EigenLayer، وذلك باستخدام آلية إعادة التخزين لتعزيز الأمان، ودعم عدد غير محدود من العقد المشاركة، وتحقيق نمو أمني فائق الخطية. كما أنه يوفر "وضعًا سريعًا" يسمح للمستخدمين بإجراء عمليات عبر السلسلة دون انتظار نافذة التحدي، مما يحسن تجربة المستخدم بشكل كبير. إن الجمع بين هاتين التقنيتين يمكّن Lagrange من معالجة البيانات واسعة النطاق بكفاءة، وإجراء حسابات معقدة، ونقل النتائج والتحقق منها بشكل آمن بين سلاسل الكتل المختلفة، مما يدعم تطوير التطبيقات المعقدة عبر السلاسل.

تم دمج Lagrange مع EigenLayer وMantle وBase وFrax وPolymer وLayerZero وOmni وAltLayer وما إلى ذلك. سيصبح ZK AVS الثالث المرتبط بالنظام البيئي Ethereum.