كيفية قياس Ethereum: شرح تقاسم

محدث ليعكس أحدث التغييرات البحثية في Ethereum 2.0!

مناقشة قابلية التوسع في مقدمة ووسط مجتمع التشفير. نظرًا لوجود حوادث كبرى مثل كارثة Cryptokitties التي تسد شبكة Ethereum بأكملها على مدار بضعة أيام ، فمن المعروف أن أكبر سلاسل الحظر العامة في حالتها الحالية لا تتوسع.

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

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

مع استمرار ارتفاع عدد المعاملات على Ethereum ، ليس لدينا وقت نضيعه. هيا بنا نبدأ.

ما هو Sharding؟

في الوقت الحالي ، يتعين على كل عقدة واحدة تدير شبكة Ethereum معالجة كل معاملة منفردة تمر عبر الشبكة. يمنح هذا blockchain قدرًا كبيرًا من الأمان بسبب مقدار التحقق من الصحة الذي يذهب إلى كل كتلة ، لكن في الوقت نفسه ، يعني ذلك أن blockchain كاملًا يكون بنفس سرعة العقد الفردية وليس مجموع أجزائها. حاليًا ، المعاملات على EVM غير قابلة للمقارنة ، ويتم تنفيذ كل معاملة بالتسلسل على مستوى العالم. تتعلق مشكلة القابلية للتوسعة بعد ذلك بفكرة أن blockchain يمكن أن يحتوي على أكثر من 2 من هذه الخصائص الثلاثة:

  • لامركزية
  • Scalabiltity
  • الأمان

إذا كان لدينا قابلية التوسع والأمان ، فهذا يعني أن كتلة سلسلة المفاتيح الخاصة بنا مركزية ومن شأنها أن تتيح لها إنتاجية أسرع. صحيح لا ، Ethereum غير مركزية وآمنة.

كيف يمكننا كسر هذه المعضلة لتشمل قابلية التوسع في النموذج الحالي؟ حسنًا ، لا يمكننا زيادة حجم الكتلة ، أو في حالة Ethereum ، GAS_LIMIT ، لزيادة الإنتاجية؟ في حين أنه من الناحية النظرية ، يمكن أن يكون هذا هو النهج الصحيح ، فكلما واصلنا زيادته ، سيتم تركيز المزيد من التعدين حول العقد التي تعمل على أجهزة الكمبيوتر العملاقة والتي من شأنها أن توفر حاجزًا أعلى للدخول إلى النظام.

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

قبل أن نتعمق في كيفية عمل blockchain الحاد بالفعل ، دعنا ننتقل إلى بعض المفردات المهمة:

  • الحالة: مجموعة المعلومات الكاملة التي تصف النظام في أي وقت. في Ethereum ، هذا هو الحساب الجاري الذي يحتوي على الأرصدة الحالية ورمز العقد الذكي وغيره في لحظة معينة. كل معاملة تغير هذه الحالة إلى حالة جديدة تمامًا.
  • المعاملة: العملية التي يصدرها المستخدم والتي تغير حالة النظام
  • Merkle Tree: بنية بيانات يمكنها تخزين كمية كبيرة من البيانات عبر تجزئة التشفير. تسهل أشجار Merkle التحقق مما إذا كانت جزءًا من البيانات جزءًا من البنية في فترة زمنية قصيرة جدًا وجهد حسابي.
  • الإيصال: أحد الآثار الجانبية لمعاملة غير مخزنة في حالة النظام ، ولكن يتم الاحتفاظ به في شجرة Merkle بحيث يمكن التحقق من وجودها بسهولة إلى عقدة. يتم الاحتفاظ بسجلات العقود الذكية في Ethereum كإيصالات في Merkle Trees ، على سبيل المثال.

مع وضع ذلك في الاعتبار ، دعونا نلقي نظرة على كيفية عمل Ethereum 2.0. سنقوم بإنشاء جانب جانبي يُعرف بسلسلة منارات عشوائية تقوم بتخزين التجزئة على كتل السلسلة الرئيسية في كتلها الخاصة. سيكون هذا النظام الجانبي بمثابة دليل إثبات كامل على تطبيق Casper FFG وسيوفر مصدرًا للعشوائية الموزعة التي ستتيح لنا بناء نظام مشاركة أعلى منه.

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

الاعتمادات هسياو وى وانغ

تقترح الأسئلة الشائعة حول المشاركة في Ethereum Wiki أخذ عينات عشوائية من المدققين على كل قشرة. والهدف من ذلك هو أن هؤلاء المدققين لن يعرفون أي قشرة سيحصلون عليها مقدمًا. ستحصل كل مجموعة على مجموعة من المصادقين ، وسيتم اختيار العينات التي سيتم التحقق منها بشكل عشوائي من تلك المجموعة.

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

