انقطاع Cloudflare: يكشف الستار عن زيف اللامركزية في صناعة العملات الرقمية

أربع أعطال كبيرة خلال 18 شهرًا، لماذا يصعب حل مأزق المركزية؟

المصدر: rekt news

الترجمة: Saoirse، Foresight News

في 18 نوفمبر 2025، الساعة 6:20 صباحًا بتوقيت الساحل الشرقي للولايات المتحدة. كثير منا واجه انقطاعًا في الشبكة.

لم يكن انقطاعًا تدريجيًا، ولم تكن هناك أي إشارات تحذيرية. في لحظة كنت تتصفح هاتفك، تتداول، أو تتحدث مع الذكاء الاصطناعي، وفي اللحظة التالية، كل ما تراه هو صفحات خطأ 500 تقريبًا في كل مكان.

توقف Twitter فجأة أثناء كتابة تغريدة، توقف ChatGPT عن الاستجابة في منتصف المحادثة، وClaude توقف كليًا.

حتى Downdetector—الموقع الذي تلجأ إليه عندما تتعطل جميع المنصات—لم يعد يعمل، ولم يعد بإمكانه إخبارك بأن "جميع الخدمات متوقفة".

اختفى 20% من الإنترنت العالمي فجأة، فقط لأن Cloudflare، التي من المفترض أن تحمي الإنترنت من الهجمات، قامت بـ"مهاجمة" نفسها عن طريق الخطأ.

تسبب تغيير عادي في الإعدادات (تحديث صلاحيات قاعدة البيانات) في كشف ثغرة خفية في نظام الحماية من الروبوتات، وفي لحظة، أصبح "حارس البوابة" يرفض الجميع.

في أكتوبر، عندما تسببت خدمات Amazon Web Services (AWS) في توقف Coinbase، كان مستخدمو Twitter في مجال العملات الرقمية يسخرون من عيوب "المركزية".

لكن ماذا حدث عند تعطل Cloudflare في نوفمبر؟ على الأقل في الساعات الأولى، كان مجتمع العملات الرقمية صامتًا تمامًا.

في النهاية، عندما تتعطل البنية التحتية التي يعتمد عليها Twitter، لا يمكنك حتى مناقشة "هشاشة البنية التحتية" على Twitter.

توقفت العديد من الخدمات الحيوية (تعطل أنظمة محطات النقل)، وواجهت بعض الشركات مشاكل في واجهاتها الشبكية، وظهرت رسائل خطأ 500 في متصفحات البلوكشين مثل Arbiscan وDeFiLlama—لكن البلوكشين نفسه لم يظهر أي علامات على انقطاع التوافق.

عندما تتوقف "ثورتك اللامركزية" التي تتفاخر بها بسبب حجم ملف إعدادات شركة واحدة، من الذي يسيطر فعلاً على كل شيء؟

الجدول الزمني للعطل: من "تغيير الإعدادات" إلى "انهيار الشبكة بالكامل"

الساعة 11:05 بتوقيت UTC: تم نشر تغيير صلاحيات الوصول إلى قاعدة البيانات.

بعد 23 دقيقة، أي الساعة 11:28 بتوقيت UTC، وصل التغيير إلى بيئة المستخدم، وظهرت أول أخطاء في حركة HTTP الخاصة بالمستخدمين.

بمعنى آخر: وقع العطل، لكن لم يكن أحد يعرف مصدر المشكلة في ذلك الوقت.

بحلول الساعة 11:48 بتوقيت UTC، اعترف الموقع الرسمي لحالة Cloudflare أخيرًا بأن "الخدمات الداخلية تواجه عطلًا"—والترجمة الحقيقية لهذا الخطاب المؤسسي هي: "كل شيء فوضوي، والجميع يلاحظ ذلك".

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

انهارت الأنظمة التابعة: لم يتمكن Workers KV (خدمة تخزين القيم الرئيسية) وAccess (خدمة التحكم في الوصول) من الاتصال بالوكيل؛ ارتفعت نسبة الأخطاء في الشبكة، ومع زيادة تحميل أدوات المراقبة، تجاوز استخدام وحدة المعالجة المركزية الحد الأقصى.

استمر تدفق الحركة إلى نقاط الحافة في Cloudflare—لكن خدمة الوكيل لم تعد تستجيب.

