كل الطرق تؤدي إلى MPC؟ استكشاف نهاية اللعبة للبنية التحتية للخصوصية

المؤلف: EQ Labs المصدر: equilibrium الترجمة: Shan Oppa, Golden Finance

رقم سلسلة الخصوصية لدينا الجزء. 1 يشرح ما تعنيه "الخصوصية"، وكيف تختلف الخصوصية في شبكات blockchain عن خصوصية web2، ولماذا يصعب تحقيق الخصوصية في blockchain.

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

تخلص من الماضي واحتضن المستقبل

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

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

• < strong>الحالة المخفية: تتطلب الغالبية العظمى من حالات الاستخدام المالي السرية من (على الأقل) مستخدمين آخرين، وستكون العديد من الألعاب متعددة اللاعبين أقل إثارة للاهتمام بشكل ملحوظ بدون بعض الحالات المخفية (على سبيل المثال، إذا كان بإمكان الجميع رؤية بطاقات بعضهم البعض ).  

• إخفاء المنطق: تتطلب بعض حالات الاستخدام إخفاء بعض المنطق مع السماح للآخرين باستخدامه التطبيقات، مثل محركات المطابقة، واستراتيجيات التداول عبر السلسلة، وما إلى ذلك.

يُظهر التحليل التجريبي (من web2 وweb3) أن معظم المستخدمين غير راغبين في دفع المزيد أو التخطي لزيادة الخصوصية كمكافأة ، ونحن نتفق أيضًا على أن الخصوصية في حد ذاتها ليست نقطة بيع. ومع ذلك، فهو يمكّن من وجود حالات استخدام جديدة (ونأمل) ذات معنى أكبر فوق blockchain – مما يخرجنا من مفارقة فيرمي.

