فتح الكأس المقدسة: تحديات وحلول التشفير المتماثل بالكامل على السلسلة

)

الأفكار الأساسية:

1. يعد FHE بأن يكون «الكأس المقدسة للتشفير»، ولكن هناك العديد من الأداء وخبرة المطور والمخاوف الأمنية التي تحد من اعتماده الحالي.

2. كما هو موضح في الرسم أعلاه، يجب استخدام FHE جنبًا إلى جنب مع ZKPs و MPC لبناء نظام دولة مشترك سري وآمن حقًا.

3.FHE يتطور بسرعة؛ تطوير المجمعين والمكتبات والأجهزة الجديدة وما إلى ذلك. ناهيك عن أن FHE تستفيد بشكل كبير من R & D لشركات Web2 (Intel و Google و DARPA وما إلى ذلك).

4. مع نضوج FHE والنظام البيئي المحيط به، نتوقع أن تصبح عبارة «FHE التي يمكن التحقق منها» هي المعيار. قد تختار تطبيقات FHE الاستعانة بمصادر خارجية للحساب والتحقق للمعالجات المشتركة لـ FHE.

5. أحد القيود التأسيسية لـ onchain FHE هو «من يحمل مفتاح فك التشفير؟» يقدم فك تشفير العتبة و MPC حلولًا، إلا أنهما مرتبطان عمومًا بمقايضة الأمان & في الأداء.

المقدمة:

إن الطبيعة الشفافة للبلوكشين هي سلاح ذو حدين. في حين أن هناك جمالًا في انفتاحها وقابليتها للملاحظة، إلا أنها تمثل عقبة أساسية أمام تبني المؤسسات.

كانت خصوصية Onchain واحدة من أكثر المشكلات تحديًا في مجال العملات المشفرة منذ ما يقرب من عقد من الزمان. على الرغم من وجود العديد من الفرق التي تبني أنظمة تعتمد على ZK لتحقيق خصوصية onchain؛ لا يمكنهم دعم الحالة المشتركة والمشفرة. لماذا؟ الإجابة المختصرة هي أن هذه البرامج هي دالة لسلسلة من ZKPs وعلى هذا النحو، يستحيل على أي شخص تطبيق المنطق التعسفي على الحالة الحالية. ماذا يعني هذا؟ في الأساس لا يمكننا إنشاء تطبيقات الحالة المشتركة السرية (فكر في Uniswap الخاص) باستخدام ZKPs فقط.

ومع ذلك، فقد أظهرت الاختراقات الأخيرة أن الجمع بين ZKPs والتشفير المتجانس بالكامل (FHE) يمكن أن يحقق DeFi سريًا وقابل للتعميم بالكامل. كيف؟ FHE هو مجال تشفير مزدهر يتيح الحساب التعسفي على البيانات المشفرة (يبدو الأمر جنونيًا أليس كذلك؟!) كما هو موضح في الرسم أعلاه، يمكن لـ ZKPs إثبات سلامة مدخلات المستخدم والحسابات، ويمكن لـ FHE معالجة الحساب نفسه.

بينما يعد FHE بأن يكون «الكأس المقدسة للتشفير»، فإننا نحاول تقديم تحليل موضوعي للمجال وتحدياته المختلفة والحلول الممكنة. نحن نغطي موضوعات FHE التالية على السلسلة:

• مخططات FHE والمكتبات والمجمعين
• فك تشفير العتبة الآمنة
• ملفات ZKPs لمدخلات المستخدم+حفلة الحوسبة
• طبقة DA قابلة للبرمجة وقابلة للتطوير
• الأجهزة

مخططات FHE والمكتبات والمجمعين

التحدي: مخططات FHE الناشئة والمكتبات والمجمعين

تكمن العقبة التأسيسية لـ onchain FHE في أدوات/البنية التحتية للمطورين المتخلفين. على عكس ZKPs أو MPC، كان FHE موجودًا فقط منذ عام 2009، وبالتالي كان لديه جدول زمني أقصر بكثير حتى ينضج.

القيود الأساسية في FHE DevEx هي:

