Rollups القابلة للبرمجة

ما هي Rollups القابلة للبرمجة؟

Rollups القابلة للبرمجة هي بيئات بلوكشين قابلة للتخصيص من Layer 2 أو Layer 3، تتيح للمطورين تحديد آلية التنفيذ والرسوم والحوكمة وتوافر البيانات والتسوية والترتيب ومنطق التطبيقات.

في عالم العملات المشفرة، يُستخدم المصطلح عادةً للإشارة إلى Rollups التي لا تقتصر على كونها شبكات توسّع عامة، بل هي بلوكشينات قابلة للتهيئة والتخصيص لتناسب تطبيقًا أو منظومة أو نموذج أعمال محددًا.

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

أما المطور، فيمكنه فهمه على أنه بنية rollup يمكن برمجة القواعد المهمة على مستوى السلسلة فيها بدلًا من أن تفرضها بالكامل شبكة عامة مشتركة.

توضح وثائق Ethereum حول Optimistic Rollups أن هذه الحلول تنفذ المعاملات خارج السلسلة، ثم تنشر بيانات المعاملات على Ethereum بصيغة calldata أو blobs.

وتصف وثائق OP Stack هذا المكوّن بأنه بنية rollup معيارية مفتوحة المصدر من Ethereum Layer 2، تضم مكونات مثل العقود الذكية لـ L1، وأدوات الترتيب وتجميع الدفعات وتقديم المقترحات والاعتراض.

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

لذلك فهي مهمة في مجالات DeFi والألعاب والمدفوعات والهوية والأصول الحقيقية وأنظمة المؤسسات والتطبيقات الاجتماعية وappchains ومنتجات العملات المشفرة الاستهلاكية عالية الإنتاجية.

وأبسط طريقة لفهم Rollups القابلة للبرمجة أنها Rollups يستطيع المطورون تخصيصها بدرجة كبيرة، بدلًا من الاكتفاء بنشر عقود ذكية على سلسلة مشتركة يملكها طرف آخر.

أهمية Rollups القابلة للبرمجة

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

فالعقد الذكي على سلسلة مشتركة يخضع لوقت إنشاء الكتل ورمز الغاز وسوق الرسوم وترتيب المعاملات والآلة الافتراضية وحدود الحوكمة وظروف الازدحام الخاصة بتلك السلسلة.

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

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

وبدلًا من منافسة كل تطبيق آخر على شبكة مشتركة واحدة، يمكن للمشروع تشغيل بيئة التنفيذ الخاصة به.

وقد يحسّن ذلك الأداء وتجربة المستخدم.

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

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

يتيح هذا التصميم المعياري للمطورين الجمع بين مكونات البنية التحتية المختلفة بدلًا من قبول تصميم سلسلة واحدة متكاملة.

أبرز مزاياها المرونة، أما التحدي الرئيسي فهو التعقيد.

آلية عمل Rollups القابلة للبرمجة

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

يرسل المستخدمون المعاملات إلى rollup بدلًا من إرسالها مباشرةً إلى الطبقة الأساسية.

يرتب sequencer المعاملات وينشئ كتل rollup أو دفعات منها.

تعالج بيئة التنفيذ في rollup المعاملات وتحدّث حالته.

ثم تنشر خدمة تجميع الدفعات أو النشر بيانات المعاملات أو الالتزامات إلى طبقة لتوافر البيانات أو للتسوية.

وقد ينشر مقدم المقترحات جذور الحالة إلى طبقة التسوية.

ويمكن للمتحدي أو أداة الإثبات المساعدة في التحقق من صحة انتقال الحالة.

في التصميم التفاؤلي، يمكن الاعتراض على انتقالات الحالة غير الصالحة عبر إثباتات الاحتيال خلال فترة الاعتراض.

أما في تصميم المعرفة الصفرية، فتُنشأ إثباتات الصلاحية لإثبات أن انتقال الحالة اتبع قواعد rollup.

ويكمن جانب البرمجة في إمكانية تهيئة الفرق لأجزاء رئيسية من هذا المسار أو استبدالها.

Rollups القابلة للبرمجة مقارنةً بـ Rollups التقليدية

تُصمم rollup التقليدية عادةً لتكون طبقة توسّع عامة تخدم تطبيقات متعددة.

قد تدعم العقود الذكية وتتيح للمطورين نشر التطبيقات، لكن مشغّل rollup أو نظام الحوكمة يحدد غالبية قواعد السلسلة.

أما rollup القابل للبرمجة، فيمنح المطورين تحكمًا مباشرًا أكبر في تصميم السلسلة، بما يشمل وحدات precompiles مخصصة، ومنطق الغاز، وتجريد الحسابات، والجسور، والأذونات، وخيارات توافر البيانات، وبيئات التنفيذ.

