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

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

المقاربات الثلاث بإيجاز

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

اقترح المشفرون بدائل للتغلب على مشاكل PKIs. في عام 1984،اقترح أدي شاميرالتشفير القائم على الهوية (IBE)، حيث يعمل معرف الطرف - رقم الهاتف، البريد الإلكتروني، اسم نطاق ENS - كمفتاح عام. يتم ذلك عن طريق القضاء على الحاجة إلى الحفاظ على دليل مفتاح عام ولكن يترتب عليه إدخال طرف ثالث موثوق به (مُنشئ المفتاح). قدم دان بونيه وماثيو فرانكلين الأول بناء عملي IBEفي عام 2001، ولكن لم يتم اعتماد IBE على نطاق واسع إلا في النظم البيئية المغلقة مثل الشركات أوتنفيذات الحكومة، ربما بسبب افتراض الثقة القوي. (كما سنرى لاحقًا، يمكن تخفيف هذا الافتراض جزئيًا عن طريق الاعتماد على شريعة موثوقة من الأطراف بدلاً من ذلك، والتي يمكن أن تسهل سهولة البلوكتشين.)

خيار ثالث، التشفير القائم على التسجيل (RBE)،مقترح في عام 2018. يحافظ RBE على نفس البنية العامة مثل IBE ولكنه يستبدل مولد المفاتيح الموثوق به ب "أمين مفاتيح" شفاف يقوم فقط بإجراء الحسابات على البيانات العامة (على وجه التحديد ، يقوم بتجميع المفاتيح العامة في نوع من "الملخص" المتاح للجمهور). إن شفافية هذا المنسق الرئيسي تجعل إعداد blockchain - حيث يمكن للعقد الذكي أن يملأ دور المنسق - مناسبا بشكل طبيعي ل RBE. كان RBE نظريا حتى عام 2022 ، عندما قدمت أنا والمؤلفون المشاركون أول بناء RBE فعليًا كفؤ.

تقييم التنازلات

هذا الفضاء التصميمي معقد، ومقارنة هذه الخطط يتطلب أخذ العديد من الأبعاد في الاعتبار. لتبسيط الأمور، سأقوم بعمل افتراضين:

1. المستخدمون لا يقومون بتحديث أو إلغاء مفاتيحهم.
2. لا يستخدم العقد الذكي أي خدمة توفر البيانات خارج السلسلة (DAS) أو بيانات بصيغة البلوب.

سأناقش في النهاية كيف يمكن أن تؤثر كل من هذه الاعتبارات الإضافية على ثلاثة حلول محتملة لدينا.

دليل المفتاح العام

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

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

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

لنلق نظرة على خصائص هذه الطريقة.

على الجانب السلبي من الدفتر:

• غير موجز. يجب تخزين دليل المفتاح الكامل على السلسلة حتى يكون متاحًا دائمًا للجميع (تذكر، الآن نفترض عدم وجود DAS). للـ ~900K عدد أسماء النطاقات الفريدة المسجلة في ENS في وقت كتابة هذا، هذا يعني تقريبًا 90 ميجابايت من التخزين الدائم. يحتاج الأطراف المسجلة إلى دفع تكلفة التخزين الذي تأخذه إدخالاتهم حوالي 65 ألف وحدة غاز (حاليًا تقريبًا 1 دولار - انظر التقييم الأداء أدناه).
• تشفير تفاعلي إلى حد ما. يحتاج المرسل إلى قراءة السلسلة لاسترداد مفتاح عام للمستخدم، ولكن فقط إذا كانت هذه هي المرة الأولى التي يقوم فيها المرسل بتشفير رسالة لهذا المستخدم الخاص. (تذكر، نفترض أن المستخدمين لا يقومون بتحديث أو إلغاء مفاتيحهم).
• ليس مرسلا مجهولا. عندما تقوم باسترداد المفتاح العام لشخص ما ، فإنك تربط نفسك بالمستلم ، مما يشير إلى أن لديك نوعا من العلاقة معه. تخيل على سبيل المثال أنك تسترجع المفتاح العام لويكيليكس: هذا يمكن أن يخلق شكوكا في أنك تقوم بتسريب وثائق سرية. يمكن تخفيف هذه المشكلة من خلال "حركة مرور الغطاء" (استرداد مجموعة كبيرة من المفاتيح ، والتي لا تنوي استخدام معظمها) أو بالمثل عن طريق تشغيل عقدة كاملة ، أو مع استرجاع المعلومات الخاصة (PIR).