• لغة واجهة أمامية سهلة الاستخدام للمطورين للترميز دون معرفة كبيرة بالتشفير الخلفي
• مترجم FHE يعمل بكامل طاقته ويمكنه التعامل مع جميع الأعمال القذرة. (اختيار المعلمات وتحسين SIMD لـ BGV/BFV والتحسين المتوازي)
• تعد مخططات FHE الحالية (خاصة TFHE) أبطأ بحوالي 1000 مرة مقارنة بالحساب العادي

لفهم تعقيدات دمج FHE حقًا، دعنا ننتقل إلى رحلة المطور:

الخطوة الأولى لدمج FHE في تطبيقك هي اختيار مخطط FHE لاستخدامه. يوضح المخطط التالي المخططات الأساسية:

كما هو موضح في الجدول أعلاه، تتمتع الدوائر المنطقية مثل FHEW & TFHE بأسرع عملية تمهيد ويمكنها تجنب إجراءات اختيار المعلمات المعقدة نوعًا ما، ويمكن استخدامها في الحسابات التعسفية/العامة ولكنها بطيئة نسبيًا؛ في حين أن BGV/BFV يمكن أن تكون مناسبة لـ DeFi العام لأنها أكثر كفاءة في الحسابات الحسابية عالية الدقة، ولكن يجب على المطورين معرفة عمق الدائرة مسبقًا لإعداد جميع معايير المخطط. على الطرف الآخر من الطيف، يدعم CKKS الضرب المتماثل حيث يُسمح بأخطاء الدقة، مما يجعله مثاليًا لحالات الاستخدام غير الدقيقة مثل ML.

بصفتك مطورًا، تحتاج إلى اختيار حل FHE بعناية فائقة لأنه سيؤثر على جميع قرارات التصميم الأخرى والأداء المستقبلي. بالإضافة إلى ذلك، هناك العديد من المعلمات الرئيسية التي تعتبر ضرورية لإعداد مخطط FHE بشكل صحيح، مثل اختيار حجم الوحدة ودور الدرجة متعددة الحدود.

بالانتقال إلى المكتبات، يمكن رؤية ميزات وإمكانيات مكتبات FHE الشهيرة من الجدول أدناه:

لكن للمكتبات أيضًا علاقات مختلفة مع المخططات والمجمعين كما هو موضح أدناه:

بعد تحديد حل FHE، يحتاج المطورون إلى تعيين المعلمات. سيكون للاختيار الصحيح للمعلمات تأثير كبير على أداء مخطط FHE. والأمر الأكثر صعوبة هو أن هذا يتطلب بعض الفهم للجبر المجرد، والعمليات الخاصة بـ FHE مثل إعادة الخطية والتحويل التناظري إلى الرقمي، والدوائر الحسابية أو الثنائية. أخيرًا، من أجل الاختيار الفعال للمعلمات، يلزم فهم مفاهيمي لكيفية تأثيرها على مخطط FHE.

في هذه المرحلة، قد يسأل المطورون:

ما هو حجم مساحة النص العادي الخاصة بي؟ ما حجم النصوص المشفرة المقبولة؟ أين يمكنني موازنة الحساب؟ وأكثر من ذلك بكثير...

بالإضافة إلى ذلك، على الرغم من أن FHE يمكن أن يدعم الحسابات التعسفية، إلا أن المطورين بحاجة إلى تغيير طريقة تفكيرهم عند كتابة برامج FHE. على سبيل المثال، لا يمكن للمرء كتابة فرع (if-else) اعتمادًا على متغير في البرنامج، لأن البرامج لا يمكنها مقارنة المتغيرات مباشرة مثل البيانات العادية. بدلاً من ذلك، يحتاج المطورون إلى تغيير التعليمات البرمجية الخاصة بهم من الفروع إلى نوع من الحسابات التي يمكن أن تتضمن شروط جميع الفروع. وبالمثل، يمنع هذا المطورين من كتابة الحلقات في التعليمات البرمجية الخاصة بهم.

باختصار، بالنسبة للمطور غير المبتدئ في FHE، يكاد يكون من المستحيل دمج FHE في تطبيقه. سيتطلب الأمر أدوات/بنية أساسية كبيرة لتجريد التعقيدات التي قدمتها FHE.

الحل:

1. برامج تجميع ملفات THE الخاصة بـ Web3

على الرغم من وجود برامج تحويل FHE بالفعل بواسطة شركات مثل Google و Microsoft، إلا أنها:

