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

هناك عدة أنواع مختلفة من حلول تحجيم Ethereum ، ولكل منها مقايضاتها ونماذج الأمان الخاصة بها ، بما في ذلك تجزئة الطبقة 1 ، وقنوات حالة الطبقة 2 ، والبلازما ، والسلاسل الجانبية ، و Rollups ، و Validium. لأن تقنية التجزئة بطيئة في التطور ومعقدة في التنفيذ والسلاسل الجانبية ولا يمكن ل Validium أن ترث الأمان وتوافر البيانات من Ethereum. باختصار ، يستخدم نظام Ethereum البيئي الآن بشكل أساسي حل توسيع نطاق Rollups.

حتى الآن أصبحت Beosin شريكًا أمنيًا لطبقة ETH Layer2 مثل شبكة Manta وشبكة StarkNet. في العديد من عمليات التدقيق السابقة، قد اجتازت العديد من سلاسل الكتل الشهيرة تدقيق أمان سلاسل Beosin، بما في ذلك شبكة Ronin وشبكة Manta وسلسلة Merlin وClover وSelf Chain وCrust Network وما إلى ذلك. يصدر Beosin الآن حلاً لتدقيق سلسلة ETH Layer2 لتقديم خدمات تدقيق أمان شاملة لنظام السلسلة البيانية ETH Layer2.

يستخدم ETH Layer2 Rollups لتجميع مئات المعاملات في تقديم واحد إلى Ethereum mainnet، وبالتالي سيتم تقسيم رسوم المعاملة لجميع مستخدمي Rollup، مما يقلل من الرسوم لكل مستخدم. يتم تقديم بيانات المعاملة في Rollups إلى Layer1، ولكن يتم تنفيذ التنفيذات بشكل مستقل من قبل Rollups. من خلال تقديم بيانات المعاملة إلى Layer1، يمكن لل Rollups أن يرثوا أمان Ethereum لأنه بمجرد تحميل البيانات إلى Layer1، يتطلب إلغاء معاملات Rollups إلغاء البيانات على Layer1.

حاليًا، يمكن تنفيذ Rollups بطريقتين رئيسيتين:

التحجيم المتفائل: استخدم الحوافز الاقتصادية ونظرية الألعاب للتحقق من المعاملات، مثل أربترام، بيس، أوب، بلاست، إلخ.

اللفات ذات المعرفة الصفرية: استخدام البراهين ذات المعرفة الصفرية لضمان الأمان والخصوصية، مثل Scroll, Linea, zkSync, StarkNet، إلخ.

تكديس التفاؤلي

مقدمة

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

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

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

كما هو موضح في الشكل أدناه، فإن فترة التحدي في معظم التقديرات المتفائلة حالياً هي 7 أيام، والأقصر هو يوم واحد.

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

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

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

شبكات الطبقة 2 الرائدة

1. Arbitrum

مع البناء البيئي والإنزال الجوي ، سرعان ما أصبحت Arbitrum الشبكة الأكثر نشاطا في ETH Layer2 ، حيث تجاوزت TVL 2.7 مليار دولار. بعد الإنزال الجوي الكبير ، أطلق فريق Arbitrum برنامج Arbitrum Orbit: تشجيع المطورين على بناء Layer3 باستخدام التقنيات ذات الصلة ب Arbitrum. أكملت Beosin التدقيق الأمني ل ArbSwap و Arbipad للمساعدة في التطوير الأمني للنظام البيئي Arbitrum.

1. تفاؤل

على الرغم من أن Optimism أقل نشاطًا بيئيًا من Arbitrum، إلا أن OP Stack، الذي أطلقته Optimism في عام 2023، حصل على اعتراف واسع النطاق في الصناعة كحل كامل وجاهز لبناء Layer2 القابلة للتعديل. تم بناء أكثر من 25 شبكة Layer2 باستخدام OP Stack، بما في ذلك مشاريع نجمة مثل Base و Mantle و Manta و OP BNB و Celo. اجتازت DIPX Finance و Starnet التي تم بناؤهما على Optimism فحص الأمان لـ Beosin.

1. القاعدة

