هذا هو الجزء الثاني من سلسلة من ثلاثة أجزاء يحدد فيها أندرو ليفين المشكلات التي تواجه سلاسل الكتل القديمة ويطرح حلولاً لهذه المشكلات. اقرأ الجزء الأول على أزمة الترقية هنا والجزء الثالث حول أزمة الحوكمة فور إطلاقها في 25 سبتمبر.
كشف ظهور الإنترنت أن لدينا شخصية رقمية يمكنها تضخيم قوتنا في العالم الحقيقي بفضل القدرة على التفاعل مع الناس في أي مكان على الأرض وتنسيق الإجراءات التي لم تستطعها أنفسنا المادية.
لكن أنفسنا الرقمية مقيدة – مسجونون على أجهزة كمبيوتر خاصة تابعة لفيسبوك ، وجوجل ، وأمازون ، ونتفليكس ، وتويتر ، والقائمة تطول. هذه الاحتكارات الخاصة لا تنتج التكنولوجيا في الواقع. بالأحرى ، منتجهم هو نحن – ذواتنا الرقمية – والغرض بأكمله هو استخراج أكبر قدر ممكن من القيمة منا.
يدرك العديد من الأشخاص إمكانية قيام تقنية blockchain بتعطيل هذه الاحتكارات الخاصة واحتكارات القلة ، ولكن لسوء الحظ ، لم يتمكن أي blockchain محدد من تجاوز جدران مجتمع blockchain و cryptocurrency الحالي.
وإذا كان الأمر كذلك ، فلن يكون قادرًا تقنيًا على دعم نوع النمو والتبني اللازمين لتمكين كل شخص على وجه الأرض من السيطرة على ذواتهم الرقمية. لماذا هذا؟ هل الأمر يتعلق فقط باختيار الميزات الصحيحة؟ التحول إلى إثبات الحصة؟ تجزئة؟
لسوء الحظ ، فإن المشكلة أكبر بكثير من ميزة واحدة أو ميزتين مفقودتين ولن يتم حلها بالتغييرات المخططة على البروتوكولات الحالية لأن المشاكل تكمن في أساس كيفية إنشائها. يحد التصميم ذاته من إمكانية توسيع نطاق هذه المنصات عموديًا.
ما هو المقياس الرأسي؟
المقياس الرأسي هو كيفية إدارة نمو عقدة واحدة (كمبيوتر) في الشبكة. بلوكشين هي قواعد بيانات لا تتجاهل المعلومات أبدًا. تتم إضافة المعلومات إلى قاعدة البيانات فقط ، ولا تتم إزالتها أبدًا. هذا يجعل النمو مشكلة أكبر. ليس هذا فقط ، ولكن معظم سلاسل الكتل غير مصممة للاستفادة الفعالة من الأجزاء المختلفة للكمبيوتر. هذا يضيف إلى قاعدة بيانات كبيرة ، ويستهلك الكثير من الموارد الحسابية على جهاز معين بطريقة غير فعالة.
من أجل التعويض عن أوجه القصور هذه ، يعتمد مشغلو العقد على أجهزة باهظة الثمن على مستوى المؤسسات – على وجه التحديد ، ذاكرة الوصول العشوائي أو ذاكرة الوصول العشوائي والذاكرة السريعة غير المتطايرة أو NVMe ، وهو ما يدفع مشاركة الشبكة (تشغيل العقدة) إلى ما وراء فهم الناس العاديين. وبطريقة ما ، من المفترض أن نصدق أن هذا ليس بالأمر السيئ لللامركزية!
لكن تجزئة!
ومن المفارقات ، أن أحد أقوى الحجج لوجود أزمة تحجيم رأسي هو مستوى الطلب على حلول القياس الأفقي.
حتى كتابة هذه السطور ، لا تزال عقدة Ethereum الكاملة لا تتجاوز 500 جيجا بايت. هذا لا شيء! ومع ذلك ، فمن الصحيح تمامًا أنه يجب إضافة آلية معقدة ومحفوفة بالمخاطر إلى Ethereum بحيث يمكن تقسيم blockchain إلى أجزاء وأجزاء ، ويجب إنفاق الموارد الحسابية الثمينة على تمكين هذه “القطع” التواصل مع بعضهم البعض ، ناهيك عن إجراء حسابات ذات مغزى.
تكمن المشكلة في أن القياس الأفقي – التجزئة – ليس بديلاً عن القياس الرأسي. تخيل أن لديك مصنعًا ينتج 1000 سيارة سنويًا ، لكن هناك طلبًا كافيًا على 2000 سيارة. ماذا تفعل أولاً: بناء مصنع جديد أو محاولة صنع المزيد من السيارات من المصنع الذي لديك بالفعل؟ يعمل التوسع الرأسي على تحسين المصنع لإنتاج المزيد من السيارات قبل مجرد بناء مصنع جديد. عُقد Blockchain هي “المصنع” ، وما يحدد مخرجاتها هو مدى كفاءة استخدامها للمكونات في الكمبيوتر.
عند الحديث من التجربة المباشرة ، فإن البلوكشين غير مُحسَّنة بشكل رهيب فيما يتعلق بإدارة موارد العقد ، مما يجعلها المرشح المثالي لحلول التوسع الرأسي.
في blockchain ، هناك سلالتان أساسيتان: Ethereum و BitShares. قد لا يكون الكثير من الأشخاص على دراية بـ BitShares ، ولكن تصميمها المعماري يدعم بعض سلاسل الكتل الأكثر أداءً في الفضاء ، بما في ذلك EOS و Hive و Steem. بينما تظل Ethereum والعديد من السلاسل التي تم تصميمها على غرار blockchain الأكثر قيمة للأغراض العامة مع أكثر التطبيقات اللامركزية والمستخدمين الفريدين ، فإن خط BitShares على الإطلاق يهيمن من حيث نشاط الصفقات الأولية ، مما يجعلها ملك الأداء.
يمكن القول إن فريقي لديه خبرة أكبر في خط BitShares أكثر من أي فريق آخر على الأرض ، لذلك سنركز على هذا التصميم. نظرًا لأن blockchains في خط BitShares قادر على إجراء العديد من المعاملات في الثانية ، فإن هذا يزيد في الواقع من أهمية القياس الرأسي – لأن حالة blockchain الخاصة بهم تنمو بشكل أسرع.
التحجيم العمودي وذاكرة الوصول العشوائي والشوكات
المقياس الرأسي ، في سياق الحوسبة ، يتعلق أساسًا باستخدام أرخص أشكال الذاكرة (القرص) كلما أمكن ذلك وإلى أقصى حد ممكن. في حالة سلاسل الكتل ، فإن العمليتين الأكثر صلة هما دقة الشوكة وحالة التخزين. توجد كل هذه الإصدارات المختلفة من قاعدة البيانات (“forks”) ، ويجب أن تتوصل العقد إلى توافق في الآراء بشأن أيها “صحيح”. هذا شوكة القرار.
الآن ، لديك قاعدة بيانات لا رجعة فيها تحتاج إلى تخزين. من الناحية المثالية ، تريد تخزينه على أرخص وسيط ممكن (قرص) بدلاً من أغلى (RAM).
نظرًا لأنك تريد حل التفرع في أسرع وقت ممكن ، فأنت تريد إجراء هذه الحسابات في ذاكرة الوصول العشوائي (ذاكرة سريعة). ولكن بمجرد حل التفرع وإضافة المعاملات الجديدة إلى الحالة التي لا رجوع فيها ، فأنت تريد تخزين قاعدة البيانات هذه في القرص. تكمن مشكلة blockchain من خط BitShares في أنها تحقق أدائها من خلال تصميم لا يعكس في الواقع الحالة الحالية لـ blockchain. بدلاً من ذلك ، عندما يتم تطبيق كل كتلة ، يتم “التراجع” عن حالة المعاملة المعلقة ، وتتم إعادة كتابة القيم القديمة إلى قاعدة البيانات ، ثم يتم تطبيق الكتلة.
تتمثل إحدى مشكلات هذا النهج في أنه في معظم الأحيان ، يعني ذلك إجراء نفس الحسابات مرة أخرى وإعادة كتابة الحالة نفسها إلى قاعدة البيانات التي كانت موجودة هناك ، وهو أمر غير فعال للغاية.
القراءة والكتابة: الحساب
والأكثر صلة بمسألة القياس الرأسي هو أن هذا التصميم يعني أنه لا يمكن تخزين الحالة التي لا رجعة فيها ككل على القرص دون الحاجة إلى “إخراج” الكتل من القرص إلى ذاكرة الوصول العشوائي لحل التفرع. لا يؤدي هذا فقط إلى زيادة تحميل ذاكرة الوصول العشوائي على عقدة معينة ، ولكن له أيضًا عواقب وخيمة للغاية فيما يتعلق بالاستفادة من RocksDB.
RocksDB هي تقنية قاعدة بيانات تم تطويرها بواسطة Facebook لتشغيل موجز الأخبار الخاص بها. باختصار ، يمكننا الحصول على أداء ذاكرة الوصول العشوائي ولكن من القرص. تستخدم العديد من مشاريع blockchain RocksDB بطرق مختلفة ، لكن المشكلة في تصميم قاعدة البيانات التي أوضحناها هي أن الحاجة المستمرة للتراجع عن المعاملات المعلقة وإعادة الكتابة إلى قاعدة البيانات تلغي فوائد RocksDB.
موجز أخبار Facebook هو كل شيء عن قراءات قاعدة البيانات. ضع في اعتبارك عدد المشاركات التي تقوم بالتمرير خلالها قبل التعامل مع واحدة. لهذا السبب ، تم تصميم RocksDB للعمل بشكل أفضل عندما يكون هناك عدد من القراءات في قاعدة البيانات أكثر بكثير مما يكتب. يؤدي تصميم قاعدة البيانات الموضح أعلاه إلى العديد من عمليات الكتابة في قاعدة البيانات التي تنفي فوائد استخدام RocksDB.
من أجل الاستفادة الكاملة من RocksDB ، نحتاج إلى إعادة بناء blockchain من الألف إلى الياء لنقل الكتل بكفاءة من ذاكرة الوصول العشوائي إلى القرص مع تقليل عدد عمليات الكتابة للاستفادة من RocksDB. يمكننا تحقيق ذلك من خلال التخلص من الحاجة إلى التراجع / إعادة الكتابة وإنشاء قاعدة بيانات واحدة تتعقب حالة لا رجوع فيها ولا تحتاج أبدًا إلى التراجع عنها.
سيمكننا ذلك من تقليل استخدام ذاكرة الوصول العشوائي في العقد عن طريق نقل الكتل التي لا رجعة فيها من ذاكرة الوصول العشوائي إلى القرص بكفاءة دون الحاجة إلى إعادتها. نقدر أن هذا قد يقلل من تكلفة تشغيل العقدة بنسبة تصل إلى 75٪! لن يؤدي هذا فقط إلى تسهيل الوصول إلى تشغيل العقدة ، مما يؤدي إلى زيادة عدد العقد قيد التشغيل ، ولكن سيتم نقل وفورات التكلفة هذه في النهاية إلى المستخدمين والمطورين.
الحد من بلوكشين أو بلوكشين غير محدود؟
تصل blockchains الحالية إلى حدود الأداء لما يمكنهم الحصول عليه من عقدة واحدة نتيجة لكيفية حلهم للتشعب وكيفية تخزين حالة blockchain الخاصة بهم. في هذه المقالة ، أوضحنا كيف يمكن أن يؤدي تصميم قاعدة البيانات إلى عملية تحليل مفترق تزيد من استخدام ذاكرة الوصول العشوائي وكذلك عمليات الكتابة في قاعدة البيانات التي تنفي الفوائد التي يمكن أن تتحقق من استخدام RocksDB ، مما يؤدي في النهاية إلى عقد أقل كفاءة من blockchain
الحقيقة هي أن هناك الكثير من التحجيم الرأسي أكثر من هذه المشكلة الفردية. تعتبر أنظمة Blockchain البيئية معقدة ، مع العديد من المكونات التي تتفاعل مع بعضها البعض. يعد تقليل تكلفة تشغيل عقدة فردية أمرًا بالغ الأهمية لزيادة عدد العقد قيد التشغيل وتقليل تكاليف استخدام الشبكة ، ولكن هناك أيضًا مكاسب هائلة يمكن تحقيقها من خلال تقليل ازدحام الشبكة ، وتحفيز تشغيل العقدة بكفاءة والمزيد.
هدفنا ليس أن نشرح بالتفصيل كيف يمكن للمرء أن يحل مشكلة القياس الرأسي ولكن لإعطاء نظرة ثاقبة لطبيعة ما نعتقد أنه مشكلة لا تحظى بالتقدير بشكل كبير في فضاء blockchain. تعد قابلية التوسع الأفقي مجالًا مهمًا للغاية من مجالات الاهتمام ، ولكن إذا تجاهلنا مشكلة قابلية التوسع الرأسي ، فكل ما سنحققه من خلال القياس الأفقي هو زيادة عدد العقد غير الفعالة بشكل رهيب.
الآراء والأفكار والآراء الواردة هنا هي آراء المؤلف وحدها ولا تعكس بالضرورة وجهات نظر وآراء كوينتيليغراف أو تمثلها.
أندرو ليفين هو الرئيس التنفيذي لشركة OpenOrchard ، حيث قام هو وفريق التطوير السابق وراء Steem blockchain ببناء حلول قائمة على blockchain تمكن الأشخاص من تولي زمام الأمور والتحكم في ذواتهم الرقمية. منتجهم الأساسي هو Koinos ، وهو blockchain عالي الأداء مبني على إطار عمل جديد تمامًا مصمم لمنح المطورين الميزات التي يحتاجون إليها من أجل تقديم تجارب المستخدم اللازمة لنشر اعتماد blockchain على الجماهير.
