وفي العاشر من أكتوبر، في تمام الساعة 14:00، أنتج حل إيثريوم من الطبقة الثانية «سكرول مايننت» أول كتلة له، مما يمثل الإطلاق الناجح للشبكة الرئيسية لـ «سكرول». اعتبارًا من 25 أكتوبر، تم ربط أكثر من 7600 ETH بشبكة Scroll من خلال الجسور عبر السلاسل، وتم إطلاق 24 منصة تداول لامركزية على شبكة Scroll الرئيسية، بإجمالي TVL يبلغ حوالي 10 ملايين دولار.
في 17 أكتوبر، أعلنت Scroll رسميًا عن إطلاق شبكتها الرئيسية مع الاستمرار في دعم التزامها بالمصادر المفتوحة واللامركزية. في المرحلة التالية، ستركز Scroll على بناء شبكة وفرز لامركزية لإثبات الحصة. في هذه المقالة، سنقدم تحليلاً مفصلاً لبنية Scroll وتقنيتها لمساعدة الجميع على فهم حالة الشبكة الحالية واتجاه التطوير المستقبلي لـ Scroll. سنشرح أيضًا دائرة zKevm الخاصة بـ Scroll ومعرفة التدقيق لتعزيز الإجراءات الأمنية لمشاريع zk.
Scroll هو حل لتوسيع نطاق Ethereum Layer 2 يعتمد على تقنية إثبات عدم المعرفة، ويهدف إلى تحسين إنتاجية المعاملات وسرعة شبكة Ethereum. وبالمقارنة مع Optiatic Rollup، يحقق Scroll قابلية التوسع من خلال براهين المعرفة الصفرية ويسرع توليد البراهين الخالية من المعرفة والتحقق منها من خلال تسريع الأجهزة. وهي ملتزمة بتحقيق توافق EVM على مستوى البايت كود. هذا يعني أنه يمكن للمطورين استخدام أدوات التطوير المتعلقة بـ Solidity و Ethereum مباشرةً لإنشاء عقود ذكية ونشرها على Scroll دون أي تعديلات.
وفقًا للموقع الرسمي لـ Scroll، يوجد حاليًا 10 أعضاء أساسيين في فريق Scroll، موزعين في جميع أنحاء آسيا وأمريكا وأوروبا. يتمتع أعضاء الفريق بخبرة غنية في عمليات تطوير ZKrollup والصناعة، حيث يتخرج معظمهم من جامعات مرموقة ويحملون درجات الدكتوراه.
في الوقت الحالي، يعد نظام Scroll البيئي غنيًا جدًا، مع مشاريع البنية التحتية بما في ذلك المحافظ وأدوات التطوير والمرافق الأمنية والمزيد. الهدف هو تقديم دعم شامل للمشاريع طوال دورة الحياة بأكملها، من التصميم والتطوير والتشغيل إلى التدقيق الأمني. يوجد حاليًا أكثر من 180 مشروعًا للنظام البيئي على شبكة Scroll الرئيسية.
تدعم Wallet Scroll حاليًا جميع المحافظ الرئيسية تقريبًا: ميتاماسك، تروستواليت، ماثواليت، توكن بوكيت، WalletConnect، محفظة سلسلة Binance، محفظة SafePal. بالإضافة إلى ذلك، تتضمن محفظة Scroll للنظام البيئي أيضًا محفظة OKX ومحفظة Versa وما إلى ذلك.
تشمل البنية التحتية الرسمية عبر السلاسل لـ Cross-Chain Bridge Scroll شبكة سيلير، وسترجيت، وأوربيتر فاينانس، وبروتوكول هوب، وLI.FI، وكونيكست، وما إلى ذلك. بالإضافة إلى ذلك، فإنه يتضمن أيضًا بروتوكول السيولة عبر السلاسل وبروتوكول Synapse و Owlto Finance الذي يركز على الجسور عبر السلاسل من الطبقة الثانية وجسر إيثريوم من الطبقة الأولى والطبقة الثانية عبر السلاسل وشبكة Pheasant Network و Symbiosis و Catalyst وما إلى ذلك.
DeFi
في نظام Scroll البيئي، هناك العديد من مشاريع DeFi الراسخة، بما في ذلك بروتوكول الإقراض Aave، ومجمع DEX متعدد السلاسل DODO، و DEX SushiSwap، ومجمع DEX OpenOcean، وبروتوكول DeFi متعدد السلاسل iZumi Finance، و DEX Syncswap، وبروتوكول العائد، وبروتوكول الإقراض dForce، ومجمع التداول بالرافعة المالية بروتوكول MUX. هناك أيضًا مشاريع مبتكرة مثل GMX لم يتم اعتمادها على نطاق واسع.
أخرى
فيما يتعلق بـ NFT والألعاب والجوانب الاجتماعية، تشمل المشاريع الأخرى في نظام Scroll البيئي NFTScan ومنصة مهام Web3 QuestN و TasKon ومنصة توقيع البروتوكولات الإلكترونية EthSign و Galaxy Blitz و OmniKingdoms وألعاب بلوكتشين الأخرى عبر الإنترنت.
ما الذي يميز تقنية Scroll عن غيرها؟
تتكون بنية Scroll من ثلاثة مكونات:
عقدة التمرير: تقوم بإنشاء كتل على شبكة Scroll استنادًا إلى معاملات المستخدم، وتقدم هذه المعاملات إلى الطبقة الأساسية لـ Ethereum، وتعالج الرسائل التي تمر بين Ethereum و Scroll.
الأسطوانة: The Roller مسؤولة عن تحويل العقود الذكية إلى دوائر zKevm، ثم تقوم بإنشاء أدلة لإثبات صحة المعاملات. هناك العديد من Rollers في شبكة Scroll، والتي تعالج المعاملات بالتوازي وتسرع توليد الإثبات من خلال الأجهزة. يحقق التمرير التوافق على مستوى البايت كود مع EVM من خلال إثبات صحة معالجة كود بايت EVM بشكل مباشر.
عقد التجميع والجسر: توفر هذه العقود توفر البيانات لمعاملات Scroll والتحقق من أدلة الصلاحية التي تم إنشاؤها بواسطة zKevm. يمكن القول أن Scroll متصل بالطبقة الأساسية لـ Ethereum من خلال عقود Rollup و Bridge. ومن خلال هذه العقود، يمكن للمستخدمين تبادل الرسائل التعسفية بين إيثريوم وScroll، ونقل أصول ERC-20 في أي اتجاه بمساعدة عقود البوابة.
المصدر: https://scroll.mirror.xyz/nDAbJbSIJdQIWqp9kn8J0MVS4s6pYBwHmK7keidQs-k
التمرير هو العقد الرئيسي الذي تم نشره على بلوكشين إيثريوم:
عقد وكيل توجيه البوابة (ضمان التعيين الصحيح للرموز في العمليات عبر السلاسل):0xF8b1378579659d8f7ee5f3c929c2f3e332e41fd6
عقد وكيل الرسائل (إرسال الرسائل بين المستوى الأول والثاني):0x6774bcbd5CEF1336b5300fb5186a12DD8b367
تجدر الإشارة إلى أنه يمكن تعديل هذه العقود من قبل مسؤول الوكيل والمالك. بالإضافة إلى ذلك، قامت Scroll بدمج وظيفة القائمة البيضاء التي تتيح تعديل رسوم الغاز لعناوين محددة داخل Scroll. حاليًا، يعمل مُسلسِل Scroll بطريقة مركزية، مما يسمح بمراجعة الرسائل والمعاملات على شبكة Scroll. علاوة على ذلك، هناك إمكانية لتجاوز أي رسالة في قائمة انتظار الرسائل وتأكيد رسالة معينة مباشرة.
بعد أن يقوم Scroll بإنشاء كتلة، فإنها تمر عبر منسق والعديد من المجربين (Rollers) لإنشاء براهين مجمعة. يتم بعد ذلك تقديم هذه البراهين إلى عقد Ethereum Rollup للتحقق. العملية التفصيلية هي كما يلي:
1、يتلقى المنظم معاملات جديدة. يقوم الجهاز الافتراضي بقراءة رمز البايت المرتبط بكل معاملة، مما يؤدي إلى إنشاء تتبع التنفيذ وإرساله إلى المنسق. في نفس الوقت، يقوم المنظم بإرسال بيانات المعاملة إلى عقد التجميع.
2、تقوم الأسطوانات بتحويل آثار التنفيذ المستلمة من المنسق إلى دوائر zKevm. كل خطوة في تتبع التنفيذ تتوافق مع دائرة zKevm. بالنسبة للوظائف غير الملائمة لـ zk (مثل hash و Keccak)، يقوم Scroll بإنشاء جداول بحث لتعيين مدخلات ومخرجات هذه الوظائف في تتبع التنفيذ إلى جدول البحث. يتم استخدام دوائر إضافية للتحقق من صحة جدول البحث. تقوم البكرات بعد ذلك بإنشاء براهين لدوائر zKevm هذه.
3、بعد إنشاء البراهين، يرسلها Rollers مرة أخرى إلى المنسق. كل بضع كتل، يقوم المنسق بتعيين مهام التجميع بشكل عشوائي إلى Roller. تقوم الأسطوانة المخصصة بعد ذلك بتجميع البراهين للكتل المتعددة في إثبات واحد.
4、أخيرًا، يقدم المنسق الدليل المجمع لعقد Rollup. يستخدم عقد Rollup هذا الدليل للتحقق من صحة بيانات الحالة والمعاملات المقدمة مسبقًا، وبالتالي تأكيد صحة الكتلة.
يتكون ZKevm من دوائر متعددة، كل منها مكلف بالتحقق من جانب معين من EVM (آلة إيثريوم الافتراضية). يتم دمج هذه الدوائر في النهاية أو تجميعها لإنشاء دليل على تنفيذ المعاملة. يوضح الرسم البياني أدناه العلاقة بين هذه الدوائر والجداول.
هناك دوائر فرعية أصغر، مثل دائرة ECDSA والدوائر الفرعية المرتبطة بالتشفير، والتي لا تتفاعل مع الجداول والدوائر الأخرى بطريقة تؤثر على تركيبة الدائرة. تم حذف هذه الدوائر الفرعية من الرسم التخطيطي للوضوح.
دائرة EVM
آلة إيثريوم الافتراضية (EVM) هي آلة حكومية تضع قواعد انتقالات الحالة الصالحة داخل بروتوكول إيثريوم. يقوم بتنفيذ التعليمات (رموز التشغيل) لتحقيق هذه التحولات وإنشاء تتبع التنفيذ. الهدف من دائرة EVM هو إنشاء نظام قيود يمثل تتبع التنفيذ ويمكن التحقق منه باستخدام نظام إثبات عدم المعرفة.
التصميم عالي المستوى لدائرة EVM يشبه إلى حد ما تصميم EVM نفسه، مثل go-ethereum. في go-ethereum، يقوم المترجم بتكرار جميع أكواد تشغيل التعليمات الموجودة على تتبع التنفيذ. بالنسبة لكل تعليمة، يتحقق المترجم من معلومات السياق ذات الصلة مثل الغاز والمكدس والذاكرة، ثم يرسل رمز التشغيل إلى JumpTable، الذي يوفر تعليمات مفصلة لتنفيذ كود التشغيل.
وبالمثل، في دوائر EVM، يقوم Scroll بإنشاء خطوات التنفيذ بناءً على تتبع التنفيذ ويوفر أدلة لرموز التشغيل وسياقات التنفيذ. لكل خطوة تنفيذ، يتم تطبيق مجموعة من القيود للتحقق من المعلومات السياقية. بالنسبة لكل كود تشغيل، يتم تطبيق مجموعة من القيود للتحقق من سلوكه. ضمن تتبع التنفيذ، يجب أن يحتوي نفس كود التشغيل على نفس القيود. يستخدم Scroll محددات «لفتح» جميع الخطوات بنفس رمز التشغيل في تتبع التنفيذ ويستخدم نظام إثبات الواجهة الخلفية لإثبات سلوكهم.
دائرة الدولة
أثناء التنفيذ، يتم تسجيل جميع عمليات القراءة والكتابة الخاصة بـ EVM في rw_table وترتيبها بواسطة متغير rw_counter. الغرض من دائرة الدولة هو إظهار التوليد الدقيق لـ rw_table.
حلبة إم بي تي
تعد شجرة Merkle Patricia (MPT) بنية بيانات رئيسية تستخدم في طبقة تخزين إيثريوم. في دوائر zKevm الخاصة بـ Scroll، يتم تعديل MPT إلى ZKtrie، وهو في الأساس ثنائي متفرق من نوع Merkle Patricia Trie. في دوائر Zkevm، يستخدم Scroll جدول MPT لتتبع انتقالات الحالة لعمليات MPT خطوة بخطوة. يحتوي جدول MPT على التخطيط التالي:
الهدف من دائرة MPT هو التحقق من دقة جدول MPT المذكور أعلاه. يضمن أن كل تحديث مسجل في جدول MPT ينتج عنه تغيير صحيح. هذا يعني أنه بالنسبة لكل تحديث، تضمن دائرة MPT وجود طريقة واحدة ممكنة لإجراء التغييرات. هذا يمنع التعديلات العرضية أو غير المصرح بها ويضمن سلامة ودقة MPT. على وجه التحديد، عندما تخضع MPT للتغييرات بسبب التحديثات في الحسابات أو التخزين، يجب أن تثبت دائرة MPT أن هذه التحديثات تتم وفقًا للقواعد المحددة. بالإضافة إلى ذلك، يجب أن تثبت أن التجزئة الجذرية تعكس بدقة نتائج جميع التغييرات.
حلبة كيجاك
قامت شركة Scroll بتطبيق نسختها الخاصة من Keccak256، وفقًا لمواصفات NIST Keccak ومواصفات فريق Keccak.
ويتم استخدام دائرة Keccak لإثبات صحة عملية Keccak256. يعد تنفيذ هذه الدائرة أمرًا معقدًا، ويرجع ذلك أساسًا إلى أن خوارزمية keccak256 نفسها غير ملائمة لـ zk-unfity.
دائرة تكساس
توفر دائرة Tx قيودًا للتحقق من صحة المعاملة. يتحقق بشكل أساسي من الجوانب التالية للمعاملة:
صحة CallDataLength و CallDataGasCost التراكمي: تحديد البوابة المخصصة والعثور على الصف الأخير من وحدات بايت بيانات المكالمات في جدول tx؛
صحة البيانات المتعلقة بـ TxSign و TxHash: ابحث في جدول RLP وجدول Keccak؛
أثبت صحة «إذا كان tx_type هو L1Msg، ثم msg_hash»: تحقق من خلال البحث في جدول RLP؛
قم بتنفيذ توقيع tx بشكل صحيح باستخدام ECDSA واسترجع عنوان المتصل بشكل صحيح من توقيع ECDSA: تحقق من خلال البحث في جدول التوقيع؛
السلوك الانتقالي الصحيح لمعرف tx وcum_num_txs وcall_data_length؛
بعض القيود الأساسية، مثل القيم المنطقية لمتغيرات مؤشر معينة.
دائرة بايت كود
تحتاج دوائر EVM إلى البحث عن جدول كود البايت الذي يحتوي على معلومات البايت كود الصحيحة. وهذا يضمن تطابق وحدات البايت المخزنة في العقد مع وحدات البايت التي تم تحميلها من الجدول. الغرض من دائرة البايت كود هو فرض صحة جدول البايت كود. وهذا يشمل:
القيود المتعلقة بسلوك الحدود باستخدام العلامات (العلامة): القيود على السطر الأول والأخير، والتحويل من العلامة == بايت إلى رأس والعكس، والتحويل من رأس إلى رأس؛
القيود على حجم الكود: بما في ذلك حساب طول البايت كود من خلال قيد فهرس البايت الأخير من البايت كود؛
القيود المفروضة على تجزئة الكود: تقييد سلوك RLC للبايتات بشكل صحيح في تجزئة الكود والتحقق من تجزئة الكود من خلال البحث عن جدول Keccak؛
التأكد من صحة سلوك PUSH: is_code = push_data_left == 0 (يجب أن تكون قيمة منطقية) والتحقق من حجم البيانات المدفوعة لـ PUSH1-PUSH32 من خلال البحث عن push_table؛
ضمان الانتشار الصحيح في كل سطر من كود البايت.
تحتوي السلاسل المختلفة على وظائف وحدة الأعمال المخصصة الخاصة بها، والتي عادةً ما تقوم بتعديل العقود المجمعة مسبقًا ورموز التشغيل في EVM. من بينها، Scroll zKevm هو حل تحجيم من الطبقة الثانية يعتمد على براهين المعرفة الصفرية. يقوم هذا الحل بإعادة بناء أكواد التشغيل ذات الصلة باستخدام الدوائر وإنشاء البراهين بناءً على آثار التنفيذ. هذا التنفيذ المعقد يزيد بشكل كبير من صعوبة التدقيق. بعد التقييم من قبل خبراء الأمن في Beosin، يركز التدقيق الأمني لـ zKevm بشكل أساسي على الجوانب التالية:
الغاز:عند إنشاء أدلة لتتبع تنفيذ دائرة zKevm، فإنها تتحقق أيضًا من صحة استهلاك الغاز للمعاملات. إذا تم استخدام المتغيرات الحرة غير المقيدة بشكل متكرر في دائرة تنفيذ أكواد التشغيل، فقد يؤدي ذلك إلى فشل توليد الإثبات أو أخطاء أخرى غير معروفة.
سلامة الذاكرة: تعتمد بعض دوائر zKevM على التزامات متعددة الحدود، مثل التزام KZG الذي تستخدمه Scroll. ومع ذلك، لا تتم محاذاة الحسابات متعددة الحدود تلقائيًا، لذلك إذا كانت الدائرة تفتقر إلى القيود، فقد يؤدي ذلك إلى نطاق قيمة غير متوافق مع نطاق البايت في برامج الكمبيوتر. في بعض الحالات، عندما يقوم مطورو العقود بتمكين تحسين الغاز، يمكن أن يؤدي الترتيب المضغوط للبيانات إلى مشكلات تتعلق بسلامة الذاكرة، مثل متعدد الحدود الثابت BYTE_C4096 في Polygon zKevm. تسمح معادلات الحدود المتعددة لقيم المعلمات بتجاوز الحد الأقصى لنطاق قيمة البايت البالغ 255، مما قد يمكّن أجهزة التسلسل الضارة من معالجة المعلمات لتحقيق الربح في بعض منصات التبادل التي تعتمد نموذج AMM. بشكل أساسي، تنشأ هذه الأنواع من الثغرات الأمنية من التناقضات بين نطاق الصلاحية العددي الذي تمثله الدائرة ونطاق القيمة المتغيرة للبرنامج. ومن الأمثلة على ذلك الثغرة الأمنية CVE-2023-33252 التي اكتشفها باحثو الأمن في Beosin في مكتبة Snarkjs.
أمان Opcode: عند تنفيذ أكواد تشغيل zKevm، هناك مشكلات أمنية شائعة، خاصة فيما يتعلق بالدقة. على سبيل المثال، عند مقارنة رقمين في الدائرة الأساسية، إذا كانت دقة عملية المقارنة في البرنامج هي 1 بايت، فإن قيود الدائرة تحتاج إلى تحديد نطاق القيمة. وإلا فإن دقة العمليات في الدائرة ستتجاوز دقة البرنامج، مما يؤدي إلى نتائج غير صحيحة.
دعم EIPs الآمنة: دعم EIPs التي تركز على الأمان مثل EIP-2 و EIP-155.
مشكلة المركزية في Sequencer: حاليًا، تعتمد جميع البراهين التي تم إنشاؤها بواسطة Scroll على تتبع التنفيذ الذي تم إنشاؤه بواسطة Sequencer. إذا تصرف Sequencer بشكل ضار، فلن يتمكن zKevm من ضمان أمان أصول المستخدم.
مشكلة التوافق: تقوم ZKevm بإنشاء أدلة الدوائر استنادًا إلى تتبع التنفيذ والتحقق منها في العقد. حتى الترقيات الطفيفة في Sequencer قد تؤدي إلى اختلافات كبيرة في تتبع التنفيذ الذي تم إنشاؤه على مستوى اللغة الأساسي.
تتبنى Scroll حاليًا إصدار KZG المكون من طبقتين من نظام Halo2 المقاوم، باستخدام تسريع أجهزة GPU لتسريع توليد الإثبات. لقد تحولت العقبة الآن إلى توليد الشهود وتكرار البيانات. بالإضافة إلى ذلك، يعد مستوى المركزية وتكاليف تشغيل الأجهزة لـ Roller أيضًا جوانب تحتاج Scroll إلى أخذها في الاعتبار من أجل التطوير المستقبلي لأنظمة الإثبات متعددة المراحل.
نظرًا لأن تتبع تنفيذ EVM يتغير ديناميكيًا، فهناك العديد من قيود ومقاييس الدوائر. حاليًا، لاستيعاب أثر التنفيذ المتغير ديناميكيًا، تحتاج كل خطوة من خطوات تتبع التنفيذ إلى تلبية أكبر مقياس للدائرة، مما يؤدي إلى إهدار إضافي للذاكرة.
من المتوقع حاليًا أن تستفيد Scroll's Roller من رسوم معاملات الشبكة. ومع ذلك، لا يمكن للعدد الحالي للمستخدمين ورسوم المعاملات في شبكة Scroll تغطية تكاليف تشغيل Roller وجهاز التسلسل. في المستقبل، تعد كيفية توفير شبكة Scroll حوافز اقتصادية لجذب المستخدمين والحفاظ على تشغيل مستقر للشبكة سؤالًا يجب مراعاته.
حاليًا، تدعم Beosin أيضًا تدقيق مشروع zk. لإجراء أبحاث أمنية صارمة على zk، يمكنك قراءة المقالات التالية: 1. إثبات مقاومة المرونة في المعاملات: هجوم النمو (16)؛ 2. استكشاف Tornado Cash بعمق للكشف عن هجمات المرونة في مشاريع ZKP.
أنشأت Beosin، بصفتها شركة أمان بلوكتشين رائدة عالميًا، فروعًا في أكثر من 10 دول ومناطق حول العالم. تغطي خدماتنا عمليات تدقيق أمان التعليمات البرمجية قبل إطلاق المشروع، ومراقبة المخاطر الأمنية، والإنذار المبكر والوقاية أثناء تشغيل المشروع، واسترداد الأصول للعملات الافتراضية المسروقة، وخدمات الامتثال الآمنة مثل KYT/AML. نحن نقدم حلاً شاملاً لمنتجات وخدمات أمان blockchain. حاليًا، قمنا بتوفير خدمات تكنولوجيا الأمان لأكثر من 3000 شركة بلوكتشين على مستوى العالم وقمنا بمراجعة أكثر من 3000 عقد ذكي. لا تتردد في الاتصال بنا.
وفي العاشر من أكتوبر، في تمام الساعة 14:00، أنتج حل إيثريوم من الطبقة الثانية «سكرول مايننت» أول كتلة له، مما يمثل الإطلاق الناجح للشبكة الرئيسية لـ «سكرول». اعتبارًا من 25 أكتوبر، تم ربط أكثر من 7600 ETH بشبكة Scroll من خلال الجسور عبر السلاسل، وتم إطلاق 24 منصة تداول لامركزية على شبكة Scroll الرئيسية، بإجمالي TVL يبلغ حوالي 10 ملايين دولار.
في 17 أكتوبر، أعلنت Scroll رسميًا عن إطلاق شبكتها الرئيسية مع الاستمرار في دعم التزامها بالمصادر المفتوحة واللامركزية. في المرحلة التالية، ستركز Scroll على بناء شبكة وفرز لامركزية لإثبات الحصة. في هذه المقالة، سنقدم تحليلاً مفصلاً لبنية Scroll وتقنيتها لمساعدة الجميع على فهم حالة الشبكة الحالية واتجاه التطوير المستقبلي لـ Scroll. سنشرح أيضًا دائرة zKevm الخاصة بـ Scroll ومعرفة التدقيق لتعزيز الإجراءات الأمنية لمشاريع zk.
Scroll هو حل لتوسيع نطاق Ethereum Layer 2 يعتمد على تقنية إثبات عدم المعرفة، ويهدف إلى تحسين إنتاجية المعاملات وسرعة شبكة Ethereum. وبالمقارنة مع Optiatic Rollup، يحقق Scroll قابلية التوسع من خلال براهين المعرفة الصفرية ويسرع توليد البراهين الخالية من المعرفة والتحقق منها من خلال تسريع الأجهزة. وهي ملتزمة بتحقيق توافق EVM على مستوى البايت كود. هذا يعني أنه يمكن للمطورين استخدام أدوات التطوير المتعلقة بـ Solidity و Ethereum مباشرةً لإنشاء عقود ذكية ونشرها على Scroll دون أي تعديلات.
وفقًا للموقع الرسمي لـ Scroll، يوجد حاليًا 10 أعضاء أساسيين في فريق Scroll، موزعين في جميع أنحاء آسيا وأمريكا وأوروبا. يتمتع أعضاء الفريق بخبرة غنية في عمليات تطوير ZKrollup والصناعة، حيث يتخرج معظمهم من جامعات مرموقة ويحملون درجات الدكتوراه.
في الوقت الحالي، يعد نظام Scroll البيئي غنيًا جدًا، مع مشاريع البنية التحتية بما في ذلك المحافظ وأدوات التطوير والمرافق الأمنية والمزيد. الهدف هو تقديم دعم شامل للمشاريع طوال دورة الحياة بأكملها، من التصميم والتطوير والتشغيل إلى التدقيق الأمني. يوجد حاليًا أكثر من 180 مشروعًا للنظام البيئي على شبكة Scroll الرئيسية.
تدعم Wallet Scroll حاليًا جميع المحافظ الرئيسية تقريبًا: ميتاماسك، تروستواليت، ماثواليت، توكن بوكيت، WalletConnect، محفظة سلسلة Binance، محفظة SafePal. بالإضافة إلى ذلك، تتضمن محفظة Scroll للنظام البيئي أيضًا محفظة OKX ومحفظة Versa وما إلى ذلك.
تشمل البنية التحتية الرسمية عبر السلاسل لـ Cross-Chain Bridge Scroll شبكة سيلير، وسترجيت، وأوربيتر فاينانس، وبروتوكول هوب، وLI.FI، وكونيكست، وما إلى ذلك. بالإضافة إلى ذلك، فإنه يتضمن أيضًا بروتوكول السيولة عبر السلاسل وبروتوكول Synapse و Owlto Finance الذي يركز على الجسور عبر السلاسل من الطبقة الثانية وجسر إيثريوم من الطبقة الأولى والطبقة الثانية عبر السلاسل وشبكة Pheasant Network و Symbiosis و Catalyst وما إلى ذلك.
DeFi
في نظام Scroll البيئي، هناك العديد من مشاريع DeFi الراسخة، بما في ذلك بروتوكول الإقراض Aave، ومجمع DEX متعدد السلاسل DODO، و DEX SushiSwap، ومجمع DEX OpenOcean، وبروتوكول DeFi متعدد السلاسل iZumi Finance، و DEX Syncswap، وبروتوكول العائد، وبروتوكول الإقراض dForce، ومجمع التداول بالرافعة المالية بروتوكول MUX. هناك أيضًا مشاريع مبتكرة مثل GMX لم يتم اعتمادها على نطاق واسع.
أخرى
فيما يتعلق بـ NFT والألعاب والجوانب الاجتماعية، تشمل المشاريع الأخرى في نظام Scroll البيئي NFTScan ومنصة مهام Web3 QuestN و TasKon ومنصة توقيع البروتوكولات الإلكترونية EthSign و Galaxy Blitz و OmniKingdoms وألعاب بلوكتشين الأخرى عبر الإنترنت.
ما الذي يميز تقنية Scroll عن غيرها؟
تتكون بنية Scroll من ثلاثة مكونات:
عقدة التمرير: تقوم بإنشاء كتل على شبكة Scroll استنادًا إلى معاملات المستخدم، وتقدم هذه المعاملات إلى الطبقة الأساسية لـ Ethereum، وتعالج الرسائل التي تمر بين Ethereum و Scroll.
الأسطوانة: The Roller مسؤولة عن تحويل العقود الذكية إلى دوائر zKevm، ثم تقوم بإنشاء أدلة لإثبات صحة المعاملات. هناك العديد من Rollers في شبكة Scroll، والتي تعالج المعاملات بالتوازي وتسرع توليد الإثبات من خلال الأجهزة. يحقق التمرير التوافق على مستوى البايت كود مع EVM من خلال إثبات صحة معالجة كود بايت EVM بشكل مباشر.
عقد التجميع والجسر: توفر هذه العقود توفر البيانات لمعاملات Scroll والتحقق من أدلة الصلاحية التي تم إنشاؤها بواسطة zKevm. يمكن القول أن Scroll متصل بالطبقة الأساسية لـ Ethereum من خلال عقود Rollup و Bridge. ومن خلال هذه العقود، يمكن للمستخدمين تبادل الرسائل التعسفية بين إيثريوم وScroll، ونقل أصول ERC-20 في أي اتجاه بمساعدة عقود البوابة.
المصدر: https://scroll.mirror.xyz/nDAbJbSIJdQIWqp9kn8J0MVS4s6pYBwHmK7keidQs-k
التمرير هو العقد الرئيسي الذي تم نشره على بلوكشين إيثريوم:
عقد وكيل توجيه البوابة (ضمان التعيين الصحيح للرموز في العمليات عبر السلاسل):0xF8b1378579659d8f7ee5f3c929c2f3e332e41fd6
عقد وكيل الرسائل (إرسال الرسائل بين المستوى الأول والثاني):0x6774bcbd5CEF1336b5300fb5186a12DD8b367
تجدر الإشارة إلى أنه يمكن تعديل هذه العقود من قبل مسؤول الوكيل والمالك. بالإضافة إلى ذلك، قامت Scroll بدمج وظيفة القائمة البيضاء التي تتيح تعديل رسوم الغاز لعناوين محددة داخل Scroll. حاليًا، يعمل مُسلسِل Scroll بطريقة مركزية، مما يسمح بمراجعة الرسائل والمعاملات على شبكة Scroll. علاوة على ذلك، هناك إمكانية لتجاوز أي رسالة في قائمة انتظار الرسائل وتأكيد رسالة معينة مباشرة.
بعد أن يقوم Scroll بإنشاء كتلة، فإنها تمر عبر منسق والعديد من المجربين (Rollers) لإنشاء براهين مجمعة. يتم بعد ذلك تقديم هذه البراهين إلى عقد Ethereum Rollup للتحقق. العملية التفصيلية هي كما يلي:
1、يتلقى المنظم معاملات جديدة. يقوم الجهاز الافتراضي بقراءة رمز البايت المرتبط بكل معاملة، مما يؤدي إلى إنشاء تتبع التنفيذ وإرساله إلى المنسق. في نفس الوقت، يقوم المنظم بإرسال بيانات المعاملة إلى عقد التجميع.
2、تقوم الأسطوانات بتحويل آثار التنفيذ المستلمة من المنسق إلى دوائر zKevm. كل خطوة في تتبع التنفيذ تتوافق مع دائرة zKevm. بالنسبة للوظائف غير الملائمة لـ zk (مثل hash و Keccak)، يقوم Scroll بإنشاء جداول بحث لتعيين مدخلات ومخرجات هذه الوظائف في تتبع التنفيذ إلى جدول البحث. يتم استخدام دوائر إضافية للتحقق من صحة جدول البحث. تقوم البكرات بعد ذلك بإنشاء براهين لدوائر zKevm هذه.
3、بعد إنشاء البراهين، يرسلها Rollers مرة أخرى إلى المنسق. كل بضع كتل، يقوم المنسق بتعيين مهام التجميع بشكل عشوائي إلى Roller. تقوم الأسطوانة المخصصة بعد ذلك بتجميع البراهين للكتل المتعددة في إثبات واحد.
4、أخيرًا، يقدم المنسق الدليل المجمع لعقد Rollup. يستخدم عقد Rollup هذا الدليل للتحقق من صحة بيانات الحالة والمعاملات المقدمة مسبقًا، وبالتالي تأكيد صحة الكتلة.
يتكون ZKevm من دوائر متعددة، كل منها مكلف بالتحقق من جانب معين من EVM (آلة إيثريوم الافتراضية). يتم دمج هذه الدوائر في النهاية أو تجميعها لإنشاء دليل على تنفيذ المعاملة. يوضح الرسم البياني أدناه العلاقة بين هذه الدوائر والجداول.
هناك دوائر فرعية أصغر، مثل دائرة ECDSA والدوائر الفرعية المرتبطة بالتشفير، والتي لا تتفاعل مع الجداول والدوائر الأخرى بطريقة تؤثر على تركيبة الدائرة. تم حذف هذه الدوائر الفرعية من الرسم التخطيطي للوضوح.
دائرة EVM
آلة إيثريوم الافتراضية (EVM) هي آلة حكومية تضع قواعد انتقالات الحالة الصالحة داخل بروتوكول إيثريوم. يقوم بتنفيذ التعليمات (رموز التشغيل) لتحقيق هذه التحولات وإنشاء تتبع التنفيذ. الهدف من دائرة EVM هو إنشاء نظام قيود يمثل تتبع التنفيذ ويمكن التحقق منه باستخدام نظام إثبات عدم المعرفة.
التصميم عالي المستوى لدائرة EVM يشبه إلى حد ما تصميم EVM نفسه، مثل go-ethereum. في go-ethereum، يقوم المترجم بتكرار جميع أكواد تشغيل التعليمات الموجودة على تتبع التنفيذ. بالنسبة لكل تعليمة، يتحقق المترجم من معلومات السياق ذات الصلة مثل الغاز والمكدس والذاكرة، ثم يرسل رمز التشغيل إلى JumpTable، الذي يوفر تعليمات مفصلة لتنفيذ كود التشغيل.
وبالمثل، في دوائر EVM، يقوم Scroll بإنشاء خطوات التنفيذ بناءً على تتبع التنفيذ ويوفر أدلة لرموز التشغيل وسياقات التنفيذ. لكل خطوة تنفيذ، يتم تطبيق مجموعة من القيود للتحقق من المعلومات السياقية. بالنسبة لكل كود تشغيل، يتم تطبيق مجموعة من القيود للتحقق من سلوكه. ضمن تتبع التنفيذ، يجب أن يحتوي نفس كود التشغيل على نفس القيود. يستخدم Scroll محددات «لفتح» جميع الخطوات بنفس رمز التشغيل في تتبع التنفيذ ويستخدم نظام إثبات الواجهة الخلفية لإثبات سلوكهم.
دائرة الدولة
أثناء التنفيذ، يتم تسجيل جميع عمليات القراءة والكتابة الخاصة بـ EVM في rw_table وترتيبها بواسطة متغير rw_counter. الغرض من دائرة الدولة هو إظهار التوليد الدقيق لـ rw_table.
حلبة إم بي تي
تعد شجرة Merkle Patricia (MPT) بنية بيانات رئيسية تستخدم في طبقة تخزين إيثريوم. في دوائر zKevm الخاصة بـ Scroll، يتم تعديل MPT إلى ZKtrie، وهو في الأساس ثنائي متفرق من نوع Merkle Patricia Trie. في دوائر Zkevm، يستخدم Scroll جدول MPT لتتبع انتقالات الحالة لعمليات MPT خطوة بخطوة. يحتوي جدول MPT على التخطيط التالي:
الهدف من دائرة MPT هو التحقق من دقة جدول MPT المذكور أعلاه. يضمن أن كل تحديث مسجل في جدول MPT ينتج عنه تغيير صحيح. هذا يعني أنه بالنسبة لكل تحديث، تضمن دائرة MPT وجود طريقة واحدة ممكنة لإجراء التغييرات. هذا يمنع التعديلات العرضية أو غير المصرح بها ويضمن سلامة ودقة MPT. على وجه التحديد، عندما تخضع MPT للتغييرات بسبب التحديثات في الحسابات أو التخزين، يجب أن تثبت دائرة MPT أن هذه التحديثات تتم وفقًا للقواعد المحددة. بالإضافة إلى ذلك، يجب أن تثبت أن التجزئة الجذرية تعكس بدقة نتائج جميع التغييرات.
حلبة كيجاك
قامت شركة Scroll بتطبيق نسختها الخاصة من Keccak256، وفقًا لمواصفات NIST Keccak ومواصفات فريق Keccak.
ويتم استخدام دائرة Keccak لإثبات صحة عملية Keccak256. يعد تنفيذ هذه الدائرة أمرًا معقدًا، ويرجع ذلك أساسًا إلى أن خوارزمية keccak256 نفسها غير ملائمة لـ zk-unfity.
دائرة تكساس
توفر دائرة Tx قيودًا للتحقق من صحة المعاملة. يتحقق بشكل أساسي من الجوانب التالية للمعاملة:
صحة CallDataLength و CallDataGasCost التراكمي: تحديد البوابة المخصصة والعثور على الصف الأخير من وحدات بايت بيانات المكالمات في جدول tx؛
صحة البيانات المتعلقة بـ TxSign و TxHash: ابحث في جدول RLP وجدول Keccak؛
أثبت صحة «إذا كان tx_type هو L1Msg، ثم msg_hash»: تحقق من خلال البحث في جدول RLP؛
قم بتنفيذ توقيع tx بشكل صحيح باستخدام ECDSA واسترجع عنوان المتصل بشكل صحيح من توقيع ECDSA: تحقق من خلال البحث في جدول التوقيع؛
السلوك الانتقالي الصحيح لمعرف tx وcum_num_txs وcall_data_length؛
بعض القيود الأساسية، مثل القيم المنطقية لمتغيرات مؤشر معينة.
دائرة بايت كود
تحتاج دوائر EVM إلى البحث عن جدول كود البايت الذي يحتوي على معلومات البايت كود الصحيحة. وهذا يضمن تطابق وحدات البايت المخزنة في العقد مع وحدات البايت التي تم تحميلها من الجدول. الغرض من دائرة البايت كود هو فرض صحة جدول البايت كود. وهذا يشمل:
القيود المتعلقة بسلوك الحدود باستخدام العلامات (العلامة): القيود على السطر الأول والأخير، والتحويل من العلامة == بايت إلى رأس والعكس، والتحويل من رأس إلى رأس؛
القيود على حجم الكود: بما في ذلك حساب طول البايت كود من خلال قيد فهرس البايت الأخير من البايت كود؛
القيود المفروضة على تجزئة الكود: تقييد سلوك RLC للبايتات بشكل صحيح في تجزئة الكود والتحقق من تجزئة الكود من خلال البحث عن جدول Keccak؛
التأكد من صحة سلوك PUSH: is_code = push_data_left == 0 (يجب أن تكون قيمة منطقية) والتحقق من حجم البيانات المدفوعة لـ PUSH1-PUSH32 من خلال البحث عن push_table؛
ضمان الانتشار الصحيح في كل سطر من كود البايت.
تحتوي السلاسل المختلفة على وظائف وحدة الأعمال المخصصة الخاصة بها، والتي عادةً ما تقوم بتعديل العقود المجمعة مسبقًا ورموز التشغيل في EVM. من بينها، Scroll zKevm هو حل تحجيم من الطبقة الثانية يعتمد على براهين المعرفة الصفرية. يقوم هذا الحل بإعادة بناء أكواد التشغيل ذات الصلة باستخدام الدوائر وإنشاء البراهين بناءً على آثار التنفيذ. هذا التنفيذ المعقد يزيد بشكل كبير من صعوبة التدقيق. بعد التقييم من قبل خبراء الأمن في Beosin، يركز التدقيق الأمني لـ zKevm بشكل أساسي على الجوانب التالية:
الغاز:عند إنشاء أدلة لتتبع تنفيذ دائرة zKevm، فإنها تتحقق أيضًا من صحة استهلاك الغاز للمعاملات. إذا تم استخدام المتغيرات الحرة غير المقيدة بشكل متكرر في دائرة تنفيذ أكواد التشغيل، فقد يؤدي ذلك إلى فشل توليد الإثبات أو أخطاء أخرى غير معروفة.
سلامة الذاكرة: تعتمد بعض دوائر zKevM على التزامات متعددة الحدود، مثل التزام KZG الذي تستخدمه Scroll. ومع ذلك، لا تتم محاذاة الحسابات متعددة الحدود تلقائيًا، لذلك إذا كانت الدائرة تفتقر إلى القيود، فقد يؤدي ذلك إلى نطاق قيمة غير متوافق مع نطاق البايت في برامج الكمبيوتر. في بعض الحالات، عندما يقوم مطورو العقود بتمكين تحسين الغاز، يمكن أن يؤدي الترتيب المضغوط للبيانات إلى مشكلات تتعلق بسلامة الذاكرة، مثل متعدد الحدود الثابت BYTE_C4096 في Polygon zKevm. تسمح معادلات الحدود المتعددة لقيم المعلمات بتجاوز الحد الأقصى لنطاق قيمة البايت البالغ 255، مما قد يمكّن أجهزة التسلسل الضارة من معالجة المعلمات لتحقيق الربح في بعض منصات التبادل التي تعتمد نموذج AMM. بشكل أساسي، تنشأ هذه الأنواع من الثغرات الأمنية من التناقضات بين نطاق الصلاحية العددي الذي تمثله الدائرة ونطاق القيمة المتغيرة للبرنامج. ومن الأمثلة على ذلك الثغرة الأمنية CVE-2023-33252 التي اكتشفها باحثو الأمن في Beosin في مكتبة Snarkjs.
أمان Opcode: عند تنفيذ أكواد تشغيل zKevm، هناك مشكلات أمنية شائعة، خاصة فيما يتعلق بالدقة. على سبيل المثال، عند مقارنة رقمين في الدائرة الأساسية، إذا كانت دقة عملية المقارنة في البرنامج هي 1 بايت، فإن قيود الدائرة تحتاج إلى تحديد نطاق القيمة. وإلا فإن دقة العمليات في الدائرة ستتجاوز دقة البرنامج، مما يؤدي إلى نتائج غير صحيحة.
دعم EIPs الآمنة: دعم EIPs التي تركز على الأمان مثل EIP-2 و EIP-155.
مشكلة المركزية في Sequencer: حاليًا، تعتمد جميع البراهين التي تم إنشاؤها بواسطة Scroll على تتبع التنفيذ الذي تم إنشاؤه بواسطة Sequencer. إذا تصرف Sequencer بشكل ضار، فلن يتمكن zKevm من ضمان أمان أصول المستخدم.
مشكلة التوافق: تقوم ZKevm بإنشاء أدلة الدوائر استنادًا إلى تتبع التنفيذ والتحقق منها في العقد. حتى الترقيات الطفيفة في Sequencer قد تؤدي إلى اختلافات كبيرة في تتبع التنفيذ الذي تم إنشاؤه على مستوى اللغة الأساسي.
تتبنى Scroll حاليًا إصدار KZG المكون من طبقتين من نظام Halo2 المقاوم، باستخدام تسريع أجهزة GPU لتسريع توليد الإثبات. لقد تحولت العقبة الآن إلى توليد الشهود وتكرار البيانات. بالإضافة إلى ذلك، يعد مستوى المركزية وتكاليف تشغيل الأجهزة لـ Roller أيضًا جوانب تحتاج Scroll إلى أخذها في الاعتبار من أجل التطوير المستقبلي لأنظمة الإثبات متعددة المراحل.
نظرًا لأن تتبع تنفيذ EVM يتغير ديناميكيًا، فهناك العديد من قيود ومقاييس الدوائر. حاليًا، لاستيعاب أثر التنفيذ المتغير ديناميكيًا، تحتاج كل خطوة من خطوات تتبع التنفيذ إلى تلبية أكبر مقياس للدائرة، مما يؤدي إلى إهدار إضافي للذاكرة.
من المتوقع حاليًا أن تستفيد Scroll's Roller من رسوم معاملات الشبكة. ومع ذلك، لا يمكن للعدد الحالي للمستخدمين ورسوم المعاملات في شبكة Scroll تغطية تكاليف تشغيل Roller وجهاز التسلسل. في المستقبل، تعد كيفية توفير شبكة Scroll حوافز اقتصادية لجذب المستخدمين والحفاظ على تشغيل مستقر للشبكة سؤالًا يجب مراعاته.
حاليًا، تدعم Beosin أيضًا تدقيق مشروع zk. لإجراء أبحاث أمنية صارمة على zk، يمكنك قراءة المقالات التالية: 1. إثبات مقاومة المرونة في المعاملات: هجوم النمو (16)؛ 2. استكشاف Tornado Cash بعمق للكشف عن هجمات المرونة في مشاريع ZKP.
أنشأت Beosin، بصفتها شركة أمان بلوكتشين رائدة عالميًا، فروعًا في أكثر من 10 دول ومناطق حول العالم. تغطي خدماتنا عمليات تدقيق أمان التعليمات البرمجية قبل إطلاق المشروع، ومراقبة المخاطر الأمنية، والإنذار المبكر والوقاية أثناء تشغيل المشروع، واسترداد الأصول للعملات الافتراضية المسروقة، وخدمات الامتثال الآمنة مثل KYT/AML. نحن نقدم حلاً شاملاً لمنتجات وخدمات أمان blockchain. حاليًا، قمنا بتوفير خدمات تكنولوجيا الأمان لأكثر من 3000 شركة بلوكتشين على مستوى العالم وقمنا بمراجعة أكثر من 3000 عقد ذكي. لا تتردد في الاتصال بنا.