نظرًا لأن مفهوم المعالجات المشتركة أصبح شائعًا في الأشهر الأخيرة، فقد بدأت حالة استخدام ZK الجديدة هذه في تلقي المزيد والمزيد من الاهتمام.

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

1. ما هو المعالج المشترك وما هو ليس كذلك؟

إذا طُلب منك شرح المعالجات المشتركة لشخص غير تقني أو مطور في جملة واحدة فقط، فكيف تصفها؟

أعتقد أن ما قاله الدكتور دونغ مو قد يكون قريبًا جدًا من الإجابة القياسية - بعبارة صريحة، فإن المعالج الثانوي «يمنح العقود الذكية القدرة على أداء Dune Analytics».

كيفية تفكيك هذه الجملة؟

تخيل السيناريو الذي نستخدم فيه Dune - تريد القيام بـ LP في Uniswap V3 لكسب بعض رسوم المناولة، لذلك تفتح Dune وتجد حجم التداول الأخير لأزواج التداول المختلفة على Uniswap، ومعدل الفائدة السنوية لرسوم المناولة في الأيام السبعة الماضية، وأزواج التداول السائدة نطاقات التذبذب العلوية والسفلية، وما إلى ذلك...

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

بالطبع، قد لا تحدق في هذه البيانات فحسب، بل إن فرق التطوير في Uniswap و StePN تولي اهتمامًا أيضًا لهذه البيانات.

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

على سبيل المثال، استنادًا إلى نمط وسعر الأحذية التي يشتريها المستخدمون ويبيعونها غالبًا، يوصى باستخدام أحذية مماثلة.

على سبيل المثال، سيتم إطلاق «برنامج مكافآت ولاء المستخدم» استنادًا إلى طول الفترة الزمنية التي يستغرقها المستخدمون في شراء Creation Shoes لمنح المستخدمين الأوفياء المزيد من التوزيعات المجانية أو المزايا.

على سبيل المثال، يمكن إطلاق خطة VIP مشابهة لـ Cex استنادًا إلى TVL أو حجم التداول المقدم من LP على Uniswap أو Trader، مما يمنح المتداول تخفيض رسوم المعاملات أو زيادة حصة رسوم LP...

في هذا الوقت، تأتي المشكلة - البيانات الضخمة لشركات الإنترنت الكبيرة+الذكاء الاصطناعي هي في الأساس صندوق أسود. يمكنهم أن يفعلوا ما يريدون. لا يمكن للمستخدمين رؤيتها ولا يهتمون.

ولكن هنا في Web3، الشفافية وعدم الثقة هما صوابنا السياسية الطبيعية، ونحن نرفض الصناديق السوداء!

لذلك عندما تريد إدراك السيناريو أعلاه، ستواجه معضلة - إما يمكنك تحقيق ذلك من خلال وسائل مركزية، واستخدام Dune «يدويًا» لحساب بيانات الفهرس في الخلفية، ثم نشرها وتنفيذها؛ أو يمكنك كتابة إعداد العقود الذكية لالتقاط هذه البيانات تلقائيًا على السلسلة، وإكمال العمليات الحسابية، ونشر النقاط تلقائيًا.

سيقودك الأول إلى مشكلات ثقة «غير صحيحة سياسيًا».

ستكون رسوم الغاز الناتجة عن الأخيرة على السلسلة رقمًا فلكيًا، ولا تستطيع محفظتك (من جانب المشروع) تحملها.

هذا هو الوقت المناسب ليظهر المعالج المشترك على خشبة المسرح. اجمع بين الطريقتين الآن، وفي نفس الوقت استخدم خطوة «دليل الواجهة الخلفية» «للتصديق الذاتي على البراءة» من خلال الوسائل التقنية. بعبارة أخرى، استخدم تقنية ZK «لفهرسة + جزء «الحساب» «يثبت البراءة ذاتيًا»، ثم يغذيها بالعقد الذكي. بهذه الطريقة، يتم حل مشكلة الثقة، وتختفي رسوم الغاز الضخمة. مثالي!

