*إعادة توجيه العنوان الأصلي 'كيف تساعد ZKP و ZK-Rollups في حل مشكلة التوسع: استعراض لسلسلة الكتل zkSync'

في هذا المقال، سنشرح ما هي تقنية الدليل على عدم المعرفة الصفرية ونتحدث عن سلسلة كتل شهيرة - zkSync: كيف تعمل المعاملات في zkSync والاختلافات الرئيسية عن آلة العقد الافتراضي (EVM) في إيثريوم. كما سنناقش مزايا وعيوب هذه السلسلة القادرة على تحقيق مستقبل واعد.

ZkSync هو بلوكشين من المستوى الثاني (الطبقة 2 - L2) لإيثيريوم، مصمم لمعالجة مشاكل الرسوم الباهظة والطاقة المحدودة (عمليات التحويل في الثانية - TPS) على شبكة إيثيريوم. تعتمد هذه المنصة تقنية ZK-Rollup، التي تستخدم دلائل الصفر المعرفة (ZKP) لدمج عدة عمليات تحويل خارج الشبكة الرئيسية (L1). يتم إرسال الدلائل التشفيرية فقط لصحة العمليات وبياناتها المضغوطة إلى L1، مما يعزز كفاءة العملية ويقلل التكاليف بشكل كبير.

تم تطويرها بواسطة مختبرات المسائل, تم الإعلان عن zkSync بوصفه منتجًا مفتوح المصدر بالكامل (مفتوح المصدر بنسبة 100٪)، يُدار من قبل المجتمع. وفقًا لـتصنيف العملات الرقمية، لقد لفت المشروع بالفعل الانتباه، حيث جمع استثمارات بقيمة 458 مليون دولار. على المدى الطويل، تهدف ماتر لابز إلى خلق بيئة نظام بيئي شاملة. حاليًا، هناك عملتان في الشبكة: zkSync Lite، التي تعالج المدفوعات بالإيثريوم ورموز ERC20، و zkSync Era، الداعمة للعقود الذكية الكاملة. تشمل الخطط المستقبلية إطلاق نظام هايبرتشين (L3)، مما يضمن أمانًا عاليًا. هدف ماتر لابز هو توسيع التكنولوجيا إلى مستوى يجذب المستخدمين القادمين مليارا على البلوكتشين.

خلفية

ZkSync يمثل نهجا جديدا لحل مشكلة التوسع المعروفة باسم الثلاثية بلوكشين. يسعى هذا المشروع، مثل حلول الطبقة 2 الأخرى (L2)، إلى العثور على توازن بين الأمان والقابلية للتوسع واللامركزية في شبكات البلوكتشين.

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

يتركز إيثريوم على الأمان واللامركزية، مؤكدًا على وضعه كبروتوكول ند لند مع وجود عقد موزعة حول العالم. للمعلومات الأحدث حول توزيع العقد، يرجى الرجوع إلى مراقبة العقد.

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

الطبقة 2

كانت المهمة الرئيسية لزيادة TPS لشبكة Ethereum دون زيادة الحمل على العقد الذكور هي إدخالتجزئةبالاقتران مع الانتقال إلى توافق PoS (برهان الحصة). تضمن ذلك تقسيم المحققين إلى مجموعات فرعية لمعالجة أقسام منفصلة من الشبكة، مما يقلل من الحمل الكلي ويزيد من الإنتاجية. ومع ذلك، ركزت المجتمع على حلول الطبقة 2، مع النظر في تطورها السريع.

بالإضافة إلى فكرة تنفيذ Sharding في Ethereum، ظهرت حلول توسيع القدرات الأخرى، مثل:

• قنوات الدفع والحالة
• السلاسل الجانبية
• بلازما
• تكديس متفائل

بالإضافة إلى التقنيات المعتمدة على أدلة الصفر المعرفة (ZKP)، بما في ذلك:

• Validium
• zkRollup
• اختيار

يمكن العثور على معلومات أكثر تفصيلاًهنا.