• لم يتم تصميمه مع وضع الأداء في الاعتبار، حيث يضيف 1000 مرة من النفقات الإضافية مقابل دوائر الكتابة مباشرة
• مُحسَّن لـ CKKS (المعروف أيضًا باسم ML) وليس مفيدًا لـ BFV/BGV المطلوب لـ DeFi
• لم يتم تصميمه لـ Web3. لا يدعم التوافق مع مخططات ZKP وتسلسل البرامج وما إلى ذلك.

هذا حتى مترجم واقي الشمس FHE. إنه مترجم أصلي لـ Web3 يقدم بعضًا من أفضل الأداء للعمليات الحسابية (فكر في DeFi) بدون مسرعات الأجهزة. كما نوقش أعلاه، يمكن القول إن اختيار المعلمات هو الجزء الأكثر صعوبة في تنفيذ مخطط FHE؛ لا يقتصر دور Suncreen على الاختيار الآلي للمعلمات فحسب، بل يقوم أيضًا بترميز البيانات واختيار المفاتيح وتنفيذ عمليات إعادة الخطية وتبديل المعامل وإعداد الدوائر وتنفيذ عمليات نمط SIMD.

مع انتقالنا إلى المستقبل، نتوقع رؤية المزيد من التحسينات ليس فقط في مترجم Suncreen، ولكن أيضًا في الفرق الأخرى التي تبني تطبيقاتها الخاصة التي تدعم اللغات الأخرى عالية المستوى.

1. مكتبة FHE الجديدة

بينما يواصل الباحثون استكشاف مخططات قوية جديدة، يمكن لمكتبات FHE تمكين المزيد من المطورين من دمج FHE.

لنأخذ العقود الذكية FHE كمثال. على الرغم من أنه قد يكون من الصعب الاختيار من بين مكتبات FHE المختلفة، إلا أن الأمر يصبح أسهل عندما نتحدث عن onchain FHE نظرًا لوجود عدد قليل فقط من لغات البرمجة المهيمنة عبر Web3.

على سبيل المثال، تدمج FHeVM من Zama مكتبة Zama مفتوحة المصدر TFHE-RS في EVM نموذجي، مما يعرض العمليات المتجانسة كعقود مجمعة مسبقًا. تمكين المطورين بشكل فعال من استخدام البيانات المشفرة في عقودهم، دون أي تغييرات على أدوات التجميع.

بالنسبة لسيناريوهات محددة أخرى، قد تكون هناك حاجة إلى بعض البنية التحتية الأخرى. على سبيل المثال، لا تتم صيانة مكتبة TFHE المكتوبة بلغة C ++ بشكل جيد مثل إصدار Rust. على الرغم من أن TFHE-RS يمكنها دعم عمليات التصدير لـ C/C ++، إذا كان مطورو C ++ يريدون توافقًا وأداءً أفضل، فيجب عليهم كتابة نسختهم الخاصة من مكتبة TFHE.

أخيرًا، السبب الأساسي لنقص البنية التحتية لـ FHE في السوق هو أننا نفتقر إلى طرق فعالة لبناء FHE-RAM. أحد الحلول الممكنة هو العمل على FHE-EVM بدون رموز تشغيل معينة.

فك تشفير العتبة الآمنة

التحدي: فك تشفير العتبة غير الآمن/المركزي

يعتمد كل نظام سري ومشترك على مفتاح تشفير/فك تشفير. لا يمكن الوثوق بأي طرف واحد، وبالتالي يتم مشاركة مفتاح فك التشفير بين المشاركين في الشبكة.

أحد الجوانب الأكثر تحديًا في onchain FHE (Threshold FHE) هو بناء بروتوكول فك تشفير عتبة آمن وفعال. هناك نوعان من الاختناقات الأساسية: (1) يؤدي الحساب المستند إلى FHE إلى عبء كبير، وبالتالي يتطلب عقدًا عالية الأداء تقلل بطبيعتها الحجم المحتمل لمجموعة المدققين (2) مع زيادة عدد العقد المشاركة في بروتوكول فك التشفير، يزداد وقت الاستجابة.

في الوقت الحالي على الأقل، تعتمد بروتوكولات FHE على أغلبية صادقة بين المدققين، ولكن كما هو مذكور أعلاه، تشير Threshold FHE إلى مجموعة مدققين أصغر وبالتالي احتمالية أكبر للتواطؤ والسلوك الضار.

