مشاركة التقنية: الاحتمال الآخر لزيادة حجم البلوكتشين
في 15 سبتمبر 2022، أكملت الإيثريوم الدمج (Merge). كانت هذه لحظة تاريخية، حيث استعدت الإيثريوم لذلك لمدة 5 سنوات، وتأجلت 6 مرات. بسبب التطوير الطويل والاهتمام الواسع، اعتقد الكثيرون أن الدمج سيجلب ببساطة قابلية توسيع وأمان واستدامة أعلى، لكن هذا ليس صحيحاً. الانتقال من إثبات العمل (PoW) إلى إثبات الحصة (PoS) هو مجرد تغيير في "المسار والعجلات"، ولن يؤدي مباشرة إلى سرعة أكبر أو سعة أكبر أو رسوم أقل. ما يمكن أن يحقق هذه الأهداف حقًا هو مجموعة كاملة من الحلول: شبكة رئيسية ذات قدرة على المشاركة مصحوبة بحلول Layer2 المعززة للقابلية للتوسع.
كما أشار مؤسس الإيثريوم فيتاليك بوتيرين، فإن المشاركة هي حل للتوسع ضمن معضلة الثلاثة صعوبات المتعلقة بالقدرة. من خلال تقسيم العقد في الشبكة إلى مجموعات أصغر، يتم معالجة مجموعات مختلفة من المعاملات وتحقيق المعالجة المتوازية. يشبه ذلك عند التسوق في وول مارت، من خلال فتح المزيد من ممرات الدفع، يمكن تقليل وقت الانتظار وزيادة كفاءة الدفع.
هذه هي منطق المشاركة، مباشر وبسيط، لكن الشيطان يكمن في التفاصيل. المبدأ والاتجاه صحيحان، لكن في التنفيذ ستواجه دائمًا الكثير من المشكلات. تهدف هذه المقالة إلى توضيح الاتجاهات والمشكلات على طريق "المشاركة"، ورسم خريطة لمستكشفي المشاركة الذين ينظرون إلى السماء بينما يقفون على الأرض. في الوقت نفسه، من خلال مقارنة الحلول الحالية للمشاركة، سيتم العثور على بعض المشكلات المشتركة، وتقديم اتجاه استكشاف قابل للتطبيق: Shardeum والمشاركة الديناميكية.
أ. حول "مشاركة"
ببساطة، بالنظر إلى قيود مثلث الاستحالة، بدءًا من الإيثيريوم كنقطة الأصل (، 0)، وفقًا لفكرتين "طولية" و"عرضية"، نقسم طرق توسيع البلوكتشين الحالية إلى فئتين رئيسيتين:
التوسع العمودي (: يتم تحقيقه من خلال تحسين أداء الأجهزة الحالية في النظام. إنشاء شبكة لامركزية، حيث يتمتع كل عقدة في الشبكة بقدرات حسابية فائقة، مما يعني أن كل عقدة تحتاج إلى "أجهزة أفضل". هذه الطريقة بسيطة وفعالة، ويمكن أن تحقق تحسينًا أوليًا في معدل نقل البيانات، خاصةً في حالات التداول عالي التردد، والألعاب، وغيرها من التطبيقات الحساسة للتأخير. ومع ذلك، فإن هذه الطريقة في التوسع ستقيد مستوى اللامركزية في الشبكة، لأن تكلفة تشغيل عقد التحقق أو العقد الكاملة قد زادت. الحفاظ على مستوى اللامركزية مقيد بمعدل النمو التقريبي في أداء الأجهزة الحاسوبية ) وهذا ما يُعرف باسم "قانون مور": عدد الترانزستورات على الشريحة يتضاعف كل عامين، وتكلفة الحوسبة تنخفض إلى النصف (.
التوسع الأفقي ) التوسع الأفقي (: يوجد عادةً عدة أفكار للتوسع الأفقي. واحدة منها هي في سياق البلوكتشين، حيث يتم توزيع كمية حسابات المعاملات في نظام بيئي معين على عدة بلوكتشينات مستقلة، حيث تمتلك كل سلسلة منتجي كتل وقدرات تنفيذ خاصة بها، ويمكن تخصيص طبقة التنفيذ لكل سلسلة بشكل كامل، مثل متطلبات أجهزة العقد، وظائف الخصوصية، رسوم الغاز، الآلات الافتراضية وإعدادات الأذونات، وغيرها. خطة التوسع الأفقي الأخرى هي البلوكتشين المعيارية، حيث يتم تقسيم بنية البلوكتشين إلى طبقة تنفيذ، طبقة توفر البيانات ) DA ( وطبقة توافق. الآلية المعيارية الأكثر شيوعاً في البلوكتشين هي الـ rollup. وهناك نوع آخر هو تقسيم بلوكتشين واحد إلى عدة أجزاء، وتنفيذها بشكل متوازي. يمكن اعتبار كل جزء بمثابة بلوكتشين، مما يعني أن العديد من البلوكتشينات يمكن أن تعمل بالتوازي. بالإضافة إلى ذلك، عادةً ما يكون هناك سلسلة رئيسية واحدة، تكون مهمتها الوحيدة هي الحفاظ على تزامن جميع الأجزاء.
![شرح مفصل عن البلوكتشين الجديد Shardeum: احتمال آخر للمشاركة])https://img-cdn.gateio.im/webp-social/moments-7aa1677db6b8128b68accfe04fcda738.webp(
من المهم الإشارة إلى أن الأفكار المذكورة أعلاه لتوسيع القدرة ليست موجودة بشكل منفصل، فكل حل من الحلول هو نقطة توازن تم العثور عليها في مثلث الاستحالة، بالتعاون مع تصميم آلية الحوافز التي تخلقها القوى الاقتصادية في النظام، لتحقيق توازن فعال على المستويين الكلي والجزئي.
للنقاش حول "مشاركة"، نحتاج إلى إعادة تنظيم الأمور من البداية.
لا يزال نفترض هذا السيناريو، عند الدفع في وول مارت، من أجل تحسين كفاءة الدفع وتقليل وقت انتظار العملاء، نحن ممتدون من قناة دفع واحدة إلى 10 نوافذ دفع، لتجنب أخطاء السجل، في هذه الحالة نحتاج إلى وضع قواعد موحدة:
أولاً، إذا كان لدينا 10 أمين صندوق، كيف نوزعهم على أي نافذة للعمل؟
ثانياً، إذا كان لدينا 1000 عميل في طابور الانتظار، كيف نقرر أي عميل يذهب إلى أي نافذة للدفع؟
ثالثاً، كيف يمكن تلخيص دفاتر الحسابات العشرة المنفصلة المرتبطة بالعشرة نوافذ هذه؟
رابعًا، كيف يمكن تجنب وقوع أخطاء من قبل أمين الصندوق لتفادي حدوث عدم تطابق في الحسابات؟
هذه الأسئلة تتعلق في الواقع بعدة مسائل رئيسية في المشاركة، وهي على التوالي:
كيف يمكن تحديد أي جزء من الشبكة ينتمي إليه العقد/المتحققون في الشبكة؟ أي: كيف يتم إجراء مشاركة الشبكة )Network Sharding(;
كيف يمكن تحديد أي شريحة تم تخصيصها لكل معاملة؟ أي: كيفية إجراء تقسيم معاملات )Transaction Sharding(؛
كيف يتم تخزين بيانات البلوكتشين في مشاركات مختلفة؟ أي: كيف يتم إجراء تقسيم الحالة )State Sharding(؛
تعني التعقيدات المخاطر، بناءً على كل ما سبق، كيف يمكن تجنب انقسام أمان النظام بأكمله؟
) 01 مشاركة الشبكة ### Network Sharding (
إذا فهمنا البلوكتشين ببساطة على أنها نوع من دفاتر الحسابات اللامركزية، فإن آلية التوافق سواء كانت PoS أو PoW، تهدف إلى السماح لكل عقدة بالتنافس على حق التسجيل وفقًا لقواعد محددة، مع ضمان صحة الدفتر في هذه العملية. بينما تشير مشاركة الشبكة إلى الحاجة إلى قواعد محددة أخرى، لتقسيم شبكة البلوكتشين إلى شرائح، بحيث تتعامل كل شريحة مع المعاملات على السلسلة، وتتنافس على حق التسجيل - أي، قواعد تجميع العقد.
ولكن في هذه العملية، المشكلة التي تواجهنا هي أنه مع تقسيم العقد الداخلية في البلوكتشين إلى مشاركات مختلفة، ستنخفض صعوبة وكلفة المهاجمين بشكل خطي. يمكننا استنتاج أنه إذا كانت قواعد ونتائج عملية التجميع هذه ثابتة وقابلة للتنبؤ، فإن المهاجم يحتاج فقط إلى السيطرة على مشاركة واحدة من أجل السيطرة على الشبكة بأكملها، وكان بإمكانه شراء بعض العقد داخل تلك المشاركة.
وصف ألكسندر سكيدانوف، مؤسس Near، هذه المشكلة على النحو التالي: إذا قررت سلسلة واحدة بها 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.
![شرح تفصيلي جديد لسلسلة الكتل Shardeum: احتمال آخر للمشاركة])https://img-cdn.gateio.im/webp-social/moments-6e8d3331d7d68cb512eb2eb47bd9064d.webp(
) 02 ###Transaction Sharding( تجزئة المعاملات
تشير مشاركة المعاملات إلى وضع قواعد حول "أي المعاملات يجب تخصيصها إلى أي مشاركات"، مما يمكن أن يحقق هدف المعالجة المتوازية ويتجنب مشكلة الإنفاق المزدوج. سيؤثر اختلاف نموذج دفتر أستاذ البلوكتشين على تطوير مشاركة المعاملات.
يوجد حاليًا نوعان من طرق المحاسبة في شبكة البلوكتشين، وهما نموذج مخرجات المعاملات غير المنفقة UTXO) والموديل الحسابي/الرصيد، ويمثل الأول BTC، بينما الثاني مثل ETH.
نموذج UTXO: في معاملات BTC، كل معاملة تحتوي على مخرجات واحدة أو أكثر، UTXO تشير إلى مخرجات معاملات البلوكتشين التي لم تُستخدم بعد، ويمكن استخدامها كمدخلات لمعاملة جديدة، بينما مخرجات المعاملات التي تم استخدامها لا يمكن استخدامها مرة أخرى، مشابهة لحالة الدفع و الباقي في معاملات الأوراق النقدية، حيث يقوم العميل بدفع ورقة نقدية واحدة أو أكثر للتاجر، ثم يقوم التاجر بإعادة الباقي من الأوراق النقدية للعميل. في نموذج UTXO، تحتاج معاملات المشاركة إلى اتصالات عبر المشاركات. قد تتضمن المعاملة الواحدة مدخلات متعددة ومخرجات متعددة، ولا يوجد مفهوم الحسابات، كما لا يوجد سجل للأرصدة، إحدى الطرق الممكنة هي: وضعها في دالة هاش بناءً على قيمة مدخلاتها لتحويلها إلى قيمة هاش متقطعة لتحديد البيانات التي يجب أن تذهب إلى أي مشاركة. كما يلي:
لضمان وضع الإدخالات بطريقة متسقة في القطع الصحيحة، يجب أن تأتي القيم المدخلة في دالة الهاش من نفس العمود. يُسمى هذا العمود مفتاح الشظية. بعد ذلك، يتم توزيع المعاملات التي تنتج قيمة 1 في الشظية 1، والمعاملات التي تنتج قيمة 2 في الشظية 2. ومع ذلك، تكمن عيوب هذه الطريقة في أنه يجب على الشظايا التواصل لتجنب هجمات الإنفاق المزدوج. إذا تم تقييد المعاملات عبر الشظايا، فسوف يحد ذلك من قابلية استخدام المنصة، بينما السماح بالمعاملات عبر الشظايا يتطلب موازنة تكاليف التواصل عبر الشظايا مع الفوائد الناتجة عن تحسين الأداء.
نموذج الحساب / الرصيد: يسجل النظام رصيد كل حساب، وعند إجراء المعاملة، يتحقق النظام مما إذا كان لدى الحساب رصيد كافٍ للدفع، مشابهًا لما يحدث عند التحويل المصرفي حيث تسجل البنوك رصيد كل حساب، ولا يمكن إجراء المعاملة إلا إذا كان رصيد الحساب أكبر من مبلغ التحويل المطلوب. في نموذج الحساب / الرصيد، نظرًا لأن المعاملة تحتوي على إدخال واحد فقط، فإنه يمكن ضمان معالجة عدة معاملات لنفس الحساب في نفس المشاركة من خلال تقسيم المعاملة وفقًا لعنوان المرسل، مما يمنع فعليًا حدوث الإنفاق المزدوج. لذلك، فإن معظم شبكات البلوكتشين التي تعتمد تقنية المشاركة هي أنظمة دفاتر حسابات مثل إيثيريوم.
( 03 حالة مشاركة ) حالة مشاركة ###
تشير مشاركة الحالة إلى كيفية توزيع بيانات البلوكتشين وتخزينها في مشاركات مختلفة.
لا يزال نستخدم مثال صف وول مارت لدينا، كل نافذة لديها حساب، كيف تُسجل دفاترهم؟ إذا: جاء العميل إلى صف معين، يتم تسجيل الحساب المناسب، على سبيل المثال، إذا ذهب العميل 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، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 12
أعجبني
12
6
إعادة النشر
مشاركة
تعليق
0/400
CodeZeroBasis
· منذ 7 س
ماذا حدث مرة أخرى؟ يبدو أنني تعبت من المشاهدة.
شاهد النسخة الأصليةرد0
GasFeeBeggar
· منذ 7 س
خمس سنوات تنتظر حدثًا فارغًا
شاهد النسخة الأصليةرد0
rugpull_survivor
· منذ 7 س
مرة أخرى POS ومشاركة لماذا غازنا لا يزال باهظ الثمن
شاهد النسخة الأصليةرد0
RugPullSurvivor
· منذ 7 س
فقط هذا قبل 5 سنوات كان الحديث عن خداع الناس لتحقيق الربح جيدًا.
شاهد النسخة الأصليةرد0
TopEscapeArtist
· منذ 7 س
مرة أخرى نتحدث عن المشاركة، بدلاً من ذلك لننظر إلى مؤشر MACD.
شاهد النسخة الأصليةرد0
LiquidationWatcher
· منذ 7 س
L2 هو الطريق الصحيح، يجب توسيع النطاق فقط من خلال الخيارات الموثوقة.
استكشاف تقنية مشاركة: التحديات وحلول توسيع إثيريوم
مشاركة التقنية: الاحتمال الآخر لزيادة حجم البلوكتشين
في 15 سبتمبر 2022، أكملت الإيثريوم الدمج (Merge). كانت هذه لحظة تاريخية، حيث استعدت الإيثريوم لذلك لمدة 5 سنوات، وتأجلت 6 مرات. بسبب التطوير الطويل والاهتمام الواسع، اعتقد الكثيرون أن الدمج سيجلب ببساطة قابلية توسيع وأمان واستدامة أعلى، لكن هذا ليس صحيحاً. الانتقال من إثبات العمل (PoW) إلى إثبات الحصة (PoS) هو مجرد تغيير في "المسار والعجلات"، ولن يؤدي مباشرة إلى سرعة أكبر أو سعة أكبر أو رسوم أقل. ما يمكن أن يحقق هذه الأهداف حقًا هو مجموعة كاملة من الحلول: شبكة رئيسية ذات قدرة على المشاركة مصحوبة بحلول Layer2 المعززة للقابلية للتوسع.
كما أشار مؤسس الإيثريوم فيتاليك بوتيرين، فإن المشاركة هي حل للتوسع ضمن معضلة الثلاثة صعوبات المتعلقة بالقدرة. من خلال تقسيم العقد في الشبكة إلى مجموعات أصغر، يتم معالجة مجموعات مختلفة من المعاملات وتحقيق المعالجة المتوازية. يشبه ذلك عند التسوق في وول مارت، من خلال فتح المزيد من ممرات الدفع، يمكن تقليل وقت الانتظار وزيادة كفاءة الدفع.
هذه هي منطق المشاركة، مباشر وبسيط، لكن الشيطان يكمن في التفاصيل. المبدأ والاتجاه صحيحان، لكن في التنفيذ ستواجه دائمًا الكثير من المشكلات. تهدف هذه المقالة إلى توضيح الاتجاهات والمشكلات على طريق "المشاركة"، ورسم خريطة لمستكشفي المشاركة الذين ينظرون إلى السماء بينما يقفون على الأرض. في الوقت نفسه، من خلال مقارنة الحلول الحالية للمشاركة، سيتم العثور على بعض المشكلات المشتركة، وتقديم اتجاه استكشاف قابل للتطبيق: Shardeum والمشاركة الديناميكية.
أ. حول "مشاركة"
ببساطة، بالنظر إلى قيود مثلث الاستحالة، بدءًا من الإيثيريوم كنقطة الأصل (، 0)، وفقًا لفكرتين "طولية" و"عرضية"، نقسم طرق توسيع البلوكتشين الحالية إلى فئتين رئيسيتين:
التوسع العمودي (: يتم تحقيقه من خلال تحسين أداء الأجهزة الحالية في النظام. إنشاء شبكة لامركزية، حيث يتمتع كل عقدة في الشبكة بقدرات حسابية فائقة، مما يعني أن كل عقدة تحتاج إلى "أجهزة أفضل". هذه الطريقة بسيطة وفعالة، ويمكن أن تحقق تحسينًا أوليًا في معدل نقل البيانات، خاصةً في حالات التداول عالي التردد، والألعاب، وغيرها من التطبيقات الحساسة للتأخير. ومع ذلك، فإن هذه الطريقة في التوسع ستقيد مستوى اللامركزية في الشبكة، لأن تكلفة تشغيل عقد التحقق أو العقد الكاملة قد زادت. الحفاظ على مستوى اللامركزية مقيد بمعدل النمو التقريبي في أداء الأجهزة الحاسوبية ) وهذا ما يُعرف باسم "قانون مور": عدد الترانزستورات على الشريحة يتضاعف كل عامين، وتكلفة الحوسبة تنخفض إلى النصف (.
التوسع الأفقي ) التوسع الأفقي (: يوجد عادةً عدة أفكار للتوسع الأفقي. واحدة منها هي في سياق البلوكتشين، حيث يتم توزيع كمية حسابات المعاملات في نظام بيئي معين على عدة بلوكتشينات مستقلة، حيث تمتلك كل سلسلة منتجي كتل وقدرات تنفيذ خاصة بها، ويمكن تخصيص طبقة التنفيذ لكل سلسلة بشكل كامل، مثل متطلبات أجهزة العقد، وظائف الخصوصية، رسوم الغاز، الآلات الافتراضية وإعدادات الأذونات، وغيرها. خطة التوسع الأفقي الأخرى هي البلوكتشين المعيارية، حيث يتم تقسيم بنية البلوكتشين إلى طبقة تنفيذ، طبقة توفر البيانات ) DA ( وطبقة توافق. الآلية المعيارية الأكثر شيوعاً في البلوكتشين هي الـ rollup. وهناك نوع آخر هو تقسيم بلوكتشين واحد إلى عدة أجزاء، وتنفيذها بشكل متوازي. يمكن اعتبار كل جزء بمثابة بلوكتشين، مما يعني أن العديد من البلوكتشينات يمكن أن تعمل بالتوازي. بالإضافة إلى ذلك، عادةً ما يكون هناك سلسلة رئيسية واحدة، تكون مهمتها الوحيدة هي الحفاظ على تزامن جميع الأجزاء.
![شرح مفصل عن البلوكتشين الجديد Shardeum: احتمال آخر للمشاركة])https://img-cdn.gateio.im/webp-social/moments-7aa1677db6b8128b68accfe04fcda738.webp(
من المهم الإشارة إلى أن الأفكار المذكورة أعلاه لتوسيع القدرة ليست موجودة بشكل منفصل، فكل حل من الحلول هو نقطة توازن تم العثور عليها في مثلث الاستحالة، بالتعاون مع تصميم آلية الحوافز التي تخلقها القوى الاقتصادية في النظام، لتحقيق توازن فعال على المستويين الكلي والجزئي.
للنقاش حول "مشاركة"، نحتاج إلى إعادة تنظيم الأمور من البداية.
لا يزال نفترض هذا السيناريو، عند الدفع في وول مارت، من أجل تحسين كفاءة الدفع وتقليل وقت انتظار العملاء، نحن ممتدون من قناة دفع واحدة إلى 10 نوافذ دفع، لتجنب أخطاء السجل، في هذه الحالة نحتاج إلى وضع قواعد موحدة:
أولاً، إذا كان لدينا 10 أمين صندوق، كيف نوزعهم على أي نافذة للعمل؟
ثانياً، إذا كان لدينا 1000 عميل في طابور الانتظار، كيف نقرر أي عميل يذهب إلى أي نافذة للدفع؟
ثالثاً، كيف يمكن تلخيص دفاتر الحسابات العشرة المنفصلة المرتبطة بالعشرة نوافذ هذه؟
رابعًا، كيف يمكن تجنب وقوع أخطاء من قبل أمين الصندوق لتفادي حدوث عدم تطابق في الحسابات؟
هذه الأسئلة تتعلق في الواقع بعدة مسائل رئيسية في المشاركة، وهي على التوالي:
كيف يمكن تحديد أي جزء من الشبكة ينتمي إليه العقد/المتحققون في الشبكة؟ أي: كيف يتم إجراء مشاركة الشبكة )Network Sharding(;
كيف يمكن تحديد أي شريحة تم تخصيصها لكل معاملة؟ أي: كيفية إجراء تقسيم معاملات )Transaction Sharding(؛
كيف يتم تخزين بيانات البلوكتشين في مشاركات مختلفة؟ أي: كيف يتم إجراء تقسيم الحالة )State Sharding(؛
تعني التعقيدات المخاطر، بناءً على كل ما سبق، كيف يمكن تجنب انقسام أمان النظام بأكمله؟
) 01 مشاركة الشبكة ### Network Sharding (
إذا فهمنا البلوكتشين ببساطة على أنها نوع من دفاتر الحسابات اللامركزية، فإن آلية التوافق سواء كانت PoS أو PoW، تهدف إلى السماح لكل عقدة بالتنافس على حق التسجيل وفقًا لقواعد محددة، مع ضمان صحة الدفتر في هذه العملية. بينما تشير مشاركة الشبكة إلى الحاجة إلى قواعد محددة أخرى، لتقسيم شبكة البلوكتشين إلى شرائح، بحيث تتعامل كل شريحة مع المعاملات على السلسلة، وتتنافس على حق التسجيل - أي، قواعد تجميع العقد.
ولكن في هذه العملية، المشكلة التي تواجهنا هي أنه مع تقسيم العقد الداخلية في البلوكتشين إلى مشاركات مختلفة، ستنخفض صعوبة وكلفة المهاجمين بشكل خطي. يمكننا استنتاج أنه إذا كانت قواعد ونتائج عملية التجميع هذه ثابتة وقابلة للتنبؤ، فإن المهاجم يحتاج فقط إلى السيطرة على مشاركة واحدة من أجل السيطرة على الشبكة بأكملها، وكان بإمكانه شراء بعض العقد داخل تلك المشاركة.
وصف ألكسندر سكيدانوف، مؤسس Near، هذه المشكلة على النحو التالي: إذا قررت سلسلة واحدة بها 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.
![شرح تفصيلي جديد لسلسلة الكتل Shardeum: احتمال آخر للمشاركة])https://img-cdn.gateio.im/webp-social/moments-6e8d3331d7d68cb512eb2eb47bd9064d.webp(
) 02 ###Transaction Sharding( تجزئة المعاملات
تشير مشاركة المعاملات إلى وضع قواعد حول "أي المعاملات يجب تخصيصها إلى أي مشاركات"، مما يمكن أن يحقق هدف المعالجة المتوازية ويتجنب مشكلة الإنفاق المزدوج. سيؤثر اختلاف نموذج دفتر أستاذ البلوكتشين على تطوير مشاركة المعاملات.
يوجد حاليًا نوعان من طرق المحاسبة في شبكة البلوكتشين، وهما نموذج مخرجات المعاملات غير المنفقة UTXO) والموديل الحسابي/الرصيد، ويمثل الأول BTC، بينما الثاني مثل ETH.
نموذج UTXO: في معاملات BTC، كل معاملة تحتوي على مخرجات واحدة أو أكثر، UTXO تشير إلى مخرجات معاملات البلوكتشين التي لم تُستخدم بعد، ويمكن استخدامها كمدخلات لمعاملة جديدة، بينما مخرجات المعاملات التي تم استخدامها لا يمكن استخدامها مرة أخرى، مشابهة لحالة الدفع و الباقي في معاملات الأوراق النقدية، حيث يقوم العميل بدفع ورقة نقدية واحدة أو أكثر للتاجر، ثم يقوم التاجر بإعادة الباقي من الأوراق النقدية للعميل. في نموذج UTXO، تحتاج معاملات المشاركة إلى اتصالات عبر المشاركات. قد تتضمن المعاملة الواحدة مدخلات متعددة ومخرجات متعددة، ولا يوجد مفهوم الحسابات، كما لا يوجد سجل للأرصدة، إحدى الطرق الممكنة هي: وضعها في دالة هاش بناءً على قيمة مدخلاتها لتحويلها إلى قيمة هاش متقطعة لتحديد البيانات التي يجب أن تذهب إلى أي مشاركة. كما يلي:
لضمان وضع الإدخالات بطريقة متسقة في القطع الصحيحة، يجب أن تأتي القيم المدخلة في دالة الهاش من نفس العمود. يُسمى هذا العمود مفتاح الشظية. بعد ذلك، يتم توزيع المعاملات التي تنتج قيمة 1 في الشظية 1، والمعاملات التي تنتج قيمة 2 في الشظية 2. ومع ذلك، تكمن عيوب هذه الطريقة في أنه يجب على الشظايا التواصل لتجنب هجمات الإنفاق المزدوج. إذا تم تقييد المعاملات عبر الشظايا، فسوف يحد ذلك من قابلية استخدام المنصة، بينما السماح بالمعاملات عبر الشظايا يتطلب موازنة تكاليف التواصل عبر الشظايا مع الفوائد الناتجة عن تحسين الأداء.
نموذج الحساب / الرصيد: يسجل النظام رصيد كل حساب، وعند إجراء المعاملة، يتحقق النظام مما إذا كان لدى الحساب رصيد كافٍ للدفع، مشابهًا لما يحدث عند التحويل المصرفي حيث تسجل البنوك رصيد كل حساب، ولا يمكن إجراء المعاملة إلا إذا كان رصيد الحساب أكبر من مبلغ التحويل المطلوب. في نموذج الحساب / الرصيد، نظرًا لأن المعاملة تحتوي على إدخال واحد فقط، فإنه يمكن ضمان معالجة عدة معاملات لنفس الحساب في نفس المشاركة من خلال تقسيم المعاملة وفقًا لعنوان المرسل، مما يمنع فعليًا حدوث الإنفاق المزدوج. لذلك، فإن معظم شبكات البلوكتشين التي تعتمد تقنية المشاركة هي أنظمة دفاتر حسابات مثل إيثيريوم.
( 03 حالة مشاركة ) حالة مشاركة ###
تشير مشاركة الحالة إلى كيفية توزيع بيانات البلوكتشين وتخزينها في مشاركات مختلفة.
لا يزال نستخدم مثال صف وول مارت لدينا، كل نافذة لديها حساب، كيف تُسجل دفاترهم؟ إذا: جاء العميل إلى صف معين، يتم تسجيل الحساب المناسب، على سبيل المثال، إذا ذهب العميل A إلى نافذة A، ثم في اليوم التالي ذهب العميل إلى نافذة تسجيل أخرى، مثل نافذة B، وليس لدى نافذة B معلومات حسابات العميل السابقة (، مثل الطرق المتعلقة ببطاقة القيمة المخزنة وما إلى ذلك )، ماذا يجب أن نفعل؟ هل ينبغي استدعاء معلومات حساب العميل من نافذة A؟
تعد حالة المشاركة أكبر تحدٍ في المشاركة، وهي أكثر تعقيدًا من مشاركة الشبكة ومشاركة المعاملات المذكورة أعلاه. لأنه بموجب آلية المشاركة، ستتم معالجة المعاملات وفقًا للعناوين في مشاركات مختلفة، مما يعني أن الحالة ستخزن فقط في المشاركة التي تنتمي إليها عنوانها، وفي هذه الحالة، يجب مواجهة مشكلة أن المعاملات لن تحدث فقط في مشاركة واحدة، وغالبًا ما ستتضمن (Cross-Sharding).
اعتبر حالة تحويل، حيث يقوم حساب A بتحويل 10U إلى حساب B، وعنوان A مخصص في مشاركة 1، وسجل المعاملة سيتم تخزينه أيضًا في مشاركة 1. عنوان B مخصص في مشاركة 2، وسجل المعاملة سيتم تخزينه في مشاركة 2.
عندما يريد A تحويل الأموال إلى B، ستتشكل عملية تداول عبر المشاركات، ستقوم المشاركة 2 بالاتصال بسجل المعاملات السابق للمشاركة 1 للتحقق من صحة المعاملة. إذا كان A يقوم بإرسال العملات بشكل متكرر إلى B، ستحتاج المشاركة 2 إلى التفاعل المستمر مع المشاركة 1، مما يؤدي إلى انخفاض كفاءة معالجة المعاملات. ومع ذلك، إذا لم يتم تحميل والتحقق من التاريخ الكامل لمشاركة معينة، فلن يكون المشاركون بالضرورة.