يمكن للبنك أن يثبت أن عملية التحويل الرمزي تعمل باستخدام نموذج أولي.

السؤال الأصعب هو ماذا يحدث عندما يتعين على هذا النموذج الأولي التحدث مع الأنظمة التي يعتمد عليها البنك بالفعل.

البنوك الأساسية. الخزانة. الخدمات المصرفية الرقمية. أنظمة الهوية وKYC.

إذا أصبحت البلوك تشين نظامًا معزولًا آخر، فإن البنك يكون قد أنشأ مشكلة تكامل أخرى بدلًا من حل واحدة.

هذه هي الجزء من رايلز سيادي أجدها الأكثر إثارة للاهتمام.

الآلية: يتيح سيادي الوصول إلى دفتر الأستاذ عبر واجهات مألوفة

رايلز سيادي هو بلوك تشين خاص متوافق مع EVM تقوم المؤسسة بتثبيته وتشغيله داخل بيئتها الخاصة.

يتولى الدفتَر معالجة نشاط المؤسسة على السلسلة (onchain)، بينما يمكن للتطبيقات الاتصال به عبر الواجهات القياسية.

الخيار الأكثر مباشرة هو Ethereum JSON-RPC.

وهذا يعني أن أدوات Ethereum الحالية مثل ethers.js وweb3.js وviem وHardhat وFoundry يمكنها التواصل مع دفتَر Sovereign دون الحاجة إلى عميل بلوكتشين مخصص.

توجد أيضًا مسارات تكامل أخرى.

يمكن لواجهة Rayls Backend عرض REST API لإنشاء المعاملات وتكامل الحفظ (custody)، بينما يمكن لاتصالات WebSocket توفير أحداث في الوقت الحقيقي من الدفتَر.

لذلك لا يحتاج التكامل إلى أن يبدو مثل:

أنظمة البنوك → مكدس بلوكتشين جديد بالكامل

قد يبدو الأمر أكثر مثل:

أنظمة البنوك → طبقة تكامل موجودة → دفتَر Sovereign

هذه التفرقة مهمة.

توضح وثائق Rayls تحديدًا أن Sovereign قادر على التكامل مع منصات الخدمات المصرفية الأساسية (core banking) وأنظمة ERP ومصادر تغذية الأسعار (price feeds) ومستودعات الهوية وKYC.

بعد ذلك يمكن للدفتَر (ledger) أن يتصل بشكل مباشر إلى الخارج

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

بالنسبة لمعاملة مؤسسية خاصة:

Sovereign → Private Network Hub → دفتَر Sovereign آخر

بالنسبة لنشاط السلسلة العامة (public-chain):

Sovereign → Rayls Public Chain

هذه ليست نفس المسار.

اتصال السلسلة العامة هو مسار مباشر من واحد إلى واحد ويستخدم تعاقداته الخاصة وعملية الوسيط/المرحل (relayer). لا يمر عبر Private Network Hub.

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

مثال عملي

تخيّل أن البنك يقوم بترميز وديعة (deposit).

يمكن للبنك إصدار وإدارة هذا الأصل على دفتَر Sovereign الخاص به، مع الحفاظ على بقاء الدفتَر داخل بيئته الخاصة.

يمكن لأنظمته الحالية التفاعل مع الدفتَر عبر الواجهات المتاحة.

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

إذا احتاج إلى الوصول إلى تطبيق أو سيولة على السلسلة العامة (Public Chain)، فله مسار منفصل لذلك.

الجزء المهم هو أن الدفتَر الداخلي للبنك يظل دفتَر المؤسسة الخاص بها.

ما الذي يتغير؟ قدرته على ربط هذا الدفتَر ببيئات أخرى عندما تكون هناك حاجة تجارية للقيام بذلك.

لماذا هذا مهم للإنتاج

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

يطرح نموذج أولي السؤال:

“هل يمكننا وضع هذا الأصل على السلسلة (onchain)؟”

الإنتاج يطلب:

“هل يمكن لأنظمتنا الحالية أن تعمل مع هذا الأصل دون إعادة بناء البنك حول مكدس (stack) جديد؟”

تم تصميم Sovereign حول السؤال الثاني.

إنه يمنح المؤسسة دفتَر EVM خاصًا بها، وواجهات تكامل مألوفة، ومسارات مُتحكَّم بها إلى Rayls Private Networks وإلى السلسلة العامة (Public Chain).

كما أن المنصة الأساسية كانت قيد الإنتاج منذ يونيو 2024، حيث ذكر Rayls أنه تم تثبيت Sovereign واستخدامه من قبل أكثر من 30 مؤسسة مالية.

خلاصة رأيي

بالنسبة للبلوكتشين المؤسسي، يُعدّ التكامل جزءًا من المنتج.

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

الفكرة هي أن البلوكتشين مُصمَّم ليعمل داخل بيئة البنك القائمة بالفعل، مع وجود مسارات محددة لشبكات onchain الخاصة والعامة.

CTA: إذا كنت تقوم بتقييم البنية التحتية للبلوكتشين لمؤسسة، فإن معمارية @Rayls Sovereign تستحق الفحص بدءًا من طبقة التكامل أولًا.