ماذا لو تواطأت العقد الحدية؟ سيكون بإمكانهم تجاوز البروتوكول وفك تشفير أي شيء بشكل أساسي، من مدخلات المستخدم إلى أي بيانات onchain. بالإضافة إلى ذلك، من المهم ملاحظة أن بروتوكول فك التشفير يمكن أن يحدث بشكل غير قابل للكشف في الأنظمة الحالية (المعروف أيضًا باسم «الهجوم الصامت»).

الحل: تحسين فك تشفير العتبة أو MPC الديناميكي

هناك عدة طرق ربما لمعالجة أوجه القصور في فك تشفير العتبة. (1) تمكين عتبة n/2 التي من شأنها أن تزيد من صعوبة التواطؤ (2) قم بتشغيل بروتوكول فك تشفير العتبة داخل HSM (3) استخدم شبكة فك تشفير العتبة القائمة على TEE والتي يتم التحكم فيها بواسطة سلسلة لامركزية للمصادقة مما يسمح بإدارة المفاتيح الديناميكية.

بدلاً من الاستفادة من فك تشفير العتبة، من الممكن استخدام MPC بدلاً من ذلك. مثال على بروتوكول MPC الذي يمكن استخدامه في onchain FHE يتضمن 2PC-MPC الجديد من Odsy، وهو أول خوارزمية MPC غير متواطئة وغير مركزية على نطاق واسع.

يمكن أن يكون الأسلوب المختلف هو استخدام المفتاح العام للمستخدم فقط لتشفير البيانات. يقوم المدققون بعد ذلك بمعالجة العمليات المتجانسة، ويمكن للمستخدمين أنفسهم فك تشفير النتيجة إذا لزم الأمر. في حين أنه ممكن فقط لحالات الاستخدام المتخصصة، يمكننا تجنب افتراض العتبة تمامًا.

للتلخيص، يحتاج onchain FHE إلى تطبيق MPC فعال يقوم بما يلي: (1) يعمل حتى في حالة وجود جهات ضارة (2) يوفر الحد الأدنى من زمن الوصول (3) يتيح الدخول غير المرن/المرن للعقد.

إثبات المعرفة الصفرية (ZKP) لإدخال المستخدم وحزب الحوسبة

التحدي: إمكانية التحقق من مدخلات المستخدم + الحساب:

في web2، عندما نطلب تنفيذ مهمة حسابية، فإننا نثق تمامًا في أن شركة معينة ستدير المهمة تمامًا كما وعدت وراء الكواليس. في web3، انقلب النموذج تمامًا؛ فبدلاً من الاعتماد على سمعة الشركة والثقة ببساطة في أنها ستتصرف بأمانة، نحن نعمل الآن في بيئة غير موثوقة، مما يعني أنه لا ينبغي على المستخدمين الوثوق بأي شخص.

بينما يتيح FHE معالجة البيانات المشفرة، فإنه لا يمكنه التحقق من صحة مدخلات المستخدم أو الحساب. وبدون القدرة على التحقق من أي منهما، لا يكاد يكون FHE مفيدًا في سياق بلوكتشين.

الحل: ملفات ZKPs لمدخلات المستخدم+ حفلة الحوسبة:

بينما يمكّن FHE أي شخص من إجراء حسابات عشوائية على البيانات المشفرة، تسمح ZKPs للمرء بإثبات صحة شيء ما دون الكشف عن المعلومات الأساسية نفسها. إذن كيف يرتبطون؟

هناك ثلاث طرق رئيسية تتناسب بها FHE و ZKPs معًا:

1. يحتاج المستخدم إلى تقديم دليل على أن النص المشفر للإدخال الخاص به قد تم تكوينه جيدًا. بمعنى أن النص المشفر يلبي متطلبات نظام التشفير وليس مجرد سلاسل عشوائية من البيانات.
2. يحتاج المستخدم إلى تقديم دليل على أن النص العادي الذي أدخله يفي بشروط تطبيق معين. مثال: المبلغ والرصيد > المبلغ المحول
3. تحتاج عقدة المدقق (المعروفة أيضًا باسم طرف الحوسبة) إلى إثبات أنها نفذت حساب FHE بشكل صحيح. يشار إلى هذا باسم «FHE الذي يمكن التحقق منه» ويمكن اعتباره مشابهًا لـ ZKPs اللازمة للتجميع.

