حاضر ومستقبل الطبقة الثانية التراكمية

نظرة عامة على Layer 2 Roll-ups

على مدار السنوات القليلة الماضية ، برزت حلول تراكم الطبقة 2 (L2) في المقدمة مع نمو النشاط على شبكة Ethereum. النشاط والتفاعل مع الرموز غير القابلة للاستبدال (NFTS) والتمويل اللامركزي (الصدمة) تسبب في زيادة نشاط blockchain للطبقة 1 (L1).

في المقابل ، زاد الطلب على blockspace ، الذي يمثله تكاليف الغاز. وارتفع وقت إنهاء المعاملة بسبب زيادة حمل الشبكة.

في حين أن دمج الاثيريوم وضع الأساس لتحسينات رسوم الغاز المستقبلية ؛ لم يخفض بشكل مباشر رسوم تحويل الغاز.

في العام بين صيف 2020 وذروة الطلب في صيف 2021 ، زادت تكلفة الغاز في جوي على شبكة Ethereum بنسبة تصل إلى 1300٪. دفعت الحاجة إلى إجراء معاملات سريعة وبأسعار معقولة إلى إنشاء شكلين أساسيين من التراكمية: التفاؤل والمعرفة الصفرية (ZK).

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

يتمثل الاختلاف الكبير بين الاثنين في أن التجميعات المتفائلة تستخدم إثباتات الاحتيال ، في حين تعتمد ZK-rollups على أدلة المعرفة الصفرية للتحقق من التغييرات التي تطرأ على السلسلة الرئيسية.

التفاؤل و ZK-rollups: أدلة الاحتيال مقابل إثباتات الصلاحية

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

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

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

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

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

للحصول على حلول تراكمية متفائلة ، مثل Arbitrum و Optimism ، يمكن أن تستمر فترة الانتظار هذه لمدة تصل إلى أسبوع. بدلاً من ذلك ، تتمتع ZK-rollups بميزة عكس حالة L2 الصحيحة دائمًا. عيبهم هو أن البراهين مطلوبة لجميع انتقالات الحالة ، وليس فقط عندما يتم الطعن فيها ، مما يحد من قابلية التوسع. يتفاقم هذا بسبب الطبيعة المعقدة والمراحل المبكرة للتكنولوجيا.

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

لهذه الأسباب ، سنركز على الوضع الحالي لمساحة ZK-rollup ، وأحدث الابتكارات وما ينتظرنا في المستقبل.

مساحة ZK-Rollup

كما ناقشنا ، فإن ZK-rollups هي في الغالب في النقطة المحورية مع لاعبين مثل zkSync و Starknet و Polygon zkEVM و Scroll جميعهم يجمعون كميات كبيرة من رأس المال لتطوير حلولهم على الرغم من إطلاق StarkNet فقط على mainnet (إجمالي 780 مليون دولار) .

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

خوارزمية الإثبات هي وسيلة لتوليد إثبات الصلاحية ، والذي يمكن أن يكون إما STARK أو SNARK.

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

يمكنك قراءة المزيد عن الاختلافات الفنية هنا. تتمتع STARKs بميزة تقديم المزيد من قابلية التوسع والأمان والشفافية مقارنةً بـ SNARKs.

لكن العيب في STARKS هو حجم إثبات أكبر ، والذي يستغرق وقتًا أطول للتحقق ، وأن SNARKs تستخدم نسبيًا 24 ٪ فقط من الغاز. هنا لكل من SNARKS و STARKS لدينا مفاضلة بين السرعة والتكلفة مقابل قابلية التوسع والأمان والشفافية.

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

عقبات للتغلب عليها

كما ناقشنا ، لا تزال ZK-rollup قيد التطوير وهناك العديد من التحديات التي يجب التغلب عليها قبل أن يتمكن مستخدمو blockchain من جني فوائدهم الكاملة.

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

على سبيل المثال ، تتطلع StarkNet إلى حل هذه المشكلة باستخدام برنامج Warp ، وهو برنامج Solidity to Cairo (لغة StarkNet's ZKP) الذي يتطلع إلى تحويل Solidity تلقائيًا إلى Cairo. يؤدي استخدام Warp إلى إزالة حاجة المطورين إلى إعادة كتابة التعليمات البرمجية الخاصة بهم في القاهرة ، مما يجعلها عملية أكثر سلاسة.

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

أخيرًا ، في حين أن التراكمية (المتفائلة والمعرفة الصفرية) لها فوائد تحسين السرعة والتكلفة ، فإنها تميل إلى أن تكون على حساب اللامركزية.

ويرجع ذلك إلى الحاجة المتأصلة إلى أجهزة التسلسل ، والجهات الفاعلة التي تجمع المعاملات وتلتزم بإثباتات على L1.

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

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

خطط اللامركزية

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

يخطط كل من StarkWare و zkSync لإطلاق رمز مميز ويمكن أن يستخدم Polygon MATIC لدعم مبادرة zkEVM من Polygon. تعد هندسة الرموز على ZK-rollup مساحة وليدة أكثر من تقنية التجميع المتفائلة وإيجاد نموذج فعال ومستدام يمكن أن يميز ويعزز التبني.

المستقبل

لا تزال zkEVMs في مراحلها الأولى والسباق على وشك الانطلاق على mainnet. تتمتع StarkNet بميزة المحرك الأول ولكنها لا تزال تواجه تحديات فيما يتعلق بدعم ميزات Solidity بسبب استخدام القاهرة ، مما يترك مجالًا للمنافسين لإجراء تحسينات.

ستجذب المشاريع القادرة على حشد قواعد مستخدمين كبيرة مطوري dapp ، مما يؤدي بدوره إلى جلب المزيد من dApps إلى نظامهم الأساسي وزيادة مجموعة الميزات. zkEVM من ConsenSys تنتقل حاليًا إلى testnet وتركز بشكل خاص على مطوري dapp لهذا السبب ، وتستفيد من أدوات مثل MetaMask و Infura و Truffle حتى يتمكنوا من نشر التطبيقات وإدارتها كما لو كانوا يستخدمون Ethereum مباشرةً.

وبينما ناقشنا اللاعبين الحاليين في سوق zkEVM ، لا تزال حلول التجميع السائدة الأخرى مثل Polygon و Optimism و Arbitrum تحظى بحصة سوقية كبيرة.

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

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