المؤلف: إيان شو @ فورسايت فنتشرز
ليرة تركية؛ د
تقدم هذه المقالة خدمة Rollup-as-a-Service، التي تلبي الاحتياجات المتزايدة والمتنوعة لـ Dapps. تُمكّن RaaS التطبيقات اللامركزية من الحفاظ على الأداء العالي وتقليل التكاليف وتقديم تجارب أفضل للمستخدمين دون المساس بتفاعلهم مع النظام البيئي الأوسع.
في حين أن RaaS لديها إمكانات، يبدو أن الميزة الأساسية لـ RaaS هي خيارات التخصيص الخاصة بها، وبشكل عام، فإن الطلب على RaaS محدود حاليًا، وتحتاج قيمتها إلى مزيد من الاستكشاف.
في حين أن المجموعات المتفائلة تتصدر حاليًا بسبب التوافق الأفضل والحدود المنخفضة، فقد تهيمن مجموعات المعرفة الصفرية في النهاية بسبب الأداء المتفوق والتخصيص.
يقارن هذا المقال L3 وL2 بالنسبة لـ RaaS و RaaS مقابل app chains، مشيرًا إلى أن RaaS قد توفر قابلية تشغيل بيني وأمان أفضل إذا تم بناء نظام بيئي قوي.
يحلل هذا المقال مشاريع RaaS مختلفة لتحديد أكثر المقاربات وعدًا. يغطي مشاريع قائمة على ZK (مثل StarkWare وOpside)، ومشاريع قائمة على التفاؤل (مثل Caldera)، وحلول Blockchain نمطية/وحداتية (مثل Celestia).
1. مقدمة عن RaaS
1.1 Rollup: حل التوسع الأكثر وعدًا
كانت النية الأولى لـ Layer 2 هي تخفيف مشكلة ازدحام الشبكة الرئيسية وتقديم خدمات لـ Dapps بتكاليف أقل وTPS أعلى مع ضمان الأمان. يقوم rollup بتنفيذ تنفيذ معاملات عالي التكلفة على L2 ويقوم بتجميع المعاملات على L1 للتحقق مع ضمان إمكانية التحقق من محتوى المعاملة الكامل. وضمن افتراض وراثة أمان Ethereum، فإنه يملك أداءً شاملاً أقوى. لذلك، خرج rollup إلى الواجهة ضمن مختلف حلول Layer 2، وهو بالتأكيد حل التوسع خارج السلسلة (off-chain) الأكثر وعدًا حاليًا.
1.2 Rollup-as-a-service: شكل من أشكال السلسلة الخاصة بالتطبيق (App-specific chain)
مع النمو التدريجي لبعض الـ Dapps وتوسع تطبيقات جديدة متعددة، لا يمكن لـ rollup كحل توسع عام أن يلبّي تمامًا سعي هذه المشاريع وراء تجربة المستخدم وهيكل التكلفة. فالمتطلبات العالية للزيارات والأداء (مثل ألعاب AAA التي تركز على تفاعل اللاعبين) تجعل هذه التطبيقات تحتاج حلول قابلية توسع أكثر تخصيصًا.
تُعد app-specific chain واحدة من أفضل حلول هذه الـ Dapps.
مفهوم app chain ليس غريبًا. يمكن للمشاريع المختلفة تخصيص تصميم البلوك تشين وفق سيناريوهات التطبيق واحتياجاتها، مما يتيح لـ Dapps الاستفادة من موارد السلسلة بشكل حصري. وفي الوقت نفسه، مع الحفاظ على عدم الانفصال عن الأنظمة البيئية الأخرى، يمكنهم تحقيق تكاليف تشغيل أقل وأداء أعلى، ما يوفر تجربة مستخدم أفضل.
على سبيل المثال، يقدم Cosmos، المبني على إجماع Tendermint، لـ Dapps بيئة منخفضة التكلفة لبناء سلسلة عامة L1 مستقلة بالسيادة. وفي الوقت نفسه، وبناءً على بروتوكول اتصال IBC، يمكن لسلاسل تطبيقات مختلفة أن تحقق أصول/معلومات عبر السلاسل بشكل أسهل. يمكنك الرجوع إلى دورة حياة حزمة IBC المقدمة من Cosmos رسميًا👇

