昨天不是刚亏吗 今天怎么又亏

في المقالتين السابقتين، اختبرتُ شفرة إثباتات Rayls على خادم سحابي، لكن الأرقام جاءت من آلة واحدة فقط، كما لم تكن شفرة الاختبار متاحة للقراء لإعادة إنتاجها مباشرةً. هذه المرة نشرت شفرة الاختبار على GitHub، وجعلت خوادم GitHub نفسها تشغّلها، واختبرت ثلاثة أنواع من وحدات المعالجة المركزية، وأتحت للجميع الاطلاع على السجلات بنقرة واحدة.
إليك الإجابة المختصرة أولاً. عند استخدام مجموعة إخفاء هوية من 6 أشخاص في دارة التحويل الخصوصي Enygma من Rayls، يستغرق توليد إثبات المعرفة الصفرية لتحويل واحد 1.55 إلى 1.95 ثانية على وحدة vCPU واحدة، و0.63 إلى 0.71 ثانية على 4 وحدات vCPU، بينما لا يستغرق التحقق من الإثبات سوى نحو 1 ملي ثانية. وعندما تعالج الخدمة تحويلاً من فئة معينة للمرة الأولى، تحتاج إلى 1.9 إلى 2.9 ثانية إضافية لتحميل مفتاح الإثبات إلى الذاكرة. وبافتراض معالجة الطلبات بالتتابع، يستطيع خادم سحابي مزود بـ4 وحدات vCPU إنتاج 1.4 إلى 1.6 إثبات في الثانية.

في المرة السابقة شغلت كود إثباتات Rayls المنشور، ووجدت أن فئة الـ6 أشخاص تحتاج 1.96 ثانية لكل إثبات. لكن في تلك المقالة كانت هناك ثلاث جمل استنتاج وليست قياسًا، وأنا كنت أعرف ذلك. هذه الأسبوع بدّلت الجهاز إلى 2 نواة وأضفت عدة شرائح بيانات، وبذلك رجعت لإكمال تلك الجمل الثلاث.
أوضح أولًا العلاقة بين هذه المقالة وتلك السابقة، حتى لا يظن القارئ أنها إعادة نشر لنفس المقالة. المقالة السابقة قيست زمن إثبات فئة الـ2 أشخاص وفئة الـ6 أشخاص في بيئة أحادية النواة، وتمت إعادة قياس الرقميْن هذه المرة تقريبًا بدون تغيير. المحتوى الجديد الكامل هنا هو تلك الأمور الثلاث التي لم تتمكن المقالة السابقة من قياسها بل كانت تضطر إلى استنتاجها.

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

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

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

我从预承诺阶段就开始质押 RLS，读官方博客算是习惯。9 月 12 日这篇讲可审计性的文章，后半段列了六条标准，说数学强制按构造全部满足。这句话我认同，但“按构造满足”是个可以查的说法，不是只能相信的说法。所以我花了一周，把这六条逐条拿去公开源码、技术文档和链上接口里找对应的东西，现在分享给大家。
先说它的分类，我认为比大多数“隐私还是透明”的讨论有用。做可审计性有三条路：数学强制，边界写在密码学构造里；硬件信任，靠可信执行环境的完整性；策略访问控制，谁能看到什么由网络运营方配置说了算。

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

منشورتي السابقة تناولت لماذا لا ترغب البنوك في مشاركة دفتر أستاذ واحد مع منافسيها. بعد أن انتهيت من الكتابة، ظهر لدي سؤال: بما أن كل جهة تتمسك بدفترها الخاص، فكيف تتم المعاملات بين بنكين مختلفين؟ يتم تسجيل الأموال والأصول في دفترين لا يتواصلان ولا يمكنهما تبادل البيانات؛ يبدو الأمر وكأنه غير قابل للتطبيق. تهدف هذه المقالة إلى توضيح العملية التفصيلية وراء ذلك.
رابط المقال السابق موجود هنا: <a-35/>(لماذا لا ترغب البنوك في مشاركة دفتر أستاذ واحد مع منافسيها)</a-35/>
حدّد السيناريو مسبقًا، وإلا فسيبدو الشرح عامًا جدًا.
لنفترض أن هناك بنكين في نفس الاختصاص القضائي. البنك (A) يريد الدفع، ويستخدم مدفوعاته المرقمنة/المُرمّزة التي يصدرها هو. البنك (B) يريد تسليم أصل مُرمّز. الطرفان لا يرغبان في منح معلومات العملاء والأرصدة والمنطق التشغيلي للطرف الآخر، ولا يرغبان أيضًا في تسليم ذلك لأي جهة ثالثة للتخزين/الوساطة. هذه هي الحالة الأكثر نموذجية لصفقة «السند مقابل المال»، أي ما يسميه القطاع DvP.

