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

تقوم كل عقدة إيثريوم بتشغيل عميل إجماعي وعميل تنفيذ. اعتبارًا من اليوم، لا يشكل أي عميل إجماع أو تنفيذ أكثر من ثلثي الشبكة. إذا كان لدى العميل الذي لديه أقل من 1/3 حصة في فئته خطأ ما، فستستمر الشبكة ببساطة كالمعتاد. إذا كان العميل الذي لديه حصة تتراوح بين 1/3 و2/3 في فئته (مثل Prysm أو Lighthouse أو Geth) يعاني من خطأ، فستستمر السلسلة في إضافة الكتل، لكنها ستتوقف عن إنهاء الكتل، مما يمنح المطورين الوقت للتدخل.

أحد التحولات الكبرى القادمة التي لم تتم مناقشتها، ولكنها مع ذلك مهمة جدًا، في الطريقة التي يتم بها التحقق من صحة سلسلة Ethereum، هو ظهور ZK-EVMs. إن SNARKs التي تثبت تنفيذ EVM كانت قيد التطوير منذ سنوات بالفعل، ويتم استخدام التكنولوجيا بشكل نشط من خلال بروتوكولات الطبقة الثانية التي تسمى ZK rollups. بعض مجموعات ZK هذه نشطة على الشبكة الرئيسية اليوم، وسيتوفر المزيد قريبًا. ولكن على المدى الطويل، لن تكون أجهزة ZK-EVM مخصصة فقط لعمليات التجميع؛ نريد استخدامها للتحقق من التنفيذ على الطبقة 1 أيضًا (انظر أيضًا: The Verge).

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

ما هو الدافع الأصلي لفلسفة تعدد العملاء في Ethereum؟

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

الحجج لصالح اللامركزية التقنية

الفائدة الرئيسية من اللامركزية التقنية بسيطة: فهي تقلل من خطر أن يؤدي خطأ واحد في برنامج واحد إلى انهيار كارثي للشبكة بأكملها. الموقف التاريخي الذي يجسد هذا الخطر هو خطأ تجاوز سعة البيتكوين في عام 2010. في ذلك الوقت، لم يتحقق رمز عميل Bitcoin من أن مجموع مخرجات المعاملة لا يتجاوز (يلتف حول الصفر عن طريق الجمع إلى أعلى من الحد الأقصى لعدد صحيح وهو 2⁶⁴−1)، ولذلك أجرى شخص ما معاملة لم تنجح هذا بالضبط، ويمنحون أنفسهم المليارات من عملات البيتكوين. تم اكتشاف الخطأ في غضون ساعات، وتم التعجيل بإصلاحه ونشره بسرعة عبر الشبكة، ولكن لو كان هناك نظام بيئي ناضج في ذلك الوقت، لكان من الممكن قبول هذه العملات من خلال البورصات والجسور والهياكل الأخرى، وكان من الممكن أن يتمكن المهاجمون من الحصول على هذه العملات. هرب مع الكثير من المال. لو كان هناك خمسة عملاء مختلفين للبيتكوين، لكان من المستبعد جدًا أن يكون لديهم جميعًا نفس الخطأ، وبالتالي لكان هناك انقسام فوري، ومن المحتمل أن يخسر جانب الانقسام الذي كان به عربات التي تجرها الدواب.

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

وأنا بالطبع لا أتفق مع هذا التحليل. جوهر خلافي هو أن (1) الأخطاء الكارثية التي حدثت في عام 2010 مهمة أيضًا، و(2) أنك لا تملك في الواقع سوى عميل واحد فقط. أصبحت النقطة الأخيرة أكثر وضوحًا من خلال انقسام البيتكوين في عام 2013: حدث انقسام في السلسلة بسبب خلاف بين نسختين مختلفتين من عميل البيتكوين، وتبين أن أحدهما يحتوي على حد عرضي وغير موثق لعدد العناصر التي يمكن يمكن تعديلها في كتلة واحدة. ومن ثم، فإن العميل الواحد من الناحية النظرية غالبًا ما يكون عميلين اثنين في الممارسة العملية، وخمسة عملاء من الناحية النظرية قد يكونون ستة أو سبعة عملاء في الممارسة العملية - لذلك يجب علينا فقط أن نخاطر ونسير على الجانب الأيمن من منحنى المخاطرة، وأن يكون لدينا على الأقل عدد قليل من العملاء المختلفين.