الحديث عن قابلية التوسع دون أخذ النظام البيئي في الاعتبار يعد بلا معنى.
إن قابلية تطبيق حل App chain تعتمد بالتأكيد على قابلية تشغيل بيني قوية ودعم بيئي. على سبيل المثال، يعمل Cosmos تدريجيًا على تحسين نظامه البيئي الخاص عبر سلسلة عامة L1 مستقلة ومزايا عبر السلاسل الناتجة عن IBC داخل النظام البيئي.
استنادًا إلى الفهم أعلاه، هناك فكرة أخرى حول app-specific chain وهي تحقيق سعي الـ Dapp للوظائف المخصصة والأداء العالي والتكلفة المنخفضة عبر roll-up مخصص. ويمكن لبعض حلول RaaS المبنية على شبكة من الطبقة الثانية أيضًا جعل تفاعل المشروع أكثر سهولة، ولها تأثير إيجابي على تخطيط النظام البيئي.
2. قيمة RaaS
يبدو أن اتجاه تعدد السلاسل وrollups في عالم العملات المشفرة أمر لا مفر منه. إن ظهور مشاريع RaaS مثل spring bamboo shoots وضع أساسًا لتطوير أشكال جديدة من الـ Dapp. لكن ضمن هذا الإجماع، ما زلت أريد طرح سؤال واقعي في الاتجاه المعاكس:
في الواقع، من المغري السماح لأي شخص بإطلاق rollup بسرعة، لكن إلى جانب كونها في الاتجاه الصحيح ومثيرة للإعجاب، هل تُنشئ بالفعل قيمة كافية لمن هم بحاجة إليها؟ يمكن تقسيم هذا السؤال إلى نقطتين:
هل توجد مشاريع كافية في السوق لديها دافع كافٍ لاستخدام RaaS؛
هل أنشأ RaaS قيمة معتبرة للأطراف المعنية في المشروع؟
تتمحور هذه القضية بشكل أساسي حول الطلب والقيمة التي يجلبها RaaS. إذ إن وجود مشاريع كافية يعني وجود طلب، أو أن RaaS يمكنه تقديم تحسينات جذابة.
من ناحية الطلب، مع استمرار نمو بعض الـ Dapps، فإن الأطراف المعنية تحتاج بالفعل بشكل عاجل إلى البحث عن:
تكلفة أقل
أداء أعلى
دوال خاصة
التكلفة
بالاستناد إلى البيانات المقدمة من L2fees، حقق rollup على L2 أقصى مستوى من تحسين التكلفة، وهو تحسن كبير مقارنة بشبكة Ethereum الرئيسية. وعند النظر مرة أخرى إلى بيانات اختبار RaaS الخاصة بـ Caldera Chains، لا يوجد تغيير نوعي في التكلفة، بل أقرب إلى تحسين بنسبة 99–100. وفي الوقت نفسه، فإن تنفيذ EIP4844 و danksharding سيخفض تكلفة rollup على L2 أكثر، وستتقلص كذلك الفروقات التي يجلبها RaaS في التكلفة والكفاءة.
يُعد الحل الذي يمكنه تقليل رسوم المعاملة بشكل كبير خيارًا جذابًا، لكن معظم حلول RaaS لا يمكنها القيام بذلك. وبالنظر إلى تكاليف الهجرة، والإيكولوجيا الإجمالية، وقابلية التشغيل البيني، والأمان، وغيرها، فهل لدى الأطراف المعنية دافع كافٍ فعلًا لاستخدام RaaS؟ بالنسبة لمعظم الـ Dapps التقليدية أو المستخدمين الذين لا يكونون شديدي الحساسية للأداء والتكلفة، ربما تكون عملية التوسع العامة للأغراض كافية.


الأداء
تتمتع rollup التابعة لـ L2 بالفعل بالقدرة على توفير TPS فائق الارتفاع. بالاستناد إلى البيانات المقدمة من Caldera، فإن RaaS المبني على Op لا يملك تقريبًا أي ميزة في زمن الكتلة. وعلى الرغم من أن ZK RaaS يمكنه توفير تخزين بيانات وضغط أكثر تخصيصًا، إلا أنه لا يوجد طلب كبير على خدمات من هذا النوع. يمكن لـ RaaS المبني على شبكة من الطبقة الثانية أن يحقق فعليًا سرعة أسرع وتكلفة أقل عبر تسوية المعاملات على L2، وبالتالي تحسين تجربة المستخدم.
كما ذُكر أعلاه، في مواجهة نظام بيئي غير كامل وتكاليف أخرى للهجرة/التطوير، هل ما زال لدى الأطراف المعنية في المشروع دافع كافٍ لاستخدام RaaS؟