يمكن تشبيه Rollups التقليدية بمبنى سكني مشترك تعيش فيه تطبيقات عديدة وفق مجموعة واحدة من القواعد.

أما Rollups القابلة للبرمجة فتشبه مباني مخصصة صُممت لتلبية احتياجات تطبيق أو منظومة بعينها.

لكن هذا لا يعني أنها أفضل تلقائيًا.

قد تتمتع Rollups المشتركة بسيولة أقوى وأدوات أوسع ودعم أفضل للمحافظ وبنية تحتية أكثر اختبارًا وشبكات مستخدمين أكبر.

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

ويتوقف الاختيار على مدى حاجة التطبيق إلى بنية مخصصة تبرر التعقيد الإضافي.

Rollups القابلة للبرمجة مقارنةً بـ Appchains

ترتبط Rollups القابلة للبرمجة ارتباطًا وثيقًا بـ appchains، لكنهما ليسا الشيء نفسه دائمًا.

الـ appchain هي بلوكشين تُبنى لتطبيق أو منظومة محددة.

وقد يكون rollup القابل للبرمجة appchain إذا صُمم لتطبيق واحد واستخدم بنية Rollup.

يكمن الاختلاف في أن appchain قد تكون سلسلة Layer 1 لها مجموعة مدققين خاصة بها، في حين قد يعتمد rollup القابل للبرمجة على طبقة أخرى للتسوية أو توافر البيانات أو افتراضات الأمان.

يشرح شرح Celestia لـ sovereign rollups أن هذه الـ Rollups تنشر المعاملات على بلوكشين آخر لترتيبها وتوفير بياناتها، بينما تحدد عقدها الخاصة السلسلة الصحيحة.

وهذا يوضح اختلاف نماذج التسوية والتحقق في appchains القائمة على Rollups.

قد يعتمد rollup قائم على العقود الذكية على عقود طبقة التسوية للتحقق من صحة التنفيذ.

وقد يعتمد sovereign rollup بدرجة أكبر على عقده الخاصة وقواعد اختيار التفرع.

تقع Rollups القابلة للبرمجة ضمن هذا المجال التصميمي، إذ يستطيع المطورون اختيار نموذج الأمان والحوكمة الملائم لتطبيقهم.

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

Rollups القابلة للبرمجة مقارنةً بالعقود الذكية

العقد الذكي هو شيفرة تُنشر على بلوكشين قائم.

أما rollup القابل للبرمجة فهو بيئة شبيهة بالبلوكشين، يمكن تشغيل العقود الذكية أو منطق التطبيقات فيها وفق قواعد مخصصة للسلسلة.

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

لكن إطلاق rollup قابل للبرمجة يوفر إمكانات أكبر، إذ يتيح للمطور تخصيص بيئة السلسلة نفسها.

على سبيل المثال، يمكن للعبة نشر عقود ذكية على سلسلة مشتركة، لكنها ستضطر إلى قبول رسوم المعاملات والازدحام فيها.

ويمكن للعبة نفسها إطلاق rollup قابل للبرمجة برسوم أقل وقواعد مخصصة للمعاملات وغاز مدعوم ووحدات precompiles خاصة أو تجريد للحسابات مفعّل افتراضيًا.

وقد يجعل ذلك التطبيق أقرب في استخدامه إلى تطبيق ويب عادي.

لكن على فريق rollup عندئذ إدارة استمرارية عمل sequencer والجسور ونشر البيانات والترقيات والمراقبة وتهيئة المستخدمين.

إطلاق عقد ذكي أسهل، بينما يوفر rollup القابل للبرمجة تحكمًا معماريًا أكبر.

ينبغي للمطورين اختيار النموذج الأبسط ما لم تكن هناك حاجة فعلية إلى تخصيص السلسلة.

Rollups القابلة للبرمجة وبيئات التنفيذ

بيئة التنفيذ هي المكان الذي تُعالج فيه المعاملات ويعمل فيه منطق التطبيق.

تستخدم Rollups كثيرة بيئة تنفيذ متوافقة مع Ethereum، كي يتمكن المطورون من كتابة العقود الذكية بلغات مألوفة واستخدام الأدوات القائمة.

وقد تستخدم Rollups أخرى آلة افتراضية مختلفة أو بيئة تشغيل مخصصة أو WebAssembly أو منطق تنفيذ خاصًا بالتطبيق.

يوضح إعلان إطار Rollkit المعياري أن Rollkit يهدف إلى تمكين المطورين من تبديل بيئات التنفيذ وربط EVM أو CosmWasm أو خيارات أخرى.

