في العام الماضي ، حققت Ethereum بعض الإنجازات الرئيسية على طريق التطوير التكنولوجي للشبكة. قدم EIP-4844 (المعروفة أيضًا بـ Dencun) مفاهيم الـ blobs والـ proto-danksharding، مما جعل تخزين البيانات يكلف نقلة واحدة أقل لطبقة 2 مما أدى إلى تخفيض كبير في رسوم المعاملات. في الوقت نفسه ، أصبحت الطبقات 2 (بشكل رئيسي من نوع optimistic) متكاملة ومستخدمة بشكل أوسع في التطبيقات ، مما يجعل من الممكن تنفيذ المعاملات بتكلفة أقل من سنت واحد ، وتحسين البنية التحتية الأساسية لـ Ethereum.
ومع ذلك ، فإنه كما هو معروف بالرسومات الغازية ، لا تزال هناك ازدحام كبير على Ethereum ، ومع تزايد استخدام البلوكشينات في العالم الحقيقي ، سيتنافس المزيد والمزيد من التطبيقات اللامركزية للحصول على مساحة البلوك والحوسبة.
لا يلزم أن يكون شخصًا هندسيًا أو عمليات تشفير لمعرفة أن هذا ليس مستدامًا. لقد شهدنا ما يحدث عندما يصبح Ethereum مزدحمًا للغاية. في بعض اللحظات المتزايدة بشكل خاص ، دفع المستخدمون أكثر من 2 ETH فقط لإتمام معاملة ، وفشلت بعض تلك المعاملات لاحقًا.
في عالم مثالي ، سننقل أكبر قدر ممكن من الحوسبة من السلسلة ، وسنكون قادرين على نشر دليل واضح وقابل للتحقق يضمن أن البيانات صحيحة وفي المكان الصحيح.
تجعل الأدلة الصفرية هذا ممكنًا ، ولكن من الصعب على البلوكشينات التحقق من المعاملات مع وجود العديد من الاحتمالات المحتملة في الـ EVM ، ويمكن أن يصبح ذلك سريعاً باهظاً التكلفة على هذا الطريق. يجب على zk-rollups دفع تكاليف الأجهزة المتخصصة التي تنشئ دليل ZK من خلال prover ، ومن ثم يجب بشكل عام تحويل ذلك إلى نوع دليل يمكن لـ Ethereum فهمه.
وباختصار ، فإن التحقق من تدوير المعاملات مجددًا بالنسبة إلى zk-rollups متعب ويكلف الكثير. بالنسبة للشركات الصغيرة وحتى الوسطى التي ترغب في إجراء بعض نشاطها على السلسلة والحفاظ على سرية المعاملات ، فإن zk-rollups هي الطريقة المثلى لكن تكلفة التحقق من الأدلة يمكن أن تكون مصاريف جزافية.
يُظهر نظام rollup مصلحته الخاصة وحققنا فرصة مع مزودي Rollup-as-a-service (RaaS) ، لأنهم يعتقدون في النهج القابل للتوسيع نحو البلوكشينات ويميلون على العموم لخدمة المشروعات الصغيرة والمتوسطة التي لا تستطيع تحمل تكاليف التحقق. بالنسبة لهؤلاء ، فإن فكرة إرسال الأدلة إلى سلسلة مستقلة ثم إرجاع التحقق بالأدلة إلى Ethereum يبدو منطقيًا. مثلما رأينا الآن مزودي RaaS يتبنى تحقق الأدلة القابل للتوسيع بذراعين مفتوحة.
يُظهر الـ L2 الكبيرة حججًا اثنين رئيسيان ضد هذا النهج: أولاً ، يعتقدون أن تحري الأدلة على طبقة مختلفة يقلل من أمان L2. في الواقع ، بعض هذه الطبقات 2 بالفعل تحقق الأدلة بعيدًا عن السلسلة. لكن لا يتم الإعلان عن هذا علنًا.
يَقُرون بشأن ضرورة التجميع بكتلة كبيرة من الأدلة معًا، وبالتالي إنشاء “دليل الأدلة”. عند القيام بذلك، يمكن للطبقات 2 الكبيرة توزيع التكلفة على عدد أكبر من المعاملات. لكنهم لا يبدون قلقين كثيرًا بأنه باستخدام هذا النهج من الممكن أن يستغرق الأمر بضع ساعات لتجميع مئات الأدلة، بتكلفة أعلى ربما.
التجميع منطقي لحالات الاستخدام كثيرة ، لكن ليس بالضرورة لتطبيق تريد أن تقوم به بسرعة وتحصل على التحقق في نفس الوقت.
في النهاية ، لا يزال عليك أن تثق في الـ L2 الذي تتعامل معه.
ببعض الطرق ، الـ EVM محصورة في 2017. وبينما كان فريقنا يستمر في البحث في مجال ZK وعلاقة Ethereum به ، اكتشفنا أن Ethereum لديها في الواقع بعض التوافق مع المنحنيات البيضاوية الصفرية باستخدام تحضير مسبق ، مما يجعل من الأكثر كفاءة للتعامل مع الحوسبة المشمولة في التحقق من الأدلة. ولكن يدعم الشبكة حاليًا فقط ثلاث عمليات رياضية على منحنى واحد.
ماذا يعني هذا للمستخدمين؟ نظرًا لأن بعض الـzk-SNARKs لا يمكن التحقق منها ، يتطلب من الأدلة أن تُعبأ في شكل أكثر ودودية (باستخدام الدليل bn128) ، مما يؤدي إلى أقل كفاءة ، ومزيد من الفرص للخطأ ، وربما تكاليف أعلى. في الواقع ، يمكن من الناحية الفنية لـ Ethereum اعتماد تحضيرات متقدمة أكثر مع مرور الوقت ، ولكن قد يستغرق تنفيذها سنوات.
لماذا ذلك؟ نقص الطلب؟ هل هو في الواقع غير قابل للتطبيق لتنفيذ هذه التحضيرات على Ethereum؟ وحتى لو كانت المجتمع قادرة على القيام بذلك ، هل من غير الفعال تحسين بأن يتم حسابها بتحضيرات جديدة على الـ EVM؟ ليس هذا واضحًا. ولكن ما هو واضح هو أن الـ EVM يحتاج إلى إعادة هيكلة، وأن تحقق الأدلة الصفرية على السلسلة لا يزال مكلفًا جدًا لحالات الاستخدام العادية.
في Horizen Labs ، نتعامل مع هذا الأمر بطريقتين: من خلال تقديم تحقق الأدلة الفردية في شكل zkVerify، وبناء سلسلة متوافقة بشكل كامل مع EVM مع دعم لأحدث التحضيرات الصفرية. على سبيل المثال ، يتم بناء Horizen 2.0 على Substrate، مما يسمح بالترقيات التي تتم بدون تحويلات وتُطبق بشكل تلقائي بعد تصويت المجتمع. لا يتعين أي عمل على الجانب الخادم ، ولا يتطلب التحديث الصعب.
قد تفضل بعض الفرق البقاء ضمن بيئة مخصصة مثل Horizen 2.0 ، بمجتمعها الوثيق وتأثيرات شبكتها الخاصة. سيختار آخرون الطريقة RaaS لبناء تدوير مخصص خاص بهم، وستستفيد من توفير التكاليف من تحقق الأدلة بعيدًا عن السلسلة هنا أيضًا. هناك طرق متعددة لتطوير الـ EVM مع ZK، ولكننا نعتقد أنه يجب أن يحدث ذلك قبل موجة القبول القادمة.
