هذا هو الجزء الأول من سلسلة من ثلاثة أجزاء يحدد فيها أندرو ليفين المشكلات التي تواجه سلاسل الكتل القديمة ويطرح حلولًا لهذه المشكلات. اقرأ الجزء الثاني حول أزمة التوسع الرأسي والجزء الثالث حول أزمة الحوكمة عند إطلاقهما في 24 و 25 سبتمبر.
نعتقد أن هناك ثلاث مشاكل أو أزمات أساسية تقف في طريق تبني blockchain: قابلية الترقية ، والتوسع الرأسي والحوكمة. في هذه المقالة ، سنستكشف أزمة قابلية الترقية وكيف يمكن أن تكون أنظمة تشغيل الكمبيوتر بمثابة تشبيه مفيد يحمل سر حل هذه الأزمة وتمكين blockchain من تحقيق التبني السائد.
أقوى مفهوم لفهم مشكلة قابلية الترقية هو “مقاومة الهشاشة”. مقترح من نسيم طالب ، مضاد الهشاشة هو خاصية للأنظمة التي تتحسن عند الضغط عليها. يمكن أن تبدو الأنظمة الهشة وكأنها تعمل بشكل رائع في معظم الأوقات ، ولكن عند الضغط عليها ، فإنها تنهار أو “تنفجر”.
Antifragility هي خاصية تنشأ من أنظمة هرمية متعددة الطبقات تحتوي على وحدات فرعية هشة تؤدي إلى نظام أكثر صحة بشكل عام عن طريق كسرها / احتضارها / تفجيرها. في الطبيعة ، نسمي هذه العملية التطور. يحدث التطور عندما يستبدل نوع ما سمة أقل نجاحًا بسمة أكثر نجاحًا. في مجال الحوسبة ، نطلق على هذه التحسينات اسم “ترقيات”.
تكمن مشكلة سلاسل الكتل الرئيسية التي نعرفها اليوم في أنها لم تكن مصممة للترقية ، مما يعني أنها لا تستطيع التطور. السبب وراء أهمية التطور هو أنه يمكّن الأنظمة من النجاة من “البجعات السوداء” ، وهي أحداث لا يمكن التنبؤ بها إلى حد كبير ولها عواقب وخيمة. لا تستطيع الأنظمة المضادة للكسر فقط النجاة من البجعة السوداء ، بل إنها تتحسن منها بالفعل.
في سلاسل الكتل ، لا توجد فعليًا طبقات منفصلة ذات أنظمة فرعية هشة تمكن من التكيف الصحي مع الضغوطات. بدلاً من التصميم من منظور التواضع ، يحاول المبدعون تقديم أنفسهم على أنهم حالمون معصومون من الخطأ صمموا نظامًا مثاليًا يستحق على الفور تقديرًا عاليًا.
رسم الخرائط قبل استكشاف المنطقة
لا يوجد دليل أكبر على ذلك من الاعتماد على الهارد فورك لترقيات النظام. الهارد فورك هو عكس مسار الترقية. إنه يطرح النظام القديم ويستبدله بنظام جديد.
ومع ذلك ، هناك جانب إيجابي لهذا التحليل ، وهو أن الحل لا يتعلق باختراق الحواجز التقنية بقدر ما يتعلق بكسر الحواجز النفسية. نحن لا نصمم blockchain من المبادئ الأولى ، ولكننا لا نزال نكرر بشكل أساسي فوق البنى الموجودة مسبقًا مثل تلك الموجودة في Bitcoin و Ethereum.
هناك العديد من الطرق لتطبيق blockchain ، لكننا غالبًا ما نفترض أن الطريقة التي تنفذ بها هذه البروتوكولات بعض مكونات blockchain هي افتراضيًا “الطريقة الصحيحة”. تؤطر هذه البروتوكولات تمامًا الطريقة التي ننظر بها إلى هذه القضايا ، مما يؤدي بنا إلى إنشاء “خرائط” ذهنية للمشكلات التي تم “رسمها” قبل أن نبدأ حتى في استكشاف هذه المنطقة الجديدة.
كانت Bitcoin و Ethereum في الأساس أول أجهزة كمبيوتر لا مركزية. كما هو الحال مع أي نموذج حوسبة جديد ، في المراحل المبكرة ، يركز المهندسون والمطورون اهتمامهم على ما إذا كان بإمكانهم استخدام التكنولوجيا لحل مشكلة معينة ، وإذا كان الأمر كذلك ، فاستخدمها لبناء تطبيقاتهم. لا توجد أدوات ولا منصات يمكنهم الاستفادة منها ، لذا يتعين عليهم بناء كل شيء من البداية وتحسين مكدسهم لتطبيقهم المحدد.
والنتيجة النهائية هي قطعة متجانسة من الكود تشغل تطبيقًا مصممًا لحل مشكلة معينة.
المحركات الأولى والأنظمة الهشة
يمكن أن تكون هذه التطبيقات المبكرة ناجحة جدًا بفضل ميزة المحرك الأول ، ولكن عندما يتعلق الأمر بتطوير البرامج ، فإن النجاح الذي يأتي من كونك المحرك الأول هو وهم. يجد المحركون الأوائل في البرنامج الميزات ، أو “السلوكيات” التي سيجدها المستخدمون أكثر قيمة ، وبالتالي التحقق من صحة التكنولوجيا الجديدة.
لكن الحفاظ على هذه الميزة يكاد يكون مستحيلًا لأن التطبيق مبني على جبل من التعليمات البرمجية القديمة التي لا يفهمها سوى قلة من الناس أو قادرون على ترقيتها. الأخطاء هي كابوس يجب إصلاحه ، ومجرد الحفاظ على الكود الموجود يصبح مهمة عبثية ؛ ننسى تحسينه.
في هذه المرحلة ، يمكن أن تموت التطبيقات لأي عدد من الأسباب ، ولكن السبب الأساسي للوفاة هو أنها هشة. البجعة السوداء التي أحدثت فسادًا في نهاية المطاف في التطبيقات الحالية هي تطوير نظام التشغيل. تجعل أنظمة التشغيل الأمر أسهل بالنسبة للمطورين لتشغيل نفس النوع من التطبيقات ، مع نفس السلوكيات الأساسية التي ظهرت في المحركات الأولى.
إن ظهور أنظمة التشغيل يمكّن التكنولوجيا من الارتقاء إلى المستوى التالي من خلال جعلها أسهل وأسرع للمطورين لإصدار برامج أفضل تخترق المزيد من السوق وتصل إلى المزيد من المستخدمين. بالإضافة إلى أنه يعطينا طبقة أخرى في المكدس. الآن ، إذا تم تفجير أحد التطبيقات ، تظل الطبقات السفلية الأكثر أهمية غير متأثرة.
إذن ، المشكلة حُلت ، أليس كذلك؟ بينما توفر أنظمة التشغيل من الجيل الأول ميزة تنافسية هائلة لمطوري التطبيقات الذين يتبنون الأنظمة المناسبة ، إلا أنهم يعانون أيضًا من نفس مشكلة قابلية الترقية لتطبيقات الجيل الأول. تظهر كوسيلة لتوفير الميزات الأساسية والأمان وقاعدة مستخدمين مشتركة ، ولكن ليس لزيادة قابلية الترقية. لذلك ، تصبح في النهاية منتفخة الميزات ومعقدة ويصعب ترقيتها.
تشبيه نظام التشغيل
تتطلب ترقية النظام عملية إعادة تشغيل النظام وإعادة التحميل التي تصبح أطول وأكثر إزعاجًا كلما زاد حجمها وتعقيدًا. بينما يتم عزل طبقة واحدة (نظام التشغيل) عن الأخطاء التي تحدث في طبقة أخرى (طبقة التطبيق) ، يظل نظام التشغيل نفسه هشًا.
تم تصميم Blockchains مثل Ethereum و EOS مثل أنظمة التشغيل المبكرة هذه. فهي توفر ميزات أساسية وأمانًا وقاعدة مستخدمين مشتركة و “مساحة مستخدم” قابلة للبرمجة يمكن للمطورين الاستفادة منها لإضافة الميزات المخصصة التي يحتاجونها لتشغيل تطبيقاتهم المحددة.
في حالة سلاسل الكتل ، يتم تضخيم المشاكل التي تصيب أنظمة تشغيل الجيل الأول بسبب الثبات ؛ يتزايد حجمها باستمرار ، مما يضع ضغطًا إضافيًا على البنية التحتية ويخلق تحديًا واضحًا للتوسع.
علاوة على ذلك ، نظرًا لأنها لا مركزية ، يجب أن تشق الترقيات طريقها من خلال عملية حوكمة تنتهي ، في أفضل الظروف ، في تنفيذ جهد منسق حيث تتوقف جميع أجهزة الكمبيوتر عن تشغيل البرنامج القديم وتبدأ في تشغيل البرنامج الجديد ( “شوكة” جديدة) في نفس الوقت بالضبط. هذا ليس بالأمر السهل ، وهذا هو السبب في أن وصفه بالشوكة “الصلبة” يعد مناسبًا بشكل خاص.
عندما تتطلب بعض التغييرات هارد فورك ، يضطر الأشخاص إلى تجميع هذه التغييرات لأن تنفيذها بشكل مجزأ سيؤدي إلى تعطل إضافي للشبكة. ينتج عن هذا “مشكلة راكب” مشابهة لما نراه في الأنظمة الحكومية حيث ترتبط التغييرات غير المرتبطة بالتغييرات المهمة. بعبارة أخرى ، هناك مركزية في الوقت المناسب مشكلة. لأن كل شيء مهم يجب القيام به في نفس الوقت ، ولأن الناس يختلفون حول ما هو مهم ، فإن اللحظة التي يجب فيها تنفيذ هذه التغييرات تخلق موجهًا للهجوم.
بغض النظر ، ينتهي الأمر بالشركات الصلبة إلى كونها كبيرة وسياسية ومحفوفة بالمخاطر ، والأهم من ذلك أنها تقضي على الشبكة! يؤدي هذا إلى إبطاء معدل التقدم بشكل كبير ، ولأن كل blockchain رئيسي يعمل بهذه الطريقة ، فإن القطاع ككل في حالة ركود.
الحماية من الهشاشة من خلال إمكانية الترقية
ما نحتاجه هو طبقة أخرى أسفل نظام التشغيل تمكن النظام بأكمله من التطور. في أنظمة التشغيل ، تسمى هذه الطبقة BIOS – نظام إدخال / إخراج أساسي. لكن من المهم أن نتذكر أننا نستخدم أنظمة التشغيل فقط كقياس. نحن بحاجة إلى بناء هذه الطبقة من المبادئ الأولى خصيصًا للاستخدام في سلاسل الكتل. يجب أن تتكون تلك الطبقة ، مثل أي طبقة أخرى ، من وحدات فرعية هشة يمكن أن “تنكسر” بطريقة ما دون تفجير النظام ككل.
كان إنشاء BIOS خطوة حاسمة لتعميم أجهزة الكمبيوتر لأنه مكّن المطورين من بناء واختبار وتكرار التطبيقات التي تجعل أجهزة الكمبيوتر الشخصية مفيدة للمستهلكين العاديين.
إذا أردنا تجاوز تلك الهوة نفسها ، فنحن لا نحتاج فقط إلى نظام تشغيل بلوكشين أفضل ، بل نحتاج إلى نظام تشغيل مبني على مكافئ BIOS لغرض محدد وهو قابلية الترقية.
يجب أن نكون قادرين على إضافة أي ميزة على blockchain دون الحاجة إلى شوكة صلبة. سيمكن ذلك blockchain من التكيف مع الضغوطات (الهجمات ، الأخطاء ، الميزات المفقودة ، إلخ) ، وتحسين نفسها ، وتوسيع نطاقها لتلبية احتياجات الجماهير.
حتى يأتي ذلك اليوم ، ستستمر جودة التطبيقات المستندة إلى blockchain في الركود ، وستظل المساحة تحت سيطرة المشاريع التي قد تبدو وكأنها تعمل على السطح ولكنها لم يتم تبنيها على نطاق واسع ، وهي هشة بطبيعتها وستكون كذلك اليوم “تفجير”.
الآراء والأفكار والآراء الواردة هنا هي آراء المؤلف وحدها ولا تعكس بالضرورة وجهات نظر وآراء كوينتيليغراف أو تمثلها.
أندرو ليفين هو الرئيس التنفيذي لشركة OpenOrchard ، حيث قام هو وفريق التطوير السابق وراء Steem blockchain ببناء حلول قائمة على blockchain تمكن الأشخاص من تولي زمام الأمور والتحكم في ذواتهم الرقمية. منتجهم الأساسي هو Koinos ، وهو blockchain عالي الأداء مبني على إطار عمل جديد تمامًا مصمم لمنح المطورين الميزات التي يحتاجون إليها من أجل تقديم تجارب المستخدم اللازمة لنشر اعتماد blockchain على الجماهير.
