Blockchain Sharing

مرحباً بالجميع ، أنا واحد من مطوري البرنامج "Near Protocol" ، والذي ينفذ ، من بين أشياء أخرى ، عملية المشاركة ، وفي هذه المقالة أود أن أخبر بالتفصيل عن ماهية المشاركة في blockchain ، وكيف تعمل ، ولمس عدد من المشاكل التي تنشأ عند محاولة بنائها.

من المعروف أن Ethereum ، منصة dApps الأكثر شعبية ، تعالج أقل من 20 معاملة في الثانية. نظرًا لهذا التقييد ، يكون سعر المعاملات ووقت تأكيدها مرتفعًا للغاية: على الرغم من حقيقة أن هناك كتلة يتم نشرها في Ethereum مرة واحدة كل 10-12 ثانية ، وفقًا لمحطة ETH للغاز ، فإن الوقت بين إرسال المعاملة وكيف يقع حقًا في الكتلة هو متوسط ​​1.2 دقائق لا يسمح النطاق الترددي المنخفض والأسعار المرتفعة وتأكيد المعاملة الطويل بإطلاق أي خدمات عالية الأداء على Ethereum.

السبب الرئيسي لعدم تمكن Ethereum من معالجة أكثر من 20 معاملة في الثانية هو أن كل عقدة في Ethereum يجب أن تحقق من كل معاملة. على مدار السنوات الخمس التي انقضت منذ إصدار Ethereum ، تم اقتراح العديد من الأفكار لحل هذه المشكلة. يمكن تقسيم هذه الحلول تقريبًا إلى مجموعتين: تلك التي تقدم لتفويض المعاملات إلى مجموعة صغيرة من العقد ذات أجهزة جيدة جدًا ، وتلك التي تقدم كل عقدة لمعالجة مجموعة فرعية فقط من جميع المعاملات. مثال على النهج الأول هو Thunder ، حيث يتم إنشاء الكتل بواسطة عقدة واحدة فقط ، والتي تسمح للمطورين ، باستلام 1200 معاملة في الثانية ، أي أكثر 100 مرة من Ethereum. أمثلة أخرى من الفئة الأولى هي Algorand و SpaceMesh و Solana . تعمل جميع هذه البروتوكولات على تحسين الجوانب المختلفة للبروتوكول وتتيح لك إجراء معاملات أكثر من مثيلاتها في Ethereum ، ولكن جميعها محدودة بسبب سرعة آلة واحدة (وإن كانت قوية جدًا).

الطريقة الثانية ، التي تعالج فيها كل عقدة مجموعة فرعية فقط من المعاملات ، تسمى المشاركة. هذه هي الطريقة التي تخطط بها مؤسسة Ethereum لزيادة عرض النطاق الترددي لـ Ethereum.

في هذا المنشور ، سوف أخبرك كيف تعمل Sharding في Blockchain باستخدام مثال على عدة بروتوكولات قيد التطوير حاليًا.

أسهل التقسيم

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

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

المصادقون التعيين و Blockchain الوسطى

المشكلة الأولى في حقيقة أن كل قشرة لها مصدقات خاصة بها هي أنه إذا كان لدينا 10 شظايا ، فإن كل قشرة أصبحت الآن أقل بعشرة أضعاف من كتلة بلوكشن واحدة. لذلك ، إذا قررت blockchain مع X Validators أن تصنع شوكة صلبة في نظام شارد بعشرة شظايا ، وتكسرت أجهزة X للتحقق من الصحة ما بين 10 شظايا ، الآن لا يوجد سوى X / 10 مصادقون في كل شارد ، ويتطلب السيطرة على شارد السيطرة على 5.1 ٪ (51 ٪ / 10) مصادقون.

مما يؤدي إلى أول سؤال مثير للاهتمام: من الذي يعين المدققين على القطع؟ إن التحكم في 5.1٪ من المدققين يمثل مشكلة فقط إذا كان كل 5.1٪ من المدققين في نفس القشرة. إذا لم يتمكن المدققون أنفسهم من اختيار القشرة التي تم تخصيصها لهم ، فإن السيطرة على 5.1٪ من المصادقين قبل تعيينهم إلى القطع لن تسمح لهم بالتحكم في أي شظايا.

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