تقنية تعزيز الخصوصية (PET) وحلول كلمات المرور الحديثة("كلمات المرور القابلة للبرمجة ” )هي اللبنات الأساسية لتحقيق هذه الرؤية(لمزيد من المعلومات حول الحلول المختلفة المتاحة والمقايضات الخاصة بها، راجعالملحق < /م>).

ثلاثة افتراضات تؤثر على وجهات نظرنا

ثلاثة افتراضات رئيسية تحدد وجهة نظرنا للمنطقة أ انظر إلى كيفية تطور البنية التحتية لخصوصية blockchain:

1. سوف ينتقل التشفير من مطوري التطبيقات إلى التجريد في اليد: لا يريد معظم مطوري التطبيقات (أو لا يعرفون كيفية التعامل مع) التشفير المطلوب للتعامل مع الخصوصية. نتوقع منهم تنفيذ التشفير الخاص بهم وإنشاء سلاسل خاصة بتطبيقات محددة (مثل Zcash أو Namada) أو تطبيقات خاصة فوق السلاسل العامة(مثل Tornado Cash) فهي غير معقولة. وهذا ببساطة معقد للغاية ومكلف، ويحد حاليًا من مساحة التصميم لمعظم المطورين (عدم القدرة على إنشاء تطبيقات تتطلب ضمانات خصوصية معينة). لذلك، نعتقد أن تعقيد إدارة جزء التشفير يجب أن يتم إبعاده عن أيدي مطوري التطبيقات. هناك طريقتان هنا هما البنية التحتية للخصوصية القابلة للبرمجة (L1/L2 الخاصة المشتركة) أو الأسرار كخدمة، والتي تسمح بالاستعانة بمصادر خارجية للحسابات السرية.

2. تتطلب العديد من حالات الاستخدام (ربما أكثر مما نعتقد) حالة خاصة مشتركة: كما ذكرنا سابقًا، تتطلب العديد من التطبيقات بعض الحالة المخفية و / أو المنطق مطلوب ليعمل بشكل صحيح. الحالة الخاصة المشتركة هي مجموعة فرعية حيث تقوم أطراف متعددة بإجراء عمليات حسابية على نفس الحالة الخاصة. وفي حين يمكننا أن نثق في حزب مركزي للقيام بذلك نيابةً عنا وترك الأمر عند هذا الحد، فمن الناحية المثالية نريد أن نفعل ذلك بطريقة تقلل من الثقة لتجنب نقطة فشل واحدة. لا يمكن لإثباتات المعرفة الصفرية (ZKP) وحدها تحقيق ذلك - نحتاج إلى الاستفادة من الأدوات الأخرى مثل بيئات التنفيذ الموثوقة (TEE)، والتشفير المتماثل بالكامل (FHE) و/أو الحوسبة متعددة الأطراف (MPC).  

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

نهاية البنية التحتية للخصوصية

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

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

في الوقت الحالي، الطريقتان الأكثر شيوعًا لبناء البنية التحتية للخصوصية في blockchain هما الاستفادة من ZKP أو FHE. ومع ذلك، كلاهما به عيوب أساسية:

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

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

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

لاحظ أنه على الرغم من أن النهجين سيتقاربان في النهاية، إلا أن MPC يخدم غرضًا مختلفًا:

• شبكة ZKP: تعمل MPC على زيادة القدرة التعبيرية من خلال تنفيذ حسابات الحالات الخاصة المشتركة.

• شبكة FHE: تعمل MPC على تحسين الأمان من خلال توزيع مفاتيح فك التشفير على لجنة MPC بدلاً من طرف ثالث واحد وتعزيز حماية الخصوصية.

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

1. ما مدى قوة ضمان الخصوصية الذي يمكن أن يوفره بروتوكول MPC في blockchain؟

2. هل التكنولوجيا ناضجة بما فيه الكفاية؟ إذا لم يكن الأمر كذلك، ما هو عنق الزجاجة؟

3. بالنظر إلى قوة الضمان والنفقات العامة التي يقدمها، هل هذا منطقي مقارنة بالمناهج الأخرى؟

دعونا نجيب على هذه الأسئلة بمزيد من التفاصيل.

استخدام MPC لتحليل المخاطر ونقاط الضعف

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

المصدر: زاما في الكلام في ETH CC

الخطر الرئيسي لـ MPC هو التواطؤ، أي تواطؤ عدد كافٍ من الأطراف بشكل ضار لفك تشفير البيانات أو سرقة الحسابات. يمكن الاتفاق على التواطؤ خارج السلسلة ولا يتم الكشف عنه إلا عندما يتخذ طرف ضار بعض الإجراءات الواضحة (الابتزاز، وسك الرموز المميزة من لا شيء، وما إلى ذلك). وغني عن القول أن هذا له آثار كبيرة على ضمانات الخصوصية التي يمكن للنظام توفيرها. يعتمد خطر التواطؤ على:

• كم عدد الأطراف الضارة التي يمكن للبروتوكول أن يتحملها؟

• ما هي الأحزاب التي تتكون منها الشبكة؟ ما مدى جدارتهم بالثقة؟

• عدد الأطراف المختلفة المشاركة في الشبكة وتوزيعها - هل هناك نواقل هجوم مشتركة؟

• هل الشبكة غير مسموح بها أو مسموح بها (الفوائد الاقتصادية والسمعة/الأساس القانوني)؟

• ما هي عقوبات السلوك الضار؟ هل لعبة التواطؤ هي النتيجة الأمثل من الناحية النظرية؟

1. ما مدى قوة ضمان الخصوصية الذي يمكن أن يوفره بروتوكول MPC في blockchain؟

TLDR: ليس بالقوة التي نرغب فيها، ولكنه أقوى من الاعتماد على طرف ثالث مركزي.  

يعتمد الحد المطلوب لفك التشفير على مخطط MPC المختار - إلى حد كبير الحيوية("تسليم المخرجات المضمون")< المفاضلة بين /em > والأمن. يمكن أن يكون لديك مخطط N/N آمن للغاية، لكنه سيتعطل بمجرد انقطاع اتصال إحدى العقد. من ناحية أخرى، يعتبر مخطط N/2 أو N/3 أكثر قوة ولكنه ينطوي على مخاطر أكبر للتواطؤ.  

الشرطين اللذين يجب الموازنة بينهما هما:

1. لا يتم الكشف عن المعلومات السرية أبدًا (مثل مفاتيح فك التشفير)

2. لا يتم الكشف عن المعلومات السرية أبدًا كشف الاختفاء (حتى لو غادر ثلث المشاركين فجأة).

تختلف الخيارات المحددة حسب التنفيذ. على سبيل المثال، تستهدف Zama N/3، في حين تقوم Arcium حاليًا بتنفيذ مخطط N/N، ولكنها ستدعم لاحقًا المخططات بضمانات أعلى للحيوية (وافتراضات ثقة أكبر).

عند حدود المقايضة هذه، يتمثل الحل الوسط في اعتماد حل مختلط:

• لجنة الثقة العليا تجري معالجة المفاتيح باستخدام حد N/3، على سبيل المثال.

• لجنة الحساب تتناوب، على سبيل المثال، هناك عتبات N-1 (أو متعددة مع خصائص مختلفة للجان الحساب المختلفة للمستخدمين للاختيار من بينها).

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

هناك طريقة أخرى لزيادة الأمان وهي تشغيل MPC داخل أجهزة موثوقة بحيث يتم الاحتفاظ بمشاركات المفاتيح داخل منطقة آمنة. وهذا يزيد من صعوبة استخراج أو استخدام مشاركة المفاتيح لأي شيء آخر غير ما يحدده البروتوكول. على الأقل يقوم Zama وArcium باستكشاف زاوية TEE.

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

2. هل التكنولوجيا ناضجة بما فيه الكفاية؟ إذا لم تكن ناضجة بما فيه الكفاية، فما هو عنق الزجاجة؟

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

1. مجموعات المشغلين الصغار: للحفاظ على الاتصال يمكن التحكم في الحمل الزائد، وتقتصر معظم البروتوكولات الحالية حاليًا على مجموعات المشغلين الصغيرة. على سبيل المثال، تسمح شبكة فك التشفير الخاصة بشركة Zama حاليًا بما يصل إلى 4 عقد (على الرغم من أنها تخطط للتوسع إلى 16 عقدة). وفقًا للمعايير الأولية التي نشرتها Zama لشبكة فك التشفير (TKMS)، حتى مع وجود مجموعة مكونة من 4 عقد فقط، يستغرق فك التشفير 0.5-1 ثانية (تستغرق عملية e2e الكاملة وقتًا أطول). مثال آخر هو تطبيق Taceo لـ MPC لقاعدة بيانات iris الخاصة بـ Worldcoin، والتي تضم 3 أطراف (بافتراض 2/3 الأطراف الصادقة).

   المصدر: Zama on ETH Lectures على CC

2. 

3. مجموعات عوامل التشغيل المسموح بها: في معظم الحالات، مجموعات عوامل التشغيل مسموح بها. وهذا يعني أننا نعتمد على السمعة والعقود القانونية بدلاً من الأمن الاقتصادي أو الأمن المشفر. التحدي الرئيسي الذي يواجه مجموعات المشغلين غير المسموح بها هو عدم القدرة على معرفة ما إذا كان الأشخاص يتواطؤون خارج السلسلة. بالإضافة إلى ذلك، يتطلب الأمر تمهيدًا دوريًا أو إعادة توزيع مشاركات المفاتيح حتى تتمكن العقد من الدخول/الخروج من الشبكة ديناميكيًا. في حين أن مجموعة المشغلين غير المسموح بها هي الهدف النهائي، وتجري الأبحاث حول كيفية توسيع آليات إثبات الحصة (PoS) لتحقيق عتبة MPC (مثل Zama)، يبدو أن المسار المصرح به هو أفضل طريقة للمضي قدمًا في الوقت الحالي.

البدائل

تتضمن مجموعة الخصوصية الشاملة ما يلي: < /p>

• يتم استخدام FHE لتفويض حساب الخصوصية

• < p style="text-align: left;">يُستخدم ZKP للتحقق مما إذا كان حساب FHE قد تم تنفيذه بشكل صحيح

• يستخدم لـ عتبة فك تشفير MPC

• تعمل كل عقدة MPC داخل TEE لتعزيز الأمان

< p style="text-align:center">

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

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

1. استخدم MPC مباشرة لإجراء الحسابات العامة

إذا عاد ZK وFHE في النهاية إلى MPC افتراض الثقة، لماذا لا نستخدم MPC فقط لإجراء العمليات الحسابية؟ إنه سؤال مشروع، وهو ما تحاول فرق مثل Arcium، وSodaLabs (المستخدمة في Coti v2)، وTaceo، وNillion القيام به. لاحظ أن MPC تأتي في أشكال عديدة، ولكن من بين الأساليب الثلاثة الرئيسية، نشير هنا إلى البروتوكولات المستندة إلى المشاركة السرية والدوائر المشوهة (GC) بدلاً من البروتوكول المستند إلى FHE باستخدام MPC لفك التشفير.  

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

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

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

المصدر: SodaLabs

< p style="text-align: left;">تتمثل فائدة النهج المستند إلى ZK في أنك تستخدم MPC فقط لحالات الاستخدام التي تتطلب الحساب في الحالة الخاصة المشتركة. تتنافس FHE بشكل مباشر مع MPC وتعتمد بشكل كبير على تسريع الأجهزة.

2. بيئة تنفيذ موثوقة

مؤخرًا، تم إحياء اهتمام الناس بـ TEE من الآن على، يمكن استخدامه إما بمفرده (بلوكشين خاص قائم على TEE أو معالج مشترك) أو بالاشتراك مع PETs أخرى (مثل الحلول المستندة إلى ZK) (فقط باستخدام TEE لحساب الحالة الخاصة المشتركة).

على الرغم من أن TEEs أكثر نضجًا في بعض الجوانب وتقدم تكاليف أداء أقل، إلا أنها لا تخلو من العيوب. أولاً، لدى TEEs افتراضات ثقة مختلفة (1/N) وتوفر حلولًا قائمة على الأجهزة بدلاً من الحلول القائمة على البرامج. غالبًا ما يتم سماع انتقادات حول نقاط الضعف السابقة في SGX، ولكن تجدر الإشارة إلى أن TEE ≠ Intel SGX. يتطلب TEE أيضًا الثقة في مزود الأجهزة، وهو أمر مكلف (وبعيد عن متناول معظم الأشخاص). قد يكون أحد الحلول لمعالجة مخاطر الهجمات الجسدية هو تشغيل أجهزة TEE في الفضاء للتعامل مع المهام الحرجة.

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

3. لجنة المساعدة الإنمائية الخاصة والطرق الأخرى التي تعتمد على أطراف ثالثة موثوقة لحماية الخصوصية

خصوصية الوسطاء يمكن أن توفر الخصوصية من وصول المستخدمين الآخرين، ولكن ضمان الخصوصية يأتي بالكامل من الثقة في طرف ثالث (نقطة فشل واحدة). وفي حين أنها تشبه "خصوصية web2" (منع خصوصية المستخدمين الآخرين)، إلا أنه يمكن تعزيزها بضمانات إضافية (تشفيرية أو اقتصادية) والسماح بإجراء التحقق بشكل صحيح.

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

على الرغم من أن هذا النهج يقدم مقايضة كبيرة فيما يتعلق بضمانات الخصوصية، من حيث التكلفة والأداء، إلا أنه قد يكون الخيار الأمثل للقيم المنخفضة، الأداء العالي البديل الوحيد القابل للتطبيق (على الأقل في الوقت الحالي) هو التطبيقات. على سبيل المثال، يخطط Lens Protocol لاستخدام DACs خاصة لتمكين تدفق المعلومات الخاصة. بالنسبة لحالات الاستخدام مثل التواصل الاجتماعي عبر السلسلة، قد تكون المفاضلة بين الخصوصية والتكلفة/الأداء مبررة حاليًا (نظرًا لتكلفة البدائل ونفقاتها العامة).

4. عنوان خفي

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

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

بالإضافة إلى ذلك، فإن ضمانات الخصوصية التي توفرها العناوين الخفية ليست قوية مثل البدائل الأخرى. يمكن كسر عدم الكشف عن الهوية من خلال تحليل عنقودي بسيط، خاصة عندما لا تكون التحويلات الواردة والصادرة في نطاقات متشابهة (على سبيل المثال، يتم استلام 10000 دولار، ولكن تكلفة المعاملات اليومية تتراوح في المتوسط ​​بين 10 و 100 دولار). التحدي الآخر الذي يواجه العناوين الخفية هو ترقية المفاتيح، والتي تحتاج اليوم إلى ترقيتها بشكل فردي لكل محفظة (يمكن أن يساعد تجميع تخزين المفاتيح في حل هذه المشكلة). من منظور تجربة المستخدم، إذا لم يكن الحساب يحتوي على رمز مميز للرسوم (مثل ETH)، فإن بروتوكول العنوان المخفي يتطلب أيضًا تجريد الحساب أو الدافع لدفع الرسوم.

المخاطر التي تواجه حجتنا

نظرًا للوتيرة السريعة للتطوير والحلول التقنية المختلفة نظرًا هناك بعض المخاطر التي تحيط بحجتنا القائلة بأن سياسة السياسة النقدية ستكون الحل النهائي. قد ينتهي بنا الأمر إلى عدم الحاجة إلى شكل ما من أشكال MPC للأسباب الرئيسية التالية:

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

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

3. التخصص يتفوق على التصميم العالمي: يعد بناء سلاسل جديدة وتمهيد مجتمع المستخدمين والمطورين أمرًا صعبًا. لذلك، قد تواجه البنية التحتية العامة للخصوصية (L1/L2) صعوبة في الحصول على قوة جذب. هناك مشكلة أخرى تتعلق بالتخصص، حيث يصعب على تصميم بروتوكول واحد أن يغطي مساحة المقايضة بأكملها. في هذا العالم، سوف تسود الحلول التي توفر الخصوصية للأنظمة البيئية القائمة (السرية كخدمة) أو حالات الاستخدام المتخصصة (مثل المدفوعات). ومع ذلك، نحن متشككون في هذا الأخير، لأنه يقدم تعقيدًا لمطوري التطبيقات الذين يحتاجون إلى تنفيذ بعض عمليات التشفير بأنفسهم (بدلاً من تجريدها بعيدًا).

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

5. لا يزال العبء الزائد للحلول المستندة إلى MPC وFHE مرتفعًا جدًا بالنسبة لمعظم حالات الاستخدام: على الرغم من أن MPC يقتصر بشكل أساسي على الاتصالات تأثيرًا عامًا، لكن فريق FHE يعتمد بشكل كبير على تسريع الأجهزة لتحسين أدائه. ولكن إذا تمكنا من استقراء تطوير الأجهزة المخصصة على جانب ZK، فسوف يستغرق الأمر وقتًا أطول بكثير مما يعتقده معظم الناس قبل أن نحصل على أجهزة FHE جاهزة للإنتاج. تشمل الفرق التي تعمل على تسريع أجهزة FHE Optalysys وfhela وNiobium.

الملخص

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

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

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

حتى لو كان لديك أفضل مطرقة في العالم، فليس كل شيء مسمارًا.