القاعدة هي شبكة Layer2 تعتمد على OP Stack، وهي تأتي بعد أربيتروم فقط من حيث النشاط البيئي والقيمة الإجمالية للرهان. سبق لـ Beosin تحليل الهندسة المعمارية للقاعدة ومخاطر الأمان بتفصيل، وتدقيق بروتوكول Surf وEDA لمساعدة أصحاب المشاريع والمستخدمين في تجنب المخاطر الأمنية.

1. انفجار

انفجار، في نهاية مسابقة المطور "الانفجار الكبير"، شهدت قفزة إجمالي القيمة المقفلة فيها إلى أكثر من 2 مليار دولار، مما جعلها تحتل مكانًا على الدائرة Layer2. قامت Beosin بتحليل أمان شبكة انفجار قبل إطلاقها على الشبكة الرئيسية. نظرًا لعدم تنفيذ انفجار لبرهان الاحتيال، يتم الاحتفاظ بالأصول في محفظة متعددة التوقيع، وليس في جسر Rollup، مما يزيد من درجة المخاطرة المركزية. قامت Beosin بالتدقيق في عدة مشاريع ايكولوجية لانفجار مثل Wand Protocol و Zest و Kalax.

تحليل الهندسة المعمارية

OP Stack، إطار ناضج للمكدس التحفيزي، يقسم بشكل أساسي العملية المعقدة لبناء سلاسل التحفيز التفاؤلية إلى عملية مبسطة من خلال توفير مجموعة كاملة من المكونات البرمجية والأدوات والإطارات. هنا نأخذ إطار Op stack كمثال لتحليل الهيكلية النمطية لـ Optimism Rollups.

● Execution node: Op-geth هو عميل تنفيذ موسّع لـ Ethereum الذي يتعامل مع وظائف الطبقة 2 بشكل محدد، مثل استقبال إيداعات الرموز من الطبقة 1. تحدد هذه الطبقة جميع الوظائف المسؤولة عن أداء تغييرات الحالة. هنا، يتم تشغيل تحولات الحالة استنادًا إلى الإدخال الذي تم استلامه من العقدة الملخصة (التسلسلات والموثقون) من خلال واجهة المحرك.

● عقدة التراكم: تتضمن جهاز التسلسل والمدقق. المجمعة مسؤولة عن تجميع المعاملات المعالجة من الطبقة 2 ونشرها في الطبقة 1. يحدد جهاز التسلسل كيفية جمع المعاملات على سلسلة Layer2 ونشرها. يتحقق المدقق / المدقق من صحة المعاملة الدفعية ويقدم الأدلة في حالة اكتشاف أي احتيال.

● إثبات الاحتيال: كانون هو نسخة محسنة من Geth ومسؤول عن تشغيل EVM أثناء مرحلة اكتشاف الاحتيال والإثبات. إنه بشكل أساسي محرك نزاع على السلسلة يتنسق مع المتتاليات والمحققين عبر واجهات برمجة التطبيقات لإثبات المعاملات الكاذبة.

● إيداع الدُفعات: يقوم سلسلة العمليات الدُفعية بمعالجة جميع المعاملات المعالجة مرة واحدة، ويتم التحقق منها من قِبل المُحققين، ويقوم سلسلة العمليات الدُفعية بإرسال المعاملات المعالجة في الدُفعة إلى الطبقة 1.

● عقود الجسر: نشرت على إثيريوم وLayer2، مما يتيح للمستخدمين تمرير الرسائل ونقل الأصول بين Layer1 وLayer2.

تحت الهندسة المعمارية لـ Optimistic Rollup، من الضروري ضمان أمان أصول المستخدم أثناء تنقلها بين L1 و L2. يوضح ما يلي كيف يمكن للمستخدمين الوصول إلى الأصول بين الطبقتين وكيف يحافظ النظام على سلامة وأمان هذه المعاملات.

● جسر الأصول إلى Rollup: يقوم المستخدمون بإيداع الأموال في عقد جسر سلسلة Rollup على Layer1. يقوم عقد جسر السلسلة بإعادة التحويلة إلى Layer2 ، حيث يتم ضخ مبلغ مماثل من الأصول وإرساله إلى عنوان يختاره المستخدم في Optimistic Rollup.

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

