تم نهب ما يقارب 4,000 بيتكوين بقيمة تقارب 320 مليون دولار من سلسلة جانبية Bitcoin Liquid. لكن لم يكن ذلك اختراقًا ببساطة لمفتاح خاص — بل إن الأشخاص الذين يمتلكون البيتكوين الآن يقولون إنهم يريدون إعادة معظمها.
في 6 سبتمبر، تعرضت شبكة Liquid إلى واحدة من أكبر حوادث أمان العملات الرقمية في عام 2026.
تم سحب ما يقارب 4,000 بيتكوين من محفظة احتياطي Bitcoin التابعة لاتحاد Liquid Federation، بقيمة تبلغ حوالي 320 مليون دولار في ذلك الوقت. ثم أوقفت Liquid لاحقًا نشاط الجسور، بينما علّقت البورصات أو جهّزت لتعليق إيداعات وسحوبات L-BTC.
ثم أخذت القصة منعطفًا غير متوقع.
يبدو أن المهاجمين عرّفوا أنفسهم على السلسلة باسم "whitehats" وأخبروا Blockstream أنهم سيعيدون معظم البيتكوين — لكن بعد إصلاح الثغرة الأساسية وبعد ترقيع عُقد الشبكة.
وقت كتابة هذا التقرير، بقيت حوالي 4,000 بيتكوين تحت سيطرة المهاجمين.
فماذا حدث فعليًا؟
لم تكن هذه عملية اختراق لبيتكوين
التمييز الأول المهم: لم يتم اختراق بيتكوين نفسها.
وقعت الحادثة على Liquid، وهي سلسلة جانبية للبيتكوين تعمل عبر اتحاد Liquid Federation.
تم بناء نموذج Liquid حول peg باتجاهين. يقوم المستخدمون بنقل BTC إلى احتياطي البيتكوين لدى الاتحاد الفيدرالي ويتلقون مقدارًا مكافئًا من Liquid Bitcoin، أو LBTC، على السلسلة الجانبية.
في التشغيل الطبيعي:
BTC → اتحاد Liquid → LBTC
وعندما يريد المستخدمون مغادرة Liquid:
LBTC → تم حرقها → إطلاق BTC
تصف وثائق Liquid نفسها LBTC على أنها مدعومة بنسبة 1:1 بواسطة بيتكوين محفوظة في محفظة متعددة التوقيعات التابعة للاتحاد الفيدرالي.
تم تصميم نموذج الأمان عمدًا بحيث لا يعتمد الاتحاد الفيدرالي على مفتاح خاص واحد.
يستخدم الاتحاد الفيدرالي بنية متعددة التوقيعات 11-من-15، مع وجود مفاتيح لدى جهات وظيفية منفصلة. كما تستخدم عمليات peg-outs مفتاح تفويض peg-out، أو PAK، لتقييد مكان إمكانية إرسال بيتكوين.
ومع ذلك، بقيت تقريبًا 4,000 بيتكوين في الاحتياطي.
وهذا ما يجعل هذه الحادثة مثيرة للاهتمام للغاية.
يبدو أن المفاتيح لم تُسرق
وفقًا لـ Liquid وتقارير SideSwap، لم تتضمن الحادثة سرقة بيانات اعتماد التوقيع الخاصة بالاتحاد الفيدرالي.
بدلًا من ذلك، مرّت المعاملة عبر آلية peg-out العادية.
يبدو أن المشكلة كانت في مكان أعمق داخل طبقات البرامج.
قال SideSwap إن الـ L-BTC المتضمنة في المعاملة تم إنشاؤها عبر خلل في Elements، وهو برنامج سلسلة بلوكتشين مفتوح المصدر الذي يدعم Liquid.
وبعبارة أخرى، يبدو أن المهاجم قد استغل ثغرة سمحت بوجود حوالي 4,000 LBTC حتى مع أن البيتكوين المقابل لم يتم إيداعه قط في الاتحاد الفيدرالي.
ثم عُرضت تلك الرموز للاسترداد.
تمكنت بنية الاتحاد الفيدرالي فعليًا من معالجة الطلب باعتباره peg-out صالحًا وإطلاق بيتكوين حقيقية.
وكانت النتيجة تحويلًا استثنائيًا:
LBTC مزوّرة/غير شرعية → peg-out شرعي → BTC حقيقية
انتهى الأمر بالمهاجمين إلى امتلاك حوالي 3,996 BTC في عنوان بيتكوين بعد المعاملة.
مشكلة 320 مليون دولار
هذا يكشف عن مخاطرة جوهرية في أي نظام أصول مُجسَّرة أو مُلتفَّة.
لا يتحدد أمان الجسر فقط بمدى حماية بيتكوين الأساسية.
كما يعتمد ذلك أيضًا على ما إذا كان النظام يمكنه الإجابة بشكل صحيح عن سؤال أبسط بكثير:
"هل يوجد هذا الرمز فعلاً بشكل شرعي؟"
يعتمد peg بالكامل في Liquid على علاقة 1:1 بين LBTC المتداول على السلسلة الجانبية وBTC المحتفظ به لدى الاتحاد الفيدرالي.
إذا سمح البرمجيات للمهاجم بتصنيع LBTC خارج نموذج المحاسبة هذا، فقد يتمكن المهاجم من استرداد تلك الرموز الاصطناعية مقابل بيتكوين حقيقية.
يمكن أن تظل الخزنة آمنة.
يمكن أن تظل المفاتيح الخاصة آمنة.
يمكن أن تظل متعدد التوقيعات سليمًا.
وما زال يمكن للنظام أن يخسر مئات الملايين من الدولارات.
هذه هي الدروس الأساسية من هذه الحادثة.
لماذا لم يمنع متعدد التوقيعات 11-من-15 ذلك؟
للوهلة الأولى، يبدو أن هذا هو النوع بالضبط من الهجوم الذي ينبغي أن يمنعه متعدد التوقيعات 11-من-15.
لكن متعدد التوقيعات يحمي من الصرف غير المصرّح به.
لا يحمي تلقائيًا من معاملة يعتبرها النظام نفسه صالحة.
تتطلب عملية peg-out الموثقة لدى Liquid من الجهات الوظيفية في الاتحاد الفيدرالي التحقق من طلب peg-out ثم توقيع معاملة بيتكوين المقابلة.
إذا كانت البرامج الأساسية تحدد بشكل غير صحيح أن استرداد LBTC مشروع، فقد ينتهي الأمر بمشاركي متعدد التوقيعات إلى القيام بما صُمموا للقيام به بالضبط:
وقّع معاملةً صالحة.
هذا التمييز حاسم.
لم يكن هذا بالضرورة:
"سرق المهاجم 11 مفتاحًا خاصًا."
كان أقرب إلى:
"وجد المهاجم طريقة تجعل النظام يعتقد أن عملية السحب كانت شرعية."
وهذا بشكل أساسي نوع مختلف تمامًا من الثغرات.
ثم فعل المهاجمون شيئًا غريبًا
بعد نقل البيتكوين، لم يختفِ المهاجمون فورًا.
بدلًا من ذلك، تركوا رسالةً على السلسلة تُعرّف عن أنفسهم باسم "whitehats" وتطلب من Blockstream التواصل معهم.
ردّت Blockstream لاحقًا عبر معاملات بيتكوين واتصالات مُشفّرة.
ثم يُفترض أن المهاجمين عرضوا إعادة معظم البيتكوين — مع شرط رئيسي واحد:
أصلح العطل أولاً.
كانوا يريدون تأكيدًا بأن الثغرة تم ترقيعها عبر العُقد ذات الصلة قبل إعادة الأموال.
أرسل Blockstream لاحقًا رسالةً على السلسلة موقَّعةً تفيد بأن عُقد الجسر تم إصلاحها وأنه يمكن إرجاع الأموال.
لكن البيتكوين لم يكن قد تحرك بعد وقت وقت الإبلاغ.
لذا فإن أكبر قصة سرقة للعملات المشفرة في ذلك اليوم، بشكل غير معتاد، تحولت إلى مفاوضات بين مطوري البروتوكول والأشخاص الذين استغلّوه.
أوقفت Liquid الجسر
بعد الحادثة، عطلت Liquid عُقد الجسر وتحركت البورصات لتعليق إيداعات وسحوبات L-BTC.
هذا منطقي: إذا لم تُصلح الثغرة في المحاسبة الأساسية، فإن مجرد إرجاع BTC المسروقة لا يحل المشكلة.
يحتاج الشبكة إلى إثبات أن الاستغلال نفسه لا يمكن تكراره.
يمكن لـ Liquid أن تستمر كبلوكشين، لكن الجسر بين Liquid والبيتكوين هو النقطة الحاسمة التي تتم حمايتها.
يهم هذا التمييز لأن Liquid ليست بيتكوين.
تصف وثائق Blockstream نفسها Liquid بأنها سلسلة جانبية للبيتكوين تعمل بشكل مستقل عن طبقة بيتكوين الأساسية. لا تعتمد بيتكوين على Liquid لكي تعمل.
لذلك لا توجد أي إشارة إلى أن آلية إجماع البيتكوين أو إثبات العمل الأساسي للبيتكوين تم اختراقه.
حدث الفشل في طبقة السلسلة الجانبية وطبقة peg.
الدرس الأكبر في عالم التشفير
هذه الحادثة أكبر من Liquid.
إنه تذكير آخر بأن البنية التحتية للعملات المشفرة لها طبقات متعددة من الأمان — وأن حماية طبقة واحدة لا تعني تلقائيًا حماية الطبقات الأخرى.
يمكنك أن يكون لديك:
مفاتيح خاصة مؤمَّنة عبر العتاد
محافظ متعددة التوقيعات
مدققون موزعون جغرافيًا
عناوين سحب مُدرجة في القائمة البيضاء
آليات التأمين المؤقت (Timelocks) واستعادة الطوارئ
…ومع ذلك قد يحدث فشل كارثي إذا احتوت البرامج التي تتحقق من الأصول على خلل في الإجماع.
تتضمن معمارية Liquid بالفعل عدة ضمانات إضافية. تصف وثائقها آلية لاستعادة الطوارئ وقوائم تأمين مؤقت (timelocks) مصممة لحماية أموال الاتحاد الفيدرالي أثناء فشل طويل الأمد في الشبكة.
لكن تُصمَّم هذه الحمايات أساسًا للتعامل مع سيناريوهات فشل مختلفة.
العبرة ليست أن متعدد التوقيعات لا يعمل.
العبرة هي أن متعدد التوقيعات لا يمكنه تعويض منطق التحقق المعطوب.
قد تكون أكثر الأجزاء إثارة للاهتمام هي ما يحدث بعد ذلك
ما تزال بيتكوين هي القطعة المحورية في لغز هذه القصة.
إذا كان المهاجمون يعيدون بالفعل معظم ~4,000 بيتكوين بعد الترقيع، فقد تصبح الحادثة مثالًا غير معتاد لتدخل ضخم من نوع "white-hat": تم استغلال ثغرة مقابل أموال حقيقية، وتم تأمين الأموال مؤقتًا بواسطة الباحثين، ثم أجبر البروتوكول على إصلاح الضعف الأساسي.
لكن إلى أن تتحرك بيتكوين فعليًا إلى الخلف، تظل مطالبة — لا تعافيًا مكتملًا.
ولا تزال هناك أسئلة كبرى يجب الإجابة عنها:
أي خلل في Elements تحديدًا مكّن إنشاء LBTC غير المصرّح به؟
كيف اكتشفه المهاجم؟
لماذا قبلت عملية التحقق لدى الاتحاد الفيدرالي عملية peg-out الناتجة؟
هل يمكن أن تكون الثغرة قد استُغلّت في وقت أبكر؟
كم عدد العُقد والأنظمة التي تأثرت؟
ولعل الأهم:
ما مقدار الثقة التي ينبغي أن يضعها المستخدمون في أصل مُجسّر تعتمد أمانه في النهاية على برمجيات تتحقق من علاقة دعم 1:1؟
لذلك ليست حادثة Liquid مجرد قصة عن سرقة 320 مليون دولار.
وهي دراسة حالة تُبرز الفرق بين حماية المفاتيح وحماية القواعد التي يتم برمجة تلك المفاتيح على تطبيقها.
وفي عالم التشفير، أحيانًا تكون المشكلة الثانية هي الأكبر.
#bitcoin #liquidnetwork #CryptoSecurity #BTC