لمزيد من استكشاف تطبيقات ZKP:

1. ZIP أو النص المشفر

تم بناء FHE على التشفير القائم على الشبكة، مما يعني أن بناء التشفير البدائي يتضمن المشابك، وهي آمنة PQ (ما بعد الكم). في المقابل، لا تعتمد ملفات ZKP الشائعة مثل SNARKS و STARKS و Bulletproof على التشفير القائم على الشبكة.

لإثبات أن النص المشفر FHE للمستخدم جيد التكوين، نحتاج إلى إثبات أنه يفي ببعض معادلات متجه المصفوفة بإدخالات من الحلقات، وأن القيم العددية لهذه العناصر صغيرة. في الأساس، نحتاج إلى نظام إثبات للتحقق على السلسلة فعال من حيث التكلفة مصمم للتعامل مع العلاقات القائمة على الشبكة، وهو مجال مفتوح للبحث.

1. ZKP لإدخال النص العادي

بالإضافة إلى إثبات وجود نص مشفر جيد التكوين، يحتاج المستخدم إلى إثبات أن النص العادي الذي أدخله يفي بمتطلبات التطبيق. لحسن الحظ، على عكس الخطوة السابقة، يمكننا استخدام SNarks العامة لإثبات الصلاحية حول مدخلات المستخدم، وبالتالي تمكين المطورين من الاستفادة من مخططات ZKP والمكتبات والبنية التحتية الحالية.

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

وضعت Suncreen أيضًا الأساس مع مترجم ZKP الخاص بها الذي يوفر الدعم لـ Bulletproofs لأنه يتصل بسهولة مع SDLP. يتم التطوير المستقبلي «لربط» مترجم FHE و ZKP.

كانت Mind Network رائدة في دمج ZKPs لضمان مدخلات ومخرجات انعدام الثقة جنبًا إلى جنب مع الاستفادة من FHE للحساب الآمن.

1. ZKP للحساب الصحيح

يعد تشغيل FHE على الأجهزة الموجودة غير فعال ومكلف للغاية. وكما رأينا ديناميكية معضلة قابلية التوسع التي ظهرت من قبل، فإن الشبكات ذات المتطلبات الأعلى لموارد العقدة لا يمكن أن تتوسع إلى مستوى كافٍ من اللامركزية. يمكن أن يكون الحل المحتمل هو عملية تسمى «FHE القابل للتحقق»، وهي عملية يقوم فيها الطرف الحسابي (المدقق) بتقديم ZKP لإثبات التنفيذ الصادق للمعاملات.

يمكن عرض نموذج أولي مبكر من FHE الذي يمكن التحقق منه من خلال مشروع يسمى SherLocked. يتم تفريغ حساب FHE بشكل أساسي إلى Risc ZERO's Bonsai الذي يعالج الحساب عبر البيانات المشفرة خارج السلسلة ويعيد النتيجة باستخدام ZKP ويقوم بتحديث الحالة على السلسلة.

يمكن رؤية مثال حديث للاستفادة من المعالج الثانوي FHE من خلال العرض التوضيحي لمزاد Aztec onchain. كما ذكرنا سابقًا، تقوم سلاسل FHE الحالية بتشفير الحالة بأكملها باستخدام مفتاح عتبة، مما يعني أن النظام قوي فقط مثل لجنة العتبة الخاصة به. على العكس من ذلك، في Aztec، يمتلك المستخدم بياناته الخاصة، وبالتالي لا يخضع لافتراض الحد الأدنى للأمان.

أخيرًا، من المهم التطرق إلى المكان الذي يمكن للمطور فيه إنشاء تطبيق FHE في المقام الأول. يمكن للمطورين بناء تطبيقاتهم إما على L1 الذي يعمل بنظام FHE أو مجموعة FHE أو البناء على أي سلسلة EVM والاستفادة من المعالج الثانوي FHE. يأتي كل تصميم مع مجموعة المقايضات الخاصة به، ولكننا نميل أكثر نحو مجموعات FHE المصممة جيدًا (التي ابتكرتها Fhenix) أو معالجات FHE لأنها ترث الأمان من Ethereum من بين مزايا أخرى.

