19 سبتمبر، أرسل رايلز مقالًا (الخصوصية لها ثمن)، والعنوان فيه كلمة honest math. وفي كامل المقال، لم يقدم سوى نطاقًا للأرقام: كم تستغرق عملية إثبات واحدة من بضع مئات من الملّي ثانية إلى بضع ثوانٍ. لقد واظبت لأسابيع على كتابة مخطط/معمارية خصوصية رايلز، وهذه المرة أشارككم محتوى جديدًا. لقد قمت بسحب كود إثباته الذي نشره وتشغيله فعليًا عشرات المرات، وسأشارككم هذا الاستنتاج المثير للاهتمام!
لنبدأ بما الذي تحدث عنه في المدونة. يمكن تلخيص حجته الأساسية في جملتين. الجملة الأولى تتناول أين تكمن التكلفة: المعاملات السرّية أغلى من المعاملات الشفافة؛ ويقع هذا الغلاء في توليد إثباتات المعرفة الصفرية، بينما يكون التحقق أرخص. فإثبات تحويل سرّي أساسي على عتاد تجاري عادي يحتاج إلى عدة مئات من الملّي ثانية إلى بضع ثوانٍ. الجملة الثانية تقول ما الذي ينبغي السؤال عنه: لا ينبغي للمؤسسات أن تكتفي بسؤال TPS، بل يجب أن تسأل عن الإنتاجية ضمن مستوى الخصوصية والتدقيق/المراجعة الذي تحتاجه، وبمواجهة أحمال العمل الفعلية. وتعتقد المدونة أن حجم تسويات البنوك بين بعضها ليس كبيرًا، وأنه يقع بالكامل ضمن قدرات أنظمة التسوية السرية.
المهمة التي قامت بها هذه المقالة بسيطة جدًا: أنها أخذت سؤال المدونة نفسه واقترحته، وتوجهت لطرحه باستخدام كود Enygma المفتوح للعموم. فيما يلي، كل ما كُتب بين «قالت المدونة» هو ادعاء من النص الأصلي؛ أما «أنا لاحظت» و«أنا حسبت» فهي نتائج واستنتاجاتي أنا، يُرجى فصلها عند القراءة.
كيف قستُ
يمكن فهم إثباتات المعرفة الصفرية كوثيقة رياضية: لا يُفصح المُدفِع عن الرصيد والمبلغ، لكنه يستطيع إثبات للشبكة أن هذه المعاملة صحيحة. نظام الإثبات الذي تستخدمه Enygma يسمى Groth16. كود خدمة توليد البرهان مفتوح على GitHub في مستودع rayls-sovereign-gnark-api، ويُعرّف README هذا المستودع بأنه واجهة إثبات تُستخدم خلف Privacy Ledger وPrivate Network Hub.
لقد قستُ على أحدث التزام في الفرع main بتاريخ 22 سبتمبر 2026: 67c4c26. لم تتغير أي سطر في كود الدائرة أو كود البرهان. كتبت فقط بعض ملفات الاختبار الإضافية لاستدعاء دوال البرهان الخاصة بالمستودع، وكانت بيانات المعاملات التي أدخلتها مأخوذة أيضًا من مجموعة الاختبارات المضمنة في المستودع، مع مجموعة لكل من k=2 وk=6.
k هنا هو حجم المجموعة المجهولة (anonymous set). وفقًا لكود الدائرة، فإن عملية تحويل واحدة تجعل k أطراف مشاركين كل واحد يولد التزامًا بالمبلغ (amount commitment). المُرسل يختبئ داخلها، ولا يستطيع من يراقب من الخارج معرفة من دفع لمن. كلما زاد k ازداد عمق الاختفاء، وتكبر أيضًا الدائرة. سيناريو اختبار الضغط المدمج في المستودع يستخدم k=6.
المفتاح مُولَّد على جهازي المحلي باستخدام نفس groth16.Setup وبنفس الطريقة. هذا لا يؤثر على زمن التوليد، لأن زمن البرهان يعتمد على بنية الدائرة، ولا علاقة له بالقيمة الملموسة للمفتاح. كما يذكر ملف README الخاص بالمستودع أيضًا أن مجموعة المفاتيح الموجودة فيه هي ناتج إعداد أحادي الطرف (single-party) للتطوير والاختبار وليست نتيجة طقوس إعداد موثوق متعددة الأطراف؛ أما النشر في الإنتاج فيستلزم طقسًا منفصلًا، وهذا يتوافق مع ما تقوله المدونة عن أن Groth16 يحتاج إعدادًا موثوقًا.
بيئة الاختبار هي آلة افتراضية Linux أحادية النواة، Intel Xeon بسرعة 2.1GHz، وذاكرة 3GB. في كل فئة يتم توليد 20 برهانًا بشكل متواصل، ثم بعد بضع دقائق تُعاد كل مجموعة لاختبار الجولة الثانية بالكامل.
الأرقام التي خرجت
نتائج الجولة الثانية: برهان k=6، في 20 تجربة كان متوسطها/وسيطها 1.96 ثانية؛ الأسرع 1.94 ثانية والأبطأ 2.12 ثانية. أما k=2 فوسيطه 0.96 ثانية. الجولة الأولى كانت 1.97 ثانية و0.96 ثانية على التوالي؛ والفارق بين الجولتين أقل من 1%. التحقق من برهان واحد يستغرق فقط 1.9 ميلي ثانية.
هذه الأرقام تقع ضمن النطاق الذي قدمته المدونة. لكن الأهم هو نسبة التوليد إلى التحقق: 1.96 ثانية مقابل 1.9 ميلي ثانية، أي تقريبًا 1,000 إلى 1. تقول المدونة إن الوقت يُصرف أساسًا على التوليد وأن التحقق رخيص جدًا؛ هذه النسبة تجعل كلمة «أساسي» تتحول إلى مضاعف محدد.
قمت أيضًا بعمليات تحقق عكسية. في مجموعة الاختبار توجد مجموعتان من البيانات تم تعديلها عمدًا بطريقة خاطئة: في مجموعة k=2 تم تغيير مبلغ تحويل من 0 إلى 10، وفي مجموعة k=6 تم العبث بأحد قيم الهاش. تم رفض المجموعتين أثناء مرحلة البرهنة، مع الإبلاغ عن عدم استيفاء القيدين رقم 517 ورقم 1085 على التوالي، ولم يتمكن من توليد برهان. بالطبع، هذا لا يثبت عدم وجود ثغرات في الدائرة؛ بل يدل فقط أن هذين النوعين الواضحين من العبث سيتم اعتراضهما.
تفاصيل غير موجودة في أي من المدونتين
التفصيل الأول يتعلق بحجم الدائرة. مع إضافة طرف مشارك واحد، يزيد عدد القيود بشكل ثابت بمقدار 8,112 قيدًا. من k=2 حيث يبلغ 37,140 قيدًا، يرتفع إلى k=6 حيث يصل إلى 69,588 قيدًا في خط مستقيم. لكن نظام البرهنة عندما يخصص مساحة الحساب للدائرة يأخذ التقريب إلى قوة 2: k=2 إلى k=5 كلها تناسب داخل 65,536، أما k=6 فيتجاوز بـ 4,052، فتنقلب سعة الحساب مباشرة إلى 131,072.
الدليل موجود في أحجام ملفات مفاتيح البرهان. من k=2 إلى k=5، يزيد حجم المفتاح بشكل ثابت بمقدار 918,382 بايت لكل فئة. أما عند k=6 فيقفز الزيادة فجأة بمقدار 3,015,534 بايت، أي أكثر من ثلاثة أضعاف كل زيادة من الفئات السابقة. كما أن اتجاه زمن التوليد يتطابق مع ذلك أيضًا: من k=2 إلى k=6 زادت القيود بنسبة 87%، وزاد زمن البرهان بنسبة 104%. بالنسبة للوقت الإضافي الذي تُضيفه عبور هذه الحدود لوحدها، فهو يتطلب بيانات معاملات من k=3 إلى k=5 حتى يمكن تفكيكه؛ والمستودع حاليًا يوفّر فئتين فقط: k=2 وk=6، لذلك ما يمكن تأكيده الآن هو أن الاتجاه متوافق. إذا كان بيئة الإنتاج تستخدم k=6 بالضبط، فهو يقع على الجانب الآخر من هذه الحدود؛ وستكون كلفة التحويل من k=5 إلى k=6 أكبر من كلفة الانتقال بين الفئات السابقة، وهذه استنتاجي وليست مقولة المدونة.
التفصيل الثاني هو الاتساق. تولدت خمس مجموعات مفاتيح برهان (proof keys) من كود المصدر المفتوح، وكانت أحجام الملفات متطابقة تمامًا مع ناتج البناء الرسمي في المستودع، بدقة تصل إلى البايت. كما أن مفاتيح التحقق عند k=6 كانت كذلك متطابقة. وبالطبع يجب أن يكون محتوى المفاتيح مختلفًا، لأن كل Setup يعيد توليد قيم عشوائية من جديد؛ لكن أحجامها متطابقة تمامًا، ما يوضح أن بنية الدائرة التي تم تجميعها من كود المصدر المفتوح هي نفس مجموعة الدائرة التي بُنيت رسميًا. في الرسالة السابقة، عندما أجريتُ تدقيق Axyl، ذكرت أن هناك تاريخًا لا يمكن تتبعه بين المستودع المفتوح والإصدار الخاص وقت التدقيق. أما في هذه المرة، في جانب خدمة البرهان، على الأقل جزء «المصدر مقابل البناء الرسمي» متوافق؛ ومع ذلك، هل بناء الرسمي يتوافق مع النشر في الإنتاج أم لا، فالوثائق العامة لا يمكنها الإجابة عنه.
把博客的问题代进真实负载
لنبدأ من حيث توقفت في الرسالة السابقة. في تلك المقالة، قمتُ بتفكيك مصدر بعض أرقامها لأكثر من 15,000 TPS؛ تلك الأرقام تصف طبقة توافق Axyl. في هذه المرة، اختبرت طبقة أخرى، أي وقت البرهان الذي يتم استهلاكه أولًا عند المُرسِل لكل معاملة سرية. لا يمكن جمع أرقام الطبقتين معًا، ولا يمكن استبدال إحداهما بالأخرى.
الترميز الحجمي الذي طرحته المدونة هو: عدد المعاملات يوميًا لعلاقات بنوك/وكلاء كبار هو بضعة آلاف؛ وخدمة تسوية إجمالية فورية على مستوى بنك/مؤسسة (tokenized real-time gross settlement) على مستوى بنك مركزي تكون عشرات الآلاف من التحويلات الكبيرة يوميًا. قمتُ باستبدال ذلك ببيانات علنية جاهزة من نظامين حقيقيين. يبلغ متوسط عدد عمليات Fedwire Funds Service في 2025 يوميًا 869,187 معاملة، ويبلغ متوسط عدد معاملات CHAPS في 2025 سنويًا 210,483 معاملة يوميًا في بريطانيا. هذه الأرقام أكبر بعدة عشرات ومئات المرات على التوالي من أمثلة المدونة.
فيما يلي حساباتي، وليست ادعاءات المدونة. وفقًا لاختبار إثبات أحادي النواة بمدة 1.96 ثانية لكل إثبات عندما k=6، يمكن لنواة واحدة أن تولد بحد أقصى حوالي 44,000 إثبات في يوم واحد. إذا استبدلنا جميع متوسط عدد العمليات اليومية في Fedwire لعام 2025 بإثباتات k=6، نحتاج إلى حوالي 473 ساعة-نواة؛ أي ما يعادل 20 يومًا كاملاً تعمل فيها النوى دون توقف. أما CHAPS فيحتاج إلى حوالي 115 ساعة-نواة، أي أقل من 5 أيام-نواة. وتذكر مواد بنك إنجلترا لعام 2021 أن الرقم القياسي لعدد معاملات CHAPS في يوم واحد كان 320,034 معاملة بتاريخ 29 مارس 2018، أي نحو 1.7 ضعف متوسط عدد المعاملات اليومية لذلك العام؛ وبحساب هذا القمة أيضًا نحتاج فقط إلى حوالي 174 ساعة-نواة.
يجب توضيح منهجية هذا الاستنتاج. فهو يحسب وفقًا لاستهلاك «نواة واحدة لكل برهان»، بحيث تكون البرهانات مستقلة عن بعضها ويمكن توزيعها على أنوية مختلفة لتوليدها بالتوازي. إنه يحسب برهان تحويل الأموال نفسه؛ أما الإيداع والاستخراج وDvP فهي دوائر أخرى. كما أن نقل الشبكة وتسوية السلسلة (على البلوكشين) ليست ضمن ذلك. بالإضافة إلى ذلك، تقول المدونة إن البرهان يُولَّد بواسطة المُرسِل، أي أن الحمل بطبيعته موزع على عقد كل جهة على حدة، وليس مركّزًا في جهاز واحد.
إذن خلاصة قراري هي: المدونة تقول إن حجم تسوية المدفوعات بين البنوك ضمن نطاق قدرة نظام التسوية السرية، وهذا الحكم يظل صحيحًا حتى تحت الأرقام الواقعية. المدونة قدّمت حجمًا أصغر من النظام الحقيقي، لكن عند إدخال الأرقام الحقيقية في الاستنتاج يبقى صالحًا؛ وهذا يجعل مثالها في النص أقل قابلية للنقاش وأكثر إقناعًا من مثال المدونة نفسه. وفي جزء المدفوعات بالتجزئة، تعترف المدونة بنفسها أنها هي العقبة الحقيقية؛ والأرقام هنا لا تغيّر ذلك الحكم.
كيف تُستخدم هذه المجموعة من الأرقام
كل الأرقام في هذه المرة ناتجة عن نواة واحدة، ويمكن اعتبارها مرجعًا متحفظًا نسبيًا. والسبب موجود في الكود: عند توليد البرهان في gnark، فإن أثقل عملية تعدد حدود (multi-scalar multiplication) يتم تقسيمها إلى مهام متعددة وتحسب بالتوازي بحسب عدد أنوية CPU على الجهاز (يتم قراءته مباشرة عبر runtime.NumCPU() في backend/groth16/bn254/prove.go). عادةً ما تكون خوادم المؤسسات متعددة الأنوية؛ وفي هذه الحالة يتم توزيع نفس البرهان على عدد أكبر من الأنوية للعمل معًا، لذلك سيكون الزمن أقل من نتيجة النواة الواحدة هنا. مقدار السرعة يعتمد على عدد الأنوية وأداء النواة الواحدة.
نطاق القياس في هذه المقالة هو توليد برهان دائرة إثبات تحويل الأموال نفسها. وفي سلسلة الخدمة الكاملة عبر HTTP توجد أيضًا تحليلات JSON وأعباء الشبكة؛ بينما الإيداع والاستخراج وDvP هي أنواع أخرى من الدوائر. ويعني توحيد أحجام المفاتيح أن بنية الدائرة نفسها متطابقة، لكنه لا يعني أن محتوى المفاتيح متطابق، وقد تم شرح هذه النقطة سابقًا.
رأيي
عنوان المدونة هو honest math، لكن الأرقام التي يعطيها النص هي مجرد «نطاق» واحد. بعد تشغيل هذه الحسابات، النطاق صحيح، كما أن استنتاج الجزء الخاص بتسوية المدفوعات بين البنوك يبقى متماسكًا أيضًا.
ما كنت أود رؤيته أكثر هو الخطوة التالية. صفحة البينشمارك الخاصة بـ Axyl توضح شروطًا مثل لجنة من أربع عقد وكتابة معاملات بحجم 512 بايت، ومن الجدير أن تُعامَل أداء إثبات Enygma بالمثل: عند نشر الأرقام القادمة، اذكر قيمة k وتكوين العتاد؛ عندها يمكن للمؤسسات أن تعيد الإنتاج كما فعلت أنا. وهذه بالضبط هي عبارة «إعلان الأداء» التي تكون متماسكة أمام اختبارات الإنتاج كما قالت المدونة في النهاية. إعادة الإنتاج ليست صعبة، والأوامر الموجودة في لقطة الشاشة هي خطوات كاملة.
مصادر الرجوع: المدونة الرسمية لـ Rayls (Privacy has a price: the honest math behind confidential settlement at scale) (19 سبتمبر 2026)؛ GitHub raylsnetwork/rayls-sovereign-gnark-api، الالتزام 67c4c26 (تم قراءته واختباره عمليًا بتاريخ 22 سبتمبر 2026)؛ إحصاءات Fedwire Funds Service السنوية من الاحتياطي الفيدرالي (تم التحديث بتاريخ 26 يناير 2026)؛ إحصاءات الدفع والتسوية لبنك إنجلترا و(A brief introduction to RTGS and CHAPS) (طبعة 2021).