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

جزء سلسلة الخصوصية لدينا 1 يشرح معنى 'الخصوصية' وكيفية اختلاف الخصوصية في شبكة البلوكتشين عن الخصوصية في شبكة الويب 2 ولماذا من الصعب تحقيق الخصوصية في البلوكتشين.

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

التخلص من قيود الماضي ومواجهة المستقبل

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

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

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

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

تعتبر تقنية تعزيز الخصوصية (PET) وحلول التشفير الحديثة ('قابلية البرمجة الرقمية') البنية الأساسية لتحقيق هذه الرؤية (لمزيد من المعلومات حول الحلول المختلفة المتاحة وتوازنها، يرجى الرجوع إلى الملحق).

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

ثلاثة افتراضات رئيسية تحدد رؤيتنا لتطوير البنية التحتية للخصوصية في سلسلة الكتل.

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

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

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

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

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

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

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

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

• شبكة ZKP: يزيد MPC من قدرة التعبير من خلال تحقيق الحساب الذي يشترك فيه الحالة الخاصة.
• شبكة FHE: تعزيز الأمان وتعزيز الخصوصية من خلال توزيع المفتاح السري للمجلس MPC (بدلاً من جهة ثالثة فردية) لتحقيق MPC.

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

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

دعنا نجيب عن هذه الأسئلة بشكل أكثر تفصيلاً.

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

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

*مصدر المعلومات: *Zama في ETH CC عرضه

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

• كم من الأطراف الخبيثة يمكن أن يتحملها هذا البروتوكول؟
• من يشكل الشبكة؟ مدى مصداقيتهم؟
• عدد وتوزيع أطراف مختلفة المشاركة في الشبكة - هل هناك وسائل هجوم مشتركة؟
• هل الشبكة تحتاج إلى ترخيص أم لا (مصلحة اقتصادية وسمعة / أساس قانوني)؟
• ما هو عقاب السلوك الخبيث؟ هل التآمر في اللعبة هو النتيجة الأمثل نظريًا؟

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

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

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

الشروط الاثنين التي يجب تحقيق التوازن بينهما هي:

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

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

في هذا الحدود التوازن، حلاً مقبولاً هو اعتماد حلاً مختلطاً:

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

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

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

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

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

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

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

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

الطرق البديلة

حزمة خصوصية شاملة تتضمن:

• يستخدم FHE للتفويض في الحساب الخصوصية
• يُستخدم ZKP للتحقق مما إذا كانت الحسابات FHE تنفذ بشكل صحيح
• MPC لفك تشفير الحد الأدنى
• يتم تشغيل كل عقدة MPC في TEE لتعزيز الأمان

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

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

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

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

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

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

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

مصدر: سودالابس

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

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

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

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

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

3. المؤسسات الذاتية الخاصة وغيرها من الطرق التي تعتمد على جهات خارجية موثوقة لحماية الخصوصية

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

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

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

4. العنوان الخفي

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

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

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

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

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

1. مشاركة الحالة الخاصة ليست مهمة كما نتصور: في هذه الحالة، من المرجح أن تفوز البنية التحتية القائمة على ZK، لأنها توفر ضمانات خصوصية أقوى وتكاليف أقل من FHE. هناك بالفعل بعض الحالات التي تشير إلى أن الأنظمة القائمة على ZK تعمل بشكل جيد في الحالات المعزولة، مثل بروتوكول الدفع الخاص Payy.
2. التوازن في الأداء لا يستحق فوائد حماية الخصوصية: قد يقول البعض إن افتراض الثقة في شبكة MPC ذات 2-3 أطراف مرخصة لا يختلف كثيرًا عن المشارك الوحيد المركزي، وأن الزيادة الكبيرة في التكلفة/النفقات ليست تستحق. بالنسبة للعديد من التطبيقات، خاصة تطبيقات قيمتها منخفضة التكلفة وحساسة للتكلفة (مثل التواصل الاجتماعي أو الألعاب)، قد يكون هذا صحيحًا. ومع ذلك، هناك أيضًا العديد من الحالات الاستخدام ذات القيمة العالية، حيث يكون التعاون مكلفًا للغاية حاليًا (أو غير ممكن) بسبب قضايا قانونية أو احتكاكات تنسيقية. هنا تبرز فوائد حلول MPC والحوسبة السحابية الكاملة المشفرة.
3. التصميم المتخصص يفوق التصميم العام: بناء سلسلة جديدة وتوجيه المستخدمين ومجتمع المطورين يكون أمرًا صعبًا للغاية. لذا، قد يكون من الصعب الحصول على متابعة لبنية الخصوصية العامة (L1/L2). مشكلة أخرى تتعلق بالتخصص؛ فتصميم البروتوكول الفردي يصعب تغطية مساحة التوازن بأكملها. في هذا العالم، ستكون الحلول التي توفر الخصوصية للنظام البيئي الحالي (مثل خدمات السرية) أو الحالات الاستخدام الخاصة (مثل الدفع) الأكثر فاعلية. ومع ذلك، نحن متشككون في الأخيرة، لأنها تزيد من تعقيدات مطوري التطبيقات، حيث يحتاجون إلى تنفيذ تقنيات التشفير بأنفسهم (بدلاً من تجريدها).
4. استمرار عرقلة الرقابة لتجارب حلول الخصوصية: بالنسبة لأي شخص يقوم ببناء بنية تحتية للخصوصية وتطبيقات تمتلك بعض الضمانات بخصوص الخصوصية، فإن هذا يشكل خطرًا. الحالات غير المالية تواجه مخاطر الرقابة الأقل، ولكن من الصعب (أو من المستحيل) التحكم في ما يمكن بناؤه فوق بنية تحتية للخصوصية غير المرخصة. من المحتمل بشدة أن نحل مشكلات التقنية قبل حل مشكلات الرقابة.
5. بالنسبة لمعظم الحالات الاستخدامية ، لا تزال تكاليف الحلول المبنية على MPC و FHE مرتفعة جدًا: على الرغم من أن تكاليف MPC تتأثر بشكل رئيسي بتكاليف الاتصال ، إلا أن فرقة FHE تعتمد بشدة على تسريع الأجهزة لتحسين أدائها. ومع ذلك ، إذا كنا يمكننا أن نستنتج تطور الأجهزة المخصصة لجانب ZK ، فإن الوقت الذي سيستغرقه حتى نحصل على أجهزة FHE جاهزة للإنتاج سيكون أطول بكثير مما يتصوره معظم الناس. الفرق المكرسة لتسريع الأجهزة FHE تشمل Optalysys و fhela و Niobium.

الخلاصة

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

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

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

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