وهذا أحد أوضح الأمثلة على قابلية البرمجة على مستوى بنية Rollup التحتية.

لم يعد المطورون محصورين في نشر العقود ضمن آلة افتراضية واحدة ثابتة.

بل يمكنهم تصميم طبقة التنفيذ بما يلائم احتياجات التطبيق.

قد يحتاج تطبيق DeFi إلى التوافق مع EVM للاستفادة من السيولة والأدوات.

وقد تحتاج اللعبة إلى بيئة تشغيل أسرع أو أكثر تخصصًا.

وقد يحتاج نظام الهوية إلى منطق تحقق مخصص مدمج في السلسلة.

Rollups القابلة للبرمجة وتوافر البيانات

يعني توافر البيانات إمكانية الوصول إلى بيانات المعاملات اللازمة للتحقق من حالة rollup أو إعادة بنائها.

وهذا أحد أهم خيارات التصميم في Rollups القابلة للبرمجة.

توضح وثائق Ethereum حول توافر البيانات ضرورة إتاحة مشغّلي Rollups لبيانات المعاملات كي يمكن التحقق من تغييرات الحالة بصورة مستقلة.

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

قد تنشر Rollups القابلة للبرمجة البيانات إلى طبقة تسوية أو طبقة مخصصة لتوافر البيانات أو blobs أو calldata أو نظام بيانات معياري آخر.

لكل خيار مفاضلات تتعلق بالتكلفة والأمان والاستمرارية والتحقق ودعم المنظومة.

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

وقد يعزز توافر البيانات القوي الأمان، لكنه قد يرفع التكاليف.

ينبغي للمطورين ألا يتعاملوا مع توافر البيانات على أنه تفصيل ثانوي.

فهو أحد أسس أمان Rollup.

Rollups القابلة للبرمجة والتسوية

التسوية هي العملية التي تحدد النهائية وحل النزاعات وأمان الجسر والحالة المقبولة لـ rollup.

تُسوى بعض Rollups القابلة للبرمجة على طبقة أساسية رئيسية عبر العقود الذكية.

وقد تتم التسوية في Rollups أخرى عبر عقد سيادية أو طبقات تسوية مشتركة أو أطر معيارية.

في rollup قائم على العقود الذكية، قد تتحقق طبقة التسوية من إثباتات الاحتيال أو إثباتات الصلاحية.

أما في sovereign rollup، فقد تحدد عقده الخاصة السلسلة الصحيحة بعد نشر البيانات في مكان آخر.

يؤثر نموذج التسوية في عمليات السحب وثقة الجسور والتحكم في الترقيات والنهائية وحماية المستخدم.

قد يوفر rollup ذو عقود التسوية القوية مسارات خروج أوضح وأقل اعتمادًا على الثقة.

وقد يمنح rollup ذو التسوية السيادية حرية حوكمة أكبر، مع افتراضات مختلفة للجسور.

على Rollups القابلة للبرمجة اختيار نموذج تسوية يتناسب مع احتياجاتها الأمنية.

ينبغي للمستخدمين إدراك أن Rollups قد تختلف في ضمانات التسوية حتى لو أُطلق عليها جميعًا اسم Rollups.

Rollups القابلة للبرمجة وSequencers

sequencer هو المكوّن الذي يرتب المعاملات وينشئ كتل Rollup أو دفعاتها.

ويُعد تصميم sequencer مجالًا رئيسيًا لقابلية البرمجة.

قد يبدأ rollup باستخدام sequencer مركزي واحد لتحقيق السرعة والبساطة.

وقد ينتقل لاحقًا إلى عدة أدوات ترتيب أو ترتيب مشترك أو لامركزي أو قائم على الطبقة الأساسية.

يمكن لـ sequencer مركزي توفير تأكيدات سريعة وتجربة استخدام سلسة.

لكنه قد يسبب مخاطر الرقابة والتوقف عن العمل وMEV والاعتماد على مشغّل واحد.

وقد يحسّن تصميم sequencer اللامركزي الحياد والمرونة.

لكنه قد يزيد التعقيد ويؤدي إلى تأخيرات في التنسيق.

تتيح Rollups القابلة للبرمجة للمشاريع اختيار قواعد الترتيب وفقًا لاحتياجاتها.

فقد تعطي لعبة عالية السرعة الأولوية لزمن الاستجابة المنخفض، بينما قد يعطي بروتوكول مالي الأولوية للترتيب العادل ومقاومة الرقابة.

Rollups القابلة للبرمجة وأنظمة الإثبات

تحدد أنظمة الإثبات كيفية إثبات صحة التنفيذ في rollup.

تفترض Optimistic Rollups صحة المعاملات ما لم يُعترض عليها بإثبات احتيال.