في كل قشرة ، سيكون لدينا عُقد تسمى مقدمو الطلبات تكون مهمتها إنشاء ارتباط تبادلي على سلسلة المنارات ، وهي بنية محددة تشمل معلومات مهمة حول القشرة المعنية.

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

  • معلومات حول ما يقابله ترتيب النسخ (دعنا نقول shard 10)
  • معلومات حول الحالة الحالية للقشرة قبل تطبيق جميع المعاملات
  • معلومات حول حالة حالة القشرة بعد تطبيق جميع المعاملات
  • كانت التواقيع من 2/3 على الأقل من جميع المصادمين على القشرة التي تؤكد كتل القشرة شرعية

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

الفكرة الأولية هي استخدام مفهوم الإيصالات لهذا النظام للعمل.

راؤول (عنوان على Shard 1) يريد إرسال 100 ETH إلى Jim (عنوان على Shard 10)

  1. يتم إرسال معاملة إلى Shard 1 مما يقلل من رصيد Raul بمقدار 100 ETH وينتظر النظام المعاملة
  2. ثم يتم إنشاء إيصال للمعاملة التي لم يتم تخزينها في الدولة ولكن في جذر Merkle التي يمكن التحقق منها بسهولة
  3. يتم إرسال معاملة إلى Shard 10 بما في ذلك إيصال Merkle كبيانات. Shard 10 يتحقق مما إذا كان هذا الإيصال لم يتم إنفاقه بعد
  4. يعالج Shard 10 المعاملة ويزيد رصيد Jim بمقدار 100 ETH. ثم يحفظ أيضًا حقيقة أن الإيصال من Shard 1 قد تم إنفاقه
  5. ينشئ Shard 10 إيصالًا جديدًا يمكن استخدامه بعد ذلك في المعاملات اللاحقة

هذا يبدو معقدًا للغاية لفهم Devs Devit ومستخدمي Ethereum! كيف سنقوم بتعليمهم على المشاركة؟

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

بعد القياس: مشاركة فائقة التربيع ومكاسب سرعة لا تصدق

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

الموارد وأين تبدأ

حسنًا ، فأنت الآن تريد البدء في ترميز blockchain المظلمة! كيف تبدأ؟ على المستوى الأساسي ، لن ينجح التنفيذ الأولي المقترح من خلال شوكة صلبة ، بل يعمل في جانب المسار المعروف باسم سلسلة منارات عشوائية ستكون بمثابة دليل على نظام الحصص + المشاركة.

ستقوم سلسلة المنارات هذه بإدارة المدققين وأخذ عيناتهم من مجموعة مصادقة عالمية وستتحمل مسؤولية المصالحة العالمية لجميع حالات القطع. حدد Vitalik مستندًا مرجعيًا رائعًا لتنفيذ التقسيم هنا: https://ethresear.ch/t/convenience-link-to-full-casper-chain-v2-spec/2332/4

لاستكشاف بنية سلسلة المنارة هذه بالتفصيل ومعرفة المزيد عن كيفية عمل النظام ، تحقق من الموارد التالية:

  • مشاركة الأسئلة الشائعة: https://github.com/ethereum/wiki/wiki/Sharding-FAQ
  • المشاركة في Go: https://github.com/prysmaticlabs/geth-sharding
  • ملخص سلسلة أبحاث منارة: https://docs.google.com/document/d/19KyosgCFdsv_UzVdaApmIr0zh37Va0Tck1cca5uEtss/edit#

هل تريد الانضمام إلى فريقي؟

هل أنت على دراية بالأعمال الداخلية لبروتوكول Ethereum؟ هل أنت مطور جولانج؟ هل ترغب في العمل معي ومع فريق من المطورين لبناء أول عميل مشاركة لـ Ethereum 2.0؟ تحقق من Prysmatic Labs ، وهو فريق تموله مؤسسة Ethereum لتنفيذ التقسيم.

تحقق من إرشادات المساهمة ومشاريعنا المفتوحة على جيثب. يتم تجميع كل مهمة ومشكلة في المرحلة الأولى من المرحلة مع مشروع محدد ينتمي إليه (سلسلة منارات ، مهام عقدة المصادقة ، وما إلى ذلك).

كما هو الحال دائمًا ، تابعنا على Twitter ، أو أرسل لنا خطا هنا أو على دردشة Gitter ، وأخبرنا بما تريد مساعدته - نحن بحاجة إلى كل التعاون الذي يمكننا الحصول عليه