لماذا يطلق عليه «المعالج الثانوي»؟ في الواقع، يأتي هذا من «GPU» في تاريخ تطوير Web2.0. كان السبب وراء تقديم وحدة معالجة الرسومات (GPU) كجهاز كمبيوتر منفصل ووجودها بشكل مستقل عن وحدة المعالجة المركزية في ذلك الوقت هو أن بنية التصميم الخاصة بها يمكن أن تتعامل مع بعض العمليات الحسابية التي كان من الصعب بشكل أساسي على وحدة المعالجة المركزية التعامل معها، مثل الحسابات المتكررة المتوازية واسعة النطاق، وحسابات الرسومات، وما إلى ذلك. وبسبب بنية «المعالج المشترك» هذه بالتحديد، لدينا أفلام CG الرائعة والألعاب ونماذج الذكاء الاصطناعي وما إلى ذلك اليوم، لذا فإن بنية المعالج المشترك هذه هي في الواقع قفزة في بنية الحوسبة. الآن تأمل العديد من فرق المعالجات المشتركة أيضًا في إدخال هذه البنية في Web3.0. تشبه البلوكشين هنا وحدة المعالجة المركزية الخاصة بـ Web3.0. وسواء كانت L1 أو L2، فهي بطبيعتها غير مناسبة لمثل هذه المهام «للبيانات الثقيلة» و «منطق الحساب المعقد»، لذلك يتم تقديم معالج مشترك لبلوكتشين للمساعدة في التعامل مع مثل هذه الحسابات، وبالتالي توسيع إمكانيات تطبيقات بلوكتشين بشكل كبير.

لذلك يمكن تلخيص ما يفعله المعالج الثانوي في شيئين:

1. احصل على البيانات من blockchain واستخدم ZK لإثبات أن البيانات التي حصلت عليها صحيحة وليست مغشوشة؛
2. قم بإجراء الحسابات المقابلة بناءً على البيانات التي حصلت عليها للتو، واستخدم ZK مرة أخرى لإثبات أن النتائج التي قمت بحسابها صحيحة وليست مغشوشة. يمكن تسمية نتائج الحساب من خلال العقد الذكي «رسوم منخفضة+غير موثوقة».

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

المعالج المشترك ليس أكثر من الخطوة 1 تليها الخطوة 2. بعد استخراج البيانات دون ثقة، قم بإجراء عملية حسابية خالية من الثقة وهذا كل شيء.

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

شيء واحد يجب ملاحظته هو أن المعالج الثانوي ليس Rollup.

من الناحية الفنية، يشبه دليل ZK الخاص بـ Rollup الخطوة 2 أعلاه، ويتم تنفيذ عملية الخطوة 1 «الحصول على البيانات» مباشرةً من خلال Sequencer. حتى جهاز التسلسل اللامركزي يستخدم فقط نوعًا من المنافسة أو آلية الإجماع لتحقيق ذلك. خذ، بدلاً من إثبات التخزين، هذا الشكل من ZK. الأهم من ذلك هو أنه بالإضافة إلى طبقة الحساب، تحتاج ZK Rollup أيضًا إلى تنفيذ طبقة تخزين مشابهة لـ L1 blockchain. هذا التخزين دائم، في حين أن المعالج الثانوي ZK «عديم الجنسية». بعد اكتمال الحساب، لا يتم الاحتفاظ بحالة الكل.

من منظور سيناريوهات التطبيق، يمكن اعتبار المعالج الثانوي بمثابة مكون إضافي للخدمة لكل Layer1/Layer2، بينما تقوم Rollup بإعادة إنشاء طبقة تنفيذ للمساعدة في توسيع طبقة التسوية.