أما ZK Rollups فتُنشئ إثباتات صلاحية يمكن التحقق منها بواسطة عقد أو نظام تحقق.

تشير مواد إطار Rollkit المعياري إلى أهداف دعم أنظمة إثبات مختلفة، منها وضع zk والوضع التفاؤلي وأوضاع أخرى.

في Rollups القابلة للبرمجة، يؤثر اختيار الإثبات في التكلفة والنهائية وتجربة المطور ومتطلبات الأجهزة وافتراضات ثقة المستخدم.

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

قد توفر أنظمة ZK ضمانات فورية أقوى لصحة المعاملات، لكن إنشاء الإثباتات قد يكون معقدًا ومكلفًا.

وقد تختار بعض Rollups المخصصة للتطبيقات نماذج إثبات مختلفة حسب تعقيد المعاملات والاحتياجات الأمنية.

ينبغي للمستخدمين معرفة ما إذا كان rollup الذي يستخدمونه يعتمد على إثباتات الاحتيال أو إثباتات الصلاحية أو التحقق المصرح به أو نظام إثبات لا يزال قيد التطوير.

ولا تلغي قابلية البرمجة الحاجة إلى نموذج تحقق واضح.

Rollups القابلة للبرمجة وRollup-as-a-Service

Rollup-as-a-Service، أو RaaS، فئة من البنية التحتية تساعد الفرق على إطلاق Rollups مخصصة دون بناء كل مكوّن من الصفر.

يعرّف شرح Chainlink لخدمة Rollup-as-a-Service هذه الخدمة بأنها منصات نشر ومجموعات أدوات SDK تتيح للمطورين إطلاق بلوكشينات مخصصة للتطبيقات.

قد توفر منصات RaaS أدوات sequencer مُدارة وتكاملات لتوافر البيانات وأدوات الجسور والمراقبة وبنية العقد ومستكشفات الكتل ولوحات النشر.

وهذا يسهّل إطلاق Rollups القابلة للبرمجة.

لكنه يضيف اعتمادًا على مزوّد الخدمة.

إذا اعتمد المشروع بشدة على مزوّد مُدار، فقد يرث rollup مخاطر التوافر والتشغيل والمركزية المرتبطة بذلك المزوّد.

يمكن لـ RaaS تقليل حجم العمل الهندسي، لكنها لا تلغي الحاجة إلى مراجعة الأمان.

ينبغي للمطورين معرفة ما يديره المزوّد، وما يتحكم فيه المشروع، وكيفية إدارة المفاتيح والترقيات، وما الذي يحدث إذا توقف المزوّد عن العمل.

ينبغي للمستخدمين ألا يفترضوا أن rollup لامركزي لمجرد استخدامه تقنية Rollup.

فنموذج التشغيل مهم.

Rollups القابلة للبرمجة ورموز الغاز المخصصة

يمكن لبعض Rollups القابلة للبرمجة استخدام رموز غاز مخصصة.

يتيح رمز الغاز المخصص للمستخدمين دفع رسوم المعاملات بتوكن التطبيق نفسه أو بأصل آخر مختار، بدلًا من الأصل الأصلي للطبقة الأساسية.

قد يحسّن ذلك تجربة المستخدم، إذ قد لا يحتاج المستخدم إلى شراء رمز رسوم منفصل قبل استخدام التطبيق.

ويمكنه أيضًا دعم اقتصاديات توكن خاصة بالتطبيق.

على سبيل المثال، قد تستخدم لعبة توكنها الخاص لدفع رسوم المعاملات داخل اللعبة.

وقد تدعم Rollup للمدفوعات رسوم الغاز أو تجعل الرسوم غير ظاهرة للمستخدمين.

لكن رموز الغاز المخصصة تنطوي على مخاطر.

إذا كان رمز الغاز متقلبًا، فقد تصبح تكاليف الرسوم غير مستقرة.

وإذا كانت سيولته ضعيفة، فقد يواجه المستخدمون صعوبة في الدخول إلى المنظومة أو الخروج منها.

وإذا كان نموذج الرسوم مدعومًا، فيجب على Rollup توضيح الجهة التي ستتحمل تكاليف البنية التحتية بمرور الوقت.

تتيح رموز الغاز المخصصة إمكانات كبيرة، لكنها تحتاج إلى تصميم اقتصادي مستدام.

Rollups القابلة للبرمجة وتجريد الحسابات

يمكن دمج تجريد الحسابات بعمق في Rollups القابلة للبرمجة.

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

ويمكن لـ rollup القابل للبرمجة جعل هذه الميزات جزءًا أصليًا من تجربة المستخدم بدلًا من إضافات اختيارية.