في البداية، اعتقدت Cloudflare أنها تتعرض لهجوم، بل هجوم DDoS واسع النطاق.

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

لكن الحقيقة لم تكن كذلك. لم يتعرضوا لهجوم خارجي، بل كانت المشكلة من الداخل.

بعد استعادة الخدمة بوقت قصير، أصدر كبير مسؤولي التكنولوجيا في Cloudflare (CTO) Dane Knecht بيان اعتذار علني، واصفًا الحادث بأنه "غير مقبول تمامًا"، وألقى باللوم على تغيير إعدادات روتيني—وهو ما تسبب في انهيار طبقة الحماية من الروبوتات.

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

في ذروة العطل، تلقى Downdetector ما يصل إلى 11183 تقريرًا عن الأعطال.

استمر هذا "الظلام الرقمي" لأكثر من خمس ساعات ونصف، حتى الساعة 17:06 بتوقيت UTC، حيث عادت الخدمة بالكامل؛ لكن منذ الساعة 14:30، وبعد نشر ملف إعدادات إدارة الروبوتات الصحيح عالميًا، تم تخفيف التأثير الأكثر خطورة.

تأثير العطل: من Web2 إلى مجال العملات الرقمية، لا أحد في مأمن

منصات Web2 في الواجهة

تلقت منصة X ما يصل إلى 9706 تقارير عن الأعطال.

لم ير المستخدمون الجدول الزمني المعتاد، بل واجهوا رسالة خطأ "عذرًا، حدث خطأ ما".

توقف ChatGPT عن الاستجابة في منتصف المحادثة.

توقفت خدمة البث Spotify، ومنعت منصة التصميم Canva المصممين من الدخول، وظهرت مشاكل في Uber وDoor Dash (منصات التوصيل).

حتى اللاعبين لم يسلموا، حيث تم فصل لاعبي League of Legends في منتصف اللعبة.

حتى أن هناك تقارير عن ظهور شاشة خطأ في أجهزة الطلب الذاتي في McDonald's—تزامن وقت الذروة مع عطل البنية التحتية.

مجال العملات الرقمية لم يكن "استثناءً".

توقف واسع النطاق لمنصات العملات الرقمية

انهار الواجهة الأمامية لـ Coinbase بالكامل، ولم يتمكن المستخدمون سوى من رؤية صفحة تسجيل الدخول غير القابلة للتحميل.

توقفت كل من واجهة الويب وتطبيق الهاتف المحمول لـ Kraken—وهذا نتيجة مباشرة لعطل Cloudflare العالمي.

نشرت BitMEX إعلانًا على صفحة الحالة الخاصة بها: "نحقق في سبب العطل، أداء المنصة منخفض، لكن أموال المستخدمين في أمان."—نفس السيناريو، لكن مع منصة تداول مختلفة.

تعذر تحميل Etherscan، وArbiscan انهارت كليًا.

ظهرت أخطاء خادم داخلية متقطعة في لوحة تحليل بيانات DeFiLlama.

حتى Ledger أصدرت إعلانًا بأن بعض خدماتها تأثرت بانخفاض التوافر بسبب عطل Cloudflare.

الاستثناء الوحيد: بروتوكولات البلوكشين نفسها

لكن الأنظمة التالية لم تتأثر:

وفقًا للتقارير، لم تواجه منصات التداول الرئيسية مثل Binance وOKX وBybit وCrypto.com وKuCoin أي مشاكل في الواجهة الأمامية، واستمرت المعاملات على السلسلة بشكل طبيعي—وفي الوقت نفسه، استمر البلوكشين نفسه في العمل بشكل طبيعي تمامًا، دون أي علامات على انقطاع التوافق.

تعمل بروتوكولات البلوكشين دائمًا بشكل مستقل—المشكلة ليست في السلسلة، بل في بنية Web2 التحتية التي يستخدمها الناس للوصول إلى البلوكشين.

إذا كان البلوكشين لا يزال يعمل، لكن لا أحد يستطيع الوصول إليه، فهل العملات الرقمية "متصلة" حقًا؟

تحليل معمق: لماذا تسبب استعلام قاعدة بيانات في شل 20% من الشبكة؟

Cloudflare لا تستضيف المواقع، ولا تقدم خدمات خوادم سحابية مثل AWS.