حتى وقت قريب، كان تحقيق أدلة الاحتيال على بيانات FHE المشفرة أمرًا معقدًا، ولكن مؤخرًا أظهر الفريق في Fhenix.io كيفية تحقيق أدلة الاحتيال باستخدام مكدس Arbitrum Nitro المقترن بالتجميع المنطقي لـ FHE إلى WebAssembly.

طبقة توفر البيانات (DA) من FHE

التحدي: عدم قابلية التخصيص والإنتاجية

بينما تم تحويل التخزين إلى سلعة في web2، فإن الشيء نفسه لا ينطبق في Web3. نظرًا لأن FHE يحتفظ بتضخم كبير للبيانات يصل إلى 10,000 x+، نحتاج إلى معرفة مكان تخزين نصوص FHE المشفرة الكبيرة. إذا قام كل مشغل عقدة في طبقة DA معينة بتنزيل وتخزين كل بيانات سلسلة FHE، فلن يتمكن سوى المشغلين المؤسسيين من مواكبة الطلب، مما يخاطر بالمركزية.

فيما يتعلق بالإنتاجية، تصل سرعة Celestia إلى 6.7 ميجابايت/ثانية، إذا أردنا تشغيل أي نموذج FHEML، فسنحتاج بسهولة إلى n جيجابايت+/ثانية. وفقًا للبيانات الحديثة التي تمت مشاركتها بواسطة 1k (x)، لا يمكن لطبقات DA الحالية دعم FHE بسبب قرارات التصميم التي تحد من الإنتاجية (عن قصد).

الحل: التحجيم الأفقي+التخصيص

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

بشكل منفصل، نظرًا لحجم البيانات الكبير المرتبط بـ FHE، سيكون من المنطقي تقديم مستوى أعلى من التخصيص للمطورين حول حدود تشفير المحو. أي ما مقدار نظام DA الذي تشعر بالراحة عند الحصول على ضمان معه؟ سواء كان الترجيح على أساس الحصة أو الترجيح القائم على اللامركزية.

تعمل بنية eiGenda كأساس لما يمكن أن تبدو عليه طبقة DA لـ FHE. إن خصائص التحجيم الأفقي، وخفض التكلفة الهيكلية، وفصل DA والإجماع وما إلى ذلك.. كلها تفسح المجال لمستوى من قابلية التوسع يمكن أن يدعم FHE يومًا ما.

أخيرًا، يمكن أن تتمثل الفكرة عالية المستوى في إنشاء فتحات تخزين محسّنة لتخزين النصوص المشفرة لـ FHE نظرًا لأن النصوص المشفرة تتبع نظام تشفير معين، لذا فإن وجود فتحات تخزين محسّنة قد يساعد في الاستخدام الفعال للتخزين والاسترجاع بشكل أسرع.

أجهزة التشفير المتماثل بالكامل (FHE)

التحدي: أجهزة FHE منخفضة الأداء

في الترويج لتطبيقات التشفير المتماثل بالكامل (FHE) على السلسلة، تتمثل المشكلة الرئيسية في وقت الاستجابة الكبير بسبب الحمل الحسابي، مما يجعل تشغيل FHE غير عملي على أي جهاز معالجة قياسي. ينبع هذا القيد من الكم الكبير من التفاعل مع الذاكرة بسبب الكم الهائل من البيانات التي يحتاج المعالج إلى معالجتها. بالإضافة إلى تفاعلات الذاكرة، فإن الحسابات المعقدة متعددة الحدود وعمليات صيانة النص المشفر التي تستغرق وقتًا طويلاً تجلب أيضًا الكثير من النفقات العامة.

لمزيد من فهم حالة مسرعات FHE، نحتاج إلى الكشف عن مساحة التصميم: مسرعات FHE الخاصة بالتطبيق مقابل مسرعات FHE القابلة للتعميم.