وهذا مفيد للألعاب والتطبيقات الاستهلاكية ومدفوعات الاشتراكات وأنظمة الهوية وسير عمل المؤسسات.

قد يتمكن المستخدمون من التفاعل دون إدارة رسوم الغاز يدويًا.

وقد تتمكن التطبيقات من توفير مسارات تسجيل وبدء استخدام أكثر سلاسة.

لكن يجب تصميم تجريد الحسابات بعناية.

فقد تتيح مفاتيح الجلسات غير الآمنة للمهاجمين إنفاق الأصول.

وقد يُساء استخدام تصميم paymaster الضعيف لإرسال الرسائل المزعجة.

وقد يصبح الاسترداد الاجتماعي نقطة ضعف إذا لم يُختر الأوصياء بعناية.

يمكن لـ Rollups القابلة للبرمجة تحسين تجربة المحافظ، لكن أمان المحفظة يظل مهمًا.

Rollups القابلة للبرمجة والتصميم المخصص للتطبيقات

أبرز استخدامات Rollups القابلة للبرمجة هو التصميم المخصص للتطبيقات.

قد تحتاج لعبة لامركزية إلى أوقات إنشاء كتل سريعة ورسوم منخفضة وقواعد مخصصة للأصول.

وقد يحتاج بروتوكول DeFi إلى ترتيب عادل وضوابط قوية لـ Oracle ووحدات مخصصة لإدارة المخاطر.

وقد يحتاج تطبيق للمدفوعات إلى رسوم مستقرة ومعاملات مدعومة وإعداد بسيط للمحافظ.

وقد يحتاج نظام مؤسسي إلى وصول مقيّد وفحوص امتثال ومعالجة خاصة للبيانات وقواعد تسوية متوقعة.

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

يصعب ضمان هذه الميزات عندما يكون التطبيق مجرد مجموعة عقود على سلسلة مشتركة.

تمنح Rollups القابلة للبرمجة المطورين تحكمًا مباشرًا أكبر بهذه الخيارات.

لكن المقابل هو أن المطورين سيحتاجون إلى صيانة كل قاعدة مخصصة ومراجعتها أمنيًا وشرحها.

ولا يكون التخصص مفيدًا إلا إذا تجاوزت فوائده التعقيد الإضافي.

Rollups القابلة للبرمجة والتشغيل البيني

يمثل التشغيل البيني أحد أكبر تحديات Rollups القابلة للبرمجة.

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

وقد يؤدي ذلك إلى زيادة عدد الجسور والمحافظ ورموز الرسوم وتعقيد رحلات المستخدمين.

قد يحتاج المستخدم إلى نقل الأصول بين عدة Rollups لمجرد استخدام تطبيقات مترابطة.

وقد تنطوي الجسور على مخاطر العقود الذكية والتحقق من الرسائل والسيولة وتأخر التسوية.

على المطورين تحديد كيفية اتصال rollup الخاص بهم ببقية منظومة العملات المشفرة.

وقد يشمل ذلك جسورًا أصلية أو طبقات مراسلة مشتركة أو بروتوكولات تشغيل بيني أو sequencers مشتركة أو معايير للتواصل بين Rollups.

يمكن للتشغيل البيني القوي أن يجعل Rollups القابلة للبرمجة تبدو جزءًا من منظومة واحدة مترابطة.

أما ضعف التشغيل البيني فقد يجعلها جزرًا معزولة.

يعتمد نجاح Rollups القابلة للبرمجة بدرجة كبيرة على التواصل الآمن والسلس بين Rollups.

Rollups القابلة للبرمجة وتجزؤ السيولة

يحدث تجزؤ السيولة عندما تتوزع الأصول ونشاط التداول على عدد كبير من السلاسل أو Rollups المنفصلة.

وقد يؤدي ذلك إلى ضعف عمق الأسواق وزيادة الانزلاق السعري وتقليل كفاءة رأس المال.

قد تزيد Rollups القابلة للبرمجة التجزؤ إذا أُطلقت appchains صغيرة كثيرة دون جسور قوية أو أنظمة سيولة مشتركة.

قد يجد مستخدم DeFi أن التوكن نفسه يتمتع بظروف سيولة مختلفة على Rollups مختلفة.

وقد يجد مستخدم اللعبة صعوبة في استخدام أصوله خارج rollup واحد.

وقد يحتاج المشروع إلى تحفيز السيولة على سلسلته الخاصة، ما قد يكون مكلفًا.

يمكن لطبقات السيولة المشتركة والجسور الآمنة والمراسلة بين Rollups وتجريد السلاسل أن تحد من هذه المشكلة.

لكن هذه الأدوات تضيف افتراضات أمنية خاصة بها.

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