دورها هو "الوسيط"—تقع بين المستخدمين والإنترنت، وتخدم 24 مليون موقع، وتعالج 20% من حركة الإنترنت العالمية عبر نقاط في 120 دولة و330 مدينة.

الخطاب التسويقي لـ Cloudflare هو: أنها "درع الإنترنت ومسرعه"، تقدم حماية DDoS على مدار الساعة، حماية من الروبوتات، توجيه حركة المرور، جدار حماية تطبيقات الويب العالمي (WAF)، إنهاء TLS، حوسبة الحافة عبر Workers، وخدمات DNS—كلها تعمل على شبكة موحدة "آمنة وسريعة".

أما الواقع: فهي تسيطر على 82% من سوق حماية DDoS، ويصل إجمالي عرض النطاق الترددي لنقاط الحافة إلى 449 تيرابت/ثانية (Tbps)، وتتصل بالعديد من مزودي خدمات الإنترنت (ISP) ومزودي الخدمات السحابية الرئيسيين حول العالم.

جوهر المشكلة: عندما يفشل الوسيط، تصبح جميع الخدمات التي تعتمد عليه "بعيدة المنال" في الوقت نفسه.

قال كبير مسؤولي التكنولوجيا في Cloudflare Dane Knecht بصراحة على منصة X:

"سأكون صريحًا: في وقت سابق اليوم، بسبب مشكلة في شبكة Cloudflare، تأثرت كمية كبيرة من الحركة التي تعتمد علينا، لقد خذلنا عملاءنا ومستخدمي الإنترنت بشكل عام."

أما تعبير الرئيس التنفيذي Matthew Prince فكان أكثر وضوحًا:

"اليوم هو أسوأ عطل في Cloudflare منذ 2019... خلال أكثر من 6 سنوات، لم يحدث لدينا عطل يمنع معظم الحركة الأساسية من المرور عبر شبكتنا."

الجذور التقنية للعطل

بدأ كل شيء بتحديث روتيني لصلاحيات قاعدة البيانات. في الساعة 11:05 بتوقيت UTC، أجرت Cloudflare تغييرًا على مجموعة قواعد بيانات ClickHouse الخاصة بها، بهدف تعزيز الأمان والموثوقية—لتمكين المستخدمين الذين لديهم "صلاحيات وصول ضمنية" من رؤية بيانات الجداول "بشكل صريح".

أين كانت المشكلة؟ الاستعلام الذي ينشئ ملف إعدادات خدمة الحماية من الروبوتات في Cloudflare لم يقم بتصفية "اسم قاعدة البيانات".

بدأ الاستعلام المسؤول عن إدارة حركة المرور الضارة في إرجاع عناصر مكررة—واحدة من قاعدة البيانات الافتراضية، وأخرى من قاعدة بيانات التخزين الأساسية r0. أدى ذلك إلى مضاعفة حجم الملف الوظيفي، من حوالي 60 خاصية إلى أكثر من 200 خاصية.

كانت Cloudflare قد حددت حدًا أقصى مشفرًا مسبقًا بـ 200 خاصية للذاكرة، واعتبرت أن "هذا أعلى بكثير من الاستخدام الفعلي الحالي البالغ حوالي 60 خاصية". هذا هو التفكير الهندسي التقليدي: تعيين هامش أمان "واسع بما فيه الكفاية" حتى يحدث غير المتوقع.

تجاوز حجم الملف الحد الأقصى، وانهار كود Rust مباشرة، مع رسالة الخطأ: "thread fl2_worker_thread panicked: called Result::unwrap () on an Err value" (انهيار خيط fl2_worker_thread: تم استدعاء طريقة Result::unwrap () على قيمة خطأ).

نظام الحماية من الروبوتات هو مكون أساسي في طبقة التحكم في Cloudflare. بمجرد انهياره، يتوقف نظام فحص الصحة الذي يخبر موازن التحميل "أي الخوادم تعمل بشكل طبيعي".

والأسوأ: يتم إعادة إنشاء ملف الإعدادات هذا كل 5 دقائق.

