1. ما هو معالج المساعدة وما ليس عليه؟

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

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

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

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

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

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

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

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

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

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

……

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

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

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

السابق يمكن أن يتركك مع مشاكل ثقة "غير سياسياً صحيحة".

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

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

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

ما يمكن تلخيصه من قبل معالج الشرطة إلى شيئين:

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

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

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

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

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

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

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

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

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

هذا لأنه عند استخدام Graph، أنت في الأساس لا تتورط في المال الحقيقي. تُقدم هذه الفهارس خدمات خارج السلسلة. ما تراه على واجهة المستخدم الأمامية هي حجم التداول، تاريخ التداول، الخ. يمكن توفير البيانات من خلال مقدمي فهارس بيانات متعددين مثل Graph، Alchemy، Zettablock، الخ، ولكن لا يمكن وضع هذه البيانات مرة أخرى في العقد الذكي، لأنه عندما تقوم بوضعها مرة أخرى، ستضيف ثقة إضافية في خدمة الفهرسة. عندما ترتبط البيانات بالمال الحقيقي، خاصةً في حالات التداول بأحجام كبيرة، تصبح هذه الثقة الإضافية مهمة. تخيل أنه في المرة القادمة التي يطلبك فيها صديقك إعارة 100 يوان، قد تقرضه دون تردد. نعم، ماذا عندما أطلب منك أن تقرضني 10,000 يوان، أو حتى مليون يوان؟

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

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

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

1. Brevis:

تتألف هندسة Brevis من ثلاثة مكونات: zkFabric و zkQueryNet و zkAggregatorRollup.

التالي هو رسم معماري لبريفيس:

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

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

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

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

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

تقوم شبكة برنامج تثبيت zkFabric Prover بتنفيذ دوائر لكل بروتوكول عميل خفي للبلوكشين ، وتقوم الشبكة بإنشاء دلائل صحة لرؤوس الكتلة. يمكن للمثبتين الاستفادة من مسرعات مثل وحدات المعالجة الرسومية ووحدات مجال برنامج التشغيل الميداني والدوائر المتكاملة للتطبيقات الخاصة لتقليل وقت البرهان والتكلفة.

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

توزيع البروفر: شبكة البروفر هي شبكة بروفر زيرو كنوليدج بروفر مركزية تختار بروفر لكل مهمة توليد إثبات وتدفع الرسوم لهؤلاء البروفرز.

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

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

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

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

1. هيرودوتس

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

الدولة L1 من L2s

حالات L2 من كل من L1s و L2s الأخرى

الدولة L3/App-Chain إلى L2s و L1s

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

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

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

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

دليل التخزين كما تم تعريفه من قبل هيرودوت هو انصهار ل:

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

تسلسل العمل :

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

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

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

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

هناك طريقتان للحصول على الهاش:

(1) استخدم كود العنوان الخاص بالكتلة لاسترجاع

(2) استعلام عن تجميعات التجزئة للكتل التي تم التحقق منها في التاريخ من متراكم تجزئة البلوك

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

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

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

stateRoot: مجموعة تجزئة تشفيرية لحالة سلسلة الكتل بأكملها في وقت حدوث سلسلة الكتل.

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

TransactionsRoot: معرف تشفيري لجميع المعاملات التي وقعت في الكتلة.

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

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

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

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

من إيثيريوم إلى ستاركنت

من إثيريوم جويرليإلى Starknet Goerli

من إثيريوم جويرليإلى zkSync Era Goerli

1. بديهية

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

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

تتكون البديل من جزأين رئيسيين من التكنولوجيا:

AxiomV1 — ذاكرة التخزين المؤقت لسلاسل الكتل في إيثيريوم، بدءاً من النشأة.

AxiomV1Query — العقد الذكي الذي ينفذ الاستعلامات ضد AxiomV1.

(1) القيمة المختصرة لكتلة الذاكرة المؤقتة في AxiomV1:

يقوم العقد الذكي AxiomV1 بتخزين هاشات كتل Ethereum منذ كتلة البداية بشكلين:

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

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

(2) تنفيذ الاستعلام في AxiomV1Query:

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

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

1. نيكسوس

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

لكي نكون دقيقين، يتم تقسيم الهندسة المعمارية إلى جزئين:

نيكسس صفر: شبكة حوسبة سحابية قابلة للتحقق لامركزية مدعومة بالبراهين المعرفية الصفرية و zkVM العالمي.

نيكسوس: شبكة حوسبة سحابية قابلة للتحقق مركزية مدعومة بالحوسبة متعددة الأطراف وتكرار آلية الحالة وآلة افتراضية WASM عالمية.

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

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

ترث تطبيقات Nexus Zero أمان Ethereum، حيث إنها برامج عالمية مع دلائل المعرفة الصفرية التي يمكن التحقق منها على السلسلة على منحنى البيانات الناقصة BN-254.

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

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

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