تصميم السيولة جزء من تصميم Rollup.

Rollups القابلة للبرمجة والحوكمة

تحدد الحوكمة كيفية تغيير rollup القابل للبرمجة بمرور الوقت.

ويشمل ذلك الترقيات وتغييرات الرسوم ومعلمات الجسر وتغييرات sequencer وإعدادات توافر البيانات واقتصاديات التوكن والإيقاف الطارئ وقواعد التطبيقات.

قد يتولى حوكمة rollup فريق أو محفظة متعددة التوقيعات أو DAO أو مؤسسة أو مجموعة مدققين أو عقد بروتوكول.

قد تساعد مرونة الحوكمة rollup على التكيف بسرعة.

لكنها قد تعرض المستخدمين للخطر إذا تمكن المسؤولون ذوو الصلاحيات الواسعة من تغيير القواعد دون سابق إنذار.

ينبغي للمستخدمين معرفة ما إذا كانت الترقيات تخضع لمحفظة متعددة التوقيعات أو قفل زمني أو تصويت عام أو مجلس طوارئ أو مشغّل واحد.

وينبغي للمطورين نشر وثائق واضحة للحوكمة.

عليهم توضيح الجهة التي تستطيع ترقية العقود أو إيقاف الجسر مؤقتًا أو تغيير قواعد sequencer، وكيف يمكن للمستخدمين الخروج إذا لم يوافقوا.

يجب ألا تتحول قابلية برمجة rollup إلى باب خلفي غير ظاهر.

الشفافية في الحوكمة ضرورية لبناء الثقة.

Rollups القابلة للبرمجة والأمان

يعتمد أمان Rollup القابل للبرمجة على طبقات عديدة.

يجب أن تكون بيئة التنفيذ سليمة.

ويجب تأمين عقود الجسور.

كما يجب أن يكون sequencer موثوقًا ومقاومًا للرقابة بما يكفي لحالة الاستخدام.

ويجب أن تتيح طبقة توافر البيانات الوصول إلى البيانات.

ويجب أن يتحقق نظام الإثبات من انتقالات الحالة على نحو صحيح.

كما يجب حماية عملية الترقية.

ويجب ألا تخدع الواجهة الأمامية المستخدمين لتنفيذ معاملات غير آمنة.

ويجب ألا يتحول مزود RaaS أو مشغّل البنية التحتية إلى نقطة فشل واحدة غير ظاهرة.

تتيح Rollups القابلة للبرمجة خيارات تصميم أكثر، لكنها تفتح أيضًا مجالات أكثر لوقوع الأخطاء.

ينبغي أن تشمل مراجعات الأمان البنية الكاملة، لا العقود الذكية للتطبيق وحدها.

فوائد Rollups القابلة للبرمجة

الفائدة الأولى هي التخصيص.

يمكن للمطورين تصميم قواعد السلسلة لتناسب تطبيقًا أو منظومة بعينها.

الفائدة الثانية هي تخصيص مساحة الكتل.

فلا يحتاج التطبيق إلى منافسة تطبيقات لا صلة لها به على سعة التنفيذ في سلسلة مشتركة.

الفائدة الثالثة هي تحسين تجربة المستخدم.

قد تجعل رموز الغاز المخصصة وتجريد الحسابات والمعاملات المدعومة والرسوم المتوقعة تطبيقات العملات المشفرة أسهل استخدامًا.

الفائدة الرابعة هي تصميم أمني معياري.

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

الفائدة الخامسة هي قابلية التوسع.

يمكن لـ Rollups المخصصة للتطبيقات معالجة النشاط خارج الطبقة الأساسية، مع نشر البيانات أو الإثباتات وفق قواعد Rollup.

الفائدة السادسة هي تسريع التجارب.

قد تقلل أطر Rollup ومنصات RaaS الوقت والتكلفة اللازمين لإطلاق بيئات سلاسل مخصصة.

الفائدة السابعة هي مرونة نموذج الأعمال.

يمكن للمشاريع إنشاء سياسات رسوم وقواعد امتثال وعمليات حوكمة وتدفقات تحقيق دخل مخصصة.

مخاطر Rollups القابلة للبرمجة وقيودها

الخطر الأول هو تعقيد البنية التحتية.

يضم rollup القابل للبرمجة مكونات متحركة أكثر من عقد ذكي واحد.

الخطر الثاني هو المركزية.

تُطلق Rollups مخصصة كثيرة باستخدام sequencers مركزية أو بنية مُدارة أو ترقيات يتحكم بها المسؤولون.

الخطر الثالث هو التعرض لمخاطر الجسور.

قد يحتاج المستخدمون إلى نقل الأصول إلى rollup ومنها، وغالبًا ما تكون الجسور أنظمة عالية المخاطر.