فقط عندما يعمل الاستعلام على "العقد المحدثة في المجموعة"، يتم إنشاء بيانات خاطئة. لذلك، كل 5 دقائق، تتأرجح شبكة Cloudflare بين "الوضع الطبيعي" و"العطل"—أحيانًا يتم تحميل الملف الصحيح، وأحيانًا الملف الخاطئ.

هذا "التأرجح" جعل المهندسين يعتقدون أنهم يتعرضون لهجوم DDoS—فالأخطاء الداخلية عادة لا تسبب دورة "استعادة ثم انهيار" متكررة.

أخيرًا، بعد تحديث جميع عقد ClickHouse، أصبح كل ملف يتم إنشاؤه خاطئًا. توقف "التأرجح"، وحل محله "عطل كامل ومستقر".

بدون إشارة نظام دقيقة، يدخل النظام في "الوضع التحفظي" افتراضيًا، ويعتبر معظم الخوادم "غير صحية". تستمر الحركة في التدفق، لكنها لا تُوجه بشكل صحيح.

يمكن لنقاط الحافة في Cloudflare استقبال طلبات المستخدمين—لكنها لم تعد قادرة على معالجتها.

"لم يكن هذا هجومًا خارجيًا،" شدد Knecht مرارًا، "لم يكن هناك سلوك خبيث، ولا هجوم DDoS. فقط استعلام قاعدة بيانات أغفل شرط التصفية، وتزامن ذلك مع تحديث الصلاحيات، مما أدى في النهاية إلى العطل."

كانت Cloudflare قد وعدت بـ"99.99% من التوافر"—لكن هذه المرة، لم يتم الوفاء بالوعد.

وهذا صحيح بالفعل.

التاريخ يعيد نفسه: أربع أعطال كبيرة خلال 18 شهرًا، لماذا يصعب حل مأزق المركزية؟

20 أكتوبر 2025—استمر عطل AWS لمدة 15 ساعة. فشل تحليل DNS لقاعدة بيانات DynamoDB في المنطقة الشرقية 1 بالولايات المتحدة، ما أدى إلى تجميد Coinbase، بطء Robinhood، وانقطاع خدمة Infura (مما أثر على MetaMask)، وتوقف شبكات البلوكشين مثل Base وPolygon وOptimism وArbitrum وLinea وScroll. رغم أن أموال المستخدمين كانت آمنة على السلسلة، إلا أن كثيرين رأوا رصيد حساباتهم "صفرًا".

29 أكتوبر 2025—عطل في Microsoft Azure. ظهرت مشكلة في مزامنة إعدادات Azure Front Door (البوابة الأمامية)، ما أدى إلى توقف مجموعة Microsoft 365 المكتبية، وتعطل خدمة Xbox Live، وانقطاع الخدمات المؤسسية.

يوليو 2024—تسبب خلل في حزمة تحديثات Windows من CrowdStrike (شركة أمنية) في توقف الرحلات الجوية، وتأخير العمليات الطبية في المستشفيات، وتجميد الخدمات المالية، واستغرق التعافي الكامل عدة أيام.

يونيو 2022—آخر عطل كبير لـ Cloudflare. اضطرت العديد من منصات تداول العملات الرقمية إلى تعليق خدماتها—نفس النمط، لكن في عام مختلف.

يوليو 2019—عطل سابق في Cloudflare. توقفت Coinbase، وتعذر الوصول إلى CoinMarketCap—وكان هذا أول "إشارة تحذير" تجاهلها الجميع.

خلال 18 شهرًا فقط، حدثت أربع أعطال كبيرة في البنية التحتية.

أربعة أعطال، تحمل نفس الدرس: البنية التحتية المركزية تؤدي حتمًا إلى "عطل مركزي".

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

كم عدد التحذيرات التي يجب أن يمر بها القطاع قبل أن يتحول من "افتراض إمكانية حدوث العطل" إلى "بناء الأنظمة على أساس أن العطل سيحدث حتمًا"؟

كذبة اللامركزية: لامركزية البروتوكول لا تعني لامركزية الوصول

لقد رسموا لك هذه الصورة:

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

لكن الواقع في 18 نوفمبر كان صادمًا: عطل Cloudflare لبضع ساعات في الصباح أدى إلى توقف بعض خدمات قطاع العملات الرقمية لساعات.

الحقيقة التقنية:

لم يتم الإبلاغ عن أي عطل في أي بروتوكول بلوكشين. شبكة Bitcoin تعمل بشكل طبيعي، وشبكة Ethereum كذلك—السلسلة نفسها بلا مشاكل.

الواقع في الاستخدام الفعلي:

انهيار واجهات منصات التداول، تعطل متصفحات البلوكشين، فشل واجهات المحافظ، تعطل منصات تحليل البيانات، ظهور رسائل خطأ 500 في واجهات التداول.

لم يتمكن المستخدمون من الوصول إلى البلوكشين "اللامركزي" الذي من المفترض أنهم "يمتلكونه". البروتوكول نفسه يعمل—بشرط أن تتمكن من "الوصول" إليه.

قد تبدو التصريحات التالية قاسية للبعض...

أشار David Schwed، المدير التنفيذي للعمليات في SovereignAI، بلا رحمة:

"عطل Cloudflare اليوم، وعطل AWS قبل أسابيع، يوضحان تمامًا: لا يمكننا ببساطة تفويض 'قدرة البنية التحتية على مقاومة الأعطال' إلى مزود واحد. إذا كانت مؤسستك بحاجة للعمل على مدار الساعة، يجب أن تبني البنية التحتية على أساس أن الأعطال حتمية. إذا كان لديك خطة لاستمرارية الأعمال تعتمد فقط على 'انتظار المزود لاستعادة الخدمة'، فهذا إهمال بحت."

"إهمال بحت"—ليس صدفة، ولا سهو، بل إهمال.

كان تقييم Jameson Lopp دقيقًا:

"لدينا تقنية لامركزية رائعة، لكننا جعلناها هشة للغاية لأن معظم الخدمات تتركز في أيدي عدد قليل من المزودين."

ما قاله Ben Schiller أثناء عطل AWS الأخير ينطبق الآن أيضًا:

"إذا كان بإمكان عطل AWS أن يوقف بلوكشينك، فهو ليس لامركزيًا بما فيه الكفاية."

استبدل "AWS" بـ "Cloudflare"، وستجد أن جوهر المشكلة لم يتغير—لم تتعلم الصناعة الدرس أبدًا.

لماذا يتم اختيار "الراحة" على "المبادئ"؟

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

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

الحماية من DDoS مسؤولية الغير، التوافر مسؤولية الغير، التوسع مسؤولية الغير.

الشركات الناشئة تسعى لـ"إطلاق سريع"، وصناديق رأس المال المخاطر تطلب "كفاءة رأس المال"—الجميع اختار "الراحة" بدلًا من "مقاومة الأعطال".

حتى اللحظة التي لم تعد فيها "الراحة" مريحة.

عطل AWS في أكتوبر أثار نقاشًا لا ينتهي على Twitter حول "اللامركزية".

أما عطل Cloudflare في نوفمبر؟ صمت تام.

ليس بسبب "صمت فلسفي"، ولا "هدوء بعد تفكير عميق".

بل لأن الناس أرادوا السخرية، لكن منصة السخرية المعتادة (Twitter) تعطلت أيضًا بسبب عطل البنية التحتية.

عندما تكون "نقطة الفشل الواحدة" هي نفسها المنصة التي تستخدمها للسخرية من "نقطة الفشل الواحدة"، لن تجد مكانًا للسخرية.

عندما تعتمد طبقة الوصول على بنية تحتية لثلاث شركات، واثنتان منها تعطلت في نفس الشهر، تصبح "اللامركزية على مستوى البروتوكول" بلا معنى.

إذا لم يتمكن المستخدمون من الوصول إلى البلوكشين، فما الذي "نلامركزه" فعلاً في "اللامركزية"؟

مأزق الاحتكار: ثلاث شركات تسيطر على 60% من سوق السحابة، إلى أين يتجه قطاع العملات الرقمية؟

تسيطر AWS على حوالي 30% من سوق البنية التحتية السحابية العالمي، وتستحوذ Microsoft Azure على 20%، وGoogle Cloud على 13%.

ثلاث شركات تسيطر على أكثر من 60% من البنية التحتية السحابية التي تدعم الإنترنت الحديث.

كان من المفترض أن يكون قطاع العملات الرقمية "حلًا للمركزية"، لكنه الآن يعتمد على أكثر البنى التحتية مركزية في العالم.