على الجانب الايجابي:

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

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

(الحد) التشفير القائم على الهوية (IBE)

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

في IBE ، لا يقوم المستخدم بإنشاء زوج المفاتيح الخاص به ولكن بدلا من ذلك يسجل باستخدام منشئ مفاتيح موثوق به. يحتوي مولد المفاتيح على زوج مفاتيح "رئيسي" (msk ، mpk في الشكل). بالنظر إلى معرف المستخدم ، يستخدم منشئ المفاتيح المفتاح السري الرئيسي msk والمعرف لحساب مفتاح سري للمستخدم. يجب توصيل هذا المفتاح السري إلى المستخدم عبر قناة آمنة (والتي يمكن إنشاؤها باستخدام ملف بروتوكول تبادل المفاتيح).

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

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

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

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

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

• التخزين المستمر / الحد الأدنى على السلسلة. يتعين تخزين مفتاح العام الرئيسي فقط (عنصر مجموعة واحد) على السلسلة. هذا أقل بكثير من التخزين الذي يتطلبه دليل مفتاح عام على السلسلة. بالنسبة لـ Boneh-Franklin IBE على منحنى BN254 ، يعني هذا إضافة 64 بايتًا من التخزين المستمر على السلسلة مرة واحدة خلال مرحلة الإعداد ، مما يتطلب من الخدمة إنفاق 40 ألف غاز فقط.
• التشفير غير التفاعلي. يحتاج المرسل فقط إلى المفتاح العام الرئيسي (الذي يقوم بتنزيله مرة واحدة في البداية) وهوية المستلم لتشفير رسالة. وهذا على عكس دليل المفتاح العام ، حيث يحتاج إلى استرداد مفتاح لكل مستخدم جديد يرغب في التواصل معه.
• فك تشفير غير تفاعلي. مرة أخرى، يستخدم المستخدمون مفاتيحهم السرية المخزنة محليًا لفك تشفير الرسائل.
• المرسل مجهول. لا يحتاج المرسل إلى استرداد أي معلومات متعلقة بالمستلم من السلسلة. وعلى العكس، في حالة سجل المفتاح العام، يجب على المرسل التفاعل مع العقد بطريقة تعتمد على المستلم.
• مجموعة معرفات تعيين عشوائي. كما في سجل المفتاح العام ، يمكن أن تكون المعرفات سلاسل عشوائية.

لكن!

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

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

التشفير القائم على التسجيل (RBE)

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

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

في RBE ، يقوم المستخدم بإنشاء زوج المفاتيح الخاص به ويحسب بعض "قيم التحديث" (a في الشكل) المشتقة من المفتاح السري والسلسلة المرجعية المشتركة (CRS). على الرغم من أن وجود CRS يعني أن الإعداد ليس غير موثوق به تماما ، إلا أن CRS هو ملف powers-of-tauالبناء، الذي يمكن أن يكونيتم حسابها بالتعاون على السلسلة الرقميةوهي آمنة طالما كان هناك مساهمة صادقة واحدة.

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

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

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

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

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

