🎉 Gate.io 【مواضيع مقترحة · قم بالنقاش واكسب】 الجولة الجديدة قائمة الآن!
🔥 قم بنشر مناقشات عالية الجودة تحت أفضل 3 مواضيع مقترحة لمشاركة مكافآت CROS بقيمة 200 دولار!
كيفية نشر المناقشات تحت "المواضيع المقترحة":
1.زيارة صفحة تطبيق Gate.io
2. انقر على أي من أعلى 3 "المواضيع المقترحة"
3. نشر المحتوى ف
هل يمكن لأي طريق أن يؤدي إلى MPC؟ استكشاف نهاية البنية التحتية للخصوصية
المؤلف: EQ Labs المصدر: التوازن الترجمة: شان أوبا ، جينسي كاينغ
جزء سلسلة الخصوصية لدينا 1 يشرح معنى 'الخصوصية' وكيفية اختلاف الخصوصية في شبكة البلوكتشين عن الخصوصية في شبكة الويب 2 ولماذا من الصعب تحقيق الخصوصية في البلوكتشين.
النقطة الرئيسية في هذا المقال هي أنه إذا كانت الحالة النهائية المثالية هي وجود قابلية البرمجة للبنية التحتية للخصوصية التي يمكنها التعامل مع الحالة الخاصة المشتركة دون أي أعطال نقطة واحدة ، فإن جميع الطرق تؤدي إلى MPC. سنناقش أيضًا نضج MPC وفرضية ثقتها ونسلط الضوء على الطرق البديلة ونقارن بينها ونقدم نظرة عامة على الصناعة.
التخلص من قيود الماضي ومواجهة المستقبل
يهدف البنية التحتية للخصوصية الموجودة في سلسلة الكتل الحالية إلى معالجة حالات الاستخدام الخاصة جدًا، مثل الدفع الخاص أو التصويت. هذا وجهة نظر ضيقة إلى حد ما، تعكس أساسًا استخدامات سلسلة الكتل الحالية (المعاملات، والتحويلات، والتكهن). كما قال Tom Walpo - العملات الرقمية تعاني من مفارقة فيمي:
بالإضافة إلى زيادة الحرية الفردية، نعتقد أن الخصوصية هي شرط مسبق لتوسيع مجال تصميم البلوكتشين، وتجاوز البيانات الوصفية التخمينية الحالية. العديد من التطبيقات تحتاج إلى حالة خاصة و / أو منطق مخفي للعمل بشكل صحيح:
تشير التحليلات الإمبريالية (من web2 و web3) إلى أن معظم المستخدمين لا يرغبون في دفع تكاليف إضافية أو تخطي خطوات إضافية لزيادة الخصوصية، ونحن نتفق أيضًا على أن الخصوصية نفسها ليست نقطة بيع. ومع ذلك، فإنه يسمح فعلاً بوجود حالات استخدام جديدة وأكثر معنى (نأمل ذلك) على سلسلة الكتل - دعونا نتخلص من معضلة فيرمي.
تعتبر تقنية تعزيز الخصوصية (PET) وحلول التشفير الحديثة ('قابلية البرمجة الرقمية') البنية الأساسية لتحقيق هذه الرؤية (لمزيد من المعلومات حول الحلول المختلفة المتاحة وتوازنها، يرجى الرجوع إلى الملحق).
الافتراضات الثلاث التي تؤثر على وجهات نظرنا
ثلاثة افتراضات رئيسية تحدد رؤيتنا لتطوير البنية التحتية للخصوصية في سلسلة الكتل.
نهاية البنية التحتية للخصوصية
مع الأخذ في الاعتبار الافتراضات المذكورة أعلاه، ما هو الهدف النهائي لبنية الخصوصية في سلسلة الكتل؟ هل هناك طريقة مناسبة لجميع التطبيقات؟ هل هناك تقنية تعزيز الخصوصية يمكن أن تستخدم للسيطرة على جميع التطبيقات؟
ليس كله. كل هذه المسائل تأتي مع توازنات مختلفة، وقد رأينا كيف تجمعت بطرق مختلفة. بشكل عام، لقد حددنا 11 طريقة مختلفة.
حاليًا، هناك أسلوبان شائعان لبناء البنية التحتية للخصوصية في تقنية البلوكشين، وهما استخدام ZKP أو FHE. ومع ذلك، يتواجد عيب جوهري في كلا الأسلوبين:
إذا كان الحال النهائي المثالي هو وجود قاعدة بيانات خاصة يمكن برمجتها يمكنها التعامل مع الحالة الخاصة المشتركة* دون حدوث أي خلل نقطي* ، فإن كلتا الطريقتين يمكن أن تؤديان إلى MPC:
يرجى ملاحظة أنه على الرغم من أن هاتين الطريقتين ستتجهان في نهاية المطاف نحو الاندماج، إلا أن استخدام MPC مختلف:
على الرغم من أن المناقشة بدأت في التحول نحو وجهات نظر أكثر تفصيلاً، إلا أن الضمانات الكامنة وراء هذه الطرق المختلفة لم تستكشف بشكل كامل بعد. نظرًا لأن فرضيتنا الثقة تقوم على فرضية MPC، فإن الأسئلة الثلاثة الرئيسية التي يجب طرحها هي:
دعنا نجيب عن هذه الأسئلة بشكل أكثر تفصيلاً.
استخدام MPC لتحليل المخاطر والنقاط الضعيفة
كلما تم استخدام الحلول التي تعتمد على FHE ، كان الناس يتساءلون دائمًا: "من يملك المفتاح السري؟". إذا كانت الإجابة "الشبكة" ، فإن السؤال التالي هو: "ما هي الكيانات الحقيقية التي تشكل هذه الشبكة؟". السؤال الأخير متعلق بجميع الحالات التي تعتمد بطريقة أو بأخرى على MPC.
*مصدر المعلومات: *Zama في ETH CC عرضه
أحد أهم المخاطر التي يواجهها MPC هو التواطؤ ، حيث يتفق عدد كافٍ من الأطراف المشاركة على تكوين تحالف لاعتراض البيانات المفككة بشكل متعمد أو سرقة الحسابات الحسابية. يمكن تحقيق التواطؤ خارج السلسلة ولن يتم الكشف عنه إلا عندما يتخذ الطرف المتعمد إجراءات واضحة (مثل الابتزاز أو إنشاء عملات مشفرة من العدم). لا شك في أن هذا يؤثر بشكل كبير على الخصوصية التي يمكن أن يوفرها النظام. تعتمد مخاطر التواطؤ على:
1. بمدى قوة الحماية للخصوصية التي يمكن أن يوفرها بروتوكول MPC في البلوكتشين؟
TLDR: ليس بقدر ما نأمل، لكنه أقوى من الاعتماد على جهة ثالثة مركزية.
يعتمد الحد الأدنى المطلوب لفك التشفير على البرنامج النصي MPC المحدد - بشكل كبير، توازن بين النشاط (تسليم النتائج المضمونة) والأمان. يمكنك اختيار الحل الآمن جدًا N/N، ولكنه سيتعطل إذا كان أي عقدة غير متصلة. من ناحية أخرى، تكون الحلول N/2 أو N/3 أكثر استقرارًا، ولكنها تزيد من مخاطر التآمر.
الشروط الاثنين التي يجب تحقيق التوازن بينهما هي:
تختلف الخطط المختارة حسب التنفيذ. على سبيل المثال، يهدف Zama إلى N/3، في حين أن Arcium تنفذ حاليًا خطة N/N، ولكنها ستدعم في وقت لاحق خططًا توفر ضمانات نشاط أعلى (وافتراضات ثقة أكبر).
في هذا الحدود التوازن، حلاً مقبولاً هو اعتماد حلاً مختلطاً:
على الرغم من أن هذا جذاب بشكل نظري ، إلا أنه يقدم أيضًا تعقيدات إضافية مثل كيفية تفاعل لجنة الحساب مع اللجنة ذات الثقة العالية.
تعزيز الأمان بشكل آخر هو تشغيل MPC داخل الأجهزة الموثوق بها لحفظ المفتاح السري في منطقة آمنة. هذا يجعل من الأصعب استخراج أو استخدام المفتاح السري المشترك لأي عملية خارج تعريف البروتوكول. على الأقل، يقوم Zama و Arcium بدراسة زوايا TEE.
تشمل المخاطر الأكثر دقة الحوافي مثل الهندسة الاجتماعية ، على سبيل المثال ، جميع الشركات في مجموعة MPC توظف مهندسًا متخصصًا لمدة تتراوح بين 10 و 15 عامًا.
2. هل التكنولوجيا ناضجة بما فيه الكفاية؟ إذا لم تكن كذلك، ما هي العقبات؟
من وجهة نظر الأداء، تواجه MPC تحديا رئيسيا هو تكلفة الاتصال. إنها ترتفع مع تعقيد الحساب وزيادة عدد العقد في الشبكة (متطلبات مزيد من التواصل الذهاب والإياب). بالنسبة لحالات استخدام كتلة السلسلة، هذا سيؤدي إلى تأثيرين عمليين:
*مصدر المعلومات: *Zama في ETH CC عرضه 2. 3. مجموعة مشغلي الترخيص: في معظم الحالات ، تكون مجموعة المشغلين مرخصة. هذا يعني أننا نعتمد على السمعة والعقود القانونية ، وليس الأمان الاقتصادي أو التشفير. التحدي الرئيسي لمجموعة المشغلين غير المرخصة هو عدم القدرة على معرفة ما إذا كان الناس يتواطؤون خارج السلسلة. بالإضافة إلى ذلك ، يتطلب الأمر توجيهًا دوريًا أو إعادة توزيع حصص المفاتيح بانتظام ، حتى يتمكن العقدة من الانضمام إلى الشبكة أو الخروج منها بشكل ديناميكي. على الرغم من أن مجموعة المشغلين غير المرخصة هي الهدف النهائي ، ويتم دراسة كيفية توسيع آلية PoS لتحقيق MPC بمستوى عتبة (مثل Zama) ، يبدو أن الطريق المرخص حاليًا هو الاتجاه الأفضل للمضي قدمًا.
الطرق البديلة
حزمة خصوصية شاملة تتضمن:
هذا معقد جداً ويدخل العديد من الحالات القصوى غير المستكشفة ويكلف كثيراً وقد لا يتم تحقيقه عملياً في السنوات القادمة. واحدة من المخاطر الأخرى هي أن الناس قد يشعرون بالأمان الزائف بسبب تراكم مفاهيم معقدة متعددة معًا. كلما زادت التعقيدات التي نضيفها وافترضات الثقة، زادت صعوبة استنتاج أمان الحل الشامل.
هل يستحق ذلك؟ قد يستحق ذلك، ولكن من الجيد أيضًا استكشاف وسائل أخرى قد تؤدي إلى كفاءة حسابية أفضل بشكل ملحوظ، مع ضمان الخصوصية الذي قد يكون أقل قليلاً. كما أشار 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، والأسباب الرئيسية تشمل:
الخلاصة
*في النهاية، تعتمد قوة السلسلة على أضعف حلقة فيها. في حالة البنية التحتية للخصوصية القابلة للبرمجة، إذا أردنا أن تتعامل مع الحالة الخاصة المشتركة بدون وجود أعطال فردية، فإن ضمان الثقة يعتمد على ضمان MPC.
على الرغم من أن هذا المقال يبدو أنه ينتقد MPC ، إلا أن الحقيقة ليست كذلك. MPC قد ساهمت بشكل كبير في تحسين الوضع الحالي الذي يعتمد بشكل كبير على الجهات الخارجية المركزية. نحن نعتقد أن المشكلة الرئيسية هي وجود ثقة مزيفة في الصناعة بأكملها ، وتم تغطية المشكلة. بدلاً من ذلك ، يجب علينا مواجهة المشكلة مباشرة والتركيز على تقييم المخاطر المحتملة.
ولكن ليس كل المشاكل تحتاج إلى استخدام نفس الأدوات لحلها. على الرغم من أننا نعتقد أن MPC هو الهدف النهائي ، إلا أنه ما زالت هناك خيارات أخرى ممكنة طالما أن تكلفة الحل الذي يدفعه MPC لا تزال مرتفعة. نحن دائما مستحقون مراعاة أي الأسلوب الأنسب لمتطلبات / سمات المشكلة التي نحاول حلها ، والتضحيات التي نحن على استعداد لاتخاذها.
حتى وإن كان لديك أفضل مطرقة في العالم، ليس كل شيء مسماراً.