2. لماذا يجب علي استخدام ZK؟ هل من المقبول استخدام OP؟

بعد قراءة ما سبق، قد يكون لديك شك، هل يجب استخدام ZK كمعالج ثانوي؟ يبدو الأمر كثيرًا مثل «رسم بياني مع إضافة ZK»، ولا يبدو أن لدينا أي «شكوك كبيرة» حول نتائج الرسم البياني.

هذا لأنه عند استخدام Graph، لا يتم تضمين الأموال الحقيقية بشكل أساسي. تخدم هذه الفهارس خدمات خارج السلسلة. ما تراه على واجهة المستخدم الأمامية هو حجم المعاملات وسجل المعاملات وما إلى ذلك. يمكن توفير البيانات من خلال العديد من موفري فهرسة البيانات مثل Graph و Alchemy و Zettablock وما إلى ذلك، ولكن لا يمكن إعادة هذه البيانات إلى العقد الذكي، لأنه بمجرد إعادة إدخالها، ستضيف ثقة إضافية في خدمة الفهرس. عندما ترتبط البيانات بأموال حقيقية، وخاصة TVL كبيرة الحجم، تصبح هذه الثقة الإضافية مهمة. تخيل أنه في المرة القادمة التي يطلب فيها أحد الأصدقاء اقتراض 100 يوان، يمكنك فقط إقراضه دون غض عين. نعم، ماذا عن عندما أطلب منك اقتراض 10000 يوان، أو حتى مليون يوان؟

ولكن مرة أخرى، هل يتعين علينا حقًا استخدام ZK للمشاركة في معالجة جميع السيناريوهات المذكورة أعلاه؟ بعد كل شيء، لدينا طريقان تقنيان، OP و ZK، في Rollup. يحتوي ZKML الشهير مؤخرًا أيضًا على مفهوم OPML لمسارات الفروع المقابلة. عند السؤال، هل يحتوي المعالج الثانوي أيضًا على فرع من OP، مثل معالج OP الثانوي؟

في الواقع، هناك بالفعل - لكننا نحافظ على سرية التفاصيل المحددة في الوقت الحالي، وسنصدر المزيد من المعلومات التفصيلية قريبًا.

3. ما هو المعالج الثانوي الأفضل - مقارنة بين العديد من الحلول التقنية الشائعة للمعالج الثانوي في السوق

بريفيس

تتكون بنية بريفيس من ثلاثة مكونات: ZKFabric وZKQueryNet وZKaggregatorrollup.

فيما يلي مخطط معماري لـ Brevis:

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

ZkQueryNet: سوق محرك استعلام ZK مفتوح يقبل استعلامات البيانات من dApps ويعالجها. تقوم استعلامات البيانات بمعالجة هذه الاستعلامات باستخدام رؤوس الكتل التي تم التحقق منها من ZKFabric وإنشاء أدلة استعلام ZK. تحتوي هذه المحركات على وظائف متخصصة للغاية ولغات استعلام عامة لتلبية احتياجات التطبيقات المختلفة.

ZkAggregatorRollup: سلسلة بلوكشين تلافيفية ZK تعمل كطبقة تجميع وتخزين لـ ZKFabric و ZKQueryNet. وهو يتحقق من البراهين من كلا المكونين، ويخزن البيانات التي تم التحقق منها، ويلتزم بجذر الحالة المصدق عليه من zk لجميع سلاسل الكتل المتصلة.

يعد ZK Fabric جزءًا أساسيًا من إنشاء دليل لرأس الكتلة. من المهم جدًا ضمان أمان هذا الجزء. فيما يلي مخطط الهندسة المعمارية لـ ZKFabric:

عميل ZKFabric الخفيف المستند إلى إثبات عدم المعرفة (ZKP) يجعله غير موثوق به تمامًا، دون الاعتماد على أي كيان تحقق خارجي. ليست هناك حاجة للاعتماد على أي كيان تحقق خارجي، حيث يأتي أمنه بالكامل من بلوكتشين الأساسي والبراهين الموثوقة رياضيًا.