ميزات مخصصة
من حيث خلق القيمة، يمكن لبعض حلول RaaS بالفعل تقديم ميزات يصعب تنفيذها حاليًا أو تصاميم تكون غير كفؤة ضمن التوسع العام للأغراض. على سبيل المثال:
العنصر الأول في تصميم دائرة ZK للـ L2 هو التوافق، من أجل خدمة جميع الـ Dapps، فإن تصميم الدائرة يضحّي بالكفاءة إلى حد ما ولا يقوم بتحسين مخصص لـ Dapps بعينها. ويمكن إظهار قيمة RaaS بوضوح: تخصيص تصميم دائرة ZK لـ Dapps محددة، أو توفير هياكل تخزين أكثر كفاءة وخدمات ضغط بيانات لتحقيق أداء أعلى؛
تنفيذ وظائف الخصوصية. بالرغم من أن ZK rollup مناسب للخصوصية، إلا أنه وبسبب اعتبارات اللامركزية والأمان، لا تزال بيانات معاملات المستخدمين تحتاج إلى النشر على L1 كسجل تاريخي بعد الضغط، ما يتيح لجميع المستخدمين التحقق. لذلك، لا يمكن لعمليات التوسع العام للأغراض الحالية تحقيق الخصوصية. يمكن لـ RaaS تخصيص تنفيذ وظائف الخصوصية استنادًا إلى rollup أو حتى rollup of rollup، ما يخلق قيمة للمشاريع التي لديها متطلبات خصوصية قوية.
لذلك، فإن القيمة الحالية لـ RaaS هي التخصيص > التكلفة والكفاءة الصرفتان. (دون استبعاد تحسينات التكلفة والكفاءة الناتجة عن التخصيص)
للإجابة عن السؤال الأولي: هل يُنشئ RaaS بالفعل قيمة كافية للأشخاص الذين هم في حاجة إليها؟
أعتقد أن الطلب الحالي على RaaS محدود، ويمكن للتوسع العام للأغراض تلبية أكثر من 90% من الاحتياجات. وعلى الرغم من أن rollups المخصصة بدأت تلعب دورًا لا يمكن الاستغناء عنه في بعض المجالات المتخصصة، إلا أنها ليست شائعة في السوق. القيمة التي يخلقها RaaS محدودة وتحتاج إلى مزيد من الاستكشاف مع مراعاة النظام البيئي وقابلية التشغيل البيني وغيرها من العوامل الشاملة.
3. استكشاف الشكل النهائي لـ RaaS
منذ ظهور L2 rollup، لم يتوقف استكشاف RaaS، وظهرت حتى الآن على السوق حلول تنفيذ متعددة لـ Rollup-as-a-service. وبالاستناد إلى تخطيط النظام البيئي على Messari، يمكنك رؤية مسارات تنفيذ RaaS المختلفة بشكل تقريبي. لذا فإن الأسئلة المحورية هي:
ما الحلول التي تبدو منطقية؟
ما نوع RaaS الذي سيفوز في النهاية بالسوق؟

