rayls

أنا أغونغ، سفير Rayls.
في الآونة الأخيرة، سألني كثيرون عن الفرق بين الودائع المُرمّزة والعملات المستقرة مثل USDT أو USDC. غالبًا ما يطرح هذا السؤال أشخاص ما زالوا حديثي العهد بتقنية البلوك تشين، وأعتقد أن من المهم الإجابة عنه بوضوح وصدق.
كتبت هذا المقال استنادًا إلى
@raylslabs
والوثائق الرسمية والمدونة، إلى جانب ملاحظاتي الشخصية خلال دراسة المنظومة. حرصت على استخدام لغة بسيطة قدر الإمكان، حتى يتمكن من هم حديثو العهد بـ Rayls من متابعة المقال.

@Rayls فتحت باب الإيداعات في أول خزنة لها في 15 أكتوبر 2026. وبدلًا من الاكتفاء بالنظر إلى إعلان الإطلاق، فحصت نشاط الجسر وتقرير الاحتياطيات والتغييرات في جدول المكافآت ومعاملات الإيداع الفعلية وبنية عقد الخزنة لفهم ما تكشفه الأدلة المتاحة حقًا.
إليكم أبرز النتائج 👇
🔹 1. نشاط الجسر ومعروض الرموز
أظهرت سجلات خزنة الجسر على Polygon التي فُحصت وجود 264,868.416247 BRL1 في التحويلات الواردة و9,576.454346 BRL1 في التحويلات الصادرة، ما خلّف رصيدًا صافيًا قدره 255,291.961901 BRL1.

عند الاطلاع على APY التخزين الخاص بـ @Rayls ، هل يكفي التحقق من معدل العائد المعروض فحسب؟
لفهم معدل العائد الفعلي، علينا التحقق من أمر آخر.
كيف تُسجَّل الإيرادات، وتُحتسب ضمن APY، وتُربط بدفع المكافآت الفعلية؟
هذه المرة، قارنت مباشرةً بين كودَي "RewardCurve" و"RewardDistributor" في مستودع Rayls الرسمي.
1. هل تنعكس إيرادات الشبكة تلقائيًا على APY التخزين؟
صُمِّم "RewardCurve" لحساب APY السنوي بجمع الانبعاثات الشهرية الأساسية والانبعاثات المتغيرة.

في المقالات القليلة الماضية، كنت أقيس المدة التي يستغرقها إثبات Rayls، لكن لدى البنوك سؤال أكثر جوهرية: متى يُعدّ المال قد وصل بالفعل ولا يمكن التراجع عنه؟ هذا الأسبوع غيّرت الاتجاه، وجعلت خوادم GitHub تراقب إيثيريوم وسلسلة Rayls العامة لمدة ساعتين، لأرى كيف تجيبان عن هذا السؤال بنفسيهما.
إليك الإجابة المختصرة أولًا. لكلمة «وصل» لدى البنوك معنيان: أن يصبح التحويل غير قابل للإلغاء قانونيًا، وألا يُتراجع عنه تقنيًا. أما من الناحية التقنية، فإن الكتلة التي يضع عليها عُقد إيثيريوم نفسها علامة «نهائية» تتأخر عن أحدث كتلة بمقدار يتراوح بين 12.6 و19.2 دقيقة، بوسيط يبلغ 16 دقيقة؛ بينما تضع سلسلة Rayls العامة علامة النهائية على كل كتلة فور ظهورها، وتُنتج كتلة كل نحو 1.35 ثانية. لكن لهذا النوع من «النهائية الحتمية» (deterministic finality) ثمنًا أيضًا: عندما يتعذر إحراز تقدم في الإجماع، تتوقف السلسلة بدلًا من أن تتشعب. ومنذ إطلاقها، توقفت سلسلة Rayls العامة مرتين على الأقل: مرة لمدة 11.72 ساعة، ومرة لمدة 9.15 ساعة؛ وفي كلتا الحالتين، استؤنف العمل مباشرةً من الكتلة التي تلت الكتلة التي توقفت عندها السلسلة.

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