• معلمات موجزة. حجم المعلمات التي يجب تخزينها على السلسلة هو غير خطي في عدد المستخدمين. هذا أصغر بكثير من التخزين الإجمالي المطلوب لدليل المفتاح العام (خطي بالنسبة لعدد المستخدمين)، ولكنه ليس ثابتًا وبالتالي أسوأ مقارنة بـ IBE.
• تشفير تفاعلي إلى حد ما. لإرسال رسالة، يحتاج الراسل إلى نسخة من المعلمات العامة التي تحتوي على المستلم المقصود. هذا يعني أنه يحتاج إلى تحديث المعلمات في نقطة ما بعد تسجيل المستلم المقصود، ولكن ليس بالضرورة لكل مستلم مقصود يتم تسجيله، حيث يمكن أن يتضمن تحديث واحد مفاتيح متعددة لعدة مستلمين. بشكل عام، إرسال الرسائل هو أكثر تفاعلية من IBE وأقل تفاعلية من الدليل.
• فك التشفير التفاعلي إلى حد ما. على غرار حالة التشفير ، يحتاج المستلم إلى نسخة من المعلومات المساعدة التي "تتطابق" مع إصدار المعلمات العامة المستخدمة للتشفير. وبشكل أكثر تحديدا ، يتم تحديث كل من المعلمة العامة و aux buckets كلما سجل مستخدم جديد في تلك الحاوية ، والقيمة a قادرة على فك تشفير نص مشفر هي القيمة المقابلة لإصدار pp المستخدم للتشفير. مثل تحديثات المعلمات العامة ، يمكن للمستخدم أن يقرر استرداد تحديثات aux بشكل دوري فقط ، إلا عند فشل فك التشفير. على عكس تحديثات المعلمات العامة ، فإن استرداد تحديثات aux في كثير من الأحيان لا يؤدي إلى تسريب المعلومات بطبيعته.
• المرسل- مجهول الهوية. كما في حالة الدليل، يمكن للمرسل تشفير الرسالة بالكامل بمفرده (في حالة توفر المعلمات الحديثة) دون الاستفسار عن معلومات خاصة بالمستلم. يتم قراءة المعلومات من السلسلة، عند الضرورة، بشكل مستقل عن المستلم المقصود. (لتقليل التواصل، يمكن للمرسل طلب دلو معين، ما يؤدي إلى تسريب معلومات جزئية.)
• شفاف. على الرغم من أن النظام يحتاج إلى الإعداد باستخدام حفل إعداد موثوق به (يحتمل أن يكون موزعا و / أو مدارا خارجيا) لإخراج CRS مثقوب ، إلا أنه لا يعتمد على أي طرف موثوق به أو النصاب القانوني بمجرد اكتمال الإعداد: على الرغم من أنه يعتمد على طرف ثالث منسق (العقد) ، إلا أنه شفاف تماما ويمكن لأي شخص أن يكون منسقا أو يتحقق من أنه يتصرف بصدق من خلال تأكيد انتقالات الحالة (لهذا السبب يمكن أن يكون نفذت كعقد ذكي). علاوة على ذلك ، يمكن للمستخدمين طلب إثبات عضوية موجز (غير) للتحقق من أنهم (أو أي شخص آخر) مسجلون / غير مسجلين في النظام. هذا على عكس حالة IBE ، حيث يصعب على الطرف / الأطراف الموثوق بها إثبات أنهم لم يكشفوا سرا عن مفتاح فك التشفير (لأنفسهم عن طريق عمل نسخة سرية أو لشخص آخر). من ناحية أخرى ، فإن دليل المفتاح العام شفاف تماما.
• مجموعة المعرفات المقيدة. لقد وصفت نسخة "أساسية" من بناء RBE. لتحديد الحاوية التي يقع فيها المعرف بشفافية ، يجب أن يكون للمعرفات ترتيب عام وحتمي. يمكن ببساطة ترتيب أرقام الهواتف ، ولكن طلب سلاسل تعسفية أمر غير عملي إن لم يكن مستحيلا لأن عدد الدلاء قد يكون كبيرا للغاية أو غير محدود. يمكن التخفيف من ذلك من خلال تقديم عقد منفصل يحسب مثل هذا التعيين أو من خلال اعتماد نهج تجزئة الوقواق المقترح في هذا العمل التالي.

