في الوقت الحالي، أطلقت شركة Scroll نشاط إطلاق Binance، وكان من المفترض أن يستمر لمدة يوم واحد ولا يزال هناك يوم آخر متبقي. يجب على أولئك الذين يرغبون في التعدين التصرف بسرعة. المبلغ الإجمالي هذه المرة كبير جدًا Launchpool: 55,000,000 SCR (الحد الأقصى للرمز 5.5% من العرض)، في هذا العدد سنقوم بتحليل الجوانب الفنية للتمرير، بالإضافة إلى الاختلافات بين ZKEVMs الأربعة على مستوى الملك، وتقديرات أسعار العملة، وما إلى ذلك.
واحد. نظرة عامة على التمرير
Scroll هو حل zkRollup مكافئ لـ EVM لتوسيع نطاق Ethereum. من الناحية الفنية، يتكون Scroll بشكل أساسي من جزأين. الجزء الأساسي هو zkEVM، والذي يُستخدم لإثبات صحة تنفيذ EVM في الطبقة الثانية.
ثانيًا: بنية Scroll
يتكوّن الهيكل الحالي من ثلاثة أجزاء من مكوّنات البنية التحتية (انظر الشكل 1 أدناه):
1. عقدة Scroll: تقوم ببناء كتلة L2 من معاملات المستخدمين، وتقوم بإرسالها إلى طبقة الأساس في Ethereum، ثم تمرير الرسائل بين L1 وL2.
2. شبكة Roller: توليد إثباتات الصحة لـ zkEVM لإثبات صحة تنفيذ المعاملات.
3. عقود Rollup وBridge: توفر بيانات توفر البيانات لمعاملات Scroll، وتتحقق من إثباتات صحة zkEVM، وتسمح للمستخدمين بنقل الأصول بين Ethereum وScroll.
2.1 عقدة Scroll
تعد عقدة Scroll هي الطريقة الرئيسية التي يتفاعل بها التطبيق والمستخدمون مع Scroll. وتتكون من ثلاثة وحدات: المُرتّب (Sequencer)، المنسق (Coordinator)، والمرسل/الرايلر (Relayer).
- يقدم الـ sequencer واجهة JSON-RPC، ويستقبل معاملات L2. كل بضع ثوانٍ، يحصل على مجموعة من المعاملات من mempool الخاصة بـ L2، وينفذ هذه المعاملات لتوليد كتلة جديدة من L2 وجذر حالة جديد. يتم تنفيذ الـ sequencer بالاعتماد على Go-Ethereum (Geth)، وهو أحد أكثر تطبيقات عقد Ethereum شيوعًا. من خلال التفرّع (fork) الخاص بـ Geth، يمكن تحقيق أعلى قدر من التوافق، والاستفادة من الأمان الذي تم اختباره عبر الزمن.
- عند توليد كتلة جديدة، يتم إخطار المنسق (Coordinator) ويقوم بجلب مسار التنفيذ لهذه الكتلة من الـ sequencer. بعد ذلك، يقوم المنسق بتوزيع مسار التنفيذ على Roller مختار عشوائيًا من مجموعة Rollers لتوليد الإثباتات.
- المرسل/الرايلر (Relayer): يراقب عقود الجسر (Bridge) وعقود الـ Rollup الموزعة على Ethereum وScroll. ولديه مسؤوليتان رئيسيتان: أولًا، مراقبة عقد Rollup، وتتبع حالة كتل L2، بما في ذلك توفر البيانات وإثباتات الصحة. ثانيًا، مراقبة أحداث الإيداع والسحب في عقود الجسر الموزعة على Ethereum وScroll، ونقل الرسائل بين الطرفين.
2.2 شبكة Roller
Roller هو مُثبِت (prover) في الشبكة، وهو مسؤول عن توليد إثباتات الصحة لعمل zkRollup. يحتاج Roller إلى استخدام مُسرّع (مثل GPU أو FPGA أو ASIC) لتقليل وقت وتكلفة توليد الإثبات. يوضح الشكل 2 عملية قيام Roller بتوليد إثباتات الصحة لكل كتلة. تتضمن العملية الخطوات التالية:
1. يقوم Roller أولًا بتحويل مسار التنفيذ الذي يتلقاه من المنسق إلى شاهد الدائرة (circuit witness).
2. تولّد الإثباتات لكل دائرة zkEVM.
3. أخيرًا، من خلال إثبات التجميع يتم دمج إثباتات عدة دوائر zkEVM في إثبات واحد للكتلة.
2.3 عقود Rollup وBridge
يتصل Scroll بالمستوى الأساسي لإيثريوم عبر Rollup وBridge ذكيَين. تضمن هذه العقود معًا توفر بيانات معاملات L2، وتسمح للمستخدمين بنقل الأصول والرسائل بين L1 وL2.
- عقد Rollup: يستقبل جذر حالة L2 وبيانات الكتل من الـ sequencer. يقوم بتخزين جذر الحالة داخل حالة Ethereum، كما يقوم بتخزين بيانات كتل L2 كـ calldata على Ethereum. وهذا يوفر توفر البيانات لكتل Scroll، ويستفيد من أمان Ethereum لضمان قدرة الفهارس (indexers) — بما في ذلك relayer في Scroll — على إعادة بناء كتل L2. بمجرد التحقق من صحة إثبات الكتلة داخل عقد Rollup، تُعتبر الكتلة المقابلة مُثبتة نهائيًا على Scroll.
- عقد Bridge: يتم نشرها على Ethereum وScroll، ما يسمح للمستخدمين بنقل أي رسائل بين L1 وL2. وبناءً على بروتوكول نقل الرسائل هذا، يبني Scroll أيضًا بروتوكول جسر غير قائم على الثقة يسمح للمستخدمين بعمل جسر ثنائي الاتجاه لأصول ERC-20 بين الطبقتين. لإرسال رسالة أو أموال من إيثريوم إلى Scroll، يحتاج المستخدم إلى استدعاء معاملة `sendMessage` على عقد Bridge. يقوم الـ Relayer بفهرسة هذه المعاملة على L1 ثم إرسالها إلى الـ sequencer، لكي يتم تضمينها في كتلة L2. ويتم تنفيذ عملية إرسال الرسالة من Scroll إلى إيثريوم على نحو مماثل عبر عقد L2 Bridge.
2.4 كيف تعمل zkRollup في Scroll؟
بدمج مكوّنات البنية الثلاثة هذه، يمكن تلخيص سير عمل zkRollup في Scroll كما هو موضح في الشكل 3 أدناه.
الترتيب التالي يوضح خطوات توليد كتل L2 في Scroll وإرسالها إلى طبقة الأساس في Ethereum ثم تثبيتها نهائيًا:
1. يقوم الـ sequencer بتوليد سلسلة من الكتل. بالنسبة للكتلة ذات الفهرس i، يقوم الـ sequencer بتوليد مسار التنفيذ T وإرساله إلى المنسق. وفي الوقت نفسه، يقوم أيضًا بتقديم بيانات المعاملة D كـ calldata إلى عقد Rollup على Ethereum لضمان توفر البيانات. ثم يقوم بتقديم جذر الحالة الناتج والالتزام ببيانات المعاملات إلى عقد Rollup كحالة (state).
2. يختار المنسق بشكل عشوائي Roller لتوليد إثباتات الصحة لمسارات كل كتلة. ولتسريع عملية توليد الإثباتات، يمكن توليد إثباتات الكتل المختلفة بشكل متوازٍ على عدة Rollers.
3. بعد توليد إثبات الكتلة P للكتلة ذات الفهرس i، يقوم Roller بإرساله إلى المنسق. وكل k كتل، يقوم المنسق بتجميع المهمة وتوزيعها على Roller آخر، بحيث يتم تجميع إثباتات هذه الـ k كتل في إثبات تجميعي واحد A.
4. أخيرًا، يقوم المنسق بتجميع إثبات A وإرساله إلى عقد Rollup. من خلال التحقق من إثبات التجميع وربط ذلك بجذر الحالة والالتزام ببيانات المعاملات التي تم تقديمها سابقًا إلى عقد Rollup، يتم تثبيت كتل L2 من i+1 إلى i+k نهائيًا.
يعرض الشكل 3 عملية التثبيت متعددة الخطوات لكتل Scroll على L1. يتم تمرير كل كتلة L2 تدريجيًا عبر المراحل الثلاث التالية حتى يتم تثبيتها نهائيًا:
- التعهّد قبل الإرسال النهائي (Precommitted): يعني أن الكتلة تم اقتراحها من قبل الـ sequencer وإرسالها إلى الـ Rollers. على الرغم من أن الكتل المُعرّضة مسبقًا ليست جزءًا رسميًا بعد من سلسلة Scroll L2 لأنها لم يتم نشرها بعد على طبقة الأساس في Ethereum، إلا أن المستخدمين الذين يثقون بالـ sequencer يمكنهم اختيار اتخاذ إجراءات بناءً على هذه الكتل.
- التعهّد المسبق (Committed): يشير إلى أن بيانات معاملات الكتلة قد تم نشرها على عقد Rollup في Ethereum. وهذا يضمن توفر بيانات الكتلة، لكن لم يتم بعد إثبات أنها تم تنفيذها بطريقة صحيحة (وفقًا لإثباتات صحة).
- التثبيت النهائي (Finalized): يعني أنه بعد التحقق من إثباتات الصحة على سلسلة إيثريوم، تم إثبات أن تنفيذ معاملات الكتلة صحيح. تُعتبر الكتل المثبتة نهائيًا جزءًا رسميًا من سلسلة Scroll L2.
ثالثًا: مقارنة Scroll مع بقية ZKEVMs
3.1 الخلفية الأساسية
في عام 2022، نشر v神 سابقًا مقالة شرح فيها أربعة أنواع مختلفة من ZKEVM (تم تقديمها سابقًا عند الحديث عن مشروع kakarot)، وهي:
فئة النوع 1 من zkEVM: مكافئة تمامًا لإيثريوم
فئة النوع 2 من zkEVM: توافق كامل مع آلة إيثريوم الافتراضية EVM
فئة النوع 3 من zkEVM: متوافقة تقريبًا مع آلة إيثريوم الافتراضية EVM
فئة النوع 4 من zkEVM: توافق مع اللغات عالية المستوى
في المخططات، يمكن ملاحظة أن أداء فئة النوع 4 جيد، لكن التوافق مع EVM منخفض. أما التوافق في النوع 1 فهو الأعلى، لكن وقت توليد الإثباتات طويل. ويبدو أن هذا يشبه "مثلثًا مستحيلًا"، أي لا يمكن الجمع بين الأداء والتوافق.
3.2 تصنيف الأربعة أنواع التي اقترحتها Immutable
ZKsync: حاليًا هو من النوع 4 zkEVM، متوافق بالكامل مع لغة البرمجة Solidity. باستخدام zkSync، يمكن للمستخدمين اختيار نوعين لتوفر البيانات: zkSync Rollup وzkSync Porter. في الحالة الأولى يتم نشر البيانات مباشرة على Ethereum، مما يجعله آمنًا مثل Ethereum L1، أما في الحالة الثانية فتتم تخزين البيانات خارج السلسلة (off-chain)، ما يؤدي إلى سرعة أعلى للمعاملات وتكلفة أقل، لكن بمستوى أمان أقل.
zkSync متوافق مع EVM لأنه يمكنه تحويل كود العقود الذكية المكتوب بلغة Solidity إلى Yul، ثم تحويل Yul إلى LLVM-IR (Intermediate Representation، أي التمثيل الوسيط لشفرة الآلة)، وبعد ذلك تتم إعادة تجميعه إلى مجموعة بايتكود متوافقة مع دوائر مخصصة لـ EVM في zkSync. ورغم أن هذا يتطلب خطوات وسيطة، إلا أنه يتيح أيضًا إضافة ميزات أخرى غير تابعة لـ EVM، مثل Account Abstraction. إضافةً إلى ذلك، تهدف شركة zkSync Matter Labs إلى جعل توافقها تدريجيًا أكبر مع مجموعة أدوات Ethereum، والاستعداد لإطلاق نموذج أولي ثلاثي الطبقات الخاص بها zkSync Opportunity في مجالات قابلية التوسع والتداخلية (interoperability)، ونشره على الشبكة الاختبارية كجزء من طموحها.
StarkNET: StarkNet هي zk-rollup من النوع 4 / متوافقة مع Solidity. تستخدم نوعًا مختلفًا من الإثباتات الصفرية المعرفة يسمى STARKs (Scalable Transparent ARgument of Knowledge) لضمان سلامة المعاملات خارج السلسلة. يُنظر إلى STARKs على أنها أكثر كفاءة وقابلة للتوسع من SNARK، لكنها قد تتطلب إعدادات تقنية أكثر تعقيدًا.
على الرغم من أن StarkNet تدعم أيضًا العقود الذكية، إلا أنه نظرًا لاستخدام STARKs، ولأن عقود StarkNet وStarkNet OS مكتوبة بلغة Cairo، فإن قدراتها تكون أقل نسبيًا. ولجعل التطوير أسهل، قامت StarkWare مؤخرًا بترقية Cairo إلى الإصدار 1.0، والذي يحاكي Rust. وبالطريقة نفسها مثل zkSync Era، يمكن تصنيف StarkNet على أنها "متوافقة مع Solidity" لأنها لا تنفذ البرامج داخل EVM، بل تقوم بإنشاء VM جديد ومصمم خصيصًا وتستخدم bytecode مخصص. تستخدم StarkWare مُحوّل Warp لتحويل كود Solidity إلى bytecode لـ Cairo VM.
ومع ذلك، وبخلاف zkSync Era والعديد من تطبيقات zkEVM الأخرى، لا يهدف فريق StarkNet إلى التوافق مع EVM أو مكونات إيثريوم الأخرى. بل يسعى إلى جعل VM الخاص بـ StarkNet أكثر كفاءة قدر الإمكان عبر تمرير (rolling) API العميل المخصص لها ومكتبات JavaScript وأنظمة المحفظة، وهو ما سيجبر الأدوات المتوافقة مع إيثريوم على إضافة دعم StarkNet يدويًا. وعلى الرغم من أن Cairo 1.0 أدخل أيضًا Sierra — التمثيل الوسيط الآمن — كطبقة تمثيل وسيطة جديدة بين Cairo 1.0 وCairo bytecode، إلا أن مُحوّل Warp لا يدعم بعض ميزات Solidity، ولا يزال هناك طريق طويل لتحقيق التوافق مع EVM كما في zkSync Era.
Polygon ZKEVM: يستخدم لغة مخصصة zkASM لفهم/تفسير كود zkEVM، والتحقق من تنفيذ العقود الذكية في بيئة تشغيل غير تابعة لـ EVM. إضافةً إلى Polygon zkEVM، طورت Polygon أيضًا Polygon Avail، وهي سلسلة بلوكشين محسّنة فقط لتوفر البيانات. ستكون هذه الشبكة غير مرخّصة، ما يسمح لأي شخص بالانضمام كمدقق، وبدلًا من DAC الحالية (Data Availability Committees) سيكون لديها مئات العقد تتعاون لتوفير أمان الشبكة. ستعمل Avail جنبًا إلى جنب مع Polygon Hermez (Rollup)، حيث يتم رفع بيانات الحالة من Hermez بدلًا من نشرها على Ethereum، لتقديم حل بين Validium وRollup.
Scroll: Scroll هو zk-rollup مكافئ لـ EVM تم تطويره بالتعاون بين فريق Scroll ومجموعة PSE (Privacy and Scaling Explorations) التابعة لمؤسسة إيثريوم. يهدف إلى التوافق الكامل على مستوى البايتكود مع آلة إيثريوم الافتراضية (EVM). وهذا يعني أنه يمكن للمطورين استخدام أي لغة متوافقة مع EVM لإنشاء العقود الذكية ونشرها على Scroll. على الرغم من أن Scroll لا يدعم حاليًا أوپكودات EVM، إلا أنه يخطط لتحقيق ذلك عبر بناء تعيين 1:1 بين الأوبكودات، والاستقبال المباشر لأوبكودات EVM دون الحاجة إلى المُصرّف (compiler).
رابعًا: تقدير سعر العملة
إجمالي المعروض: 1,000,000,000. الكمية المتداولة في البداية: 190,000,000. توزيع الرموز: 35% للنظام البيئي (25% نمو النظام البيئي، و10% خزانة DAO)، 10% للمؤسسة، 23% للمساهمين، 17% للمستثمرين، 15% للإطلاق الجوي (airdrops).
حاليًا من ناحية TVL، يتقدم Scroll (瑶瑶) في الصدارة، والمركز الثاني هو ZKsync. حاليًا قيمة FDV لدى zksync تبلغ 2.5 مليار، وبعد الإطلاق بحوالي وقت قصير وصلت تقريبًا إلى 5 مليارات؟ على ما يبدو 50亿، بينما straknet حاليًا FDV تبلغ 3.8 مليار، وبعد الإطلاق وصلت إلى 20 مليار. وبحسب عوائد launchpool السابقة (1%-2%)، نتوقع أن يكون سعر الإطلاق بين 2.2 و4.4 دولارًا. وبالتالي تكون القيمة السوقية المكافئة بين 2 مليار و4 مليارات. في الواقع، هذا التقييم لا يزال منخفضًا نسبيًا؛ لأن مثل هذه المشاريع عند الإطلاق تكون عادةً بعلاوة (premium)، لذا يُتوقع أن يتجاوز التقدير حاليًا 5 دولارات.
