شاردوم والحالة الديناميكية لمشاركة: إمكانية أخرى للمشاركة
في 15 سبتمبر 2022، أكملت إيثيريوم الدمج المنتظر منذ فترة طويلة (Merge). كانت هذه لحظة تاريخية، حيث استعدت إيثيريوم لذلك لمدة 5 سنوات، وتم تأجيله 6 مرات. بسبب عمليات التصحيح المتكررة والتطوير الطويل الأمد، اعتقد الكثيرون أن الدمج سيؤدي بشكل طبيعي إلى زيادة القابلية للتوسع والأمان والاستدامة، ولكن هذا ليس صحيحًا. الانتقال من PoW إلى PoS هو مجرد تغيير للمسار والعجلات، ولن يؤدي مباشرة إلى سرعة أكبر أو سعة أكبر أو رسوم أقل. ما يمكنه تحقيق ذلك هو مجموعة كاملة من الحلول: شبكة رئيسية تمتلك قدرة المشاركة جنبًا إلى جنب مع حلول Layer2 المعززة للقابلية للتوسع.
كما أشار مؤسس الإيثيريوم فيتالك بوتيرين، فإن المشاركة هي حل للتوسع تحت معضلة قابلية التوسع، من خلال تقسيم العقد في الشبكة إلى مجموعات أصغر، ومعالجة مجموعات مختلفة من المعاملات وتحقيق المعالجة المتوازية. من خلال تخفيف عبء معالجة كمية كبيرة من البيانات المطلوبة لتجميعها عبر الشبكة بأكملها، تمامًا كما نفعل عند التسوق في السوبر ماركت والدفع، من خلال فتح المزيد من قنوات الدفع، يمكن تقليل أوقات الانتظار وزيادة كفاءة الدفع.
هذه هي منطق المشاركة، مباشر وبسيط، ومع ذلك، الشيطان يكمن في التفاصيل. المبادئ والاتجاهات صحيحة، لكن تنفيذها دائماً ما يواجه العديد من المشكلات. تهدف هذه المقالة إلى توضيح الاتجاهات والمآزق على طريق "المشاركة"، ورسم خريطة لمستكشفي المشاركة الذين يتطلعون إلى النجوم ويعيشون على الأرض. في الوقت نفسه، من خلال مقارنة الحلول الحالية للمشاركة، سيتم العثور على بعض المشكلات المشتركة، واقتراح اتجاه استكشاف قابل للتطبيق: Shardeum والمشاركة الديناميكية.
1. حول "مشاركة"
باختصار، بالنظر إلى قيود مثلث المستحيل، انطلاقًا من إيثريوم كنقطة الأصل (، 0،0)، وفقًا لفكرتين "رأسي" و"أفقي"، نقسم طرق قابلية التوسع الحالية في blockchain إلى فئتين رئيسيتين:
التوسع العمودي(Vertical Scaling): يتم تحقيقه من خلال تحسين أداء الأجهزة الحالية للنظام. إنشاء شبكة لامركزية حيث يمتلك كل عقدة في الشبكة قدرة حوسبة فائقة، مما يعني أن كل عقدة تحتاج إلى "أفضل" الأجهزة. هذه الطريقة بسيطة وفعالة، ويمكن أن تحقق تحسينًا أوليًا في قدرة المعالجة، وخاصة في تطبيقات مثل التداول عالي التردد، والألعاب، وغيرها من السيناريوهات الحساسة للزمن. ومع ذلك، فإن هذه الطريقة للتوسع ستقيد مستوى اللامركزية للشبكة، حيث تزداد تكلفة تشغيل العقدة المُصادقة أو العقدة الكاملة. إن الحفاظ على مستوى اللامركزية محدود بسرعة النمو التقريبي لأداء الأجهزة الحاسوبية( وهذا هو ما يسمى بـ"قانون مور": عدد الترانزستورات على الرقاقة يتضاعف كل عامين، بينما تتناقص تكاليف الحوسبة إلى النصف).
التوسع الأفقي(Horizontal Scaling): هناك عدة أفكار حول التوسع الأفقي. واحدة هي في سياق blockchain، حيث يتم توزيع حجم المعاملات في نظام بيئي معين على عدة blockchains مستقلة، حيث تمتلك كل سلسلة منتجي كتلها وقدرتها التنفيذية الخاصة، وهذه الطريقة تسمح بتخصيص كامل لطبقة التنفيذ لكل سلسلة، مثل متطلبات الأجهزة للعقد، وظائف الخصوصية، رسوم الغاز، الآلات الافتراضية وإعدادات الإذن وغيرها. خيار آخر للتوسع الأفقي هو blockchain المودولاري، حيث يتم تقسيم بنية blockchain الأساسية إلى طبقة تنفيذ، وطبقة توفر البيانات(DA) وطبقة إجماع. آلية المودولار الأكثر شيوعًا في blockchain هي rollup. وهناك خيار آخر هو تقسيم سلسلة blockchain إلى العديد من المشاركات، وتنفيذها بالتوازي. يمكن اعتبار كل مشاركة كـ blockchain، مما يعني أنه يمكن تنفيذ العديد من blockchains بالتوازي. بالإضافة إلى ذلك، عادة ما سيكون هناك سلسلة رئيسية، والتي تكون مهمتها الوحيدة هي الحفاظ على تزامن جميع المشاركات.
من المهم الإشارة إلى أن أفكار التوسع المذكورة أعلاه ليست قائمة في عزلة، بل كل حل هو نقطة توازن موجودة في مثلث مستحيل، مصممة بالتعاون مع آليات التحفيز التي تخلقها القوى الاقتصادية في النظام، لتحقيق توازن فعال على المستويين الكلي والجزئي.
للمناقشة حول "مشاركة"، نحتاج إلى إعادة تنظيم الأمور من البداية.
لا يزال نفترض هذا السيناريو، عند دفع ثمن التسوق في السوبرماركت، من أجل تحسين كفاءة الدفع وتقليل وقت انتظار العملاء، قمنا بتوسيع من ممر دفع واحد إلى 10 نوافذ دفع، لتجنب أخطاء السجلات، في هذه المرحلة، نحتاج إلى وضع قواعد موحدة:
أولاً، إذا كان لدينا 10 صرافين، كيف نقوم بتوزيعهم على أي نافذة للعمل؟
ثانياً، إذا كان لدينا 1000 عميل في انتظار، كيف نقرر أي عميل يذهب إلى أي نافذة للدفع؟
ثالثًا، كيف يمكن تلخيص دفاتر الحسابات العشرة الفردية المرتبطة بهذه النوافذ العشرة؟
رابعًا، كيف يمكن تجنب الأخطاء من قبل أمين الصندوق لتفادي حدوث عدم تطابق في الحسابات؟
هذه الأسئلة تتعلق في الواقع بعدة قضايا رئيسية في المشاركة، وهي كما يلي:
كيف يمكن تحديد أي مشاركة تنتمي إليها العقد/المحققون في الشبكة؟ أي: كيف يتم تنفيذ تقسيم الشبكة (Network Sharding);
كيف يمكن تحديد أي جزء من المعاملة يتم تخصيصه لكل شريحة؟ أي: كيف يتم إجراء تقسيم المعاملات (Transaction Sharding);
كيف يتم تخزين بيانات blockchain في مشاركات مختلفة؟ أي: كيف يتم إجراء تقسيم الحالة (State Sharding)؛
تعني التعقيد المخاطر، بناءً على كل ما سبق، كيف يمكن تجنب انقسام أمان النظام بأكمله؟
إذا فهمنا سلسلة الكتل ببساطة كنوع من دفتر الأستاذ اللامركزي، فإن آلية الإجماع سواء كانت PoS أو PoW، تهدف إلى السماح لكل عقدة بالتنافس على حقوق المحاسبة وفقًا لقواعد معينة محددة مسبقًا، مع ضمان صحة دفتر الأستاذ خلال هذه العملية. أما تقسيم الشبكة فهو يعني أنه يحتاج إلى قواعد محددة مسبقًا أخرى، لتقسيم شبكة سلسلة الكتل، مع تقليل التواصل المتبادل قدر الإمكان، حيث تتولى كل شريحة معالجة المعاملات على السلسلة، والتنافس على حقوق المحاسبة - أي قواعد تجميع العقد.
وفي هذه العملية، المشكلة التي تواجهنا هي أنه مع تقسيم العقد الداخلية في سلسلة الكتل إلى مقاطع مختلفة، فإن صعوبة وه成本 المهاجمين ستنخفض بشكل كبير. يمكننا الاستنتاج أنه إذا كانت قواعد ونتائج هذه العملية ثابتة وقابلة للتنبؤ، فإن المهاجم يحتاج فقط إلى السيطرة على جزء من شبكة سلسلة الكتل، من خلال السيطرة الموجهة على مقطع واحد، وشراء بعض العقد داخل هذا المقطع.
وصف مؤسس سلسلة الكتل هذه المشكلة على النحو التالي: إذا قررت سلسلة واحدة تحتوي على X من المدققين أن تتشعب إلى سلسلة مشاركة وتقسم X من المدققين إلى 10 مشاركات، فسيكون لدى كل مشاركة الآن X/10 من المدققين، وسيكون تدمير مشاركة واحدة يتطلب تدمير 5.1%(51% / 10) من إجمالي المدققين. وهذا يثير النقطة الثانية: من يختار المدققين لكل مشاركة؟ فقط عندما يكون جميع هؤلاء المدققين بنسبة 5.1% في نفس المشاركة، يكون التحكم في 5.1% من المدققين ضاراً. إذا لم يتمكن المدققون من اختيار المشاركة التي سيقومون بالتحقق فيها، فمن غير المحتمل للغاية أن يضع المشاركون الذين يتحكمون في 5.1% من المدققين جميع المدققين في نفس المشاركة، مما يقلل بشكل كبير من قدرتهم على تدمير النظام.
يجب على نظام المشاركة تطوير آلية للثقة في أن الشبكة لن تعكس هذه المعاملات من المشاركات الخارجية. حتى الآن، قد تكون أفضل إجابة هي التأكد من أن عدد المدققين داخل المشاركة أعلى من حد أدنى معين، بحيث تكون فرصة المدققين غير الشرفاء في التغلب على مشاركة واحدة منخفضة جداً. الطريقة الأكثر شيوعاً هي بناء درجة معينة من العشوائية غير المنحازة، بالاعتماد على الرياضيات، لتقليل فرصة نجاح المهاجمين إلى الحد الأدنى. على سبيل المثال، في إثريوم، كانت حل إثريوم هو اختيار مدققين لمشاركة معينة عشوائياً من جميع المدققين، وتغيير المدققين كل 6.4 دقائق ( طول حقبة ).
ببساطة، يعني ذلك تقسيم العقد إلى مجموعات عشوائية، ثم توزيع العمل على كل مجموعة من العقد للتحقق بشكل مستقل.
ومع ذلك، من الضروري الإشارة إلى أن العشوائية في البلوك تشين هي موضوع صعب للغاية، ومن المنطقي أن عملية توليد هذا الرقم العشوائي لا ينبغي أن تعتمد على حساب أي مشاركة معينة. بالنسبة لهذا الحساب، فإن العديد من الأفكار التصميمية الحالية تتضمن تطوير بلوك تشين منفصل، للحفاظ على الشبكة بأكملها. تُعرف هذه السلسلة في Ethereum وNear باسم سلسلة Beacon، وفي PolkaDot تُعرف باسم سلسلة Relay، وفي Cosmos تُعرف باسم Cosmos Hub.
02 (Transaction Sharding) تجزئة المعاملات
تقسيم المعاملات يعني وضع قواعد حول "أي المعاملات يجب تخصيصها لأي تقسيم"، مما يحقق هدف المعالجة المتوازية ويتجنب مشكلة الإنفاق المزدوج. سيكون لاختلاف نماذج دفاتر البلوكتشين تأثير على تطوير تقسيم المعاملات.
يوجد حاليًا نوعان من أنظمة المحاسبة في شبكات البلوكشين، وهما نموذج مخرجات المعاملات غير المنفقة (UTXO) والموديل القائم على الحساب/الرصيد. الممثل النموذجي للأول هو BTC، بينما الثاني مثل ETH.
نموذج UTXO: في معاملات BTC، تحتوي كل معاملة على مخرجات واحدة أو أكثر، حيث تشير UTXO إلى مخرجات معاملات blockchain التي لم تُنفَذ بعد، ويمكن استخدامها كمدخلات لمعاملات جديدة، بينما لا يمكن إنفاق المخرجات التي تم إنفاقها، مثل حالات الدفع والباقي في معاملات الأوراق النقدية، حيث يدفع العميل ورقة نقدية واحدة أو أكثر للتاجر، ثم يقوم التاجر بإعطاء العميل ورقة نقدية واحدة أو أكثر كفكة. في نموذج UTXO، تحتاج تقسيمات المعاملات إلى التواصل عبر تقسيمات مختلفة. قد تتضمن المعاملة الواحدة مدخلات متعددة ومخرجات متعددة، ولا يوجد مفهوم الحسابات، ولن يكون هناك سجلات للأرصدة، إحدى الطرق الممكنة هي: وضعها في دالة هاش وفقًا لقيمة مدخلاتها لتصبح قيمة هاش منفصلة لتحديد البيانات التي يجب أن تذهب إلى أي تقسيم.
لضمان وضع الإدخالات بطريقة متسقة في الشظايا الصحيحة، يجب أن تأتي القيم المدخلة في دالة التجزئة من نفس العمود. يُطلق على هذا العمود مفتاح الشظية. بعد ذلك، يتم تصنيف المعاملات التي تنتج القيمة 1 في الشظية 1، والمعاملات التي تنتج القيمة 2 في الشظية 2. ومع ذلك، فإن عيب هذه الطريقة هو أنه يجب على الشظايا التواصل لتجنب هجمات الإنفاق المزدوج. إذا تم تقييد المعاملات عبر الشظايا، فسيؤدي ذلك إلى تقييد إمكانية استخدام المنصة، بينما السماح بالمعاملات عبر الشظايا يتطلب موازنة بين تكاليف التواصل عبر الشظايا والفوائد الناتجة عن تحسين الأداء.
نموذج الحساب/الرصيد: يسجل النظام رصيد كل حساب، وعند إجراء المعاملات، يتحقق النظام مما إذا كان لدى الحساب رصيد كافٍ للدفع، مشابهًا لتحويل الأموال في البنك، حيث يسجل البنك رصيد كل حساب، ولا يمكن إجراء المعاملة إلا إذا كان رصيد الحساب أكبر من مبلغ التحويل المطلوب. في نموذج الحساب/الرصيد، نظرًا لأن المعاملة تحتوي على إدخال واحد فقط، فإنه يمكن ضمان معالجة العديد من المعاملات لنفس الحساب في نفس المشاركة من خلال تقسيم المعاملة حسب عنوان المرسل، مما يمنع فعليًا عمليات الإنفاق المزدوج. لذلك، فإن معظم سلاسل الكتل التي تعتمد على تقنية المشاركة هي أنظمة دفاتر حسابات مثل الإيثيريوم.
( 03 حالة مشاركة ) حالة مشاركة ###
تشير حالة المشاركة إلى كيفية توزيع بيانات blockchain على مشاركات مختلفة للتخزين.
لا يزال نستخدم مثال صفوف السوبر ماركت، كل نافذة لديها حساب، كيف تسجل دفاتر حساباتهم؟ إذا: جاء العميل للوقوف في أي صف، يتم تسجيله في أي حساب، على سبيل المثال، إذا ذهب العميل A إلى نافذة A، وفي اليوم التالي ذهب العميل إلى نافذة دفع أخرى مثل نافذة B، ولم يكن لدى نافذة B معلومات حساب العميل السابق ( على سبيل المثال، إذا كانت تتعلق ببطاقة الائتمان أو أي طريقة دفع أخرى )، ماذا نفعل؟ هل نتصل بنافذة A لاستدعاء معلومات حساب ذلك العميل؟
تعتبر حالة المشاركة أكبر مشكلة في المشاركة، فهي أكثر تعقيدًا من تقسيم الشبكة وتقسيم المعاملات المذكورة أعلاه. لأنه بموجب آلية المشاركة، يتم توزيع المعاملات بناءً على العنوان لمعالجتها في مشاركات مختلفة، مما يعني أن الحالة ستظل محفوظة فقط في المشاركة التي ينتمي إليها عنوانها، وفي هذه الحالة، تواجه مشكلة أن المعاملات لن تتم فقط في مشاركة واحدة، وغالبًا ما تشمل عمليات عبر المشاركة (Cross-Sharding).
اعتبر حالة تحويل، حيث يقوم الحساب A بتحويل 10U إلى الحساب B، وعنوان A مخصص في مشاركة 1، وسجل المعاملة سيتم تخزينه أيضًا في مشاركة 1. عنوان B مخصص في مشاركة 2، وسجل المعاملة سيتم تخزينه في مشاركة 2.
عندما يريد A تحويل الأموال إلى B، سيحدث交易跨مشاركة، وستقوم المشاركة 2 بالاتصال بسجل المعاملات السابقة في المشاركة 1 للتحقق من صحة المعاملة. إذا كان A يقوم بتحويل الأموال إلى B بشكل متكرر، فسيتعين على المشاركة 2 التفاعل باستمرار مع المشاركة 1، مما سيؤدي إلى انخفاض كفاءة معالجة المعاملات. ومع ذلك، إذا لم يتم تنزيل والتحقق من
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
شارديم استكشاف حالة المشاركة الديناميكية لحل مشكلة توسعة البلوكتشين
شاردوم والحالة الديناميكية لمشاركة: إمكانية أخرى للمشاركة
في 15 سبتمبر 2022، أكملت إيثيريوم الدمج المنتظر منذ فترة طويلة (Merge). كانت هذه لحظة تاريخية، حيث استعدت إيثيريوم لذلك لمدة 5 سنوات، وتم تأجيله 6 مرات. بسبب عمليات التصحيح المتكررة والتطوير الطويل الأمد، اعتقد الكثيرون أن الدمج سيؤدي بشكل طبيعي إلى زيادة القابلية للتوسع والأمان والاستدامة، ولكن هذا ليس صحيحًا. الانتقال من PoW إلى PoS هو مجرد تغيير للمسار والعجلات، ولن يؤدي مباشرة إلى سرعة أكبر أو سعة أكبر أو رسوم أقل. ما يمكنه تحقيق ذلك هو مجموعة كاملة من الحلول: شبكة رئيسية تمتلك قدرة المشاركة جنبًا إلى جنب مع حلول Layer2 المعززة للقابلية للتوسع.
كما أشار مؤسس الإيثيريوم فيتالك بوتيرين، فإن المشاركة هي حل للتوسع تحت معضلة قابلية التوسع، من خلال تقسيم العقد في الشبكة إلى مجموعات أصغر، ومعالجة مجموعات مختلفة من المعاملات وتحقيق المعالجة المتوازية. من خلال تخفيف عبء معالجة كمية كبيرة من البيانات المطلوبة لتجميعها عبر الشبكة بأكملها، تمامًا كما نفعل عند التسوق في السوبر ماركت والدفع، من خلال فتح المزيد من قنوات الدفع، يمكن تقليل أوقات الانتظار وزيادة كفاءة الدفع.
هذه هي منطق المشاركة، مباشر وبسيط، ومع ذلك، الشيطان يكمن في التفاصيل. المبادئ والاتجاهات صحيحة، لكن تنفيذها دائماً ما يواجه العديد من المشكلات. تهدف هذه المقالة إلى توضيح الاتجاهات والمآزق على طريق "المشاركة"، ورسم خريطة لمستكشفي المشاركة الذين يتطلعون إلى النجوم ويعيشون على الأرض. في الوقت نفسه، من خلال مقارنة الحلول الحالية للمشاركة، سيتم العثور على بعض المشكلات المشتركة، واقتراح اتجاه استكشاف قابل للتطبيق: Shardeum والمشاركة الديناميكية.
1. حول "مشاركة"
باختصار، بالنظر إلى قيود مثلث المستحيل، انطلاقًا من إيثريوم كنقطة الأصل (، 0،0)، وفقًا لفكرتين "رأسي" و"أفقي"، نقسم طرق قابلية التوسع الحالية في blockchain إلى فئتين رئيسيتين:
التوسع العمودي(Vertical Scaling): يتم تحقيقه من خلال تحسين أداء الأجهزة الحالية للنظام. إنشاء شبكة لامركزية حيث يمتلك كل عقدة في الشبكة قدرة حوسبة فائقة، مما يعني أن كل عقدة تحتاج إلى "أفضل" الأجهزة. هذه الطريقة بسيطة وفعالة، ويمكن أن تحقق تحسينًا أوليًا في قدرة المعالجة، وخاصة في تطبيقات مثل التداول عالي التردد، والألعاب، وغيرها من السيناريوهات الحساسة للزمن. ومع ذلك، فإن هذه الطريقة للتوسع ستقيد مستوى اللامركزية للشبكة، حيث تزداد تكلفة تشغيل العقدة المُصادقة أو العقدة الكاملة. إن الحفاظ على مستوى اللامركزية محدود بسرعة النمو التقريبي لأداء الأجهزة الحاسوبية( وهذا هو ما يسمى بـ"قانون مور": عدد الترانزستورات على الرقاقة يتضاعف كل عامين، بينما تتناقص تكاليف الحوسبة إلى النصف).
التوسع الأفقي(Horizontal Scaling): هناك عدة أفكار حول التوسع الأفقي. واحدة هي في سياق blockchain، حيث يتم توزيع حجم المعاملات في نظام بيئي معين على عدة blockchains مستقلة، حيث تمتلك كل سلسلة منتجي كتلها وقدرتها التنفيذية الخاصة، وهذه الطريقة تسمح بتخصيص كامل لطبقة التنفيذ لكل سلسلة، مثل متطلبات الأجهزة للعقد، وظائف الخصوصية، رسوم الغاز، الآلات الافتراضية وإعدادات الإذن وغيرها. خيار آخر للتوسع الأفقي هو blockchain المودولاري، حيث يتم تقسيم بنية blockchain الأساسية إلى طبقة تنفيذ، وطبقة توفر البيانات(DA) وطبقة إجماع. آلية المودولار الأكثر شيوعًا في blockchain هي rollup. وهناك خيار آخر هو تقسيم سلسلة blockchain إلى العديد من المشاركات، وتنفيذها بالتوازي. يمكن اعتبار كل مشاركة كـ blockchain، مما يعني أنه يمكن تنفيذ العديد من blockchains بالتوازي. بالإضافة إلى ذلك، عادة ما سيكون هناك سلسلة رئيسية، والتي تكون مهمتها الوحيدة هي الحفاظ على تزامن جميع المشاركات.
من المهم الإشارة إلى أن أفكار التوسع المذكورة أعلاه ليست قائمة في عزلة، بل كل حل هو نقطة توازن موجودة في مثلث مستحيل، مصممة بالتعاون مع آليات التحفيز التي تخلقها القوى الاقتصادية في النظام، لتحقيق توازن فعال على المستويين الكلي والجزئي.
للمناقشة حول "مشاركة"، نحتاج إلى إعادة تنظيم الأمور من البداية.
لا يزال نفترض هذا السيناريو، عند دفع ثمن التسوق في السوبرماركت، من أجل تحسين كفاءة الدفع وتقليل وقت انتظار العملاء، قمنا بتوسيع من ممر دفع واحد إلى 10 نوافذ دفع، لتجنب أخطاء السجلات، في هذه المرحلة، نحتاج إلى وضع قواعد موحدة:
أولاً، إذا كان لدينا 10 صرافين، كيف نقوم بتوزيعهم على أي نافذة للعمل؟
ثانياً، إذا كان لدينا 1000 عميل في انتظار، كيف نقرر أي عميل يذهب إلى أي نافذة للدفع؟
ثالثًا، كيف يمكن تلخيص دفاتر الحسابات العشرة الفردية المرتبطة بهذه النوافذ العشرة؟
رابعًا، كيف يمكن تجنب الأخطاء من قبل أمين الصندوق لتفادي حدوث عدم تطابق في الحسابات؟
هذه الأسئلة تتعلق في الواقع بعدة قضايا رئيسية في المشاركة، وهي كما يلي:
كيف يمكن تحديد أي مشاركة تنتمي إليها العقد/المحققون في الشبكة؟ أي: كيف يتم تنفيذ تقسيم الشبكة (Network Sharding);
كيف يمكن تحديد أي جزء من المعاملة يتم تخصيصه لكل شريحة؟ أي: كيف يتم إجراء تقسيم المعاملات (Transaction Sharding);
كيف يتم تخزين بيانات blockchain في مشاركات مختلفة؟ أي: كيف يتم إجراء تقسيم الحالة (State Sharding)؛
تعني التعقيد المخاطر، بناءً على كل ما سبق، كيف يمكن تجنب انقسام أمان النظام بأكمله؟
! شارديوم: إمكانية أخرى للتشارك
01 شبكة مشاركة(Network Sharding)
إذا فهمنا سلسلة الكتل ببساطة كنوع من دفتر الأستاذ اللامركزي، فإن آلية الإجماع سواء كانت PoS أو PoW، تهدف إلى السماح لكل عقدة بالتنافس على حقوق المحاسبة وفقًا لقواعد معينة محددة مسبقًا، مع ضمان صحة دفتر الأستاذ خلال هذه العملية. أما تقسيم الشبكة فهو يعني أنه يحتاج إلى قواعد محددة مسبقًا أخرى، لتقسيم شبكة سلسلة الكتل، مع تقليل التواصل المتبادل قدر الإمكان، حيث تتولى كل شريحة معالجة المعاملات على السلسلة، والتنافس على حقوق المحاسبة - أي قواعد تجميع العقد.
وفي هذه العملية، المشكلة التي تواجهنا هي أنه مع تقسيم العقد الداخلية في سلسلة الكتل إلى مقاطع مختلفة، فإن صعوبة وه成本 المهاجمين ستنخفض بشكل كبير. يمكننا الاستنتاج أنه إذا كانت قواعد ونتائج هذه العملية ثابتة وقابلة للتنبؤ، فإن المهاجم يحتاج فقط إلى السيطرة على جزء من شبكة سلسلة الكتل، من خلال السيطرة الموجهة على مقطع واحد، وشراء بعض العقد داخل هذا المقطع.
وصف مؤسس سلسلة الكتل هذه المشكلة على النحو التالي: إذا قررت سلسلة واحدة تحتوي على X من المدققين أن تتشعب إلى سلسلة مشاركة وتقسم X من المدققين إلى 10 مشاركات، فسيكون لدى كل مشاركة الآن X/10 من المدققين، وسيكون تدمير مشاركة واحدة يتطلب تدمير 5.1%(51% / 10) من إجمالي المدققين. وهذا يثير النقطة الثانية: من يختار المدققين لكل مشاركة؟ فقط عندما يكون جميع هؤلاء المدققين بنسبة 5.1% في نفس المشاركة، يكون التحكم في 5.1% من المدققين ضاراً. إذا لم يتمكن المدققون من اختيار المشاركة التي سيقومون بالتحقق فيها، فمن غير المحتمل للغاية أن يضع المشاركون الذين يتحكمون في 5.1% من المدققين جميع المدققين في نفس المشاركة، مما يقلل بشكل كبير من قدرتهم على تدمير النظام.
يجب على نظام المشاركة تطوير آلية للثقة في أن الشبكة لن تعكس هذه المعاملات من المشاركات الخارجية. حتى الآن، قد تكون أفضل إجابة هي التأكد من أن عدد المدققين داخل المشاركة أعلى من حد أدنى معين، بحيث تكون فرصة المدققين غير الشرفاء في التغلب على مشاركة واحدة منخفضة جداً. الطريقة الأكثر شيوعاً هي بناء درجة معينة من العشوائية غير المنحازة، بالاعتماد على الرياضيات، لتقليل فرصة نجاح المهاجمين إلى الحد الأدنى. على سبيل المثال، في إثريوم، كانت حل إثريوم هو اختيار مدققين لمشاركة معينة عشوائياً من جميع المدققين، وتغيير المدققين كل 6.4 دقائق ( طول حقبة ).
ببساطة، يعني ذلك تقسيم العقد إلى مجموعات عشوائية، ثم توزيع العمل على كل مجموعة من العقد للتحقق بشكل مستقل.
ومع ذلك، من الضروري الإشارة إلى أن العشوائية في البلوك تشين هي موضوع صعب للغاية، ومن المنطقي أن عملية توليد هذا الرقم العشوائي لا ينبغي أن تعتمد على حساب أي مشاركة معينة. بالنسبة لهذا الحساب، فإن العديد من الأفكار التصميمية الحالية تتضمن تطوير بلوك تشين منفصل، للحفاظ على الشبكة بأكملها. تُعرف هذه السلسلة في Ethereum وNear باسم سلسلة Beacon، وفي PolkaDot تُعرف باسم سلسلة Relay، وفي Cosmos تُعرف باسم Cosmos Hub.
02 (Transaction Sharding) تجزئة المعاملات
تقسيم المعاملات يعني وضع قواعد حول "أي المعاملات يجب تخصيصها لأي تقسيم"، مما يحقق هدف المعالجة المتوازية ويتجنب مشكلة الإنفاق المزدوج. سيكون لاختلاف نماذج دفاتر البلوكتشين تأثير على تطوير تقسيم المعاملات.
يوجد حاليًا نوعان من أنظمة المحاسبة في شبكات البلوكشين، وهما نموذج مخرجات المعاملات غير المنفقة (UTXO) والموديل القائم على الحساب/الرصيد. الممثل النموذجي للأول هو BTC، بينما الثاني مثل ETH.
نموذج UTXO: في معاملات BTC، تحتوي كل معاملة على مخرجات واحدة أو أكثر، حيث تشير UTXO إلى مخرجات معاملات blockchain التي لم تُنفَذ بعد، ويمكن استخدامها كمدخلات لمعاملات جديدة، بينما لا يمكن إنفاق المخرجات التي تم إنفاقها، مثل حالات الدفع والباقي في معاملات الأوراق النقدية، حيث يدفع العميل ورقة نقدية واحدة أو أكثر للتاجر، ثم يقوم التاجر بإعطاء العميل ورقة نقدية واحدة أو أكثر كفكة. في نموذج UTXO، تحتاج تقسيمات المعاملات إلى التواصل عبر تقسيمات مختلفة. قد تتضمن المعاملة الواحدة مدخلات متعددة ومخرجات متعددة، ولا يوجد مفهوم الحسابات، ولن يكون هناك سجلات للأرصدة، إحدى الطرق الممكنة هي: وضعها في دالة هاش وفقًا لقيمة مدخلاتها لتصبح قيمة هاش منفصلة لتحديد البيانات التي يجب أن تذهب إلى أي تقسيم.
لضمان وضع الإدخالات بطريقة متسقة في الشظايا الصحيحة، يجب أن تأتي القيم المدخلة في دالة التجزئة من نفس العمود. يُطلق على هذا العمود مفتاح الشظية. بعد ذلك، يتم تصنيف المعاملات التي تنتج القيمة 1 في الشظية 1، والمعاملات التي تنتج القيمة 2 في الشظية 2. ومع ذلك، فإن عيب هذه الطريقة هو أنه يجب على الشظايا التواصل لتجنب هجمات الإنفاق المزدوج. إذا تم تقييد المعاملات عبر الشظايا، فسيؤدي ذلك إلى تقييد إمكانية استخدام المنصة، بينما السماح بالمعاملات عبر الشظايا يتطلب موازنة بين تكاليف التواصل عبر الشظايا والفوائد الناتجة عن تحسين الأداء.
نموذج الحساب/الرصيد: يسجل النظام رصيد كل حساب، وعند إجراء المعاملات، يتحقق النظام مما إذا كان لدى الحساب رصيد كافٍ للدفع، مشابهًا لتحويل الأموال في البنك، حيث يسجل البنك رصيد كل حساب، ولا يمكن إجراء المعاملة إلا إذا كان رصيد الحساب أكبر من مبلغ التحويل المطلوب. في نموذج الحساب/الرصيد، نظرًا لأن المعاملة تحتوي على إدخال واحد فقط، فإنه يمكن ضمان معالجة العديد من المعاملات لنفس الحساب في نفس المشاركة من خلال تقسيم المعاملة حسب عنوان المرسل، مما يمنع فعليًا عمليات الإنفاق المزدوج. لذلك، فإن معظم سلاسل الكتل التي تعتمد على تقنية المشاركة هي أنظمة دفاتر حسابات مثل الإيثيريوم.
( 03 حالة مشاركة ) حالة مشاركة ###
تشير حالة المشاركة إلى كيفية توزيع بيانات blockchain على مشاركات مختلفة للتخزين.
لا يزال نستخدم مثال صفوف السوبر ماركت، كل نافذة لديها حساب، كيف تسجل دفاتر حساباتهم؟ إذا: جاء العميل للوقوف في أي صف، يتم تسجيله في أي حساب، على سبيل المثال، إذا ذهب العميل A إلى نافذة A، وفي اليوم التالي ذهب العميل إلى نافذة دفع أخرى مثل نافذة B، ولم يكن لدى نافذة B معلومات حساب العميل السابق ( على سبيل المثال، إذا كانت تتعلق ببطاقة الائتمان أو أي طريقة دفع أخرى )، ماذا نفعل؟ هل نتصل بنافذة A لاستدعاء معلومات حساب ذلك العميل؟
تعتبر حالة المشاركة أكبر مشكلة في المشاركة، فهي أكثر تعقيدًا من تقسيم الشبكة وتقسيم المعاملات المذكورة أعلاه. لأنه بموجب آلية المشاركة، يتم توزيع المعاملات بناءً على العنوان لمعالجتها في مشاركات مختلفة، مما يعني أن الحالة ستظل محفوظة فقط في المشاركة التي ينتمي إليها عنوانها، وفي هذه الحالة، تواجه مشكلة أن المعاملات لن تتم فقط في مشاركة واحدة، وغالبًا ما تشمل عمليات عبر المشاركة (Cross-Sharding).
اعتبر حالة تحويل، حيث يقوم الحساب A بتحويل 10U إلى الحساب B، وعنوان A مخصص في مشاركة 1، وسجل المعاملة سيتم تخزينه أيضًا في مشاركة 1. عنوان B مخصص في مشاركة 2، وسجل المعاملة سيتم تخزينه في مشاركة 2.
عندما يريد A تحويل الأموال إلى B، سيحدث交易跨مشاركة، وستقوم المشاركة 2 بالاتصال بسجل المعاملات السابقة في المشاركة 1 للتحقق من صحة المعاملة. إذا كان A يقوم بتحويل الأموال إلى B بشكل متكرر، فسيتعين على المشاركة 2 التفاعل باستمرار مع المشاركة 1، مما سيؤدي إلى انخفاض كفاءة معالجة المعاملات. ومع ذلك، إذا لم يتم تنزيل والتحقق من