我从预承诺阶段就开始质押 RLS，读官方博客算是习惯。9 月 12 日这篇讲可审计性的文章，后半段列了六条标准，说数学强制按构造全部满足。这句话我认同，但“按构造满足”是个可以查的说法，不是只能相信的说法。所以我花了一周，把这六条逐条拿去公开源码、技术文档和链上接口里找对应的东西，现在分享给大家。
先说它的分类，我认为比大多数“隐私还是透明”的讨论有用。做可审计性有三条路：数学强制，边界写在密码学构造里；硬件信任，靠可信执行环境的完整性；策略访问控制，谁能看到什么由网络运营方配置说了算。
بناءً على ذلك، وضعت ستة معايير على مستوى المؤسسات لكي تكون قابلة للتدقيق، ثم قالت إن الرياضيات تُلزم بالتحقق عبر البناء بحيث تُستوفى كل الشروط الستة.
لئلا نصير في الكلام أكثر فأكثر افتراضياً، سأثبت سيناريو: بنك يشارك في تجربة عملة رقمية للبنك المركزي، والمدقق في البنك المركزي يريد فحص معاملات هذا البنك على الشبكة. سيناريو Drex في البرازيل هو بالضبط هذا، وRayls يجري تجارب داخل هذا السياق. السؤال الوحيد الذي يجب الإجابة عليه هو: لماذا تكون الأشياء التي يراها المدقق موثوقة؟
الأولى والثانية: الإفصاح الانتقائي وتقييد النطاق
نقطة هاتين العبارتين تقعان على الشيء نفسه: مفتاح المراقبة.
GitHub لدى Rayls مفتوح. في دليل cryptography بمستودع relayer يوجد ملف mlkem.go. داخله GenerateSalt يستخدم تغليف مفتاح المراقبة العام لـ ML-KEM-768 الخاص بالمرسل إليه لمشاركة المفتاح المشترك. RecoverSalt يستخدم ML-KEM-768 الخاص محليًا لفك التغليف باستخدام مفتاح المراقبة الخاص. الاستدعاءات هي NewEncapsulationKey768 وNewDecapsulationKey768 من مكتبة Go القياسية. أسماء المتغيرات مكتوبة كـ view public key وview secret key.
لذا فإن الأساس التشفيري لمفتاح المراقبة هو ML-KEM-768، وهذه النقطة موثقة.
لنقل كلمة إضافية عن معنى ذلك. في 30 أغسطس، مقالة Rayls التي تتحدث عن التحضير للكمّية أكدت خصيصًا: إذا لم يكتب توصيف «أمان كمّي» على مستوى المعلمات، فهذا ليس ادعاءً بقدر ما هو مجرد وسم (label). والأمثلة التي ذُكرت بالضبط ليست الشيء نفسه: ML-KEM-512 وML-KEM-1024 ليسا متماثلين. وفي حديثها عن ترقيتها هي كتبت فقط: «تم استبداله بـ ML-KEM». وفي الكود مكتوب 768. هذا ليس خللًا: 768 هو فئة معاملات رسمية لدى NIST، وهو أيضًا القيمة الافتراضية الموصى بها لتطبيقات الشركات في الصناعة. هو فقط حقيقة لم تكن معروفة سابقًا إلا بقراءة الكود، والآن أصبحت يمكن الاستشهاد بها مباشرة.
بما أن المستويات محددة، يمكن حساب كلفة تغيير المستوى. FIPS 203 تثبت الأحجام: مفتاح تغليف عمومي 768 حجمه 1184 بايت، والنص المشفر 1088 بايت، وكلاهما 1024 يساوي 1568 بايت.
المفتاح هو التكرار (الوتيرة)، ووثيقة إدارة المفاتيح تذكر ذلك أيضًا: يتم عمل التغليف مرة واحدة لكل زوج مشارك أثناء بناء الشبكة، ويتم تخزين النص المشفر على محور الشبكة الخاصة؛ ومن ثم لا تحمل كل رسالة إلا وسمًا صغيرًا واحدًا. لذا لا يتزايد ذلك مع زيادة حجم المعاملات. شبكة من 30 مؤسسة لديها 435 زوجًا، والفارق بين مستويين يساوي تقريبًا 215 KB؛ حتى لو كانت 60 مؤسسة و1770 زوجًا، فإن الفرق لا يتجاوز 1 MB، وهو مرة واحدة فقط.
هذا القدر صغير لدرجة لا معنى له، وهذا هو الاستنتاج: إذا كان أي نشر يحتاج مستوى أعلى، فلن تأتي المقاومة من عرض النطاق الترددي أو التخزين، بل إنها مجرد تعديل كود. في نقاشات الانتقال العام بعد الحقبة الكمّية غالبًا يكون اختيار المعلمات مقايضة بين الأداء، لكن في هذه الطبقة الأمر ليس كذلك.
تقييد هذا النطاق على هذه الحالة فقط: وثائق التقنية أضافت الشطر الآخر: يمكن تحديد قدرات الملاحظة عبر نافذة زمنية أو عبر الحساب.
الفقرة الثالثة: فصل الرؤية عن الصلاحيات
عبارة الوثيقة التقنية أصعب من عبارة المدونة: مفاتيح الصرف والمفاتيح الخاصة بالمراقبة مستقلة رياضياً عن بعضها ولا يمكن استنتاج إحداهما من الأخرى. وفي ملخص المراجعة الأمنية جملة أكثر مباشرة: صلاحيات المراقبة وصلاحيات الصرف مفصولتان بواسطة التشفير لا بواسطة الإعداد؛ لذلك لا يمكن أن يؤدي خطأ إعداد واحد إلى تحويل صلاحية القراءة إلى صلاحية كتابة.
وثيقة إدارة المفاتيح صححت لي أيضًا افتراضًا شائعًا. جميع مواد المفاتيح على جانب المؤسسة تُعالج بشكل موحّد بواسطة مكوّن اسمه Cryptographic Trust Suite، يعمل داخل حدود المؤسسة نفسها. لا يقوم Relayer بحيازة أي مفتاح؛ يقتصر دوره على أن يطلب منه إجراء التشفير وفك التشفير نيابةً. وتأتي صلاحية قراءة المدقق من: كل مؤسسة تقوم بتشفير مفتاح المراقبة الخاص بها باستخدام مفتاح التشفير العلني للجهة المشغلة، وتخزن ذلك مع رمز تحقق (authentication code) في محور الشبكة الخاصة، كجزء من سجل كجهة مشاركة. وخدمة التدقيق تستعيد ذلك عند بدء التشغيل.
هنا يوجد وثيقة فرعية تشير هي نفسها إلى شيء: يمكن للمؤسسة أن ترى على المحور ما هي الجهات المشاركة التي يوجد سجل لها، وبالتالي تعرف ما الذي جُعل قابلاً للقراءة. إن منح قابلية الرؤية بحد ذاته أمر يمكن رؤيته.
على الهامش، هذه الصفحة الخاصة بجدول أنواع المفاتيح الثلاثة تدعم ما رأيته في الكود: مفاتيح التوقيع على secp256k1 عبر ECDSA، مفاتيح المراقبة عبر ML-KEM، ومفاتيح الدفع على BN254 عبر Baby JubJub. الوثيقة والمصدر مطابقان تمامًا.
الفقرة الرابعة: تحقق الصحة
تعتمد هذه المدونة على الإثباتات عديمة المعرفة (zero-knowledge)، وRayls لديها خدمة gnark-api مخصصة لتوليد والتحقق من إثباتات Groth16.
وثيقة Enygma الخاصة بالمعاملات قدمت عدة معاملات محددة لا يُستشهد بها عادةً في العادة. حجم مجموعة الإخفاء (anonymity set) هو 2 أو 6، أي أن كل عملية تحويل تُجمّع مع عملية أخرى أو خمس عمليات أخرى، ولا يستطيع المراقب تحديد من بدأ الإرسال. وكل عملية crossTransfer يمكنها الإشارة إلى ما يصل إلى 5 سلاسل مستهدفة، مع حمل 5 إجراءات قابلة للاستدعاء. يتم ضمان الذرّية على مستوى الدفعات عبر عقد Enygma الموجودة على محور الشبكة الخاصة: يتحقق أولاً من إثباتات الدفعة كاملة، ولا يتم سكّ العملات إلا للمقاصد التي تكتمل لها التحقق.
وهناك كلفة تشغيلية أخرى تُكتب بصراحة في الوثيقة: المعالجة على دفعات، وتوليد البراهين، والتحقق عبر المحور، كلها عند مستوى عشرات الثواني؛ لذا يجب التخطيط وفق ذلك، وليس وفق نهائية دون مستوى الثانية بين معاملات داخل مؤسسة. التحقق من الصحة ليس مجانيًا؛ وسعره هو تلك العشرات من الثواني.
لكن هنا توجد صياغة تستحق أن تُؤخذ وحدها بالحديث، لأنها تتعلق بأربع مواد.
تقول الوثيقة التقنية إن التزام Pedersen «يخفي قيمةً، وفي الوقت نفسه يربط المتعهِّد بهذه القيمة بحيث لا يمكن تغييره لاحقًا»، وتحول صفة القابلية للربط إلى خاصية مُذكورة في العبارة. أما مقال 8 أغسطس عن الكمّية فقد وضع ذلك ضمن «لا يحتاج معالجة»، بمعنى أنه مقاوم للكمّ أصلاً. يظهر في الكود enygma_math.go أنه يستخدم مولدات مستقلتين على منحنى BabyJubJub لحساب v*G + r*H، وهو بناء Pedersen قياسي وصحيح. أما الورقتان الأكاديميتان لدى Rayls، IACR المرقمان 2025/1639 و2025/1638، فتصفان مفردات التصميم بالكامل على أنه quantum-private أي خصوصية كمّية، وتفسير ذلك هو أن الخصم الكمّي لا يستطيع استنتاج المرسل/المستلم والمبلغ من المعاملة. هذه مجرد مطالبة تتعلق بالسرية.
قراءتي هي أنه من بين أربع مواد، الورقة وحدها هي التي تستخدم ألفاظًا دقيقة. BabyJubJub مبنية على مجال القياس في BN254، لذا الانكشاف/الخفاء (hiding) صالح ضد الخصم الكمّي؛ وهذا هو جزء الادعاء في الورقة. أما الربط (binding) فيعتمد على اللوغاريتمات المنفصلة، وهذا هو الجزء الذي لم تدّعِه الورقة.
بالنسبة لمؤسسة تريد أن تُثبت وضع الامتثال بحيث تصمد أمام مراجعة الخصوم، فإن «الخصم الكمّي لا يرى رصيدي» و«الخصم الكمّي لا يستطيع تزوير رصيد مزيف» أمران مختلفان، وقد تم كتابتهما في الوثائق والمدونة وكأنهما شيء واحد. المقالة العلمية لم ترتكب هذا الدمج.
الفقرة الخامسة: قابلة للإلغاء
لقد بحثت عن هذه النقطة طويلاً. في وثائق Rayls توجد صفحة ضمن وثيقة بعنوان «خيارات تصميم الشبكة الخاصة» أجد فيها الجواب. لكن هذا ليس الشيء نفسه الذي تتحدث عنه المدونة، وأعتقد أنه أكثر إثارة للاهتمام.
المدققون هم دور يعيّنه الطرف المشغّل، وبالتوازي معهم توجد الجهات المشاركة والجهة المُصدِرة. النقطة الأساسية هي أن قابلية رؤية المدقق ليست مفتاح تشغيل/إيقاف، بل هي مرتبطة بالمستوى. وتستخدم هذه الوثيقة ثلاثة أمثلة لرسم معنى المستوى.
في تلك الفئة الخاصة بشبكة العملات الرقمية للبنك المركزي، يمكن لمدقّقي الحسابات فك تشفير المعاملات بين العقد. وفي فئة منصات تداول الأصول المُرمّزة (tokenization)، يراقب المدققون عبر التحقق من التزامات Pedersen التي تنشرها كل عقدة إلى المحور (hub). تذكر الوثائق صراحة أن المدققين لا يملكون صلاحية الوصول مباشرة إلى بيانات حمولة المعاملات المشفرة؛ فهم يرون الشواهد فقط وليس المحتوى. وفي فئة سوق NFT الذي تديره DAO، وهي الأكثر تطرفًا، يقوم بدور المدقق مُتحقق يثبته السلسلة العامة؛ وبشكل افتراضي لا توجد أي صلاحية وصول. لا يتم تمكين فك تشفير المعاملة المعينة إلا عندما تُظهر عملية التحقق وجود احتيال في تلك البينة.
وضعت الفِئات الثلاث جنبًا إلى جنب، وجملة المدقق في المتصفح «درجة فك التشفير يمكن ضبطها أثناء مرحلة البناء» هي التي تجسدت فعليًا.
عدنا إلى تلك الفقرة في المدونة. تقول المدونة إن قابلية استرجاع الرؤية ممكنة، والاسترجاع تفرضه التشفير. أما الوثيقة فتقدم تصميمًا آخر: الرؤية يتم ضبطها أثناء بناء الشبكة حسب المستوى، وليست شيئًا يُسحب بعد وقوعه. وكلتاهما تقيدان المدقق: واحدة قيد مسبق، والأخرى إلغاء بعدي.
وسيلة الإلغاء في طبقة الحوكمة موجودة فعلًا: يمكن تحديث الأدوار، وحالة الأعضاء تكون نشطة أو مجمدة أو مُعطّلة. يتم تنفيذ التجمد من قبل جهة التشغيل عبر عقد حوكمة ParticipantStorage. لكنني لم أجد وصفًا لكيفية سحب إمكانية وصول ظاهرة كان المدقق قد حصل عليها بالفعل. وهناك تفاصيل تجعل هذه المسألة ملموسة جدًا: تقول الوثيقة إن المدقق يستقبل في كل مرة ينضم فيها عقد جديد تبادل مفاتيح Diffie-Hellman، وأن القدرة على الوصول تُسلَّم على شكل مادة مفاتيح. تعطيل الدور يمكنه منع منح صلاحيات مستقبلية، لكن هل يمكن إبطال مادة المفاتيح التي تم تسليمها بالفعل؟ ما زلت أبحث ذلك.
الفقرة السادسة: الاستمرارية
هذه النقطة عكس الخامسة: المدونة قللت من شأن نفسها.
يقول إن الاستمرارية تعود إلى إدارة المفاتيح ويمكن حلها، ويقرأ كأنه فراغ. لكن وثيقة إدارة المفاتيح حوّلت عبارة «يمكن حلها» إلى مخطط محدد. التخزين الفعلي للمفاتيح قابل للتبديل (pluggable) مع ما لدى المؤسسة بالفعل: AWS KMS وGoogle Cloud KMS وAzure Key Vault وHSM محلي؛ بيئة التطوير فقط تستخدم ملفات محلية. يتم تشفيره بشكل ثابت عبر «تشفير ظرفي/مغلف» (envelope)، وما يتم حفظه بعد ذلك هو النص المشفر وليس مادة المفاتيح.
الأهم هي هذه الجملة. لأن كل مرة للتشفير/فك التشفير تمر عبر خدمة إدارة مفاتيح خاصة بالمؤسسة، فإن مسارات التدقيق التي تنتجها تلك الخدمات أصلًا—عند تغطية عمليات Rayls—تكون مثل تغطية المؤسسة لباقي الأشياء التي تعمل بها بنفسها. والنتيجة الموجهة لجهة الامتثال في الوثيقة هي: لا حاجة لبناء سطح تدقيق جديد لذلك. وهذا ما تريد الاستمرارية: مسارات التدقيق معلقة على منظومة المؤسسة نفسها، لا على سجلّ مميز لمورّد بعينه.
تمت كتابة فكرة التدوير (rotation) بتفصيل كبير: يمكن أن يكون لكل سلسلة عدة مفاتيح توقيع، ويتم تدويرها حسب الاستخدام. وتتم متابعة كل مفتاح منفردًا عن طريق nonce. ويظل المفتاح الذي تم توقيعه للمعاملات قيد الانتظار صالحًا حتى اكتمال تسوية تلك المعاملات. هذا يعالج بالضبط الفجوة الأكثر عرضة للمشكلات أثناء التدوير.
لكن توجد نقطة حدود واحدة: القسم الذي يصف التدوير يتحدث عن مفاتيح التوقيع، ولم أر تدوير مفاتيح المراقبة في هذه الصفحات. أما الاستمرارية فمهمتها تحديدًا هي هل يمكن قراءة أثر التدقيق بعد سنوات؛ وهذا يعتمد أكثر على جانب مفاتيح المراقبة.
الأداة التي يستخدمها المدقق فعليًا
كانت الأمور كلها حتى الآن في قراءة علم التشفير، لكن المدقق حين يجلس فعليًا لاستخدامه يعتمد على أداة. الوثيقة توضّح أن متصفح المدقق في الشبكة الخاصة لا يمكن الوصول إليه إلا من قِبل المدققين، أما الجهة المشغلة وباقي المشاركين فلا يمكنهم؛ وهو يقدم «منظرًا خلفيًا» بعد فك تشفير المعاملات عبر السلاسل.
تقييد النطاق: يغطي فقط معاملات عبر السلاسل التي يتم تسجيلها إلى محور الشبكة الخاصة؛ والمعاملات التي تحدث داخل دفتر سيد/سجادة السيادة (Sovereign) الخاص بإحدى المؤسسات لا يستطيع المدققون الوصول إليها. لذا فهذه «قابلية رؤية المدقق» تكون بين المؤسسات، وليست داخل المؤسسة.
فهل يوجد مثال يمكن التحقق منه بالكامل؟
نعم، ولديه واحدة فقط. لأن البنية المعمارية بحد ذاتها تحدد أن معظم الأشياء لا يمكن رؤيتها.
توضح الوثيقة الرسمية السبب: معاملات Enygma تصدر من دفاتر Sovereign الخاصة بكل مؤسسة. وتقوم كل مؤسسة بنشر متصفح لمراقبة دفترها الخاص؛ أما جزء عبر السلاسل فيقع على محور الشبكة الخاصة ويقوم متصفح المدقق بمشاهدته. وفقًا للتصميم، الأنشطة بين المؤسسات لا توجد على السلسلة العامة، لذلك لا يمكن العثور على معاملات Enygma في متصفح السلسلة العامة. هذا ليس نقصًا؛ بل نتيجة حتمية للبنية ذات الطبقات الثلاث.
لكن عقد القفل لدى Parfin موجود على السلسلة العامة، وهو بالمناسبة مثال كامل لـ «تفرضه الرياضيات».
العنوان الذي يبدأ بـ 0x1463889D، واسم العقد RlsTokenLock—تم التحقق من الكود المصدري—ليس عقدًا وكيلاً. هذا يعني أنه واحد من عدد قليل جدًا من الكائنات التي يمكن قراءة الكود فيها وكذلك التحقق من الحالة الحالية. لقد طابقت الجانبين.
يُصرّح المُنشئ بأن totalAmount هو 1,070,493,535 RLS. وكمية RLS التي يحتفظ بها العقد فعليًا حاليًا هي 1,070,493,535. دون أي فرق: كاملة ومؤكدة التمويل 1:1.
جدول فك القفل يستحق أن يُذكر أكثر. في المُنشئ يوجد 48 طابعًا زمنيًا، فككّتُها جميعًا: أول مستوى في 1 ديسمبر 2027، ثم كل شهر في اليوم الأول مستوى، وآخر مستوى في 1 نوفمبر 2031. المدى حوالي 3.92 سنة، وكل مستوى حوالي 22.30 مليون RLS. المواد المنشورة مسبقًا أكدت أن القفل حتى ديسمبر 2027؛ هذا صحيح، وهو المستوى الأول. لكن المُنشئ يعرض الصورة الكاملة: بعد المستوى الأول توجد قرابة أربع سنوات من الإطلاق الشهري.
تعليقات العقد نفسها تكتب نية التصميم بوضوح: غير قابل للترقية، وشروط النشر هي شروط أبدية؛ لا يوجد فك قفل مسبق، ولا يمكن لأي مفتاح أن ينتقل إلى مستوى آخر قبل تاريخ الانتهاء. لقد طابقت هاتين النقطتين واحدًا تلو الآخر مع الكود. أما مخطط التوقيت فموجود في المُنشئ دون وجود setter، والعقد فعلاً ليس وكيلًا (proxy).
هذه هي «الرياضيات القهرية» كما تظهر في مثال يمكنني التحقق الكامل منه: الادعاء يتوافق مع الكود، والكود أكثر تحديدًا من الادعاء. في تلك الأشياء من المعايير الستة التي لم أجد لها إلا أثرًا في المصدر والوثائق، يمكنني هنا أن أراها متتابعة حتى النهاية.
إحالات خارجية في موضعين آخرين
عندما تتحدث المدونة عن TEE تقول إن لدى Intel SGX ثغرات موثقة تمكّنت من خرق ضمانات عزلها. هذه الجملة صحيحة، لكنها تُخفف من قوة حجتها. ثغرات فئة العزل تشمل Foreshadow وPlundervolt وEPIC Leak وSmashEx، وأرقامها على التوالي هي CVE-2018-3615 وCVE-2019-11157 وCVE-2022-21233 وCVE-2021-0186 وCVE-2021-33767. والأخطر فعلًا هو SGAxe في 2020: فهو يستخدم CVE-2020-0549 لاستخراج مفتاح الشهادة نفسه من enclave معتمد في بيئة إنتاج Intel، وبعد ذلك يمكنه إصدار أي تصريحات تعتقد خدمة الشهادة الخاصة بـ Intel أنها شرعية.
حجّة المدونة هي أن ضمانات TEE تُقدّم عبر إثبات تصدره العتاد، بينما تقوم SGAxe بالاختراق تحديدًا في ذلك الجزء الذي يقدّم إثبات الضمان. أسوأ مرة فشل لم تكن أن البيانات سرقت، بل أن الضمان نفسه تم تزويره. وبإنصاف: تمت إصلاح هذه الأمور عبر تحديثات microcode وTCB recovery. اليوم SGX ليس SGX في 2018؛ الصياغة الدقيقة هي أن جذر الثقة في العتاد يملك مساحة ثغرات متجددة.
المرة الأخرى هي عندما تقول إن BIS لـ Project Agora يتقارب إلى نفس البنية. لقد راجعت تقرير النموذج الأولي من BIS بتاريخ 27 مايو. على مستوى الطوبولوجيا نعم يبدو قريبًا: بنية ذات طبقتين، دفتر مشترك بالإضافة إلى دفاتر مستقلة لكل اختصاص. لكن حد Agora يتم رسمه عبر سلطة الاختصاص. والتقرير لم يوضح كيف يتم تنفيذ التحكم في الوصول داخل دفاتر الاختصاص. لذلك لا يمكننا معرفة ما إذا كان هذا التقارب يمتد إلى طبقة نموذج الثقة؛ وفق المواد العامة المتاحة لا يبدو ذلك واضحًا.
ما الذي هو تأكيد، وما الذي هو استنتاجي؟
المؤكد: ML-KEM-768 يستخدم لمفاتيح المراقبة، انظر relayer في cryptography/mlkem.go. وPedersen يبني مولدات على BabyJubJub الزوجية، انظر enygma_math.go. ويتم تسليم مفتاح التدقيق الخاص مُشفّرًا بواسطة relayer، انظر治理服务的 cryptography/service.go. والاستقلالية الرياضية بين مفتاح الصرف ومفتاح المراقبة، وإمكانية تقييد نطاق المراقبة حسب الوقت والحساب، وأن متصفح المدقق يغطي فقط المعاملات عبر السلاسل وأن درجة فك التشفير قابلة للتكوين أثناء مرحلة الإنشاء—كلها مذكورة في الوثائق التقنية الرسمية. وCryptographic Trust Suite يحتفظ بالمفاتيح بشكل موحّد ولا يحوز Relayer مفاتيح مطلقًا، كما يمكن توصيل تخزين المفاتيح إلى KMS أو HSM، والتشفير ثابت عبر مغلف/ظرفي. وسجلات تدقيق سجل عمليات المفاتيح للمفاتيح المُدارة من طرف المؤسسة (ضمن خدمة إدارة مفاتيح خاصة بالمؤسسة) هي مسار تدقيق عمليات المفاتيح. ومفاتيح التوقيع يتم تدويرها حسب الاستخدام، والمفتاح الذي تم توقيعه لمعاملات قيد التسوية يبقى صالحًا حتى اكتمال تسويتها. والتغليف يتم إتمامه مرة واحدة أثناء بناء الشبكة لكل طرف مشارك. وحجم مجموعة الإخفاء 2 أو 6. كل crossTransfer يمكنه الإشارة إلى ما يصل إلى 5 سلاسل مستهدفة. والنهائية على مستوى عشرات الثواني. وتجميد المشاركين يتم تنفيذه عبر عقد الحوكمة ParticipantStorage من قِبل جهة التشغيل. كلها في الوثائق التقنية الرسمية. وحالة التحقق لـ RlsTokenLock، وكونه غير وكيل، وجدول 48 مستوى زمنية، وإعلان المبلغ مقابل الرصيد الفعلي—كلها تم قراءتها عبر واجهة المتصفح العامة في 12 سبتمبر 2026. وأرقام ثغرات SGX مأخوذة من سجلات CVE ومن ورقة SGAxe. وبنية وبيانات Agorá مأخوذة من مواد BIS العامة.
استنتاجي: من بين أربع مواد، المقالة وحدها هي التي تستعمل ألفاظًا دقيقة فيما يخص Pedersen. وصف «تفرضه الرياضيات على الحدود» يتحدث عن التنفيذ لا عن التوزيع. SG A xe يدعم حجة المدونة بشكل أفضل من ثغرات فئة العزل. لا يوجد في هذه الثلاث مواد ما كُتب بهذه الطريقة.
لم أتمكن من التحقق: آلية السحب اللاحق للفقرة الخامسة. لقد بحثت في وثائق إدارة المفاتيح، ومتصفح المدقق، والأساسيات التشفيرية لـ Enygma، وتجميد الجهات المشاركة، وخيارات تصميم الشبكة الخاصة، ووثائق محور الشبكة الخاصة الستة، بالإضافة إلى مستودعي كود اثنين هما relayer وخدمة الحوكمة. وجدت إعدادات ثلاثية للمستويات الخاصة بالرؤية، وآلية المنح، وتجميد وإيقاف الجهات المشاركة. لكن لم أعثر على تنفيذ لسحب إمكانية وصول سبق منحها وتم فرضه بالتشفير. وبالنسبة للتدوير طويل الأمد لمفتاح المراقبة، لم أجد أيضًا. القسم الذي يصف التدوير في الوثائق يتحدث عن مفاتيح التوقيع فقط.
وأخيرًا أذكر شيئًا ليس له علاقة بالتقنية
في الأسبوع نفسه الذي كُتبت فيه هذه المقالة، أعلنت الجهة الرسمية أن 55% من مستويات الرهان ستُمدد حتى 15 سبتمبر، وقالت إنها خلال فترة تعديل آلية الرهان ستسمح للمؤيدين الأوائل بالاستمرار في الحصول على هذه الجزء من العوائد؛ وستُعلن لاحقًا تحديثات حول الرهان والاقتصاد الرمزي الأوسع بما في ذلك التدمير.
منذ مرحلة الالتزام المسبق كنت أراهن، وشاركت بالكامل لمدة ثلاثة أشهر. في الأصل كان ينتهي مستوى الرهان في 9 سبتمبر؛ في تلك الأيام رأيت على الواجهة أن السقف قد امتلأ ولا يمكنني إضافة المزيد، فظننت لحظتها أن المشكلة من الواجهة الأمامية. الآن يبدو أن الآلية قيد التعديل.
هذه خلاصة رأيي الشخصي، وليست تقريرًا واقعيًا: في نافذة تعديل الآلية، اختيار الإطالة بدل قطعها مباشرة، وكتابة التاريخ بوضوح؛ أرى ذلك تصرفًا فيه نية صادقة. أكثر ما قد يحدث خلال فترة تعديل الآلية هو الغموض في التعبير؛ وتقديم تاريخ محدد يعني أن الحل إمّا الوفاء أو تفسير جديد عند انقضاء المدة.
هذه مجرد حادثة محددة، ولا تشكل حكما على أي ترتيبات طويلة الأمد. لا أتنبأ بالعوائد، ولا أنصح أي شخص باتخاذ قرار بناءً على ذلك.
المراجع: المدونة الرسمية لدى Rayls Auditability without surveillance: why mathematical enforcement beats trusting the code، 12 سبتمبر 2026. وصفحتان من الوثائق التقنية الرسمية لدى Rayls: الأساسيات التشفيرية لـ Enygma ومتصفح المدققين في الشبكة الخاصة. مستودعا GitHub تحت منظمة raylsnetwork: rayls-sovereign-relayer وrayls-sovereign-pnh-governance. واجهة explorer للبلوكشين العامة لدى Rayls: explorer.rayls.com للـ addresses وsmart-contracts، وقت أخذ البيانات 12 سبتمبر 2026. NIST FIPS 203. سجلات CVE: 2018-3615 و2019-11157 و2020-0549 و2021-0186 و2021-33767 و2022-21233، وورقة SGAxe. تقرير نموذج BIS Project Agorá othp110. أرشيف IACR الإلكتروني للتشفير 2025/1638 و2025/1639. بيان حساب Rayls الرسمي على X في 12 سبتمبر 2026.
