【مقدمة】

تم بناء البلوكشين بالكامل على التشفير، لأن التشفير قد أوجد بيئة الطبقة الأولى من دفتر الأستاذ الموزع بأكمله؛ وبسبب التشفير، ظهرت خطة توسيع الطبقة الثانية خارج السلسلة. في أغسطس 2022، أصدرت Vitalik «مقالة «الأنواع المختلفة من ZK-EVMs» مقارنة شاملة لحلول التوسع السائدة الحالية، كما هو موضح في الشكل أدناه:

الخطوة 1: نظرة عامة على الأنواع المختلفة من ZK-EVMS

لذلك، تدور حلول توسيع ZkVM الحالية بشكل أساسي حول حل zKevm، لأن حلول ZkVM الأخرى غير متوافقة مع استمرار ودعم البيئة الحالية، ولكنها ستكون مشكلة من حيث المستقبل. تعد ترقية Web2 جزءًا مهمًا من Web3، خاصة بعد ظهور الحلول التي يمثلها ZkWasm والمتوافقة مع العديد من لغات C ++ و Rust و Go و AssemblyScript و C # وغيرها من اللغات، أصبح من الممكن ترقية نظام حساب تطبيقات Web2؛ ZkWasm المتوقع من اليسار إلى الماضي، ينتقل ZkWasm من اليمين إلى الخلف لبناء بيئة كبيرة من ترقيات تطبيقات Web3 بشكل مشترك، بدلاً من الاستمرار الخلاف حول السلسلة العامة الذي كان مربكًا لسنوات عديدة.

【لتر؛ جاف】

1. تتمثل الوظيفة الأساسية النهائية لـ Ethereum في وضع دفتر الأستاذ الموزع لتسوية DA+Settlement + الإجماع. يعد حل ZkWasm من eWasm أكثر ملاءمة لبناء نظام Web3.0 البيئي.

2. يرث zKevm الماضي ويحسن بيئة البلوكشين، ويبدأ ZkWasm المستقبل ويخلق مستقبل Web3.0!

3. أنشئ مجموعات باستخدام ZkWasm، وليس فقط البلوكشين

【يرث zKevM الماضي، ZkWasm يبدأ المستقبل】

كما ذكرنا في المقدمة، فإن العصر البيئي الذي يربط حقًا Web2.0 و Web3.0 هو عصر Approllup. بالمقارنة مع البيئة التي لا تزال هادئة بشأن فكرة السلسلة، لا يحتاج عصر التجميع إلى إنشاء عدد كبير جدًا من السلاسل، لأن السلسلة تلعب دور دفتر الأستاذ، أي أن طبقة الحساب تنفصل عن تطبيق منفصل وتعود إلى الطبقة العامة، مع إعادة الملكية إلى المستخدم؛ السلسلة هي بطبيعة الحال مثل الناقل، حيث تقوم بالوظائف الأساسية لتوافر البيانات (DA) والتسوية والتوافق.

الشكل 2: يعتبر ApprollUp أكثر مرونة بكثير من Appchain

【ZKP，دليل عدم المعرفة】

في التشفير، يعد إثبات المعرفة الصفرية (الإنجليزية: إثبات المعرفة الصفرية) أو بروتوكول المعرفة الصفرية (بروتوكول المعرفة الصفرية) طريقة لطرف واحد (المُثبت) لإثبات اقتراح معين للطرف الآخر (المختبر). السمة هي أنه في هذه العملية، «لن يتم الكشف عن أي معلومات بخلاف أن الاقتراح صحيح. لذلك، يمكن فهمه على أنه «مقاوم للتسرب الصفري». تم اقتراحه لأول مرة من قبل شافي جولدفاسر وسيلفيو ميكالي وتشارلز راكوف من معهد ماساتشوستس للتكنولوجيا في ورقة عام 1985 بعنوان «التعقيد المعرفي لأنظمة الإثبات التفاعلية» ([GMR85]). ذكر المؤلف في الورقة أنه من الممكن أن يقنع المُثبت بأصالة البيانات دون الكشف عن البيانات المحددة. يمكن أن يكون إثبات المعرفة الصفرية تفاعليًا، أي أنه يجب على المُثبت إثبات صحة البيانات مرة واحدة لكل مدقق؛ يمكن أيضًا أن يكون غير تفاعلي، أي أن المُثبت ينشئ دليلًا، ويمكن التحقق من أي شخص يستخدم هذا الدليل.

