By Bitcoin المجلة - منذ شهرين - مدة القراءة: 6 دقائق
بعد الوفاة على هجوم ركوب الدراجات البديل البرق
لذلك تم إحداث الكثير من الضجيج حولها ضعف البرق كشف عنها مؤخرا أنطوان ريارد. يزعم الكثير من الناس أن السماء تسقط، وأن البرق مكسور بشكل أساسي، ولا شيء أبعد عن الحقيقة. أعتقد أن جزءًا من المشكلة هو أن الأشخاص لا يفهمون حقًا كيفية عمل هذه الثغرة الأمنية، أولاً، وثانيًا، لا يفهم العديد من الأشخاص كيف تتداخل مشكلة عدم الحصانة الفردية هذه مع مشكلات أخرى معروفة على الشبكة المسرّعة والتي لها حلول معروفة.
لذا، دعونا أولاً نستعرض ونحاول فهم الثغرة الأمنية نفسها. عندما يتم توجيه دفعة Lightning عبر الشبكة، فإن الشيء الوحيد الذي يجب فهمه هو كيفية عمل الأقفال الزمنية لاسترداد دفعة فاشلة. تحتوي القفزة الأقرب إلى جهاز الاستقبال على قفل زمني قدره "x"، وكل قفزة تعود إلى المرسل لها قفل زمني من "x+1"، و"x+2"، وما إلى ذلك. تصبح الأقفال الزمنية أطول بشكل تدريجي مع كل قفزة من جهاز الاستقبال إلى المرسل. والسبب في ذلك هو أنه إذا وصلت دفعة إلى المتلقي، ولكن هناك مشكلة تمنع الصورة المسبقة من الانتشار على طول الطريق مرة أخرى إلى المرسل، فإن القفزة حيث توقفت لديها الوقت لفرضها على السلسلة، ووضع الصورة المسبقة هناك بحيث يكون كل شيء القفزات السابقة تحتاج إلى تأكيد الدفع. آخرwise يمكن لشخص ما في المنتصف، حيث يحدث الفشل، أن يجعل قفزته الصادرة تطالب بالأموال باستخدام الصورة المسبقة، والقفزة التي أرسلتها إليهم تطالب بها من خلال مسار استرداد الأموال الخاص بهم، وتترك هذا الشخص في المنتصف بعيدًا عن الحظ بعد أن خسر أموال.
يعد هجوم ركوب الدراجات البديل طريقة معقدة لمحاولة تحقيق تلك النتيجة غير المرغوب فيها بالضبط، حيث تخسر العقدة المستهدفة الأموال من خلال جعل القفزة الصادرة تطالب بالأموال من خلال معاملة ناجحة، والقفزة الواردة تطالب بالأموال من خلال معاملة استرداد الأموال. وهذا يستلزم تعطيل عقدة الضحية، ومنعهم من رؤية الصورة الأولية في معاملة النجاح على جانب واحد حتى بعد انتهاء صلاحية القفل الزمني على الجانب الآخر، حتى يتمكنوا من المطالبة باسترداد الأموال هناك.
يتطلب هذا لعبة مستهدفة ومعقدة للغاية للتعامل مع ذاكرة الضحية. دعونا نلقي نظرة على هيكل المعاملة الفعلية المعنية هنا. لديك معاملة الالتزام، وهي المعاملة الرئيسية التي تمثل حالة قناة Lightning. يحتوي على مخرج لكل جانب من القناة يمثل الأموال الخاضعة بالكامل لسيطرة عضو أو آخر، ومخرجات لكل HTLC في عملية التوجيه. هذه المخرجات هي التي نهتم بها. يمكن إنفاق كل مخرجات HTLC إما على الفور في أي وقت باستخدام الصورة الأولية من جهاز الاستقبال، أو بعد انتهاء صلاحية القفل الزمني عند استرداد الأموال.
يتطلب الهجوم أن يكون لدى طرف ضار، أو طرفين متآمرين، قناة على جانبي عقدة الضحايا لتوجيه الدفع. لذا فإن بوب، الضحية، لديه قناة مع أليس وكارول، المهاجمين، ويتم توجيه الدفع من كارول إلى بوب إلى أليس. تذكر الآن أن مسار استرداد الأموال بين أليس وبوب سوف ينتهي ويصبح صالحًا قبل استرداد الأموال بين كارول وبوب.
يقوم المهاجمون بتوجيه الدفعة عبر بوب، وبعد ذلك سترفض أليس إرسال الصورة المسبقة إلى بوب لإنهاء الدفعة عندما تستلمها. ما سيفعله بوب الآن هو الانتظار حتى تنتهي نافذة القفل الزمني بينه وبين أليس، ويذهب لبث معاملة التزام القناة ومعاملة استرداد الأموال لتأكيدها قبل انتهاء نافذة القفل الزمني. ما ستفعله أليس بعد ذلك هو إنفاق معاملة الصورة المسبقة للمطالبة بالأموال ذات المخرجات غير المرتبطة بالقناة، وبعد ذلك مباشرة، قم بإنفاق المدخل الثاني في معاملة نجاح الصورة المسبقة. الهدف هنا هو طرد معاملة المهلة الخاصة بـ Bob من مجمع الذاكرة، ولكن أيضًا طرد معاملة نجاح الصورة المسبقة حتى لا يراها Bob. إذا فعل ذلك، فسوف يتعلم الصورة المسبقة ويمكنه ببساطة المطالبة بالأموال الموجودة في قناته مع كارول قبل أن تصبح معاملة المهلة الخاصة بها صالحة للإنفاق.
يتعين على أليس وكارول القيام بذلك على أساس ثابت، في كل مرة يعيد بوب بث معاملة المهلة الخاصة به مع أليس، حتى يمر ارتفاع الكتلة حيث تكون معاملة المهلة الخاصة بكارول صالحة. بعد ذلك، يمكنهم إرسال المعاملة الناجحة من جانب أليس، ومعاملة المهلة من جانب كارول، وترك بوب يحمل الحقيبة بعد أن فقد قيمة الدفعة التي كان يقوم بتوجيهها.
المشكلة في هذا ذات شقين. أولاً الضحية Bitcoin يجب أن يتم استهداف العقدة الأساسية على وجه التحديد لضمان عدم انتشار معاملة نجاح الصورة المسبقة في أي وقت من الأوقات إلى مجمع الذاكرة الخاص بهم حيث يمكن لعقدة Lightning الخاصة بهم الحصول على الصورة الأولية. ثانيًا، إذا تم تأكيد المعاملة الثانية التي تستخدمها Alice لطرد معاملة الصورة المسبقة، فستتحمل Alice تكلفة (تذكر أن الفكرة هي استبدال معاملة المهلة بالصورة المسبقة، بحيث يتم إخلاؤها من مجمع الذاكرة، ثم استبدال معاملة الصورة السابقة بمعاملة الصورة المسبقة والثاني ينفق بشكل مزدوج المدخلات الإضافية في معاملة الصورة المسبقة). وهذا يعني أنه في كل مرة يعيد بوب بث معاملة المهلة الخاصة به، يتعين على أليس دفع رسوم أعلى لإعادة طردها، وعندما يتم تأكيد ذلك، فإنها تتحمل تكلفة بالفعل.
لذلك يمكن لبوب إجبار أليس على تحمل تكلفة كبيرة ببساطة عن طريق إعادة بث معاملة المهلة الخاصة به بانتظام برسوم أعلى، مما يعني أنه إذا كانت قيمة مخرجات HTLC المدفوعة لا تساوي أكثر بكثير من الرسوم التي يمكن أن تتكبدها أليس، فإن الهجوم لن يكون مجديًا اقتصاديًا للتنفيذ . سيكون من الممكن أيضًا منع الهجوم تمامًا عن طريق تغيير كيفية إنشاء معاملات نجاح HTLC والمهلة. باستخدام علامة SIGHASH_ALL، مما يعني أن التوقيع يلتزم بالمعاملة بأكملها ويصبح غير صالح إذا تم تغيير أصغر التفاصيل (مثل إضافة المدخلات الجديدة في معاملة الصورة المسبقة المطلوبة لهذا الهجوم). لن يعمل هذا مع الإصدار الحالي من قنوات Lightning التي تستخدم نواتج المرساة، ولكن من شأنه أن يحل المشكلة تماما. اقترح بيتر تود أيضًا أ ميزة الإجماع الجديدة وهذا من شأنه أن يحل المشكلة تمامًا، وهو في الأساس قفل زمني عكسي، حيث تصبح المعاملة غير صالحة بعد وقت معين أو ارتفاع الكتلة بدلاً من أن تصبح صالحة بعد ذلك. ولكن الذهاب إلى هذا الحد ليس ضروريا في رأيي.
إن مجرد إعادة بث معاملتك بانتظام مع زيادة طفيفة في الرسوم يعد بمثابة تخفيف كبير للهجوم، ولكن هناك أيضًا العديد من الديناميكيات التي تجعلها ليست مشكلة خطيرة بغض النظر. أولاً، إذا لم تكن عقدة توجيه، فهذه ليست مشكلة خطيرة حقًا. لذا فإن معظم المستخدمين النهائيين في مأمن من هذا الهجوم. ثانيًا، هناك العديد من الأسباب التي تجعل العقد لا تسمح لأي شخص عشوائي بفتح القنوات لها. العقد الكبيرة انتقائية للغاية بشأن الأشخاص الذين تتعامل معهم، حيث أن القنوات العشوائية التي لا تتم إدارتها بكفاءة أو احترافية لها تكلفة في شكل رأس مال غارق أو مهدر في القنوات غير المستخدمة. لذا فإن أي عقدة كبيرة من شأنها أن تشكل هدفًا مثيرًا لهذا الهجوم ليس من السهل حتى الاتصال بها في المقام الأول، ناهيك عن الاتصال بها بقنوات متعددة لتنفيذ الهجوم في المقام الأول. وأخيرا، كما لقد كتبت عنه في الماضي، فإن الهجمات الأخرى غير ذات الصلة المحتملة على الشبكة تتطلب بالفعل عوامل تصفية وقيودًا في كيفية اختيار العقد للتعامل مع HTLCs التي يمكنها إعادة توجيهها. على سبيل المثال، القيود المفروضة على حجم المدفوعات التي سيتم تحويلها، وعدد المدفوعات التي سيسمحون بها في أي وقت معين، وما إلى ذلك. لذا، حتى لو كان بإمكانك فتح قناة بعقدة تستحق الهجوم، مع تطور الشبكة، سيكون هناك المزيد من التفكير من خلال المعايير والمرشحات لتحديد ما إذا كان سيتم إرسال دفعة في المقام الأول.
بشكل عام، هذه مشكلة مشروعة وهجوم محتمل، ولكن من حيث التخفيف المباشر وكيفية تفاعل الهجوم مع حلول القضايا الأخرى على المدى الطويل، فهذه ليست مشكلة غير قابلة للحل. إنها مسألة مشروعة، ورفضها باعتبارها FUD محضًا ليس رد فعل دقيقًا، ولكن الادعاء بأن السماء تسقط وأن الشبكة المسرّعة كبروتوكول محكوم عليها بالفشل هو أمر مبالغ فيه للغاية.
سوف يمر الوقت، وسوف نواجه مشاكل، وسوف نقوم بإصلاح تلك المشاكل عندما تأتي. كما فعلنا دائما.
المصدر الأصلي: Bitcoin مدونة