وهم اللامركزية: كيف كشف خطأ في قاعدة بيانات شركة واحدة هشاشة بنية التحتية للعملات الرقمية

في 18 نوفمبر 2025، توقف حوالي 20% من الإنترنت عن العمل—ليس بسبب هجوم إلكتروني، بل بسبب تحديث روتيني لصلاحيات قاعدة البيانات أدى إلى ظهور خطأ مخفي في Cloudflare، شركة “تحمي” الإنترنت من هذا النوع من الفشل بالذات.

خلال دقائق، بدأ التسلسل: تعطلت تويتر أثناء التغريدة، تجمد ChatGPT، توقف Spotify عن البث. وفي عالم العملات الرقمية؟ توقفت منصات التداول، فشلت مستكشفات البلوكشين، عادت واجهات المحافظ إلى أخطاء 500. لمدة خمس ساعات ونصف، صنعت الصناعة التي وضعت نفسها كحماية ضد الرقابة ولا يمكن إيقافها نفسها توقفت تمامًا.

السخرية القاسية؟ أن البلوكشين نفسها استمرت في العمل بشكل مثالي. بيتكوين كانت تعدين الكتل. إيثيريوم كانت تعالج المعاملات. لا فشل في الإجماع، لا انهيار في البروتوكول. المستخدمون ببساطة لم يستطيعوا الوصول إلى ما يُفترض أنهم “يمتلكونه”.

ما حدث فعلاً: عثرة تقنية ذات مدى كارثي

Cloudflare لا تستضيف مواقع إلكترونية ولا تبيع قوة حوسبة مثل مزودي السحابة الكبار الآخرين. بدلاً من ذلك، فهي تعمل كمتحكم لحركة المرور على الإنترنت—تقف بين المستخدمين والخدمات عبر 120 دولة. تعالج الشركة حوالي 20% من حركة المرور العالمية عبر شبكتها العالمية.

في 18 نوفمبر عند الساعة 11:05 بالتوقيت العالمي، أجرت Cloudflare تغييرًا روتينيًا على مجموعة قواعد بيانات ClickHouse الخاصة بها. الهدف كان معقولًا: تحسين الأمان والموثوقية من خلال تحديث ضوابط الوصول. لكن هنا تكمن مشكلة مقاومة البنية التحتية الحديثة.

الاستعلام عن قاعدة البيانات الذي أنشأ إعدادات حماية الروبوتات لم يتضمن فلترًا لأسماء قواعد البيانات. هذا يعني أن الاستعلام بدأ يعيد إدخالات مكررة—واحدة من قاعدة البيانات الافتراضية، وأخرى من طبقة التخزين الأساسية. فجأة، تضاعف حجم ملف التكوين، من حوالي 60 ميزة إلى أكثر من 200.

المهندسون في Cloudflare وضعوا حدًا ثابتًا عند 200 ميزة، معتقدين أن هذا يتجاوز الاستخدام الفعلي بكثير. منطق هندسي كلاسيكي: وضع هامش أمان كبير وافترض أنه لن يتم تجاوزه أبدًا. حتى حدث ذلك.

الملف الضخم أوقف نظام حماية الروبوتات—مكون أساسي في طبقة التحكم الكاملة لـ Cloudflare. عندما يفشل نظام، تتبع الأنظمة التابعة. نظام مراقبة الصحة الذي يخبر موازنات الحمل “أي الخوادم تعمل” أيضًا فشل. استمر المرور في الوصول إلى عقد Cloudflare الحافة، لكن لم يكن هناك طريقة لتوجيهه.

لساعات قليلة، ظن مهندسو Cloudflare أنهم يتعرضون لهجوم حجب الخدمة الموزع الضخم. استمر النظام في التبديل بين “يعمل” و"مكسور تمامًا" كل خمس دقائق مع إعادة توليد التكوين المسبب للمشكلة. لكن لم يكن هناك هجوم—فقط فلتر قاعدة بيانات مفقود وافتراض ثبت خطؤه.