قائمة "الاعتماد المركزي" في قطاع العملات الرقمية

• Coinbase — تعتمد على AWS؛
• Binance، BitMEX، Huobi، Crypto.com — جميعها تعتمد على AWS؛
• Kraken بنيت بنيتها التحتية على AWS، لكنها تأثرت أيضًا بعطل شبكة توزيع المحتوى (CDN) في Cloudflare.

العديد من منصات التداول التي تدعي "اللامركزية" تعمل فعليًا على بنية تحتية مركزية.

هناك فرق رئيسي آخر بين أعطال أكتوبر ونوفمبر:

عند عطل AWS، استمرت منصة X (Twitter سابقًا) في العمل بشكل طبيعي، وتمكن مستخدمو العملات الرقمية من السخرية من "هشاشة البنية التحتية".

أما عند عطل Cloudflare، فقد توقفت منصة X أيضًا.

عندما تكون المنصة التي تستخدمها "للسخرية من نقطة الفشل الواحدة" جزءًا من "نقطة الفشل الواحدة" نفسها، لن تجد ما يضحكك.

هذا الشعور بالسخرية أوقف النقاش الصناعي قبل أن يبدأ.

ثلاث أعطال كبيرة خلال 30 يومًا، وقد أصبحت الهيئات التنظيمية تراقب ذلك عن كثب.

القضايا الأساسية التي يجب على الجهات التنظيمية مواجهتها

• هل تعتبر هذه الشركات "مؤسسات ذات أهمية نظامية"؟
• هل يجب أن تخضع خدمات الإنترنت الأساسية لـ"تنظيم المرافق العامة"؟
• ما المخاطر التي قد تنشأ عندما يجتمع "الكبر الذي لا يمكن معه السقوط" مع البنية التحتية التقنية؟
• إذا كانت Cloudflare تسيطر على 20% من حركة الإنترنت العالمية، فهل يشكل ذلك احتكارًا؟

قالت Corinne Cath-Speth من منظمة المادة 19 صراحة أثناء عطل AWS الأخير: "عندما يتعطل مزود واحد، تتوقف الخدمات الحيوية—لا يمكن للصحافة الوصول، وتتوقف تطبيقات الاتصالات الآمنة مثل Signal، وتنهار البنية التحتية التي تدعم المجتمع الرقمي. نحن بحاجة ماسة إلى تنويع الحوسبة السحابية."

بعبارة أخرى: بدأت الحكومات تدرك تدريجيًا أن عددًا قليلاً من الشركات يمكن أن يوقف الإنترنت.

في الواقع، البدائل اللامركزية موجودة منذ فترة طويلة، لكن لا أحد يريد استخدامها.

مثل Arweave للتخزين، وIPFS لنقل الملفات الموزعة، وAkash للحوسبة، وFilecoin للاستضافة اللامركزية.

لماذا لا تلقى الحلول اللامركزية رواجًا؟

الأداء أقل من الحلول المركزية، ويمكن للمستخدمين الشعور بالتأخير مباشرة.

معدل الانتشار منخفض جدًا، وبالمقارنة مع سهولة "النشر على AWS" بنقرة زر، تبدو الحلول اللامركزية معقدة وصعبة الاستخدام.

غالبًا ما تكون التكلفة أعلى من استئجار البنية التحتية من "الثلاثة الكبار" (AWS، Azure، Google Cloud).

الواقع هو:

بناء بنية تحتية لامركزية حقيقية أمر بالغ الصعوبة، ويتجاوز التوقعات.

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

في مقال رأي حديث على CoinDesk، أشار الدكتور Max Li، الرئيس التنفيذي لشركة OORT، إلى نفاق القطاع:

"بالنسبة لصناعة تفتخر بـ'اللامركزية' وتروج لمزاياها باستمرار، فإن اعتمادها الشديد على منصات سحابية مركزية هشة هو نفاق بحد ذاته."

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

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

فقط عندما يصبح ثمن "الراحة" باهظًا بما يكفي لتغيير سلوك القطاع، ستنتصر "المبادئ" على "الراحة".

من الواضح أن عطل 18 نوفمبر لم يكن كافيًا، ولا عطل AWS في 20 أكتوبر، ولا عطل CrowdStrike في يوليو 2024.