● سحب الأصول من Rollup: بسبب آلية إثبات الاحتيال ، فإن سحب الأموال من Optimistic Rollup إلى Ethereum أكثر تعقيدًا. إذا قام المستخدم ببدء عملية تحويل من Layer2 إلى Layer1 لسحب الأموال المُدارة على Layer1 ، فيجب عليهم الانتظار لنهاية فترة التحدي ، والتي تستغرق عادة حوالي 7 أيام.

عندما يبدأ المستخدم طلب سحب على Rollup، يتم تضمين الصفقة في الدفعة التالية وتدمير أصول المستخدم على Rollup. بمجرد نشر الدفعة على Ethereum، يمكن للمستخدمين حساب دليل ميركل للتحقق من أن صفقة الخروج الخاصة بهم مضمنة في الكتلة. الخطوة التالية هي الانتظار لانتهاء فترة التأخير لاستكمال الصفقة على Layer1 وسحب الأموال إلى الشبكة الرئيسية.

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

عناصر التدقيق

الطبقة 2 هي نظام سلسلة كتل كامل، لذا ينطبق أيضًا التدقيق الشائع لسلاسل الكتل العامة على التكديس التفاؤلي، كما هو موضح في التذييل في نهاية هذه المقالة.

بالإضافة إلى ذلك، نظرًا لطبيعتها الخاصة، يتطلب Optimistic Rollup عددًا من الفحوصات الإضافية:

● دليل توافر البيانات: التأكد من توافر بيانات المعاملات في الطبقة ٢ على الطبقة ١ لمنع فقدان البيانات.

● آلية مزامنة البيانات: تحقق مما إذا كانت آلية مزامنة البيانات بين الطبقة 1 والطبقة 2 سليمة ويمكنها التعامل مع حالات غير طبيعية مثل تقسيم الشبكة.

● عقد إثبات الاحتيال: التحقق من تنفيذ عقد إثبات الاحتيال بشكل صحيح.

آلية فترة التحدي: تحقق مما إذا كانت مدة فترة التحدي معقولة ومما إذا كان يمكن إكمال دليل الاحتيال خلال الوقت المحدد.

● عملية تقديم إثبات الاحتيال: تحقق من أن عملية تقديم إثبات الاحتيال آمنة.

● عملية الإيداع والسحب: تحقق من عملية الإيداع والسحب من الطبقة 1 إلى الطبقة 2 ومن الطبقة 2 إلى الطبقة 1 لضمان سلامة العملية.

● إنتاج الأصول وحرقها: تحقق من منطق الصب والتدمير للأصول على الطبقة 2 لضمان التطابق الصحيح مع الأصل على الطبقة 1.

● آلية موفر السيولة: إذا كان هناك آلية موفر السيولة (LP)، فمن الضروري دراسة عملية التشغيل لـ LP وأمانها.

لفائف الصفر المعرفة

مقدمة

Zero-Knowledge (ZK) Rollup هو طبقة 2 مبنية على الدليل الصفري للمعرفة. يقوم بأداء عمليات حسابية معقدة وإنشاء دليل خارج السلسلة، والتحقق من الدليل على السلسلة وتخزين جزء من البيانات لضمان توافر البيانات.

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

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

الشبكات الرائدة من الطبقة 2

1. zkSync

zkSync، وهو حل من المستوى L2 تم إطلاقه قبل خمس سنوات من قبل فريق Matter Labs، يستخدم تقنية البرهان المعرف صفري اللمس (zero-knowledge proof) لتمكين التحقق الفعال من المعاملات وقد جمعت أكثر من 200 مليون دولار. يعتبر zkSync واحدًا من أنشط الشبكات من الطبقة L2 بيئيًا باستخدام ZK Rollups، وzkSync مثير للجدل أيضًا. أجرت Beosin سابقًا تدقيقًا لمشروع DeFi الرائد لديها، SyncSwap، والذي يغطي جودة الكود، ومنطق العقد، والأمان، ونموذج التشغيل، والمزيد.

1. StarkNet