حجج اللامركزية السياسية

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

كان القلق بشأن سياسات البروتوكول، لا سيما في سياق حروب Bitcoin OP_RETURN 2013-2014 حيث كان بعض المشاركين يؤيدون بشكل علني التمييز ضد استخدامات معينة للسلسلة، عاملاً مساهمًا مهمًا في اعتماد Ethereum المبكر لفلسفة العملاء المتعددين، والتي كان الهدف منه هو جعل الأمر أكثر صعوبة على مجموعة صغيرة لاتخاذ هذا النوع من القرارات. وقد قدمت المخاوف الخاصة بالنظام البيئي للإيثريوم - أي تجنب تركيز السلطة داخل مؤسسة الإيثريوم نفسها - مزيدًا من الدعم لهذا الاتجاه. في عام 2018، تم اتخاذ قرار بتعمد عدم تنفيذ المؤسسة لبروتوكول Ethereum PoS (على سبيل المثال. ما يسمى الآن "عميل الإجماع")، وترك هذه المهمة بالكامل للفرق الخارجية.

كيف ستأتي ZK-EVMs على الطبقة الأولى في المستقبل؟

اليوم، يتم استخدام ZK-EVMs في عمليات التجميع. يؤدي هذا إلى زيادة التوسع من خلال السماح بتنفيذ EVM باهظ الثمن لبضع مرات فقط خارج السلسلة، مع قيام الجميع ببساطة بالتحقق من SNARKs المنشورة على السلسلة والتي تثبت أن تنفيذ EVM قد تم حسابه بشكل صحيح. كما يسمح أيضًا بعدم تضمين بعض البيانات (خاصة التوقيعات) على السلسلة، مما يوفر تكاليف الغاز. يمنحنا هذا الكثير من فوائد قابلية التوسع، والجمع بين الحسابات القابلة للتطوير مع ZK-EVMs والبيانات القابلة للتطوير باستخدام <a href="https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling"> يمكن لأخذ عينات توفر البيانات أن يسمح لنا بالتوسع إلى حد كبير.

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

الخيار 1: تضييق الطبقة 1، وإجبار جميع الأنشطة تقريبًا على الانتقال إلى الطبقة 2

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

يمكن أن ينجح هذا النهج، لكن به عدة نقاط ضعف مهمة:

• إنه أمر غير متوافق مع الإصدارات السابقة بحكم الأمر الواقع، بمعنى أن العديد من التطبيقات الحالية المستندة إلى اللغة الأولى تصبح غير قابلة للحياة اقتصاديًا. يمكن أن تتعطل أموال المستخدمين التي تصل إلى مئات أو آلاف الدولارات عندما تصبح الرسوم مرتفعة للغاية بحيث تتجاوز تكلفة إفراغ تلك الحسابات. يمكن معالجة هذه المشكلة من خلال السماح للمستخدمين بتوقيع الرسائل لاختيار الترحيل الجماعي داخل البروتوكول إلى لغة L2 من اختيارهم (راجع بعض أفكار التنفيذ المبكرة هنا)، ولكن هذا يضيف تعقيدًا إلى عملية الانتقال، كما أن جعلها رخيصة بما يكفي يتطلب الأمر نوع من SNARK في الطبقة 1 على أي حال. أنا عمومًا من محبي كسر التوافق مع الإصدارات السابقة عندما يتعلق الأمر <a href="https://hackmd.io/@vbuterin/selfdestruct"> بأشياء مثل كود التشغيل SELFDESTRUCT، ولكن في هذه الحالة تبدو المقايضة أقل تفضيلًا بكثير.
• ربما لا يزال لا يجعل عملية التحقق رخيصة بما فيه الكفاية. من الناحية المثالية، يجب أن يكون من السهل التحقق من بروتوكول إيثريوم ليس فقط على أجهزة الكمبيوتر المحمولة ولكن أيضًا داخل الهواتف وملحقات المتصفح وحتى داخل السلاسل الأخرى. يجب أيضًا أن تكون مزامنة السلسلة لأول مرة، أو بعد فترة طويلة من عدم الاتصال بالإنترنت، أمرًا سهلاً. يمكن لعقدة الكمبيوتر المحمول التحقق من وجود مليون غاز في حوالي 20 مللي ثانية، ولكن حتى هذا يعني 54 ثانية للمزامنة بعد يوم واحد دون الاتصال بالإنترنت (بافتراض<a href="https://notes.ethereum.org/ @vbuterin /single_slot_finality">فردي تزيد نهائية الفتحة من أوقات الفتحة إلى 32 ثانية)، وبالنسبة للهواتف أو ملحقات المتصفح، فقد يستغرق الأمر بضع مئات من المللي ثانية لكل كتلة وقد يظل ذلك بمثابة استنزاف لا يمكن إهماله للبطارية. يمكن التحكم في هذه الأرقام، لكنها ليست مثالية.
• حتى في النظام البيئي الذي يعتمد على اللغة الثانية أولاً، هناك فوائد لكون اللغة الأولى ميسورة التكلفة إلى حد ما على الأقل. يمكن أن تستفيد Validiums من نموذج أمني أقوى إذا تمكن المستخدمون من سحب أموالهم إذا لاحظوا أن بيانات الحالة الجديدة لم تعد متاحة. تصبح المراجحة أكثر كفاءة، خاصة بالنسبة للرموز الأصغر حجمًا، إذا كان الحد الأدنى لحجم النقل المباشر عبر L2 المجدي اقتصاديًا أصغر.

وبالتالي، يبدو من المعقول محاولة إيجاد طريقة لاستخدام ZK-SNARKs للتحقق من الطبقة 1 نفسها.

الخيار 2: SNARK-تحقق من الطبقة 1

يمكن استخدام ZK-EVM من النوع 1 (المكافئ بالكامل لـ Ethereum) للتحقق من تنفيذ EVM لكتلة Ethereum (الطبقة 1). يمكننا كتابة المزيد من كود SNARK للتحقق أيضًا من الجانب المتفق عليه للكتلة. ستكون هذه مشكلة هندسية صعبة: اليوم، تستغرق ZK-EVMs دقائق إلى ساعات للتحقق من كتل Ethereum، وسيتطلب إنشاء البراهين في الوقت الفعلي واحدًا أو أكثر من (i) تحسينات على Ethereum نفسه لإزالة المكونات غير الملائمة لـ SNARK، (ii) ) إما مكاسب كبيرة في الكفاءة من خلال الأجهزة المتخصصة، و(3) تحسينات معمارية مع قدر أكبر من التوازي. ومع ذلك، لا يوجد سبب تكنولوجي أساسي يمنعنا من القيام بذلك ــ وعلى هذا فأنا أتوقع أن يتم إنجازه حتى لو استغرق الأمر سنوات عديدة.

هنا نرى التقاطع مع نموذج العملاء المتعددين: إذا استخدمنا ZK-EVMs للتحقق من الطبقة 1، فما هو ZK-EVM الذي نستخدمه؟

أرى ثلاثة خيارات:

1. ZK-EVM واحد: تخلى عن النموذج متعدد العملاء، واختر ZK-EVM واحد نستخدمه للتحقق من الكتل.
2. ZK-EVM المتعددة المغلقة: الموافقة على مجموعة محددة من ZK-EVMs المتعددة وتكريسها بالإجماع، والحصول على قاعدة بروتوكول طبقة الإجماع التي تنص على أن الكتلة تحتاج إلى أدلة من أكثر من نصف ZK-EVMs في تلك المجموعة حتى تعتبر صالحة .
3. فتح ZK-EVM متعدد: لدى العملاء المختلفين تطبيقات ZK-EVM مختلفة، وينتظر كل عميل دليلًا متوافقًا مع التنفيذ الخاص به قبل قبول الكتلة باعتبارها صالحة.

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

