فيتاليك: ماذا سيحدث إذا تم تجميع ZK-EVM في Ethereum L1؟

النص الأصلي: https://notes.ethereum.org/@vbuterin/enshrined_zk_evm
المترجم: مجتمع Denlink ^[1] فريق الترجمة

بروتوكول Layer2 EVM المبني على Ethereum، بما في ذلك Optimistic Rollups وZK Rollups، تعتمد جميعها على التحقق من EVM. ومع ذلك، فإن هذا يتطلب منهم الثقة في قاعدة تعليمات برمجية كبيرة، وإذا كانت هناك نقاط ضعف في قاعدة التعليمات البرمجية، فإن هذه الأجهزة الافتراضية معرضة لخطر الاختراق. بالإضافة إلى ذلك، حتى ZK-EVM الذي تم تصميمه ليكون مكافئًا تمامًا لـ L1 EVM سيتطلب شكلاً من أشكال آلية الإدارة لتكرار التغييرات من L1 EVM إلى تطبيق EVM الخاص به.

هذا الوضع ليس مثاليًا لأن هذه المشاريع تكرر الوظائف الموجودة بالفعل في بروتوكول Ethereum، كما أن حوكمة Ethereum مسؤولة بالفعل عن ترقية الأخطاء وإصلاحها. المكان: تقوم ZK-EVM بشكل أساسي بمهمة التحقق من صحة كتل Layer1 Ethereum! بالإضافة إلى ذلك، نتوقع خلال السنوات القليلة المقبلة أن يصبح العملاء الخفيفون ^[2] أكثر قوة وقريبًا يقومون بالمصادقة الكاملة على عمليات تنفيذ L1 EVM باستخدام ZK-SNARKs . عند هذه النقطة، ستحتوي شبكة الإيثيريوم على ZK-EVM مدمج بشكل فعال. لذلك، يطرح سؤال: لماذا لا يتم استخدام ZK-EVM أصلاً في عملية التجميع؟

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

ما هي الميزات الرئيسية التي تريد الحصول عليها من خلال تغليف ZK-EVM؟

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

التوافق مع فلسفة تعدد عملاء الإيثريوم^[3]، مما يعني أننا نأمل في تجنب استخدام نظام تصديق واحد وبدلاً من ذلك السماح للعملاء المختلفين باستخدام أنظمة تصديق مختلفة. وهذا بدوره يعني بعض الأشياء:

• متطلبات توفر البيانات: بالنسبة لأي تنفيذ EVM من خلال ZK-EVM المغلف، نتوقع ضمان توفر البيانات الأساسية^[4]، وبهذه الطريقة تثبت الاستخدام يمكن لنظام إثبات مختلف إعادة التصديق على عمليات التنفيذ، ويمكن للعملاء الذين يعتمدون على نظام الإثبات هذا التحقق من الأدلة التي تم إنشاؤها حديثًا.

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

قابلية التدقيق: إذا تم إثبات أي تنفيذ، نريد أن تكون البيانات الأساسية متاحة لـ يمكن للمستخدم والمطورين التحقق. في الواقع، يضيف هذا سببًا آخر لأهمية متطلبات توفر البيانات.

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

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

مفتوحة ومغلقةأنظمة متعددة العملاء

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

الخيار الآخر هو نظام مغلق متعدد العملاء، حيث تكون مجموعة ثابتة من أنظمة التصديق معروفة ضمن البروتوكول. على سبيل المثال، قد نقرر استخدام ثلاث وحدات ZK-EVM: PSE ZK-EVM^[5]، وPolygon ZK-EVM^[6]، وKakarot ^[7] . تتطلب الكتلة إثباتات من اثنين من هؤلاء الثلاثة حتى تعتبر صالحة. وهذا أفضل من نظام إثبات واحد، ولكنه يجعل النظام أقل قابلية للتكيف لأنه يجب على المستخدمين الحفاظ على أدوات التحقق من صحة كل نظام إثبات، مما له بالضرورة آثار على أشياء مثل عملية الحوكمة السياسية التي تتضمن أنظمة إثبات جديدة.

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