وتقوم شبكة ZKFabric Prover بتنفيذ الدوائر لكل بروتوكول Lightclient الخاص ببلوكتشين، وتقوم الشبكة بإنشاء أدلة صلاحية لرؤوس الكتل. يمكن لـ Provers الاستفادة من المسرعات مثل وحدات معالجة الرسومات و FPGAs و ASICs لتقليل وقت الإثبات والتكلفة.

تعتمد ZKFabric على افتراضات الأمان الخاصة بـ blockchain وبروتوكولات التشفير الأساسية وافتراضات الأمان لبروتوكولات التشفير الأساسية. ومع ذلك، لضمان فعالية ZKFabric، يلزم وجود مرحل صادق واحد على الأقل لمزامنة الشوكة الصحيحة. لذلك، يستخدم ZKFabric شبكة ترحيل لامركزية بدلاً من مرحل واحد لتحسين فعالية ZKFabric. يمكن لشبكة الترحيل هذه الاستفادة من الهياكل الحالية، مثل شبكة حراس الدولة في شبكة Celer.

تخصيص Prover: شبكة prover هي شبكة وكيل ZKP لامركزية تختار محسنًا لكل مهمة من مهام إنشاء الإثبات وتدفع رسومًا لهؤلاء المثبتين.

النشر الحالي:

تُعد بروتوكولات العميل الخفيفة التي يتم تنفيذها حاليًا للعديد من سلاسل البلوكشين بما في ذلك Ethereum PoS و Cosmos Tendermint و BNB Chain بمثابة أمثلة وإثبات للمفاهيم.

تعاونت Brevis حاليًا مع uniswap hook، والذي يضيف بشكل كبير مجمعات uniswap المخصصة. ومع ذلك، بالمقارنة مع CEX، لا تزال UniSwap تفتقر إلى قدرات معالجة البيانات الفعالة لإنشاء مشاريع تعتمد على بيانات معاملات المستخدم الكبيرة (مثل برامج الولاء القائمة على حجم المعاملات). الوظيفة.

بمساعدة Brevis، حل هوك التحدي. يمكن لـ Hooks الآن القراءة من بيانات سلسلة التاريخ الكاملة للمستخدم أو LP وتشغيل حسابات قابلة للتخصيص بطريقة غير موثوقة تمامًا.

هيرودوت

Herodotus عبارة عن برنامج وسيط قوي للوصول إلى البيانات يوفر عقودًا ذكية بالوظائف التالية للوصول المتزامن إلى البيانات الحالية والتاريخية على السلسلة عبر طبقة Ethereum:

1. حالات L1 من L2s
2. حالات L2 من كل من L1s و L2s الأخرى
3. حالات L3/سلسلة التطبيقات إلى L2s و L1s

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

ويتمثل جوهر بلوكتشين في قاعدة البيانات، حيث يتم تشفير البيانات وحمايتها باستخدام هياكل البيانات مثل أشجار Merkle وأشجار Merkle Patricia. ما يميز هياكل البيانات هذه هو أنه بمجرد الالتزام بالبيانات بشكل آمن بها، يمكن إنشاء أدلة لتأكيد احتواء البيانات داخل الهيكل.

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

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

إثبات التخزين كما حدده هيرودوت هو مزيج من:

1. براهين الاحتواء: تؤكد هذه البراهين وجود بيانات محددة في بنية بيانات مشفرة (مثل شجرة Merkle أو شجرة Merkle Patricia)، مما يضمن أن البيانات المعنية موجودة بالفعل في مجموعة البيانات.
2. الإثبات الحسابي: تحقق من تنفيذ سير عمل متعدد الخطوات، مما يثبت صحة عنصر واحد أو أكثر في مجموعة بيانات واسعة، مثل سلسلة بلوكشين إيثريوم بأكملها أو التجميع. بالإضافة إلى الإشارة إلى وجود البيانات، فإنها تتحقق أيضًا من التحويلات أو العمليات المطبقة على تلك البيانات.
3. براهين المعرفة الصفرية: قم بتبسيط كمية البيانات التي تحتاج العقود الذكية للتفاعل معها. تسمح براهين المعرفة الصفرية للعقود الذكية بتأكيد صحة المطالبة دون معالجة جميع البيانات الأساسية.

سير العمل

1. الحصول على تجزئة الكتلة

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

2. الحصول على رأس الكتلة

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

هناك طريقتان للحصول على التجزئة:

1. استخدم كود تشغيل BLOCKHASH للاسترداد
2. قم بالاستعلام عن تجزئة الكتل التي تم التحقق منها في التاريخ من Block Hash Accumulator

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

3. تحديد الجذور المطلوبة (اختياري)

مع وجود رأس الكتلة في متناول اليد، يمكننا الخوض في محتوياته، على وجه التحديد:

StateRoot: ملخص مشفر لحالة البلوكشين بأكملها في وقت حدوث البلوكشين.

ReceiptsRoot: ملخص مشفر لجميع نتائج المعاملات (الإيصالات) في الكتلة.

TransactionsRoot: ملخص مشفر لجميع المعاملات التي حدثت في الكتلة.

يمكن فك تشفيرها، مما يسمح بالتحقق مما إذا كان هناك حساب أو إيصال أو معاملة معينة مضمنة في الكتلة.

4. التحقق من صحة البيانات مقابل الجذر المحدد (اختياري)

باستخدام الجذر الذي اخترناه، وبالنظر إلى أن إيثريوم تستخدم بنية Merkle-Patricia Trie، يمكننا استخدام دليل إدراج Merkle للتحقق من وجود البيانات في الشجرة. ستختلف خطوات التحقق اعتمادًا على البيانات وعمق البيانات داخل الكتلة.

الشبكات المدعومة حاليًا:

1. من إيثريوم إلى ستاركنت
2. من إيثريوم جورلي إلى ستاركنت جورلي
3. من إيثريوم جورلي إلى زيكسنك إيرا جورلي

اكسيوم

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

أصدرت أكسيوم مؤخرًا Halo2-repl، وهو برنامج halo2 REPL قائم على المتصفح مكتوب بلغة جافا سكريبت. يتيح ذلك للمطورين كتابة دوائر ZK باستخدام جافا سكريبت القياسي فقط دون الحاجة إلى تعلم لغة جديدة مثل Rust أو تثبيت مكتبات إثبات أو التعامل مع التبعيات.

تتكون أكسيوم من مكونين تقنيين رئيسيين:

1. AxiomV1 - ذاكرة التخزين المؤقت لبلوكتشين لإيثيريوم، بدءًا من جينيسيس.
2. AxiomV1Query - عقد ذكي يقوم بتنفيذ الاستعلامات ضد AxiomV1.

تجزئات الكتل في التخزين المؤقت في AxiomV1:

ذاكرة التخزين المؤقت للعقود الذكية AxiomV1 تجزئات كتلة إيثريوم منذ كتلة التكوين في شكلين:

أولاً، يتم تخزين جذر Keccak Merkle المكون من 1024 تجزئة كتلة متتالية مؤقتًا. يتم تحديث جذور Merkle هذه عبر براهين ZK، للتحقق من أن تجزئة رأس الكتلة تشكل سلسلة التزام تنتهي بواحدة من أحدث 256 كتلة يمكن الوصول إليها مباشرة من EVM أو تجزئة الكتلة الموجودة بالفعل في ذاكرة التخزين المؤقت AxiomV1.

