عند الخوض في مستقبل اعتماد Bitcoin وتطويره، هناك مشكلة واحدة تتعلق بتفاعل البرامج والتي تأتي في طليعة حواجز الطرق التي يجب على مطوري الطرق التعامل معها: التوافق. نظرًا لأن التطبيقات والبروتوكولات في هذا المجال أصبحت أكثر تعقيدًا وميزات من أجل تلبية احتياجات المستخدمين الفعليين وحالات الاستخدام، فإن هذا يمثل معضلة لها في الأساس إجابتان حقيقيتان فقط؛ يجب أن يدمج التطبيق أو المحفظة داخليًا كل بروتوكول وميزة ضرورية لتلبية متطلبات الغرض منه، أو يجب أن تكون التطبيقات المختلفة قادرة على التحدث مع بعضها البعض.
أحد الأمثلة على ظهور هذه المشكلة هو دمج Lightning في التطبيقات وأدوات البرامج المختلفة. Lightning عبارة عن حزمة بروتوكولات معقدة جدًا للتنفيذ، وتتضمن العديد من البروتوكولات الفرعية التي تملي كيفية تنسيق ومعالجة التحديثات لحالة قناة Lightning. يتضمن ذلك هيكل المعاملة لكل حالة قناة وما يتم تنفيذه، والترتيب الذي يتم به إجراء كل خطوة من خطوات صياغة المعاملات الجديدة وتوقيعها لضمان سلامة أموال المستخدم، ووظائف مراقبة blockchain للتفاعل بالطريقة المناسبة تلقائيًا إذا يتم إرسال الحالات غير الصالحة إلى blockchain.
يعد هذا أمرًا معقدًا للغاية بالنسبة لمطور تطبيق واحد ليقوم بالتكامل المباشر مع مشروعه. الاستنتاج الواضح إذا كان ذلك يتطلب الكثير من الجهد هو الاعتماد على البرامج التي تم إنتاجها بالفعل والتي تتعامل مع مشكلة تنفيذ Lightning، وقم ببساطة ببناء التطبيق الخاص بك للتحدث مع هذا البرنامج الخارجي. يؤدي ذلك إلى المشكلة التالية: ماذا لو كان مستخدمو التطبيق الخاص بك لا يستخدمون تطبيق Lightning أو المحفظة المحددة؟
حتى من خلال الاستعانة بمصادر خارجية لهذه الوظيفة الخاصة بالتطبيق، فإن فريق التطوير لم يفلت تمامًا من مشكلة التعقيد. على الرغم من أنهم لا يتعين عليهم تنفيذ Lightning بشكل كامل من تلقاء أنفسهم، إلا أنه يتعين على المطور الذي يسلك هذا الطريق الآن التعامل مع دمج دعم واجهة برمجة التطبيقات لأي محفظة Lightning من المحتمل أن يستخدمها مستخدم تطبيقه. وهذا يتطلب مواكبة أي تغييرات أو تعديلات على محافظ Lightning المتعددة وواجهة برمجة التطبيقات الخاصة بها وكيفية عمل الميزات الداخلية لتلك المحفظة والميزات التي تدعمها. إن عدم مواكبة أي تغييرات في محفظة معينة قد يؤدي إلى تعطيل تطبيقهم لمستخدمي تلك المحفظة.
يجب أن توجد آلية موحدة للبرامج على جانبي هذه الفجوة حتى تتمكن ببساطة من تنفيذ هذا الشيء الوحيد لجميع هذه الأدوات المختلفة للتحدث مع بعضها البعض. وهذا من شأنه أن يسمح لكل مطور تطبيق، وكل مطور لمحفظة Lightning، بدمج وصيانة بروتوكول واحد من شأنه أن يمكّن تطبيقاتهم من التواصل مع بعضها البعض.
Nostr Wallet Connect هو بروتوكول يحاول أن يكون آلية معممة حقًا لتلبية هذه الحاجة. عند السعي إلى تضمين مدفوعات Lightning في Nostr، ظهرت كل هذه المشكلات المعقدة الناجمة عن كيفية القيام بذلك.
البرق وNWC
قام الفريق الذي يقف وراء Amethyst، وهو عميل Nostr، وAlby، محفظة Lightning المستندة إلى الويب، بإنشاء NWC من أجل حل مشكلة مستخدمي Nostr الذين يرغبون في دمج Lightning في تجربة Nostr الخاصة بهم دون الحاجة إلى استخدام محفظة ذات غرض خاص. يعتمد التطبيق/البروتوكول على بنية هوية Nostr حيث يتم توقيع كل رسالة (حدث) يتم إرسالها عبر Nostr بواسطة زوج مفاتيح مشفر يعمل بمثابة هويتك على Nostr. يسمح هذا للتطبيق بإنشاء زوج مفاتيح Nostr ببساطة، ومن خلال ذلك وحده يكون لديه آلية مصادقة تشفير لاستخدامها في التواصل مع محفظة Bitcoin خارجية لتحقيق وظائف التطبيق.
باستخدام زوج المفاتيح لتسجيل التطبيق الخارجي بمحفظة Lightning، يمكن للتطبيق الآن تنفيذ الأمر ping على محفظتك لبدء الدفع. تدعم المواصفات حاليًا دفع فواتير BOLT 11، وإجراء دفعات المفاتيح (مدفوعات بدون فواتير يتم إجراؤها على المفتاح العام للعقدة)، ودفع فواتير متعددة في وقت واحد، وإنشاء فاتورة لتقديمها إلى شخص آخر ليدفع لك، وبعض الوظائف الأخرى للسماح بسجل الدفع و الاستعلام عن رصيد المحفظة من التطبيق الخارجي.
يتم تنسيق كل هذا عبر Nostr، مما يسمح بوسائل اتصال زائدة عن الحاجة لا تعتمد على آلية مراسلة مركزية واحدة أو يحتاج المستخدم إلى الاعتماد على برامج معقدة مثل Tor أو بروتوكولات أخرى لتسهيل اتصال الشبكة بين التطبيق وبرنامج المحفظة. أو البنية التحتية التي تعمل على شبكتهم المنزلية. تدعم Nostr أيضًا الرسائل المباشرة المشفرة، مما يعني أن الاتصال بين المحفظة والتطبيق خاص تمامًا، ولا يكشف عن أي تفاصيل حول المدفوعات التي يتم تنسيقها مع مرحلات Nostr المستخدمة للتواصل.
على جانب المحفظة من جسر NWC، يمكن تنفيذ قيود أمنية لمنع التطبيق الخارجي من الوصول غير المقيد إلى أموال المحفظة في حالة تعرض مفتاح Nostr المستخدم للتواصل مع المحفظة للخطر. يمكن تكوين القيود المفروضة على المبالغ المسموح بإنفاقها، بالإضافة إلى تكرار الدفعات، على جانب المحفظة من الاتصال.
تعد NWC مفيدة لأكثر من مجرد دمج Lightning في تطبيقات Nostr أيضًا. تمحورت فلسفة تصميم Nostr بأكملها كبروتوكول حول إبقائه بسيطًا بدرجة كافية بحيث يمكن تنفيذ البروتوكول بأكمله بسهولة بشكل صحيح بواسطة أي مطور بأقل قدر من الوقت والموارد. يمكن للتطبيقات التي لا علاقة لها بـ Nostr أن تدمج بسهولة NWC أو بروتوكولات مماثلة دون أي عبء أو تعقيد تقريبًا لمعالجة المشكلات الأساسية المتعلقة بكيفية توصيل محفظة Bitcoin بتطبيقاتها دون الحاجة إلى إنشائها مباشرة في التطبيق.
ما وراء البرق
إن إمكانية بروتوكول مثل NWC لتوفير قيمة هائلة لمطوري المحفظة والتطبيقات تتجاوز بكثير دمج محافظ Lightning في تطبيقات ذات أغراض خاصة. إن الاتجاه الكامل طويل المدى للتفاعل مع Bitcoin، باستثناء بعض الإنجازات الأساسية المذهلة التي لم يدركها أحد بعد، هو نحو البروتوكولات التفاعلية بين عدة مستخدمين.
تعد تجمعات العملات المعدنية متعددة الأطراف مثالًا مثاليًا. معظم مقترحات التصميم المحددة مثل أشجار Ark أو Timeout مبنية حول طرف تنسيق مركزي أو مزود خدمة، والذي يمكنه بسهولة تسهيل وسيلة تمرير الرسائل بين محافظ المستخدمين، ولكن هذا يعرقل مساحة التصميم بنقطة فشل واحدة. إذا تم تجميع مائة مستخدم في مجموعة عملات معدنية معًا فوق UTXO واحد، فإن نموذج الأمان يعتمد على أن يكون لكل مستخدم مسار موقّع مسبقًا لسحب عملاته المعدنية من جانب واحد على السلسلة. ويمكن ممارسة هذه الآلية في حالة حدوث أي فشل أو اختفاء للمنسق لضمان عدم ضياع أمواله، ولكن هذه هي الطريقة الأقل كفاءة للتعامل مع مثل هذا السيناريو الأسوأ.
إذا تمكن المستخدمون من إيجاد آلية للتواصل مع بعضهم البعض في غياب مزود الخدمة أو المنسق، فيمكن تحقيق عمليات خروج أكثر كفاءة على السلسلة باستخدام المجموعة الأكبر multisig لترحيل أموالهم إلى مكان آخر بطريقة أكثر كفاءة ( وبالتالي أرخص) بصمة على السلسلة. تعتبر NWC وNostr مناسبتين تمامًا لمثل هذا السيناريو.
يمكن أيضًا للمحافظ التعاونية متعددة التوقيع بين أطراف متعددة أن تستفيد من هذا البروتوكول. بالاشتراك مع معايير مثل PSBT، يمكن لآلية اتصال Nostr البسيطة أن تبسط بشكل كبير تعقيد المحافظ المختلفة مع دعم multisig لتنسيق توقيع المعاملات بطريقة سلسة وسهلة الاستخدام.
تعد عقود السجل السرية (DLC) استخدامًا رائعًا آخر لمثل هذا البروتوكول. يعتمد مخطط المحتوى القابل للتنزيل (DLC) بأكمله على قدرة كلا الطرفين على الوصول إلى توقيعات أوراكل لإبرام العقد بشكل صحيح من جانب واحد إذا لم يتعاون الطرفان لتسويته بشكل تعاوني. Nostr هي الآلية المثالية لـ Oracles لبث هذه التوقيعات، وتسمح بالاشتراك البسيط في مفتاح Nostr الخاص بهم في محافظ المستخدمين لتتبع التوقيعات والحصول عليها تلقائيًا عند البث بواسطة Oracles.
مع مرور الوقت وإنشاء المزيد من التطبيقات والبروتوكولات فوق Bitcoin مع متطلبات التفاعل بين المستخدمين، وبين التطبيقات المختلفة، ستكون هناك حاجة ماسة إلى آلية اتصال للأغراض العامة لتسهيل ذلك دون الاعتماد على نقطة فشل واحدة. .
Nostr هو البروتوكول الأساسي المثالي لتسهيل ذلك نظرًا لبساطته المذهلة وتكرار مجموعة كبيرة من المرحلات للاستفادة منها. إن شركة المياه الوطنية هي المثال الأمثل على كون ذلك حلاً قابلاً للتطبيق.
Source link
#Nostr #Wallet #Connect #طبقة #تعاون #لتطبيق #Bitcoin
تعليقات
إرسال تعليق