تستخدم StarkNet ZK-STARK لبناء Layer2 لزيادة سرعة المعاملات وتقليل رسوم المعاملات. تمتلك StarkNet جهازا افتراضيا أصليا (Cairo VM) ولغة تطوير Cairo لمساعدة المطورين على كتابة العقود الذكية بشكل أكثر أمانا وسهولة. أصبحت Beosin شريكا أمنيا رسميا ل StarkNet ، حيث أكملت عمليات التدقيق الأمني ل Option Dance و Reddio. في 13 أغسطس 2024 ، أغلقت Reddio جولة تمويل أولي بقيادة Paradigm لبناء شبكة EVM Layer2 موازية عالية الأداء.

1. تمرير

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

تحليل الهندسة المعمارية

تشمل الأطر المشتركة لـ ZK Rollups عقود Rollup و Bridge ومجمعات البيانات والمكررات وشبكات Roller التي تولد الأدلة بدون معرفة. يتم عرض الهندسة المعمارية المحددة في الشكل التالي:

● عقد Rollup وعقد Bridge:

يتحمل عقد Rollup مسؤولية توفير توافر البيانات لمعاملات Rollup، والتحقق من دليل صحة zkEVM، والسماح للمستخدمين بنقل الأصول بين إثيريوم وRollup. يتلقى جذر الحالة من الطبقة 2 والكتلة من المجمع، يتم تخزين جذر الحالة في حالة إثيريوم، وتُحفظ بيانات الكتلة طبقة 2 كبيانات الاستدعاء لإثيريوم.

يتم نشر عقود الجسر على Ethereum و Layer2 ، مما يسمح للمستخدمين بتمرير الرسائل ونقل الأصول بين Layer1 و Layer2.

● المتسلسل: يوفر المتسلسل الواجهة JSON-RPC ويقبل المعاملات Layer2 ، ويسترد دفعة من المعاملات من حافظة الذاكرة بشكل دوري للتنفيذ ، مما يولد كتل Layer2 جديدة وجذور حالة. يتم تنفيذه عادة بناءً على Go-Ethereum (Geth) ، مما يضمن أفضل توافق وأعلى مستوى أمان.

● المنسق: يتم إخطار المنسق عندما يقوم المقارن بإنشاء كتلة جديدة ويتلقى تتبع تنفيذ لتلك الكتلة من المجمع. ثم يتم إرسال تتبع التنفيذ إلى الأسطوانة المحددة عشوائيا في شبكة الأسطوانة ، والتي تولد دليلا على الصلاحية.

● الناقل: يراقب الناقل عقود ال Rollup وعقود الجسر المنشورة على إثيريوم والطبقة 2. المسؤوليات الرئيسية هي: 1) تتبع توافر البيانات والتحقق من صحة كتل الطبقة 2 عن طريق مراقبة عقود ال Rollup؛ 2) مراقبة أحداث الإيداع والسحب من إثيريوم ومشاركة الجسر الطبقة 2 وإعادة الرسائل إلى الطرف الآخر.

● شبكة Roller: يعمل Roller في شبكة Roller كـ البتّة ومسؤول عن إنشاء دليل صحة لـ ZK Rollup. يتم استلام تتبع تنفيذ الكتلة أولاً من المنسق، ثم يتم تحويله إلى دليل للدائرة، ثم يتم إنشاء دليل لكل zkevm باستخدام تسريع الأجهزة، وأخيرًا يتم استخدام تجميع الدليل لتجميع عدة دلائل في دليل واحد.

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

● ربط الأصول في رولاب: يدخل المستخدمون إلى رولاب عن طريق إيداع الرموز في عقد رولاب زيتك المنتشر على طبقة من سلسلة الشبكة. يتعين تقديم هذه العملية إلى عقد رولاب من جانب المشروع.

إذا بدأت قائمة انتظار الودائع المعلقة في ملء نفسها، سيقوم مشغل ZK Rollups بقبول هذه المعاملات الوديعة وتقديمها إلى عقد الRollup. بمجرد إيداع الأموال في Rollup، يمكن للمستخدم بدء معالجة المعاملات.