3.1 OP أم ZK؟
إن النقاش حول التفاؤل (Optimistic) أو المعرفة الصفرية (zero knowledge) لم يتوقف أبدًا. فحتى لو كان ZKrollup نظريًا يقدم أداءً أقوى، وزمن نهائية أسرع بكثير من optimistic rollup، وأمانًا أعلى، فإن optimistic rollup يتمتع بتوافق أفضل وعتبة أقل.
في مشاريع RaaS الحالية، تعتمد معظم المشاريع أساسًا على optimistic rollups. وأرى أن الأسباب الرئيسية هي:
يأتي النظام البيئي دائمًا أولًا. يتمتع RaaS المبني على optimistic بتوافق أفضل، ما يقلل بشكل كبير عتبة انتقال/تطوير الأطراف المعنية، ويسمح بمزيد من الأطراف المعنية بالنشر بسرعة وبناء نظام بيئي أكثر ازدهارًا بسرعة، والاستفادة من ميزة السبق إلى السوق (first-mover advantage).
خفض العتبة، وغير معتمد على دعم قدرات الحوسبة. يعتمد RaaS على التفاؤل (Optimistic) أيضًا في التحقق من صحة المعاملات عبر إثباتات احتيال، لذلك تكون متطلبات أداء الآلة والاحتياطيات أقل من حيث قوة الحوسبة. كما يُعد هذا عاملًا مُقيِّدًا لعدد كبير من حلول RaaS التي لا يمكنها البدء باستخدام ZK**.
أسهل في التوسع. إن عتبة تطوير RaaS المبني على التفاؤل أقل، بخلاف ZK RaaS الذي يسعى إلى الأداء وإلى قدر أكبر من التخصيص الأساسي، ما يتطلب من مقدمي الخدمة المشاركة بعمق في التطوير. وفي الوقت نفسه، وبسبب محدودية قدرة الحوسبة اللازمة لإنشاء ZKP، يصبح من الصعب نشر ZK RaaS على نطاق واسع مثل RaaS التفاؤلي.
على الرغم من أن optimistic rollup لديه مزايا واضحة في التخطيط البيئي (ecological layout)، إلا أن RaaS المبني على ZK لديه أيضًا مزايا واضحة.
تخصيص حقيقي، أداء أفضل، وتكلفة أقل. في تصميم تخصيص rollup، يمكن لـ RaaS المبني على ZK أن يوفر قيمة أكبر للمشروع من حيث الوظائف والأداء، وهي صعوبة تحقيقها عبر التوسع العام للأغراض. ويمكن اعتباره تحولًا من 0 إلى 1. بينما يركز RaaS المبني على التفاؤل أكثر على إجراء تغييرات من 90 إلى 99 من حيث التكلفة والكفاءة.
أمان أعلى. يمكن لـ ZK’s RaaS أن يكون بلا ثقة، بينما الخدمات المبنية على op تتطلب الثقة في الـ challenger للعمل بشكل طبيعي ومنع sequencer من التصرف بشكل شرير.
قابلية تشغيل بيني أفضل وزمن نهائية. يحتاج RaaS المبني على OP إلى إجراء تحقق fraud-proof لمدة 7 أيام، بينما يمنح ميزة “بلا ثقة” في ZK وقت نهائية أسرع، وفترة تحقق 7 أيام تجعل OP-RaaS يواجه تحديات في بناء cross-rollup.
ملخص
على المدى القصير، ميزة النظام البيئي لـ RaaS المبني على التفاؤل لا يمكن زعزعتها، لكن من منظور الطلب طويل الأجل وإنشاء القيمة، أعتقد أن RaaS المبني على ZK من المرجح أن يحصل على حصة أكبر في السوق مستقبلًا.
3.2 الطبقة 2 أم الطبقة 3؟
اعتمادًا على حالات الاستخدام وأهداف التنفيذ المختلفة لـ RaaS، يجب اختيار خطة التنفيذ الأكثر ملاءمة. وفي رأيي، يكمن أكبر اختلاف في التكلفة وتجربة المستخدم (قابلية التشغيل البيني).
من خلال اعتبار Layer 2 (L2) طبقة التسوية وترتيب RaaS كـ Layer 3 (L3)، يمكن تحقيق تكاليف معاملات أقل وتفاعلات أسرع عبر rollups، وبالتالي تحسين تجربة المستخدم الشاملة. وعلى الرغم من أن L2 RaaS المبني على Ethereum ورث بنجاح أمان الشبكة الرئيسية، إلا أن تكلفة وسرعة الاتصالات عبر السلاسل أقل بكثير من تصاميم الشبكات متعددة الطبقات.
لذلك، L3 > L2
لمزيد من المعلومات حول Layer 3، يمكنك الرجوع إلى مقال كتبته سابقًا:
Foresight Ventures: شرح متعمق للطبقة 3
3.3 RaaS أم L1 app chain: موازنة بين النظام البيئي والتكلفة
كان Cosmos وPolkadot من أوائل من اقترحوا حل app-specific chain. إذن، بين app-specific chain وRaaS، أيهما أكثر ملاءمة لتقديم خدمات مخصصة لـ dapps؟

