سبب قدرتي على فهم أهمية تحقيق الحوسبة اللامركزية بالكامل بشكل عميق، وراء ذلك قصة خاصة إلى حد ما؛ إنها تستحق أن تُروى، فدعني أشرحها لك بهدوء شيئًا فشيئًا.
منذ وقت مبكر في عام 2015، كنت قد دخلت مجال العملات المشفرة في بداياته، لكنني كنت أواصل أيضًا إدارة “Fight My Monster” التي أسستها سابقًا؛ وهي لعبة MMO (لعبة أدوار متعددة اللاعبين عبر الإنترنت) ومنصة شبكات اجتماعية، تضم 3 ملايين مستخدم، وتستطيع أن تدعم نفسها ماليًا، وتمتلك دعمًا من شركات رأس المال الاستثماري.
على الرغم من أنني وجدت مسارًا مهنيًا طويل الأمد في مجال الحوسبة اللامركزية، إلا أنني لا أستطيع أن أخيب ظن تلك الفئة من اللاعبين الذين ظلوا يدعمون هذه اللعبة باستمرار.
تم تطوير “Fight My Monster” بين عامي 2010 و2012، واعتمدت بنية معمارية كانت في ذلك الوقت مبتكرة للغاية. سمحت هذه البنية للنظام بأن يتوسع على نطاق واسع بتكلفة منخفضة وبجهد تشغيل وصيانة قليل جدًا (أي لاستيعاب عدد هائل من المستخدمين).
بشكل جوهري، يتألف هذا النظام من ثلاثة مكوّنات خلفية أساسية: الأول هو خدمة استضافة ويب بسيطة، مسؤولة عن توزيع كود اللعبة في الواجهة الأمامية والموارد إلى متصفحات الويب لدى المستخدمين (كنت أستخدم وقتها شبكة توزيع محتوى رائجة، أي CDN).
وبنفس منطق خدمة استضافة الويب، يجب أن تمتلك المكوّنان الآخران في الخلفية أيضًا قدرة “التوسع الأفقي”. وهذا يعني أنه لدعم المزيد من المستخدمين ومتطلبات الحوسبة والبيانات الخاصة بهم، كل ما عليّ فعله هو إضافة موارد عتادية، دون الحاجة إلى إعادة كتابة كود برامج الخلفية، ودون الحاجة إلى إدارة نظم معقدة ومملة. هذه الخاصية جعلتني في المراحل المبكرة من المشروع، وبعدد قليل جدًا من الأشخاص وبميزانية محدودة، قادرًا على تحقيق توسع سريع على نطاق واسع.
المكوّن الثاني هو إطار خادم ألعاب أفقي قابل للتوسع يُسمى “Starburst”، وهو ثمرة عمل بذلت فيها جهدي الشخصي، فقد بُني على خادم مفتوح المصدر يدعم بروتوكول RTMP. وRTMP هو بروتوكول شبكي طوّرته Adobe، يسمح لموارد وسائط Flash التي تعمل داخل متصفح الويب (هل تتذكر Flash؟) بأن تتواصل مباشرة مع الخادم. يتولى Starburst حمل منطق اللعبة وشبكة التواصل الاجتماعي، ويوجّه تقريبًا في الوقت الفعلي الكم الهائل من الأحداث التي تنتجها اللعبة إلى المستخدمين.
المكوّن الثالث هو قاعدة بيانات NoSQL قابلة للتوسع أفقيًا تُسمى Cassandra (إذا كنت مهتمًا بمجال قواعد البيانات، فستعرف على الأرجح أن أحد إصداراتها الحديثة وهو ScyllaDB، والذي يبرع حاليًا في تلبية احتياجات الذكاء الاصطناعي في الوقت الحقيقي).
يجدر بالذكر أن في فريقي كان لدينا، إضافةً إلى مطوري Cassandra الأصليين، المساهم الوحيد الآخر في الكود الأساسي (core committer) بخلاف الشركة الأصلية التي طورت Cassandra. علاوة على ذلك، كنت من أوائل المستخدمين الذين أدخلوا نسخة Cassandra التجريبية (beta) فعليًا في بيئة إنتاج عالية الشدة. عندما وصل عدد المستخدمين إلى 800 ألف، تعرضت قاعدة البيانات للتلف. ثم جاءت الـ 24 ساعة التالية لتكون أشد أيام التوتر على الإطلاق - كان عليّ إنقاذ البيانات بأقصى سرعة وإعادة تشغيل النظام (في تلك اللحظة شعرت كأني أندفع نحو السحابة، وفي اللحظة التالية شعرت أن كل شيء لا يمكن إصلاحه…… لكن في النهاية كانت هناك نتيجة مُطمئنة).
أجمل ما في Cassandra أنك تستطيع زيادة عدد العقد مباشرةً (أي خوادم مزودة بأقراص تخزين كبيرة السعة) لتحقيق توسع أفقي في سعة التخزين، وفي معدل القراءة، والأهم - معدل الكتابة. وهذه خاصية نادرة جدًا، لكنها محورية بالنسبة لتطبيقي، لأن “Fight My Monster” يولد كمًا هائلًا من البيانات.
بالطبع، من المزايا المهمة الأخرى لدى Cassandra أنها تمتلك القدرة على تحمل الأعطال. لقد ضبطت عامل نسخ (replication factor) يساوي 5، وهذا يعني أن بيانات الجميع آمنة جدًا (على الأقل اعتقدت ذلك آنذاك……). وبفضل إعداد النسخ الخمسة، بالنسبة لأي “نِصاب بيانات” (quorum) بعينه، طالما كانت 3 عقد على الإنترنت، يمكن للنظام أن يكتب البيانات بنجاح.
على عكس البلوك تشين، لا تمتلك Cassandra قدرات تحمل الأعطال البيزنطية، وهذا يعني أن عليّ إدارة أمن البنية التحتية بدقة ومنع اختراق المتسللين أو البرمجيات الخبيثة. ومع ذلك، لم يكن المتسللون آنذاك مهتمين بلعبة MMO مع شبكة اجتماعية يكون جمهورها الأساسي من الأطفال، كما أنها لم تكن بطبيعتها منصة عامة يمكن للآخرين البناء عليها.
إن الضغوط التقنية الرئيسية التي أواجهها تنبع من أن أحجام توليد البيانات الهائلة تجعل العقد التي تستضيف قاعدة البيانات تتحمل عبئًا شديدًا، ما يؤدي إلى تعطلها بشكل متكرر! وهذا يعني أنني أحتاج إلى تسجيل الدخول إلى البنية التحتية من وقت لآخر، وإيقاف العقد المتعطلة وإضافة عقد جديدة. ولحسن الحظ، فإن تشغيل ذلك ليس صعبًا: وبفضل آليات التسامح مع الأعطال، لا يلزم إنجاز هذه المهمة بشكل عاجل جدًا، كما أن هذه الخوادم “العادية المعدنية” يمكن لجهة مزوّد الخدمة السحابية لدي أن تُجري لها جدولة موحّدة……
تتبنى “Fight My Monster” بنية معمارية سبقت عصرها، ما مكنني من تحقيق التوسع بسهولة. بالإضافة إلى ذلك، فإن قدرتها على التعامل مع الأعطال، وبنيتها الخلفية البسيطة التي تضم ثلاثة مكونات أنظمة أساسية فقط، تعني أن عبء الأعمال الإدارية والضغط اللازمين لتشغيل النظام قد انخفضا إلى أدنى حد. إذن ما هذه “الدرس” المهم جدًا، لدرجة أنه لا يزال يؤثر حتى اليوم على طريقة تفكيري وعلى تطور ICP؟ لا بد أنك تشعر أن شيئًا غير عادي حدث في ذلك الوقت - واليوم سأروي لأول مرة علنًا تفاصيل تلك التجربة.
في ذلك الوقت، كنت أتنقل في أنحاء آسيا، كأحد أعضاء “فريق جولات” مجتمع الإيثيريوم الأساسي في بداياته، وأزور الأطراف المعنية (غالبًا ما يتم تجاهل الدور الداعم الذي لعبته آسيا - وخاصة الصين - في تطوير مجال العملات المشفرة المبكر)، كما كنت أشارك في مختلف الفعاليات المتعلقة بالإيثيريوم. في هذه اللقاءات، كان تركيزي الأساسي على بعض تقنيات علوم الحاسوب المعقدة التي طورتها بنفسي، بهدف تعزيز قابلية الشبكات مثل البيتكوين والإيثيريوم للتوسع وتحسين أدائها.
لا أرغب في الكلام المطوّل عن “سنوات زمان في عالم العملات المشفرة”، لكنني أقول إن تلك كانت فترة سحرية. لقد ترك لنا المشاركون الأوائل الكثير من الذكريات الجميلة، وعمري ما نسيت الامتنان لذلك. كانت التجربة مشوِّقة لدرجة جعلتني حتى بلا وقت لمراجعة البريد الإلكتروني.
وبالنتيجة، فقدت خلال رحلاتي عددًا لا يحصى من رسائل البريد الإلكتروني - كانت كلها تحذرني: إن بطاقة الائتمان المستخدمة لدفع رسوم عقد Cassandra الخاصة بمشروع Fight My Monster قد انتهت صلاحيتها……
حسنًا، ماذا فعل مزوّد السحابة حين لم أجب خلال بضعة أسابيع (لا أتذكر المدة بدقة، لكنها ليست طويلة)؟ ببساطة، قاموا بحذف جميع العقد!!!
يصعب وصف ما شعرت به عندما عدت إلى بالو ألتو في كاليفورنيا واكتشفت كل ما حدث. كان شعورًا مزيجًا من الصدمة والهلع: فراغ في المعدة، اندفاع الأدرينالين، والخوف ينتشر دون توقف. حاولت جاهدًا إنقاذ الموقف، لكن في النهاية تأكد لي أن كل شيء غير قابل للإصلاح. من مرّ بتجربة اختراقات قراصنة في مجال العملات المشفرة سيفهم بالتأكيد هذه المشاعر.
انتهى كل شيء بهذه الطريقة. لقد اختفى “Fight My Monster” تمامًا. وحتى في المجتمع، أطلق بعض الناس عريضة على Change.org طالبوا إعادة تشغيله.
رغم أنني فقدت القيمة التي كان من الممكن أن يخلقها، فقد شعرت بالذنب أيضًا، لكن في جزءٍ ما منحني ذلك شعورًا بالارتياح: لم يعد عليّ أن أتحمل مسؤولية صيانته (وإلا ربما كنت سأستمر بلا نهاية في الحفاظ عليه لصالح المجتمع). علاوة على ذلك، صار إرثًا جميلًا لأولاد الجيل الذين لعبوا تلك اللعبة (وكذلك لبعض البالغين)، وانتهت قبل أن تتحول إلى شيء قديم وممل. وهذا ما سمح لي بالتركيز على المجال الذي كنت مولعًا به آنذاك: شبكات الحوسبة اللامركزية.
لكنني استخلصت درسًا عميقًا جدًا من ذلك: يمكنك بناء بنية تحتية حوسبية لا مركزية قابلة للتوسع وقادرة على تحمل الأعطال، لكن طالما توجد نقطة فشل واحدة (single point of failure) في أي وقت وأي مرحلة، فقد ينهار النظام كله بالكامل.
لذلك، كلما سمعت عن بعض البلوك تشين التي تعتمد على مفاتيح مدير بحوزة مطورين أساسيين، أو سمعت عن أن عددًا كبيرًا من العقد يتم إيقافه بسبب إغلاق مزوّدي الخدمات السحابية أو أعطال تقنية (بل وقد اقتربت من الشلل)، أشعر دائمًا بقلق كبير. إن هذه الهشاشة الشديدة أكثر شيوعًا في صناعتنا بكثير مما قد تتخيل.
الدرس القاسي الذي نتج عن تجربة Fight My Monster ترك أثرًا عميقًا على فلسفة تصميم Internet Computer. الأهم ليس مجرد عدد العقد، بل عوامل أخرى أكثر جوهرية. فإذا كانت العقد مجهولة، فقد يكون عدد الكيانات المستقلة التي تشغّل غالبية العقد أقل بكثير مما تتوقعه. إضافةً إلى ذلك، وعلى الرغم من أن عدد العقد كبير، فإنها غالبًا تعمل على منصات لدى عدد قليل من مزوّدي خدمات السحابة. حتى لو كانت مملوكة ومدارة من كيانات مختلفة، فقد يقرر مزوّد السحابة فجأة التوقف عن دعمها وإغلاقها بين ليلة وضحاها (كما فعلت Hetzner مع مشروع بلوك تشين معروف).
في التطبيق الفعلي، ما يهم حقًا هو عدد الكيانات المستقلة التي تشغّل العقد، وكذلك مدى استقلالها من ناحية الموقع الجغرافي والاختصاص القضائي. وهذه الرؤية البسيطة هي حجر الأساس لفكرة “إزالة مركزية محدَّدة” (deterministic decentralization)، وهي الفكرة التي ستظهر بصيغة جديدة في الميزات التوسعية التي يستعد Internet Computer لطرحها ضمن “محركات سحابية” (ICP cloud engines).
تتيح محركات ICP السحابية للشركات (عادةً) إنشاء شبكات فرعية خاصة بها فعليًا على Internet Computer، والتحكم بنفسها في إعداداتها. ويمكن للشركات تجميع العقد عبر اختيارها من مجموعة عقد تعمل كنقطة “سوق”. حاليًا، هناك أكثر من 1500 عقد في وضع الاستعداد، ويستمر العدد في الزيادة.
تقدّم “المحركات” منصة سحابية خالية من الخوادم (serverless) بخصائص استثنائية، وهي المكان المثالي لبناء تطبيقات وخدمات الذكاء الاصطناعي. وذلك لأن مكدسها التقني مُصمم خصيصًا لدعم إنشاء برامج AIware متقدمة بسهولة وبأمان، كما تتمتع هذه التطبيقات بمرونة قوية جدًا.
تتمتع هذه التطبيقات بخصائص متعددة مثل: مقاومة العبث (أي تحصين ضد الهجمات على مستوى البنية التحتية)، والاتصال الدائم على مدار الساعة (وبالتالي مرونة عالية جدًا)، وتشغيل اختياري ذاتي (ما يعني عدم وجود أبواب خلفية)، ودعم أصيل للأصول الرقمية، وغيرها. كما يمكن للمحركات تشغيل تطبيقات AIware مثل حزمة Open SaaS، وتمكين الشركات من تنفيذ تشغيل أعمال متكامل من طرف إلى طرف. وتُسهّل محركات السحابة تثبيت وصيانة تطبيقات معقدة مثل Open CRM أو Open Email، حتى تصبح مثل تطبيقات الهاتف المحمول من حيث البساطة.
تدعم العقد “الاستبدال الحار” (hot plugging)، ما يعني أنه يمكنك تعديل عامل تكرار الحوسبة (compute replication factor) أو تغيير العقد دون إيقاف الخدمات التي تستضيفها محركات السحابة. وبهذا تتخلص من الاعتماد على مزوّد حوسبة بعينه. إضافةً إلى ذلك، يمكنك اختيار استخدام عقد جديدة يتم نشرها على مزوّدي السحابة العمالقة (hyperscalers)، وكذلك العقد التقليدية الخاصة بـ Internet Computer، وتحويل ذلك إلى سوق عام لموارد الحوسبة.
توجّه أطر محركات السحابة (Cloud Engine) المستخدمين إلى تجميع عقد تتمتع باستقلالية، وفي الوقت نفسه توفر مرونة لا توجد في الاستضافة المشتركة لـ Internet Computer. على سبيل المثال، قد تختار شركة ألمانية أن تستخدم عقدًا لا تكون موجودة إلا داخل الاتحاد الأوروبي من أجل الالتزام بـ GDPR (اللائحة العامة لحماية البيانات).
ومع ذلك، فإن وحدة التحكم الذاتية لمحرك سحابي تَستضيفه شبكة Internet Computer ويقوم NNS (الشبكة العصبية، أي DAO الأكثر تقدمًا عالميًا) بتحديثه، ستقدّم إرشادًا للمستخدمين. وإذا جمع المستخدمون عقدًا من مزوّد عقد واحد، أو عقدًا في مركز بيانات واحد، أو عقدًا تُشغَّل بواسطة مزوّد سحابة واحد، فستصدر وحدة التحكم تحذيرات قوية.
لذلك، حتى في سياق محركات ICP السحابية (Cloud Engines)، تظل الدروس المستفادة من مشروع “Fight My Monster” ذات معنى واقعي.
قد يتساءل الناس لماذا يدفع هذا الإطار بقوة لدمج كل عقد مستقلة معًا. في الحقيقة، هناك سبب كافٍ وراء ذلك - وسبب هذا الإطار مهم جدًا بالنسبة لمجتمع البلوك تشين الأوسع اليوم، تمامًا كما كان مهمًا في عام 2015.
أتطلع إلى مشاركة تفاصيل محركات السحابة معكم قريبًا.
محتوى IC الذي يهمك
تقدم تقني | معلومات عن المشروع | فعاليات عالمية
تابع واهتم بـ IC - قناة Binance
الحصول على أحدث المعلومات