تفكيك المزايا التقنية للمعالج المشترك Ethereum ZK Axiom

المؤلف: شبكة القناع

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

النص التالي هو النسخة الصينية المترجمة من خطاب يي صن ، والرابط هو الفيديو المباشر:

أولاً ، دعنا نفهم رحلة المستخدم للوصول فعليًا إلى معلومات Ethereum. عندما كنا نستخدم Ethereum لأول مرة ، كانت الطريقة التي تلقينا بها بالفعل معلومات حول ما كان يحدث على السلسلة من خلال استدعاءات JSON-RPC لأرشفة التعليقات التوضيحية. الغرض من واجهة برمجة تطبيقات JSON-RPC هو تقديم معلومات فعلية حول السجل على السلسلة للمستخدم. بشكل أساسي ، يتم استخراج جميع المعلومات التي نراها حول blockchain من استدعاءات API هذه وتقديمها كإدخال على موقع الويب ليقرأه المستخدم.

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

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

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

الآن ، إذا فكرنا في الأمر ليس من منظور المستخدم ، ولكن من منظور العقد الذكي على Ethereum. بالطبع ، تريد العقود أيضًا أن تكون قادرة على الوصول إلى البيانات وإجراء عمليات حسابية عليها ، لكن هذا يمثل تحديًا أكبر. في الواقع ، إذا ذهبنا إلى OpenSea وألقينا نظرة على قائمة CryptoPunk ، فسنجد أنه من بين جميع المعلومات الموجودة على الصفحة ، يمكن الوصول إلى جزء صغير فقط في العقد الذكي على السلسلة.

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

أيضًا ، كما يمكن لأي مطور blockchain أن يخبرك ، فإن تشغيل العمليات الحسابية على السلسلة يعد مكلفًا للغاية ، على الرغم من أن Ethereum لديها عمليات فعالة نسبيًا للآلة الافتراضية (VM) ، كما أن التجميع المسبق يجعل أنواعًا معينة من العمليات أرخص. على سبيل المثال ، يوفر Ethereum دعمًا رخيصًا نسبيًا لعمليات المنحنى البيضاوي على منحنى BN254. ومع ذلك ، بالنسبة لبعض التطبيقات المحددة ، لا يزال Ethereum Virtual Machine بيئة تشغيل مكلفة للغاية. عند تصميم جهاز افتراضي لـ blockchain ، يجب على المرء اختيار مجموعة متأصلة من العمليات التي تحتاج إلى قياسها بعناية لضمان أن كل عقدة يمكنها التحقق من المعاملات في وقت ثابت. بالإضافة إلى ذلك ، يجب أيضًا مراعاة الاستقرار الأمني وتوافق الآراء في أسوأ الأحوال. لذا فإن التحدي هنا هو كيفية تنفيذ التحجيم الخاص بالتطبيقات للتطبيقات على السلسلة. تهدف اكسيوم إلى توسيع نطاق الوصول إلى البيانات وقدرات الحوسبة للعقود الذكية لتلبية احتياجات التوسع للتطبيقات المختلفة.

! [تفكيك المزايا التقنية للمعالج المشترك Ethereum ZK Axiom] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-b76a3ae720-dd1a6f-7649e1)

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

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

! [تفكيك المزايا التقنية للمعالج المشترك Ethereum ZK Axiom] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-9773eb20c1-dd1a6f-7649e1)

يمكننا التعرف على أنواع العمليات التي يمكن أن تنفذها أكسيوم ، ويمكن تقسيم كل استعلام إلى أكسيوم إلى ثلاثة أجزاء.

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

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

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

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

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

إذن ما هي فوائد التأمل؟

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

لسوء الحظ ، فإن القيام بذلك في EVM يعد مكلفًا. كما ذكرنا للتو ، يجب عليك التحقق من سلاسل التجزئة وإثباتات Merkle لجميع رؤوس الكتل ، والتي تتضمن العديد من حسابات تجزئة Keccak على كمية كبيرة من البيانات. لذلك بمجرد أن تعود بالزمن إلى الوراء ، يصبح الأمر صعبًا للغاية. لذلك ، نطبق عملية الانعكاس بلف هذا الدليل بـ ZK في EVM. لذا بدلاً من وضع جميع رؤوس الكتل السابقة وجميع أدلة Merkle هذه في السلسلة ثم التحقق منها ، فإننا نتحقق من عدم المعرفة فيما إذا كان هناك تسلسل لرؤوس الكتل السابقة وبعض أدلة التحقق.

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

اسمحوا لي أن أتطرق بإيجاز إلى المقايضات الخاصة بمفهوم عملية الانعكاس القائم على ZK.

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

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

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

ثم ننظر في كيفية تنفيذ عمليات الانعكاس من خلال اكسيوم.

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

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

ميزة أخرى نضيفها هي Merkle Mountain Range. إنه مبني على قمة ذاكرة التخزين المؤقت للكتل ، وهي بنية بيانات تسمح لنا بالإشارة إلى كل تجزئة كتلة في Ethereum في DNA محدود.

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

الآن دعنا نتحدث عن التطبيقات الممكنة لعملية التفكير المتصورة.

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

! [تفكيك المزايا التقنية للمعالج المشترك Ethereum ZK Axiom] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-6e1c8a9796-dd1a6f-7649e1)

لذلك ، فإن النوع الأول من التطبيق هو أحد التطبيقات التي يمكن أن تنفذها اكسيوم أو أي نوع من آليات عملية الانعكاس على Ethereum ، لكن التكلفة أعلى قليلاً.

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

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

على سبيل المثال ، أحد التطبيقات المثيرة للاهتمام هو السماح لـ Roll-up على Ethereum بقراءة حالة الطبقة الأساسية أو عرض Roll-up آخر بطريقة موثوقة ، باستخدام المعرفة الصفرية للتفاعل. قد يكون أحد هذه التطبيقات هو السماح لـ Roll-ups بقراءة لقطات الرصيد الكامل لرموز ERC20.

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

هناك أيضًا فئة من التطبيقات التي تستخدم البيانات التاريخية على السلسلة لإدارة البروتوكول فعليًا. يُعرف عمومًا باسم محاسبة الاتفاقية.

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

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

هذه مجرد أفكار قليلة لما يمكن أن تجلبه عمليات التفكير إلى blockchain.