لن يكون تنفيذ (3) صعبًا للغاية: قد يكون لدى الشخص شبكة فرعية p2p لكل نوع من أنواع الإثبات، والعميل الذي يستخدم نوعًا واحدًا من الإثبات سوف يستمع إلى الشبكة الفرعية المقابلة وينتظر حتى يتلقوا دليلاً على أن يتعرف المدقق على أنه صالح.

من المحتمل أن يكون التحديان الرئيسيان في (3) كما يلي:

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

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

يجب معالجة مشكلة كفاءة البيانات من خلال وجود بروتوكول منفصل لتجميع البيانات المتعلقة بالتحقق. بالنسبة للتوقيعات، يمكننا استخدام تجميع BLS ، والذي يدعمه ERC-4337 بالفعل. فئة رئيسية أخرى من البيانات المتعلقة بالتحقق هي ZK-SNARKs المستخدمة للخصوصية. ولحسن الحظ، تميل هذه غالبًا إلى أن يكون لها بروتوكولات تجميع خاصة بها.

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

الاستنتاجات

إن جعل النظام البيئي ZK-EVM مفتوحًا ومتعدد العملاء يعمل بشكل جيد سيستغرق الكثير من العمل. لكن الخبر السار حقًا هو أن الكثير من هذا العمل يحدث أو سيحدث على أي حال:

• لدينا بالفعل العديد من تطبيقات ZK-EVM القوية. هذه التطبيقات ليست من النوع 1 بعد (أي ما يعادل الإيثيريوم بالكامل)، ولكن العديد منها يتحرك بنشاط في هذا الاتجاه.
• قد يتحول العمل على العملاء الخفيفين مثل Helios و Succinct في النهاية إلى تحقق أكثر شمولاً من SNARK لجانب إجماع PoS في سلسلة Ethereum.
• من المرجح أن يبدأ العملاء بتجربة ZK-EVMs لإثبات تنفيذ كتلة Ethereum بأنفسهم، خاصة عندما يكون لدينا عملاء عديمي الجنسية وليس هناك حاجة فنية لإعادة تنفيذ كل كتلة مباشرة للحفاظ على الحالة. من المحتمل أن نحصل على انتقال بطيء وتدريجي من العملاء الذين يتحققون من كتل Ethereum عن طريق إعادة تنفيذها إلى معظم العملاء الذين يتحققون من كتل Ethereum عن طريق التحقق من أدلة SNARK.
• من المرجح أن تبدأ الأنظمة البيئية ERC-4337 وPBS العمل مع تقنيات التجميع مثل BLS وتجميع الإثبات قريبًا جدًا، من أجل توفير تكاليف الغاز. لقد بدأ العمل بالفعل في تجميع BLS.

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

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

وعلى المدى القريب، لا تزال هذه رحلة طويلة. إن ZK-EVMs موجودة هنا، ولكن أن تصبح ZK-EVMs قابلة للحياة حقًا في الطبقة 1 سيتطلب منها أن تصبح من النوع 1، وأن تثبت بسرعة كافية بحيث يمكن أن تحدث في الوقت الفعلي. مع ما يكفي من التوازي، يكون هذا ممكنًا، ولكن سيظل هناك الكثير من العمل للوصول إلى هناك. ستكون تغييرات الإجماع مثل رفع تكلفة الغاز لـ KECCAK وSHA256 وغيرها من عمليات التجميع المسبق لوظيفة التجزئة جزءًا مهمًا من الصورة. ومع ذلك، قد تحدث الخطوات الأولى للانتقال في وقت أقرب مما نتوقع: بمجرد التحول إلى أشجار Verkle والعملاء عديمي الجنسية، يمكن للعملاء البدء تدريجيًا في استخدام ZK-EVMs، ويمكن أن يكون الانتقال إلى عالم "مفتوح متعدد ZK-EVM" البدء في حدوث كل شيء من تلقاء نفسه.

تنصل:

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