يمكن للمستخدمين التحقق من الرصيد في Rollup عن طريق تجزئة حساباتهم وإرسال قيمة التجزئة إلى عقد Rollup وتقديم دليل Merkle يتحقق من جذر الحالة الحالي.

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

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

2. بيانات المعاملات

3. دفعة الجذر

4. عنوان الشبكة الطبقية 1 لاستقبال الأموال المودعة

يقوم عقد ال Rollup بتجزئة بيانات المعاملة والتحقق مما إذا كانت جذور الدفعة موجودة ويستخدم دليل Merkle للتحقق مما إذا كانت قيمة تجزئة المعاملة جزءًا من جذر الدفعة. يقوم العقد بتنفيذ المعاملة المنسحبة وإرسال الأموال إلى عنوان في الشبكة الطبقية 1 المحددة من قبل المستخدم.

عناصر التدقيق

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

بالإضافة إلى ذلك ، نظرا لطبيعتها الخاصة ، فإن ZK Rollup مطلوب لإجراء بعض عمليات التدقيق الإضافية:

● إثبات أمان النظام: التحقق من سلامة وصحة خطط الإثبات بدون معرفة المستخدمة (على سبيل المثال Groth16، Plonk، Halo2، zk-STARK، إلخ).

● سلامة الدائرة: تحقق من نقاط الضعف المحتملة في تصميم الدائرة وتنفيذها ، بما في ذلك بشكل أساسي ما يلي:

1. الدوائر غير المقيدة

2. الدوائر المفرطة القيد

3. الدوائر غير المحددة

4. تجاوزات الحساب / تحت الحساب الحسابية

5. أطوال بت غير متطابقة

6. تحسين المدخلات العامة غير المستخدمة

7. قلب مجمد: تشكيل البراهين بدون معرفة صفرية

8. تسرب إعداد موثوق به

9. مخصص ولكن ليس مقيدا

10. استخدام مكونات غير آمنة

11. دقة متغيرة

● إنشاء البرهان والتحقق: مراجعة عملية إنشاء البرهان والتحقق لضمان كفاءتها وأمانها.

● إثبات توفر البيانات: تأكد من توفر بيانات معاملات Layer2 على Layer1 لمنع فقدان البيانات.

● آلية مزامنة البيانات: تحقق مما إذا كانت آلية مزامنة البيانات بين الطبقة 1 والطبقة 2 سليمة وقادرة على التعامل مع حالات غير طبيعية مثل تجزئة الشبكة.

● عملية الإيداع والسحب: تحقق من عملية الإيداع والسحب من الطبقة1 إلى الطبقة2 ومن الطبقة2 إلى الطبقة1 لضمان سلامة العملية.

● إنشاء الأصول وحرقها: تحقق من منطق الإنشاء والتدمير للأصول على الطبقة 2 لضمان المطابقة الصحيحة مع الأصل على الطبقة 1.

● البحث عن الاعتماديات الخارجية والثغرات المعروفة: يعتمد ZK Rollup في كثير من الأحيان بشكل كبير على مستودعات التشفير والأدوات الرياضية لجهات خارجية ويجب فحص أمان اعتمادياته بدقة لفحص وتحقق من الثغرات المعروفة.

التذييل

عناصر التدقيق العامة للبلوكشين والطبقة 2:

● تجاوز الصحيح: تحقق من تجاوزات الصحيح وتحتجوزات الصحيح

● التكرار: تحقق من حلقة البرنامج لمعرفة ما إذا كانت الشرطية معقولة

● مكالمة متكررة لانهائية: تحقق مما إذا كانت حالة الخروج من المكالمة العودية للبرنامج معقولة

● حالة سباق: يتحقق من الوصول إلى الموارد المشتركة في الحالة المتزامنة

● تعطل استثناء: تحقق من الكود الذي يلقي الاستثناء والذي يؤدي إلى خروج البرنامج بنشاط

● القسمة على 0 ثغرة أمنية: تحقق مما إذا كانت هناك حالة قسمة على 0

● تحويل النوع: تحقق مما إذا كان تحويل النوع صحيحًا ومما إذا كان يفقد المعلومات الهامة أثناء التحويل

● صفيف خارج الحدود: يتحقق من الوصول إلى عناصر خارج حدود الصفيف

