هذا هو التعليق الافتتاحي من قبل Shinobi
المعلم الذي علم نفسه بنفسه في مجال Bitcoin ومضيف بودكاست Bitcoin ذي التوجه التكنولوجي.
![مع](https://bitcoinmagazine.com/.image/ar_16:9%2Cc_fill%2Ccs_srgb%2Cg_faces:center%2Cq_auto:good%2Cw_768/MTkyNjA3MTM2MjI2NzQ4MTUz/20220926_good-gdog-proof-collaborative-custody-multisig-by-will-schoellkopf_.png)
أقترح قبل قراءة هذا المقال أن تقرأ مقالًا سابقًا كتبته يشرح ماهية Nostr وكيف يعمل على مستوى عالٍ. في هذه المرحلة ، يجب أن يكون لديك فكرة جيدة جدًا عن التصميم الأساسي للنظام ، لذلك دعونا الآن نلقي نظرة على المشكلات التي قد تنشأ مع تزايد التبني. يجب الانتباه إلى هذه المشكلات نظرًا لأن النظام الأساسي أصبح شائعًا في مجتمع Bitcoin.
كما ناقشت في منشور سابق
تعد أزواج المفاتيح العامة / الخاصة للمستخدم جزءًا لا يتجزأ من كيفية عمل Nostr كبروتوكول. لا يوجد اسم مستخدم أو معرف من أي نوع يتحكم فيه خادم الترحيل مرتبطًا بمستخدم فردي. كل ما في الأمر أن مفاتيح هؤلاء المستخدمين تحت سيطرتهم تمامًا.
هذا بمثابة رابط وثيق بين المستخدم الفعلي وكيفية التعرف عليه من قبل الآخرين
مما يمنع أي خادم ترحيل من فك هذين الأمرين ، أي إعطاء معرف شخص ما لمستخدم آخر. هذا يحل واحدة من أكبر المشاكل الأساسية مع منصات التواصل بين البشر: الافتقار إلى السيطرة على هويات المستخدمين. ولكنه يقدم أيضًا جميع مشكلات الإدارة الرئيسية التي تأتي مع شخص يمتلك المفتاح الخاص. يمكن أن تُفقد المفاتيح ، ويمكن اختراق المفاتيح ، وإذا حدث مثل هذا الحدث ، فلن يتمكن المستخدمون من طلب المساعدة ، تمامًا مثل Bitcoin. لا يوجد دعم العملاء لاستعادة أي شيء. تخسر ، هذا كل شيء. .
مُثير للإهتمام حقاً
سيتطلب هذا حتمًا مخططًا للتدوير من زوج مفاتيح إلى آخر بطريقة قابلة للتحقق والاكتشاف للمستخدمين الذين يتفاعلون معها من خلال البروتوكول. يعتمد البروتوكول بأكمله على إثبات أن حدثًا جاء من مستخدم معين (مفتاح الهوية) ، لذلك بمجرد اختراق مفتاح شخص ما ، تصبح كل هذه الضمانات غير صالحة.
كيف تتعاملون مع ذلك
فقط للتحقق من حساب Twitter الخاص بهم؟ حسنًا ، هذا ليس نظامًا لامركزيًا للغاية ، وفي النهاية ، إذا كنت بحاجة إلى استخدام نظام أساسي مركزي حيث لا يتحكمون في هويتهم للتحقق من هوية Nostr الخاصة بهم.
هل شهد المستخدمون الآخرون على شرعية المفتاح الجديد
هذا لا يعالج مواقف مثل تعرض عدد كبير من المفاتيح للخطر أو الأشخاص الذين لا يعرفونهم قريبين بما يكفي ليثقوا في براهينهم.
يتطلب Nostr مخطط تشفير فعلي يربط دوران مفتاح بآخر
اقترح المطور fiatjaf حلاً أساسيًا قد يحل هذه المشكلة. الفكرة الأساسية هي أخذ قائمة طويلة من العناوين المشتقة من بذرة رئيسية واحدة وإنشاء مجموعة من المفاتيح “المعدلة” ، على غرار كيفية التزام أشجار Taproot بمفاتيح Bitcoin. يأخذ Taproot جذر Merkle الخاص بشجرة Taproot و “يضيفه” إلى المفتاح العام لإنشاء مفتاح عمومي جديد. يمكن تكرار ذلك عن طريق إضافة جذر Merkle إلى المفتاح الخاص للحصول على مفتاح خاص يطابق المفتاح العام الجديد. تتمثل فكرة Fiatjaf في ربط الالتزامات بشكل عكسي من البداية إلى البداية ، بحيث يحتوي كل مفتاح معدّل في الواقع على دليل على استخدام المفتاح المعدل التالي لإنشائه.
لذا
تخيل أن تبدأ بالمفتاح Z ، الأخير في السلسلة. يمكنك تعديله بشيء ما ، ثم العودة وإنشاء نسخة معدلة من المفتاح Y باستخدام مفتاح Z المعدل (Z ‘+ Y = Y’). من هنا يمكنك أن تأخذ Y ‘وتستخدمها لضبط X (Y’ + X = X ‘). ستفعل هذا طوال الطريق إلى المفتاح A ، وتحصل على A ‘، وتستخدم هذا المفتاح من هناك. عندما يتم كسرها ، يمكن للمستخدم بث حدث يحتوي على المفتاح غير المعدل A والمفتاح المعدل B ‘. سيحتوي هذا على جميع البيانات اللازمة لإظهار أن B ‘تم استخدامه لإنشاء A’ ، ويمكن للمستخدم التوقف فورًا عن اتباع A ‘واتباع B’ بدلاً من ذلك. سيعرفون صراحةً أن B ‘هو المفتاح التالي لذلك المستخدم ، ويتبعونه بدلاً من ذلك ..
ومع ذلك
لا تزال هناك بعض المشاكل مع هذا الاقتراح. أولاً ، يجب عليك إنشاء جميع المفاتيح التي ستستخدمها مسبقًا ، ولا توجد طريقة للتدوير إلى مجموعة مفاتيح جديدة تمامًا. يمكن حل ذلك عن طريق إدخال مفتاح رئيسي في هذا المخطط يمكنه توثيق هذا الدوران ، أو ببساطة عن طريق إنشاء مجموعة كبيرة جدًا من المفاتيح من البداية. كلا المسارين ممكن ، لكنك في النهاية تحتاج إلى الحفاظ على مفتاح الجذر أو المادة الرئيسية آمنة وتعريض مفتاح اختصار واحد فقط لعملاء Nostr.
ومع ذلك
فإن هذا النظام لا يحمي المستخدمين أو يوفر آليات لاستعادة الهوية في حالة فقدان مادة مفتاح الجذر أو تعرض نفسها للخطر. الآن ، هذا لا يعني أن حل fiatjaf ليس جيدًا ، إنه بالتأكيد كذلك ، لكن من المهم الإشارة إلى أنه لا يوجد حل من شأنه أن يحل جميع المشاكل.
بالنسبة لبعض المناقشات حول الحلول المحتملة هنا
تخيل أنه بدلاً من تعديل مفتاح واحد لمفتاح بارد رئيسي ، كما يقترح ، يجب أيضًا استخدام هذا المفتاح البارد الرئيسي لتوقيع المعاملات من مفتاح إلى تدوير الأحداث لمفتاح آخر. لديك المفتاح A ‘الذي تم اشتقاقه عن طريق إضافة A و M (المفتاح الرئيسي) ، سيكون حدث التدوير A و M و B’ (يتم إنشاؤه عن طريق إضافة B و M) وتوقيع M. يمكن أن يكون M مفتاح عتبة متعدد التوقيعات – اثنان من ثلاثة ، ثلاثة من خمسة ، إلخ. قد يضيف هذا التكرار مقابل الخسارة ويوفر آلية آمنة لتدوير المفتاح. هذا يفتح الباب أمام استخدام الخدمة للمساعدة في الاسترداد ، أو لنشر بعض هذه المفاتيح للأصدقاء الموثوق بهم. إنه يوفر نفس المرونة مثل multisig في Bitcoin نفسها.
NIP26 هو أيضًا اقتراح قد يكون مفيدًا جدًا في معالجة هذه المشكلة
يحدد هذا امتداد بروتوكول للأحداث التي تسمح للتوقيع من مفتاح واحد لتفويض مفتاح آخر لنشر الأحداث نيابة عنه. سيتم بعد ذلك تضمين “الرمز المميز” أو إثبات التوقيع المفوض في جميع الأحداث التي ينشرها المفتاح العام الثاني نيابة عن الأول. يمكن أن يكون الأمر محدودًا بوقت ، لذلك تنتهي صلاحية رموز التفويض تلقائيًا ويجب تجديدها ..
في النهاية
مهما تم حلها ، يجب حل هذه المشكلة لـ Nostr على المدى الطويل. ستفشل البروتوكولات القائمة كليًا على أزواج المفاتيح العامة / الخاصة المستخدمة كهويات في اكتساب قوة جذب واعتماد إذا كان لا يمكن تأمين سلامة هذه الهويات والحفاظ عليها للمستخدمين. سينتهي هذا في النهاية إلى الاضطرار إلى استخدام الأنظمة الأساسية خارج النطاق والمركزية باستمرار للتحقق من صحة المفاتيح الجديدة والتنسيق بين الأشخاص الذين يتابعون هويتك الجديدة في حالة فقد شيء ما أو تعرضه للخطر ، وفي هذه المرحلة تصبح هذه الأنظمة الأساسية الأخرى هي التي تنشر الفوضى. يعني .. وللمراجعة ..
تعد مسألة إدارة المفاتيح والأمان مشكلة كبيرة جدًا مع مساحة تصميم كبيرة جدًا
مليئة بالمقايضات ونقاط الضعف ، ولكن يجب حل هذه المشكلات في سياق Nostr لتكون مفيدة. في رسالتي التالية ، سألخص بعض المشكلات التي أعتقد أنها برزت فيما يتعلق بهندسة خادم الترحيل ومشكلات التوسع التي سيتعين على مطوري Nostr مواجهتها نظرًا لهياكل البيانات الأساسية التي تستند إليها Nostr.
لأي شخص يقرأ هذا ويتساءل لماذا لم أذكر المعرفات اللامركزية (DID)
نعم ، إنه حل محتمل لهذه المشاكل ، وهو شامل جدًا في رأيي. ومع ذلك ، يبدو أن مطوري Nostr مترددون جدًا في دمج DID في البروتوكول أو العميل ، حيث أنه سيخلق تبعيات خارجية خارج بروتوكول Nostr. إذا لم تكن على دراية بكيفية عمل اضطراب الشخصية الانفصامية على المستوى الفني وكنت مهتمًا ، فهذه المقالة في المستوى 39 هي ملخص جيد لكيفية عملها.
هذا منشور ضيف بواسطة Shinobi
الآراء المعبر عنها خاصة بها تمامًا ولا تعكس بالضرورة آراء BTC Inc أو Bitcoin Magazine.