إذا فشل التحويل في Rayls، فهل ستعود رموزي؟
إذا فشلت معاملة الوجهة في تحويل بين سلسلتين، فماذا يحدث للرموز التي عولجت في المصدر؟ $RLS
عند نقل الرموز إلى سلسلة أخرى، قد تُقفل الأصول أو تُحرق في سلسلة المصدر. لكن إذا فشلت المعالجة في الوجهة، فستكون هناك حاجة إلى إجراء لاستعادة حالة الأصول.
تشرح وثائق Rayls الرسمية آلية استعادة للتعامل مع هذا الوضع. لكن عند الاطلاع على الشيفرة المتاحة للعامة، تظهر نقاط إضافية تحتاج إلى التحقق منها.

ما توصلت إليه عند البحث في آلية الإجماع لدى Rayls، وبنية التسوية، وإيصالات المعاملات.
بدأت بسؤال بسيط:
إذا وعدت سلسلة بلوكتشين بنهائية المعاملات في أقل من ثانية، فهل يعني ذلك أن المعاملة بأكملها تكتمل في أقل من ثانية؟
قد تبدو الإجابة واضحة للوهلة الأولى. تُؤكَّد المعاملة، وتتوصل الشبكة إلى الإجماع، وتنتهي العملية.
لكن البنية التحتية المالية أكثر تعقيدًا من ذلك.
يمكن إتمام معاملة على دفتر أستاذ بينما تظل عملية أكبر معتمدة على دفتر أستاذ آخر، أو جهة ترحيل، أو التحقق من الإثبات، أو التنفيذ على الجانب المستقبِل.

أعتقد أن إعلانات الإقفال عادةً لا تهتم إلا بأمر واحد، وهو ما إذا كان يمكن التحقق من هذا التعهد. في أغلب المشاريع، ينتهي "إقفال الفريق" في النهاية إلى جملة واحدة؛ فلا خيار لك سوى أن تصدّق أو لا تصدّق. وهذه المرة الأمر مختلف قليلًا، لذلك قمت بالتحقق على السلسلة.
لنضع الحقائق أولًا بشكل واضح. Parfin هي الجهة التقنية الأساسية خلف Rayls، وهي مسؤولة عن تطوير عقد الخصوصية والعقد/الشبكة الخاصة وإطار Enygma للخصوصية وسلسلة Rayls العامة. وكمقابل عن العمل الذي تم قبل TGE، حصلت على 1,070,493,535 من رموز RLS، أي حوالي 11% من إجمالي المعروض الأولي البالغ 10 مليارات.
تم تخزين هذه الدفعة من الرموز المميزة سابقًا لدى جهة حافظة لدى مؤسسة على شبكة الإيثيريوم. والسبب عملي جدًا: خلال حدث TGE، لم تكن سلسلة بلوكتشين Rayls قد انطلقت بعد، لذلك كان لا بد من الإيداع لدى جهة حافظة. والآن أصبحت السلسلة العامة متاحة، تم نقل هذه الدفعة من الرموز إلى سلسلة Rayls العامة، وتم حبسها في عقد ذكي يمكن التحقق منه علنًا، كما تم تأجيل وقت فكّ القفل من ديسمبر 2026 إلى ديسمبر 2027.

إخوتي، لقد كنت أتمركز في كمين داخل مجتمع Rayls باستمرار. أعرف أن الجميع غير راضٍ جدًا عن الفريق، وأنا أيضًا غير راضٍ، لكن الفريق يعمل حقًا ويجتهد دائمًا. فقط فريق Rayls يسير على طريق الامتثال. إخوتي، لا يجب أبدًا أن تستسلموا، ودعوا كل شيء للوقت. أؤمن أن فريق Rayls في النهاية سيُسلّم لنا ورقة/اختبارًا تكون مرضية لنا. سأشارككم الآن بعض الأخبار الجيدة. سأخبركم خبرًا سارًا: وهو أن فريق Rayls مؤخرًا قام بربط RPC. هذه مسألة مهمة جدًا!!
نظرة سريعة
ما هو RPC
يمكنك فهم RPC على أنه خط هاتفي مخصص بين التطبيق والبلوكشين.

