اقتراح لوقف هجمات البرق على البيتكوين – مجلة البيتكوين
هذه مقالة افتتاحية بقلم Shinobi ، المعلم الذي علم نفسه بنفسه في مجال Bitcoin ومضيف بودكاست Bitcoin ذي التوجه التكنولوجي.
يعد تشويش القنوات أحد أكثر المشاكل المعلقة التي تهدد شبكة Lightning Network. إنه يقدم آلية مفتوحة لعقد هجوم رفض الخدمة على الشبكة لمنعها من التوجيه ، وخسارة الأموال أثناء قفل السيولة وعدم القدرة على إعادة توجيه المدفوعات التي ستكسبها رسومًا. يمكن للمهاجم أن يوجه دفعة عبر عقد أخرى من نفسه إلى نفسه ، ويرفض إنهاء الدفع. هذا يجعل هذه السيولة عديمة الجدوى لإعادة توجيه المدفوعات الأخرى حتى ينتهي عقد timelock المجزأ (HTLC) واسترداد المدفوعات.
في الشهر الماضي ، اقترح مطور Lightning Antoine Riard مواصفات رسمية لحل هذه المشكلة. في أغسطس ، نشر Riard و Gleb Naumenko بحثًا يبحث في المشكلة العامة نفسها ، بالإضافة إلى عدد من الحلول المختلفة التي يمكن استخدامها لتخفيفها أو حلها. كان أحد تلك الحلول المقترحة شكلاً من أشكال بيانات الاعتماد المجهولة الهوية التي يمكن للعقد استخدامها لبناء نوع من نظام تسجيل السمعة للمستخدمين الذين يوجهون المدفوعات من خلالها دون الحاجة إلى القيام بذلك أو ربط هذه السمعة بمعرف ثابت من شأنه أن يؤثر سلبًا على خصوصية الأشخاص. أصبح هذا الحل الآن هو اقتراح البروتوكول الرسمي الذي قدمه Riard الشهر الماضي.
داخل اقتراح التخفيف من تشويش القناة
جوهر الفكرة هو رمز ecash Chaumian. هذه هي رموز مركزية صادرة عن سلطة إصدار بطريقة تمنع إصدار رمز من الارتباط باسترداد الرمز المميز لاحقًا. يتم ذلك عن طريق توقيع رمز بطريقة عمياء ، مما يسمح لمتلقي الرمز بفك التعمية دون إبطال التوقيع. يمكن للمُصدر بعد ذلك التحقق من أنه رمز مميز دون أن يكون قادرًا على توصيل هذا الرمز المميز عند إصداره.
يقترح الاقتراح استخدام هذه الرموز المميزة Chaumian ، الصادرة عن كل عقدة توجيه على الشبكة ، كشكل من أشكال إثبات السمعة. عند توجيه دفعة ، سيتم تغليف رمز ecash الخاص بـ Chaumian الصادر عن كل عقدة في قفزة الدفع في حزمة البصل لتلك العقدة على طول الدفع. ستمثل الوحدات الرمزية كلاً من قيمة HTLC المسموح بها بالإضافة إلى فترة القفل الزمني للاسترداد. قبل إعادة توجيه HTLC ، ستتحقق كل عقدة من أن الرمز المميز المتضمن في فقاعة البصل الخاص بها صالح ولم يتم استرداده من قبل ، فقط إعادة توجيه HTLC إذا كان كلا الشرطين صحيحين.
إذا استقر HTLC بنجاح مع الكشف عن الصورة الأولية ، فستشير كل عقدة على طول مسار الدفع وتتضمن رمزًا مميزًا Chaumian تم إصداره حديثًا ليتم إرجاعه إلى المرسل ، جنبًا إلى جنب مع HTLC preimage. إذا لم يتم تسوية HTLC بنجاح ، فإن عقد التوجيه “تحرق” الرمز المميز من خلال تضمينه في جدول الرموز المستهلكة ولا تصدر رمزًا مميزًا جديدًا. هذا يفرض على المرسل الحصول على رموز جديدة من تلك العقد لتوجيه المدفوعات من خلالها مرة أخرى. المفهوم بأكمله هو أن هجمات التشويش تفشل دائمًا في التسوية ، لذلك في هذا المخطط ، يتم حرق هذه الرموز المميزة الصادرة عن كل عقدة تقوم بالتوجيه من خلالها إذا قمت بتنفيذ هجوم تشويش وخلق تكلفة اكتساب المزيد للقيام بذلك مرة أخرى. في الوقت الحالي ، لا تكلف هجمات التشويش شيئًا سوى الوقت ، لذا فإن هذا من شأنه أن يضيف تكلفة اقتصادية عليها.
لذا ، حان الوقت لمناقشة موضوع الفيل في الغرفة: كيف يمكنك تشغيل إصدار هذه الرموز وتداولها عبر الشبكة؟ تتطلب كل عقدة تريد التوجيه من خلالها رمزًا صادرًا عنهم. الحل: دفع ثمنها. هناك حل آخر مقترح لمشكلة تشويش القنوات وهو الرسوم المسبقة ، أي فرض رسوم حتى لمحاولة توجيه دفعة بغض النظر عما إذا كانت تنجح أم لا. لذلك ، حتى المدفوعات الفاشلة ستتحمل رسومًا على المرسل.
اقتراح Riard هو شراء هذه الرموز مباشرة من كل عقدة كمشتريات لمرة واحدة. من هذه النقطة فصاعدًا ، بدلاً من دفع الرسوم مقدمًا لكل دفعة ، طالما تم تسوية الدفعة السابقة بنجاح ، ستتم إعادة إصدار “الرموز المميزة للتوجيه” التي من شأنها تمكين توجيه دفعتك المقترحة التالية بدون رسوم. وبهذه الطريقة ، لا تدفع المدفوعات الناجحة سوى رسوم التوجيه الفعلية ، ولا تدفع المدفوعات الفاشلة سوى الرسوم المقدمة ، مما يمنع نوعًا من “الرسوم المزدوجة” للدفعات الناجحة. من الناحية الاقتصادية على الأقل ، فكر في الأمر على أنه نوع من تسوية وسط بين الوضع الحالي حيث لا تكلف المدفوعات الفاشلة شيئًا ولا تدفع سوى المدفوعات الناجحة رسومًا ، ونموذج الرسوم الكاملة مقدمًا حيث تدفع جميع المدفوعات رسومًا مقدمًا و الناجحون يدفعون رسوم التوجيه أيضًا.
الوجبات الجاهزة من الاقتراح
أنا شخصياً أعتقد أن هذا النوع من الدفع المباشر للرموز في وقت مبكر يمكن أن يقدم درجة كبيرة من احتكاك UX في عملية استخدام شبكة Lightning Network. ومع ذلك ، أعتقد أن هناك حلًا بسيطًا جدًا لهذا الاحتكاك عن طريق تعديل الاقتراح قليلاً.
بدلاً من الاضطرار إلى دفع كل عقدة على وجه التحديد مقابل رموز Chaumian في وقت مبكر ، يمكن دمج الاقتراح بشكل مباشر أكثر مع اقتراح الرسوم المسبقة. إذا كان لديك رموز للعقدة ، فقم بتضمين تلك الموجودة في فقاعة البصل ، وإذا لم تكن مجرد دفع رسوم مقدمة مباشرة ضمن اقتراح HTLC وإذا تم تسوية الدفع بنجاح ، فسيتم إصدار رموز Chaumian مرة أخرى بما يتناسب مع ما لديك – الرسوم الأمامية كانت. بهذه الطريقة ، بدلاً من الاضطرار إلى جمع الرموز المميزة من العديد من العقد المختلفة مسبقًا ، يمكنك ببساطة الحصول عليها على مدار إجراء الدفعات الأولية حتى تحصل على مجموعة جيدة من العقد المختلفة التي تستخدمها بشكل متكرر ونادرًا ما تضطر إلى تحمل التكلفة من الرسوم المقدمة للحصول عليها.
مصدر آخر محتمل للاحتكاك هو لمشغلي العقد ، وينزل إلى القضايا الأساسية لـ Chaumian ecash نفسه. من أجل ضمان إنفاق الرمز المميز مرة واحدة فقط ، يحتاج المُصدر إلى الاحتفاظ بقاعدة بيانات لجميع الرموز المميزة التي تم إنفاقها. ينمو هذا إلى الأبد ، مما يجعل عمليات البحث للتحقق من صلاحية الرمز أكثر تكلفة وتستغرق وقتًا أكبر كلما كبرت قاعدة البيانات. لهذا السبب ، يقترح Riard أن تنتهي صلاحية هذه الرموز المميزة Chaumian بشكل دوري ، على ارتفاع الكتلة المعلن عنها في بروتوكول القيل والقال لكل عقدة. هذا يعني أن المرسلين بحاجة إلى إعادة شراء هذه الرموز بشكل دوري ، أو إذا كان التنفيذ يدعمها ، فاستبدلها برموز جديدة موقعة بواسطة مفتاح التوقيع الجديد بعد انتهاء صلاحية الرمز السابق.
سيؤدي هذا إما إلى فرض تكلفة اقتصادية منتظمة على مرسلي المدفوعات ، أو يتطلب منهم تسجيل الوصول بشكل دوري لضمان إعادة الإصدار عند انتهاء صلاحية الرموز القديمة. من الناحية العملية ، يمكن أتمتة هذا للأشخاص الذين يديرون عقد Lightning الخاصة بهم ، وبالنسبة لأي محافظ مبنية حول نموذج مزود خدمة Lightning (LSP) ، يمكن لـ LSP نفسه بالفعل التعامل مع اكتساب الرموز المميزة وصيانتها نيابة عن مستخدميه ، والتعامل مع توفير الرمز المميز لمدفوعات المستخدمين. ومع ذلك ، على الهامش ، بدون عقدة Lightning كاملة أو LSP ، قد يصبح هذا مصدر إزعاج لمستخدمي المحفظة الخفيفة.
أعتقد أن هذا الاقتراح يمكن أن يقطع شوطًا طويلاً في الواقع لتخفيف تشويش القناة كمتجه للهجوم ، خاصةً إذا تم تهجينه بشكل أكثر إحكامًا مع مخطط الرسوم الأساسية مقدمًا ، ويمكن التعامل مع معظم احتكاكات UX بسهولة شديدة لمستخدمي LSP و الأشخاص الذين يديرون عقد Lightning الخاصة بهم. وحتى إذا كانت الرسوم المقدمة تقدم درجة عالية من الاحتكاك ، فمن الممكن أن يتم استخدام إثبات التحكم في Bitcoin UTXO بدلاً من دفع الرسوم فعليًا للحصول على الرموز.
هذا منشور ضيف بواسطة Shinobi. الآراء المعبر عنها خاصة بها تمامًا ولا تعكس بالضرورة آراء BTC Inc أو Bitcoin Magazine.