ما هي الميزات الرئيسية التي نريد أن يتمتع بها تطبيق ZK-EVM؟

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

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

كيف تبدو وظيفة ZK-EVM بالضبط في البروتوكول؟

على غرار معاملة EIP-4844 كبيرة الحجم^[8]، نقدم معاملة جديدة تحتوي على مطالبات ZK-EVM النوع: < /p>

على غرار EIP-4844، سيكون الكائن الذي تم نشره في تجمع الذاكرة نسخة معدلة من المعاملة:

يمكن تحويل الأخير إلى الأول، ولكن ليس العكس. لقد قمنا أيضًا بتوسيع كائن السيارة الجانبي (المقدم في EIP-4844^[9]) ليشمل قائمة من البراهين للمطالبات المقدمة في الكتلة.

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

في طبقة الإجماع، أضفنا قاعدة تحقق: لا يمكن للعميل قبول الكتلة إلا بعد رؤية دليل صالح لكل مطالبة في قطعة الكتلة. يجب أن يكون الدليل عبارة عن ZK-SNARK يثبت أن تسلسل transaction_and_witness_blobs هو تسلسل لزوج (Block, Witness)، وأن الكتلة يتم تنفيذها على pre_state_root باستخدام Witness (i) صالح، و(ii) يتم إخراج post_state_root الصحيح. من المحتمل أن يختار العميل انتظار M-of-N لأنواع متعددة من البراهين.

النقطة الفلسفية التي يجب ذكرها هنا هي أنه يمكن النظر إلى تنفيذ الكتلة بحد ذاته على أنه مطلوب ببساطة مع ZKEVMClaimTransaction One من الثلاثيات (σ_pre,σ_post,Proof) التي تم التحقق منها مع الثلاثيات المتوفرة في الكائن. لذلك، يمكن لتطبيقات ZK-EVM الخاصة بالمستخدمين أن تحل محل عملاء التنفيذ الخاصين بهم؛ وسيظل عملاء التنفيذ مستخدمين بواسطة (i) المُثبتين ومنشئي الكتل، و(ii) العقد التي تهتم بفهرسة الاستخدام المحلي وتخزين البيانات.

التحقق والتوبيخ

لنفترض أن هناك مربعين من الأثير العملاء، أحدهما يستخدم PSE ZK-EVM والآخر يستخدم Polygon ZK-EVM. افترض أن كلا التطبيقين قد تطورا الآن إلى الحد الذي يمكنهم من خلاله إثبات تنفيذ كتلة إيثريوم في 5 ثوانٍ، وأنه يوجد لكل نظام إثبات عدد كافٍ من المتطوعين المستقلين الذين يقومون بتشغيل الجهاز لإنشاء البراهين.

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

لنفترض أن شخصًا ما أطلق ZKEvmClaimNetworkTransaction، ولكنه أطلق فقط نسخة تجريبية من PSE ZK-EVM. شهدت عقد إثبات Polygon ZK-EVM حدوث ذلك، وقامت بحساب الكائن وإعادة نشره باستخدام دليل Polygon ZK-EVM.

يؤدي هذا إلى زيادة إجمالي الحد الأقصى للتأخير بين أقرب عقدة صادقة لقبول كتلة وأحدث عقدة صادقة لقبول نفس الكتلة الأخيرة، من δ إلى 2δ+T_إثبات (افترض هنا T< sub >إثبات <5s).

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

الامتداد: دعم EVMs تقريبًا