● ثغرة في عملية التحليل: تحقق من وجود مشاكل أثناء عملية التحليل

● الأمان في تنفيذ الوظائف: التحقق مما إذا كان تنفيذ واجهات برمجة التطبيقات عن بعد لديها مخاطر أمان ومتسق مع التصميم الوظيفي لواجهات برمجة التطبيقات عن بعد.

● ما إذا كانت إعدادات الإذن لواجهة RPC الحساسة معقولة: تحقق من إذن الوصول إعدادات واجهة RPC الحساسة

● آلية النقل المشفرة: تحقق مما إذا كان يتم استخدام بروتوكول النقل المشفر، مثل TLS

● عملية تحليل تنسيق بيانات الطلب: يقوم بفحص عملية تحليل تنسيق البيانات للطلب

● هجوم فتح المحفظة: عندما يقوم العقد بفتح محفظته، يُطلب منه عبر RPC سرقة الأموال

● الأمان التقليدي للويب: تحقق من الثغرات التالية: البرمجة عبر الجانب الآخر (XSS)/حقن النموذج/ثغرة المكون الجانبي الثالث/تلوث معلمة HTTP/حقن SQL/حقن كيان XXE/ثغرة فك التسلسل/ثغرة SSRF/حقن الكود/تضمين ملف محلي/تضمين ملف عن بعد/حقن تنفيذ الأوامر وغيرها من الثغرات التقليدية

آلية مصادقة وتحديد هوية عقدة الشبكة: التحقق مما إذا كان هناك آلية لتحديد هوية عقدة الشبكة، يمكن التغاضي عن آلية تحديد هوية عقدة الشبكة

● تلوث جدول التوجيه: تحقق مما إذا كان يمكن إدراج جدول التوجيه أو استبداله بشكل تعسفي

● خوارزمية اكتشاف العقدة: تحقق مما إذا كانت خوارزمية اكتشاف العقدة متوازنة وغير متوقعة ، على سبيل المثال ، خوارزمية المسافة غير متوازنة

● تدقيق استخدام الاتصال: تحقق مما إذا كان الحد وإدارة عدد العقد المتصلة بالشبكة الند-إلى-ند معقولة

● هجمات الكسوف الشمسي: قيم تكاليف ومخاطر هجمات الكسوف الشمسي، وتقديم تحليل كمي إذا لزم الأمر

● هجوم سيبيل: تقييم آليات الإجماع على التصويت وتحليل استراتيجيات التحقق من أهلية التصويت

● هجوم التنصت: تحقق مما إذا كان بروتوكول الاتصال يكشف عن الخصوصية

● هجوم الكائن الغريب: يقيم ما إذا كان بإمكان العقدة التعرف على نوع نفس سلسلة العقدة

● اختراق الوقت: تحقق من آلية حساب وقت الشبكة لعقدة

● هجوم استنزاف الذاكرة: التحقق من استهلاك الذاكرة الكبير

● هجوم استنزاف القرص الصلب: تحقق من مكان تخزين الملفات الكبيرة

● هجوم ضغط المقبس: تحقق من سياسة الحد على عدد الروابط

● هجوم استنزاف مقبض النواة: تحقق من وجود قيود على إنشاء مقابض النواة، مثل مقابض الملفات

● تسرب الذاكرة المستمر: تحقق من تسرب الذاكرة

● أمان خوارزمية التجزئة: تحقق من مقاومة التصادم لخوارزمية التجزئة

● أمان خوارزمية التوقيع الرقمي: تحقق من أمان خوارزمية التوقيع وتنفيذ الخوارزمية

● أمان خوارزمية التشفير: تحقق من أمان خوارزمية التشفير وتنفيذ الخوارزمية

● أمان مولد الأرقام العشوائية: تحقق مما إذا كان خوارزمية توليد الأرقام العشوائية للمفتاح معقولة

● أمان تنفيذ BFT: تقييم أمان تنفيذ خوارزميات BFT

● قواعد اختيار الفورك: تحقق من قواعد اختيار الفورك لضمان الأمان

● اختبار درجة التمركز: تحديد ما إذا كان هناك تصميم مركزي جدًا في تصميم النظام

