تجارة PSE: أين هو المخرج لإثباتات المعرفة الصفرية؟

المشاركة الأصلية كتبها @Calvin، محلل تداول PSE

"بشكل عام، وجهة نظري هي أنه على المدى القصير، يكون للتراكم المتفائل اليد العليا من حيث توافق EVM، في حين من المتوقع أن يكون ZKrollup أفضل في طبقات الدفع البسيطة والمعاملات وحالات الاستخدام المحددة الأخرى.

ومع ذلك ، على المدى المتوسط والطويل ، ستفوز مجموعة ZK في جميع حالات الاستخدام مع تحسين تقنية ZK-SNARK. "

هذه هي الكلمات الأصلية لـ God V في مدونته "دليل غير مكتمل إلى Rollups".

ZK هو المثل الأعلى لـ ETH، ويكشف تطبيق إثباتات المعرفة الصفرية (المشار إليها فيما يلي باسم ZK) في النظام البيئي للإيثريوم عن قدرته على حل مشكلة المثلث المستحيل لـ blockchain (أي الأمن وقابلية التوسع واللامركزية) دون المركزية) الاضطرار إلى الوصول إلى تفاصيل المعاملة الكاملة، وتحسين قابلية تطوير النظام دون المساس بالأمن.

! [تداول PSE: ما هو السبيل للخروج من براهين المعرفة الصفرية؟] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-577e1ceb57-dd1a6f-1c6801)

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

مع ZK المهم هذا، لماذا يتمتع الجميع بتجربة سيئة في استخدامه، ولا يمكن أن يسبب التنفيذ على نطاق واسع أي موجات؟

1. صفر المعرفة برهان مشكلة تراكمية الحالية

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

1.1 القضية الرئيسية والأكثر إلحاحًا: قضايا التوافق

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

هناك مقولة متداولة على الإنترنت: "أي شيء يمكن تنفيذه في Java سيتم تنفيذه في Java في النهاية".

هناك مفهوم آخر مهم ولكنه محير وهو "توافق EVM" و"مكافئ EVM".

** فهم الفجوة بين الاثنين من "التقارب" و "طريقة التنفيذ" —— **

"متوافق": النظام قادر على تنفيذ وفهم كود EVM الثانوي بطريقة تدعم العقود الذكية المكتوبة بلغة Solidity أو لغات EVM الأخرى.

"مكافئ": معادلة EVM هي شريط أعلى. النظام المكافئ لـ EVM ليس قادرًا فقط على تنفيذ كود EVM الثانوي، ولكنه يطابق أيضًا EVM تمامًا في السلوك والمسار. يجب أن تعمل جميع الأدوات والمكتبات التي تستهدف Ethereum أيضًا على أنظمة مكافئة لـ EVM دون أي تعديل.

** مزايا وعيوب "مكافئ EVM": **

ميزة:

دعم كامل لسلسلة الأدوات والبنية التحتية: تمتلك Ethereum نظامًا بيئيًا لسلسلة الأدوات والبنية التحتية الكبيرة ، بما في ذلك أدوات التطوير المختلفة ، وأطر الاختبار ، ومكتبات الأكواد ، والخدمات. إذا كان حل L2 مكافئًا لـ EVM ، فيمكن حينئذٍ دمج كل هذه الأدوات والخدمات معه بسلاسة ، لأنه من وجهة نظرهم ، فإن حل L2 هذا يشبه شبكة Ethereum أخرى.

• سهولة جذب المطورين وترحيلهم: أصبح المطورون على Ethereum معتادين على سلوك وخصائص EVM. إذا كان حل L2 مكافئًا لـ EVM، فيمكن للمطورين استخدام اللغة مباشرة (مثل Solidity) والأدوات التي يعرفونها بالفعل للتطوير على حل L2 هذا دون تعلم نموذج برمجة أو لغة جديدة.
• توافق أفضل للعقود: تعتمد العديد من عقود Ethereum الحالية على سلوك محدد لـ EVM. إذا كان حل L2 مكافئًا لـ EVM، فيمكن تشغيل هذه العقود على حل L2 هذا بدون أي تعديل أو بأقل قدر من التعديل.
• التحسينات والميزات المستقبلية لـ EVM: لا يزال EVM يتطور ويتحسن، وقد تقدم EIPs الجديدة (مقترحات تحسين Ethereum) ميزات أو تحسينات جديدة. يمكن تنفيذ هذه التحسينات والميزات بسهولة على حل L2 إذا كان مكافئًا لـ EVM.

سلبيات:

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

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

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

1.2 البيئة التقنية لمجموعة ZK غير ناضجة في الواقع

من منظور التحقق من البيانات ، تعد إمكانية التحقق من البيانات ميزة أساسية في نظام blockchain ، مما يضمن شفافية النظام وقابليته للتدقيق.

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

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

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

أثارت هذه التغييرات تحديات جديدة: كيف نضمن أمن النظام مع تقليل الاعتماد على بيانات السلسلة الرئيسية؟

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

وفقًا للوصف أعلاه، لا يزال تنفيذ مجموعة ZK بحاجة إلى الاعتماد على ETH لمزيد من التحسينات الملائمة لـ ZK، مثل تحسين طبقة DA وEVM.

1.3 بالإضافة إلى ZK rollup، هناك بعض المشاكل الأخرى، مثل مشاكل الكفاءة:

في مجال blockchain، تعد سرعة Sequencer (التي يتم قياسها عادةً بعدد المعاملات في الثانية، TPS) مؤشرًا رئيسيًا لتقييم أداء نظام ZK. يعتبر Sequencer مسؤولاً عن فرز المعاملات ومعالجتها، وتحدد قدرته المعالجة بشكل مباشر إنتاجية السلسلة بأكملها.

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

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

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

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