الخطر الرابع هو ضعف توافر البيانات.

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

الخطر الخامس هو تجزؤ السيولة.

قد تتوزع الأصول والمستخدمون على Rollups صغيرة عديدة.

الخطر السادس هو عدم نضج الأدوات.

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

الخطر السابع هو غموض الحوكمة.

إذا لم يعرف المستخدمون الجهة التي تتحكم في الترقيات، فلن يتمكنوا من تقييم افتراضات الثقة كما ينبغي.

الخطر الثامن هو عدم الاستقرار الاقتصادي.

قد تفشل رموز الغاز المخصصة والرسوم المدعومة والحوافز الخاصة بالتطبيق إذا لم يكن النموذج مستدامًا.

كيفية تقييم المستخدمين لـ Rollups القابلة للبرمجة

ينبغي للمستخدمين أولًا معرفة الطبقة التي يستخدمها rollup للتسوية.

وعليهم معرفة مكان نشر بيانات المعاملات والمدة التي تظل خلالها متاحة.

كما ينبغي أن يسألوا عما إذا كان rollup يستخدم إثباتات احتيال أو إثباتات صلاحية أو تحققًا مصرّحًا به أو نظام إثبات قيد التطوير.

وعليهم التحقق مما إذا كان sequencer مركزيًا أو لامركزيًا.

كما ينبغي مراجعة آلية السحب والمدة التي يستغرقها.

ويجب التحقق مما إذا كانت الأصول أصلية أو منقولة عبر جسر أو مغلفة أو اصطناعية.

ينبغي معرفة الجهة التي تتحكم في الترقيات وصلاحيات الطوارئ.

كما يجب مراجعة عمليات التدقيق والمراقبة والوثائق العامة وإجراءات الاستجابة للحوادث.

ينبغي إدراك أن انخفاض الرسوم لا يعني تلقائيًا قوة الأمان.

ويجب التعامل مع كل rollup قابل للبرمجة على أنه سلسلة مستقلة ذات ملف مخاطر خاص بها.

أفضل الممارسات للمطورين

ينبغي للمطورين تحديد سبب الحاجة إلى rollup قابل للبرمجة قبل إطلاقه.

وعليهم تجنب إنشاء rollup جديد لمجرد أنه رائج.

كما ينبغي اختيار إطار Rollup استنادًا إلى الأمان والأدوات وتوافر البيانات ودعم المنظومة وقابلية الصيانة على المدى الطويل.

ويجب توثيق بيئة التنفيذ ونموذج sequencer ونظام الإثبات وطبقة توافر البيانات وطبقة التسوية وتصميم الجسر وضوابط الحوكمة.

كما ينبغي تدقيق عقود التطبيق والعقود الخاصة ببنية Rollup التحتية.

وعليهم اختبار الترقيات والسحب وتعطل الجسور وتوقف sequencer وانقطاع توافر البيانات.

ينبغي شرح قواعد الرسوم واقتصاديات رمز الغاز بوضوح.

كما ينبغي توفير جسور ومستكشفات رسمية واضحة للمستخدمين.

ويجب تصميم ضوابط طوارئ آمنة دون منح موقّع واحد صلاحيات غير مقيدة.

ينبغي التخطيط للتشغيل البيني منذ البداية، لا التعامل مع الجسور على أنها أمر ثانوي.

مفاهيم خاطئة شائعة حول Rollups القابلة للبرمجة

من المفاهيم الخاطئة أن Rollups القابلة للبرمجة أكثر أمانًا تلقائيًا من العقود الذكية العادية.

قد تكون أكثر مرونة، لكنها تضيف أيضًا مخاطر تتعلق بالبنية التحتية والحوكمة.

ومن المفاهيم الخاطئة أن كل rollup قابل للبرمجة يتمتع بمستوى أمان الطبقة الأساسية نفسها.

يعتمد الأمان على عقود التسوية وتوافر البيانات والجسور وأنظمة الإثبات وsequencers وضوابط الترقية.

ومن المفاهيم الخاطئة أيضًا أن الرسوم المنخفضة تعني دائمًا تصميمًا أفضل.

قد تكون الرسوم منخفضة بسبب ضعف افتراضات الأمان أو دعم التكاليف أو انخفاض تكلفة توافر البيانات.

ومن المفاهيم الخاطئة أن rollup المخصص يلغي الحاجة إلى تدقيق العقود الذكية.

ما زالت شيفرة التطبيق بحاجة إلى تدقيق، كما تحتاج البنية التحتية لـ rollup إلى المراجعة.

ومن المفاهيم الخاطئة أن إطلاق rollup يحل مشكلات السيولة.