على الرغم من أن تقنين الشارد مازال قيد التطوير، إلا أن الفork الصلب لـ Dencun مخطط له في بداية عام 2024، الذي سينفذاحترافي-Danksharding. تهدف هذه الخطوة الوسيطة إلى تحسين حلول الطبقة 2، مما يجعل تخزين البيانات على L1 أكثر اقتصادية. وبالتالي، يعد Proto-Danksharding بتقليل تكاليف المعاملات على L2، كخطوة نحو حل شاردينج كامل.

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

في هذا المقال,معايير رئيسية لتقييم البروتوكولات المستخدمة في الحلول من الطبقة 2 مقترحة. تشمل:

• أمان,
• الأداء والكفاءة الاقتصادية،
• سهولة الاستخدام،
• جوانب إضافية مثل دعم العقود الذكية وتوافق بايت كود EVM وخيارات الخصوصية.

!مهم! تمت كتابة المقال بواسطة Matter Labs وبرأيي تم "تمديد" بعض الأمور لصالح zkRollup (نظرًا لوجود صراع مصلحة واضح)، ولكن هذا ليس مهمًا جدًا، الأمر الرئيسي هو رؤية الفروقات الموجودة بين بروتوكولات الطبقة 2.

سأقدم أدناه جدولًا، وهنا سأصف بإيجاز محتوياته.

الأمان

• يُفترَض أنّ الحياد أو "القابلية" للطبقة 2. يُفترَض أنّ بعض المشاركين سيكونون دائمًا على السلسلة في مستوى الطبقة 1 للرد على حالات الاحتيال المحتملة للحفاظ على وظائف الطبقة 2. إمّا بأن يكونوا مراقبين يراهنون مبلغًا معينًا من الأموال (مسمّى "مُربَوط" في الجدول) على L1، أو أطراف ثالثة تضمن أمان البروتوكول مقابل مكافأة. كما هو مبيّن في الجدول، الحلول التي تستخدم ZKP (Validium و zkRollup) ليس لديها هذه الضرورة.
• مشكلة الخروج الجماعي. مشكلة تنشأ إذا كان من الضروري، لأسباب أمنية، بدء سحب الأموال من قبل جميع المستخدمين من L2 إلى L1. كما هو موضح في الجدول، هذه المشكلة موجودة فقط مع بروتوكول Plasma، ويمكن قراءة المزيد حولههنا.
• العهد. السؤال حول ما إذا كان بإمكان محققي L2 حظر أو استولاء مؤقت على أموال المستخدمين.
• الضعف الاقتصادي. يشمل الهجمات المختلفة على المحققين في الطبقة L2، بما في ذلك رشوة المُنقبين في الطبقة L1، وإنشاء DAOs 'الظلية'، وهجمات أخرى تعتمد اقتصادياً.
• علم التشفير. الفرق بين المبادئ التشفيرية القياسية والجديدة. المبادئ القياسية تم دراستها بشكل أكبر وقد تكون معرضة للضعف، بينما المبادئ الجديدة (مثل SNARK و STARK) توفر موثوقية أكبر ولكن تتطلب معرفة وتدقيقات إضافية من قبل المطورين.

الأداء والاقتصاد

مع الأداء، يكون الأمر مباشرًا. يُشير TPS (المعاملات في الثانية) إلى إنتاجية الشبكة، وفي سياق التوسيع، هو المعلم الأكثر أهمية.

الجوانب الاقتصادية:

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

سهولة الاستخدام

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

جوانب أخرى

• العقود الذكية: النظر في ما إذا كانت الحلول L2 تدعم العقود الذكية القابلة للبرمجة بالكامل، أو مجرد مجموعة محدودة من الوظائف من خلال الجمل الفعلية.
• التوافق مع بيانات التعليمات البرمجية التنفيذية لـ EVM: يقيم إمكانية نقل عقود ذكية موجودة بتعليمات برمجية تنفيذية لـ Ethereum EVM إلى L2 دون تغييرات كبيرة.
• الدعم المدمج للخصوصية: النظر في كفاءة حماية الخصوصية في حلول L2، خاصة في سياق توفر وكفاءة تكلفة المعاملات السرية.

أدناه جدول مقارن للحلول الرئيسية المعتمدة على ZKP:

للحصول على فهم أكثر تفصيلاً للدلائل بدون معرفة (ZKP)، أوصي بالرجوع إلى هذا المقال في حديقتنا blockchain-wiki, تم إنشاؤه من قبل المطورين للمطورين مع حبهم للأدلة والغوص العميق في التفاصيل.

الدورة الحياة للمعاملة في zkSync

يمكن تمثيل عملية ZK-Rollups على مستوى عالٍ كما يلي:

1. تشكيل رول اب: تعبئة الصفقات في رول اب.
2. انشاء ZKP: يتم تشكيل دليل الصفر المعرفة.
3. التحقق في إيثريوم: يتم إرسال الدليل للتحقق إلى عقد ذكي في إيثريوم.

في سياق هندسة zkSync، يبدو العملية كما يلي:

1. مجموعة من الكتل الداخلية: يقوم محققو zkSync بجمع الكتل الداخلية من المعاملات كل بضع ثوانٍ.
2. تشكيل حزمة الكتل: كل 30-90 ثانية، يتم إنشاء حزمة من الكتل من الكتل الداخلية.
3. الالتزام بحالة سلسلة الكتل: يسجل المحققون الحالة الحالية لسلسلة الكتل وينقلون البيانات المعدلة إلى L1 كبيانات الاتصال لاستعادة محتملة.
4. حساب وإرسال SNARK: يقوم المحققون بحساب SNARK (ZKP) للحزمة وإرسالها للتحقق إلى عقد ذكي على شبكة Ethereum. بعد التحقق، يصبح حالة الشبكة الجديدة نهائية.

يقوم المحققون في ZK-Rollups بأداء دور مهم، حيث يقومون بتعبئة المعاملات في الكتل وإنشاء الأدلة بدون معرفة (Zero-Knowledge Proofs) لها. ميزة النظام هي أن المحققين لا يمكنهم بشكل فعلي سرقة الأموال. أكبر ضرر محتمل يمكن أن يتسببوا فيه هو توقف مؤقت للشبكة.

ملاحظة: في عصر zkSync، يقوم مشغلون بدور الفاحصين.

يسلط مطورو zkSync الضوء على الضمانات التالية لهندستهم:

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

تتجاوز المعاملات في عصر zkSync عدة حالات رئيسية، مختلفة عن تأكيدات Rollup المعتادة في L1:

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

بالإضافة إلى رقم الكتلة، تعرض المعاملات في zkSync أيضًا رقم الحزمة. في الأصل، تم أخذ معلمات مثل block.number و block.timestamp و blockhash من L1. ومع ذلك، بعد تحديث, سيتم الحصول على هذه القيم الآن من L2. على الرغم من ذلك، يخطط المطورون لتوفير طرق للوصول إلى البيانات من L1.

الاختلافات بين zkEVM و EVM

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

اختار zkSync واحدة من أصعب الطرق، مستهدفًا الأداء العالي ولكن مع توافق محدود مع كل من Ethereum و EVM. للحصول على بايت كود متوافق مع zkEVM، LLVMيتم استخدام المشروع مع مجموعة من المترجمات والمحسنات الخاصة. في حالة Solidity و Yul، بعد مترجم solc القياسي، يخضع الكود لعدة مراحل أخرى قبل أن يصبح بايت كود zkEVM. يوضح الرسم البياني أدناه جميع مراحل هذه العملية (التي تم وصفها بتفصيل أكثر هنا):

!مدعومة في zksolc الأمور الهامة

البايت كود المترجم خصيصًا لـ EVM ليس متوافقًا مع zkEVM. وهذا يعني أن عناوين العقود الذكية المتطابقة في Ethereum و zkSync ستختلف. ومع ذلك، يخطط المطورون لحل هذه المشكلة في المستقبل.

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

مسألة توافق مترجمات zk مع أدوات التطوير والتصحيح الحالية لعقود Solidity و Vyper الذكية ذات أهمية كبيرة. منصات التطوير الحالية مثل Remix و Hardhat و Foundry لا تدعم مترجمات zk بشكل افتراضي، مما يخلق صعوبات في العمل معها. ومع ذلك، حلول يتم تطوير أدوات احترافية تعد بتسهيل عملية هجر المشاريع والتكيف مع التقنيات الجديدة.

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