قابلية التشغيل البيني
بالنسبة لسلاسل تطبيقات L1 (App chains)، بالإضافة إلى نظام Cosmos البيئي المبني على بروتوكول الاتصالات IBC المذكور في القسم الأول، يمكن للتطبيقات إنشاء parachains على Polkadot وإجراء تبادل معلومات عبر السلاسل بناءً على XCM. ومع ذلك، وبسبب اعتبارات الأمان والتكلفة، نرى في التطبيقات الفعلية أن معظم المشاريع تعتمد فقط على محرك إجماع Tendermint أو Substrate لتطوير سلاسل تطبيقات L1 مخصصة، ونادرًا ما تستخدم الاتصالات عبر السلاسل. وهذا يؤدي إلى قدر من الاستقلالية النسبية بين هذه النظم البيئية عبر السلاسل، ولا ينسجم ذلك، إلى حد ما، مع رؤيتي النهائية لـ app chain، حيث ينبغي أن تتشكل معًا منظومة مزدهرة مع قابلية قوية للتوافق البيني.
بالنسبة لبنى مثل StarkNet التي تُوسّع RaaS المبني على شبكات الطبقة 2 إلى ما هو أبعد، فإن لديها ميزة أكبر من حيث قابلية التشغيل البيني. يمكن لـ dapps مختلفة تحتفظ بـ rollups الخاصة بها أن تجري Cross-chains بتكلفة منخفضة، وبما أنها يمكن أن تستقر في شبكات الطبقة 2، فستكون السرعة وتجربة المستخدم أفضل. لكن جميع افتراضات قابلية التشغيل البيني هذه مبنية على أن يكون RaaS قادرًا على بناء نظام بيئي قوي بدرجة كافية.
الأمان
اعتمادًا على تصميم RaaS، فإن DA المبني على RaaS الخاص بـ Ethereum يرث غالبًا مكافئ أمان Ethereum على مستوى L1، وهو أعلى من مستوى الأمان واللامركزية لـ L1 app chains. أما بالنسبة لـ RaaS المبني على طبقة DA أو على سلسلة جانبية، فإن الأمان مضمون عبر شبكات الطبقة 2 هذه.
التكلفة
بالنسبة لسلاسل app الخاصة بـ L1، تتقارب تكاليف المعاملات مع الرمز المميز الأصلي الخاص بمشروع الـ dapp نفسه، ما يتيح تكاليف تشغيل منخفضة للغاية؛
بالنسبة لـ RaaS، فإن L2 RaaS تكون بتكلفة أعلى نسبيًا لأنها تحتاج إلى التفاعل مباشرة مع شبكة Ethereum الرئيسية، بينما يمكن لـ L3 RaaS المبني على Polygon وStarkNet وغيرها أن يُسوي على L2، وبالتالي تكون تكاليفه أقل نسبيًا.
4. تحليل مشاريع RaaS: من سيفوز في سوق RaaS
هناك العديد من مشاريع RaaS يجري تطويرها حاليًا أو تم نشر بعضها بالفعل، بما في ذلك على سبيل المثال لا الحصر StarkNet L3 وOpside وCaldera وCelestia وDymension وSovereign وStackr وEclipse وAltlayer وSaga…
فيما يلي بعض الأمثلة التمثيلية للتحليل.
4.1 سلسلة ZK
بما في ذلك على سبيل المثال لا الحصر Sovereign Labs وFractal وStarkNet وOpside وZKsync
StarkWare: L3 مخصص مبني على ZKRollup
بالرجوع إلى الرسم القديم، اقترح فريق StarkWare أولًا تصميم شبكة Ethereum متعددة الطبقات في المقالة “Fractal Scaling: From L2 to L3”. ومع ذلك، فإن إدخال الشبكات متعددة الطبقات ليس فقط لمزيد من التوسع، بل أكثر لإتاحة لمالكي المشاريع التحكم في المزيد من موارد السلاسل عبر تكديس rollups مخصصة بناءً على أساس التوسع العام للأغراض على L2، وتوفير تجربة مستخدم لا يمكن لـ L2 rollup الوصول إليها.
على الرغم من أنه من منظور حوسبي يمكن توليد ZKP لإثبات صحة مجموعة من ZKPs، إلا أن البيانات لا يمكن ضغطها ثم ضغطها بشكل أكبر. وبسبب ضرورة ضمان توفر البيانات، بحيث يمكن لأي شخص التحقق من صحة الدليل، يحتاج الـ rollup إلى إرسال المحتوى الكامل أو المضغوط للمعاملات إلى L1.
لذلك، يجب أن تكون سيناريوهات تطبيق StarkWare’s app-specific chain تسعى إلى أداء مرتفع أو إلى ميزات محددة.
أداء عالٍ: يمكن للألعاب التي تتطلب أداءً مرتفعًا استخدام موارد دوائر ZK حصريًا لتوفير تجربة مستخدم أفضل؛
الخصوصية: بالنسبة لبعض المشاريع التي لديها متطلبات خصوصية، يمكن تنفيذ وظائف الخصوصية على نحو مخصص فوق rollup أو rollup of rollup؛
توسيع التوافق: إن توفير بيئة متوافقة مع EVM، أو حتى التوافق مع لغات برمجة أكثر، يجلب قيمة إيجابية للنظام البيئي نفسه؛
تكلفة منخفضة: تقليل كبير لتكاليف التشغيل عبر التضحية بدرجة معينة من اللامركزية والأمان من خلال Validium.
يمكن لحل L3 المبني على Validium الخاص بـ StarkNet نظريًا أن يقلل التكاليف بشكل حدسي، كما أن قابلية التشغيل البيني مضمونة أيضًا.
ومع ذلك، ومن منظور التخصيص، يمكن الاستدلال أيضًا أن app-specific chain المبنية على ZKrollup، رغم أنها توفر تحسينًا كبيرًا في الأداء، فإنها ترفع كذلك تكلفة التطوير وعتبة مشاركة الأطراف المعنية بالمشروع. لذلك، يحتاج مقدمو RaaS إلى المشاركة بعمق في التطوير، كما أن سرعة وتيرة التوسع في مسار التحول التجاري محدودة.
Opside: بنية شبكة ثلاثية الطبقات أخرى مصممة لسلاسل التطبيقات الخاصة (App-specific chains)
بالرجوع إلى المخطط أدناه، وبالمقارنة مع StarkWare، فإن تصميم Opside للـ L3 الخاص به المعتمد على rollup قائم على ZK من ناحية App-specific، يقترح شبكة ثلاثية الطبقات مُصممة خصيصًا لتطبيقات ذات TPS مرتفع. إذ يقوم بتصميم سلسلة جانبية كـ L2 استنادًا إلى إجماع PoS+PoW، ويربط السلسلة الخاصة بالتطبيق كـ L3 بهذه السلسلة الجانبية.

