بصراحة، أول مرة رأيت هذه الاختصارات الثلاثة مصطفّة معًا، ظننت أنها ثلاثة حلول لمسألة واحدة: أيّها أسرع، وأيّها أكثر أمانًا، اختر واحدًا وانتهى الأمر. لكنني فهمت لاحقًا أن ترتيبها معًا يشبه سؤال: "أيّ أفضل: مطرقة أم مفك براغي أم مفتاح ربط؟" فالإجابة تعتمد على ما إذا كانت لديك مسمارًا أم برغيًا أم صامولة برغيّ.
إن كلّ واحدٍ منها يحل في الواقع ثلاثة مسائل تمّ خلطها معًا.
المسألة الأولى هي: أريد أن أبرهن أن شيئًا ما صحيح، لكن البيانات المطلوبة لإجراء البرهان حسّاسة للغاية، ولا أريد أن أُظهرها لك. يريد البنك إبلاغ الجهة التنظيمية أن "هذه المعاملة قانونية، وأن التفويض صحيح، ولا توجد عمليات مكررة"، لكنه لا يرغب في إدراج المبالغ وأطراف الدفع/الاستلام في السجلات. إن هذا النوع من البرهنة على الحقيقة دون كشف البيانات هو الساحة المفضلة لـ ZK. جمالها يكمن في أن الضمان يأتي من الرياضيات، لا من عبارة من قبيل: "أعدك أنني لن أطلع على الأمر". يمكن للجهة التنظيمية أو المدقق التي تحصل على مفاتيح التحقق أن تتحقق من النتيجة، لكنها لا تتمكن من الوصول إلى البيانات الأساسية. أما الثمن فواضح أيضًا: فهي تتفوق في إثبات خصائص البيانات، لكنها لا تجيد احتساب النتيجة بحيث تعمل عدة جهات معًا وهي جميعًا لا تملك بيانات كاملة، كما أنها أكثر استهلاكًا للحوسبة من النص الصريح.
المسألة الثانية مختلفة: لا يمكنني إطلاقًا فك تشفير البيانات، ومع ذلك يجب أن أجري عليها عمليات. مؤسستان تتعاملان بقيد دفع-لقيد تسليم (券款 مقابل التسوية)، وكل منهما تُقدِّم شروط الصفقة مُشفّرة، ونظام التسوية يحتاج إلى تحديد ما إذا كان الطرفان يتحدثان عن نفس الصفقة دون فك تشفير أي طرف، ثم تنفيذ التسليم. هذا هو نطاق FHE: يمكنه إجراء الحساب مباشرة على النصوص المشفرة واستخراج نتيجة مشفرة. يبدو الأمر كسحر، لكنه الآن بطيء جدًا: أبطأ من العمليات على النص الصريح بعدة مراتب من حيث الحجم، ولا يمكنه دعم التسوية الفورية عالية التردد. (أثبتت Zama في أواخر 2025 قدرتها على التمكين في سيناريوهات محددة، لكن "استخدامها في سيناريو محدد" يظل بعيدًا عن "قابلية استخدامها على نطاق مستوى المؤسسات للتسوية الشاملة".) وله أيضًا جانب أكثر تعقيدًا: في FHE التقليدي، مفتاح واحد يتحكم في "القدرة على الرؤية" و"القدرة على التلاعب/التشغيل" معًا، ولا يمكن إعطاء صلاحية قراءة فقط للتدقيق وحده—وهذا غير مريح في عالم مُنظَّم.
المسألة الثالثة مختلفة أيضًا: أحتاج إلى تشغيل منطق ما، يجب أن يكون سريعًا، وفي الوقت نفسه لا يجوز أن يطّلع من يوفّر الأجهزة على ما يتم حسابه داخلها. تريد البنوك تشغيل محرك مطابقة خاص بها على مرافق مشتركة، ولا تريد أن ترى جهة الخصم أو جهة المرفق المنطق نفسه. هنا نستخدم TEE: نضع الكود داخل "صندوق أسود" عتادي داخل المعالج، ولا يستطيع أي طرف خارجي قراءته. أكبر ميزة له هي السرعة، إذ يقترب من الأداء الأصلي، ويمكنه التعامل مع منطق معقد وبيانات ضخمة. لكنك تستبدل الثقة بمكان آخر: عليك الوثوق في مصنع الشريحة. إذا ظهرت ثغرة في العتاد أو تم العبث بسلسلة التوريد، تنهار السرية (مثلما حدثت مشكلات مُسجَّلة في Intel SGX). إضافةً إلى ذلك، هو صندوق أسود: تحصل فقط على شهادة بأن "هذه الشفرة قد تم تشغيلها"، لكن لا يمكنك التحقق مستقلًا ماذا فعلت بالضبط. وبالنسبة لمؤسسات تهتم بـ "الامتثال القابل للإثبات"، فإن هذا الاعتماد قد يكون مؤلمًا جدًا.
هل رأيت؟ الأفعال في ثلاث مسائل مختلفة: واحدة لإثبات، وواحدة للحساب، وواحدة للتشغيل. اعتبارها شيئًا واحدًا بمسميات ثلاث، هو أكثر سوء فهم شائع.
لذلك، الشيء المثير للاهتمام فعلًا ليس "أي تقنية تفوز"، بل "مشروع محدد، هل اختار الأداة الصحيحة لمشكلته؟". Enygma، أي بنية الخصوصية الخاصة بـ Rayls، مثال يمكنه أن يوضح الأمر.
طبقة المعاملات الخاصة بها مبنية على ZK، مع تبادل مفاتيح مقاوم للكوانتوم؛ تُستخدم العمليات المتجانسة فقط عند الحاجة فعليًا إلى "إجراء حساب على قيم سرّية" داخل ذلك النطاق. وTEE لا يدخل طبقة المعاملات. ليست قيمة افتراضية اخترتها عشوائيًا، بل قرار مُدروس جيدًا. المطلوب هو إفصاح انتقائي قابل للتحقق: أن يتمكن المنظمون من إثبات أن المعاملة حدثت، وأنها كانت مُخوَّلة، وأن التسوية صحيحة—مع عدم كشف التفاصيل لطرف غير ذي صلة. وهذه بالضبط مشكلة يعالجها ZK بالفطرة. والأهم أن تدقيقها إجبارِيٌّ رياضيًا: يمكن تقييد مفتاح الكشف إلى جهة تنظيمية أو جهة خصم محددة، ولا يُطَّلع إلا على الجزء المُخوَّل رؤيته. هذه ليست قاعدة يستطيع المدير تغييرها؛ بل هي قيدٌ تشفيري. لا تحتاج المؤسسة إلى الاعتماد على ثقة شركة تصنيع شريحة أو طرف منصة لحماية هذا الحد.
أما لماذا لا تستخدم FHE كطبقة معاملات؟ لأن أداؤها الحالي لا يدعم تسويات المؤسسات؛ Enygma هي بنية معيارية (modular)، وعندما تنضج يمكن إدخالها، لكن إجبارها الآن مع مبادلة أداء التسوية بالمعدل يؤدي إلى الفشل. ولماذا لا نتعامل مع TEE؟ لأن مثل هذه المؤسسات، ضمانات الرياضيات أقوى من الثقة في العتاد؛ لا يمكن تفويض "قاعدة الثقة" لجهاز مُعتمد من جهة تصنيع شريحة واحدة.
يرجى الرجوع إلى مدونة Rayls الرسمية: https://www.rayls.com/blog/the-privacy-stack-decoded-why-zk-fhe-and-encrypted-black-boxes-are-not-solving-the-same-problem
شكرًا لمشاركة Rayls، وأهم ما استفدته هو: في المرة القادمة التي ترى فيها شخصًا يضع ZK وFHE وTEE في قائمة مقارنة/ترتيب، يمكنك أولًا أن تسأله: "أي مشكلة بالضبط تحاول حلها؟". إن حددت هل المطلوب هو الإثبات أم الحساب أم التشغيل—ستظهر الإجابة من تلقاء نفسها. كما أن اختيار معمارية تضم أي التقنيات تم اختيارها تحديدًا، وأيها لم يُختَر عن عمد، غالبًا ما يوضح نية المشروع أكثر من ادعاء أنه "يجمع عددًا كبيرًا من التقنيات المتقدمة".
