في السنوات الأخيرة، أصبح نموذج Rollup-as-a-Service (RaaS) شائعًا كاستجابة عملية لمشكلة حقيقية في نظام بلوكتشين: إطلاق وتشغيل شبكة خاصة مكلف ومعقد ويتطلب مستوى من التخصص الذي لا تمتلكه معظم فرق المنتجات. يظهر RaaS، إذن، كنوع من التجريد الملائم. يعد بتقليل الحواجز التقنية، وتسريع وقت الوصول إلى السوق، وتمكين الفرق من التركيز على المنتج، وليس على البنية التحتية.

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

يقترح هذا المقال تحليلًا مقارنًا متزنًا بين RaaS التقليدي ونهج @Tanssi ، مع تركيز محدد على هذين المحورين. وليس المقصود إعلان فائزين يصلحون للجميع، بل فهم أسباب اختلاف نتائج البنى المختلفة عند اختبارها بحالات استخدام حقيقية.

ما الذي يحله RaaS التقليدي، وأين يبدأ الاحتكاك

يقدم RaaS، في أكثر أشكاله شيوعًا، حزمة مُدارة لنشر شبكات التجميع. يختار الفريق حزمة تقنية معروفة، ويحدد بعض المعلمات، ويحصل على بنية تحتية جاهزة: مُسلسِل، وRPC، ومستكشف، وجسر افتراضي، وفهرسة، ومراقبة. وهذا مناسب للنماذج الأولية والتطبيقات في مراحلها المبكرة. فالتكلفة الذهنية منخفضة، والقدرة على التنبؤ التشغيلي في البداية مرتفعة.

تظهر المشكلة حين ينمو التطبيق ويبدأ بالاعتماد على ضمانات أقوى. وثمة ثلاثة أوجه احتكاك تتكرر كثيرًا.

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

الاحتكاك الثاني يتعلق بالتسلسل. تعتمد نماذج كثيرة من RaaS، على الأقل في البداية، على مُسلسِل تديره جهة مركزية لضمان الأداء. وهذا يحسن تجربة المستخدم على المدى القصير، لكنه ينشئ اعتمادًا تشغيليًا ونقطة فشل واحدة تزداد حساسيتها مع نمو حجم الاستخدام.

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

لا تجعل هذه الحدود من RaaS خيارًا «سيئًا»، بل تحدد بوضوح نوع التطبيقات التي يناسبها.

السيادة متغير اقتصادي، لا شعار

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

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

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

عمليًا، ينقل ذلك السيادة من مستوى «الحزمة التقنية المختارة» إلى مستوى السلسلة نفسها. يتحكم الفريق في التنفيذ والاقتصاد، بينما تعمل Tanssi كطبقة لتوفير البنية التحتية والتنسيق والموثوقية التشغيلية.

بنية تحتية مُدارة من دون اعتماد مفرط

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

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

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

الاتصال البيني جزء من البنية، لا إضافة تكميلية

ومن الجوانب المهمة الأخرى التي تميّز هذا النموذج طريقة التعامل مع الاتصال البيني. ففي نموذج Tanssi، لا تُعد قابلية التشغيل البيني مجرد مجموعة من عمليات التكامل الاختيارية، بل مكوّنًا بنيويًا.

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

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

Gotas: حين يكشف توسع المستهلكين حدود البنية

تساعد حالة Gotas على توضيح هذه الاختلافات بصورة ملموسة. تعمل المنصة في السياق البرازيلي، مع تركيز قوي على تفاعل المستخدمين النهائيين والعلامات التجارية. وأرقامها لافتة: مئات الآلاف من المحافظ، وملايين التفاعلات، وحملات في الوقت الفعلي.

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

أتاح اختيار شبكة L1 سيادية لـ Gotas عزل بيئة التنفيذ الخاصة بها، والتحكم في التكاليف، وتقليل الاعتماد على مُسلسِل واحد، مع الحفاظ في الوقت نفسه على الاتصال بمنظومات أخرى. هنا، لا تظهر السيادة كأيديولوجيا، بل كنتيجة مباشرة للمتطلبات التشغيلية.

Rivool: قابلية التنبؤ متطلب، لا ميزة إضافية

في حين تكشف Gotas عن تحديات التوسع أمام المستهلكين، تُظهر Rivool نوعًا آخر من الضغوط: ضرورة القدرة على التنبؤ في السياقات المالية والإنتاجية.

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

ومرة أخرى، لا يُعد اختيار بنية سيادية مسألة جمالية، بل يستجيب مباشرةً للحاجة إلى مواءمة البنية التحتية للبلوك تشين مع مسؤوليات العالم الحقيقي.

ربط التحديات بالتصاميم المعمارية

تساعدنا ملاحظة هذه الحالات على فهم موضع ملاءمة كل نموذج.

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

لا يتعلق الأمر بتطور خطي، بل بخيارات معمارية مختلفة لمراحل واحتياجات مختلفة.

أفكار ختامية

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

عند مقارنة Tanssi بنموذج RaaS التقليدي، لا تتمثل الفكرة الأساسية في الادعاء بأن أحد النموذجين يحل محل الآخر، بل في توضيح أن السيادة والاتصال البيني لا يعودان «ميزات متقدمة» حين تنضج التطبيقات. بل يصبحان شرطين أساسيين لكي تتجاوز البلوك تشين كونها مجرد طبقة تجريبية وتبدأ في دعم اقتصاد حقيقي.