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

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

هل جميعنا نبني نفس الشيء؟ استمر في القراءة لمعرفة الإجابة.

شكراً لـAvishay (SodaLabs), لوكاس (Taceo), مايكل (التوازن), ونيكو (Arcium) للمناقشات التي ساهمت في تشكيل هذا المنشور.

ما يمكن أن يكون، بدون أن يكون محملاً بما كان

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

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

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

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

تقنيات تعزيز الخصوصية (PETs) وحلول التشفير الحديثة (التشفير القابل للبرمجة“) هي الكتل الأساسية لتحقيق هذه الرؤية (انظر الملحقلمزيد من المعلومات حول الحلول المختلفة المتاحة وتنازلاتها في التداول).

ثلاث فرضيات تشكل آراءنا

تتشكل آراءنا حول كيفية تطور البنية التحتية للخصوصية في سلاسل الكتل حول ثلاث فرضيات رئيسية:

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

نهاية اللعبة لبنية الخصوصية

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

ليس تمامًا. جميع هذه الاختيارات لها تضحيات مختلفة ونرى بالفعل دمجها بطرق مختلفة. في المجموع، قمنا بتحديد 11 نهجًا مختلفًا (انظرالمُلحق.

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

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

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

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

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

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

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

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

تحليل المخاطر والضعف مع MPC

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

المصدر: محادثة زاما في ETH CC

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

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

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

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

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

الشرطان المتوازيان للتوازن هما:

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

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

يمكن أن يكون التوافق بين هذه النقاط التجارية هو حل مختلط:

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

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

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

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

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

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

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

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

النهج البديل

يتكون كوكتيل الخصوصية الكاملة من:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. عناوين مخفية

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

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

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

المخاطر على أطروحتنا

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

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

ملخص

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

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

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

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

الملحق 1: نهج مختلفة للخصوصية في سلاسل الكتل

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

هناك الكثير من PETs المختلفة للاختيار من بينها ، ولكن أكثرها صلة بصناعة blockchain تشمل الحساء المكون من ثلاثة أحرف - ZKP و MPC و FHE و TEE - إلى جانب طرق إضافية مثل عناوين التخفي:

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

في المجموع ، حددنا 11 طريقة مختلفة لتحقيق بعض ضمانات الخصوصية في شبكات blockchain. وتشمل بعض المقايضات التي لوحظت ما يلي:

• الخصوصية الموثوقة مقابل الخصوصية المقللة (هل هناك نقطة فشل واحدة؟)
• نهج الأجهزة مقابل البرمجيات
• الحالات المعزولة مقابل مجموعة من الحيوانات الأليفة المتعددة
• L1 مقابل L2
• سلسلة جديدة مقابل إضافة الخصوصية إلى السلاسل القائمة ("السرية كخدمة")
• حجم المجموعة المحمية (متعدد السلاسل > تطبيق > أحادي السلسلة > أصل واحد)

الملحق 2: نظرة عامة على الصناعة

Dentro de estas 11 categorías, muchas compañías diferentes están trabajando en una o más soluciones. A continuación se muestra un resumen (no exhaustivo) del estado actual de la industria:

اخلاء المسؤوليه:

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