يعتبر كل من استلام الأرقام العشوائية وتعيين أجهزة التحقق من الحسابات عبارة عن حسابات على نطاق المنظومة لا تخص أي قشرة معينة. لمثل هذه العمليات الحسابية ، تشتمل التصميمات الحديثة لـ blockchain على شكل شظية على blockchain مخصص إضافي موجود فقط لإجراء العمليات الحسابية على مستوى النظام. بالإضافة إلى الأرقام العشوائية وتعيين المدققين ، قد تتضمن هذه الحسابات الحصول على تجزئات الكتل الأخيرة من القطع وتخزينها ؛ معالجة الضمانات في أنظمة إثبات الملكية ، ودراسة الأدلة على السلوك غير السليم مع الاختيار المرتبط بهذه الضمانات ؛ إعادة التوازن بين القطع ، إذا تم توفير هذه الوظيفة. تُسمى هذه السلسلة blockchain منارة في Ethereum 2.0 و Near Protocol ، وسلسلة Relay في PolkaDot ، و Cosmos Hub في Cosmos.

في هذا المنشور ، سوف نسمي مثل هذا blockchain باسم "blockchain المركزي". يؤدي وجود blockchain المركزي إلى الموضوع التالي المثير للاهتمام - التدرج التربيعي.

التدرج التربيعي

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

دعونا نرى كيف يتغير إنتاجية النظام بأكمله إذا زادت قوة العقد الداعمة لها k مرة. سيكون بإمكان كل وحدة معالجة معاملات k مرة أكثر ، وستكون سلسلة المفاتيح المركزية قادرة على دعم عدد أكبر من عمليات k. وبالتالي ، فإن الإنتاجية للنظام بأكمله سوف تنمو ك ^ 2 مرات. ومن هنا جاءت تسميته "التربيع الترتيبي".

من الصعب التنبؤ بحجم القدر الذي يمكن أن يدعمه blockchain المركزي اليوم ، ولكن على الأرجح في المستقبل القريب ، لن نقترب من حد المعاملات لسلسلة blockchain مظلمة مع التقسيم التربيعي. على الأرجح ، سنواجه قريبًا حد عدد العقد اللازمة لدعم مثل هذا العدد من القطع.

تقاسم الدولة

الحالة هي كل المعلومات حول جميع الحسابات والعقود. لقد تحدثنا حتى الآن عن التقسيم بشكل عام ، دون تحديد ما هو التقسيم بالضبط. تنفيذ العقد في blockchain المهام الثلاثة التالية: 1) إجراء المعاملات 2) المعاملات إلى الأمام وكتل إلى العقد الأخرى و 3) تخزين حالة وتاريخ blockchain. يرتبط كل من هذه المهام الثلاث ببعض الحمل المتزايد على العقد:

1. الحاجة إلى إجراء المعاملات تتطلب المزيد من القوة الحاسوبية مع زيادة في عدد المعاملات ؛
2. تتطلب الحاجة إلى إعادة توجيه المعاملات مزيدًا من النطاق الترددي للشبكة أثناء نمو المعاملات ؛
3. تتطلب الحاجة إلى الحفاظ على الحالة والتاريخ مساحة أكبر على القرص مع زيادة حجم الحالة و / أو السجل. من المهم ملاحظة أنه ، على عكس النقطتين الأوليين ، ينمو مقدار مساحة القرص المطلوبة حتى إذا لم يتغير عدد المعاملات لكل وحدة زمنية.

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

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

على الرغم من اقتراح حالة الولاية بدون حسابات تظليل ، لا أعرف أي مشاريع تقوم بهذا بالفعل ، لذلك فإننا نفترض أن حالة الحالة تعني ضمنا عمليات مشاركة الحسابات.

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

معاملات بين الاسهم

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

للبساطة ، سننظر فقط في المعاملات التي تقوم بتحويل الأموال ، وسوف نفترض أن كل مشارك لديه حساب على قشرة واحدة بالضبط. إذا أراد أحد المشاركين في بعض القطع تحويل الأموال إلى مشارك في نفس القطعة ، فيمكن لمدققي هذه الشريحة معالجة هذه المعاملة وتطبيقها على الولاية. ولكن ، على سبيل المثال ، إذا كان لدى Alice حساب على shard # 1 وترغب في إرسال أموال إلى Bob من خلال حساب على shard # 2 ، فلا مصادقون على shard # 1 (الذين لا يمكنهم إضافة أموال إلى Bob) أو مصادقون على shard # 2 (الذين لا يمكنهم الحصول على أموال Alice ) لا يمكن إكمال المعاملة وتحديث الحالة.

هناك مجموعتان كبيرتان من الطرق لحل هذه المشكلة:

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

   
   

