تقنية المشاركة: الاستكشاف الرائد لتوسيع البلوكتشين
في 15 سبتمبر 2022، أكملت الإيثيريوم الدمج (Merge). كانت هذه لحظة تاريخية، حيث استعدت الإيثيريوم لهذا لمدة 5 سنوات، وتأجلت 6 مرات. بسبب الضبط المتكرر والتطوير الطويل الأمد، بالإضافة إلى التأثير الذي جذب انتباه الجميع، اعتقد الكثيرون أن الدمج سيؤدي بشكل طبيعي إلى قابلية توسع أعلى، وأمان أكبر، واستدامة أكبر، ولكن الأمر ليس كذلك. الانتقال من PoW( إثبات العمل) إلى PoS( إثبات الحصة)، هو مجرد تغيير "المسار والعجلات"، ولن يؤدي مباشرة إلى سرعة أكبر، أو سعة أكبر، أو تكاليف أقل. ما يمكنه تحقيق هذه الأهداف هو مجموعة كاملة من الحلول: شبكة رئيسية تمتلك قدرة المشاركة مرفقة بحلول Layer2 المعززة للقابلية للتوسع.
كما أشار مؤسس الإيثيريوم فيتاليك بوتيرين، فإن المشاركة هي حل للتوسع في إطار معضلة قابلية التوسع الثلاثية. من خلال تقسيم العقد في الشبكة إلى مجموعات أصغر، يتم معالجة مجموعات مختلفة من المعاملات وتحقيق المعالجة المتوازية. يشبه ذلك عند الشراء في السوبرماركت، من خلال فتح عدة نقاط دفع، يمكن تقليل وقت الانتظار وزيادة كفاءة الدفع.
هذه هي منطق المشاركة، مباشرة وبسيطة. ومع ذلك، الشيطان في التفاصيل - المبدأ والاتجاه صحيحان، ولكن دائمًا ما تواجه الكثير من المشكلات أثناء التنفيذ. تهدف هذه المقالة إلى توضيح الاتجاهات والمآزق على طريق "المشاركة"، ورسم خريطة لمستكشفي المشاركة الذين ينظرون إلى السماء بينما يثبتون أقدامهم على الأرض. في الوقت نفسه، من خلال مقارنة الحلول الحالية للمشاركة، نجد بعض المشكلات المشتركة، ونقترح اتجاه استكشاف قابل للتطبيق: Shardeum والمشاركة الديناميكية.
أ. حول "مشاركة"
باختصار، بالنظر إلى قيود مثلث المستحيل، ومن نقطة انطلاق إيثريوم كنقطة الأصل (0،0)، وفقًا لفكرتين "عموديتين" و"أفقيتين"، نقسم طرق قابلية توسيع البلوكتشين الحالية إلى فئتين رئيسيتين:
التوسع الرأسي (Vertical Scaling): يتم تحقيقه من خلال تحسين أداء الأجهزة الحالية للنظام. إنشاء شبكة لامركزية، حيث يتمتع كل عقدة في الشبكة بقوة حوسبة فائقة، أي أن كل عقدة تحتاج إلى أجهزة "أفضل". هذه الطريقة بسيطة وفعالة، ويمكن أن تحقق تحسينًا أوليًا في القدرة على معالجة البيانات، خاصة في تداولات عالية التردد، والألعاب، وغيرها من السيناريوهات التي تكون حساسة للتأخير. ومع ذلك، ستحد هذه الطريقة من مستوى اللامركزية في الشبكة، لأن تكلفة تشغيل عقد التحقق أو العقد الكاملة قد ارتفعت. الحفاظ على مستوى اللامركزية مقيد بمعدل النمو التقريبي لأداء الأجهزة الحاسوبية ( وهذا هو ما يسمى "قانون مور": عدد الترانزستورات على الشريحة يتضاعف كل عامين، وتكلفة الحوسبة تنخفض إلى النصف ).
التوسع الأفقي(Horizontal Scaling): يوجد عادةً عدة أفكار حول التوسع الأفقي. أحدها هو في سياق البلوكتشين، توزيع كمية معالجة المعاملات في نظام بيئي معين على عدة بلوكتشينات مستقلة، حيث تمتلك كل سلسلة منتجي كتل وقدرات تنفيذ خاصة بها، مما يسمح بتخصيص طبقة التنفيذ لكل سلسلة، مثل متطلبات الأجهزة العقدية، ميزات الخصوصية، رسوم الغاز، الآلات الافتراضية، وإعدادات الأذونات وغيرها. فكرة أخرى للتوسع الأفقي هي البلوكتشين المودولاري، حيث يتم تقسيم بنية البلوكتشين إلى طبقة التنفيذ، طبقة توفر البيانات(DA) وطبقة الإجماع. آلية المودولار الأكثر شيوعًا في البلوكتشين هي rollup. وهناك فكرة أخرى هي تقسيم بلوكتشين واحدة إلى عدة شظايا، وتنفيذها بشكل متوازي. يمكن اعتبار كل شظية كبلوكتشين، مما يعني أن العديد من البلوكتشينات يمكن أن تعمل بشكل متوازي. بالإضافة إلى ذلك، عادةً ما يكون هناك سلسلة رئيسية واحدة، تكون مهمتها الوحيدة هي الحفاظ على تزامن جميع الشظايا.
يجدر بالذكر أن جميع أفكار التوسع المذكورة أعلاه ليست موجودة بشكل منعزل، حيث أن كل حل من الحلول هو نقطة توازن يتم العثور عليها ضمن مثلث الاستحالة، بالتعاون مع تصميم آليات الحوافز التي تخلقها القوى الاقتصادية في النظام، لتحقيق توازن فعال على المستويين الكلي والجزئي.
للنقاش حول "مشاركة"، نحتاج إلى إعادة تنظيم الأمور من البداية.
لا يزال نفترض وجود مثل هذا السيناريو، حيث يتسوق الناس في السوبر ماركت، ولتحسين كفاءة الدفع وتقليل وقت انتظار العملاء، قمنا بتوسيع من قناة دفع واحدة إلى 10 نوافذ دفع، ولتجنب الأخطاء في الحساب، نحتاج في هذه اللحظة لوضع قواعد موحدة:
أولاً، إذا كان لدينا 10 صرافين، كيف نقوم بتوزيعهم على أي نافذة للعمل؟
ثانياً، إذا كان لدينا 1000 عميل في طابور ينتظرون، كيف نقرر أي عميل يذهب إلى أي نافذة للدفع؟
ثالثاً، كيف يمكن تلخيص دفاتر الحسابات العشرة المنفصلة التي تتوافق مع هذه النوافذ العشرة؟
رابعًا، لتجنب حدوث حالة عدم تطابق في الحسابات، كيف يمكن منع حدوث أخطاء من قبل أمين الصندوق؟
هذه الأسئلة تتعلق في الواقع ببعض القضايا الرئيسية في المشاركة، وهي كما يلي:
كيف يمكن تحديد أي كتلة من الشبكة تنتمي إليها العقد/المتحققون؟ أي: كيف يتم إجراء مشاركة الشبكة (Network Sharding)؛
كيف يمكن تحديد أي مشاركة يتم تخصيص كل معاملة لها؟ أي: كيف يتم إجراء مشاركة المعاملات (Transaction Sharding)؛
كيف يتم تخزين بيانات البلوكتشين في مشاركات مختلفة؟ أي: كيف يتم إجراء مشاركة الحالة (State Sharding)؛
تعني التعقيد المخاطر، بناءً على كل ما سبق، كيف يمكن تجنب تقسيم أمان النظام بأكمله؟
01 تجزئة الشبكة (Network Sharding)
إذا فهمنا البلوكتشين ببساطة على أنه نوع من دفتر الأستاذ الموزع، سواء كان آلية توافق بروتوكول إثبات الحصة (PoS) أو إثبات العمل (PoW)، فإن الهدف هو أن تتنافس العقد المختلفة على حق التسجيل وفقًا لقواعد معينة محددة مسبقًا، مع ضمان صحة السجل خلال هذه العملية. أما مشاركة الشبكة، فهي تشير إلى الحاجة إلى قواعد محددة أخرى، لتقسيم شبكة البلوكتشين إلى أجزاء، بحيث يتم معالجة المعاملات على السلسلة من قبل كل جزء مع تقليل التواصل فيما بينها قدر الإمكان، وتتنافس على حق التسجيل - أي، قواعد تجميع العقد.
وأثناء هذه العملية، تكمن المشكلة في أنه مع تقسيم العقد الداخلية في البلوكتشين إلى مشاركات مختلفة، ستنخفض صعوبة وتكلفة المهاجمين بشكل خطي. يمكننا أن نستنتج أنه إذا كانت قواعد هذه العملية ونتائجها ثابتة وقابلة للتنبؤ، فإن المهاجمين يحتاجون فقط إلى السيطرة على مشاركة واحدة من الشبكة الكاملة للبلوكتشين، من خلال السيطرة بشكل موجه على بعض العقد داخل تلك المشاركة.
يجب على نظام المشاركة تطوير آلية لإثبات أن الشبكة لن تعكس هذه المعاملات من أجزاء خارجية. حتى الآن، قد تكون أفضل إجابة هي ضمان أن عدد المدققين داخل الشريحة أعلى من حد أدنى معين، بحيث تقل احتمالية تمكن المدققين غير الأمان من السيطرة على شريحة واحدة. الطريقة الأكثر شيوعًا هي بناء مستوى معين من العشوائية غير المتحيزة، بالاعتماد على الرياضيات، لتقليل احتمال نجاح المهاجمين إلى الحد الأدنى. على سبيل المثال، إيثريوم، حيث تتمثل الحلول في اختيار مدقق لشريحة معينة بشكل عشوائي من جميع المدققين، ويتم تغيير المدققين كل 6.4 دقائق ( طول حقبة ).
ببساطة، يعني ذلك تقسيم العقد إلى مجموعات عشوائية، ثم توزيع العمل على عقد كل مجموعة للتحقق بشكل مستقل.
ومع ذلك، يجب الإشارة إلى أن العشوائية في البلوكتشين هي موضوع مليء بالتحديات، من المنطقي أن عملية إنشاء هذا الرقم العشوائي لا ينبغي أن تعتمد على حساب أي مشاركة معينة. بالنسبة لهذا الحساب، هناك الكثير من الأفكار التصميمية الحالية التي تتضمن تطوير بلوكتشين منفصل، للحفاظ على الشبكة بأكملها. تُعرف هذه السلسلة في Ethereum و Near بسلسلة Beacon، وفي PolkaDot تُعرف بسلسلة Relay، وفي Cosmos تُعرف بـ Cosmos Hub.
02 (Transaction Sharding) تجزئة المعاملات
تعيين المشاركة للمعاملات هو عبارة عن وضع قواعد حول "أي المعاملات يجب أن تُوزع على أي مشاركة"، مما يتيح تحقيق هدف المعالجة المتوازية وتجنب ظهور مشكلة الإنفاق المزدوج. سيؤثر اختلاف نموذج دفتر حسابات البلوكتشين على تطوير مشاركة المعاملات.
يوجد حاليًا نوعان من طرق المحاسبة في شبكة البلوكتشين، وهما نموذج مخرجات المعاملات غير المنفقة UTXO(، ونموذج الحساب/الرصيد، حيث يمثل الأول BTC، في حين أن الثاني مثل ETH.
نموذج UTXO: في معاملات BTC، سيكون لكل معاملة مخرجات واحدة أو أكثر، تشير UTXO إلى مخرجات معاملات البلوكتشين التي لم تُستخدم بعد، ويمكن استخدامها كمدخلات لمعاملات جديدة، بينما لا يمكن استخدام مخرجات المعاملات التي تم إنفاقها مرة أخرى، مشابهة لحالة الدفع والفكة في معاملات الأوراق النقدية، حيث يدفع العميل ورقة نقدية واحدة أو أكثر للتاجر، ثم يقوم التاجر بإعطاء العميل ورقة نقدية واحدة أو أكثر كفكة. تحت نموذج UTXO، تحتاج معاملات المشاركة إلى الاتصال عبر المشاركات. قد تشمل المعاملة الواحدة عدة مدخلات ومخرجات، ولا يوجد مفهوم الحسابات، ولا يوجد سجل للرصيد، إحدى الطرق الممكنة هي: وضعها في دالة هاش بناءً على قيمة مدخلات معاملتها لتحويلها إلى قيمة هاش منفصلة لتحديد البيانات التي يجب أن تذهب إلى أي مشاركة.
لضمان وضع الإدخالات بطريقة متسقة في الكتل الصحيحة، يجب أن تأتي القيم المدخلة في دالة التجزئة من نفس العمود. يُطلق على هذا العمود اسم مفتاح المشاركة. بعد ذلك، سيتم تخصيص المعاملات التي تنتج القيمة 1 إلى المشاركة 1، والمعاملات التي تنتج القيمة 2 إلى المشاركة 2. ومع ذلك، فإن عيب هذه الطريقة هو أنه يجب على المشاركات التواصل لتجنب هجمات الإنفاق المزدوج. إذا تم تقييد المعاملات عبر المشاركات، فسيؤدي ذلك إلى تقييد قابلية استخدام المنصة، بينما السماح بالمعاملات عبر المشاركات يتطلب موازنة بين تكلفة التواصل عبر المشاركات والفوائد الناتجة عن تحسين الأداء.
نموذج الحساب/الرصيد: يسجل النظام رصيد كل حساب، وعند إجراء المعاملات، يتحقق النظام مما إذا كان لدى الحساب رصيد كافٍ للدفع، مماثلًًا لعمليات التحويل البنكي حيث تسجل البنوك رصيد كل حساب، ولا يمكن تنفيذ المعاملة إلا إذا كان رصيد الحساب أكبر من مبلغ التحويل المطلوب. تحت نموذج الحساب/الرصيد، نظرًا لأن المعاملة تحتوي على إدخال واحد فقط، فإنه يكفي تقسيم المعاملة حسب عنوان المرسل، لضمان معالجة عدة معاملات لنفس الحساب في نفس المشاركة، مما يمنع بشكل فعال ظاهرة الإنفاق المزدوج. لذلك، فإن معظم سلاسل الكتل التي تستخدم تقنية المشاركة هي أنظمة دفاتر حسابات مثل الإيثيريوم.
![شرح مفصل عن البلوكتشين الجديد Shardeum: إمكانية جديدة للمشاركة])https://img-cdn.gateio.im/webp-social/moments-4227a2e49f76cd01b23d7b5398e51a3c.webp(
) 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، مما سيؤدي إلى تقليل كفاءة معالجة المعاملات. ومع ذلك، إذا لم يتم تنزيل والتحقق من التاريخ الكامل لمشاركة معينة، فلن يتمكن المشاركون بالضرورة من التأكد من أن حالة التفاعل بينهم هي نتيجة لتسلسل كتل صالحة معينة، وأن هذا التسلسل من الكتل هو بالفعل السلسلة القياسية داخل المشاركة.
لذلك، بالمقارنة مع سلسلة واحدة بدون مشاركة، فإن النظام القائم على المشاركة يواجه تحديًا جديدًا وهو أن المستخدمين لا يمكنهم التحقق بالكامل من صحة وموثوقية أي سلسلة معينة، لأن البيانات كثيرة جدًا. يجب توفير طرق غير موثوقة وعملية إلى أقصى حد للمستخدمين للتحقق من أي سلسلة متاحة تمامًا وصالحة، وذلك لتمكينهم من تحديد أي سلسلة هي السلسلة القياسية. في الممارسة العملية، يمكن لمطوري البلوكتشين استخدام التقنيات التالية لحل بعض مشكلات التحقق: مثل اللجان، وSNARKs/STARKs، وآلية الصياد، بالإضافة إلى إثبات الاحتيال وموثوقية البيانات.
هناك فكرتان لحل هذه المشكلة، واحدة هي التزامن عبر المشاركة
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 12
أعجبني
12
7
مشاركة
تعليق
0/400
ExpectationFarmer
· منذ 13 س
مشاركة?又不能当饭吃
شاهد النسخة الأصليةرد0
BuyHighSellLow
· منذ 20 س
Rug Pull 5 سنوات أخيرًا تم حلها
شاهد النسخة الأصليةرد0
ShitcoinConnoisseur
· منذ 20 س
فيتاليك بوتيرين يقول أي شيء صحيح~
شاهد النسخة الأصليةرد0
SellTheBounce
· منذ 20 س
مرة أخرى، تم خداع الحمقى واستخدام أداة جديدة للخداع.
شاهد النسخة الأصليةرد0
BrokenYield
· منذ 20 س
آه... مرة أخرى دمج مبالغ فيه لم يحل شيئًا. إنها عملة مشفرة كلاسيكية بصراحة.
استكشاف تقنية المشاركة: تحليل مبادئ وتحديات توسيع البلوكتشين
تقنية المشاركة: الاستكشاف الرائد لتوسيع البلوكتشين
في 15 سبتمبر 2022، أكملت الإيثيريوم الدمج (Merge). كانت هذه لحظة تاريخية، حيث استعدت الإيثيريوم لهذا لمدة 5 سنوات، وتأجلت 6 مرات. بسبب الضبط المتكرر والتطوير الطويل الأمد، بالإضافة إلى التأثير الذي جذب انتباه الجميع، اعتقد الكثيرون أن الدمج سيؤدي بشكل طبيعي إلى قابلية توسع أعلى، وأمان أكبر، واستدامة أكبر، ولكن الأمر ليس كذلك. الانتقال من PoW( إثبات العمل) إلى PoS( إثبات الحصة)، هو مجرد تغيير "المسار والعجلات"، ولن يؤدي مباشرة إلى سرعة أكبر، أو سعة أكبر، أو تكاليف أقل. ما يمكنه تحقيق هذه الأهداف هو مجموعة كاملة من الحلول: شبكة رئيسية تمتلك قدرة المشاركة مرفقة بحلول Layer2 المعززة للقابلية للتوسع.
كما أشار مؤسس الإيثيريوم فيتاليك بوتيرين، فإن المشاركة هي حل للتوسع في إطار معضلة قابلية التوسع الثلاثية. من خلال تقسيم العقد في الشبكة إلى مجموعات أصغر، يتم معالجة مجموعات مختلفة من المعاملات وتحقيق المعالجة المتوازية. يشبه ذلك عند الشراء في السوبرماركت، من خلال فتح عدة نقاط دفع، يمكن تقليل وقت الانتظار وزيادة كفاءة الدفع.
هذه هي منطق المشاركة، مباشرة وبسيطة. ومع ذلك، الشيطان في التفاصيل - المبدأ والاتجاه صحيحان، ولكن دائمًا ما تواجه الكثير من المشكلات أثناء التنفيذ. تهدف هذه المقالة إلى توضيح الاتجاهات والمآزق على طريق "المشاركة"، ورسم خريطة لمستكشفي المشاركة الذين ينظرون إلى السماء بينما يثبتون أقدامهم على الأرض. في الوقت نفسه، من خلال مقارنة الحلول الحالية للمشاركة، نجد بعض المشكلات المشتركة، ونقترح اتجاه استكشاف قابل للتطبيق: Shardeum والمشاركة الديناميكية.
أ. حول "مشاركة"
باختصار، بالنظر إلى قيود مثلث المستحيل، ومن نقطة انطلاق إيثريوم كنقطة الأصل (0،0)، وفقًا لفكرتين "عموديتين" و"أفقيتين"، نقسم طرق قابلية توسيع البلوكتشين الحالية إلى فئتين رئيسيتين:
التوسع الرأسي (Vertical Scaling): يتم تحقيقه من خلال تحسين أداء الأجهزة الحالية للنظام. إنشاء شبكة لامركزية، حيث يتمتع كل عقدة في الشبكة بقوة حوسبة فائقة، أي أن كل عقدة تحتاج إلى أجهزة "أفضل". هذه الطريقة بسيطة وفعالة، ويمكن أن تحقق تحسينًا أوليًا في القدرة على معالجة البيانات، خاصة في تداولات عالية التردد، والألعاب، وغيرها من السيناريوهات التي تكون حساسة للتأخير. ومع ذلك، ستحد هذه الطريقة من مستوى اللامركزية في الشبكة، لأن تكلفة تشغيل عقد التحقق أو العقد الكاملة قد ارتفعت. الحفاظ على مستوى اللامركزية مقيد بمعدل النمو التقريبي لأداء الأجهزة الحاسوبية ( وهذا هو ما يسمى "قانون مور": عدد الترانزستورات على الشريحة يتضاعف كل عامين، وتكلفة الحوسبة تنخفض إلى النصف ).
التوسع الأفقي(Horizontal Scaling): يوجد عادةً عدة أفكار حول التوسع الأفقي. أحدها هو في سياق البلوكتشين، توزيع كمية معالجة المعاملات في نظام بيئي معين على عدة بلوكتشينات مستقلة، حيث تمتلك كل سلسلة منتجي كتل وقدرات تنفيذ خاصة بها، مما يسمح بتخصيص طبقة التنفيذ لكل سلسلة، مثل متطلبات الأجهزة العقدية، ميزات الخصوصية، رسوم الغاز، الآلات الافتراضية، وإعدادات الأذونات وغيرها. فكرة أخرى للتوسع الأفقي هي البلوكتشين المودولاري، حيث يتم تقسيم بنية البلوكتشين إلى طبقة التنفيذ، طبقة توفر البيانات(DA) وطبقة الإجماع. آلية المودولار الأكثر شيوعًا في البلوكتشين هي rollup. وهناك فكرة أخرى هي تقسيم بلوكتشين واحدة إلى عدة شظايا، وتنفيذها بشكل متوازي. يمكن اعتبار كل شظية كبلوكتشين، مما يعني أن العديد من البلوكتشينات يمكن أن تعمل بشكل متوازي. بالإضافة إلى ذلك، عادةً ما يكون هناك سلسلة رئيسية واحدة، تكون مهمتها الوحيدة هي الحفاظ على تزامن جميع الشظايا.
يجدر بالذكر أن جميع أفكار التوسع المذكورة أعلاه ليست موجودة بشكل منعزل، حيث أن كل حل من الحلول هو نقطة توازن يتم العثور عليها ضمن مثلث الاستحالة، بالتعاون مع تصميم آليات الحوافز التي تخلقها القوى الاقتصادية في النظام، لتحقيق توازن فعال على المستويين الكلي والجزئي.
للنقاش حول "مشاركة"، نحتاج إلى إعادة تنظيم الأمور من البداية.
لا يزال نفترض وجود مثل هذا السيناريو، حيث يتسوق الناس في السوبر ماركت، ولتحسين كفاءة الدفع وتقليل وقت انتظار العملاء، قمنا بتوسيع من قناة دفع واحدة إلى 10 نوافذ دفع، ولتجنب الأخطاء في الحساب، نحتاج في هذه اللحظة لوضع قواعد موحدة:
أولاً، إذا كان لدينا 10 صرافين، كيف نقوم بتوزيعهم على أي نافذة للعمل؟
ثانياً، إذا كان لدينا 1000 عميل في طابور ينتظرون، كيف نقرر أي عميل يذهب إلى أي نافذة للدفع؟
ثالثاً، كيف يمكن تلخيص دفاتر الحسابات العشرة المنفصلة التي تتوافق مع هذه النوافذ العشرة؟
رابعًا، لتجنب حدوث حالة عدم تطابق في الحسابات، كيف يمكن منع حدوث أخطاء من قبل أمين الصندوق؟
هذه الأسئلة تتعلق في الواقع ببعض القضايا الرئيسية في المشاركة، وهي كما يلي:
كيف يمكن تحديد أي كتلة من الشبكة تنتمي إليها العقد/المتحققون؟ أي: كيف يتم إجراء مشاركة الشبكة (Network Sharding)؛
كيف يمكن تحديد أي مشاركة يتم تخصيص كل معاملة لها؟ أي: كيف يتم إجراء مشاركة المعاملات (Transaction Sharding)؛
كيف يتم تخزين بيانات البلوكتشين في مشاركات مختلفة؟ أي: كيف يتم إجراء مشاركة الحالة (State Sharding)؛
تعني التعقيد المخاطر، بناءً على كل ما سبق، كيف يمكن تجنب تقسيم أمان النظام بأكمله؟
01 تجزئة الشبكة (Network Sharding)
إذا فهمنا البلوكتشين ببساطة على أنه نوع من دفتر الأستاذ الموزع، سواء كان آلية توافق بروتوكول إثبات الحصة (PoS) أو إثبات العمل (PoW)، فإن الهدف هو أن تتنافس العقد المختلفة على حق التسجيل وفقًا لقواعد معينة محددة مسبقًا، مع ضمان صحة السجل خلال هذه العملية. أما مشاركة الشبكة، فهي تشير إلى الحاجة إلى قواعد محددة أخرى، لتقسيم شبكة البلوكتشين إلى أجزاء، بحيث يتم معالجة المعاملات على السلسلة من قبل كل جزء مع تقليل التواصل فيما بينها قدر الإمكان، وتتنافس على حق التسجيل - أي، قواعد تجميع العقد.
وأثناء هذه العملية، تكمن المشكلة في أنه مع تقسيم العقد الداخلية في البلوكتشين إلى مشاركات مختلفة، ستنخفض صعوبة وتكلفة المهاجمين بشكل خطي. يمكننا أن نستنتج أنه إذا كانت قواعد هذه العملية ونتائجها ثابتة وقابلة للتنبؤ، فإن المهاجمين يحتاجون فقط إلى السيطرة على مشاركة واحدة من الشبكة الكاملة للبلوكتشين، من خلال السيطرة بشكل موجه على بعض العقد داخل تلك المشاركة.
يجب على نظام المشاركة تطوير آلية لإثبات أن الشبكة لن تعكس هذه المعاملات من أجزاء خارجية. حتى الآن، قد تكون أفضل إجابة هي ضمان أن عدد المدققين داخل الشريحة أعلى من حد أدنى معين، بحيث تقل احتمالية تمكن المدققين غير الأمان من السيطرة على شريحة واحدة. الطريقة الأكثر شيوعًا هي بناء مستوى معين من العشوائية غير المتحيزة، بالاعتماد على الرياضيات، لتقليل احتمال نجاح المهاجمين إلى الحد الأدنى. على سبيل المثال، إيثريوم، حيث تتمثل الحلول في اختيار مدقق لشريحة معينة بشكل عشوائي من جميع المدققين، ويتم تغيير المدققين كل 6.4 دقائق ( طول حقبة ).
ببساطة، يعني ذلك تقسيم العقد إلى مجموعات عشوائية، ثم توزيع العمل على عقد كل مجموعة للتحقق بشكل مستقل.
ومع ذلك، يجب الإشارة إلى أن العشوائية في البلوكتشين هي موضوع مليء بالتحديات، من المنطقي أن عملية إنشاء هذا الرقم العشوائي لا ينبغي أن تعتمد على حساب أي مشاركة معينة. بالنسبة لهذا الحساب، هناك الكثير من الأفكار التصميمية الحالية التي تتضمن تطوير بلوكتشين منفصل، للحفاظ على الشبكة بأكملها. تُعرف هذه السلسلة في Ethereum و Near بسلسلة Beacon، وفي PolkaDot تُعرف بسلسلة Relay، وفي Cosmos تُعرف بـ Cosmos Hub.
02 (Transaction Sharding) تجزئة المعاملات
تعيين المشاركة للمعاملات هو عبارة عن وضع قواعد حول "أي المعاملات يجب أن تُوزع على أي مشاركة"، مما يتيح تحقيق هدف المعالجة المتوازية وتجنب ظهور مشكلة الإنفاق المزدوج. سيؤثر اختلاف نموذج دفتر حسابات البلوكتشين على تطوير مشاركة المعاملات.
يوجد حاليًا نوعان من طرق المحاسبة في شبكة البلوكتشين، وهما نموذج مخرجات المعاملات غير المنفقة UTXO(، ونموذج الحساب/الرصيد، حيث يمثل الأول BTC، في حين أن الثاني مثل ETH.
نموذج UTXO: في معاملات BTC، سيكون لكل معاملة مخرجات واحدة أو أكثر، تشير UTXO إلى مخرجات معاملات البلوكتشين التي لم تُستخدم بعد، ويمكن استخدامها كمدخلات لمعاملات جديدة، بينما لا يمكن استخدام مخرجات المعاملات التي تم إنفاقها مرة أخرى، مشابهة لحالة الدفع والفكة في معاملات الأوراق النقدية، حيث يدفع العميل ورقة نقدية واحدة أو أكثر للتاجر، ثم يقوم التاجر بإعطاء العميل ورقة نقدية واحدة أو أكثر كفكة. تحت نموذج UTXO، تحتاج معاملات المشاركة إلى الاتصال عبر المشاركات. قد تشمل المعاملة الواحدة عدة مدخلات ومخرجات، ولا يوجد مفهوم الحسابات، ولا يوجد سجل للرصيد، إحدى الطرق الممكنة هي: وضعها في دالة هاش بناءً على قيمة مدخلات معاملتها لتحويلها إلى قيمة هاش منفصلة لتحديد البيانات التي يجب أن تذهب إلى أي مشاركة.
لضمان وضع الإدخالات بطريقة متسقة في الكتل الصحيحة، يجب أن تأتي القيم المدخلة في دالة التجزئة من نفس العمود. يُطلق على هذا العمود اسم مفتاح المشاركة. بعد ذلك، سيتم تخصيص المعاملات التي تنتج القيمة 1 إلى المشاركة 1، والمعاملات التي تنتج القيمة 2 إلى المشاركة 2. ومع ذلك، فإن عيب هذه الطريقة هو أنه يجب على المشاركات التواصل لتجنب هجمات الإنفاق المزدوج. إذا تم تقييد المعاملات عبر المشاركات، فسيؤدي ذلك إلى تقييد قابلية استخدام المنصة، بينما السماح بالمعاملات عبر المشاركات يتطلب موازنة بين تكلفة التواصل عبر المشاركات والفوائد الناتجة عن تحسين الأداء.
نموذج الحساب/الرصيد: يسجل النظام رصيد كل حساب، وعند إجراء المعاملات، يتحقق النظام مما إذا كان لدى الحساب رصيد كافٍ للدفع، مماثلًًا لعمليات التحويل البنكي حيث تسجل البنوك رصيد كل حساب، ولا يمكن تنفيذ المعاملة إلا إذا كان رصيد الحساب أكبر من مبلغ التحويل المطلوب. تحت نموذج الحساب/الرصيد، نظرًا لأن المعاملة تحتوي على إدخال واحد فقط، فإنه يكفي تقسيم المعاملة حسب عنوان المرسل، لضمان معالجة عدة معاملات لنفس الحساب في نفس المشاركة، مما يمنع بشكل فعال ظاهرة الإنفاق المزدوج. لذلك، فإن معظم سلاسل الكتل التي تستخدم تقنية المشاركة هي أنظمة دفاتر حسابات مثل الإيثيريوم.
![شرح مفصل عن البلوكتشين الجديد Shardeum: إمكانية جديدة للمشاركة])https://img-cdn.gateio.im/webp-social/moments-4227a2e49f76cd01b23d7b5398e51a3c.webp(
) 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، مما سيؤدي إلى تقليل كفاءة معالجة المعاملات. ومع ذلك، إذا لم يتم تنزيل والتحقق من التاريخ الكامل لمشاركة معينة، فلن يتمكن المشاركون بالضرورة من التأكد من أن حالة التفاعل بينهم هي نتيجة لتسلسل كتل صالحة معينة، وأن هذا التسلسل من الكتل هو بالفعل السلسلة القياسية داخل المشاركة.
لذلك، بالمقارنة مع سلسلة واحدة بدون مشاركة، فإن النظام القائم على المشاركة يواجه تحديًا جديدًا وهو أن المستخدمين لا يمكنهم التحقق بالكامل من صحة وموثوقية أي سلسلة معينة، لأن البيانات كثيرة جدًا. يجب توفير طرق غير موثوقة وعملية إلى أقصى حد للمستخدمين للتحقق من أي سلسلة متاحة تمامًا وصالحة، وذلك لتمكينهم من تحديد أي سلسلة هي السلسلة القياسية. في الممارسة العملية، يمكن لمطوري البلوكتشين استخدام التقنيات التالية لحل بعض مشكلات التحقق: مثل اللجان، وSNARKs/STARKs، وآلية الصياد، بالإضافة إلى إثبات الاحتيال وموثوقية البيانات.
هناك فكرتان لحل هذه المشكلة، واحدة هي التزامن عبر المشاركة