ميزات zkEVM

!مهم، البروتوكول يتم تطويره بنشاط؛ يُرجى الرجوع دائمًا إلى أحدث إصدار من الوثائق!

يختلف zkEVM عن EVM وعلى الرغم من جهود المطورين لإخفاء هذه الفروقات "تحت الغطاء"، هناك ميزات مهمة يجب مراعاتها عند كتابة العقود الذكية:

1. الاختلافات عن EVM: قد تختلف سلوك الشيفرات المكتوبة بلغة Solidity لـ zkEVM، خاصة في جوانب مثل block.timestamp و block.number. من المهم التحقق بانتظام.وثائقللتغييرات.
2. عقود النظام: في zkSync، هناك عقود ذكية للنظام لمختلف الوظائف، مثل ContractDeployer لنشر العقود الذكية و MsgValueSimulator للعمل مع ETH. يمكن العثور على المزيد حول عقود النظام الذكية في وثائق.
3. نمط الوكيل للنشر: يُوصى باستخدام نمط الوكيل خلال الأشهر الأولى بعد النشر لمنع الأخطاء المحتملة في المترجم.
4. حساب الغاز: يختلف نموذج حساب الغاز في zkEVM عن Ethereum، بما في ذلك مجموعة مختلفة من أوامر التشغيل واعتماد سعر الغاز على L1. يمكن العثور على التفاصيلهنا.
5. اختبار محلي: الأدوات القياسية مثل Hardhat Node أو Anvil ليست مناسبة للاختبار المحلي لـ zkEVM. بدلاً من ذلك، خيارات خاصةتستخدم ، بما في ذلك اختبار وضع الشوكة.
6. التحقق من التوقيع: يُوصى باستخدام الدعم المدمج لتجريد الحساب بدلاً من ecrecover.
7. تتبع أخطاء ذات صلة بالغاز: في zkSync، من غير الممكن تتبع الأخطاء المتعلقة بنقص الغاز بسبب تفاصيل التنفيذ داخل عقد الذكاء الافتراضي للنظام الذكي للحسابات.

للحصول على فهم عميق للعمل مع zkEVM، يُوصى بدراسة الوثائق، بما في ذلك القسم "الأمان وأفضل الممارسات".

تجريد الحساب

تجريد الحساب في zkSync يقدم عدة مزايا رئيسية على ERC-4337:

1. مستوى التنفيذ: في zkSync، تم بناء التجريب الحسابي في مستوى البرتوكول، مما يجعل جميع الحسابات، بما في ذلك الحسابات الخارجية المملوكة (EOA)، مشابهة وظيفيًا للعقود الذكية.
2. معالجة المعاملات: بينما يستخدم ERC-4337 مجموعة ذاكرة مؤقتة منفصلة للمجمعين، مما يخلق تيارين مختلفين من المعاملات، يحتوي zkSync Era على مجموعة ذاكرة مؤقتة واحدة. وهذا يعني أن المعاملات الناتجة عن EOAs والعقود الذكية تُعالج في تيار واحد، مما يضمن تكاملًا أسهل ومعالجة أكثر سلاسة.
3. يدعم zkSync البدلاء لجميع أنواع الحسابات، مما يسمح بتكوين رسوم الغاز في رموز ERC20 لأي حساب.

بنية zkSync

بنية zkSync Era تكتسب زخمًا بسرعة وتضم بالفعل عشرات من البروتوكولات: جسور، DeFi، بروتوكولات البنية التحتية، والمزيد. (يمكن الاطلاع على القائمة الحاليةهنا).

ميزة أخرى هي التوافق مع محافظ الإيثيريوم، مثل MetaMask أو TrustWallet.

سلاسل فائقة

بدأ بروتوكول zkSync تطويره مع إطلاق zkSync Lite، الذي يهدف فقط لتحويل الإثير ورموز ERC-20، دون القدرة على نشر بروتوكولات كاملة. كانت هذه المرحلة خطوة مهمة في التطوير ولكنها سبقت فقط وصول عصر zkSync - حلاً من الطبقة L2 الكامل لإيثريوم، الذي يمكن نظريًا تكييفه لسلاسل L1 أخرى أيضًا. ومع ذلك، لا تتوقف طموحات zkSync هنا، حيث تشمل خطط التطوير إطلاق ما يسمى بالسلاسل الفائقة.

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