إلى أي مدى يجب أن نصل حتى تتحول "البنية التحتية اللامركزية" من "موضوع للنقاش" إلى "متطلب أساسي"؟

في 18 نوفمبر، لم "تفشل" صناعة العملات الرقمية—بلوكشين نفسها عملت بشكل مثالي.

الفشل الحقيقي كان في كذبة القطاع الجماعية: الاعتقاد بإمكانية بناء "تطبيقات لا يمكن إيقافها" على "بنية تحتية قابلة للتعطل"؛ الاعتقاد بأن "مقاومة الرقابة" لها معنى فعلي عندما تسيطر ثلاث شركات على "قنوات الوصول"؛ الاعتقاد بأن "اللامركزية" لا تزال حقيقية عندما يمكن لملف إعدادات واحد في Cloudflare أن يقرر ما إذا كان ملايين الأشخاص يمكنهم التداول أم لا.

إذا كان البلوكشين لا يزال ينتج كتلًا، لكن لا أحد يستطيع إرسال معاملات، فهل هو "متصل" حقًا؟

لا توجد أي خطة طوارئ في القطاع.

عندما يحدث عطل، لا خيار سوى انتظار Cloudflare لإصلاحه، أو AWS لاستعادة الخدمة، أو Azure لنشر التصحيح.

هذه هي "استراتيجية التعافي من الكوارث" الحالية للقطاع.

تخيل فقط: ماذا لو ارتبطت الهوية الرقمية بالبلوكشين بشكل عميق؟

تدفع وزارة الخزانة الأمريكية نحو تضمين بيانات الهوية في العقود الذكية، وتطلب أن تمر كل تفاعل DeFi عبر تحقق KYC.

عندما يحدث العطل التالي في البنية التحتية، لن يفقد المستخدمون فقط حق التداول—بل سيفقدون القدرة على "إثبات هويتهم" في النظام المالي.

قد يتحول عطل مدته 3 ساعات إلى 3 ساعات من "عدم القدرة على تحميل واجهة التحقق البشري"—فقط لأن خدمة التحقق تعمل على بنية تحتية معطلة.

الضوابط التنظيمية التي تريد الهيئات بناءها تفترض أن "البنية التحتية متصلة دائمًا". لكن عطل 18 نوفمبر أثبت أن هذا الافتراض غير صحيح.

عندما تصبح مشكلة "المراقبة المفرطة" واضحة، سيتجه العاملون في التقنية نحو "حماية الخصوصية".

ربما حان الوقت الآن لإدراج "قدرة البنية التحتية على مقاومة الأعطال" ضمن هذه الفئة أيضًا.

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

العطل القادم قادم لا محالة—قد يكون من AWS، أو Azure، أو Google Cloud، أو عطلًا آخر في Cloudflare.

قد يكون الشهر المقبل، أو الأسبوع المقبل. لم تتغير البنية التحتية، ولم تتغير علاقات الاعتماد، ولم تتغير حوافز القطاع.

اختيار الحلول المركزية لا يزال الخيار الأرخص والأسرع والأسهل—حتى يتغير ذلك.

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

لن يتغير شيء، لأن "الراحة" دائمًا ما تتغلب على "إدارة المخاطر"—حتى يصبح ثمن "الراحة" كبيرًا لدرجة لا يمكن تجاهلها.

هذه المرة، تعطل "حارس البوابة" لمدة ثلاث ساعات ونصف.

في المرة القادمة، قد يستمر العطل لفترة أطول؛ في المرة القادمة، قد يحدث العطل أثناء انهيار السوق حيث تكون كل ثانية تداول مصيرية؛ في المرة القادمة، قد تتأثر أنظمة التحقق من الهوية أيضًا.

عندما تتعطل البنية التحتية التي تعتمد عليها في اللحظة التي لا يمكنك فيها تحمل الخسارة، من المسؤول؟

مصادر البيانات: The Guardian، Johnny Popov، PC Magazine، IT Professional، CNBC، Cloudflare، TechCrunch، AP News، CoinDesk، Tom's Hardware، Dane Knecht، Tom's Guide، Surya، Sheep Esports، TheBlock، Kraken، BitMEX، Ledger، Blockchain News، Statista، Roaring Computers، Jameson Lopp، Ben Schiller، المادة 19، CoinTelegraph