الهدف المثالي لوظيفة ZK-EVM هو< قوي>دعم أجهزة EVM تقريبًا: إنه جهاز EVM مع بعض الميزات الإضافية. يمكن أن يشمل ذلك مترجمات مسبقة جديدة، أو أكواد تشغيل جديدة، أو خيارات لكتابة العقود باستخدام EVM أو جهاز افتراضي مختلف تمامًا (كما هو الحال مع Arbitrum Stylus^[11])، أو حتى وجود مزامنة متعددة لـ EVMs المتوازية للتقاطع -تواصل.

يمكن دعم بعض التعديلات بطريقة بسيطة: يمكننا تحديد لغة تسمح لـ ZKEVMClaimTransaction بتمرير الوصف الكامل للتعديل قاعدة EVM . يمكن تطبيق ذلك على:

جدول تكلفة الغاز المخصص (لا يُسمح للمستخدم بتخفيض رسوم الغاز، ولكن يمكنه زيادتها)

تعطيل رموز تشغيل محددة

تعيين رقم الكتلة (وهذا يعني قواعد مختلفة اعتمادًا على الانقسام الكلي)

قم بتعيين علامة تقوم بتنشيط مجموعة كاملة من تغييرات EVM خصيصًا للمستوى الثاني ولكن ليس للمستوى الأول، أو التغييرات البسيطة الأخرى

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

سيتم تعديل تنفيذ EVM. ستتم تهيئة مصفوفة المدخلات لتكون فارغة. عندما يتم استدعاء العنوان الموجود في used_precompile_addresses للمرة التاسعة، نضيف InputsRecord(callee_address,gas, input_calldata) إلى inputs ونستبدل < تم تعيين الكود >RETURNDATA على المخرجات[i]. أخيرًا، نتحقق من أن used_precompile_addresses قد تم تسميته بـ len(outputs) إجمالاً، وأن inputs_commitments متوافقة مع inputs نتيجة النقطة التي تنتجها تسلسل SSZ تتطابق مع الوعد. الغرض من الكشف عن inputs_commitments هو تسهيل SNARKs الخارجية لإثبات العلاقة بين المدخلات والمخرجات.

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

قد تكون الميزة المفيدة الأخرى هي السماح "بالمعاملات المميزة" التي يمكن استدعاؤها من أي حساب مرسل. يمكن تشغيل هذه المعاملات بين معاملتين أخريين، أو عند استدعاء المترجم المسبق في معاملة أخرى (ربما مميزة أيضًا). يمكن استخدام هذا للسماح للآليات غير التابعة لـ EVM بمعاودة الاتصال بـ EVM.

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

عن طريق تعيين used_precompile_addresses لتضمين قائمة عناوين الحساب العادية مع علامات معينة في الحالة وإنشاء دليل SNARK لإثبات بنائه الصحيح، يمكنك دعم ميزات مثل أسلوب Arbitrum Stylus، حيث يمكن للعقد كتابة التعليمات البرمجية الخاصة به في EVM أو WASM (أو جهاز افتراضي آخر). يمكن استخدام المعاملات المميزة للسماح لحسابات WASM بمعاودة الاتصال بـ EVM.

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

النوع 4 ZK-EVM[13] يمكن تشغيله من خلال تطبيقات متعددة: أحدهما سيكون Solidity أو مستوى آخر أعلى. يتم تحويله مباشرة إلى تطبيق VM صديق لـ SNARK، ويقوم آخر بتجميعه في كود EVM وتنفيذه في ZK-EVM المدمج. لا يمكن تشغيل التنفيذ الثاني (الأبطأ حتمًا) إلا في حالة قيام المُثبت الخاطئ بإرسال تأكيد معاملة ضعيف، وجمع المكافأة عند تقديم معاملة تمت معالجتها بشكل مختلف.

يمكن تنفيذ جهاز افتراضي غير متزامن خالص عن طريق جعل جميع المكالمات ترجع صفرًا وتعيين المكالمات للمعاملات المميزة المضافة إلى نهاية الكتلة.

الامتداد: دعم الأمثال ذات الحالة

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

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