الصورة 3: تاريخ تطوير براهين المعرفة الصفرية

ربما يكون ZK-snark (حجج المعرفة الموجزة غير التفاعلية) هو الشكل الأكثر شيوعًا لإثبات عدم المعرفة، حيث ظهر لأول مرة في ورقة Bit+11 لعام 2011. بحلول عام 2013، يمكن استخدام براهين المعرفة الصفرية في تطبيقات العالم الحقيقي بفضل ورقة Pinocchio PHGR13، التي جعلت ZK-SNARKS مناسبة للحساب العام، وإن كان ذلك بشكل أبطأ. أدت خوارزمية Groth16 المقترحة في عام 2016 إلى تقليل التعقيد الحسابي بشكل كبير، مما جعل ZK-SNARKS فعالة للغاية بحيث تظل المعيار اليوم.

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

وأعقب ذلك تقديم مضاد للرصاص (BBBPWM17) في عام 2017 وZK-Starks (BBHR18) في عام 2018. على عكس سابقاتها، فهي نوع من إثبات النطاق الذي لا يتطلب إعدادًا أوليًا للثقة. نفذت ورقة Plonk لعام 2019 خوارزمية عالمية لإثبات عدم المعرفة، مما يعني أنه يجب بدء إعداد واحد موثوق به فقط، على عكس Groth16، الذي يتطلب إعدادًا منفصلاً موثوقًا لكل دائرة.

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

لذلك، تشكل ZK-SNARKS و ZK-starks و PLONK و Bulletproof طرق التنفيذ الرئيسية الحالية لإثبات عدم المعرفة. كل طريقة لها مزاياها وعيوبها من حيث حجم الإثبات ووقت الإثبات ووقت التحقق. في حل توسيع بلوكتشين، يدور الأمر أساسًا حول طريقة التنفيذ الصديقة لـ ZK-Snark.

【WASM، تجميع الويب】

WebAssembly (WASM باختصار) هو عضو جديد نسبيًا في عائلة تكنولوجيا الويب (JavaScript و HTML و CSS) وأصبح معيارًا معترفًا به رسميًا من قبل W3C في ديسمبر 2019. يقدم WebAssembly وقت تشغيل جديدًا في المتصفح يعمل مع وقت تشغيل JavaScript. وبالمقارنة، فهي أكثر خفة وزنًا وتحتوي على مجموعة تعليمات صغيرة ونموذج عزل صارم (لا يحتوي WebAssembly على I/O افتراضيًا). كان أحد الدوافع الرئيسية لتطوير WebAssembly هو توفير أهداف تجميع لمزيد من لغات البرمجة (C ++ و Rust و Go وما إلى ذلك)، مما يسمح للمطورين بتطوير تطبيقات ويب جديدة أو نقل التطبيقات الحالية باستخدام مجموعة أدوات أوسع.

الشكل 4: منطقة Wasm

سواء كان Web2 أو Web3، أصبح نطاق الدعم والاستخدام لـ Wasm أكثر شمولاً:

الشكل 5: الشركات والمؤسسات الكبرى في النظام البيئي WebAssembly

【ZkWasm = zip + WASM】

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

الشكل 6: بيئة ZkWASM

يمكن تمثيل الاتجاه المنطقي العام للبيانات بالشكل التالي:

الصفحة 7：العقود على السلسلة+الآلة الافتراضية خارج السلسلة (VM) +قابلية تركيب WASM

