قد يكون Nostr 2.0 قادرًا على البناء على Bitcoin كطبقة 2 ، مما يوفر تخزينًا آمنًا للبيانات خارج السلسلة ، تمامًا كما توفر Lightning Network مدفوعات فورية خارج السلسلة كطبقة 2.
تشرح هذه المقالة كيف يقوم مرحل Nostr بمزامنة بياناته مع الحفاظ على طبيعته خفيفة الوزن ، مما يسمح للمستخدمين بحذف البيانات بشكل انتقائي ، وهو أمر غير متوفر في سلاسل الكتل من الطبقة الأولى. في الوقت نفسه ، مقارنةً بتخزين كميات كبيرة من البيانات في Bitcoin blockchain ، بسبب السعة المحدودة وسرعة كتل Bitcoin ، قد يكون من الأرخص تخزين البيانات باستخدام مرحلات Nostr.
يعمل تصميم علوم الكمبيوتر البسيط التالي على تحسين خصائص التوزيع لشبكات Nostr وفقًا لمعيار نظرية CAP الموحدة. CAP تعني الاتساق والتوافر وتحمل التقسيم
** لا يعرف Nostr relay متى يكون ملف التكوين غير مكتمل ، ويفتقر الترحيل إلى التناسق (C في نظرية CAP). **
يفتقر التتابع إلى الاتساق (C في نظرية CAP)
الاتساق يعني أن قواعد البيانات المتزامنة على كل كمبيوتر هي نفسها. لا تستطيع مرحلات Nostr إجراء تزامن مصغر للثقة بطريقة مشابهة لكيفية مزامنة blockchain لبياناتها كتلة تلو الأخرى. على عكس عقد Bitcoin الكاملة ، فإن قاعدة البيانات المخزنة بواسطة Nostr relay عادة ما تكون غير مكتملة. بصرف النظر عن الطلب الأعمى لجميع المنشورات الموقعة من قبل مستخدم معين ، لا يمكن لـ Nostr relay اكتشاف البيانات المفقودة.
** قضايا تناسق / مزامنة Nostr: **
إذا قام مستخدمان بتحميل منشورات كل منهما على مرحلات Nostr مختلفة ، فقد لا يتمكن هذان المستخدمان من رؤية منشورات بعضهما البعض لأن Nostr لا يشبه blockchain. في blockchain ، في كل مرة يوجد فيها سجل جديد ، ستقوم جميع العقد الكاملة بمزامنة blockchain. ستضيف جميع العقد الكاملة هذه البيانات ككتلة إلى blockchain في نفس الوقت. كل عقدة كاملة في Bitcoin blockchain تمتلك نفس blockchain بالضبط.
إذا أردنا أن يتمكن مستخدمو Nostr دائمًا من رؤية منشورات بعضهم البعض ، فحينئذٍ تحتاج جميع مرحلات Nostr إلى طريقة لتحديد البيانات المفقودة في ملفات تعريف المستخدمين حتى يتمكنوا من طلب الأجزاء المفقودة من مرحلات Nostr أو المستخدمين الآخرين.
** استخدم جذر Merkle الأسبوعي على السلسلة وتجزئة الشجرة الكاملة لمزامنة Nostr relay **
مرة واحدة في الأسبوع تقريبًا ، يمكن للمستخدمين تنظيم جميع مشاركاتهم في شجرة Merkle.
تحتوي كل ورقة في شجرة Merkle على تجزئة منشور ، تمامًا مثل كل ورقة في Bitcoin تحتوي على تجزئة للمعاملة.
بمجرد قيام المستخدم بتنظيم ملفه الشخصي بالكامل في شجرة Merkle ، سينشر جذر Merkle في OP \ _RETURN على السلسلة ، أسفل معاملة Bitcoin العادية. هذا هو السبب في أن Nostr 2.0 لا يتطلب شوكة صلبة من blockchain للعمل. OP \ _RETURN هو قسم أسفل معاملة Bitcoin يسمح بإلحاق ملاحظة صغيرة قبل توقيع المرسل.
بالإضافة إلى ذلك ، سيقوم المستخدم بتجزئة الشجرة بأكملها وتحميلها إلى السلسلة مع جذر Merkle (في OP \ _RETURN). جذر Merkle هو مجرد تجزئة للفرع العلوي ، وليس الشجرة بأكملها. تجزئة الشجرة بأكملها ضرورية للمستخدمين والمرحلين حتى يتمكنوا من اكتشاف ما إذا كانت بيانات الملف الشخصي مفقودة.
للحصول على تجزئة للشجرة بأكملها ، ضع جذر Merkle في جذر الملف النصي. ثم ضع فرع Merkle على الخط الموجود أسفل الجذر. ثم ضع أوراق Merkle على الصف الموجود أسفل الفرع. بمجرد ترتيب الشجرة كما هو موصوف ، قم بتجزئةها كلها مرة واحدة. يوجد أدناه مثال على تجزئة شجرة كاملة لما سيبدو عليه تجزئة شجرة كاملة لشجرة Merkle الموضحة أعلاه. تجزئة الشجرة بأكملها (تجزئة جميع بيانات شجرة Merkle مرة واحدة)
توفر تجزئة جذر Merkle وكامل تجزئة الشجرة وظيفتين رئيسيتين:
تتيح جذور Merkle للمستخدمين والمرحلين تنزيل جزء من ملف التكوين في وقت واحد ، مثل القدرة على تنزيل معاملة دون الحاجة إلى تنزيل الكتلة بالكامل.
يتيح تجزئة الشجرة الكاملة للمستخدمين والمرحلين معرفة ما إذا كانت ملفات التكوين المخزنة غير مكتملة. على عكس جذر Merkle ، لن تتطابق تجزئة الشجرة بأكملها إلا إذا كان لديك كل البتات في شجرة Merkle.
يمكن استخدام هذه الطريقة الرخيصة لتحديث ملف التكوين بأكمله على تردد أسبوعي أو محدد من قبل المستخدم. ستظل Nostr تعمل كما هي الآن ، ولكن يمكن للمستخدمين أحيانًا دفع بعض السواتس لمزامنة بياناتهم بين مرحلات Nostr إذا كانوا يريدون أن يطلع جميع المستخدمين على منشوراتهم.
يمكن للمستخدمين والمرحلين تنزيل المنشورات لفرع واحد في كل مرة. بعد كل فرع ، يقومون بتجزئة هذا الفرع مع فرع آخر أقرب إلى جذر Merkle للتحقق مما إذا كان يتطابق مع جذر Merkle في السلسلة (على غرار SPV). إذا تم تجزئة هذه الفروع معًا لتتطابق مع جذر Merkle ، فسيعرفون أن هذا الفرع جزء من ملف تعريف المستخدم ، حتى لو لم يكن لديهم ملف تعريف المستخدم الكامل حتى الآن. يمكن للمستخدمين تنزيل فروع مختلفة من نفس ملف التكوين من العديد من جذوع Nostr المختلفة ، مع التحقق من صلاحية كل فرع والتأكد من اكتمال ملف التكوين الذي تم تنزيله.
يؤدي تنزيل الشوكات واحدًا تلو الآخر إلى منع هجمات التأخير التي يمكن أن تؤدي إلى تدمير العديد من الشبكات الموزعة ، ولهذا السبب تُستخدم جذور وشوكات Merkle في ورقة Bitcoin البيضاء لحماية محافظ SPV الخفيفة.
** لماذا لا يعمل جذر Merkle مثل تجزئة شجرة كاملة؟ **
** إذا كان Nostr يعتمد فقط على جذر Merkle ، فلن يتمكنوا من معرفة متى اكتملت شجرة Merkle ، نظرًا لأن كل زوج من الفروع الأقرب إلى جذر Merkle سوف يتم تجزئته في نفس جذر Merkle. **
لضمان اكتمال ملف تعريف المستخدم ، سيقوم المُرحِّل أو المستخدم بتجزئة شجرة Merkle المُحدَّثة بالكامل والتحقق من أنها تطابق تجزئة الشجرة بأكملها على السلسلة. إذا كانت تجزئة الشجرة بأكملها متطابقة ، فستكتمل بيانات المستخدم. إذا كانت تجزئة الشجرة بأكملها غير متطابقة ، فيمكن للمرحل أو المستخدم إخبار المرحلات الأخرى بأحدث رقم أوراق خاص بهم وطلب الفرع المفقود حتى تطابق تجزئة الشجرة بأكملها. من أجل تتبع جميع جذور Merkle الجديدة التي تتم إضافتها كل أسبوع أو نحو ذلك ، يجب أن تصبح مرحلات Nostr عُقدًا كاملة لـ Bitcoin. يتم دفع مرحلات Nostr 2.0 بشكل غير مباشر لتخزين Bitcoin blockchain مع تعزيز أمان Bitcoin و Nostr.
** حدود تخزين Nostr: قاعدة إبهام المستخدم **
نظرًا لأن المرحلات لها الحق في اختيار ما تريد تخزينه ، على عكس عقد Bitcoin الكاملة ، فقد تفقد مرحلات Nostr بعض بيانات المستخدم. لذلك ، يجب على المستخدمين تخزين البيانات على مرحل Nostr فقط ، إذا كان بإمكان المستخدمين عمل نسخ احتياطية محليًا. تتيح خدمة Web5 ذاتية الاستضافة للمستخدمين مزامنة النسخ الاحتياطية مع جميع أجهزتهم المحلية ، مما سيقلل من المخاطر التي يتعرض لها المستخدمون المهتمون باستخدام Nostr. في نهاية اليوم ، فقط blockchain هو المكان الذي تكون فيه البيانات غير قابلة للتغيير حقًا. ومع ذلك ، فإن Nostr هو حل هجين آمن إلى حد ما وسيظل يعمل بشكل جيد للعديد من التطبيقات. المفاضلات مذكورة أدناه:
** ثلاث طبقات لتقليل الثقة **
المستوى 1: تخزين البيانات غير القابل للتغيير والمكلف الذي يصعب للغاية مراقبته. (تقوم الكتل الموجودة على السلسلة بمزامنة جميع عقد Bitcoin الكاملة)
المستوى 2: تخزين بيانات متغير ورخيص ، رقابة صعبة بدرجة متوسطة. (شجرة Merkle خارج السلسلة وتجزئة على السلسلة ، مرحل Nostr متزامن عند الطلب)
تخزين البيانات المحلية المتزامنة مع جميع الأجهزة المحلية ، من السهل أن تخضع للرقابة. (مركزية محلية)
** المقايضات الأساسية بين بلوكشين ناكاموتو القائمة على الإجماع ونوستر **
** كلما زاد عدد مرات ترحيل Nostr التي تخزن البيانات لعنوان معين ، زادت صعوبة فرض الرقابة على تلك البيانات. هذا يعني أن البيانات الشائعة التي يستضيفها العديد من مرحلات Nostr قد يكون من الصعب مراقبتها أكثر من البيانات غير الشائعة التي نادرًا ما يتم تنزيلها. **
** من ناحية أخرى ، فإن blockchain المُجمع في ناكاموتو يمنع الرقابة بناءً على عمر البيانات. كلما كانت البيانات أطول في blockchain ، زادت صعوبة حذفها باستخدام هجوم بنسبة 51٪. **
نظرًا لأنه يمكننا التحقق من أن بعض الشوكات تنتمي إلى مستخدمين محددين ، يمكن دفع مرحلات Nostr في كل مرة يقومون فيها بتمرير جزء صغير من البيانات إلى مستخدم. من أجل تحقيق ذلك ، يحتاج المستخدم إلى تنزيل رأس blockchain (كما في SPV) حتى يتمكن من أداء الوظائف النموذجية للمحفظة الخفيفة. سيستفيد المستخدم من وظيفة SPV الخاصة بالمحفظة الخفيفة لجلب معاملة معينة من السلسلة ، والتي ستتضمن جذر Merkle لملف تعريف المستخدم وتجزئة الشجرة بأكملها في OP \ _RETURN. يمكن للمستخدمين الآن دفع الترحيل لتنزيل فرع ملف تعريف المستخدم حسب الفرع ، والتحقق من كل فرع عن طريق تجزئته لمطابقة جذر Merkle على السلسلة.
من أجل إرسال ساتس (أصغر وحدة بيتكوين) إلى مرحل Nostr في مقابل توفير البيانات ، نستخدم تصميم ZKCP (مطور Bitcoin Core الشهير) لـ Gregory Maxwell (مدفوعات مشروطة صفرية المعرفة) [1] نسخة مطورة من ZKCSP: إثبات قابلية الاسترجاع [2] مدمج مع شبكة Lightning Network.
وفقًا لوصف الورقة البيضاء ZKCSP:
"... لا حاجة لطرف ثالث موثوق به ... لقد طبقنا أيضًا بروتوكول ZKCSP لحالة إثبات قابلية الاسترداد ، حيث يدفع العميل للخادم لإثبات أن بيانات العميل مخزنة بشكل صحيح على الخادم." [2]
يقوم المستخدم ببدء عقد Lightning smart مع العديد من الممولين.
يرسل المستخدم طلبات إلى الممولين المحيطين. يوقع الممول على الطلب.
يرسل المستخدمون الطلبات الموقعة من قبل الممولين مباشرة إلى مرحلات Nostr المتصلة بهؤلاء الممولين.
يبدأ المستخدمون الآن إنشاءات ZKCSP للتأكد من أن مرحلات Nostr تحصل على أموال من الممولين فقط بعد تسليم البيانات المطلوبة بشكل صحيح.
بمجرد حدوث الخطوة 3 ، سيقوم المستخدم بإجراء تعديلات على الطلب الأصلي الموقع من قبل الممول قبل البدء في إنشاء ZKCSP في الخطوة 4. سيضيف المستخدم مبلغًا إضافيًا أعلى الطلب الأصلي ، مع تحديد المبلغ المراد خصمه من أرصدة كل من المستخدم والممول (يجب أن يكونا نفس المبلغ ، بالإضافة إلى رسوم الممول) ، والتي سيقوم المستخدم بعد ذلك بإلحاقها بالرسالة الأصلية المحتوى للتوقيع.
** إذا قرر المستخدم إرسال عدد من جلسات ساتس أكثر مما يمتلكه ، أو إذا جمد الممول أكثر من مرحل Nostr هذا ، فإن مرحل Nostr سيرفض الطلب لأن المرحل لن يكون قادرًا على الدفع. **
بهذه الطريقة ، يمكن للمستخدمين الاتصال بالعديد من مرحلات Nostr أثناء تجميد أموالهم مع عدد قليل فقط من الممولين. يمكن اتباع نهج مماثل مع شبكة Lightning Network ، حيث يكون المموّلون الذين تقلص الثقة هم وسطاء غير مرخصين بين المستخدمين والتجار. تتوفر قفزات البرق العادية P2P أيضًا في Nostr 2.0 ، ولكن قد يكون هذا مفيدًا إذا فشل التوجيه وموازنة القنوات بشكل متكرر.
** القائمة البيضاء إفتح Nostr Relay المدفوعة **
يمكن لمرحلات Nostr إدراج مفاتيح معينة في القائمة البيضاء إذا كانوا يرغبون في تخزين البيانات التي يشاهدها كل هؤلاء المستخدمين. إذا كانت مرحلات Nostr غير قادرة على إدراج المستخدمين الراغبين في تخزين البيانات في القائمة البيضاء ، فسوف يقومون بتخزين أي بيانات يتم إرسالها إليهم. إذا كان بإمكان المستخدمين دائمًا إرسال البيانات إلى المرحلات مجانًا ، فلن يحتاج المستخدمون أبدًا إلى الدفع مقابل مرحلات Nostr. لا يمكن لـ Nostr تقديم خيارات مدفوعة إلا إذا كان لدى المرحل خيار رفض تخزين البيانات التي لا يمكن الدفع مقابلها. لا تزال المرحلات المجانية موجودة ، لكن خيار المرحلات المدفوعة غير موجود حاليًا.
بدلاً من محاولة تخزين جميع بيانات Nostr مجانًا ، يمكن لترحيل Nostr المدفوع استخدام القائمة البيضاء لتخزين جميع البيانات التي يعرضها المستخدمون الذين يدفعون على أساس يومي بشكل انتقائي. ستستمر بعض مرحلات Nostr في العمل على نموذج مجاني ، ولكن على نطاق واسع ، هذا ليس مستدامًا لأن معظم المرحلات المجانية هي مجرد متحمسين متحمسين. وضع القائمة البيضاء (حتى لو تمكنا من تعيين مفتاح عام بشكل آمن لكل ملف تعريف Nostr) يمنح Nostr relay القدرة على تحديد البيانات التي لن يتم تخزينها.
يفتح مفتاح عام واحد لكل ملف تعريف ميزة القائمة البيضاء: يصبح عنوان Bitcoin مفتاح Nostr العام الخاص بك.
يسمح لنا هذا النظام أخيرًا بتعيين مفتاح عام لكل ملف تكوين.
ليست هناك فائدة من إنشاء المستخدمين لمفاتيح عامة جديدة لكل منشور ... لأنهم جميعًا مرتبطون بملفاتهم الشخصية! هذا ليس هو نفسه عنوان Bitcoin. على عكس Bitcoin ، فإن امتلاك المستخدمين لمفاتيح عامة متعددة داخل نفس التطبيق لا يؤدي إلى تحسين الخصوصية.
** يجب أن يتطابق المفتاح العام لملف تعريف Nostr مع المفتاح العام لمعاملة Bitcoin التي تحتوي على التجزئة الأسبوعية (جذر Merkle لجميع منشورات المستخدم وتجزئة الشجرة بأكملها). على عكس مستخدمي Nostr الذين يستخدمون توقيعات شنور ، سيحتاجون إلى استخدام محفظة بيتكوين (محفظة محمولة / محفظة خفيفة أو عقدة كاملة) للتوقيع. **
يكمن جمال هذا في أن كل حساب Nostr سيتم تمثيله بعنوان Bitcoin الخاص به ، ** مما يعني أنه يمكن للمستخدمين إرسال المدفوعات مباشرة إلى حسابات Nostr دون طلب مفتاحين عامين مختلفين. هذا يقلل من التكلفة المعرفية للمستخدمين الجدد في النظام. بدلاً من استخدام أسماء المستخدمين ، لا يزال المستخدمون بحاجة إلى إرسال مفاتيح عامة أو DNS لبعضهم البعض للعثور على بعضهم البعض على Nostr. **
إذا كانت تطبيقات Nostr الأخرى تستخدم مفاتيح عامة مختلفة ، فلا يزال من الممكن إرفاقها بنفس الهوية اللامركزية (DID) - وبهذه الطريقة ، تظل طريقة تحديد حسابك متسقة عبر التطبيقات. ومع ذلك ، ستحد قاعدة إجماع Nostr هذه من استخدام مفتاح عام واحد فقط لكل ملف تعريف في كل تطبيق Nostr.
يعمل DHT بمثابة لوحة ليدربورد لاكتشاف الأقران.
يمكن أن تستخدم المرحلات جدول تجزئة موزع (DHT) للعثور على مرحلات أخرى. يمكن أن تشارك المرحلات قائمتهم البيضاء في جدول التجزئة الموزع عن طريق سرد المفتاح العام حيث يتم تخزين البيانات. بهذه الطريقة ، يمكن للمرحلات التي تحتوي على تفرعات مفقودة من البيانات لمفتاح عام معين مسح DHT والاتصال مباشرة بعناوين IP للمرحلات الأخرى التي تدعي تخزين تلك الشوكات المفقودة. يمكن للمرحلات بعد ذلك تنزيل الفروع المفقودة مباشرة من مرحلات Nostr هذه.
ستتمكن المرحلات أيضًا من العثور على أكثر المرحلات نشاطًا عن طريق التحقق من عدد معاملات ZKCSP السابقة التي قامت هذه المرحلات بحلها على السلسلة - حديثة وفي كل الأوقات. في هذا النظام ، تصبح جميع مرحلات Nostr عُقدًا كاملة ، لذا فإن تدقيق المعاملات السابقة للمرحلات الأخرى سيكون أمرًا غير مؤلم. هذا من شأنه أن يجعل تكوين الثقة مكلفًا ، لأن المعاملات على السلسلة تتطلب دائمًا رسوم المعاملات. إذا فتح مرحل Nostr العديد من القنوات لبناء الثقة مع نفسه من أجل كسب ثقة المرحلات الأخرى ، فسيتعين عليه دفع الكثير من رسوم المعاملات للحفاظ على السمعة المزيفة كل أسبوع. بعد فشل المهاجم في توفير الفرع المفقود ، ستؤدي المهلة الزمنية إلى قطع اتصال الترحيل - لذلك يعد هذا هجومًا مؤقتًا ومكلفًا (تمامًا مثل هجوم 51٪ هو هجوم مؤقت ومكلف).
إن DHT ليس مجهولاً مثل التعدين ، حيث سيتم إدراج كل مفتاح عام لترحيل Nostr بجوار عنوان IP في DHT ، ولكنه سيتجنب الحاجة إلى المرحلات لإرسال الطلبات بشكل أعمى عبر الشبكة - على نطاق واسع بما يكفي ، هذا سوف تفرط في الشبكة. يمكن لمُرحلي Nostr الذين يبحثون عن مزيد من الخصوصية استخدام VPN أو خدمة حماية IP أخرى.
لن يتمكن المستخدمون من الوصول إلى نفس نظام الثقة هذا لأنهم ليسوا عقدًا كاملة. ومع ذلك ، يمكن للمستخدمين الاعتماد عليها.
** مربي الحيوانات مرتبطون بشكل غير مباشر بمئات مرحلات Nostr **
نظرًا لأن المستخدمين يقومون تلقائيًا بتخزين جميع رؤوس الكتل في محافظهم الخفيفة ، يمكن للمستخدمين معرفة من هم أكثر عمال المناجم نشاطًا. سيمكن عمال المناجم الذين يتحولون إلى ممولين المستخدمين من تصفية أشهر عمال المناجم حتى لا يضطروا إلى ربط الأموال بشكل أعمى بممولين عشوائيين لا علاقة لهم بصلاحية الشبكة.
** يحتاج المموّلون (عمال المناجم) فقط إلى تأمين جلستهم باستخدام مرحل Nostr ، دون تمرير البيانات نفسها بين المستخدمين والترحيل. ** يحتاج الممول (عامل التعدين) فقط إلى التوقيع على طلب المستخدم حتى يتمكن المستخدم من التفاعل مباشرة مع جميع مرحلات Nostr التي يتصل بها الممول - 4 خطوات لـ ZKCSP + Lightning على النحو الوارد أعلاه.
ختاماً
لن تكون شبكة Lightning Network موجودة بدون blockchain الإجماع على Nakamoto من Bitcoin ، حيث لن يكون لدى المستخدمين مكان لتخزين البراهين المجمعة للمعاملات خارج السلسلة.
تمامًا مثل تجميع جميع معاملات Lightning Network هذه معًا ووضع أدلة صغيرة في blockchain ، سنقوم بتجميع جميع بيانات Nostr ووضع أدلة صغيرة في blockchain. بالطريقة نفسها التي توفر بها Lightning Network مدفوعات فورية في الطبقة الثانية ، قد تتمكن Nostr من توفير تخزين البيانات في الطبقة الثانية دون المخاطرة بسلسلة جانبية غير آمنة. **
** تستخدم نفس نهج شبكة Lightning Network ، مع blockchain بإجماع Nakamoto من Bitcoin على الطبقة الأولى و Nostr + ZKCSP Lightning على الطبقة الثانية. **
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
Nostr2.0: كطبقة تخزين بيانات تحت سلسلة Bitcoin Layer 2
المؤلف: Colby Serpa Compiler: DAOrayaki
قد يكون Nostr 2.0 قادرًا على البناء على Bitcoin كطبقة 2 ، مما يوفر تخزينًا آمنًا للبيانات خارج السلسلة ، تمامًا كما توفر Lightning Network مدفوعات فورية خارج السلسلة كطبقة 2.
تشرح هذه المقالة كيف يقوم مرحل Nostr بمزامنة بياناته مع الحفاظ على طبيعته خفيفة الوزن ، مما يسمح للمستخدمين بحذف البيانات بشكل انتقائي ، وهو أمر غير متوفر في سلاسل الكتل من الطبقة الأولى. في الوقت نفسه ، مقارنةً بتخزين كميات كبيرة من البيانات في Bitcoin blockchain ، بسبب السعة المحدودة وسرعة كتل Bitcoin ، قد يكون من الأرخص تخزين البيانات باستخدام مرحلات Nostr.
يعمل تصميم علوم الكمبيوتر البسيط التالي على تحسين خصائص التوزيع لشبكات Nostr وفقًا لمعيار نظرية CAP الموحدة. CAP تعني الاتساق والتوافر وتحمل التقسيم
** لا يعرف Nostr relay متى يكون ملف التكوين غير مكتمل ، ويفتقر الترحيل إلى التناسق (C في نظرية CAP). **
يفتقر التتابع إلى الاتساق (C في نظرية CAP)
الاتساق يعني أن قواعد البيانات المتزامنة على كل كمبيوتر هي نفسها. لا تستطيع مرحلات Nostr إجراء تزامن مصغر للثقة بطريقة مشابهة لكيفية مزامنة blockchain لبياناتها كتلة تلو الأخرى. على عكس عقد Bitcoin الكاملة ، فإن قاعدة البيانات المخزنة بواسطة Nostr relay عادة ما تكون غير مكتملة. بصرف النظر عن الطلب الأعمى لجميع المنشورات الموقعة من قبل مستخدم معين ، لا يمكن لـ Nostr relay اكتشاف البيانات المفقودة.
** قضايا تناسق / مزامنة Nostr: **
إذا قام مستخدمان بتحميل منشورات كل منهما على مرحلات Nostr مختلفة ، فقد لا يتمكن هذان المستخدمان من رؤية منشورات بعضهما البعض لأن Nostr لا يشبه blockchain. في blockchain ، في كل مرة يوجد فيها سجل جديد ، ستقوم جميع العقد الكاملة بمزامنة blockchain. ستضيف جميع العقد الكاملة هذه البيانات ككتلة إلى blockchain في نفس الوقت. كل عقدة كاملة في Bitcoin blockchain تمتلك نفس blockchain بالضبط.
إذا أردنا أن يتمكن مستخدمو Nostr دائمًا من رؤية منشورات بعضهم البعض ، فحينئذٍ تحتاج جميع مرحلات Nostr إلى طريقة لتحديد البيانات المفقودة في ملفات تعريف المستخدمين حتى يتمكنوا من طلب الأجزاء المفقودة من مرحلات Nostr أو المستخدمين الآخرين.
** استخدم جذر Merkle الأسبوعي على السلسلة وتجزئة الشجرة الكاملة لمزامنة Nostr relay **
توفر تجزئة جذر Merkle وكامل تجزئة الشجرة وظيفتين رئيسيتين:
يمكن استخدام هذه الطريقة الرخيصة لتحديث ملف التكوين بأكمله على تردد أسبوعي أو محدد من قبل المستخدم. ستظل Nostr تعمل كما هي الآن ، ولكن يمكن للمستخدمين أحيانًا دفع بعض السواتس لمزامنة بياناتهم بين مرحلات Nostr إذا كانوا يريدون أن يطلع جميع المستخدمين على منشوراتهم.
يمكن للمستخدمين والمرحلين تنزيل المنشورات لفرع واحد في كل مرة. بعد كل فرع ، يقومون بتجزئة هذا الفرع مع فرع آخر أقرب إلى جذر Merkle للتحقق مما إذا كان يتطابق مع جذر Merkle في السلسلة (على غرار SPV). إذا تم تجزئة هذه الفروع معًا لتتطابق مع جذر Merkle ، فسيعرفون أن هذا الفرع جزء من ملف تعريف المستخدم ، حتى لو لم يكن لديهم ملف تعريف المستخدم الكامل حتى الآن. يمكن للمستخدمين تنزيل فروع مختلفة من نفس ملف التكوين من العديد من جذوع Nostr المختلفة ، مع التحقق من صلاحية كل فرع والتأكد من اكتمال ملف التكوين الذي تم تنزيله.
يؤدي تنزيل الشوكات واحدًا تلو الآخر إلى منع هجمات التأخير التي يمكن أن تؤدي إلى تدمير العديد من الشبكات الموزعة ، ولهذا السبب تُستخدم جذور وشوكات Merkle في ورقة Bitcoin البيضاء لحماية محافظ SPV الخفيفة.
** لماذا لا يعمل جذر Merkle مثل تجزئة شجرة كاملة؟ **
** إذا كان Nostr يعتمد فقط على جذر Merkle ، فلن يتمكنوا من معرفة متى اكتملت شجرة Merkle ، نظرًا لأن كل زوج من الفروع الأقرب إلى جذر Merkle سوف يتم تجزئته في نفس جذر Merkle. **
لضمان اكتمال ملف تعريف المستخدم ، سيقوم المُرحِّل أو المستخدم بتجزئة شجرة Merkle المُحدَّثة بالكامل والتحقق من أنها تطابق تجزئة الشجرة بأكملها على السلسلة. إذا كانت تجزئة الشجرة بأكملها متطابقة ، فستكتمل بيانات المستخدم. إذا كانت تجزئة الشجرة بأكملها غير متطابقة ، فيمكن للمرحل أو المستخدم إخبار المرحلات الأخرى بأحدث رقم أوراق خاص بهم وطلب الفرع المفقود حتى تطابق تجزئة الشجرة بأكملها. من أجل تتبع جميع جذور Merkle الجديدة التي تتم إضافتها كل أسبوع أو نحو ذلك ، يجب أن تصبح مرحلات Nostr عُقدًا كاملة لـ Bitcoin. يتم دفع مرحلات Nostr 2.0 بشكل غير مباشر لتخزين Bitcoin blockchain مع تعزيز أمان Bitcoin و Nostr.
** حدود تخزين Nostr: قاعدة إبهام المستخدم **
نظرًا لأن المرحلات لها الحق في اختيار ما تريد تخزينه ، على عكس عقد Bitcoin الكاملة ، فقد تفقد مرحلات Nostr بعض بيانات المستخدم. لذلك ، يجب على المستخدمين تخزين البيانات على مرحل Nostr فقط ، إذا كان بإمكان المستخدمين عمل نسخ احتياطية محليًا. تتيح خدمة Web5 ذاتية الاستضافة للمستخدمين مزامنة النسخ الاحتياطية مع جميع أجهزتهم المحلية ، مما سيقلل من المخاطر التي يتعرض لها المستخدمون المهتمون باستخدام Nostr. في نهاية اليوم ، فقط blockchain هو المكان الذي تكون فيه البيانات غير قابلة للتغيير حقًا. ومع ذلك ، فإن Nostr هو حل هجين آمن إلى حد ما وسيظل يعمل بشكل جيد للعديد من التطبيقات. المفاضلات مذكورة أدناه:
** ثلاث طبقات لتقليل الثقة **
** المقايضات الأساسية بين بلوكشين ناكاموتو القائمة على الإجماع ونوستر **
** كلما زاد عدد مرات ترحيل Nostr التي تخزن البيانات لعنوان معين ، زادت صعوبة فرض الرقابة على تلك البيانات. هذا يعني أن البيانات الشائعة التي يستضيفها العديد من مرحلات Nostr قد يكون من الصعب مراقبتها أكثر من البيانات غير الشائعة التي نادرًا ما يتم تنزيلها. **
** من ناحية أخرى ، فإن blockchain المُجمع في ناكاموتو يمنع الرقابة بناءً على عمر البيانات. كلما كانت البيانات أطول في blockchain ، زادت صعوبة حذفها باستخدام هجوم بنسبة 51٪. **
نظرًا لأنه يمكننا التحقق من أن بعض الشوكات تنتمي إلى مستخدمين محددين ، يمكن دفع مرحلات Nostr في كل مرة يقومون فيها بتمرير جزء صغير من البيانات إلى مستخدم. من أجل تحقيق ذلك ، يحتاج المستخدم إلى تنزيل رأس blockchain (كما في SPV) حتى يتمكن من أداء الوظائف النموذجية للمحفظة الخفيفة. سيستفيد المستخدم من وظيفة SPV الخاصة بالمحفظة الخفيفة لجلب معاملة معينة من السلسلة ، والتي ستتضمن جذر Merkle لملف تعريف المستخدم وتجزئة الشجرة بأكملها في OP \ _RETURN. يمكن للمستخدمين الآن دفع الترحيل لتنزيل فرع ملف تعريف المستخدم حسب الفرع ، والتحقق من كل فرع عن طريق تجزئته لمطابقة جذر Merkle على السلسلة.
من أجل إرسال ساتس (أصغر وحدة بيتكوين) إلى مرحل Nostr في مقابل توفير البيانات ، نستخدم تصميم ZKCP (مطور Bitcoin Core الشهير) لـ Gregory Maxwell (مدفوعات مشروطة صفرية المعرفة) [1] نسخة مطورة من ZKCSP: إثبات قابلية الاسترجاع [2] مدمج مع شبكة Lightning Network.
وفقًا لوصف الورقة البيضاء ZKCSP:
"... لا حاجة لطرف ثالث موثوق به ... لقد طبقنا أيضًا بروتوكول ZKCSP لحالة إثبات قابلية الاسترداد ، حيث يدفع العميل للخادم لإثبات أن بيانات العميل مخزنة بشكل صحيح على الخادم." [2]
بمجرد حدوث الخطوة 3 ، سيقوم المستخدم بإجراء تعديلات على الطلب الأصلي الموقع من قبل الممول قبل البدء في إنشاء ZKCSP في الخطوة 4. سيضيف المستخدم مبلغًا إضافيًا أعلى الطلب الأصلي ، مع تحديد المبلغ المراد خصمه من أرصدة كل من المستخدم والممول (يجب أن يكونا نفس المبلغ ، بالإضافة إلى رسوم الممول) ، والتي سيقوم المستخدم بعد ذلك بإلحاقها بالرسالة الأصلية المحتوى للتوقيع.
** إذا قرر المستخدم إرسال عدد من جلسات ساتس أكثر مما يمتلكه ، أو إذا جمد الممول أكثر من مرحل Nostr هذا ، فإن مرحل Nostr سيرفض الطلب لأن المرحل لن يكون قادرًا على الدفع. **
بهذه الطريقة ، يمكن للمستخدمين الاتصال بالعديد من مرحلات Nostr أثناء تجميد أموالهم مع عدد قليل فقط من الممولين. يمكن اتباع نهج مماثل مع شبكة Lightning Network ، حيث يكون المموّلون الذين تقلص الثقة هم وسطاء غير مرخصين بين المستخدمين والتجار. تتوفر قفزات البرق العادية P2P أيضًا في Nostr 2.0 ، ولكن قد يكون هذا مفيدًا إذا فشل التوجيه وموازنة القنوات بشكل متكرر.
** القائمة البيضاء إفتح Nostr Relay المدفوعة **
يمكن لمرحلات Nostr إدراج مفاتيح معينة في القائمة البيضاء إذا كانوا يرغبون في تخزين البيانات التي يشاهدها كل هؤلاء المستخدمين. إذا كانت مرحلات Nostr غير قادرة على إدراج المستخدمين الراغبين في تخزين البيانات في القائمة البيضاء ، فسوف يقومون بتخزين أي بيانات يتم إرسالها إليهم. إذا كان بإمكان المستخدمين دائمًا إرسال البيانات إلى المرحلات مجانًا ، فلن يحتاج المستخدمون أبدًا إلى الدفع مقابل مرحلات Nostr. لا يمكن لـ Nostr تقديم خيارات مدفوعة إلا إذا كان لدى المرحل خيار رفض تخزين البيانات التي لا يمكن الدفع مقابلها. لا تزال المرحلات المجانية موجودة ، لكن خيار المرحلات المدفوعة غير موجود حاليًا.
بدلاً من محاولة تخزين جميع بيانات Nostr مجانًا ، يمكن لترحيل Nostr المدفوع استخدام القائمة البيضاء لتخزين جميع البيانات التي يعرضها المستخدمون الذين يدفعون على أساس يومي بشكل انتقائي. ستستمر بعض مرحلات Nostr في العمل على نموذج مجاني ، ولكن على نطاق واسع ، هذا ليس مستدامًا لأن معظم المرحلات المجانية هي مجرد متحمسين متحمسين. وضع القائمة البيضاء (حتى لو تمكنا من تعيين مفتاح عام بشكل آمن لكل ملف تعريف Nostr) يمنح Nostr relay القدرة على تحديد البيانات التي لن يتم تخزينها.
يفتح مفتاح عام واحد لكل ملف تعريف ميزة القائمة البيضاء: يصبح عنوان Bitcoin مفتاح Nostr العام الخاص بك.
يسمح لنا هذا النظام أخيرًا بتعيين مفتاح عام لكل ملف تكوين.
ليست هناك فائدة من إنشاء المستخدمين لمفاتيح عامة جديدة لكل منشور ... لأنهم جميعًا مرتبطون بملفاتهم الشخصية! هذا ليس هو نفسه عنوان Bitcoin. على عكس Bitcoin ، فإن امتلاك المستخدمين لمفاتيح عامة متعددة داخل نفس التطبيق لا يؤدي إلى تحسين الخصوصية.
** يجب أن يتطابق المفتاح العام لملف تعريف Nostr مع المفتاح العام لمعاملة Bitcoin التي تحتوي على التجزئة الأسبوعية (جذر Merkle لجميع منشورات المستخدم وتجزئة الشجرة بأكملها). على عكس مستخدمي Nostr الذين يستخدمون توقيعات شنور ، سيحتاجون إلى استخدام محفظة بيتكوين (محفظة محمولة / محفظة خفيفة أو عقدة كاملة) للتوقيع. **
يكمن جمال هذا في أن كل حساب Nostr سيتم تمثيله بعنوان Bitcoin الخاص به ، ** مما يعني أنه يمكن للمستخدمين إرسال المدفوعات مباشرة إلى حسابات Nostr دون طلب مفتاحين عامين مختلفين. هذا يقلل من التكلفة المعرفية للمستخدمين الجدد في النظام. بدلاً من استخدام أسماء المستخدمين ، لا يزال المستخدمون بحاجة إلى إرسال مفاتيح عامة أو DNS لبعضهم البعض للعثور على بعضهم البعض على Nostr. **
إذا كانت تطبيقات Nostr الأخرى تستخدم مفاتيح عامة مختلفة ، فلا يزال من الممكن إرفاقها بنفس الهوية اللامركزية (DID) - وبهذه الطريقة ، تظل طريقة تحديد حسابك متسقة عبر التطبيقات. ومع ذلك ، ستحد قاعدة إجماع Nostr هذه من استخدام مفتاح عام واحد فقط لكل ملف تعريف في كل تطبيق Nostr.
يعمل DHT بمثابة لوحة ليدربورد لاكتشاف الأقران.
يمكن أن تستخدم المرحلات جدول تجزئة موزع (DHT) للعثور على مرحلات أخرى. يمكن أن تشارك المرحلات قائمتهم البيضاء في جدول التجزئة الموزع عن طريق سرد المفتاح العام حيث يتم تخزين البيانات. بهذه الطريقة ، يمكن للمرحلات التي تحتوي على تفرعات مفقودة من البيانات لمفتاح عام معين مسح DHT والاتصال مباشرة بعناوين IP للمرحلات الأخرى التي تدعي تخزين تلك الشوكات المفقودة. يمكن للمرحلات بعد ذلك تنزيل الفروع المفقودة مباشرة من مرحلات Nostr هذه.
ستتمكن المرحلات أيضًا من العثور على أكثر المرحلات نشاطًا عن طريق التحقق من عدد معاملات ZKCSP السابقة التي قامت هذه المرحلات بحلها على السلسلة - حديثة وفي كل الأوقات. في هذا النظام ، تصبح جميع مرحلات Nostr عُقدًا كاملة ، لذا فإن تدقيق المعاملات السابقة للمرحلات الأخرى سيكون أمرًا غير مؤلم. هذا من شأنه أن يجعل تكوين الثقة مكلفًا ، لأن المعاملات على السلسلة تتطلب دائمًا رسوم المعاملات. إذا فتح مرحل Nostr العديد من القنوات لبناء الثقة مع نفسه من أجل كسب ثقة المرحلات الأخرى ، فسيتعين عليه دفع الكثير من رسوم المعاملات للحفاظ على السمعة المزيفة كل أسبوع. بعد فشل المهاجم في توفير الفرع المفقود ، ستؤدي المهلة الزمنية إلى قطع اتصال الترحيل - لذلك يعد هذا هجومًا مؤقتًا ومكلفًا (تمامًا مثل هجوم 51٪ هو هجوم مؤقت ومكلف).
إن DHT ليس مجهولاً مثل التعدين ، حيث سيتم إدراج كل مفتاح عام لترحيل Nostr بجوار عنوان IP في DHT ، ولكنه سيتجنب الحاجة إلى المرحلات لإرسال الطلبات بشكل أعمى عبر الشبكة - على نطاق واسع بما يكفي ، هذا سوف تفرط في الشبكة. يمكن لمُرحلي Nostr الذين يبحثون عن مزيد من الخصوصية استخدام VPN أو خدمة حماية IP أخرى.
لن يتمكن المستخدمون من الوصول إلى نفس نظام الثقة هذا لأنهم ليسوا عقدًا كاملة. ومع ذلك ، يمكن للمستخدمين الاعتماد عليها.
** مربي الحيوانات مرتبطون بشكل غير مباشر بمئات مرحلات Nostr **
نظرًا لأن المستخدمين يقومون تلقائيًا بتخزين جميع رؤوس الكتل في محافظهم الخفيفة ، يمكن للمستخدمين معرفة من هم أكثر عمال المناجم نشاطًا. سيمكن عمال المناجم الذين يتحولون إلى ممولين المستخدمين من تصفية أشهر عمال المناجم حتى لا يضطروا إلى ربط الأموال بشكل أعمى بممولين عشوائيين لا علاقة لهم بصلاحية الشبكة.
** يحتاج المموّلون (عمال المناجم) فقط إلى تأمين جلستهم باستخدام مرحل Nostr ، دون تمرير البيانات نفسها بين المستخدمين والترحيل. ** يحتاج الممول (عامل التعدين) فقط إلى التوقيع على طلب المستخدم حتى يتمكن المستخدم من التفاعل مباشرة مع جميع مرحلات Nostr التي يتصل بها الممول - 4 خطوات لـ ZKCSP + Lightning على النحو الوارد أعلاه.
ختاماً
لن تكون شبكة Lightning Network موجودة بدون blockchain الإجماع على Nakamoto من Bitcoin ، حيث لن يكون لدى المستخدمين مكان لتخزين البراهين المجمعة للمعاملات خارج السلسلة.
تمامًا مثل تجميع جميع معاملات Lightning Network هذه معًا ووضع أدلة صغيرة في blockchain ، سنقوم بتجميع جميع بيانات Nostr ووضع أدلة صغيرة في blockchain. بالطريقة نفسها التي توفر بها Lightning Network مدفوعات فورية في الطبقة الثانية ، قد تتمكن Nostr من توفير تخزين البيانات في الطبقة الثانية دون المخاطرة بسلسلة جانبية غير آمنة. **
** تستخدم نفس نهج شبكة Lightning Network ، مع blockchain بإجماع Nakamoto من Bitcoin على الطبقة الأولى و Nostr + ZKCSP Lightning على الطبقة الثانية. **