بصراحة، أول مرة رأيت هذه الاختصارات الثلاثة مصطفّة معًا، ظننت أنها ثلاثة حلول لمسألة واحدة: أيّها أسرع، وأيّها أكثر أمانًا، اختر واحدًا وانتهى الأمر. لكنني فهمت لاحقًا أن ترتيبها معًا يشبه سؤال: "أيّ أفضل: مطرقة أم مفك براغي أم مفتاح ربط؟" فالإجابة تعتمد على ما إذا كانت لديك مسمارًا أم برغيًا أم صامولة برغيّ.
إن كلّ واحدٍ منها يحل في الواقع ثلاثة مسائل تمّ خلطها معًا.
المسألة الأولى هي: أريد أن أبرهن أن شيئًا ما صحيح، لكن البيانات المطلوبة لإجراء البرهان حسّاسة للغاية، ولا أريد أن أُظهرها لك. يريد البنك إبلاغ الجهة التنظيمية أن "هذه المعاملة قانونية، وأن التفويض صحيح، ولا توجد عمليات مكررة"، لكنه لا يرغب في إدراج المبالغ وأطراف الدفع/الاستلام في السجلات. إن هذا النوع من البرهنة على الحقيقة دون كشف البيانات هو الساحة المفضلة لـ ZK. جمالها يكمن في أن الضمان يأتي من الرياضيات، لا من عبارة من قبيل: "أعدك أنني لن أطلع على الأمر". يمكن للجهة التنظيمية أو المدقق التي تحصل على مفاتيح التحقق أن تتحقق من النتيجة، لكنها لا تتمكن من الوصول إلى البيانات الأساسية. أما الثمن فواضح أيضًا: فهي تتفوق في إثبات خصائص البيانات، لكنها لا تجيد احتساب النتيجة بحيث تعمل عدة جهات معًا وهي جميعًا لا تملك بيانات كاملة، كما أنها أكثر استهلاكًا للحوسبة من النص الصريح.

يوجد تسع صفوف في جدول مقارنة مورّدي Rayls في الموقع، وقد اخترتُ الصف بعنوان «الخصوصية». والسبب بسيط جدًا: الخصوصية مهمة، وBesu مفتوح المصدر، ويمكنني مراجعة توثيقه وكوده.
في جدول المقارنة، يضع Rayls علامة في السطرين «الخصوصية المعزولة» و«الخصوصية التشفيرية»، بينما يضع Besu علامة في السطر الأول فقط. كنت أنوي التحقق عبر وثائق الطرف الآخر، لذلك بحثتُ في وثائق Besu، ثم حمّلت كوده وعددتُ الأسطر/الأجزاء بدقة مرةً أخرى.
الاستنتاج ليس «أن Besu لا يصلح». الفرق الحقيقي هو أن الشركتين تضعان الخصوصية في طبقات مختلفة، وأن Besu نقل ذلك في وقت أبكر مما يظن الكثيرون.

يمكنك كل أسبوع في عالم التشفير أن ترى ”عملاقًا ماليًا تقليديًا ما“ يدخل إلى عالم البلوك تشين. أنا الآن أرى أن هذا النوع من العناوين غالبًا ما يتم تمريره سريعًا؛ لأن الغالبية في النهاية تتوقف عند مختبرات الابتكار، وتنشر بيانًا صحفيًا ثم لا يحدث شيء بعدها. للتحقق من الحقيقة، يوجد معيار بسيط جدًا: هل يستطيع العميل العادي، من تطبيقه الخاص، أن يقوم بفتحه مباشرة ويستخدمه؟
شركة XP Inc. لقد اجتازت هذا المعيار هذه المرة.
أولًا، يجب توضيح هذه الشركة، لأن حجمها يحدد وزن هذه المسألة. شركة XP هي منصة استثمار برازيليّة مدرجة في بورصة ناسداك، ورمز السهم هو XP. تحققتُ من صفحة علاقات المستثمرين لديها من بيانات الربع الأول لعام 2026: إجمالي أصول العملاء حوالي 1,529 مليار ريال برازيلي؛ ودقيقةً هي 1.529 تريليون ريال. عدد مستشاري الاستثمار يتجاوز 18,000 شخص. وإجمالي الإيرادات خلال الاثني عشر شهرًا الماضية يبلغ 19.8 مليار ريال برازيلي، بينما الأرباح قبل الضريبة تبلغ 5.8 مليار ريال برازيلي.