يرتبط جوهر تعقيد الحساب وتصميم الأجهزة لـ FHE دائمًا بعدد المضاعفات اللازمة لتطبيق معين، ويشار إليه باسم «عمق التشغيل المتماثل». في الحالة الخاصة بالتطبيق، يكون العمق معروفًا، لذلك يتم إصلاح معلمات النظام والحسابات ذات الصلة. لذلك، سيكون تصميم الأجهزة لهذه الحالة الخاصة بالتطبيق أسهل ويمكن عادةً تحسينه للحصول على أداء أفضل من تصميم المسرع القابل للتعميم. في الحالة العامة، حيث يكون FHE مطلوبًا لدعم عدد تعسفي من المضاعفات، يلزم التمهيد لإزالة جزء من الضوضاء المتراكمة في العمليات المتجانسة. يعد Bootstrapping مكلفًا ويتطلب موارد كبيرة للأجهزة بما في ذلك الذاكرة الموجودة على الرقاقة وعرض النطاق الترددي للذاكرة والحساب، مما يعني أن تصميم الأجهزة سيكون مختلفًا تمامًا عن التصميم الخاص بالتطبيق. وبالتالي، في حين أن العمل الذي يقوم به اللاعبون الرئيسيون في الفضاء، بما في ذلك أمثال Intel و Duality و SRI و DARPA والعديد من الشركات الأخرى، لا شك أنه يتجاوز الحدود مع تصميماتهم القائمة على GPU و ASIC، إلا أنها قد لا تكون قابلة للتطبيق بنسبة 1:1 لدعم حالات استخدام بلوكتشين.

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

من المهم ملاحظة أن تسريع onchain FHE أصعب بكثير من حالات الاستخدام الخاصة بالتطبيق (على سبيل المثال FHEML) لأنه يتطلب القدرة على معالجة حسابات أكثر عمومية مقابل مجموعة أكثر تخصصًا. للتوضيح، فإن fHeVM devnet مقيد بـ TPS المكون من رقم واحد في الوقت الحالي.

نظرًا لأننا نحتاج إلى مسرّع FHE المصمم خصيصًا لبلوكتشين، هناك اعتبار آخر هو مدى قابلية نقل العمل من أجهزة ZKP إلى أجهزة FHE؟

هناك بعض الوحدات المشتركة بين ZKP و FHE، مثل التحويل النظري للأرقام (NTT) والعمليات متعددة الحدود الأساسية. ومع ذلك، يختلف عرض البت لـ NTT المستخدم في هاتين الحالتين. في ZKP، يحتاج الجهاز إلى دعم نطاق واسع من عرض البت لـ NTT، مثل 64 بت و 256 بت، بينما في FHE، تكون معاملات NTT أقصر نظرًا لتمثيلها في نظام الأرقام المتبقية. ثانيًا، درجة NTT التي يتم التعامل معها في ZKP أعلى بشكل عام من درجة حالة FHE. بسبب هذين السببين، ليس من السهل تصميم وحدة NTT التي تحقق أداءً مرضيًا لكل من ZKP و FHE. بخلاف NTT، هناك بعض الاختناقات الحاسوبية الأخرى في FHE، مثل automorphism، والتي لا توجد في ZKPs. تتمثل إحدى الطرق الساذجة لنقل أجهزة ZKP إلى إعداد FHE في إلغاء تحميل مهمة الحوسبة NTT إلى أجهزة ZKP واستخدام وحدة المعالجة المركزية أو الأجهزة الأخرى للتعامل مع بقية العمليات الحسابية في FHE.

للتغلب على التحديات، كانت الحوسبة على البيانات المشفرة باستخدام FHE أبطأ بـ 100,000 مرة من البيانات ذات النص العادي. ومع ذلك، بفضل أنظمة التشفير الأحدث والتطورات الأخيرة في أجهزة FHE، تحسن الأداء الحالي بشكل كبير إلى حوالي 100 مرة أبطأ من بيانات النص العادي.

حلول:

1. تحسين في أجهزة FHE

هناك العديد من الفرق التي تعمل بنشاط على بناء مسرعات FHE، ومع ذلك، فإنها لا تعمل على مسرعات FHE الخاصة بحوسبة blockchain القابلة للتعميم (أي THE). يُعد FPT، وهو مسرّع FGA ذو النقطة الثابتة، مثالاً على مسرّع الأجهزة الخاص بتقنية البلوكشين. FPT هو أول مسرّع للأجهزة يستغل بشكل كبير الضوضاء المتأصلة الموجودة في حسابات FHE من خلال تنفيذ TFHE bootstrapping بالكامل باستخدام حساب تقريبي للنقطة الثابتة. مشروع آخر يمكن أن يكون مفيدًا لـ FHE هو BASALISC، وهي عائلة معمارية من مسرعات الأجهزة التي تهدف إلى تسريع حسابات FHE بشكل كبير في السحابة.