2. إثبات المعرفة الصفرية هو المثل الأعلى لـ ETH

لقد تحدثنا عن مشاكل ZK الحالية والصعوبات التي تواجهها ، فما سبب وفاة ZK؟

2.1

"تم تصميم بروتوكول Ethereum في الأصل كنسخة مطورة من العملات المشفرة ، مما يوفر وظائف متقدمة من خلال لغة برمجة ذات أغراض عامة للغاية ... بروتوكول Ethereum يتجاوز نطاق العملة."

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

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

2.2

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

الهيكل الحالي لـ Ethereum يضحي بالخصوصية من أجل الأمان والراحة. تعيد ETH تعريف مفهوم الخصوصية من خلال تقديم إثبات المعرفة الصفرية. ولم يعد يتعين على الناس الاختيار بين الخصوصية والأمان، بل يمكنهم التمتع بكلا الحقين في نفس الوقت.

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

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

2.3

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

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

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

3. انعدام المعرفة يثبت مسارًا معقولًا للتنفيذ في المستقبل

الضرورة هي الوجهة، والمشكلة هي الوضع الراهن، فما هو الطريق؟

** دعنا نتحدث عن الاستنتاج أولاً: وهو إجراء مجموعة ZK مكافئة لـ EVM، وانتظار Ethereum الحالي لترقية EVM المتوافق مع ZK، والسير جنبًا إلى جنب للمساعدة في التكامل المثالي بين تقنية ZK وETH. **

3.1 الأنواع الأربعة من ZKrollup في فم الله V

• ** النوع 1 (مكافئ إيثريوم كامل) **

يهدف النوع 1 ZK-EVM إلى أن يكون مكافئًا تمامًا لـ Ethereum دون مساومة. لا يغير أي شيء ، حتى لو كان من الصعب إنشاء البراهين.

المزايا: التوافق التام.

العيب: وقت إثبات طويل.

من يقوم بتطويرها؟ : إصدار المجتمع ZK-EVM.

• النوع 2 (مكافئ EVM الكامل)

يسعى النوع 2 ZK-EVM إلى أن يكون مكافئًا تمامًا لـ EVM ، ولكن مع تغييرات في هياكل البيانات الخارجية.

الميزة: مكافئ تمامًا على مستوى الجهاز الظاهري.

العيب: وقت إثبات محسّن ولكنه لا يزال بطيئًا.

من يقوم بتطويرها؟ : التمرير والمضلع هرمز.

• النوع 3 (يعادل EVM تقريبًا)

النوع 3 ZK-EVM يعادل تقريبًا EVM، ولكن تم إجراء بعض التنازلات لتحسين وقت الإثبات وسهولة التطوير.

المزايا: أسهل في البناء، وأسرع وقت للإثبات.

العيب: المزيد من عدم التوافق.

من يقوم بتطويرها؟ : التمرير والمضلع.

• ** النوع 4 (مكافئ لغوي عالي المستوى) **

تعمل أنظمة النوع 4 من خلال التجميع مباشرة من لغة عالية المستوى، دون التنفيذ من خلال EVM.

الميزة: وقت إثبات سريع جدًا.

العيب: المزيد من عدم التوافق.

من يقوم بتطويرها؟ : مشروع ZKSync وNethermind's Warp. (لاحظ أن StarkNet غير متوافق حتى مع EVM وهو خارج المناقشة)

! [تداول PSE: ما هو السبيل إلى إثبات عدم المعرفة؟] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-10dcb96b7b-dd1a6f-1c6801)

تقدم الأنواع المختلفة من ZK-EVM مجموعة معقدة من المقايضات بين التوافق والكفاءة.

يهدف النوع 1 إلى التوافق التام ، ولكنه يخضع لوقت الإثبات الطويل ، مما يكشف التحدي الحقيقي الذي لم يعتبره Ethereum تصميمًا صديقًا لـ ZK.

يسعى النوع 2 والنوع 3 إلى تحقيق التوازن بين التوافق الكامل وكفاءة الإثبات ، مما يوضح استكشاف الحلول العملية والتسوية عليها في ظل الظروف التقنية الحالية.

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

3.2 الترقية المشتركة لـ EVM و ZK: اعملوا معًا للاجتماع في النهاية

إن أفضل مسار لتطبيق ETH لتنفيذ ZK لا يشمل فقط تطبيق إثبات المعرفة الصفرية المكافئ لـ ZK EVM ، ولكن الأهم من ذلك ، ترقية وتحويل EVM نفسه.

• ** التحول الصديق لـ ZK لـ EVM **

يعد التحول الصديق لـ ZK لـ EVM عملية معقدة ولكنها ضرورية. لا يحتاج EVM فقط إلى أن يكون مكافئًا لـ ZK-EVM، ولكن يجب أيضًا أن يأخذ في الاعتبار التطوير المستقبلي المحتمل لـ ZK-SNARK ASICs.

• تعاون ثنائي الاتجاه بين ZK-EVM وEVM

لا يكمن التعاون بين ZK-EVM و EVM فقط في التوافق والكفاءة على المستوى التقني ، ولكن أيضًا في تكامل أدوات المطورين ودعم ما قبل الترجمة.

• خطوة بخطوة نحو المستقبل من النوع الأول

إنها رؤية العديد من الأشخاص لتحقيق النوع 1 تدريجيًا من خلال التحسين المستمر لـ ZK-EVM وEthereum نفسه. قد تكون العملية بطيئة، لكنها ترسم طريقًا واضحًا للمستقبل.

3.3 الجهود المشتركة والتعاون داخل البيئة هي النور

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

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

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

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

4. ملخص

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

الرابط الأصلي