19 سبتمبر، أرسل رايلز مقالًا (الخصوصية لها ثمن)، والعنوان فيه كلمة honest math. وفي كامل المقال، لم يقدم سوى نطاقًا للأرقام: كم تستغرق عملية إثبات واحدة من بضع مئات من الملّي ثانية إلى بضع ثوانٍ. لقد واظبت لأسابيع على كتابة مخطط/معمارية خصوصية رايلز، وهذه المرة أشارككم محتوى جديدًا. لقد قمت بسحب كود إثباته الذي نشره وتشغيله فعليًا عشرات المرات، وسأشارككم هذا الاستنتاج المثير للاهتمام!
لنبدأ بما الذي تحدث عنه في المدونة. يمكن تلخيص حجته الأساسية في جملتين. الجملة الأولى تتناول أين تكمن التكلفة: المعاملات السرّية أغلى من المعاملات الشفافة؛ ويقع هذا الغلاء في توليد إثباتات المعرفة الصفرية، بينما يكون التحقق أرخص. فإثبات تحويل سرّي أساسي على عتاد تجاري عادي يحتاج إلى عدة مئات من الملّي ثانية إلى بضع ثوانٍ. الجملة الثانية تقول ما الذي ينبغي السؤال عنه: لا ينبغي للمؤسسات أن تكتفي بسؤال TPS، بل يجب أن تسأل عن الإنتاجية ضمن مستوى الخصوصية والتدقيق/المراجعة الذي تحتاجه، وبمواجهة أحمال العمل الفعلية. وتعتقد المدونة أن حجم تسويات البنوك بين بعضها ليس كبيرًا، وأنه يقع بالكامل ضمن قدرات أنظمة التسوية السرية.

$RLS
وأثناء مراجعة كود Rayls Relayer لاحظت ملاحظة غريبة واحدة.
إذا كان Relayer هو الجهة التي تُمرِّر الرسالة، فهل يجب أن يمتلك صلاحية RELAYER أيضًا في "executeMessage()"؟
لكن عند تتبّع الكود الفعلي تبيّن أن الأمر ليس كذلك.
بل إن Rayls كان قد فصل صلاحية تمرير الرسالة عن التنفيذ الفعلي.
في Public Chain، المكان الذي يدخل فيه Relayer لأول مرة هو "PublicRNEndpoint.receivePayload()".
هنا لا يقوم بتنفيذ الرسالة مباشرةً،

أنا بدأت بعملية الإيداع/الرهان (staking) من مجموعة يونيو الخاصة بالالتزامات المسبقة، لذا فهذه العملية مررت بها بالفعل مرة. هذه المرة تم فتحها للجميع؛ وفي محيطي كثيرون يسألونني كيف تتم العملية وما الذي ينبغي الانتباه له، لذا كتبتها مرة واحدة لتكون واضحة تمامًا.
قل أولاً التغيير نفسه.
يستخدم Rayls إثبات الحصة المفوّضة (delegated proof of stake)؛ حيث يقوم المدقّق بتشغيل العقد والتحقق وبناء الكتل وضمان أمان السلسلة العامة، بينما لا يحتاج مالكو الحصص العاديون إلى تشغيل العقد بأنفسهم. يمكنهم تفويض RLS الموجود لديهم إلى أحد المدققين، ومشاركة جزء من عوائد/مكافآت الرهان.
تم تشغيل هذه الآلية منذ يونيو، لكن في ذلك الوقت كانت متاحة فقط لمحافظ شاركت في خطة الالتزامات المسبقة وأنشطة سيولة البذور. تلك المجموعة قامت بقفل العملات قبل إطلاق الشبكة الرئيسية، وقدمت الجهة الرسمية نسبة سنوية إضافية قدرها 55% لمدة ثلاثة أشهر، وحتى أرسلت لهم 1 USDr لكل محفظة تستوفي الشروط، حتى لا يفتقروا إلى تكاليف الـ gas.