إذا أردنا أن نجعل وظيفة ZK-EVM ذات حالة، فلدينا خياران:

يتطلب أن يكون σpre فارغًا، أو قائمة متاحة لبيانات القيمة والمفتاح المعلن عنها مسبقًا، أو تنفيذ سابق لـ σpost قائمة الفرعية>

إلى (σpre, σpost, إثبات ) يضيف الصف وعدًا نقطيًا مع الإيصال الذي تم إنشاؤه بواسطة الكتلة R. يمكن الإشارة إلى أي التزام ثنائي كبير الحجم تم إنشاؤه أو استخدامه مسبقًا في ZKEVMClaimTransaction، بما في ذلك ممثلو الكتل والشهود والإيصالات وحتى معاملات EIP-4844 الثنائية العادية، ربما مع بعض القيود الزمنية، التي يمكن الوصول إليها أثناء تنفيذها ( قد يكون ذلك من خلال سلسلة من التعليمات: "أدخل البايتات N...N+k-1 من الالتزام i في الموضع j من الكتلة + بيانات الشاهد")

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

وسيطات الأنظمة المغلقة متعددة الإثبات والبيانات خارج السلسلة

مغلقة أنظمة الإثبات المتعددة، حيث يكون لعدد ثابت من أنظمة الإثبات بنية M-of-N، تتجنب العديد من التعقيدات المذكورة أعلاه. لا تحتاج الأنظمة المغلقة متعددة الشهادات على وجه الخصوص إلى القلق بشأن ضمان وجود البيانات على السلسلة. بالإضافة إلى ذلك، سيسمح النظام المغلق متعدد المثبتات بتنفيذ إثباتات ZK-EVM خارج السلسلة، مما يجعله متوافقًا مع حل EVM Plasma[14].

ومع ذلك، تزيد الأنظمة المغلقة متعددة المصدقين من تعقيد الإدارة وتزيل إمكانية التدقيق، وهي مقايضات. التكلفة العالية لهذه الفوائد .

إذا كانت ZK-EVM تعمل كوظيفة بروتوكول، فما هو الدور المستمر لمشروع Layer2؟

سيتم التعامل مع وظيفة التحقق من EVM التي ينفذها فريق Layer2 حاليًا بواسطة البروتوكول، ولكن سيظل مشروع Layer2 مسؤولاً عن العديد من الوظائف المهمة :< /p>

التحقق المسبق السريع: قد يؤدي الانتهاء من فتحة واحدة إلى إبطاء فتحات Layer1، والتي يوفرها مشروع Layer2 بالفعل مستخدميها مع "التأكيد المسبق" المدعوم بأمان الطبقة الثانية، يكون زمن الوصول أقل بكثير من فتحة واحدة. سيستمر التعامل مع هذه الخدمة فقط بواسطة Layer2.

استراتيجيات التخفيف من آثار MEV: قد يتضمن ذلك مجموعات ذاكرة مشفرة، واختيار تسلسل قائم على السمعة، وميزات أخرى لا يرغب Layer1 في تنفيذها .

امتدادات لـ EVM : يمكن أن تتضمن مشاريع Layer2 امتدادات مهمة لـ EVM، مما يوفر قيمة كبيرة لمستخدميها. يتضمن ذلك EVM على حد سواء وأساليب متباينة مثل دعم WASM الخاص بـ Arbitrum Stylus ولغة القاهرة الصديقة لـ SNARK (https://www.cairo-lang.org/).

الراحة للمستخدمين والمطورين: يلتزم فريق Layer2 بجذب المستخدمين والمشاريع إلى نظامه البيئي وجعلهم يشعرون بالترحيب. مرحبًا ؛ ويتم تعويضهم عن طريق التقاط رسوم المركبات الكهربائية المتوسطة (MEV) ورسوم الازدحام داخل شبكتهم. وسوف تستمر هذه العلاقة في الوجود.