Shardeum و حالة المشاركة الديناميكية: إمكانية أخرى لاستكشاف المشاركة
في 15 سبتمبر 2022، أكملت الإيثيريوم الدمج المنتظر منذ فترة طويلة (Merge). تمثل هذه اللحظة التاريخية انتقال الإيثيريوم من إثبات العمل (PoW) إلى إثبات الحصة (PoS)، حيث أعد فريق الإيثيريوم لذلك لمدة 5 سنوات، وأجّلوا 6 مرات. ومع ذلك، يعتقد العديد من الناس خطأً أن الدمج سيؤدي بشكل طبيعي إلى زيادة قابلية التوسع والأمان والاستدامة، لكن هذا ليس صحيحًا. الدمج هو مجرد تغيير "المسار والعجلات"، ولن يؤدي مباشرة إلى سرعة أكبر أو سعة أكبر أو تكاليف أقل. ما يمكنه تحقيق هذه الأهداف هو مجموعة كاملة من الحلول: شبكة رئيسية تتمتع بقدرة مشاركة بالتزامن مع حلول Layer2 المعززة لقابلية التوسع.
كما أشار مؤسس الإيثيريوم فيتاليك بوتيرين، فإن المشاركة هي حل للتوسع في ظل معضلة الثلاثة الصعبة للتوسع. من خلال تقسيم العقد في الشبكة إلى مجموعات أصغر، تعالج مجموعات مختلفة من المعاملات وتحقق المعالجة المتوازية. من خلال تخفيف العبء الناتج عن معالجة كميات كبيرة من البيانات المطلوبة للتجميع في الشبكة بأكملها، كما هو الحال عندما نتسوق في السوبرماركت ونتوجه إلى الدفع، من خلال فتح عدة نقاط دفع، يمكن تقليل وقت الانتظار وزيادة كفاءة الدفع بشكل واضح.
هذه هي المنطق الأساسي لمشاركة، بسيط ومباشر. ومع ذلك، الشيطان يكمن في التفاصيل - المبادئ والاتجاهات صحيحة، ولكن في التنفيذ دائماً ما تواجه العديد من المشكلات. يهدف هذا المقال إلى توضيح الاتجاهات والصعوبات على طريق "مشاركة"، ورسم خريطة لمستكشفي المشاركة. في نفس الوقت من خلال مقارنة الحلول الحالية لمشاركة، نجد بعض القضايا المشتركة، ونقترح اتجاه استكشاف قابلاً للتطبيق: شاردوم ومشاركة الديناميكية.
أولاً، حول "مشاركة"
ببساطة، بالنظر إلى قيود مثلث الاستحالة، انطلاقًا من الإيثيريوم كنقطة الأصل في نظام الإحداثيات (، 0،0)، وفقًا لفكرتين "عموديتين" و"أفقيتين"، نقسم طرق قابلية التوسع الحالية في blockchain إلى فئتين رئيسيتين:
التحجيم العمودي (Vertical Scaling): يتم تحقيقه من خلال تحسين أداء الأجهزة الحالية للنظام. إنشاء شبكة لامركزية، حيث تمتلك كل عقدة في الشبكة قدرة حسابية فائقة، أي أن كل عقدة تحتاج إلى "أفضل" أجهزة. هذه الطريقة بسيطة وفعالة، ويمكن أن تحقق تحسيناً أولياً في معدل النقل، خاصةً في التداول عالي التردد، والألعاب، وغيرها من السيناريوهات التطبيقية الحساسة للزمن. ومع ذلك، فإن هذه الطريقة في التحجيم ستقيد مستوى اللامركزية في الشبكة، لأن تكلفة تشغيل عقد التحقق أو العقد الكاملة قد ارتفعت. الحفاظ على مستوى اللامركزية مقيد بمعدل النمو العام في أداء الأجهزة الحاسوبية ( وهذا ما يعرف بـ "قانون مور": عدد الترانزستورات على الرقاقة يتضاعف كل عامين، بينما تتقلص تكلفة الحساب إلى النصف ).
التوسع الأفقي(Horizontal Scaling): التوسع الأفقي عادة ما يكون له عدة أفكار. واحدة منها في سياق blockchain، هي توزيع حجم المعاملات الحسابية ضمن نظام بيئي معين على عدة blockchains مستقلة، حيث تمتلك كل سلسلة منتجي الكتل وقدرات التنفيذ الخاصة بها، مما يسمح بتخصيص كامل لطبقة التنفيذ لكل سلسلة، مثل متطلبات الأجهزة للعقد، ميزات الخصوصية، رسوم الغاز، آلة افتراضية، وإعدادات الأذونات. فكرة أخرى للتوسع الأفقي هي blockchain المودولية، حيث يتم تقسيم البنية التحتية للـ blockchain إلى طبقة تنفيذ، طبقة توافر البيانات(DA) وطبقة توافق. أكثر آليات المودولية شيوعًا في blockchain هي rollup. وهناك فكرة أخرى وهي تقسيم blockchain واحد إلى عدة أجزاء، وتنفيذها بشكل متوازي. يمكن اعتبار كل جزء كـ blockchain، مما يعني أن العديد من blockchains يمكن أن تعمل بشكل متوازي. بالإضافة إلى ذلك، عادة ما يكون هناك سلسلة رئيسية واحدة، مهمتها الوحيدة هي الحفاظ على تزامن جميع الأجزاء.
من الضروري الإشارة إلى أن أفكار التوسع المذكورة أعلاه ليست موجودة بشكل معزول، فكل حل من الحلول يمثل نقطة توازن تم العثور عليها ضمن مثلث الاستحالة، مع تصميم آليات التحفيز التي أنشأتها القوى الاقتصادية في النظام، لتحقيق توازن فعال على المستويين الكلي والجزئي.
للمناقشة حول "مشاركة"، نحتاج إلى البدء من الصفر.
لا يزال نفترض هذا السيناريو، التسوق في السوبر ماركت والدفع، من أجل تحسين كفاءة الدفع وتقليل وقت انتظار العملاء، قمنا بتوسيع من ممر دفع واحد إلى 10 نوافذ دفع. لتجنب أخطاء السجلات، في هذه المرحلة نحتاج إلى وضع قواعد موحدة:
أولاً، إذا كان لدينا 10 خزنة، كيف نوزعهم على أي نافذة للعمل؟
ثانياً، إذا كان لدينا 1000 عميل في صف الانتظار، كيف نحدد أي عميل يذهب إلى أي نافذة للدفع؟
ثالثًا، كيف يمكن تلخيص هذه 10 دفاتر منفصلة المقابلة لـ 10 نوافذ؟
رابعًا، كيف يمكن منع حدوث أخطاء من قبل الصرافين لتجنب حالات عدم تطابق الحسابات؟
هذه الأسئلة تتعلق في الواقع بعدة مسائل رئيسية في المشاركة، وهي:
كيف يمكن تحديد إلى أي مشاركة تنتمي عقد/متحقق الشبكة بالكامل؟ أي: كيف يتم تنفيذ تقسيم الشبكة (Network Sharding)؛
كيف يمكن تحديد أي جزء من المشاركة يتم تخصيصه لكل معاملة؟ أي: كيف يتم إجراء مشاركة المعاملة (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 Hub.
![شرح مفصل عن البلوكتشين الجديد Shardeum: مشاركة أخرى محتملة])https://img-cdn.gateio.im/webp-social/moments-6e8d3331d7d68cb512eb2eb47bd9064d.webp(
) 02 ###Transaction Sharding( تجزئة المعاملات
تشير مشاركة المعاملات إلى وضع قواعد حول "أي المعاملات يجب تخصيصها لأي مشاركة"، مما يمكن أن يحقق هدف المعالجة المتوازية ويتجنب ظهور مشكلة الإنفاق المزدوج. سيؤثر اختلاف نماذج دفتر الأستاذ في سلسلة الكتل على تطوير مشاركة المعاملات.
يوجد حاليًا نوعان من طرق المحاسبة في شبكة blockchain، وهما نموذج مخرجات المعاملات غير المنفقة UTXO) ونموذج الحساب / الرصيد. الممثل النموذجي للأول هو BTC، بينما الثاني مثل ETH.
نموذج UTXO: في معاملات BTC، تحتوي كل معاملة على مخرجات واحدة أو أكثر، حيث تشير UTXO إلى المخرجات غير المنفقة من معاملات سلسلة الكتل، والتي يمكن استخدامها كمدخلات لمعاملات جديدة، بينما لا يمكن إنفاق المخرجات التي تم إنفاقها مرة أخرى، وهو مشابه لحالة الدفع والعودة في معاملات الأوراق النقدية، حيث يقوم العميل بدفع ورقة نقدية واحدة أو أكثر للتاجر، ثم يُعيد التاجر ورقة نقدية واحدة أو أكثر كعودة للعميل. في نموذج UTXO، تحتاج معاملات المشاركة إلى التواصل عبر المشاركات. قد تتضمن المعاملة الواحدة عدة مدخلات ومخرجات، ولا يوجد مفهوم للحسابات، كما لن يكون هناك سجل للأرصدة. إحدى الطرق الممكنة هي: وضعها في دالة تجزئة وفقًا لقيمة مدخلاتها لتصبح قيمة تجزئة منفصلة لتحديد إلى أي مشاركة يجب أن تذهب البيانات.
للتأكد من وضع الإدخالات بطريقة متسقة في الشريحة الصحيحة، يجب أن تأتي القيم المدخلة في دالة التجزئة من نفس العمود. يُطلق على هذا العمود اسم مفتاح الشريحة. بعد ذلك، يتم توزيع المعاملات التي تنتج قيمة 1 إلى الشريحة 1، والمعاملات التي تنتج قيمة 2 إلى الشريحة 2. ومع ذلك، فإن عيب هذه الطريقة هو أن الشرائح يجب أن تتواصل لتجنب هجمات الإنفاق المزدوج. إذا تم تقييد المعاملات عبر الشرائح، فسوف يحد ذلك من توفر المنصة، بينما السماح بالمعاملات عبر الشرائح يتطلب الموازنة بين تكلفة الاتصال عبر الشرائح والفوائد الناتجة عن تحسين الأداء.
نموذج الحساب / الرصيد: يقوم النظام بتسجيل رصيد كل حساب، وعند إجراء المعاملات، يتحقق النظام مما إذا كان لدى الحساب رصيد كافٍ للدفع، مشابهًا لتحويلات البنك، حيث يسجل البنك رصيد كل حساب، ولا يمكن إجراء المعاملة إلا إذا كان رصيد الحساب أكبر من مبلغ التحويل المطلوب. في نموذج الحساب / الرصيد، نظرًا لأن المعاملة تحتوي على إدخال واحد فقط، فإنه يكفي تقسيم المعاملة وفقًا لعنوان المرسل، لضمان معالجة المعاملات المتعددة لنفس الحساب في نفس المشاركة، مما يمنع بشكل فعال الإنفاق المزدوج. لذلك، فإن معظم سلاسل الكتل التي تعتمد على تقنية المشاركة هي أنظمة دفتر حسابات مثل إيثيريوم.
( 03 حالة مشاركة )State Sharding ###
تشير حالة المشاركة إلى كيفية توزيع البيانات على البلوكشين للتخزين في مشاركات مختلفة.
لا يزال نستخدم مثال الطوابير في سوبرماركتنا، كل نافذة لديها حساب، كيف يتم تسجيل دفاترهم؟ إذا: جاء العميل للوقوف في أي طابور، يتم تسجيله في ذلك الحساب، على سبيل المثال، إذا ذهب العميل 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، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 7
أعجبني
7
4
إعادة النشر
مشاركة
تعليق
0/400
ThreeHornBlasts
· 08-09 22:54
مرة أخرى بدأ الثور في الهراء.
شاهد النسخة الأصليةرد0
CrossChainBreather
· 08-09 22:52
هل انتهى الدمج؟ لا يزال لا يمكن تشغيله.
شاهد النسخة الأصليةرد0
DecentralizeMe
· 08-09 22:39
خمس سنوات من التحضير، ماذا تفعلون، هل انفجر الأمر؟
Shardeum: استكشاف حالة ديناميكية مشاركة للاتجاه الجديد لتوسيع البلوكتشين
Shardeum و حالة المشاركة الديناميكية: إمكانية أخرى لاستكشاف المشاركة
في 15 سبتمبر 2022، أكملت الإيثيريوم الدمج المنتظر منذ فترة طويلة (Merge). تمثل هذه اللحظة التاريخية انتقال الإيثيريوم من إثبات العمل (PoW) إلى إثبات الحصة (PoS)، حيث أعد فريق الإيثيريوم لذلك لمدة 5 سنوات، وأجّلوا 6 مرات. ومع ذلك، يعتقد العديد من الناس خطأً أن الدمج سيؤدي بشكل طبيعي إلى زيادة قابلية التوسع والأمان والاستدامة، لكن هذا ليس صحيحًا. الدمج هو مجرد تغيير "المسار والعجلات"، ولن يؤدي مباشرة إلى سرعة أكبر أو سعة أكبر أو تكاليف أقل. ما يمكنه تحقيق هذه الأهداف هو مجموعة كاملة من الحلول: شبكة رئيسية تتمتع بقدرة مشاركة بالتزامن مع حلول Layer2 المعززة لقابلية التوسع.
كما أشار مؤسس الإيثيريوم فيتاليك بوتيرين، فإن المشاركة هي حل للتوسع في ظل معضلة الثلاثة الصعبة للتوسع. من خلال تقسيم العقد في الشبكة إلى مجموعات أصغر، تعالج مجموعات مختلفة من المعاملات وتحقق المعالجة المتوازية. من خلال تخفيف العبء الناتج عن معالجة كميات كبيرة من البيانات المطلوبة للتجميع في الشبكة بأكملها، كما هو الحال عندما نتسوق في السوبرماركت ونتوجه إلى الدفع، من خلال فتح عدة نقاط دفع، يمكن تقليل وقت الانتظار وزيادة كفاءة الدفع بشكل واضح.
هذه هي المنطق الأساسي لمشاركة، بسيط ومباشر. ومع ذلك، الشيطان يكمن في التفاصيل - المبادئ والاتجاهات صحيحة، ولكن في التنفيذ دائماً ما تواجه العديد من المشكلات. يهدف هذا المقال إلى توضيح الاتجاهات والصعوبات على طريق "مشاركة"، ورسم خريطة لمستكشفي المشاركة. في نفس الوقت من خلال مقارنة الحلول الحالية لمشاركة، نجد بعض القضايا المشتركة، ونقترح اتجاه استكشاف قابلاً للتطبيق: شاردوم ومشاركة الديناميكية.
أولاً، حول "مشاركة"
ببساطة، بالنظر إلى قيود مثلث الاستحالة، انطلاقًا من الإيثيريوم كنقطة الأصل في نظام الإحداثيات (، 0،0)، وفقًا لفكرتين "عموديتين" و"أفقيتين"، نقسم طرق قابلية التوسع الحالية في blockchain إلى فئتين رئيسيتين:
التحجيم العمودي (Vertical Scaling): يتم تحقيقه من خلال تحسين أداء الأجهزة الحالية للنظام. إنشاء شبكة لامركزية، حيث تمتلك كل عقدة في الشبكة قدرة حسابية فائقة، أي أن كل عقدة تحتاج إلى "أفضل" أجهزة. هذه الطريقة بسيطة وفعالة، ويمكن أن تحقق تحسيناً أولياً في معدل النقل، خاصةً في التداول عالي التردد، والألعاب، وغيرها من السيناريوهات التطبيقية الحساسة للزمن. ومع ذلك، فإن هذه الطريقة في التحجيم ستقيد مستوى اللامركزية في الشبكة، لأن تكلفة تشغيل عقد التحقق أو العقد الكاملة قد ارتفعت. الحفاظ على مستوى اللامركزية مقيد بمعدل النمو العام في أداء الأجهزة الحاسوبية ( وهذا ما يعرف بـ "قانون مور": عدد الترانزستورات على الرقاقة يتضاعف كل عامين، بينما تتقلص تكلفة الحساب إلى النصف ).
التوسع الأفقي(Horizontal Scaling): التوسع الأفقي عادة ما يكون له عدة أفكار. واحدة منها في سياق blockchain، هي توزيع حجم المعاملات الحسابية ضمن نظام بيئي معين على عدة blockchains مستقلة، حيث تمتلك كل سلسلة منتجي الكتل وقدرات التنفيذ الخاصة بها، مما يسمح بتخصيص كامل لطبقة التنفيذ لكل سلسلة، مثل متطلبات الأجهزة للعقد، ميزات الخصوصية، رسوم الغاز، آلة افتراضية، وإعدادات الأذونات. فكرة أخرى للتوسع الأفقي هي blockchain المودولية، حيث يتم تقسيم البنية التحتية للـ blockchain إلى طبقة تنفيذ، طبقة توافر البيانات(DA) وطبقة توافق. أكثر آليات المودولية شيوعًا في blockchain هي rollup. وهناك فكرة أخرى وهي تقسيم blockchain واحد إلى عدة أجزاء، وتنفيذها بشكل متوازي. يمكن اعتبار كل جزء كـ blockchain، مما يعني أن العديد من blockchains يمكن أن تعمل بشكل متوازي. بالإضافة إلى ذلك، عادة ما يكون هناك سلسلة رئيسية واحدة، مهمتها الوحيدة هي الحفاظ على تزامن جميع الأجزاء.
من الضروري الإشارة إلى أن أفكار التوسع المذكورة أعلاه ليست موجودة بشكل معزول، فكل حل من الحلول يمثل نقطة توازن تم العثور عليها ضمن مثلث الاستحالة، مع تصميم آليات التحفيز التي أنشأتها القوى الاقتصادية في النظام، لتحقيق توازن فعال على المستويين الكلي والجزئي.
للمناقشة حول "مشاركة"، نحتاج إلى البدء من الصفر.
لا يزال نفترض هذا السيناريو، التسوق في السوبر ماركت والدفع، من أجل تحسين كفاءة الدفع وتقليل وقت انتظار العملاء، قمنا بتوسيع من ممر دفع واحد إلى 10 نوافذ دفع. لتجنب أخطاء السجلات، في هذه المرحلة نحتاج إلى وضع قواعد موحدة:
أولاً، إذا كان لدينا 10 خزنة، كيف نوزعهم على أي نافذة للعمل؟
ثانياً، إذا كان لدينا 1000 عميل في صف الانتظار، كيف نحدد أي عميل يذهب إلى أي نافذة للدفع؟
ثالثًا، كيف يمكن تلخيص هذه 10 دفاتر منفصلة المقابلة لـ 10 نوافذ؟
رابعًا، كيف يمكن منع حدوث أخطاء من قبل الصرافين لتجنب حالات عدم تطابق الحسابات؟
هذه الأسئلة تتعلق في الواقع بعدة مسائل رئيسية في المشاركة، وهي:
كيف يمكن تحديد إلى أي مشاركة تنتمي عقد/متحقق الشبكة بالكامل؟ أي: كيف يتم تنفيذ تقسيم الشبكة (Network Sharding)؛
كيف يمكن تحديد أي جزء من المشاركة يتم تخصيصه لكل معاملة؟ أي: كيف يتم إجراء مشاركة المعاملة (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 Hub.
![شرح مفصل عن البلوكتشين الجديد Shardeum: مشاركة أخرى محتملة])https://img-cdn.gateio.im/webp-social/moments-6e8d3331d7d68cb512eb2eb47bd9064d.webp(
) 02 ###Transaction Sharding( تجزئة المعاملات
تشير مشاركة المعاملات إلى وضع قواعد حول "أي المعاملات يجب تخصيصها لأي مشاركة"، مما يمكن أن يحقق هدف المعالجة المتوازية ويتجنب ظهور مشكلة الإنفاق المزدوج. سيؤثر اختلاف نماذج دفتر الأستاذ في سلسلة الكتل على تطوير مشاركة المعاملات.
يوجد حاليًا نوعان من طرق المحاسبة في شبكة blockchain، وهما نموذج مخرجات المعاملات غير المنفقة UTXO) ونموذج الحساب / الرصيد. الممثل النموذجي للأول هو BTC، بينما الثاني مثل ETH.
نموذج UTXO: في معاملات BTC، تحتوي كل معاملة على مخرجات واحدة أو أكثر، حيث تشير UTXO إلى المخرجات غير المنفقة من معاملات سلسلة الكتل، والتي يمكن استخدامها كمدخلات لمعاملات جديدة، بينما لا يمكن إنفاق المخرجات التي تم إنفاقها مرة أخرى، وهو مشابه لحالة الدفع والعودة في معاملات الأوراق النقدية، حيث يقوم العميل بدفع ورقة نقدية واحدة أو أكثر للتاجر، ثم يُعيد التاجر ورقة نقدية واحدة أو أكثر كعودة للعميل. في نموذج UTXO، تحتاج معاملات المشاركة إلى التواصل عبر المشاركات. قد تتضمن المعاملة الواحدة عدة مدخلات ومخرجات، ولا يوجد مفهوم للحسابات، كما لن يكون هناك سجل للأرصدة. إحدى الطرق الممكنة هي: وضعها في دالة تجزئة وفقًا لقيمة مدخلاتها لتصبح قيمة تجزئة منفصلة لتحديد إلى أي مشاركة يجب أن تذهب البيانات.
للتأكد من وضع الإدخالات بطريقة متسقة في الشريحة الصحيحة، يجب أن تأتي القيم المدخلة في دالة التجزئة من نفس العمود. يُطلق على هذا العمود اسم مفتاح الشريحة. بعد ذلك، يتم توزيع المعاملات التي تنتج قيمة 1 إلى الشريحة 1، والمعاملات التي تنتج قيمة 2 إلى الشريحة 2. ومع ذلك، فإن عيب هذه الطريقة هو أن الشرائح يجب أن تتواصل لتجنب هجمات الإنفاق المزدوج. إذا تم تقييد المعاملات عبر الشرائح، فسوف يحد ذلك من توفر المنصة، بينما السماح بالمعاملات عبر الشرائح يتطلب الموازنة بين تكلفة الاتصال عبر الشرائح والفوائد الناتجة عن تحسين الأداء.
نموذج الحساب / الرصيد: يقوم النظام بتسجيل رصيد كل حساب، وعند إجراء المعاملات، يتحقق النظام مما إذا كان لدى الحساب رصيد كافٍ للدفع، مشابهًا لتحويلات البنك، حيث يسجل البنك رصيد كل حساب، ولا يمكن إجراء المعاملة إلا إذا كان رصيد الحساب أكبر من مبلغ التحويل المطلوب. في نموذج الحساب / الرصيد، نظرًا لأن المعاملة تحتوي على إدخال واحد فقط، فإنه يكفي تقسيم المعاملة وفقًا لعنوان المرسل، لضمان معالجة المعاملات المتعددة لنفس الحساب في نفس المشاركة، مما يمنع بشكل فعال الإنفاق المزدوج. لذلك، فإن معظم سلاسل الكتل التي تعتمد على تقنية المشاركة هي أنظمة دفتر حسابات مثل إيثيريوم.
( 03 حالة مشاركة )State Sharding ###
تشير حالة المشاركة إلى كيفية توزيع البيانات على البلوكشين للتخزين في مشاركات مختلفة.
لا يزال نستخدم مثال الطوابير في سوبرماركتنا، كل نافذة لديها حساب، كيف يتم تسجيل دفاترهم؟ إذا: جاء العميل للوقوف في أي طابور، يتم تسجيله في ذلك الحساب، على سبيل المثال، إذا ذهب العميل A إلى النافذة A، وفي اليوم التالي ذهب العميل إلى نافذة دفع أخرى مثل النافذة B، ولم يكن لدى النافذة B معلومات الحساب السابقة لذلك العميل ( مثل ما يتعلق ببطاقة القيمة المخزنة وطرق الدفع الأخرى )، ماذا نفعل؟ هل يجب استدعاء معلومات حساب ذلك العميل من النافذة A؟
تعتبر حالة المشاركة أكبر تحدٍ في المشاركة، وأكثر تعقيدًا من تقسيم الشبكة وتقسيم المعاملات المذكورة أعلاه. لأنه في آلية المشاركة، سيتم معالجة المعاملات بناءً على العنوان المخصص في أجزاء مختلفة، مما يعني أن الحالة ستظل محفوظة فقط في الجزء الذي يقع فيه عنوانها. في هذه الحالة، تواجه مشكلة تتمثل في أن المعاملات لا تتم فقط في جزء واحد، بل غالبًا ما تتعلق بالمشاركة عبر الأجزاء (Cross-Sharding).
فكر في حالة تحويل، يقوم حساب A بتحويل 10U إلى حساب B، بينما يتم تخصيص عنوان A في مشاركة 1، وسيتم تخزين سجل المعاملة أيضًا في مشاركة 1. يتم تخصيص عنوان B في مشاركة 2، وسيتم تخزين سجل المعاملة في مشاركة 2.
عندما يريد A تحويل المال إلى B، سيحدث تبادل عبر مشاركة، وستقوم مشاركة 2 باستدعاء سجلات المعاملات السابقة من مشاركة 1، للتحقق من صحة المعاملة. إذا كان A يقوم بتحويل الأموال بشكل متكرر إلى B، فستحتاج مشاركة 2 إلى التفاعل باستمرار مع مشاركة 1، مما يؤدي إلى تقليل كفاءة معالجة المعاملات. ولكن، إذا لم يكن...