ثانيًا، تخزن أكسيوم سلسلة جبال ميركل من جذور ميركل هذه بدءًا من كتلة التكوين. تم بناء سلسلة جبال Merkle على السلسلة من خلال تحديث الجزء الأول من ذاكرة التخزين المؤقت، جذر Keccak Merkle.

قم بتنفيذ الاستعلام في استعلام Axiomv1:

يُستخدم العقد الذكي AxiomV1Query للاستعلامات المجمعة لتمكين الوصول غير الموثوق به إلى رؤوس كتل إيثريوم التاريخية والحسابات والبيانات التعسفية المخزنة في الحسابات. يمكن إجراء الاستعلامات على السلسلة وإكمالها على السلسلة عبر براهين ZK مقابل تجزئات الكتلة المخزنة مؤقتًا من AxiomV1.

تتحقق أدلة ZK هذه مما إذا كانت البيانات ذات الصلة على السلسلة موجودة مباشرة في رأس الكتلة، أو في حساب الكتلة أو حاوية التخزين، من خلال التحقق من إثبات التضمين (أو عدم التضمين) لثلاثية Merkle-Patricia.

رابطة

تحاول Nexus استخدام براهين المعرفة الصفرية لبناء منصة عالمية للحوسبة السحابية التي يمكن التحقق منها. وهي حاليًا لا تعتمد على بنية الماكينة وتدعم risc 5/WebAssembly/EVM. يستخدم Nexus نظام إثبات السوبرنوفا. اختبر الفريق أن الذاكرة المطلوبة لإنشاء الدليل هي 6 جيجابايت. في المستقبل، سيتم تحسينه على هذا الأساس حتى تتمكن أجهزة الكمبيوتر العادية من إنشاء أدلة.

على وجه الدقة، تنقسم البنية إلى قسمين:

1. Nexus zero: شبكة حوسبة سحابية لا مركزية يمكن التحقق منها مدعومة ببراهين المعرفة الصفرية و zKVM العالمية.
2. Nexus: شبكة حوسبة سحابية لا مركزية يمكن التحقق منها مدعومة بحسابات متعددة الأطراف، وتكرار آلة الحالة، وآلة WASM الافتراضية العالمية.

يمكن كتابة تطبيقات Nexus و Nexus Zero بلغات البرمجة التقليدية، التي تدعم حاليًا Rust، مع المزيد من اللغات القادمة.

تعمل تطبيقات نيكسوس على شبكة حوسبة سحابية لامركزية، وهي في الأساس عبارة عن «بلوكتشين بدون خادم» للأغراض العامة ومتصلة مباشرة بإيثيريوم. لذلك، لا ترث تطبيقات Nexus أمان Ethereum، ولكن في المقابل تحصل على إمكانية الوصول إلى قوة حوسبة أعلى (مثل الحوسبة والتخزين والإدخال/الإخراج القائم على الأحداث) بسبب الحجم المنخفض لشبكتها. تعمل تطبيقات Nexus على سحابة مخصصة تحقق إجماعًا داخليًا وتوفر «أدلة» يمكن التحقق منها للحساب (بدلاً من البراهين الحقيقية) من خلال توقيعات عتبة يمكن التحقق منها على مستوى الشبكة داخل إيثريوم.

ترث تطبيقات Nexus Zero أمان إيثريوم، نظرًا لأنها برامج عالمية ذات براهين خالية من المعرفة يمكن التحقق منها على السلسلة على منحنى BN-254 البيضاوي.

نظرًا لأن Nexus يمكنه تشغيل أي ثنائي WASM حتمي في بيئة منسوخة، فمن المتوقع استخدامه كمصدر لإثبات الصلاحية/التشتت/التسامح مع الخطأ للتطبيقات التي تم إنشاؤها، بما في ذلك متسلسلات zk-rollup ومتسلسلات التجميع المتفائلة وغيرها من البراهين الخادم، مثل خادم zkVm الخاص بـ Nexus Zero نفسه.

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [panewslab]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [ABCDE]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.