عندما يفشل التحكم في السحابة، يشعر الإنترنت بذلك؛ حان الوقت لتدخل RPC اللامركزية

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

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

تُفسر هذه الديناميكية سبب تجميد الوصول إلى المحفظة، وتعطيل نقاط نهاية واجهة برمجة التطبيقات (API)، وتعطيل قدرة مستخدمي العملات المشفرة على التفاعل مع سلاسل آمنة. لقد انهار الإنترنت إلى مخطط تبعيات ضيق، حيث تُوجه مختلف مستويات التحكم السحابي، وتُؤمّن، وتُسلّم معظم حركة المرور العالمية.

لماذا تنتشر الأخطاء الداخلية الصغيرة عالميا؟

نادرًا ما يُفصح مُزوّدو الخدمات السحابية عن تكاليف انقطاع الخدمة، ولكن بالنسبة للشركات المتوسطة والكبيرة، قد تُكلّف أوقات التوقف مئات الآلاف من الدولارات في الساعة، بل قد تصل إلى ملايين الدولارات في الساعة للأنظمة الحيوية للإيرادات. لا تشمل هذه الأرقام الأعطال المتتالية في عمليات المصادقة والمدفوعات والحفظ والتداول، حيث تُعدّ كل ثانية بالغة الأهمية. 

البنية التحتية للعملات المشفرة معرضة للخطر بشكل خاص. وكما لوحظ خلال انقطاع خدمة AWS في أكتوبر، تأثرت Coinbase وRobinhood والعديد من المحافظ ليس بسبب فشل سلاسل الكتل، بل لأن طبقة الوصول الخاصة بها، ونقاط نهاية RPC، وواجهات برمجة التطبيقات، وخدمات البوابة تعتمد على نفس نقاط الاختناق السحابية.

يقول كليبر: "الدرسdentمن حادثتي AWS وCloudflare بسيط. إذا كانت جميع حركة المرور تشترك في طريق واحد، فإن حفرة واحدة توقف الجميع".

الذكاء الاصطناعي سيُرهق البنية التحتية المركزية

وفقًا لوكالة الطاقة الدولية (IEA)، سيتضاعف استهلاك مراكز البيانات العالمية للكهرباء بحلول عام 2030، وستشكل أحمال عمل الذكاء الاصطناعي حصة كبيرة منه. ويعني ازدياد استخدام الذكاء الاصطناعي استمرارية الطلبات، واعتمادًا أكبر على واجهات برمجة التطبيقات السحابية، وزيادة الضغط على طبقات التوجيه ونظام أسماء النطاقات (DNS).

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

سيتطلب عصر الذكاء الاصطناعي بنية تحتية قادرة على تحمل الانقطاعات المحلية دون عواقب عالمية. 

لماذا يغير RPC اللامركزي ملف تعريف الفشل

منصات مثل Lava Network تُوجّه الطلبات عبر عدةdent ، وتراقب الأداء آنيًا، وتُعيد توجيه حركة البيانات تلقائيًاmaticعن المسارات غير السليمة. النتيجة: الأعطال التي عادةً ما تُصبح انقطاعات على مستوى المنصة تبدو أشبه بتدهور محلي. 

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

بمعنى آخر، اللامركزية ليست تكرارًا، بل عزلًا للأخطاء. إذا كان تطبيق يستخدم شبكة Lava أثناء انقطاع AWS أو Cloudflare، فيمكنه تجاوز العطل بدلًا من انقطاع الخدمة.

يقول كليبر: "مهمة جهاز التوجيه هي الحفاظ على صغرdent. في حال تعطل منطقة أو مزود خدمة، تُوجَّه الطلبات إلى مسارات سليمة وتُستعاد عند تعافيها. يتقلص نطاق التعطل من "التطبيق بأكمله" إلى "الشريحة التي تستخدم المسار الخاطئ"."

هذا هو عكس RPC المركزي، حيث يؤثر فشل بوابة واحدة على كل مستخدم.

التنوع القابل للتحقق: العنصر المفقود في البنية التحتية لـ Web3

إن إحدى نقاط القوة الرئيسية لـ RPCs اللامركزية هي أنها يمكن أن توفر تنوعًا يمكن التحقق منه، وليس مجرد ادعاءات.

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

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

ما يمكن وما لا يمكن لـ RPC اللامركزي إصلاحه

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

المستقبل: السحابة + التوجيه اللامركزي

عند التفكير في المرحلة التالية من البنية التحتية للإنترنت، يرى كليبر أن الوجهة ستكون مختلطة: حيث تبقى مرونة السحابة قائمة، لكن التركيز المفرط سيتلاشى في النهاية. ويوضح قائلاً: "الحالة الثابتة هي سحابات متعددة وموفرو خدمات متخصصون، مترابطون عبر توجيه يُفضّل المسارات السليمة ويترك سجل تدقيق موثوقًا به. لا تزال الانقطاعات تحدث؛ لكنها لم تعد تُصبح عناوين رئيسية."

إذا كان عام 2025 بمثابة طلقة تحذيرية، فإن عام 2026 هو العام الذي يتعين فيه على الصناعة تنويع طبقة الوصول الخاصة بها قبل أن يتسبب خطأ مستوى التحكم التالي في توقف نصف الإنترنت.