2. غير متزامن : يتم تنفيذ معاملة بين الأسهم على شكل شظايا تؤثر عليها ، بشكل غير متزامن: يتم تنفيذ جزء المعاملة الذي يضيف أموال إلى بوب في الجزء الثاني عندما يكون لدى المدققين في القشرة بعض الأدلة على أن جزء المعاملة الذي يطرح الأموال من أليس قد تم تنفيذه في قشرة # 1. هذا النهج أكثر شيوعًا في الأنظمة التي يتم تطويرها اليوم نظرًا لأنه لا يتطلب تزامنًا إضافيًا بين القطع لإنتاج القطع. يتم تقديم مثل هذه الأنظمة اليوم في Cosmos و Ethereum Serenity و Near Protocol و Kadena وغيرها. تكمن المشكلة في هذا الأسلوب في أنه إذا تم إنتاج الكتل بشكل مستقل ، فمن المحتمل ألا تكون إحدى الكتل التي تحتوي على تحديث حالة المعاملة في السلسلة المتعارف عليها في شظتها ، وبالتالي لن يتم إكمال المعاملة جزئيًا. على سبيل المثال ، النظر في الشكل أدناه. تُظهر هذه الأداة قطعتين من القطع التي حدثت فيها الشوكات ، ومعاملة بين القطع ، حيث ينعكس تحديث الحالة في المربعين A و X ، على التوالي. إذا تبين أن السلاسل AB و V'-X'-Y'-Z 'كانت متعارف عليها في شحذاتها ، فسيتم الانتهاء من المعاملة تمامًا. إذا كانت السلاسل A'-B'-C'-D 'و VX متعارف عليها ، فسيتم إلغاء المعاملة تمامًا ، وهو أمر مقبول. ولكن ، على سبيل المثال ، إذا أصبحت AB و VX متعارف عليها ، فسيتم إنهاء جزء من المعاملة ، ويتم إلغاء الجزء الآخر ، ويتم إكمال المعاملة جزئيًا.

   
   

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

سلوك سيء

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

فوركس المستهدفة

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

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

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

إنشاء كتل غير صالحة

إذا كان المشارك قادرًا على التحكم في عدد كبير بشكل كافٍ من أدوات التحقق في القشرة ، فيمكنه محاولة إنشاء كتلة غير صالحة تمامًا. على سبيل المثال ، لنفترض أنه قبل الحظر ، كانت الحالة بحيث يكون لدى Alice 10 رموز ، وفي Bob - 0 ، تحتوي الكتلة على معاملة واحدة فقط ، والتي ترسل 10 رموز من حساب Alice إلى حساب Bob ، ولكن في الحالة الجديدة ، تظهر 0 رموز من Alice ، و 1000 مع بوب.

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

يوضح الشكل أعلاه خمسة أجهزة تحقق ، ثلاثة منها تحت سيطرة المهاجم. قاموا بإنشاء الكتلة غير الصحيحة A '، ثم واصلوا بناء السلسلة على القمة. تجاهل مدققان خاصان على الفور المجموعة "أ" باعتبارها غير صالحة واستمروا في البناء على رأس آخر كتلة صالحة عرفوها ، وبالتالي خلق شوكة. نظرًا لوجود عدد أقل من المدققين في سلسلة صادقة مقارنة بسلسلة غير نزيهة ، فإن سلسلتهم أقصر. ومع ذلك ، في blockchain الكلاسيكية غير المقسمة ، يقوم جميع المشاركين في النظام بالتحقق من صحة جميع الكتل التي يرونها. وبالتالي ، فإن أي مشارك يستخدم blockchain سيرى أن A 'غير صالحة ، وتجاهلها ، وبالتالي تجاهل B' و C 'و D' كما هو مبني على الجزء العلوي من الكتلة غير الصالحة ، وبالتالي سيرى جميع المشاركين AB كسلسلة أساسية.

في تصميم قاطع ، لا يمكن لأي مشارك التحقق من صحة جميع الكتل في جميع block Blockins. - , , , - .

, , . , , ( ).

, :

1. - . , 2/3 . , , , . , , , - , . , .
2. - , , , , , . , zk-SNARKs ( zk, zero-knowledge, , non-zk SNARKs). , zk-SNARKs , .

, , , , . — .

اكتب الكثير عن blockchain و sharding باللغة الإنجليزية. نحن نقوم أيضًا بإجراء مقابلات دورية مع مؤلفي بروتوكولات أخرى مثل Cosmos و Solana ، حيث يتم البحث في التفاصيل الفنية. إذا كنت مهتمًا بالموضوع ، فيمكنك متابعة المنشورات ومقاطع الفيديو الجديدة عن طريق الاشتراك في TwitterAlexSkidanov .