بدأت أعمل على الحصص المرهونة RLS منذ مرحلة الالتزام المسبق، والاطلاع على المواد الرسمية يعدّ هذا الأمر عادةً بالنسبة لي. بعد ظهور اسم Sovereign، غالبًا ما بقيت المناقشات تدور حول: "هل هو مجرد تغيير اسم؟". برأيي، هذا السؤال يُطرح بالعكس. الاسم ليس مهمًا؛ المهم هو ما الذي تم تغييره فعليًا تحته، وكم يمكن لمؤسسة ما أن تحصل عليه أثناء إجراء العناية الواجبة بحيث يمكنها التحقق بنفسها. كل رقم في هذه المقالة أعطيتُه بمصدر محدّد، ويمكنك إعادة إنتاجه خطوة بخطوة كما هو.
لنوضّح أولاً أمرًا واحدًا: في الأسبوع الماضي كتبتُ مقالًا عن قابلية التدقيق، وقد يكون بعض القرّاء قد شاهدوه.
في هذه المقالة، معظم المحتوى جديد، جاء من مستودع كود Axyl، ومن مجلدات التدقيق داخل المستودع، ومن صفحة وثيقة معايير أداء Axyl. هذه الأماكن الثلاثة لم أتعامل معها من قبل. فقط المقطع الصغير الخاص بإدارة المفاتيح هو استمرارية لنتائج المقال السابق، وسأشير إليه هناك. أفصل الجديد عن القديم لأن عبارة "ما الذي وجدته هذا الأسبوع" و"ما الذي كنت قد تحققت منه سابقًا" ينبغي أن تساعد القارئ على التمييز بنفسه.

في المرة السابقة عندما كتبت مقال XP، ظلّت لدي فضولية حول سؤال واحد: بعد أن يتم إصدار عملات مستقرة مؤسسية مثل USDXP، كيف تشارك فعلًا في التسوية الحقيقية عبر الحدود؟ هذا المقال بمثابة إجابة على تلك الحيرة، وبالمناسبة جعلني أفهم للمرة الأولى كلمةً تُسمّى «ساندويتش العملات المستقرة».
أولاً اشرح هذا المصطلح؛ إنه فعليًا تصويري جدًا. تحويل دفع عبر الحدود بخط واحد: طرفا العملية هما العملة المحلية، وبينهما توجد طبقة من العملات المستقرة العامة. يقوم المُرسل بتحويل العملة المحلية إلى عملة مستقرة مرتبطة بالدولار، ثم تُنجز العملة المستقرة التسوية عبر السلسلة (البلوك تشين) للمعاملة عبر الحدود، وبعد ذلك يقوم المُستلم بتحويلها مرة أخرى إلى عملته المحلية. ألا يشبه ذلك شريحتين من الخبز تفصل بينهما طبقة في الوسط؟ هذا هو التعبير الذي بدأ المجال يستخدمه لوصف التسوية عبر الحدود باستخدام العملات المستقرة.

بدأتُ رهن RLS منذ مرحلة التعهّد المسبق، وأقرأ المدونة الرسمية عادةً فقط لأعرف ما إذا كانت مراكزي ستتأثر. أما المقال المنشور في 30 أغسطس عن الكمّيات فكان مختلفًا؛ إذ كان يشرح للمؤسسات، من البداية إلى النهاية، كيف تقوم بالشراء، ولم تكن له علاقة مباشرة بشخص مثلي من المستثمرين الأفراد. ومع ذلك قرأته حتى النهاية، لأنه وضع في بدايته قاعدة صارمة جدًا، وهذه القاعدة هي التي أعادتني لاحقًا إلى المقال نفسه.
القاعدة هي كالتالي: إذا كان هناك ادعاء بـ”الأمان الكمي“، ولم يُذكر بوضوح أي خوارزمية معيارية استُخدمت، وعلى أي مستوى من المعلمات، فهو ليس ادعاءً بل مجرد وسم.

في المقالة السابقة كتبت عن فتح/إتاحة الرهن نفسه. لكن في الخلفية، كان أكثر سؤال يتكرر من الإخوة هو الجملة التالية: كيف يتم ذلك عمليًا بالضبط؟ لذا هذه المرة، سلكتُ العملية من البداية إلى النهاية مرةً أخرى، ودوّنت كل خطوة وكل نقطة قد تسبب تعثّرًا. اتبع ما كتبته فقط.
رابط المقالة السابقة موجود هنا: 质押开放给所有人了,但有几件事最好先知道
أولاً، حدِّد لمن تم تقديم هذه المقالة. إذا لم تكن قد تعاملت مطلقًا مع Rayls، وحتى أنك غير معتاد على كلمات مثل المحفظة والجسر (bridging)، فهذه المقالة مكتوبة لك. سأشرح باختصار كل مصطلح تقني أثناء المرور عليه.