بحلول الساعة 17:06 بالتوقيت العالمي، تم نشر التكوين الصحيح عالميًا. استُعيدت الخدمة. تم تفادي الأزمة.

صناعة العملات الرقمية لا تملك فرصة للاحتفال—لقد تعرضت للكشف

بينما عانت منصات Web2 أولاً وبشكل أكثر وضوحًا—تقطعت بثوث Spotify، انقطعت جلسات الألعاب، تعطلت أنظمة توصيل الطعام—واجه عالم العملات الرقمية حقيقة أكثر إزعاجًا.

لم تتمكن العديد من منصات التبادل من التحميل. فشلت مستكشفات البلوكشين. خدمات المحافظ توقفت. واجهات التداول أظهرت رسائل خطأ. وأراد الجميع نشر ذلك على تويتر—لكن اكتشفوا أن تويتر أيضًا متوقف.

خلق هذا صمتًا غريبًا. خلال انقطاع AWS في أكتوبر، قضى تويتر العملات الرقمية ساعات يسخر من “هشاشة البنية التحتية” و"مخاطر المركزية". هذه المرة؟ لم يستطع أحد السخرية من شيء. المنصة التي تستخدمها لانتقاد نقاط الفشل المفردة هي نفسها نقطة فشل مفردة.

الجزء غير المريح: بروتوكولات البلوكشين نفسها لم تتأثر أبدًا. يمكن معالجة المعاملات على السلسلة. استمر الإجماع. الأساس الفني الكامل لـ"التمويل غير الموثوق، المقاوم للرقابة" عمل تمامًا كما هو مصمم.

لكن الأمر لم يهم. لأنه بدون وصول، البلوكشين الوظيفي هو مجرد سجل تاريخي لا يمكن لأحد قراءته.

النمط الذي لا يكسره أحد: أربع انقطاعات رئيسية، نفس المشكلة الأساسية

  • يوليو 2019: انقطاع Cloudflare. Coinbase غير متصل، البيانات السوقية غير متاحة.
  • يونيو 2022: فشل آخر في Cloudflare. عُلّقت خدمات عدة منصات عملات رقمية.
  • 20 أكتوبر 2025: انقطاع AWS استمر 15 ساعة. فشلت قواعد بيانات DynamoDB وتتابعت عبر الخدمات التابعة.
  • 18 نوفمبر 2025: مرة أخرى Cloudflare. خمس ساعات ونصف من الاضطراب الواسع.

أربع حوادث بنية تحتية رئيسية خلال حوالي 18 شهرًا. الدرس واضح: البنية التحتية المركزية تخلق فشلًا مركزيًا.

لكن الصناعة لم تتعلم بعد.

لماذا تظل “اللامركزية” مصطلحًا تسويقيًا أكثر منه واقعًا تقنيًا

صنعت صناعة العملات الرقمية فلسفتها على فرضية واحدة: القضاء على الوسطاء، إزالة نقاط الفشل المفردة، إنشاء أنظمة لا يمكن إيقافها.

لكن الواقع يبدو مختلفًا.

سلسلة الاعتماد على البنية التحتية الحالية للعملات الرقمية تقرأ كأنها نكتة يخشى أحد أن يرويها:

  • تعتمد البورصات الكبرى على Amazon Web Services
  • تعتمد DNS وتوصيل المحتوى على Cloudflare
  • تعتمد مستكشفات البلوكشين على Cloudflare
  • تعتمد منصات التحليلات على Cloudflare
  • تعتمد واجهات المحافظ على بنية تحتية مركزية مماثلة

لذا عندما تقوم Cloudflare بتحديث تكوين قاعدة البيانات وتكسر حماية الروبوتات، تتوقف الصناعة بأكملها—التي يُفترض أنها مبنية لمنع هذا السيناريو بالذات.