تتفاعل Opside مع البيانات عبر جسر ZK الذي طورته، وبدلًا من التوقيع متعدد الأطراف (multi-signing)، يتم إكمال إثبات صحة/مشروعية المعاملات عبر zkp، وبالتالي تكون لديها أمان أعلى. وفي الوقت نفسه، تقوم Opside بدمج rollup الخاص بالتطبيق داخل إجماع سلسلة جانبية L2 عبر rollup أصلي (native rollup)، أي أنها تدفع أطرافًا ثالثة إلى الحفاظ على rollup على سلسلة جانبية L2 من منظور الإجماع.
تُعد قابلية التشغيل البيني أمرًا حاسمًا بالنسبة لـ RaaS، وتشترك rollups الأصلية في Opside في شجرة حالة عالمية (world state tree) وقائمة انتظار رسائل عالمية (global message queue). لذلك ستكون تفاعلات الأصول والمعلومات بين rollups الخاصة بكل تطبيق فعالة جدًا وتكلف أقل. إن تفاعل الأصول عبر السلاسل يحتاج فقط إلى استدعاء مباشرة طريقة عقد rollup المستهدفة داخل عقد L3 rollup. ومع ذلك، لا تزال قابلية التوافق وتطوير النظام البيئي تحديًا لـ rollups القائمة على ZK.
المقايضة التي يجلبها نهج ZK من حيث الثقة المعدومة (Trustless) وزمن نهائية أسرع، هي أن الحجم التجاري لـ RaaS محدود بقدرة الحوسبة، ويتطلب دعم عتاديًا لإنشاء ZKP، وهو أيضًا أحد الأسباب التي تجعل معظم حلول RaaS لا تعتمد ZK. بالإضافة إلى ذلك، فإن تصميم السلسلة الجانبية كـ L2 يفرض تحديًا على أمن مقدمي RaaS.
4.2 سلسلة التفاؤل (Optimistic)
بما في ذلك على سبيل المثال لا الحصر Caldera وEclipse
Caldera: تعظيم تجربة المستخدم بناءً على Op Stack
Caldera هي RaaS مبنية على Op stack، وتوفر لفِرق المشاريع إنتاجية عالية وزمن استجابة منخفض وميزات وظيفية قابلة للتخصيص لـ L2 rollup. تتيح شبكتها التجريبية الحالية لأي شخص إنشاء L2 rollup في وقت قصير جدًا. تجربة المستخدم سلسة جدًا؛ يمكنك تجربتها هنا: https://dashboard.caldera.xyz/

يمنح التصميم المبني على Op stack لـ Caldera ميزة كبيرة في التوافق. مع التوافق الكامل مع EVM وتحسينات الفريق لتجربة المستخدم، فإنه يقلل بشكل كبير من عتبات الهجرة/التطوير. كذلك، لا يقتصر RaaS لدى Caldera على قدرات الحوسبة للعُتاد الأساسي، ما يتيح لفِرق مشاريع أكثر النشر بسرعة، وبالتالي بناء نظام بيئي أكثر ازدهارًا.
بالرجوع إلى الرسم البنيوي في التوثيق الرسمي لـ Caldera، يمكن لـ Caldera Chains أن لا تكتفي بإطلاق L2 rollup-as-a-service على Ethereum فحسب، بل توفر خدمات أيضًا على أي L1 متوافق مع EVM، مع ضمان صحة المعاملات عبر إرسال إثباتات احتيال إلى L1. وفي طبقة توفر البيانات، حققت Caldera أيضًا ابتكارات عبر فصل طبقة توفر البيانات (Data Availability Layer) عن طبقة التسوية (Settlement Layer). يمكن لـ rollups المخصصة إرسال محتوى المعاملات إلى Ethereum، أو إلى طبقة DA مخصصة مثل Eigenlayer أو Celestia. يصمم هذا النظام بشكل كبير تحسين قابلية توسع Caldera وتكاليف المعاملات.
يتم تحقيق قابلية التشغيل البيني لمنظومة Caldera عبر الجسر عبر السلاسل الداخلي. يتيح ذلك الأصول والبيانات عبر السلاسل عبر نشر عقود على L1 المقابل وعلى rollups الخاصة بكل تطبيق. وفي الوقت نفسه، توفر Caldera حزمة SDK عالية المستوى من نوع JavaScript لمساعدة المطورين على إضافة وظائف عبر السلاسل بشكل أكثر كفاءة داخل rollups مخصصة.