تضمن جزء أساسي مهم من تحديث Ethereum 2.0 الأولي أيضًا الانتقال من EVM إلى eWASM؛ ومع ذلك، لم يكن التقدم الفعلي لـ 2.0 كما هو متوقع، لذلك لم يتم ذكر eWASM كثيرًا في خطة التخطيط الأخيرة.

الشكل 8: الخطة الشاملة لـ ETH 2.0

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

يتم التعرف على المزايا الرئيسية لاستخدام eWASM على EVM من قبل التيار الرئيسي على النحو التالي:

1. الأداء: بالمقارنة مع EVM، يوفر eWASM أداءً أفضل لأنه يستخدم WebAssembly، والذي تم تصميمه ليكون أسرع وأكثر كفاءة من رمز بايت EVM. يوفر WebAssembly أداءً شبه أصلي، والذي يمكن أن يزيد بشكل كبير من سرعة شبكة Ethereum وقابليتها للتطوير.

2. قابلية التشغيل البيني: يوفر eWASM إمكانية التشغيل البيني بشكل أفضل من EVM لأنه يدعم لغات برمجة متعددة، بما في ذلك C ++ و Rust و AssemblyScript. يتيح ذلك للمطورين كتابة العقود الذكية بلغتهم المفضلة، وتحسين جودة التعليمات البرمجية وإنتاجية المطورين.

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

4. المرونة: توفر eWASM مرونة أفضل من EVM لأنها تدعم الربط الديناميكي، والذي يسمح للعقود الذكية بأن تتكون من وحدات متعددة يمكن تحديثها بشكل مستقل. يمكن أن يؤدي ذلك إلى تنظيم أفضل للكود وصيانة أسهل للعقود الذكية.

5. دعم المجتمع: تلقت eWASM دعمًا قويًا من مجتمع Ethereum، وقام العديد من عملاء Ethereum الرئيسيين، بما في ذلك Geth و Parity، بتنفيذ دعم eWASM. وهذا يعني أن المطورين يمكنهم الوصول إلى مجموعة واسعة من الأدوات والموارد عند إنشاء العقود الذكية باستخدام eWASM.

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

الشكل 9: يقترح فيتاليك بوترين أحدث خارطة طريق لإيثيريوم

تقسم خارطة الطريق الترقيات إلى عدة فئات بناءً على تأثيرها على بنية Ethereum. وهذا يشمل:

الدمج: يتضمن الترقية من إثبات العمل إلى إثبات الحصة

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

الآفة: ترقية تنطوي على مخاطر البروتوكول لمقاومة الرقابة واللامركزية والقيمة القصوى القابلة للاستخراج

Verge: ترقيات تتضمن التحقق الأسهل من الكتل

التطهير: يتضمن تقليل التكلفة الحسابية لعقد التشغيل وتبسيط ترقيات البروتوكول

Splurge: ترقيات أخرى لا تندرج ضمن الفئات المذكورة أعلاه

يدرك الجميع أن الوظيفة الأساسية النهائية لـ Ethereum هي وضع دفتر الأستاذ الموزع لـ DA + Settlement + Consensus. وبهذه الطريقة، لا تتطلب العديد من متطلبات قابلية التوسع الكثير من التعديلات على إيثريوم نفسها وتؤدي إلى مخاطر أخرى غير معروفة. الأسماك والدببة. طريقة الحصول على كليهما في نفس الوقت هي تقسيم العمل إلى طبقات. يجب أن يكون وضع eWASM على الطبقة الثانية حلاً أكثر معقولية وفعالية. خاصة بعد الدمج مع zk، يمكن للحل التقني لـ ZkWasm أن يرث تمامًا التأثير الذي تريد eWasm تحقيقه. في الوقت نفسه، يمكنها تقديم خدمات لكل من Web2 و Web3 وتوصيل بعضها البعض. يرث zKevm الماضي ويحسن بيئة blockchain، ويبدأ ZkWasm المستقبل ويخلق مستقبل Web3.0!

الشكل 10: ZkWasm = zkp + WASM

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

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