تظهر اللامركزية الزائفة بوضوح: طبقة البروتوكول موزعة حقًا، لكن طبقة الوصول مقيدة عبر ثلاث شركات تسيطر على حوالي 60% من البنية التحتية السحابية (أمازون ويب سيرفيسز بنسبة 30%، مايكروسوفت أزور بنسبة 20%، جوجل كلاود بنسبة 13%).

ثلاث شركات. اثنتان منها تعرضتا لانقطاعات في نفس الشهر. هذا ليس تكرارًا—بل هشاشة مركزة.

اقتصاد الإهمال

لماذا يتكرر هذا؟ لماذا لا تبني منصات العملات الرقمية بنية تحتية تفترض حدوث انقطاعات؟

الجواب بسيط ومؤلم: إنه مكلف ومعقد.

بناء بنيتك التحتية الخاصة يعني شراء أجهزة، ضمان استقرار الطاقة، صيانة عرض النطاق الترددي المخصص، توظيف خبراء أمن، إنشاء تكرار جغرافي، تصميم استرداد الكوارث، وتوفير مراقبة على مدار الساعة. يتطلب رأس مال كبير وتكاليف تشغيل مستمرة.

استخدام Cloudflare يتطلب إدخال رقم بطاقة ائتمان والنشر خلال دقائق.

الشركات الناشئة تركز على سرعة الوصول للسوق. المستثمرون يطالبون بالكفاءة الرأسمالية. الجميع يختار الراحة على المقاومة.

حتى تصبح الراحة غير مريحة بشكل عميق—وحتى أربع انقطاعات رئيسية خلال 18 شهرًا لا تكفي لتغيير السلوك.

هناك بدائل لامركزية: Arweave للتخزين، IPFS لنقل الملفات الموزع، Akash للحوسبة، Filecoin للاستضافة اللامركزية. لم تحقق أي منها اعتمادًا كبيرًا لأنها أبطأ، وأكثر تعقيدًا، وغالبًا أكثر تكلفة من البدائل المركزية.

الصناعة تتحدث عن اللامركزية بشكل شكلي، وتختار الحلول المركزية بشكل منهجي كلما ظهرت مفاضلة حقيقية بين المبدأ والراحة.

ما يراه المنظمون—ولماذا بدأوا يولون اهتمامًا

ثلاثة انقطاعات رئيسية خلال 30 يومًا لفتت انتباه صانعي السياسات الذين أدركوا الآن ما كان واضحًا: أن بضع شركات تكنولوجيا يمكنها تعطيل البنية التحتية الحيوية.

الأسئلة المطروحة:

  • هل الشركات التي تتحكم في 20% من حركة المرور العالمية على الإنترنت تعتبر “مؤسسات ذات أهمية نظامية”؟
  • هل يجب تنظيم البنية التحتية للإنترنت كمرافق عامة؟
  • ماذا يحدث عندما تنطبق عبارة “كبير جدًا على أن يفشل” على منصات التكنولوجيا؟
  • أين التكرار عندما تتسلسل الانقطاعات عبر مزودين يُفترض أنهم مستقلون؟

خلال فشل البنية التحتية السابق، كان خبراء السياسات واضحين: عندما يفشل بائع واحد، يصبح الإعلام غير متاح، وتتوقف الاتصالات الآمنة، وتنهار البنية التحتية التي تدعم المجتمع الرقمي.

الحكومات تدرك أن تركيز البنية التحتية للإنترنت يخلق مخاطر نظامية.

لكن التنظيم وحده لن يحل المشكلة. الحل الحقيقي يتطلب اعتماد البنية التحتية اللامركزية طوعيًا من قبل الصناعة نفسها—تحول يتطلب أن يكون ألم الفشل المركزي أكبر من راحة الحلول المركزية.

شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • تعليق
  • إعادة النشر
  • مشاركة
تعليق
0/400
لا توجد تعليقات
  • تثبيت