إن فرادة السلاسل الفائقة تكمن في أنه يمكن إنشاؤها ونشرها بشكل مستقل. من أجل الحفاظ على التناسق والتوافق، يجب أن تستخدم كل سلسلة فائقة محرك zkEVM مشترك، جزء من مكدس ZK (مع Era zkSync العامل كأول سلسلة فائقة). وهذا يتيح للسلاسل الفائقة أن ترث أمانها من L1، مما يضمن موثوقيتها ويقضي على الحاجة إلى تدابير الثقة والأمان الإضافية.

Hyperchains تمثل نهجًا مبتكرًا لتوسيع شبكات البلوكشين، مما يقلل من العبء على الشبكة الرئيسية ويزيد من سرعة معالجة المعاملات. الجوانب الرئيسية لهذا النهج تشمل:

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

• شفافية للمستخدمين: لن يلاحظ المستخدمون الفرق - يتم معالجة معاملاتهم في السلسلات الفائقة ويمكن أن تمر عبر عدة مستويات قبل الوصول إلى الشبكة الرئيسية، مما يخلق عدم تزامن في المعالجة.
• المزايا على الحلول الحالية: على عكس الحلول الحالية من الجيل الثاني، التي تكون أسرع ولكن لا تزال محدودة في حجم المعاملات وأحيانًا تتنازل عن الأمان، تعد الهايبرتشينات بقدرة توسعية أكبر بشكل كبير.
• المرونة في إنشاء سلاسل الكتل المخصصة: تتيح Hyperchains إنشاء سلاسل كتل مخصصة وحسابات بمستويات مختلفة من الأمان والخصوصية. حتى مع مستوى أقل من الأمان، في أسوأ الحالات، يُتوقع فقط تجميد مؤقت للأموال.

المزيد عن كل هذا يمكن العثور عليههنا.

مزايا وعيوب zkSync

احترافي

1. الأمان: أمان عالي القرب من المستوى L1 وإمكانية اللامركزية في المستقبل.
2. دعم التوافق مع EVM: دعم للعقود الذكية المتوافقة مع EVM.
3. واجهة برمجة تطبيقات Web3 والمحافظ: واجهة برمجة تطبيقات Web3 القياسية ودعم لمحافظ Ethereum مثل MetaMask.
4. تجريف الحساب: الدعم الأصلي لتجريف الحساب.
5. سرعة المعاملات: معالجة سريعة للمعاملات على L2 مع تأكيد لاحق على L1.
6. رسوم منخفضة: رسوم الغاز المخفضة مقارنة ب L1.
7. الدفع بالغاز ERC20: القدرة على دفع رسوم الغاز باستخدام رموز ERC20.
8. تطور البنية التحتية: تطوير البنية التحتية نشط جدًا.
9. القدرة على التوسع: فرص لتحسينات كبيرة في القدرة على التوسع.

عيوب

1. التوافق المحدود مع EVM: بالمقارنة مع المنافسين (على سبيل المثال، Polygon zkEVM، Scroll)، فإنه يتمتع بتوافق أقل مع EVM.
2. خطر الأخطاء في العقود الذكية: زيادة خطر الأخطاء، مما يتطلب اختبارًا وتدقيقًا شاملين.
3. احتياجات محددة للتطوير: ضرورة تكييف مجموعة التطوير مع تفاصيل البروتوكول.
4. التأخر في تقنيات النواة: تأخير في اعتماد الابتكارات في المترجمات وتحديثات المكتبة.
5. تمركز الشبكة: حاليا، تُدار الشبكة من قبل عدد محدود من المشغلين.
6. حاجة إلى عقود ذكية قابلة للترقية: من كل ما تم ذكره أعلاه، يتبع من ذلك أن هناك حاجة لجعل العقود قابلة للترقية دائمًا في بداية المشروع، لتكون قادرة على تصحيح النقائص والثغرات بسرعة.

استنتاج

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

إخلاء المسؤولية:

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