في 6 سبتمبر تحديدًا، غادر 3,996.01834922 $BTC احتياطي اتحاد Liquid.
بطبيعة الحال، جعلت العناوين الرئيسية الأولى الأمر يبدو كأنه نوع من اختراق بيتكوين.
لم يكن الأمر كذلك.
لم يتم اختراق Bitcoin L1.
وفقًا للبيان الرسمي لشركة SideSwap، قام المهاجم أولاً بإنشاء L-BTC على Liquid من خلال خلل في برنامج Elements، ثم مرّر ذلك الـ L-BTC عبر ما بدا وكأنه عملية عادية لإخراج الرهن.
اعتبر الاتحاد أن عملية إخراج الرهن صالحة وقام بدفع بيتكوين حقيقية على شبكة Bitcoin الرئيسية (mainnet).
https://x.com/liquid_btc/status/2096696272447218108
لذا لم يقم أحد باختراق بيتكوين مباشرةً.
البرمجيات الموجودة وراء sidechain المجمعة (federated) في بيتكوين سمحت بأن يظهر L-BTC غير صالح كـ L-BTC حقيقي.
وبسبب اعتقاد الاتحاد بأن تلك الأصول قد تم حرقها بشكل مشروع، أطلق BTC الحقيقي من احتياطيه.
هذا الفرق هو القصة برمتها تقريبًا.
لم تُخترق كتل بيتكوين والمعدّنون والتوافق (consensus) والتشفير ومحافظ L1 العادية.
ما تضرر كان Liquid.
كانت المشكلة الفعلية هي L-BTC وبنية الربط (peg) والقدرة على نقل الأصول عبر الشبكة.
ما نعرفه وما لا نزال لا نعرفه
ما نعرفه:
➛ غادر حوالي 4,000 BTC احتياطي Liquid Federation
➛ عبارة “تم اختراق Bitcoin mainnet” غير صحيحة
➛ يقول SideSwap إن مفتاح PAK والبنية التحتية لم تكن مسروقة
https://x.com/side_swap/status/2096709838310928674
➛ جاءت المشكلة من وجود خلل في Elements
➛ تم إيقاف عمليات Liquid
ما لا نزال لا نعرفه:
➛ ما إذا سيتم إرجاع كل الأموال
➛ إجمالي المبلغ الدقيق غير المدعوم من L-BTC الذي تم إنشاؤه
وأعتقد أن إبقاء هاتين المجموعتين منفصلتين هو أمر مهم هنا.
هناك بالفعل قدر كبير من التكهنات حول الخلل المحدد. لكن إلى أن نحصل على تقرير تقني كامل بعد الحادث (post-mortem) بشكل صحيح، ما يزال جزء من هذه التفاصيل مجرد نظريات.
أولاً، ما هي Liquid؟
لننجز الإعداد بطريقة بسيطة أولاً.
إن بيتكوين شديدة الأمان، لكن بيتكوين نفسها لم تُصمَّم للقيام بكل شيء مالي يرغب الناس في فعله باستخدام BTC.
Liquid هي شبكة منفصلة تعمل جنبًا إلى جنب مع بيتكوين.
Sidechain (سلسلة جانبية).
لكن على عكس Ethereum أو شبكات المدققين المفتوحة الأخرى، فإن Liquid تُدار بواسطة مجموعة من المشاركين المؤسسيين تُسمى Liquid Federation.
مسار المستخدم الأساسي يبدو كالتالي:
أنت ترسل BTC إلى Liquid. يتم قفل هذه BTC في احتياطي الشبكة الرئيسية (mainnet) الخاص بالاتحاد.
تستلم L-BTC على Liquid.
يمكنك استخدام L-BTC داخل Liquid للتحويلات الأسرع أو المعاملات السرّية أو منتجات أخرى.
عندما تريد BTC مرة أخرى، يتم حرق L-BTC ويتم إطلاق BTC من احتياطي الاتحاد على Bitcoin mainnet.
تحمي Liquid احتياطي BTC باستخدام multisig من نوع 11-of-15.
على الأقل يجب أن يوقّع 11 من أصل 15 مسؤولًا قبل أن تتمكن BTC من مغادرة الاحتياطي.
يبدو هذا قويًا جدًا.
ولأجل أمان المفاتيح فهو:
لكن هذا الحادث يوضح لماذا لا تكفي أمان المفاتيح وحده.
لا تحتاج لسرقة 11 مفتاحًا إذا كان يتم إظهار المعلومات نفسها الخاطئة للـ 11 مُوقِّعًا الأمناء.
إذا أخبرت البرمجيات الجميع “أن عملية السحب هذه صالحة”، فقد لا تزال التواقيع المخلصة توافق على دفعة سيئة.
هذا أكثر إثارة للاهتمام بالنسبة لي من مجرد القول “فشل multisig”.
فما الذي حدث فعليًا؟
1. تسبب خلل في Elements في جعل L-BTC غير صالح يبدو صالحًا
تعمل Liquid على برنامج مفتوح المصدر يُسمى Elements.
تضيف Elements أشياء مثل المعاملات السرّية والأصول السرّية وربط ثنائي الاتجاه (two-way peg) مُجمّع فوق بنية تحتية شبيهة ببيتكوين.
تصريح SideSwap واضح تمامًا بشأن هذه النقطة:
تم إنشاء L-BTC المستخدمة في عملية peg-out بسبب خلل في برمجيات Elements.
بعبارة أخرى، كان لدى المهاجم L-BTC كان ينبغي ألا يكون موجودًا.
لم تكن هذه مسألة سرقة كلمة مرور محفظة.
كانت مشكلة تحقق (validation).
قبلت الشبكة شيئًا على أنه صالح كان ينبغي ألا يكون صالحًا.
لم يتم نشر الآلية التقنية الدقيقة للخلل بعدُ في تقرير رسمي كامل بعد الحادث.
هناك ادعاءات حول أمور مثل تخزين مؤقت rangeproof ومكوّنات المعاملات السرّية، لكن لن أتعامل مع أيٍّ منها على أنه مؤكد حتى تنشر Blockstream أو Liquid التفصيل التقني.
2. أرسل المهاجم 4,000 L-BTC إلى خدمة peg-out التابعة لـ SideSwap
وفقًا لـ SideSwap:
6 سبتمبر، 14:05 بالتوقيت العالمي المنسق
أرسل أحد العملاء 4,000 L-BTC إلى خدمة peg-out الخاصة بـ SideSwap.
ومن منظور النظام بدا كطلب عادي.
تم حرق L-BTC.
بدت ترخيص عملية peg-out صالحة.
PAK، أو Peg-out Authorization Key (مفتاح ترخيص خروج الربط)، هو في الأساس تحكم آخر يحدد عناوين بيتكوين التي يمكنها استلام peg-outs.
وهذه نقطة مهمة أخرى أيضًا:
لم يتم سرقة مفتاح PAK.
قال كلٌّ من Liquid وSideSwap إن مفتاح PAK ومفاتيح التوقيع الأخرى لم تكن مُخترقة.
لذلك مرة أخرى، لم تكن المشكلة أن شخصًا ما سرق المفاتيح وأجبر النظام على إرسال BTC.
اعتقد النظام نفسه أن عملية السحب كانت شرعية.
3. ثم غادرت BTC الحقيقية احتياطي الاتحاد
عند 14:28 بالتوقيت العالمي المنسق، دفعت Liquid Federation بالضبط:
على شبكة Bitcoin mainnet.
يمكنك التحقق من معاملة بيتكوين هنا: https://mempool.space/tx/8db751a650ae2f12006b7e8c69a75e4df360e8afd6b9e05ae0b9fa6458a7b140
والجزء المتعلق بخروج الربط (peg-out) على Liquid هنا: https://blockstream.info/liquid/tx/ce4caece413cd9d444ce7ed9f54e5b328b3da5e4af301aff59a3571f76e988f2
لذلك عندما يقول الناس “4,000 BTC” فهم يقربون الرقم.
كان دفع بيتكوين القابل للتحقق يساوي 3,996.01834922 BTC، وكانت قيمته آنذاك حوالي 318–320 مليون دولار.
هذه هي BTC الحقيقية التي غادرت احتياطي الاتحاد (federation).
هذا الجزء ليس نظريًا.
4. توقفت Liquid
بعد الحادث قامت Liquid بتعطيل عقد الجسر (bridge nodes) وأوقفت المعاملات الجديدة.
بدأت البورصات أيضًا بتعليق إيداعات وسحوبات L-BTC.
إذًا هذه لم تكن مجرد مشكلة محاسبة احتياطي.
إذا كنت تستخدم Liquid فعلاً، فقد تأثرت كذلك قدرتك على التحويل أو التبديل أو عمل peg in أو peg out.
5. يدّعي المهاجم أنهم whitehats
وهناك أيضًا هذا الجزء.
ترك المهاجم رسالة على بيتكوين:
“نحن whitehats. تواصلوا معنا على chain.”
لكن قولك إنك whitehat لا يجعلك واحدًا.
على الأقل ليس بعد.
إلى أن تُعاد الأموال فعليًا، وبما أن الكشف عن الثغرة يتم بطريقة مسؤولة ويتم معالجة الضرر، أعتقد أن أدق وصفٍ هو ببساطة هذا:
يدّعي المهاجم أنه whitehat.
لم يتم تأكيد أن الأموال قد أُعيدت.
لذلك ما زال هذا الحادث الأمني الكبير جدًا غير محسوم حتى الآن.
لماذا لم يتم اختراق بيتكوين؟
لأن وجهة نظر بيتكوين لا ترى شيئًا غير صالح حدث.
كانت المعاملة قد حصلت على التواقيع المطلوبة.
رأى المُعدِّنون معاملة بيتكوين صالحة.
قبلت إجماع بيتكوين ذلك.
لم يكسر أحد Proof-of-Work.
لم يَكسر أحد تشفير بيتكوين.
لم يغيّر أحد حد إمداد 21 مليون.
لم يكن لبيتكوين طريقة لمعرفة أن المحاسبة داخل Liquid كانت خاطئة.
اعتبرها مثل بنك.
تخيّل أن لدى البنك خزانة تُشترط فيها عدة تواقيع مُصرّح بها لعمليات السحب.
النظام الداخلي للبنك يبلّغ هؤلاء المُوقِّعين خطأً أن العميل يملك فعلًا 100 مليون دولار.
يوافقون على التحويل.
لم تفشل الخزنة نفسها.
وصلت معلومات خاطئة إلى عملية التفويض (authorization).
هذا هو الفرق تقريبًا هنا.
إذًا:
“تم اختراق بيتكوين” غير صحيح.
عبارة “تعرضت شبكة الربط المجمعة لـ Liquid لفشل أمني كبير” أقرب بكثير إلى ما حدث فعليًا.
وهنا تصبح القصة أكثر إثارة للاهتمام
بالنسبة لي، الدرس الأكبر ليس محددًا بـ Liquid تحديدًا.
هذا ما يحدث في كل مرة نأخذ فيها BTC ونجعله أكثر قابلية للاستخدام في مكان آخر.
إن BTC الأصلية في محفظتك الخاصة تعتمد بشكل أساسي على افتراضات الأمان الخاصة ببيتكوين.
L-BTC يعتمد على أشياء أكثر.
إجماع بيتكوين + برمجيات Liquid
إثبات العمل + ثقة الاتحاد (federation)
مفاتيحك + آلية الربط (peg)
تحقق أصول Liquid
ولأن الاتحاد يدير احتياطي BTC بشكل صحيح.
هذا لا يعني تلقائيًا أن L-BTC غير آمنة.
هذا يعني فقط أن نموذج المخاطر أوسع.
كل جسر (bridge) أو sidechain أو منتج BTC ملفوف (wrapped) أو أمين حفظ (custodian) يضيف شيئًا مفيدًا.
وغالبًا أيضًا تضيف عنصرًا آخر يجب أن يعمل بشكل صحيح.
11-of-15 يبدو آمنًا. لكن ماذا يوقّع الـ 11 فعليًا؟
على الأرجح هذا جزءٌ أنا أحبّه أكثر من أي جزء آخر في الحادث.
عندما يفكر الناس في أمان multisig عادةً يكون السؤال:
كم مفتاحًا يحتاج المهاجم لسرقته؟
يبدو 11-of-15 قويًا لأن سرقة 11 مفاتيح توقيع مستقلة أمر صعب بطبيعة الحال.
لكن وفقًا للتفسير الرسمي الحالي، لم يحدث ذلك هنا.
يبدو أن المُوقِّعين قُدِّموا إلى حالة كانت تبدو صحيحة.
لذلك ربما يكون السؤال الأهم أكثر هو:
ماذا يتحقق فعليًا منه هؤلاء الـ 11 المُوقِّع؟
وهل تعتمد كل الـ 11 على منطق برنامج واحد؟
لأنه إذا كان لدى كل مُوقِّع مفتاح آمن بشكل مستقل لكن كل مُوقِّع يثق بنفس منطق التحقق الخاطئ المُكسور، فتنوع المفاتيح لا يعني بالضرورة تنوع التحقق (validation diversity).
هذا نوع مختلف تمامًا من المخاطر.
وهي من الأشياء التي يتحدث عنها الناس أقل بكثير.
حتى إثباتات الاحتياطي تصبح أكثر تعقيدًا
عادةً السؤال الواضح بشأن شيء مثل L-BTC هو:
هل تطابق كمية BTC الموجودة في الاحتياطي كمية L-BTC المتداولة؟
هذا منطقي.
لكن أنظمة المعاملات السرّية تجعل هذا أصعب، لأن مبالغ الرموز قد لا تكون مرئية علنًا دائمًا بنفس الطريقة البسيطة.
وهناك مشكلة أخرى أيضًا.
إذا أمكن إنشاء L-BTC غير صالح ثم حرقه ضمن نفس العملية التي تسحب BTC الحقيقي، فقد لا يخبرك لقطة (snapshot) يتم أخذها لاحقًا بالقصة التاريخية كاملة.
قد تتمكن من النظر إلى النظام بعد وقوع الحدث وأن تفوتك كيفية حدوث عدم التطابق.
لكنني لا أريد أن أذهب أبعد من الأدلة هنا.
هذا ليس حكمًا نهائيًا على تصميم احتياطي Liquid.
إنها مشكلة تسوية (reconciliation) كشف عنها الحادث.
نحتاج إلى التقرير التقني الكامل، وتسوية الاحتياطي، وتسويات إنشاء/حرق (mint/burn) كاملة قبل تقديم ادعاءات أقوى.
هل هذا أمر منهجي بالنسبة لبيتكوين؟
لا أعتقد ذلك.
حوالي 4,000 BTC مالٌ ضخم.
لكن مقارنةً ببيتكوين نفسها، فهذا ليس صدمة توريدية منهجية.
لم تتأثر أيضًا أمان بروتوكول بيتكوين.
لذلك لن أحوّل ذلك إلى قصة سوق من نوع “بيتكوين معطلة”.
لكن ماذا عن البنية التحتية التي يتم بناؤها حول بيتكوين؟
نعم، هذا مهم.
خصوصًا عندما يتم التفاف BTC وربطها وتخزينها بأمان وتحويلها إلى أصول مالية عبر أنظمة أكثر.
هناك أيضًا تمييز آخر يتعلق بأصول Liquid الأخرى.
قالت Liquid إن الأصول مثل USDT وDePix وRWAs لم تكن مخترقة مباشرةً بسبب حادث الأمان.
لكن عبارة “غير مختَرقة مباشرةً” لا تعني “غير متأثرة تمامًا”.
إذا توقفت الشبكة، يمكنك أن تواجه مشاكل تحويل وسيولة حتى لو لم يتم اختراق الرمز نفسه.
فمن يحتاج فعليًا إلى القلق؟
إذا كنت تمتلك BTC محليًا في محفظتك الخاصة
لا يؤثر هذا الحادث بشكل مباشر على أمان بروتوكولك.
لم يتم اختراق Bitcoin L1.
إذا كنت تمتلك L-BTC
لديك تعرّض تشغيلي لربط (peg) Liquid والتحويلات وإعادة تشغيل الشبكة.
من الواضح أن إيقاف peg-outs والتبديلات والتحويلات أمر مهم.
إذا كنت تمتلك USDT أو أصولًا مُرمّزة (tokenized) على Liquid
لا توجد تأكيدات على أن هذه الأصول نفسها تم اختراقها.
لكن إذا لم تكن Liquid تعمل بشكل طبيعي، فقد يصبح الوصول والسيولة مشكلةً كذلك.
إذا كنت تستخدم منتجًا مبنيًا على Liquid
عندها سأهتم تحديدًا بكم يعتمد هذا المنتج على Liquid، وما الضمان (collateral) الذي يستخدمه، وكيف يبدو plan التعافي/إعادة التشغيل (recovery/restart).
رأيي
لم تكن هذه عملية اختراق لبيتكوين.
وأعتقد أن وصفها بهذه الطريقة يخبّئ الدرس الأكثر فائدة.
أدى خطأ برمجي في Elements إلى السماح بمرور L-BTC غير مدعوم عبر ما بدا أنه مسار Peg-out (خروج ربط) شرعي.
بعدها قامت Liquid Federation بسحب 3,996 BTC على شبكة Bitcoin mainnet.
يبدو أن المفاتيح لم تُسرق.
كانت التواقيع تعمل.
عمل بيتكوين.
كانت المشكلة أن الشيء الذي تم توقيعه بدا صالحًا عندما لا ينبغي أن يكون كذلك.
وهذا يغيّر سؤال الأمان بشكل كبير.
ليس الأمر فقط:
كم عدد المفاتيح التي تحمي الاحتياطي؟
وهو أيضًا:
ما المعلومات التي تثق بها تلك المفاتيح قبل أن توقّع؟
يمكن أن تكون بيتكوين شديدة الأمان بينما تفشل أي شيء يتم بناؤه حول بيتكوين.
في كل مرة نلتف BTC أو نربطها أو نحتفظ بها بأمان أو ننقلها إلى بيئة تنفيذ أخرى، نكسب قابلية استخدام أكثر.
لكننا نضيف أيضًا افتراض ثقة آخر.
وهذا هو القصة الحقيقية هنا