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

المؤلف: EQ Labs المصدر: توازن الترجمة: شان أوبا ، رؤية Baitchain

يغطي الجزء 1 من سلسلة الخصوصية الخاصة بنا معنى “الخصوصية” ، وكيف تختلف الخصوصية في شبكة blockchain عن خصوصية Web2 ، ولماذا يصعب تحقيق الخصوصية في blockchain.

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

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

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

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

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

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

يوضح التحليل التجريبي (من Web2 و Web3) أن معظم المستخدمين يترددون في دفع رسوم إضافية أو تخطي روابط إضافية لزيادة الخصوصية ، ونحن نتفق أيضًا على أن الخصوصية نفسها ليست نقطة بيع.ومع ذلك ، فإنه يسمح بوجود حالات الاستخدام الجديدة و (نأمل) أكثر جدوى فوق blockchain – دعنا نتخلص من مفارقة Fermi.

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

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

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

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

2. تتطلب العديد من حالات الاستخدام (ربما أكثر مما كنا نعتقد) مشاركة الحالة الخاصة: كما ذكرنا سابقًا ، تتطلب العديد من التطبيقات بعض الحالة الخفية و/أو المنطق للعمل بشكل صحيح.الحالة الخاصة المشتركة هي مجموعة فرعية منهم ، حيث تحسب العديد من الأطراف نفس الحالة الخاصة.على الرغم من أننا نستطيع الوثوق بحزب مركزي للقيام بذلك من أجلنا والتوقف عند هذا الحد ، إلا أننا نريد أن نفعل ذلك مع تقليل الثقة لتجنب نقطة الفشل.هذا غير ممكن مع إثبات المعرفة الصفري وحده-نحن بحاجة إلى الاستفادة من الأدوات الأخرى مثل بيئة التنفيذ الموثوق (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 هو التواطؤ ، أي أن هناك ما يكفي من الأطراف المشاركة في التواطؤ الضار لفك تشفير البيانات أو الحسابات الخاطئة.يمكن الاتفاق على التواطؤ خارج السلسلة ولن يتم الكشف إلا إذا اتخذ الحزب الضار بعض الإجراءات الواضحة (Ransformation ، والخروج من الرموز من الهواء الرقيق ، وما إلى ذلك).وغني عن القول ، هذا له تأثير كبير على ضمانات الخصوصية التي يمكن أن يوفرها النظام.يعتمد خطر التواطؤ على:

• كم عدد الأطراف الخبيثة التي يمكن أن تحملها هذه الاتفاقية؟

• ما هي الشبكات؟ما مدى موثوقيهم؟

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

• هل خالية من ترخيص الشبكة أو الحاجة إلى ترخيص (المصالح الاقتصادية والسمعة/الأساس القانوني)؟

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

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

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

تعتمد العتبة المطلوبة لفك التشفير على مخطط MPC المحدد – إلى حد كبير مستوى النشاط(“تسليم الإخراج مضمون”)والمقايضات الأمنية.يمكنك أخذ مخطط N/N آمن للغاية ، ولكنه سيتعطل طالما أن هناك عقدة في وضع عدم الاتصال.من ناحية أخرى ، فإن مخطط N/2 أو N/3 أكثر قوة ، لكن خطر التآمر أعلى.

شرطان يجب أن تكونا متوازنة هما:

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

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

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

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

• لجنة الثقة العاليةيتم إجراء المعالجة الرئيسية مع ، على سبيل المثال ، عتبة N/3.

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

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

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

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

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

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

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

   مصدر:خطاب زاما في ETH CC

2. 

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

طريقة بديلة

تشمل محفظة خصوصية شاملة:

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

• يتم استخدام ZKP للتحقق من تنفيذ حساب Fhe بشكل صحيح

• MPC لفك تشفير العتبة

• تعمل كل عقدة MPC داخل نقطة الإنطلاق لتحسين الأمان

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

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

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

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

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

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

يوضح الجدول التالي لـ Sodalabs المدة التي يستغرقها تنفيذ الرموز المبتكرة المختلفة 1000 مرة في GCEVM(في microseconds).في حين أن هذه خطوة في الاتجاه الصحيح ، لا يزال هناك الكثير من العمل الذي يتعين القيام به لتحسين الكفاءة وتوسيع نطاق المشغل الذي يتجاوز بضع عقد.

المصدر: Sodalabs

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

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

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

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

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

3. DACs الخاصة وطرق أخرى للاعتماد على أطراف ثالثة موثوق بها لحماية الخصوصية

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

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

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

4. عنوان غير مرئي

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

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

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

المخاطر على حجتنا

بالنظر إلى الوتيرة السريعة للتنمية وعدم اليقين العام للحلول التكنولوجية المختلفة ، نعتقد أن هناك بعض المخاطر في الحجة القائلة بأن MPC سيكون الحل النهائي.قد لا ينتهي بنا المطاف إلى بعض أشكال 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 لا تزال عالية.نحن نستحق دائمًا النظر في الطريقة التي تناسب الاحتياجات/خصائص المشكلة المحددة التي نحاول حلها ، وما هي المفاضلات التي نرغب في تقديمها.

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