طريق الابتكار في تقنية المشاركة: Shardeum والمشاركة الديناميكية للحالة
في 15 سبتمبر 2022، أكملت إيثيريوم الدمج (Merge). كانت هذه لحظة تاريخية حيث استعدت إيثيريوم لذلك لمدة 5 سنوات، وتم تأجيلها 6 مرات. بسبب التطوير الطويل والاختبار، بالإضافة إلى تأثير الهالة الذي حظيت به، اعتقد الكثيرون خطأً أن الدمج سيؤدي بشكل طبيعي إلى زيادة القابلية للتوسع، والأمان، والاستدامة، لكن هذا ليس صحيحًا. الانتقال من PoW( إثبات العمل) إلى PoS( إثبات الحصة) هو مجرد تغيير للمسار والعجلات، ولن يؤدي مباشرة إلى سرعة أكبر، أو سعة أكبر، أو رسوم أقل. ما يمكن أن يحقق هذه الأهداف هو مجموعة كاملة من الحلول: شبكة رئيسية مع قدرة المشاركة إلى جانب حلول Layer2 التي تعزز القابلية للتوسع.
كما أشار مؤسس إيثريوم فيتاليك بوتيرين، فإن المشاركة هي حل للتوسع في ظل صعوبة التوسع الثلاثية، من خلال تقسيم العقد في الشبكة إلى مجموعات أصغر، ومعالجة مجموعات مختلفة من المعاملات وتنفيذ المعالجة المتوازية. من خلال تخفيف عبء معالجة كميات كبيرة من البيانات المطلوبة لتجميع الشبكة بأكملها، تمامًا كما هو الحال عندما نتسوق في وول مارت وندفع، من خلال فتح المزيد من ممرات الدفع، يمكن تقليل وقت الانتظار وزيادة كفاءة الدفع بشكل ملحوظ.
هذه هي منطق المشاركة، مباشر وبسيط، ومع ذلك، الشيطان يكمن في التفاصيل - المبدأ والاتجاه صحيحان، لكن في التنفيذ دائمًا ما تواجه العديد من المشاكل. تهدف هذه المقالة إلى ترتيب الاتجاهات والقيود على طريق "المشاركة"، ورسم خريطة لمستكشفي المشاركة الذين ينظرون إلى السماء ويقفون على الأرض. وفي الوقت نفسه، من خلال مقارنة الحلول الحالية للمشاركة، نجد بعض المشاكل المشتركة، ونقترح اتجاه استكشاف قابل للتطبيق: شاردوم والمشاركة الديناميكية.
أ. حول "مشاركة"
ببساطة، بالنظر إلى قيود مثلث الاستحالة، انطلاقًا من الإيثيريوم كنقطة الأصل (0،0)، وفقًا لطريقتين "عموديتين" و"أفقيتين"، نقسم طرق قابلية التوسع الحالية في البلوكشين إلى فئتين رئيسيتين:
التوسيع العمودي (: يتم تحقيقه عن طريق تحسين أداء الأجهزة الحالية للنظام. إنشاء شبكة لامركزية، حيث تمتلك كل عقدة في الشبكة قدرة حسابية فائقة، مما يعني أن كل عقدة تحتاج إلى "أفضل" الأجهزة - وهذه الطريقة بسيطة وفعالة، ويمكن أن تحقق تحسينًا أوليًا في معدل نقل البيانات، وهي مناسبة بشكل خاص للتداول عالي التردد، والألعاب، وغيرها من السيناريوهات التي تكون حساسة للتأخير. ومع ذلك، فإن هذا النوع من التوسيع سيقيد مستوى اللامركزية في الشبكة، لأن تكلفة تشغيل العقدة المصدقة أو العقدة الكاملة قد ارتفعت. الحفاظ على مستوى اللامركزية مقيد بمتوسط سرعة النمو في أداء الأجهزة الحاسوبية ) وهذا ما يسمى "قانون مور": عدد الترانزستورات على الشريحة يتضاعف كل عامين، وتتكلف الحسابات نصف التكلفة (.
التوسع الأفقي ) التوسع الأفقي (: عادة ما يكون هناك عدة أفكار للتوسع الأفقي. أحدها هو في سياق blockchain، توزيع كمية المعاملات على عدة blockchains مستقلة في نظام بيئي معين، حيث تمتلك كل سلسلة منتجي الكتل والقدرة على التنفيذ الخاصة بها، مما يسمح بتخصيص كامل لطبقة التنفيذ لكل سلسلة، مثل متطلبات الأجهزة للعقد، وميزات الخصوصية، ورسوم الغاز، والآلة الافتراضية، وإعدادات الإذن، وما إلى ذلك. خطة أخرى للتوسع الأفقي هي blockchain المعيارية، التي تقسم البنية التحتية لل blockchain إلى طبقة التنفيذ، وطبقة توفر البيانات ) DA ( وطبقة الإجماع. آلية blockchain المعيارية الأكثر شيوعًا هي rollup. هناك أيضًا طريقة لتقسيم blockchain إلى العديد من المشاركات، يتم تنفيذها بشكل متوازي. يمكن اعتبار كل مشاركة ك blockchain، مما يعني أن العديد من blockchains يمكن تنفيذها بشكل متوازي. بالإضافة إلى ذلك، عادة ما يكون هناك سلسلة رئيسية واحدة، تكون مهمتها الوحيدة هي الحفاظ على تزامن جميع المشاركات.
من الضروري الإشارة إلى أن أفكار التوسع المذكورة أعلاه ليست موجودة بشكل معزول، فكل حل من الحلول هو نقطة توازن تم العثور عليها في مثلث الاستحالة، حيث يتم تصميم آليات التحفيز التي تنشأ من القوى الاقتصادية في النظام لتحقيق توازن فعال على المستويين الكلي والجزئي.
لمناقشة "مشاركة"، نحتاج إلى إعادة整理 الأمور من البداية.
لا يزال نفترض هذا السيناريو،checkout في Walmart، لتحسين كفاءة checkout وتقليل وقت انتظار العملاء، قمنا بتوسيع من قناة checkout واحدة إلى 10 نوافذ checkout، لتجنب أخطاء الحساب، في هذا الوقت نحتاج إلى وضع قواعد موحدة:
أولاً، إذا كان لدينا 10 محصلين، كيف نقوم بتوزيعهم على أي نافذة للعمل؟
ثانياً، إذا كان لدينا 1000 عميل في الطابور في انتظار، كيف نقرر أي عميل يذهب إلى أي نافذة للدفع؟
ثالثًا، كيف يتم تجميع هذه 10 دفاتر حسابات منفصلة المرتبطة بالنوافذ العشرة؟
رابعًا، كيف يمكن منع حدوث أخطاء من قبل أمين الصندوق لتجنب حدوث عدم تطابق في الحسابات؟
هذه الأسئلة تتعلق في الواقع بعدة قضايا رئيسية في المشاركة، وهي:
كيف يمكن تحديد أي شريحة تنتمي إليها العقد/المدققون في الشبكة؟ أي: كيف يتم تنفيذ تقسيم الشبكة )NetworkSharding(؛
كيف يمكن تحديد كل معاملة تُخصص لأي مشاركة؟ أي: كيف يتم إجراء مشاركة المعاملات )Transaction Sharding(؛
كيف يتم تخزين بيانات البلوكشين في مشاركات مختلفة؟ أي: كيف يتم إجراء تقسيم الحالة )State Sharding(؛
تعني التعقيدات المخاطر، بناءً على كل ما سبق، كيف يمكن تجنب انقسام أمان النظام بأكمله؟
) 01 شبكة مشاركة###Network Sharding(
إذا فهمنا blockchain ببساطة على أنه دفتر أستاذ لامركزي، سواء كانت آلية توافق PoS أو PoW، فإنها تهدف إلى تمكين كل عقدة من التنافس على حق التسجيل وفقًا لقواعد محددة مسبقًا، مع ضمان صحة دفتر الأستاذ خلال هذه العملية. أما تقسيم الشبكة فهو يعني أنه يحتاج إلى قاعدة محددة أخرى، لتقسيم شبكة blockchain، مع تقليل التواصل المتبادل قدر الإمكان، بحيث تتعامل كل مشاركة مع المعاملات على السلسلة، وتتنافس على حق التسجيل - أي، قاعدة تجميع العقد.
وفي هذه العملية، تتمثل المشكلة التي نواجهها في أنه مع تقسيم العقد الداخلية في سلسلة الكتل إلى أجزاء مختلفة، ستنخفض صعوبة وكلفة الهجوم بشكل حاد. يمكننا أن نستنتج أنه إذا كانت قواعد ونتائج هذه العملية ثابتة وقابلة للتنبؤ، فإن المهاجم سيحتاج فقط إلى السيطرة على جزء واحد من شبكة سلسلة الكتل بأكملها، من خلال التحكم بشكل موجه في أحد الأجزاء وشراء بعض العقد داخل هذا الجزء.
وصف مؤسس Near ألكسندر سكيدانوف هذه المشكلة على النحو التالي: إذا قررت سلسلة واحدة تحتوي على X من المدققين الانقسام إلى سلسلة مشاركة ووزعت X من المدققين إلى 10 مشاركات، فإن كل مشاركة تحتوي الآن فقط على X/10 من المدققين، ويتطلب تدمير مشاركة واحدة تدمير 5.1%)51% / 10( من إجمالي عدد المدققين. هذا يؤدي إلى النقطة الثانية: من يختار المدققين لكل مشاركة؟ فقط عندما يكون جميع هؤلاء المدققين البالغ عددهم 5.1% في نفس المشاركة، فإن السيطرة على 5.1% من المدققين تكون ضارة. إذا لم يتمكن المدققون من اختيار المشاركة التي سيتم فيها التحقق، فإن احتمال أن يضع المشاركون الذين يتحكمون في 5.1% من المدققين جميع المدققين في نفس المشاركة يكون منخفضًا جدًا، مما يقلل بشكل كبير من قدرتهم على تدمير النظام.
يجب على نظام المشاركة تطوير آلية للثقة في أن الشبكة لن تعكس هذه المعاملات من مشاركات خارجية. حتى الآن، قد تكون أفضل إجابة هي ضمان أن عدد المدققين داخل المشاركة أعلى من عتبة دنيا معينة، مما يجعل فرص المدققين غير المخلصين في السيطرة على مشاركة واحدة منخفضة جداً. الطريقة الأكثر شيوعًا هي بناء مستوى معين من العشوائية غير المتحيزة، بالاعتماد على الرياضيات، لتقليل احتمال نجاح المهاجمين إلى الحد الأدنى. على سبيل المثال، الحل في الإيثيريوم هو اختيار مدقق لمشاركة معينة عشوائيًا من بين جميع المدققين، وتغيير المدققين كل 6.4 دقائق ) طول حقبة (.
بعبارة بسيطة، يتم تقسيم العقد بشكل عشوائي إلى مجموعات، ثم يتم توزيع العمل على كل مجموعة من العقد للتحقق بشكل مستقل.
ومع ذلك، من المهم الإشارة إلى أن العشوائية في blockchain هي موضوع يمثل تحديًا كبيرًا، ومن المنطقي أن عملية توليد هذا الرقم العشوائي لا ينبغي أن تعتمد على حساب أي مشاركة معينة. بالنسبة لهذا الحساب، فإن العديد من الأفكار التصميمية الحالية هي تطوير blockchain منفصل، للحفاظ على الشبكة بالكامل. تُعرف هذه السلسلة في Ethereum و Near بسلسلة Beacon، وفي PolkaDot بسلسلة Relay، وفي Cosmos تُعرف بمركز Cosmos.
![شرح مفصل حول سلسلة الكتل الجديدة Shardeum: مشاركة أخرى ممكنة])https://img-cdn.gateio.im/webp-social/moments-69c7de2bfe4ae7b233bec1f706fad9ad.webp(
) 02 ###Transaction Sharding( تجزئة المعاملات
تتعلق مشاركة المعاملات بوضع قواعد حول "أي المعاملات يجب تخصيصها لأي مشاركة"، مما يمكن أن يحقق هدف المعالجة المتوازية ويتجنب ظهور مشكلة الإنفاق المزدوج. سيؤثر نموذج دفاتر الحسابات في blockchain على تطوير مشاركة المعاملات.
يوجد حاليًا نوعان من طرق المحاسبة في شبكة blockchain، وهما نموذج مخرجات المعاملات غير المنفقة UTXO) ونموذج الحساب/الرصيد، حيث يمثل الأول BTC، بينما تمثل ETH النموذج الثاني.
نموذج UTXO: في معاملات BTC، تحتوي كل معاملة على مخرجات واحدة أو أكثر، حيث تشير UTXO إلى مخرجات معاملات blockchain التي لم يتم إنفاقها بعد، ويمكن استخدامها كمدخلات لمعاملات جديدة، بينما لا يمكن إنفاق مخرجات المعاملات التي تم إنفاقها، مماثلة لحالة الدفع والبدل في معاملات الأوراق النقدية، حيث يدفع العميل ورقة نقدية واحدة أو أكثر للتاجر، ثم يقوم التاجر بإعادة ورقة نقدية واحدة أو أكثر كبدل للعميل. في نموذج UTXO، تحتاج تقسيمات المعاملات إلى تواصل عبر تقسيمات. قد تشمل المعاملة الواحدة مدخلات متعددة ومخرجات متعددة، ولا يوجد مفهوم للحسابات، ولا توجد سجلات للأرصدة، وأحد الطرق الممكنة هو: وضعها في دالة تجزئة بناءً على قيمة إدخال معينة من معاملتها لتحويلها إلى قيمة تجزئة منفصلة لتحديد البيانات التي يجب أن تذهب إلى أي تقسيم. كما يلي:
لضمان وضع الإدخالات بطريقة متسقة في المشاركات الصحيحة، يجب أن تأتي القيم المدخلة في دالة التجزئة من نفس العمود. يُطلق على هذا العمود اسم مفتاح التجزئة. بعد ذلك، يتم تصنيف المعاملات التي تنتج قيمة 1 في المشاركة 1، والمعاملات التي تنتج قيمة 2 في المشاركة 2. ومع ذلك، فإن عيب هذه الطريقة هو أنه يجب على المشاركات التواصل لتجنب هجمات الإنفاق المزدوج. إذا تم تقييد المعاملات عبر المشاركات، فإن ذلك سيقيد قابلية استخدام المنصة، بينما السماح بالمعاملات عبر المشاركات سيتطلب الموازنة بين تكلفة الاتصال عبر المشاركات والفوائد الناجمة عن تحسين الأداء.
نموذج الحساب / الرصيد: يسجل النظام رصيد كل حساب، وعند إجراء المعاملات، يتحقق النظام مما إذا كان لدى الحساب رصيد كافٍ للدفع، مثلما تفعل البنوك عند التحويلات البنكية، حيث تسجل كل بنك رصيد كل حساب، ولا يمكن إجراء المعاملة إلا إذا كان رصيد الحساب أكبر من المبلغ المطلوب للتحويل. تحت نموذج الحساب / الرصيد، نظراً لأن المعاملة تحتوي على إدخال واحد فقط، فإنه يكفي تقسيم المعاملة حسب عنوان المرسل، لضمان معالجة معاملات متعددة لنفس الحساب في نفس المشاركة، مما يمنع بشكل فعال ظاهرة الإنفاق المزدوج. لذلك، فإن معظم سلاسل الكتل التي تستخدم تقنية المشاركة هي أنظمة دفتر حسابات مثل إيثيريوم.
( 03 حالة مشاركة )State Sharding ###
تشير مشاركة الحالة إلى كيفية توزيع بيانات blockchain في تخزينها عبر مشاركات مختلفة.
لا يزال يستخدم مثال طابور Walmart لدينا، كيف يتم تسجيل دفاتر الحسابات في كل نافذة؟ إذا: جاء العميل للوقوف في أي طابور، يتم تسجيله في الحساب المقابل، على سبيل المثال، إذا ذهب العميل 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، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 9
أعجبني
9
5
مشاركة
تعليق
0/400
GasOptimizer
· منذ 3 س
غاز متى سينخفض إلى 2gwei؟ حسناً، لننتظر 5 سنوات أخرى لحل كامل.
Shardeum تدفع الابتكار في تقنية مشاركة وتستكشف مسارات جديدة لمشاركة الحالة الديناميكية
طريق الابتكار في تقنية المشاركة: Shardeum والمشاركة الديناميكية للحالة
في 15 سبتمبر 2022، أكملت إيثيريوم الدمج (Merge). كانت هذه لحظة تاريخية حيث استعدت إيثيريوم لذلك لمدة 5 سنوات، وتم تأجيلها 6 مرات. بسبب التطوير الطويل والاختبار، بالإضافة إلى تأثير الهالة الذي حظيت به، اعتقد الكثيرون خطأً أن الدمج سيؤدي بشكل طبيعي إلى زيادة القابلية للتوسع، والأمان، والاستدامة، لكن هذا ليس صحيحًا. الانتقال من PoW( إثبات العمل) إلى PoS( إثبات الحصة) هو مجرد تغيير للمسار والعجلات، ولن يؤدي مباشرة إلى سرعة أكبر، أو سعة أكبر، أو رسوم أقل. ما يمكن أن يحقق هذه الأهداف هو مجموعة كاملة من الحلول: شبكة رئيسية مع قدرة المشاركة إلى جانب حلول Layer2 التي تعزز القابلية للتوسع.
كما أشار مؤسس إيثريوم فيتاليك بوتيرين، فإن المشاركة هي حل للتوسع في ظل صعوبة التوسع الثلاثية، من خلال تقسيم العقد في الشبكة إلى مجموعات أصغر، ومعالجة مجموعات مختلفة من المعاملات وتنفيذ المعالجة المتوازية. من خلال تخفيف عبء معالجة كميات كبيرة من البيانات المطلوبة لتجميع الشبكة بأكملها، تمامًا كما هو الحال عندما نتسوق في وول مارت وندفع، من خلال فتح المزيد من ممرات الدفع، يمكن تقليل وقت الانتظار وزيادة كفاءة الدفع بشكل ملحوظ.
هذه هي منطق المشاركة، مباشر وبسيط، ومع ذلك، الشيطان يكمن في التفاصيل - المبدأ والاتجاه صحيحان، لكن في التنفيذ دائمًا ما تواجه العديد من المشاكل. تهدف هذه المقالة إلى ترتيب الاتجاهات والقيود على طريق "المشاركة"، ورسم خريطة لمستكشفي المشاركة الذين ينظرون إلى السماء ويقفون على الأرض. وفي الوقت نفسه، من خلال مقارنة الحلول الحالية للمشاركة، نجد بعض المشاكل المشتركة، ونقترح اتجاه استكشاف قابل للتطبيق: شاردوم والمشاركة الديناميكية.
أ. حول "مشاركة"
ببساطة، بالنظر إلى قيود مثلث الاستحالة، انطلاقًا من الإيثيريوم كنقطة الأصل (0،0)، وفقًا لطريقتين "عموديتين" و"أفقيتين"، نقسم طرق قابلية التوسع الحالية في البلوكشين إلى فئتين رئيسيتين:
التوسيع العمودي (: يتم تحقيقه عن طريق تحسين أداء الأجهزة الحالية للنظام. إنشاء شبكة لامركزية، حيث تمتلك كل عقدة في الشبكة قدرة حسابية فائقة، مما يعني أن كل عقدة تحتاج إلى "أفضل" الأجهزة - وهذه الطريقة بسيطة وفعالة، ويمكن أن تحقق تحسينًا أوليًا في معدل نقل البيانات، وهي مناسبة بشكل خاص للتداول عالي التردد، والألعاب، وغيرها من السيناريوهات التي تكون حساسة للتأخير. ومع ذلك، فإن هذا النوع من التوسيع سيقيد مستوى اللامركزية في الشبكة، لأن تكلفة تشغيل العقدة المصدقة أو العقدة الكاملة قد ارتفعت. الحفاظ على مستوى اللامركزية مقيد بمتوسط سرعة النمو في أداء الأجهزة الحاسوبية ) وهذا ما يسمى "قانون مور": عدد الترانزستورات على الشريحة يتضاعف كل عامين، وتتكلف الحسابات نصف التكلفة (.
التوسع الأفقي ) التوسع الأفقي (: عادة ما يكون هناك عدة أفكار للتوسع الأفقي. أحدها هو في سياق blockchain، توزيع كمية المعاملات على عدة blockchains مستقلة في نظام بيئي معين، حيث تمتلك كل سلسلة منتجي الكتل والقدرة على التنفيذ الخاصة بها، مما يسمح بتخصيص كامل لطبقة التنفيذ لكل سلسلة، مثل متطلبات الأجهزة للعقد، وميزات الخصوصية، ورسوم الغاز، والآلة الافتراضية، وإعدادات الإذن، وما إلى ذلك. خطة أخرى للتوسع الأفقي هي blockchain المعيارية، التي تقسم البنية التحتية لل blockchain إلى طبقة التنفيذ، وطبقة توفر البيانات ) DA ( وطبقة الإجماع. آلية blockchain المعيارية الأكثر شيوعًا هي rollup. هناك أيضًا طريقة لتقسيم blockchain إلى العديد من المشاركات، يتم تنفيذها بشكل متوازي. يمكن اعتبار كل مشاركة ك blockchain، مما يعني أن العديد من blockchains يمكن تنفيذها بشكل متوازي. بالإضافة إلى ذلك، عادة ما يكون هناك سلسلة رئيسية واحدة، تكون مهمتها الوحيدة هي الحفاظ على تزامن جميع المشاركات.
من الضروري الإشارة إلى أن أفكار التوسع المذكورة أعلاه ليست موجودة بشكل معزول، فكل حل من الحلول هو نقطة توازن تم العثور عليها في مثلث الاستحالة، حيث يتم تصميم آليات التحفيز التي تنشأ من القوى الاقتصادية في النظام لتحقيق توازن فعال على المستويين الكلي والجزئي.
لمناقشة "مشاركة"، نحتاج إلى إعادة整理 الأمور من البداية.
لا يزال نفترض هذا السيناريو،checkout في Walmart، لتحسين كفاءة checkout وتقليل وقت انتظار العملاء، قمنا بتوسيع من قناة checkout واحدة إلى 10 نوافذ checkout، لتجنب أخطاء الحساب، في هذا الوقت نحتاج إلى وضع قواعد موحدة:
أولاً، إذا كان لدينا 10 محصلين، كيف نقوم بتوزيعهم على أي نافذة للعمل؟
ثانياً، إذا كان لدينا 1000 عميل في الطابور في انتظار، كيف نقرر أي عميل يذهب إلى أي نافذة للدفع؟
ثالثًا، كيف يتم تجميع هذه 10 دفاتر حسابات منفصلة المرتبطة بالنوافذ العشرة؟
رابعًا، كيف يمكن منع حدوث أخطاء من قبل أمين الصندوق لتجنب حدوث عدم تطابق في الحسابات؟
هذه الأسئلة تتعلق في الواقع بعدة قضايا رئيسية في المشاركة، وهي:
كيف يمكن تحديد أي شريحة تنتمي إليها العقد/المدققون في الشبكة؟ أي: كيف يتم تنفيذ تقسيم الشبكة )NetworkSharding(؛
كيف يمكن تحديد كل معاملة تُخصص لأي مشاركة؟ أي: كيف يتم إجراء مشاركة المعاملات )Transaction Sharding(؛
كيف يتم تخزين بيانات البلوكشين في مشاركات مختلفة؟ أي: كيف يتم إجراء تقسيم الحالة )State Sharding(؛
تعني التعقيدات المخاطر، بناءً على كل ما سبق، كيف يمكن تجنب انقسام أمان النظام بأكمله؟
) 01 شبكة مشاركة###Network Sharding(
إذا فهمنا blockchain ببساطة على أنه دفتر أستاذ لامركزي، سواء كانت آلية توافق PoS أو PoW، فإنها تهدف إلى تمكين كل عقدة من التنافس على حق التسجيل وفقًا لقواعد محددة مسبقًا، مع ضمان صحة دفتر الأستاذ خلال هذه العملية. أما تقسيم الشبكة فهو يعني أنه يحتاج إلى قاعدة محددة أخرى، لتقسيم شبكة blockchain، مع تقليل التواصل المتبادل قدر الإمكان، بحيث تتعامل كل مشاركة مع المعاملات على السلسلة، وتتنافس على حق التسجيل - أي، قاعدة تجميع العقد.
وفي هذه العملية، تتمثل المشكلة التي نواجهها في أنه مع تقسيم العقد الداخلية في سلسلة الكتل إلى أجزاء مختلفة، ستنخفض صعوبة وكلفة الهجوم بشكل حاد. يمكننا أن نستنتج أنه إذا كانت قواعد ونتائج هذه العملية ثابتة وقابلة للتنبؤ، فإن المهاجم سيحتاج فقط إلى السيطرة على جزء واحد من شبكة سلسلة الكتل بأكملها، من خلال التحكم بشكل موجه في أحد الأجزاء وشراء بعض العقد داخل هذا الجزء.
وصف مؤسس Near ألكسندر سكيدانوف هذه المشكلة على النحو التالي: إذا قررت سلسلة واحدة تحتوي على X من المدققين الانقسام إلى سلسلة مشاركة ووزعت X من المدققين إلى 10 مشاركات، فإن كل مشاركة تحتوي الآن فقط على X/10 من المدققين، ويتطلب تدمير مشاركة واحدة تدمير 5.1%)51% / 10( من إجمالي عدد المدققين. هذا يؤدي إلى النقطة الثانية: من يختار المدققين لكل مشاركة؟ فقط عندما يكون جميع هؤلاء المدققين البالغ عددهم 5.1% في نفس المشاركة، فإن السيطرة على 5.1% من المدققين تكون ضارة. إذا لم يتمكن المدققون من اختيار المشاركة التي سيتم فيها التحقق، فإن احتمال أن يضع المشاركون الذين يتحكمون في 5.1% من المدققين جميع المدققين في نفس المشاركة يكون منخفضًا جدًا، مما يقلل بشكل كبير من قدرتهم على تدمير النظام.
يجب على نظام المشاركة تطوير آلية للثقة في أن الشبكة لن تعكس هذه المعاملات من مشاركات خارجية. حتى الآن، قد تكون أفضل إجابة هي ضمان أن عدد المدققين داخل المشاركة أعلى من عتبة دنيا معينة، مما يجعل فرص المدققين غير المخلصين في السيطرة على مشاركة واحدة منخفضة جداً. الطريقة الأكثر شيوعًا هي بناء مستوى معين من العشوائية غير المتحيزة، بالاعتماد على الرياضيات، لتقليل احتمال نجاح المهاجمين إلى الحد الأدنى. على سبيل المثال، الحل في الإيثيريوم هو اختيار مدقق لمشاركة معينة عشوائيًا من بين جميع المدققين، وتغيير المدققين كل 6.4 دقائق ) طول حقبة (.
بعبارة بسيطة، يتم تقسيم العقد بشكل عشوائي إلى مجموعات، ثم يتم توزيع العمل على كل مجموعة من العقد للتحقق بشكل مستقل.
ومع ذلك، من المهم الإشارة إلى أن العشوائية في blockchain هي موضوع يمثل تحديًا كبيرًا، ومن المنطقي أن عملية توليد هذا الرقم العشوائي لا ينبغي أن تعتمد على حساب أي مشاركة معينة. بالنسبة لهذا الحساب، فإن العديد من الأفكار التصميمية الحالية هي تطوير blockchain منفصل، للحفاظ على الشبكة بالكامل. تُعرف هذه السلسلة في Ethereum و Near بسلسلة Beacon، وفي PolkaDot بسلسلة Relay، وفي Cosmos تُعرف بمركز Cosmos.
![شرح مفصل حول سلسلة الكتل الجديدة Shardeum: مشاركة أخرى ممكنة])https://img-cdn.gateio.im/webp-social/moments-69c7de2bfe4ae7b233bec1f706fad9ad.webp(
) 02 ###Transaction Sharding( تجزئة المعاملات
تتعلق مشاركة المعاملات بوضع قواعد حول "أي المعاملات يجب تخصيصها لأي مشاركة"، مما يمكن أن يحقق هدف المعالجة المتوازية ويتجنب ظهور مشكلة الإنفاق المزدوج. سيؤثر نموذج دفاتر الحسابات في blockchain على تطوير مشاركة المعاملات.
يوجد حاليًا نوعان من طرق المحاسبة في شبكة blockchain، وهما نموذج مخرجات المعاملات غير المنفقة UTXO) ونموذج الحساب/الرصيد، حيث يمثل الأول BTC، بينما تمثل ETH النموذج الثاني.
نموذج UTXO: في معاملات BTC، تحتوي كل معاملة على مخرجات واحدة أو أكثر، حيث تشير UTXO إلى مخرجات معاملات blockchain التي لم يتم إنفاقها بعد، ويمكن استخدامها كمدخلات لمعاملات جديدة، بينما لا يمكن إنفاق مخرجات المعاملات التي تم إنفاقها، مماثلة لحالة الدفع والبدل في معاملات الأوراق النقدية، حيث يدفع العميل ورقة نقدية واحدة أو أكثر للتاجر، ثم يقوم التاجر بإعادة ورقة نقدية واحدة أو أكثر كبدل للعميل. في نموذج UTXO، تحتاج تقسيمات المعاملات إلى تواصل عبر تقسيمات. قد تشمل المعاملة الواحدة مدخلات متعددة ومخرجات متعددة، ولا يوجد مفهوم للحسابات، ولا توجد سجلات للأرصدة، وأحد الطرق الممكنة هو: وضعها في دالة تجزئة بناءً على قيمة إدخال معينة من معاملتها لتحويلها إلى قيمة تجزئة منفصلة لتحديد البيانات التي يجب أن تذهب إلى أي تقسيم. كما يلي:
لضمان وضع الإدخالات بطريقة متسقة في المشاركات الصحيحة، يجب أن تأتي القيم المدخلة في دالة التجزئة من نفس العمود. يُطلق على هذا العمود اسم مفتاح التجزئة. بعد ذلك، يتم تصنيف المعاملات التي تنتج قيمة 1 في المشاركة 1، والمعاملات التي تنتج قيمة 2 في المشاركة 2. ومع ذلك، فإن عيب هذه الطريقة هو أنه يجب على المشاركات التواصل لتجنب هجمات الإنفاق المزدوج. إذا تم تقييد المعاملات عبر المشاركات، فإن ذلك سيقيد قابلية استخدام المنصة، بينما السماح بالمعاملات عبر المشاركات سيتطلب الموازنة بين تكلفة الاتصال عبر المشاركات والفوائد الناجمة عن تحسين الأداء.
نموذج الحساب / الرصيد: يسجل النظام رصيد كل حساب، وعند إجراء المعاملات، يتحقق النظام مما إذا كان لدى الحساب رصيد كافٍ للدفع، مثلما تفعل البنوك عند التحويلات البنكية، حيث تسجل كل بنك رصيد كل حساب، ولا يمكن إجراء المعاملة إلا إذا كان رصيد الحساب أكبر من المبلغ المطلوب للتحويل. تحت نموذج الحساب / الرصيد، نظراً لأن المعاملة تحتوي على إدخال واحد فقط، فإنه يكفي تقسيم المعاملة حسب عنوان المرسل، لضمان معالجة معاملات متعددة لنفس الحساب في نفس المشاركة، مما يمنع بشكل فعال ظاهرة الإنفاق المزدوج. لذلك، فإن معظم سلاسل الكتل التي تستخدم تقنية المشاركة هي أنظمة دفتر حسابات مثل إيثيريوم.
( 03 حالة مشاركة )State Sharding ###
تشير مشاركة الحالة إلى كيفية توزيع بيانات blockchain في تخزينها عبر مشاركات مختلفة.
لا يزال يستخدم مثال طابور Walmart لدينا، كيف يتم تسجيل دفاتر الحسابات في كل نافذة؟ إذا: جاء العميل للوقوف في أي طابور، يتم تسجيله في الحساب المقابل، على سبيل المثال، إذا ذهب العميل A إلى نافذة A، ثم في اليوم التالي ذهب هذا العميل إلى نافذة أخرى مثل نافذة B، وليس لدى نافذة B معلومات الحساب السابقة لهذا العميل ( مثل تلك المتعلقة ببطاقات القيمة المخزنة وطرق الدفع الأخرى )، ماذا يجب أن نفعل؟ هل يجب استدعاء معلومات حساب هذا العميل من نافذة A؟
تعد حالة المشاركة أكبر تحدٍ في المشاركة، حيث إنها أكثر تعقيدًا من مشاركة الشبكة ومشاركة المعاملات المذكورة أعلاه. لأنه في آلية المشاركة، ستتم معالجة المعاملات بناءً على العناوين المخصصة في شرائح مختلفة، مما يعني أن الحالة ستظل محفوظة فقط في الشريحة التي توجد بها عنوانها، وفي هذه الحالة، فإن المشكلة التي يجب مواجهتها هي أن المعاملات لن تحدث فقط في شريحة واحدة، بل ستشمل غالبًا المشاركة عبر الشريحة (Cross-Sharding).
فكر في حالة تحويل، حيث يقوم حساب A بتحويل 10U إلى حساب B، وعنوان A مخصص في مشاركة 1، وسجل المعاملة سيتم تخزينه أيضًا في مشاركة 1. عنوان B مخصص في مشاركة 2، وسجل المعاملة سيتم تخزينه في مشاركة 2.
عندما يريد A تحويل الأموال إلى B، سيتم إنشاء معاملة عبر مشاركة، وستقوم مشاركة 2 بالاتصال بسجل المعاملات السابق في مشاركة 1 للتحقق من صحة المعاملة، إذا كان A يرسل الأموال بشكل متكرر إلى B، يجب على مشاركة 2 التفاعل باستمرار مع مشاركة 1، مما يقلل من كفاءة معالجة المعاملات. ومع ذلك، إذا لم يتم تنزيل والتحقق من التاريخ الكامل لمشاركة معينة، فقد لا يتمكن المشاركون من التأكد من أن حالة تفاعلهم هي نتيجة تسلسل كتل معينة صالحة، وأن هذا التسلسل من الكتل هو بالفعل السلسلة القياسية في المشاركة.
لذلك، مقارنة بالسلسلة الواحدة بدون مشاركة، التحدي الجديد الذي يواجهه نظام المشاركة هو عدم وجود مستخدمين