كما أشرنا سابقًا، فإن أحد الاختناقات الأساسية في تصميم أجهزة FHE هو التفاعل الهائل مع الذاكرة. للتحايل على هذا الحاجز، يتمثل الحل المحتمل في تقليل التفاعل مع الذاكرة قدر الإمكان. ربما تكون المعالجة في الذاكرة (PIM) أو حساب الذاكرة القريبة مفيدة في هذا السيناريو. يعد PIM حلاً واعدًا لمواجهة تحديات «جدار الذاكرة» لأنظمة الكمبيوتر المستقبلية، مما يسمح للذاكرة بخدمة وظائف الحساب والذاكرة، مما يعد بتجديد جذري للعلاقة بين الحساب والذاكرة. في العقد الماضي، تم إحراز تقدم هائل في تصميم الذكريات غير المتطايرة لهذا الغرض، مثل ذاكرة الوصول العشوائي المقاومة وذاكرة الوصول العشوائي المغناطيسية لعزم الدوران وذاكرة تغيير الطور. باستخدام هذه الذاكرة الخاصة، كان هناك عمل يُظهر تحسنًا كبيرًا في الحساب في التعلم الآلي وتشفير المفتاح العام المستند إلى الشبكة.

1. برامج وأجهزة محسّنة

في التطورات الأخيرة، تم الاعتراف بالبرمجيات كمكون حاسم في عملية تسريع الأجهزة. على سبيل المثال، تستخدم مسرعات FHE البارزة مثل F1 و CraterLake المجمّعات لنهج التصميم المشترك للبرامج/الأجهزة الهجينة.

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

1. مسرعات شبكات FHE: التحول من التوسع إلى التوسع

تركز جهود تسريع أجهزة FHE الحالية بشكل كبير على «التوسع»، مما يعني التركيز على تحسين مسرع واحد عموديًا. من ناحية أخرى، تركز أماكن «التوسع» على توصيل العديد من مسرعات FHE من خلال التواصل أفقيًا، الأمر الذي يمكن أن يحسن الأداء بشكل كبير، على غرار التوليد المتوازي مع ZKPs.

تتمثل إحدى الصعوبات الأساسية في تسريع FHE في مشكلة تضخم البيانات: تشير إلى الزيادة الكبيرة في حجم البيانات التي تحدث أثناء التشفير والحساب، مما يشكل تحديات لحركة البيانات الفعالة بين الذكريات الموجودة على الرقاقة وخارجها.

يشكل تضخم البيانات تحديًا كبيرًا لربط العديد من مسرعات FHE عبر الشبكات أفقيًا. لذلك، سيكون التصميم المشترك للأجهزة والشبكات من FHE اتجاهًا واعدًا للبحث في المستقبل. يمكن أن يتضمن أحد الأمثلة توجيه الشبكة التكيفي لمسرعات FHE: تنفيذ آلية توجيه تقوم بضبط مسارات البيانات ديناميكيًا بين مسرعات FHE استنادًا إلى الحمل الحسابي في الوقت الفعلي وحركة مرور الشبكة. وهذا من شأنه أن يضمن معدلات نقل البيانات المثلى والاستخدام الفعال للموارد.

الخاتمة

ستقوم FHE بشكل أساسي بإعادة تصور الطريقة التي نقوم بها بتأمين البيانات عبر المنصات، مما يمهد الطريق لعصر جديد من الخصوصية غير المسبوقة. سيتطلب بناء مثل هذا النظام تقدمًا كبيرًا ليس فقط في FHE، ولكن في ZKPs و MPC أيضًا.

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

في نهاية المطاف، ستقف FHE في طليعة الموجة التحويلية للسيادة الرقمية، مما يبشر بمستقبل لم تعد فيه خصوصية البيانات وأمانها متنافيين ولكن موحدين بشكل لا ينفصم.

شكر خاص：

شكراً جزيلاً لماسون سونغ (مايند نتورك)، جاي إيتزاكي (فينيكس)، ليو فان (Cysic)، كورت بان، شيانغ شي (PADO)، نيتانشو لوخاندي (BananaHQ) للمراجعة. نتطلع إلى القراءة عن العمل الرائع والجهود التي يبذلها هؤلاء الأفراد في هذا المجال!

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [HashKey Capital]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [جيفري هو، أرناف باجيديالا]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.