عندما تتحدث مشاريع البلوك تشين عن تبنّي المؤسسات، عادةً ما يتحدثون عن «أن تقنيتنا أكثر تقدمًا». لكن هذه المرة، فإن المقال الذي نشرته Rayls مختلف: فقد خصصت الجزء الأكبر من النص لشكاوى العملاء، وكانت الشكاوى غير لطيفة إلى حدٍّ ما. بعد أن قرأته، شعرت بأن الشيء الجدير بالقول ليس مجرد قائمة المنتجات، بل إنها تعترف بشيء لا يبدو أن الصناعة ترغب كثيرًا في الاعتراف به.
先说这次发布本身有个反常的地方。
في 25 أغسطس، أطلقت Rayls خدمة Sovereign، وهي سلسلة خاصة مخصصة للمؤسسات المالية. ولكن حسب ما ذكرته الجهة الرسمية، فإن منصتها الأساسية تعمل في بيئة الإنتاج منذ يونيو 2024، وقد تم تجهيزها واستخدامها من قبل أكثر من 30 مؤسسة مالية. وSovereign هو إصدار مُعاد هيكلته بشكل كبير من المنتج السابق الذي كان يُسمى Rayls Privacy Node؛ وقد كان التحويل جذريًا إلى الحد الذي استدعى تغيير الاسم.

عادةً أتصفح أخبار التنظيم لمحة واحدة فقط وأتجاوزها، لأن معظمها لا علاقة له بالمستثمرين العاديين. لكن هذه المرة، بعد أن قرأت قواعد بريطانيا هذه بالكامل، تغيّر رأيي؛ لأن لديها آلية غير واضحة نسبيًا ستؤثر فعليًا على الخيارات التي ستختارها المؤسسات في المستقبل لاستخدام أي سلسلة بلوك تشين.
أولًا، رتّب التسلسل الزمني بوضوح، لأن ذلك يحدد درجة الاستعجال.
اعتمد البرلمان البريطاني، في 4 فبراير 2026، اللوائح ذات الصلة، ونشرت هيئة السلوك المالي (FCA) في 30 يونيو محتوى النظام الأساسي لهذه المنظومة، وهي تتكوّن من خمس وثائق سياسات. ستُفتح قناة الترخيص في 30 سبتمبر، بينما سيبدأ النطاق الكامل للأنشطة الخاضعة للتنظيم في النفاذ بشكل شامل في 25 أكتوبر 2027.

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

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

تركّز معظم المشاريع على آلية الحرق، أي “كم عدد الرموز التي سنقوم بحرقها”. لكن ما يثير فضولي أكثر هو الجزء السابق: من أين جاءت تلك الرموز التي تم حرقها في الأصل. إجابة تصميم Rayls كانت مفاجئة بعض الشيء؛ فبدايته لم تكن من التشفير، بل كانت دفعة بالعملة الورقية.
أولاً، الخلاصة. نقطة البداية في السلسلة بأكملها ليست عالم التشفير، بل هي دفعة بالعملة الورقية (Fiat) تصدرها جهة ما داخل بلدها.
عند إجراء الأعمال على Rayls عبر عقد الخصوصية، تترتب على المؤسسات رسوم. الفكرة الأساسية هي أنها يمكن أن تُسوي مباشرة بالعملة الورقية، أو أن تختار استخدام USDr أو RLS.

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

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

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

بصراحة، أخبار التعاون عادةً أمرّ عليها بعيني بسرعة وأكمل، فمِن كل عشرة أخبار تسعة فقط تكتفي بتعليق شعارين. لكن هذه المرة توقفت وقرأت حتى النهاية، لأنها تمس أَتفه وأغلى جزء في مدفوعات عبر الحدود.
التحويلات عبر الحدود بطيئة، وكثيرون يظنون أن السبب هو “بطء الشبكة”. في الحقيقة السبب تافه جدًا ومباشر: المال ليس “يُرسل” فعليًا عبر الطريق، بل كان “موجودًا” هناك مسبقًا. عندما تريد البنوك دفع مبلغ إلى بلد معيّن، فعادةً يلزمها فتح حساب في البنك المحلي مسبقًا، وإيداع مبلغ كبير من المال هناك، وهذا يُسمّى في لغة المهنة حساب nostro. كل ممر دفع في العالم يحتاج إلى أن تُكدَّس فيه دفعة من الأموال، مثلما تترك لدى كل صديق كومة نقود جاهزة بالبيت لاستخدامها في يوم ما. المال يظل راكدًا على الحساب، والتقلبات في سعر الصرف يتحمّلها المرء بنفسه. وغالبًا ما يستغرق إتمام عملية تحويل عبر الحدود واحدة عدة أيام.

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

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