على الرغم من أن Caldera قامت بالكثير في قابلية التشغيل البيني والجسور عبر السلاسل، تتطلب optimistic rollups وقت fraud-proof لمدة 7 أيام، ما يجعل من الصعب بناء قابلية تشغيل بيني بين rollups. وفي الوقت نفسه، لا يمكن لـ optimistic RaaS تحقيق الثقة المعدومة؛ يجب الوثوق بوجود challenger واحد على الأقل لمنع sequencer من إساءة السلوك.
بالإضافة إلى ذلك، في جانب التخصيص، تركز Caldera وغيرها من حلول Optimistic RaaS أكثر على التكلفة المنخفضة وTPS العالي، ومن الصعب تقديم قيمة كبيرة في الوظائف والأداء للمشاريع مقارنةً بـ ZK-based RaaS. وعند النظر إلى rollups التوسع العام للأغراض الحالية، يمكنها تحقيق زمن كتلة وtps وتكاليف معاملات معتبرة. والبيانات وRaaS ليستا مختلفتين بشكل كبير، ما يشير إلى تحسن من 0 إلى 1. لذلك، يستحق التساؤل عما إذا كانت تحسينات التكلفة والسعة التي يقدمها RaaS المبني على Op هي ما يحتاجه السوق الحالي بالفعل.
4.3 البلوك تشين المُقسّم إلى وحدات (Modular Blockchain)
بما في ذلك على سبيل المثال لا الحصر Celestia وDymension
Celestia: بناء بلوك تشين مُقسّم إلى وحدات استنادًا إلى طبقة DA
Celestia هي في الأساس طبقة توفر البيانات (data availability). تم بناء بنية هرمية لسلسلة بلوك قابلة للتوسع على طبقة DA استنادًا إلى إجماع Tendermint. ومن خلال rollmint (وهو نوع من تنفيذ واجهة بلوكتشين تطبيقية)، يمكن للـ dapps إنشاء rollup الخاص بها ونشره على Celestia، حيث تُخزَّن البيانات في طبقة DA ويتم رفع جذر الحالة والدليل إلى L1 للتحقق. تقوم Celestia بتحسين طبقة DA عبر أخذ عينات توفر البيانات (DAS)، حيث يحتاج كل عقدة خفيفة (light node) في الشبكة إلى أخذ عينة وتنزيل جزء صغير فقط من بيانات الكتل. لذا كلما زاد عدد العقد، زاد عدد المعاملات التي يمكن أن تحتويها كل كتلة، محققًا بذلك هدف توسيع طبقة DA.