مع الامتدادات:

• المستلم - مجهول. يمكن توسيع النظام بحيث لا يكشف النص المشفر هوية المستلم.

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

مقارنة الأداء

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

لدى PKI لا تكلفة إعداد وتكلفة تسجيل منخفضة لكل مستخدم، بينما لدى IBE تكلفة إعداد صغيرة وتسجيل مجاني تقريباً لكل مستخدم. لدى RBE تكلفة إعداد أعلى وأيضا تكلفة تسجيل عالية بشكل غير متوقع، على الرغم من الحاجة القليلة لتخزين البيانات على السلسلة.

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

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

نويمي غلايسر هو مرشح لدرجة الدكتوراه في علوم الكمبيوتر في جامعة ماريلاند ومعهد ماكس بلانك للأمن والخصوصية وكان متدربا باحثا في a16z crypto خلال صيف عام 23. حصلت على زمالة NSF لأبحاث الخريجين ، وكانت سابقا متدربة بحثية في NTT Research.

الملحق: اعتبارات إضافية

التعامل مع تحديثات/إلغاء المفاتيح

في حالة وجود دليل لمفتاح عام، تتم معالجة تحديثات المفاتيح وإبطالها بسهولة: لإبطال مفتاح، يطلب الطرف من العقد مسحه من الدليل. ولتحديث المفتاح، يتم الكتابة فوق الإدخال (id، pk) بمفتاح جديد إلى (id، pk ').

لإلغاء الاعتماد في IBE ، اقترح بونيه وفرانكلين أن يقوم المستخدمون بتحديث مفاتيحهم بشكل دوري (على سبيل المثال ، كل أسبوع) ، وأن يتضمن المرسلون الفترة الزمنية الحالية في سلسلة الهوية عند التشفير (على سبيل المثال ، "بوب <الأسبوع الحالي>"). نظرًا لطبيعة التشفير غير التفاعلية ، لا يمكن للمرسلين معرفة متى يلغي المستخدم مفتاحه ، لذلك فإن بعض تحديثات الفترة لازمة. أعطت Boldyreva و Goyal و Kumar ، آلية إبطال أكثر كفاءةبناءً على"Fuzzy" IBE الأمر الذي يتطلب مفتاحين لفك التشفير: مفتاح "هوية" ومفتاح "وقت" إضافي. بهذه الطريقة ، يجب تحديث مفتاح الوقت فقط بانتظام. يتم تجميع مفاتيح وقت المستخدمين في شجرة ثنائية ، ويمكن للمستخدم استخدام أي عقدة على طول المسار (في الحالة الأساسية ، يكون الجذر فقط ضروريا وهو الجزء الوحيد الذي يتم نشره بواسطة مولد المفاتيح). يتم تحقيق إبطال المفتاح من خلال عدم نشر التحديثات لمستخدم معين (حذف العقد على طول مسار هذا المستخدم من الشجرة) ، وفي هذه الحالة يزداد حجم التحديث ولكنه لا يزيد أبدا عن لوغاريتمي في عدد المستخدمين.

لم يأخذ بناء RBE الفعال لدينا في الاعتبار التحديثات والإبطال ، أ عمل المتابعةيقدم مترجم يمكنه "ترقية" مخططنا لإضافة هذه الوظائف.

نقل البيانات خارج السلسلة بواسطة DAS

استخدام حل توفر البيانات (DAS) لنقل تخزين سلسلة الكتلة خارج السلسلة سيؤثر فقط على حساب دليل المفتاح العمومي و RBE ، مما يقلل كلاهما إلى نفس كمية تخزين سلسلة الكتلة. سيظل RBE يحتفظ بميزة الخصوصية الأكثر للمرسل ، حيث يتجنب لا تسرب هوية المستلم عبر أنماط الوصول. IBE كان لديه بالفعل تخزين أدنى في سلسلة الكتلة ولن يستفيد من DAS.

تنصل:

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