● التدقيق في الحوافز: تقييم تأثير الحوافز على الأمان

● هجمات الإنفاق المزدوج: تحقق مما إذا كان التوافق يمكنه الدفاع عن هجمات الإنفاق المزدوج

● تدقيق في هجوم MEV: فحص تأثير MEV لعقدة حزمة الكتل على عدالة السلسلة

● تدقيق عملية مزامنة الكتلة: يتحقق من وجود مشاكل أمان أثناء المزامنة

● تدقيق عملية تحليل تنسيق الكتلة: يتحقق من وجود مشكلات أمنية أثناء تحليل التنسيق ، مثل أخطاء التحليل التي تسبب أعطالا

● تدقيق عملية إنشاء الكتل: تحقق من مشكلات الأمان في عملية إنشاء الكتلة ، بما في ذلك ما إذا كان جذر شجرة Merkle قد تم إنشاؤه بطريقة معقولة

● تدقيق عملية التحقق من الكتلة: تحقق مما إذا كانت عناصر توقيع الكتلة ومنطق التحقق كافيين

● تدقيق منطق التحقق من الكتلة: تحقق ما إذا كان خوارزمية التحقق من الكتلة وتنفيذها معقولة

● تصادم هاش الكتلة: تحقق من كيفية بناء تصادم هاش الكتلة وما إذا كان يتم التعامل مع التصادم بشكل معقول

● حدود موارد معالجة الكتلة: تحقق مما إذا كانت حمامات الكتلة المتخلفة والحوسبة التحقق وعناوين القرص الصلب وحدود الموارد الأخرى معقولة

● تدقيق عملية مزامنة المعاملات: يتحقق من مشاكل الأمان في عملية المزامنة

● تصادمات مجموعة هاش للمعاملات: افحص كيفية بناء تصادمات مجموعة هاش للمعاملات وكيفية التعامل معها

● تحليل تنسيق المعاملة: تحقق من وجود مشكلات أمنية أثناء تحليل التنسيق ، مثل أخطاء التحليل التي تسبب أعطالا

● التحقق من صحة الصفقة: تحقق مما إذا كانت العناصر التوقيعية لكل نوع من الصفقات والمنطق التحقق كافية

● حدود موارد معالجة المعاملات: تحقق مما إذا كانت حدود الموارد مثل تجمعات المعاملات وحوسبة التحقق وعنونة القرص الثابت معقولة

● هجوم مرونة المعاملة: ما إذا كان بإمكان المعاملة تغيير الحقول الداخلية (مثل ScriptSig) لتغيير تجزئة المعاملة دون التأثير على صحة المعاملة

● تدقيق هجوم إعادة تشغيل المعاملة: يتحقق من اكتشاف النظام لإعادة تشغيل المعاملة

● التحقق من برنامج البايت للعقد: تحقق من أمان عملية التحقق من العقد في الآلة الافتراضية، مثل تجاوز الصفر والحلقات الميتة

● تنفيذ كود العقد: تحقق من أمان عملية تنفيذ كود العقد في الآلة الافتراضية، مثل تجاوز العدد الصحيح، وحلقات ميتة، وما إلى ذلك

● نموذج الغاز: تحقق من أن الرسوم لكل عملية ذرية في معالجة التحويلة / تنفيذ العقد متناسبة مع استهلاك الموارد

● سلامة السجل: تحقق مما إذا كان قد تم تسجيل المعلومات الأساسية

● أمان السجلات: تحقق مما إذا كانت معالجة السجلات غير المناسبة تسبب مشاكل أمنية، مثل تجاوز الصحيفة العددية

● تحتوي السجلات على معلومات خاصة: تحقق مما إذا كانت السجلات تحتوي على معلومات خاصة مثل المفاتيح

● تخزين السجل: تحقق مما إذا كان يتم تسجيل المحتوى الزائد في السجلات ، مما يستهلك موارد العقدة

● أمان سلسلة التوريد لكود العقد: تحقق من جميع مكتبات الأطر الجانبية والمكونات والإصدارات لأطر السلسلة العامة لمعرفة المشاكل المعروفة

اخلاء المسؤوليه:

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