يجلب هذا إلى الذهن Validiums المألوفة: حل توسع يتحقق من نتائج الحوسبة عبر خوارزميات ZK، ولا يرفع البيانات إلى L1، ويعتمد على المدققين لحراسة البيانات. وبما أن البيانات موجودة خارج السلسلة (off-chain) بدلًا من نشرها مباشرة على Layer 1، فإن Validium يقلل تكاليف الغاز. لكن من منظور اللامركزية والأمان، تعتمد Data Availability على لجنة طرف ثالث، لذا لا تُستخدم Validiums على نطاق واسع.
من منظور التنفيذ، فإن الـ dapps في المنظومة كاملة تقوم فعليًا ببناء Validium الخاص بها، والحفاظ على sequencer وprover، بينما توفر Celestia مساحة موحدة لتخزين البيانات. وبالطريقة نفسها تقريبًا التي تعمل بها Validiums، يقلل أسلوب التنفيذ هذا من تكلفة تشغيل الـ dapps، لكنه أيضًا يُضحّي بدرجة معينة من اللامركزية والأمان. وبالمقارنة مع الحلول الأخرى التي ترث أمان Ethereum، فإن أمان سلاسل الـ dapp على Celestia يعتمد على العقد وطبقة DA.
بالإضافة إلى ذلك، لا تدعم Celestia حاليًا fraud-proof. لذلك، يتعين على العقد إعادة تنفيذ جميع المعاملات وفق افتراض متشائم لضمان صحتها. وفي الوقت نفسه، يدعم rollmint sequencer واحدًا فقط، ما يترك مساحة كبيرة للتحسين من حيث الكفاءة واللامركزية.
لكن، وباعتبار Celestia طبقة DA، فإن إمكاناتها تمتد بكثير إلى ما هو أبعد من ذلك. على سبيل المثال، تستخدم حل RaaS التفاؤلي Eclipse Celestia كطبقة إجماع وDA.
5. الخلاصة والتطلع
يمكن لـ RaaS أن يجلب تحسينات في التكلفة والأداء بشكل بديهي، لكن استنادًا إلى الأداء وحده، فإن هذه التحسينات لا تتمتع بجاذبية قوية؛ وتظل القيمة الأكبر مرتبطة بالميزات المخصصة. إن الطلب في السوق حاليًا محدود، لكن مع تطور العملات المشفرة في المستقبل، ستؤدي الزيارات/الحركة الأكبر إلى زيادة خطية في سعي dapp نحو التكلفة المنخفضة والأداء المرتفع، وستكون خدمات rollup المخصصة بالتأكيد حلًا قابلًا للحياة.
للإجابة عن السؤال الذي طُرح في البداية تمامًا: ما فهمي للشكل النهائي لـ RaaS؟ وما نوع RaaS الذي سيلتقط السوق؟
من جهة المنتج نفسه
تتمثل ميزة RaaS القائمة على OP في بناء نظام بيئي بسرعة وتكوين حواجز، لكن التحسينات الصغيرة الناتجة فقط من التكلفة والكفاءة لا تكفي لجذب المشاريع، وبالتالي لا توجد قيمة طويلة الأجل. من ناحية أخرى، يمكن لـ RaaS المبني على ZK معالجة نقاط الألم بميزات مخصصة، لكن الطلب ما زال غير سائد.
يُمكّن تصميم بنية شبكة متعددة الطبقات لـ L3 RaaS من تحقيق تكاليف أقل وقابلية تشغيل بيني أقوى. علاوة على ذلك، فإن التشغيل البيني القوي هو أساس بناء نظام بيئي مزدهر لـ RaaS. لذا يمكن لتصميم شبكة متعددة الطبقات قائم على ZK أن يجمع بين مزايا التخصيص والتكلفة المنخفضة، ويمكننا أن نرى قيمته على المدى الأطول.
أعتقد أنه على المدى الطويل، ستصبح RaaS لشبكة متعددة الطبقات مبنية على ZK هي الاختيار النهائي للسوق.
السوق والطلب
يمكن لـ RaaS ذات قابلية توسع كافية تلبية احتياجات جميع المشاريع لعمل rollups مخصصة مع ضمان الأداء. وفي الوقت نفسه، فإن الارتفاع الحقيقي لـ RaaS يعتمد بشدة على بناء النظام البيئي. لذلك، فإن نمط تواجد عدة حلول RaaS معًا لا يبدو منطقيًا بوضوح.
أعتقد أن النتيجة النهائية بالتأكيد ستكون وجود واحد أو عدد قليل من حلول RaaS يهيمن على السوق بالكامل.
مراجع
https://ethresear.ch/t/rollup-as-a-service-opportunities-and-challenges/13051
https://ibcprotocol.org/
https://messari.io/report/the-rollups-as-a-service-ecosystem
حول Foresight Ventures
تكرّس Foresight Ventures لدعم الابتكار التخريبي في تقنية البلوك تشين خلال العقود القليلة القادمة. نحن ندير عدة صناديق: صندوق VC، وصندوق ثانوي مُدار بنشاط، وFOF متعدد الاستراتيجيات، وصندوق ثانوي في السوق الخاص، بإجمالي أصول تحت الإدارة AUM يتجاوز 400 مليون دولار. تلتزم Foresight Ventures بمعتقد “عقلية مميزة، مستقلة، هجومية، وطويلة الأجل” وتوفر دعمًا واسعًا لشركات محفظتها ضمن نظام بيئي متنامٍ. يتكوّن فريقنا من مخضرمين من شركات مالية وتقنية رائدة مثل Sequoia Capital وCICC وGoogle وBitmain وغيرها الكثير.
الموقع الإلكتروني: https://www.foresightventures.com/
إخلاء مسؤولية: لا تهدف جميع المقالات التي تنشرها Foresight Ventures إلى تقديم نصيحة استثمارية. ينبغي على الأفراد تقييم تحملهم للمخاطر واتخاذ قرارات استثمارية بشكل حكيم.