قد يؤدي rollup مخصص إلى مزيد من تجزؤ السيولة ما لم يُخطط للتشغيل البيني وتصميم السوق بعناية.

الأسئلة الشائعة

ما المقصود بـ rollup قابل للبرمجة؟

هو بلوكشين rollup قابل للتخصيص، يستطيع المطورون تهيئة ميزات على مستوى السلسلة فيه، مثل التنفيذ والرسوم والترتيب والتسوية وتوافر البيانات والحوكمة ومنطق التطبيقات.

هل Rollups القابلة للبرمجة هي نفسها شبكات Layer 2؟

كثير منها شبكات Layer 2، لكن بعضها قد يكون شبكات Layer 3 أو sovereign rollups، حسب نموذج التسوية وتوافر البيانات.

لماذا تستخدم المشاريع Rollups القابلة للبرمجة؟

تستخدمها للحصول على مساحة كتل مخصصة ورسوم مخصصة وتنفيذ متخصص وتجربة مستخدم أفضل وتحكم أكبر في البنية التحتية مقارنةً بما يوفره نشر عقد ذكي عادي.

هل Rollups القابلة للبرمجة آمنة؟

قد تكون آمنة، لكن ذلك يعتمد على التصميم بأكمله، بما يشمل الجسور وأنظمة الإثبات وتوافر البيانات وsequencers وعقود التسوية والترقيات والضوابط التشغيلية.

ما الفرق بين rollup قابل للبرمجة وappchain؟

الـ appchain هي أي بلوكشين مخصصة لتطبيق معين، أما rollup القابل للبرمجة فهو سلسلة مخصصة لتطبيق أو قابلة للتخصيص، وتستخدم بنية Rollup.

هل يمكن لـ Rollups القابلة للبرمجة استخدام رموز غاز مخصصة؟

نعم، يمكن لبعضها استخدام رموز غاز مخصصة أو غاز مدعوم أو منطق رسوم خاص، حسب الإطار والإعدادات.

هل تحتاج Rollups القابلة للبرمجة إلى جسور؟

تحتاج معظمها إلى جسور أو أنظمة مراسلة كي يتمكن المستخدمون من نقل الأصول والبيانات بينها وبين سلاسل أخرى.

ما أبرز مخاطر Rollups القابلة للبرمجة؟

يضيف التخصيص تعقيدًا، وقد يؤدي التعقيد إلى جسور ضعيفة وsequencers مركزية وحوكمة غير واضحة ومشكلات في توافر البيانات وبنية تحتية غير ناضجة.

هل تقتصر Rollups القابلة للبرمجة على DeFi؟

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

ما خدمة Rollup-as-a-Service؟

هي بنية تحتية تساعد الفرق على نشر Rollups مخصصة وإدارتها دون بناء كل مكوّن من sequencer وجسر وعقدة وتوافر بيانات من الصفر.

هل يمكن أن تكون Rollups القابلة للبرمجة متوافقة مع EVM؟

نعم، تستخدم Rollups قابلة للبرمجة كثيرة تنفيذًا متوافقًا مع EVM، بينما قد تستخدم أخرى آلات افتراضية مختلفة أو بيئات تشغيل مخصصة.

كيف يقارن المستخدمون بين Rollups القابلة للبرمجة؟

ينبغي مقارنة التسوية وتوافر البيانات ونظام الإثبات ولا مركزية sequencer وأمان الجسر والحوكمة والتدقيق والسيولة والرسوم وافتراضات السحب.

الخلاصة

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

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

أبرز مزاياها المرونة.

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

أما أبرز عيوبها فهو التعقيد.

إذ لا يزال على rollup القابل للبرمجة معالجة تحديات صعبة تتعلق بالجسور وتوافر البيانات وموثوقية sequencer وأنظمة الإثبات والترقيات والسيولة والتشغيل البيني وحماية المستخدم.

ينبغي للمطورين إطلاق Rollups قابلة للبرمجة فقط عندما يحتاج التطبيق فعلًا إلى التحكم في مستوى السلسلة.

وينبغي للمستخدمين تقييم كل rollup قابل للبرمجة كنظام مستقل، بدلًا من افتراض أن جميع Rollups توفر ضمانات الأمان نفسها.

تجعل أفضل Rollups القابلة للبرمجة التخصيص شفافًا، وافتراضات الأمان واضحة، وتجربة المستخدم بسيطة.

وأبسط طريقة لفهم Rollups القابلة للبرمجة أنها تحوّل Rollups من شبكات توسّع عامة إلى بيئات بلوكشين قابلة للتهيئة، تُبنى حول تطبيقات ومجتمعات محددة في عالم العملات المشفرة.