1. في المرحلة المبكرة من البلوكشين، يعتبر الحفاظ على اتساق البيانات أمرًا بالغ الأهمية لضمان الأمن واللامركزية. ومع ذلك، مع تطور النظام البيئي لبلوكتشين، يزداد ضغط التخزين أيضًا، مما يؤدي إلى اتجاه المركزية في تشغيل العقدة. في هذه الحالة، يجب حل مشكلة تكلفة التخزين الناتجة عن نمو TPS في Layer1 بشكل عاجل.
2. في مواجهة هذه المشكلة، يجب على المطورين اقتراح حل يأخذ في الاعتبار الأمان وتكلفة التخزين وسرعة قراءة البيانات وتعدد استخدامات طبقة DA بشكل كامل.
3. في عملية حل هذه المشكلة، ظهرت العديد من التقنيات والأفكار الجديدة، بما في ذلك مكونات Sharding و DAS و Verkle Tree و DA الوسيطة وما إلى ذلك. إنهم يحاولون تحسين نظام التخزين لطبقة DA عن طريق تقليل تكرار البيانات وتحسين كفاءة التحقق من صحة البيانات.
4. يتم تصنيف حلول DA على نطاق واسع إلى نوعين من منظور موقع تخزين البيانات، وهما DAs للسلسلة الرئيسية و DAs التابعة لجهات خارجية. تم تصميم DAs للسلسلة الرئيسية من منظور التطهير المنتظم للبيانات وتخزين البيانات المقطعة لتقليل ضغط التخزين على العقد، بينما تم تصميم DAs التابعة لجهات خارجية لتلبية احتياجات التخزين والحصول على حلول معقولة لكميات كبيرة من البيانات. ونتيجة لذلك، نقوم بشكل أساسي بالمفاضلة بين التوافق أحادي السلسلة والتوافق متعدد السلاسل في DAs التابعة لجهات خارجية، ونقترح ثلاثة أنواع من الحلول: DAs الخاصة بالسلسلة الرئيسية، و DAs المعيارية، و DAs ذات السلسلة العامة للتخزين.
5. تتمتع السلاسل العامة من نوع الدفع بمتطلبات عالية جدًا لأمن البيانات التاريخية، وبالتالي فهي مناسبة للاستخدام في السلسلة الرئيسية كطبقة DA. ومع ذلك، بالنسبة للسلاسل العامة التي تعمل منذ فترة طويلة ولديها عدد كبير من عمال المناجم الذين يديرون الشبكة، فمن الأنسب اعتماد DA تابع لجهة خارجية لا يتضمن تغيير طبقة الإجماع بأمان مرتفع نسبيًا. بالنسبة للسلاسل العامة الشاملة، من الأنسب استخدام تخزين DA المخصص للسلسلة الرئيسية بسعة بيانات أكبر وتكلفة أقل وأمان. ومع ذلك، وبالنظر إلى الطلب على السلاسل المتقاطعة، فإن DA المعياري يعد أيضًا خيارًا جيدًا.
6. وبشكل عام، تتجه بلوكتشين نحو الحد من تكرار البيانات بالإضافة إلى تقسيم العمل متعدد السلاسل.

1. الخلفية

وباعتبارها دفتر الأستاذ الموزع، تحتاج بلوكتشين إلى تخزين البيانات التاريخية على جميع العقد لضمان الأمان واللامركزية الكافية لتخزين البيانات. نظرًا لأن صحة كل تغيير في الحالة مرتبطة بالحالة السابقة (مصدر المعاملة)، لضمان صحة المعاملات، يجب على البلوكشين من حيث المبدأ تخزين جميع السجلات التاريخية من المعاملة الأولى إلى المعاملة الحالية. إذا أخذنا إيثريوم كمثال، حتى إذا كان متوسط حجم الكتلة يُقدر بـ 20 كيلو بايت، فإن الحجم الإجمالي الحالي لكتل إيثريوم قد وصل إلى 370 جيجابايت. بالإضافة إلى الكتلة نفسها، تحتاج العقدة الكاملة أيضًا إلى تسجيل إيصالات الحالة والمعاملات. عند حساب هذا الجزء، تجاوزت سعة التخزين الإجمالية للعقدة الواحدة 1 تيرابايت، مما يركز تشغيل العقدة على عدد قليل من الأشخاص.

أحدث ارتفاع لكتلة إيثريوم، مصدر الصورة: Etherscan

2. مؤشرات أداء DA

2.1 الأمان

وبالمقارنة مع قواعد البيانات أو هياكل تخزين القوائم المرتبطة، فإن عدم قابلية بلوكتشين للمقارنة يأتي من القدرة على التحقق من البيانات التي تم إنشاؤها حديثًا من خلال البيانات التاريخية. لذلك، فإن ضمان أمان البيانات التاريخية هو المشكلة الأولى التي يجب أخذها في الاعتبار في تخزين طبقة DA. عند الحكم على أمان بيانات أنظمة بلوكتشين، غالبًا ما نقوم بتحليلها من خلال مقدار تكرار البيانات وطريقة التحقق من توفر البيانات.

1. مقدار التكرار: فيما يتعلق بتكرار البيانات في نظام بلوكتشين، يمكن أن تلعب بشكل أساسي الأدوار التالية: أولاً، إذا كان عدد التكرارات في الشبكة أكبر، عندما يحتاج المدقق إلى عرض حالة الحساب في كتلة تاريخية معينة للتحقق عندما يتم التحقق من المعاملة، يمكنه الحصول على معظم العينات للرجوع إليها وتحديد البيانات المسجلة بواسطة معظم العقد. في قواعد البيانات التقليدية، نظرًا لأن البيانات يتم تخزينها فقط في شكل أزواج من القيم الرئيسية على عقدة معينة، فلا يمكن إجراء التغييرات على البيانات التاريخية إلا على عقدة واحدة، وتكلفة الهجوم منخفضة للغاية. من الناحية النظرية، كلما زاد عدد حالات التكرار، قل احتمال ظهور البيانات. كلما ارتفعت درجة المصداقية. في الوقت نفسه، كلما تم تخزين المزيد من العقد، قل احتمال فقدان البيانات. يمكن أيضًا مقارنة ذلك بالخادم المركزي الذي يخزن ألعاب Web2. بمجرد إغلاق جميع خوادم الواجهة الخلفية، سيتم إغلاق الخادم تمامًا. ومع ذلك، كلما كان ذلك أفضل، لأن كل قطعة احتياطية ستوفر مساحة تخزين إضافية. سيؤدي التكرار المفرط للبيانات إلى ضغط تخزين مفرط على النظام. يجب أن تختار طبقة DA الجيدة طبقة مناسبة. يوازن الأسلوب الاحتياطي بين الأمان وكفاءة التخزين.
2. التحقق من توفر البيانات: يضمن عدد مرات التكرار وجود سجلات كافية للبيانات في الشبكة، ولكن يجب التحقق من دقة واكتمال البيانات التي سيتم استخدامها. إن طريقة التحقق الشائعة الاستخدام في بلوكتشين الحالية هي خوارزمية الالتزام بالتشفير، والتي تحتفظ بالتزام تشفير صغير للشبكة بأكملها لتسجيله. يتم الحصول على هذا الالتزام من خلال خلط بيانات المعاملات. عندما تريد اختبار أصالة جزء معين من البيانات التاريخية، فأنت بحاجة إلى استعادة التزام التشفير من خلال البيانات والتحقق مما إذا كان التزام التشفير الذي تم الحصول عليه من خلال هذه الاستعادة متوافقًا مع سجلات الشبكة بأكملها. إذا كان الأمر متسقًا، يتم تمرير التحقق. تتضمن خوارزميات التحقق من التشفير الشائعة الاستخدام Verkle Root و Verkle Root. لا تتطلب خوارزمية التحقق من توفر البيانات عالية الأمان سوى كمية صغيرة من بيانات التحقق ويمكنها التحقق بسرعة من البيانات التاريخية.

2.2 تكلفة التخزين

على أساس ضمان الأمان الأساسي، فإن الهدف الأساسي التالي الذي تحتاج طبقة DA إلى تحقيقه هو تقليل التكاليف وزيادة الكفاءة. الأول هو تقليل تكاليف التخزين، بغض النظر عن الاختلافات في أداء الأجهزة، أي تقليل استخدام الذاكرة الناتج عن تخزين البيانات بحجم الوحدة. في هذه المرحلة، تتمثل الطرق الرئيسية لتقليل تكاليف التخزين في بلوكتشين في اعتماد تقنية المشاركة واستخدام التخزين القائم على المكافآت لضمان تخزين البيانات بشكل فعال وتقليل عدد النسخ الاحتياطية للبيانات. ومع ذلك، ليس من الصعب أن نرى من طرق التحسين المذكورة أعلاه أن هناك علاقة لعبة بين تكلفة التخزين وأمن البيانات. غالبًا ما يعني تقليل إشغال وحدات التخزين انخفاضًا في الأمان. لذلك، تحتاج طبقة DA الممتازة إلى تحقيق التوازن بين تكلفة التخزين وأمن البيانات. بالإضافة إلى ذلك، إذا كانت طبقة DA عبارة عن سلسلة عامة منفصلة، فإنها تحتاج إلى تقليل التكلفة عن طريق تقليل العملية الوسيطة لتبادل البيانات. في كل عملية نقل، يجب ترك بيانات الفهرس لاستدعاءات الاستعلام اللاحقة. لذلك، كلما طالت عملية الاتصال، سيتم ترك المزيد من بيانات الفهرس وستزداد تكلفة التخزين. أخيرًا، ترتبط تكلفة تخزين البيانات ارتباطًا مباشرًا بمتانة البيانات. بشكل عام، كلما ارتفعت تكلفة تخزين البيانات، زادت صعوبة تخزين السلسلة العامة للبيانات باستمرار.

2.3 سرعة قراءة البيانات

بعد تحقيق خفض التكلفة، تتمثل الخطوة التالية في زيادة الكفاءة، وهي القدرة على استدعاء البيانات بسرعة من طبقة DA عند الحاجة إلى استخدامها. تتضمن هذه العملية خطوتين. الأول هو البحث عن العقد التي تخزن البيانات. هذه العملية مخصصة بشكل أساسي للسلاسل العامة التي لم تحقق اتساق البيانات عبر الشبكة بأكملها. إذا حققت السلسلة العامة مزامنة البيانات للعقد عبر الشبكة بأكملها، فيمكن تجاهل ذلك. استهلاك الوقت للعملية. ثانيًا، في أنظمة بلوكتشين السائدة الحالية، بما في ذلك بيتكوين وإيثيريوم وفايلكوين، فإن طريقة تخزين العقدة هي قاعدة بيانات Leveldb. في Leveldb، يتم تخزين البيانات بثلاث طرق. أولاً، سيتم تخزين البيانات المكتوبة على الفور في ملفات من نوع Memtable. عند امتلاء مساحة التخزين Memtable، سيتم تغيير نوع الملف من Memtable إلى Immutable Memtable. يتم تخزين كلا النوعين من الملفات في الذاكرة، ولكن لم يعد من الممكن تغيير ملفات Immutable Memtable، بل يمكن قراءة البيانات منها فقط. تقوم وحدة التخزين الساخنة المستخدمة في شبكة IPFS بتخزين البيانات في هذا الجزء. عندما يتم استدعاؤها، يمكن قراءتها بسرعة من الذاكرة. ومع ذلك، غالبًا ما تكون الذاكرة المحمولة للعقدة العادية بمستوى غيغابايت، ومن السهل الكتابة ببطء، عند تعطل العقدة أو حدوث حالة غير طبيعية أخرى، ستفقد البيانات الموجودة في الذاكرة نهائيًا. إذا كنت تريد تخزين البيانات باستمرار، فأنت بحاجة إلى تخزينها في شكل ملف SST على محرك أقراص ذي حالة صلبة (SSD). ومع ذلك، عند قراءة البيانات، تحتاج إلى قراءة البيانات في الذاكرة أولاً، مما يقلل بشكل كبير من سرعة فهرسة البيانات. أخيرًا، بالنسبة للأنظمة التي تستخدم التخزين المشترك، تتطلب استعادة البيانات إرسال طلبات البيانات إلى عقد متعددة واستعادتها. ستؤدي هذه العملية أيضًا إلى تقليل سرعة قراءة البيانات.

طريقة تخزين بيانات Leveldb، مصدر الصورة: دليل LevelDB

2.4 تعميم DA

مع تطور DeFi والمشكلات المختلفة مع CEX، تتزايد أيضًا متطلبات المستخدمين للمعاملات عبر السلاسل للأصول اللامركزية. بغض النظر عن الآلية المتقاطعة لقفل التجزئة أو كاتب العدل أو سلسلة الترحيل، لا يمكن تجنب التحديد المتزامن للبيانات التاريخية على كلتا السلسلتين. يكمن مفتاح هذه المشكلة في فصل البيانات على السلسلتين، ولا يمكن تحقيق الاتصال المباشر في الأنظمة اللامركزية المختلفة. لذلك، يُقترح حل في هذه المرحلة عن طريق تغيير طريقة تخزين طبقة DA، والتي لا تخزن البيانات التاريخية لسلاسل عامة متعددة على نفس السلسلة العامة الموثوقة فحسب، بل تحتاج فقط إلى استدعاء البيانات الموجودة على هذه السلسلة العامة أثناء التحقق. يستطيع. يتطلب ذلك أن تكون طبقة DA قادرة على إنشاء طرق اتصال آمنة مع أنواع مختلفة من السلاسل العامة، مما يعني أن طبقة DA تتمتع بتعدد جيد.

3. التقنيات المتعلقة بـ DA

3.1 التقسيم

1. في النظام الموزع التقليدي، لا يتم تخزين الملف بشكل كامل على عقدة معينة. بدلاً من ذلك، يتم تقسيم البيانات الأصلية إلى عدة كتل ويتم تخزين كتلة واحدة في كل عقدة. غالبًا لا يتم تخزين الكتل على عقدة واحدة فقط ولكنها ستترك نسخًا احتياطية مناسبة على العقد الأخرى. في الأنظمة الموزعة السائدة الحالية، يتم تعيين هذا العدد من النسخ الاحتياطية عادةً على 2. يمكن لآلية التقسيم هذه تقليل ضغط التخزين لعقدة واحدة، وتوسيع السعة الإجمالية للنظام إلى مجموع سعة التخزين لكل عقدة، وفي نفس الوقت ضمان أمان التخزين من خلال التكرار المناسب للبيانات. يتشابه نظام Sharding المعتمد في البلوكشين بشكل عام، ولكن التفاصيل المحددة ستكون مختلفة. أولًا، نظرًا لأن كل عقدة في بلوكتشين غير جديرة بالثقة افتراضيًا، فإن عملية تنفيذ التقسيم تتطلب قدرًا كبيرًا بما يكفي من النسخ الاحتياطي للبيانات للحكم اللاحق على أصالة البيانات، لذلك يجب أن يكون عدد النسخ الاحتياطية لهذه العقدة أكثر من 2. من الناحية المثالية، في نظام blockchain الذي يستخدم نظام التخزين هذا، إذا كان العدد الإجمالي لعقد التحقق هو T وعدد الأجزاء هو N، فيجب أن يكون عدد النسخ الاحتياطية T/N. والثاني هو عملية تخزين الكتلة. هناك عدد أقل من العقد في الأنظمة الموزعة التقليدية، لذلك غالبًا ما تتكيف عقدة واحدة مع كتل بيانات متعددة. أولاً، يتم تعيين البيانات إلى حلقة التجزئة من خلال خوارزمية التجزئة المتسقة، ثم تقوم كل عقدة بتخزين كتل البيانات المرقمة في نطاق معين، ويمكن أن تقبل أن العقدة لا تخصص مهام تخزين أثناء تخزين معين. على البلوكشين، لم يعد تخصيص كتلة لكل عقدة حدثًا عشوائيًا ولكنه حدث لا مفر منه. ستختار كل عقدة بشكل عشوائي كتلة للتخزين. تجمع هذه العملية البيانات الأصلية مع الكتلة ومعلومات العقدة. يتم إكمال نتيجة تجزئة البيانات بأخذ معامل عدد الأجزاء. بافتراض أن كل جزء من البيانات مقسم إلى N Blocks، فإن حجم التخزين الفعلي لكل عقدة هو 1/N فقط من الأصل. من خلال ضبط N بشكل مناسب، يمكن تحقيق التوازن بين TPS المتزايد وضغط تخزين العقدة.

طريقة تخزين البيانات بعد التقسيم، مصدر الصورة: Kernel Ventures

3.2 DAS（أخذ عينات توافر البيانات）

تعتمد تقنية DAS على التحسين الإضافي لطرق تخزين Sharding. أثناء عملية التقسيم، بسبب التخزين العشوائي البسيط للعقد، قد يتم فقدان كتلة معينة. ثانيًا، بالنسبة للبيانات المجزأة، من المهم جدًا أيضًا تأكيد صحة البيانات وسلامتها أثناء عملية الاستعادة. في DAS، يتم حل هاتين المشكلتين من خلال كود Eraser والتزام KZG متعدد الحدود.

1. كود الممحاة: بالنظر إلى العدد الهائل من عقد التحقق في إيثريوم، فإن احتمال عدم تخزين كتلة معينة بواسطة أي عقدة هو صفر تقريبًا، ولكن من الناحية النظرية لا يزال هناك احتمال حدوث مثل هذا الموقف المتطرف. للتخفيف من هذا التهديد المحتمل بفقدان التخزين، بموجب هذا المخطط، غالبًا ما لا يتم تقسيم البيانات الأصلية بشكل مباشر إلى كتل للتخزين. بدلاً من ذلك، يتم تعيين البيانات الأصلية أولاً لمعاملات متعدد الحدود من الرتبة n، ثم يتم أخذ 2n من متعدد الحدود. النقاط، ودع العقدة تختار عشوائيًا واحدة منها للتخزين. بالنسبة إلى متعدد الحدود هذا ذو الترتيب n، لا يلزم سوى نقاط n+1 لاستعادته. لذلك، يجب تحديد نصف الكتل فقط بواسطة العقد، ويمكننا استعادة البيانات الأصلية. من خلال رمز Eraser، تم تحسين أمان تخزين البيانات وقدرة استعادة بيانات الشبكة.
2. يعد التحقق من صحة البيانات أحد الجوانب المهمة جدًا لتخزين البيانات. في الشبكات التي لا تستخدم كود Eraser، يمكن استخدام طرق مختلفة للتحقق، ولكن إذا تم تقديم رمز Eraser أعلاه لتحسين أمان البيانات، فمن الأنسب استخدام التزام KZG متعدد الحدود، والذي يمكنه التحقق من محتويات كتلة واحدة مباشرة في شكل متعدد الحدود، وبالتالي القضاء على الحاجة إلى تقليل البيانات متعددة الحدود إلى بيانات ثنائية. يمكن لالتزام KZG متعدد الحدود التحقق مباشرة من محتوى كتلة واحدة في شكل متعددات الحدود، وبالتالي القضاء على الحاجة إلى تقليل تعدد الحدود إلى بيانات ثنائية، والشكل العام للتحقق مشابه لشكل Merkle Tree، ولكنه لا يتطلب بيانات عقدة المسار المحددة ويتطلب فقط KZG Root وبيانات الكتلة للتحقق من صحة الكتلة.

3.3 طريقة التحقق من صحة البيانات في DA

يضمن التحقق من صحة البيانات أن البيانات التي يتم استدعاؤها من العقدة دقيقة وكاملة. لتقليل كمية البيانات والتكلفة الحسابية المطلوبة في عملية التحقق، تستخدم طبقة DA الآن بنية شجرة كطريقة التحقق السائدة. أبسط شكل هو استخدام Merkle Tree للتحقق، والذي يستخدم شكل سجلات شجرة ثنائية كاملة، ويحتاج فقط إلى الاحتفاظ بـ Merkle Root ويمكن التحقق من قيمة التجزئة للشجرة الفرعية على الجانب الآخر من مسار العقدة، والتعقيد الزمني للتحقق هو مستوى O (LogN) (LogN هو logN الافتراضي log2 (N)). على الرغم من تبسيط عملية التحقق إلى حد كبير، إلا أن كمية البيانات لعملية التحقق بشكل عام لا تزال تنمو مع زيادة البيانات. لحل مشكلة زيادة حجم التحقق، يتم اقتراح طريقة تحقق أخرى، وهي Verkle Tree، في هذه المرحلة، حيث لا تقوم كل عقدة في Verkle Tree بتخزين القيمة فحسب، بل ترفق أيضًا التزامًا متجهًا، والذي يمكنه التحقق بسرعة من صحة البيانات باستخدام قيمة العقدة الأصلية وإثبات الالتزام، دون الحاجة إلى استدعاء قيم العقد الشقيقة الأخرى، مما يجعل حساب كل عملية تحقق أسهل وأسرع. هذا يجعل عدد الحسابات لكل عملية تحقق مرتبطًا فقط بعمق شجرة Verkle، وهو ثابت ثابت، مما يؤدي إلى تسريع سرعة التحقق بشكل كبير. ومع ذلك، يتطلب حساب Vector Commitation مشاركة جميع العقد الشقيقة في نفس الطبقة، مما يزيد بشكل كبير من تكلفة كتابة البيانات وتغييرها. ومع ذلك، بالنسبة للبيانات مثل البيانات التاريخية، التي يتم تخزينها بشكل دائم ولا يمكن العبث بها، يمكن أيضًا قراءتها فقط ولكن لا يمكن كتابتها، فإن Verkle Tree مناسبة للغاية. بالإضافة إلى ذلك، تحتوي Merkle Tree و Verkle Tree نفسها على شكل K-ary من المتغيرات، والتنفيذ المحدد للآلية مشابه، ما عليك سوى تغيير عدد الأشجار الفرعية تحت كل عقدة، ويمكن رؤية مقارنة الأداء المحددة في الجدول التالي.

مقارنة الأداء الزمني لطرق التحقق من البيانات، مصدر الصورة: Verkle Trees

3.4 البرامج الوسيطة العامة DA

أدى التوسع المستمر في نظام blockchain البيئي إلى زيادة مستمرة في عدد السلاسل العامة. نظرًا لمزايا كل سلسلة عامة وعدم قابليتها للاستبدال في مجالات تخصصها، فمن المستحيل تقريبًا أن تتحد سلاسل الطبقة الأولى العامة في وقت قصير. ومع ذلك، مع تطور DeFi والمشاكل المختلفة مع CEX، تتزايد أيضًا متطلبات المستخدمين لأصول التداول اللامركزية عبر السلاسل. لذلك، حظي تخزين البيانات متعدد السلاسل بطبقة DA والذي يمكنه القضاء على مشكلات الأمان في تفاعلات البيانات عبر السلاسل باهتمام متزايد. ومع ذلك، لقبول البيانات التاريخية من سلاسل عامة مختلفة، تحتاج طبقة DA إلى توفير بروتوكول لامركزي للتخزين الموحد والتحقق من تدفقات البيانات. على سبيل المثال، تقوم kvye، وهي برمجية وسيطة للتخزين تعتمد على Arweave، بجمع البيانات بنشاط من السلسلة ويتم تخزين جميع البيانات الموجودة على السلسلة في Arweave في شكل قياسي لتقليل الاختلافات في عملية نقل البيانات. من الناحية النسبية، تتفاعل Layer2، التي توفر تحديدًا تخزين بيانات طبقة DA لسلسلة عامة معينة، مع البيانات من خلال العقد المشتركة الداخلية. على الرغم من أنه يقلل من تكلفة التفاعل ويحسن الأمان، إلا أنه يحتوي على قيود كبيرة نسبيًا ويمكنه فقط توفير البيانات إلى سلاسل عامة محددة تقدم الخدمات.

4. طرق تخزين DA

4.1 السلسلة الرئيسية DA

4.1.1 مثل مشاركة الشكر

هذا النوع من حلول التخزين ليس له اسم محدد حتى الآن، والممثل الأبرز هو DankSharding على Ethereum، لذلك تستخدم هذه المقالة فئة DankSharding للإشارة إلى هذا النوع من الحلول. يستخدم هذا النوع من الحلول بشكل أساسي تقنيتي تخزين DA المذكورتين أعلاه، Sharding و DAS. أولاً، يتم تقسيم البيانات إلى مشاركات مناسبة من خلال Sharding، ثم تقوم كل عقدة باستخراج كتلة بيانات في شكل DAS للتخزين. إذا كان هناك عدد كافٍ من العقد في الشبكة بأكملها، فيمكننا اختيار عدد أكبر من الأجزاء N، بحيث يكون ضغط التخزين لكل عقدة 1/N فقط من الأصل، وبالتالي تحقيق توسع بمقدار N مرة في مساحة التخزين الإجمالية. في الوقت نفسه، لمنع الموقف المتطرف المتمثل في عدم تخزين كتلة معينة في أي كتلة، يقوم DankSharding بترميز البيانات باستخدام Eraser Code، ويمكن استعادة نصف البيانات فقط تمامًا. الخطوة الأخيرة هي عملية التحقق من البيانات، والتي تستخدم بنية شجرة Verkle والالتزام متعدد الحدود لتحقيق التحقق السريع.

4.1.2 تخزين مؤقت

بالنسبة إلى DA للسلسلة الرئيسية، تتمثل إحدى أبسط طرق معالجة البيانات في تخزين البيانات التاريخية على المدى القصير. وفي الأساس، تلعب بلوكتشين دور دفتر الأستاذ العام، مما يسمح بمشاهدة التغييرات التي تطرأ على محتوى دفتر الأستاذ من قبل الشبكة بأكملها، دون الحاجة إلى تخزين دائم. بأخذ Solana كمثال، على الرغم من مزامنة بياناتها التاريخية مع Arweave، فإن عقدة الشبكة الرئيسية تحتفظ فقط ببيانات المعاملات في اليومين الماضيين. في السلسلة العامة المستندة إلى سجلات الحساب، تحتفظ البيانات التاريخية في كل لحظة بالحالة النهائية للحساب على البلوكشين، وهو ما يكفي لتوفير أساس التحقق من التغييرات في اللحظة التالية. بالنسبة للمشاريع التي لديها احتياجات خاصة للبيانات قبل هذه الفترة، يمكنها تخزينها بنفسها على سلاسل عامة لامركزية أخرى أو بواسطة طرف ثالث موثوق به. بمعنى آخر، يحتاج أولئك الذين لديهم احتياجات بيانات إضافية إلى الدفع مقابل تخزين البيانات التاريخية.

4.2 DA لطرف ثالث

4.2.1 DA الخاص بالسلسلة الرئيسية: ETHStorage

1. DA الخاص بالسلسلة الرئيسية: أهم شيء في طبقة DA هو أمان نقل البيانات. الأكثر أمانًا في هذه المرحلة هو DA للسلسلة الرئيسية. ومع ذلك، يخضع تخزين السلسلة الرئيسية لقيود مساحة التخزين والمنافسة على الموارد. لذلك، عندما تنمو كمية بيانات الشبكة بسرعة، سيكون DA التابع لجهة خارجية خيارًا أفضل إذا أريد تحقيق تخزين طويل الأجل للبيانات. إذا كان DA التابع لجهة خارجية يتمتع بتوافق أعلى مع الشبكة الرئيسية، فيمكنه تحقيق مشاركة العقد، وسيكون لديه أيضًا مستوى أعلى من الأمان أثناء عملية تفاعل البيانات. لذلك، في إطار فرضية النظر في الأمان، سيكون لـ DA الخاص بالسلسلة الرئيسية مزايا ضخمة. وبأخذ إيثريوم كمثال، فإن أحد المتطلبات الأساسية لـ DA الخاص بالسلسلة الرئيسية هو أن يكون متوافقًا مع EVM ويضمن قابلية التشغيل البيني مع بيانات وعقود إيثريوم. تشمل المشاريع التمثيلية Topia و ETHStorage وما إلى ذلك. من بينها، تعد ETHStorage حاليًا الأكثر تطورًا من حيث التوافق، لأنه بالإضافة إلى التوافق على مستوى EVM، فقد قامت أيضًا بإعداد واجهات ذات صلة بشكل خاص للاتصال بأدوات تطوير Ethereum مثل Remix و Hardhat لتحقيق التوافق على مستوى أداة تطوير Ethereum.
2. ETHStorage: ETHStorage هي سلسلة عامة مستقلة عن إيثريوم، ولكن العقد التي تعمل عليها تتفوق على عقد إيثريوم. أي أن العقد التي تقوم بتشغيل ETHStorage يمكنها أيضًا تشغيل Ethereum في نفس الوقت. من خلال رموز التشغيل على Ethereum، يمكنك الوصول مباشرة إلى ETHStorage. تقوم ETHStorage بتنفيذ العمليات. في نموذج التخزين الخاص بـ ETHStorage، يتم الاحتفاظ بكمية صغيرة فقط من البيانات الوصفية على شبكة Ethereum الرئيسية للفهرسة، مما يؤدي بشكل أساسي إلى إنشاء قاعدة بيانات لامركزية لـ Ethereum. وفي الحل الحالي، تنفذ ETHStorage التفاعل بين شبكة إيثريوم الرئيسية وETHStorage من خلال نشر عقد ETHStorage على شبكة إيثريوم الرئيسية. إذا أرادت إيثريوم تخزين البيانات، فإنها تحتاج إلى استدعاء وظيفة put () في العقد. ومعلمات الإدخال هي مفتاح المتغيرات ثنائية البايت والبيانات، حيث تمثل البيانات البيانات التي سيتم تخزينها، والمفتاح هو موقعها في شبكة إيثريوم. يمكن اعتبار التعريف مشابهًا لوجود CID في IPFS. بعد تخزين زوج البيانات (المفتاح والبيانات) بنجاح في شبكة ETHStorage، ستقوم ETHStorage بإنشاء kvldx وإعادته إلى شبكة Ethereum الرئيسية، ويتوافق مع المفتاح الموجود على Ethereum. تتوافق هذه القيمة مع عنوان تخزين البيانات على ETHStorage، لذلك كان ذلك ممكنًا في الأصل. أصبحت مشكلة الحاجة إلى تخزين كميات كبيرة من البيانات الآن تخزين زوج واحد (مفتاح، kvldx)، مما يقلل بشكل كبير من تكلفة تخزين شبكة Ethereum الرئيسية. إذا كنت بحاجة إلى استدعاء البيانات المخزنة مسبقًا، فأنت بحاجة إلى استخدام وظيفة get () في ETHStorage وإدخال المعلمة الرئيسية. يمكنك البحث بسرعة عن البيانات على ETHStorage من خلال kvldx المخزن في إيثريوم.

عقد تخزين ETHstorage، مصدر الصورة: كيرنيل فنتشرز

1. فيما يتعلق بكيفية تخزين العقد للبيانات على وجه التحديد، تعتمد ETHStorage على نموذج Arweave. أولاً، يتم تقسيم عدد كبير من أزواج (k، v) من ETH. تحتوي كل مشاركة على عدد ثابت من أزواج البيانات (k، v). يوجد أيضًا حد للحجم المحدد لكل زوج (k، v). وبهذه الطريقة، يتم ضمان عدالة عبء العمل اللاحق لعمال المناجم في عملية مكافأة التخزين. لإصدار المكافآت، من الضروري أولاً التحقق مما إذا كانت العقدة تخزن البيانات. وخلال هذه العملية، ستقوم ETHStorage بتقسيم التجزئة (حجم مستوى TB) إلى عدة أجزاء، مع الاحتفاظ بجذر Verkle على شبكة إيثريوم الرئيسية للتحقق. ثم يحتاج المُعدِّن أولاً إلى تقديم اسم لإنشاء عناوين عدة أجزاء من خلال خوارزمية عشوائية مع تجزئة الكتلة السابقة على ETHStorage. يحتاج المُعدِّن إلى توفير بيانات هذه القطع لإثبات أنه يخزن بالفعل التقسيم بأكمله. ولكن لا يمكن تحديد هذا مرة واحدة بشكل تعسفي، وإلا فإن العقدة ستختار نقطة مناسبة تتوافق فقط مع الجزء المخزن الخاص بها وتجتاز عملية التحقق. لذلك، يجب أن تكون هذه النقطة بحيث يمكن لقيمة صعوبة المقطع الذي تم إنشاؤه أن تلبي متطلبات الشبكة بعد الخلط والتجزئة، ويمكن فقط للعقدة الأولى التي تقدم الدليل غير المباشر والوصول العشوائي الحصول على المكافأة.

4.2.2 نمذجة الحمض النووي: سيليستيا

1. وحدة Blockchain: في هذه المرحلة، تنقسم المعاملات المطلوب تنفيذها بواسطة سلسلة Layer1 العامة بشكل أساسي إلى الأجزاء الأربعة التالية: (1) تصميم المنطق الأساسي للشبكة، وتحديد عقد التحقق بطريقة معينة، وكتابة الكتل وتخصيص المكافآت لمشرفي الشبكة؛ (2) تجميع المعاملات ومعالجتها ونشر المعاملات ذات الصلة؛ (3) التحقق من المعاملات التي سيتم تحميلها إلى السلسلة وتحديد الحالة النهائية؛ (4) تخزين البيانات التاريخية والحفاظ عليها على بلوكشين. وفقًا للوظائف المختلفة المكتملة، يمكننا تقسيم البلوكشين إلى أربع وحدات، وهي طبقة الإجماع وطبقة التنفيذ وطبقة التسوية وطبقة توفر البيانات (طبقة DA).
2. تصميم بلوكشين المعياري: لفترة طويلة، تم دمج هذه الوحدات الأربع في سلسلة عامة. وتسمى هذه البلوكشين بلوكشين واحدة. هذا النموذج أكثر استقرارًا وأسهل في الصيانة، ولكنه أيضًا يضع ضغطًا كبيرًا على سلسلة عامة واحدة. أثناء التشغيل الفعلي، تقيد هذه الوحدات الأربع بعضها البعض وتتنافس على موارد الحوسبة والتخزين المحدودة للسلسلة العامة. على سبيل المثال، ستؤدي زيادة سرعة معالجة طبقة المعالجة إلى زيادة ضغط التخزين على طبقة توفر البيانات؛ لضمان أمان طبقة التنفيذ، يلزم وجود آلية تحقق أكثر تعقيدًا ولكنها تبطئ سرعة معالجة المعاملات. لذلك، غالبًا ما يواجه تطوير السلاسل العامة مقايضات بين هذه الوحدات الأربع. وللتغلب على عقبة تحسين أداء السلسلة العامة، اقترح المطورون حلًا معياريًا لبلوكتشين. تتمثل الفكرة الأساسية لـ blockchain المعياري في فصل واحدة أو أكثر من الوحدات الأربع المذكورة أعلاه وتنفيذها على سلسلة عامة منفصلة. وبهذه الطريقة، يمكن للسلسلة العامة التركيز فقط على تحسين سرعة المعاملات أو سعة التخزين، وكسر القيود السابقة على الأداء العام للبلوكشين بسبب أوجه القصور.
3. Modular DA: تعتبر الطريقة المعقدة لفصل طبقة DA عن أعمال blockchain وتسليمها إلى سلسلة عامة حلاً عمليًا للبيانات التاريخية المتنامية للطبقة الأولى. لا يزال الاستكشاف في هذا المجال في المراحل الأولى في هذه المرحلة، والمشروع الأكثر تمثيلًا في الوقت الحاضر هو Celestia. فيما يتعلق بطريقة التخزين المحددة، تعتمد Celestia على طريقة تخزين Danksharding، والتي تقسم أيضًا البيانات إلى كتل متعددة، وتستخرج كل عقدة جزءًا للتخزين وتستخدم التزام KZG متعدد الحدود للتحقق من سلامة البيانات. في الوقت نفسه، تستخدم Celestia رمز محو RS المتقدم ثنائي الأبعاد، وتتم إعادة كتابة البيانات الأصلية في شكل مصفوفة k، ويمكن استرداد 25٪ فقط من البيانات الأصلية. ومع ذلك، فإن تخزين مشاركة البيانات بشكل أساسي يضاعف فقط ضغط التخزين لعقدة الشبكة بأكملها بمعامل على إجمالي حجم البيانات. لا يزال ضغط تخزين العقدة وحجم البيانات يحافظان على نمو خطي. ومع استمرار الطبقة الأولى في تحسين سرعة معاملاتها، قد يستمر ضغط تخزين العقد في الوصول إلى مستوى حرج غير مقبول يومًا ما. لحل هذه المشكلة، يتم تقديم مكون IPLD في Celestia للمعالجة. بالنسبة إلى Kلا يتم تخزين البيانات الموجودة في مصفوفة k مباشرة على Celestia، ولكن يتم تخزينها في شبكة LL-IPFS، ويتم الاحتفاظ فقط برمز CID للبيانات الموجودة على IPFS في العقدة. عندما يطلب المستخدم جزءًا من البيانات التاريخية، سترسل العقدة CID المقابل إلى مكون IPLD، وسيتم استدعاء البيانات الأصلية على IPFS من خلال CID هذا. إذا كانت البيانات موجودة على IPFS، فسيتم إرجاعها عبر مكون IPLD والعقدة؛ إذا لم تكن موجودة، فلا يمكن إرجاع البيانات.

طريقة قراءة بيانات سيليستيا، مصدر الصورة: Celestia Core

1. Celestia: بأخذ Celestia كمثال، يمكننا الحصول على لمحة عن تطبيق بلوكتشين المعياري في حل مشكلة تخزين إيثريوم. سترسل عقدة Rollup بيانات المعاملات المجمعة والتي تم التحقق منها إلى Celestia وتخزن البيانات على Celestia. خلال هذه العملية، تقوم Celestia بتخزين البيانات فقط دون وعي مفرط. أخيرًا، سيتم تدوير عقدة Rollup وفقًا لحجم مساحة التخزين. سيتم دفع رموز tia المقابلة إلى Celestia كرسوم تخزين. يستخدم التخزين في Celstia DAS ورموز المحو المشابهة لتلك الموجودة في EIP4844، ولكن تمت ترقية رموز المحو متعددة الحدود في EIP4844 ويتم استخدام رموز محو RS ثنائية الأبعاد لترقية أمان التخزين مرة أخرى. يمكن لـ 25٪ فقط من الكسور استعادة بيانات المعاملة بالكامل. إنها في الأساس مجرد سلسلة POS عامة بتكاليف تخزين منخفضة. إذا كان سيتم استخدامه لحل مشكلة تخزين البيانات التاريخية لـ Ethereum، فهناك حاجة إلى العديد من الوحدات المحددة الأخرى للتعاون مع Celestia. على سبيل المثال، من حيث التجميع، يوصى بشدة بوضع التجميع على موقع Celestia الرسمي هو Sovereign Rollup. بخلاف المجموعة الشائعة في الطبقة الثانية، يتم حساب المعاملات والتحقق منها فقط، أي إكمال عمليات طبقة التنفيذ. تتضمن Sovereign Rollup عملية التنفيذ والتسوية بأكملها، مما يقلل من معالجة المعاملات على Celestia. عندما يكون الأمان العام لشركة Celestia أضعف من أمان Ethereum، يمكن لهذا الإجراء زيادة أمان عملية المعاملة الشاملة. فيما يتعلق بضمان أمان البيانات التي دعت إليها Celestia، الشبكة الرئيسية لشركة Ethereum، فإن الحل الأكثر شيوعًا في الوقت الحالي هو العقد الذكي لجسر الجاذبية الكمومية. بالنسبة للبيانات المخزنة على Celestia، فإنها ستولد Verkle Root (دليل على توفر البيانات) وتبقيها على عقد جسر الجاذبية الكمومية لشبكة Ethereum الرئيسية. في كل مرة تستدعي فيها Ethereum البيانات التاريخية على Celestia، ستتم مقارنة نتيجة التجزئة الخاصة بها مع استخدام Verkle Root للمقارنة، وإذا تطابقت، فهذا يعني أنها بالفعل بيانات تاريخية حقيقية.

4.2.3 سلسلة التخزين DA

فيما يتعلق بالمبادئ التقنية للسلسلة الرئيسية DA، يتم استعارة العديد من التقنيات المشابهة لـ Sharding من سلسلة التخزين العامة. من بين الإعلانات الإعلانية التابعة لجهات خارجية، يستخدم البعض سلسلة التخزين العامة مباشرةً لإكمال بعض مهام التخزين. على سبيل المثال، يتم وضع بيانات المعاملات المحددة في Celestia على شبكة LL-IPFS. في حل DA التابع لجهة خارجية، بالإضافة إلى إنشاء سلسلة عامة منفصلة لحل مشكلة التخزين في Layer1، هناك طريقة أكثر مباشرة تتمثل في ربط سلسلة التخزين العامة مباشرة بـ Layer1 لتخزين البيانات التاريخية الضخمة على Layer1. بالنسبة إلى سلاسل البلوكشين عالية الأداء، يكون حجم البيانات التاريخية أكبر من ذلك. عند التشغيل بأقصى سرعة، يكون حجم بيانات سلسلة Solana العامة عالية الأداء قريبًا من 4 PG، وهو ما يتجاوز تمامًا نطاق تخزين العقد العادية. الحل الذي اختاره Solana هو تخزين البيانات التاريخية على شبكة التخزين اللامركزية Arweave، والاحتفاظ فقط بيومين من البيانات على عقد الشبكة الرئيسية للتحقق منها. لضمان أمان العملية المخزنة، صممت Solana و Arweave Chain خصيصًا بروتوكول جسر التخزين، Solar Bridge. ستتم مزامنة البيانات التي تم التحقق منها بواسطة عقدة Solana مع Arweave وسيتم إرجاع العلامة المقابلة. فقط من خلال هذه العلامة، يمكن لعقدة Solana عرض البيانات التاريخية لـ Solana blockchain في أي وقت. في Arweave، ليست هناك حاجة لجميع عقد الشبكة للحفاظ على تناسق البيانات واستخدامها كحد أدنى للمشاركة في عمليات الشبكة. بدلاً من ذلك، تم اعتماد تخزين المكافآت. بادئ ذي بدء، لا تستخدم Arweave بنية سلسلة تقليدية لبناء الكتل ولكنها تشبه إلى حد كبير بنية الرسم البياني. في Arweave، لن تشير الكتلة الجديدة إلى الكتلة السابقة فحسب، بل ستشير أيضًا بشكل عشوائي إلى الكتلة التي تم إنشاؤها Recall Block. يتم تحديد الموقع المحدد لكتلة الاستدعاء من خلال نتيجة التجزئة للكتلة السابقة وارتفاع الكتلة الخاصة بها. موقع Recall Block غير معروف حتى يتم استخراج الكتلة السابقة. ومع ذلك، في عملية إنشاء كتلة جديدة، تحتاج العقدة إلى بيانات Recall Block لاستخدام آلية POW لحساب تجزئة الصعوبة المحددة. فقط أول عامل منجم يقوم بحساب التجزئة التي تلبي الصعوبة يمكنه الحصول على المكافأة، مما يشجع عمال المناجم على تخزين أكبر قدر ممكن. البيانات التاريخية. وفي الوقت نفسه، كلما قل عدد الأشخاص الذين يخزنون كتلة تاريخية معينة، سيكون لدى العقد عدد أقل من المنافسين عند إنشاء وحدات غير قابلة لمواجهة الصعوبة، مما يشجع عمال المناجم على تخزين عدد أقل من الكتل في الشبكة. أخيرًا، للتأكد من أن العقد تخزن البيانات بشكل دائم في Arweave، فإنها تقدم آلية تسجيل عقدة WildFire. تميل العقد إلى التواصل مع العقد التي يمكنها توفير المزيد من البيانات التاريخية بشكل أسرع، في حين أن العقد ذات التصنيفات المنخفضة غالبًا ما تكون غير قادرة على الحصول على أحدث بيانات الكتلة والمعاملات في أقرب وقت ممكن وبالتالي لا يمكنها الاستفادة من مسابقة POW...

طريقة بناء كتل الأسهم، مصدر الصورة: Arweave Yellow-Paper

5. مقارنة مركبة

بعد ذلك، سنقارن مزايا وعيوب حلول التخزين الخمسة استنادًا إلى الأبعاد الأربعة لمؤشرات أداء DA.

1. الأمان: أكبر مصدر لمشاكل أمان البيانات هو الخسارة التي تحدث أثناء عملية نقل البيانات والتلاعب الضار من العقد غير النزيهة. في العملية عبر السلاسل، نظرًا لاستقلالية وحالة السلسلتين العامتين، يعد أمن نقل البيانات أحد أكثر المجالات تضررًا. بالإضافة إلى ذلك، غالبًا ما تحتوي الطبقة الأولى، التي تتطلب حاليًا طبقة DA مخصصة، على مجموعة إجماع قوية، وسيكون أمنها أعلى بكثير من أمن سلاسل التخزين العامة العادية. لذلك، يتمتع حل DA للسلسلة الرئيسية بأمان أعلى. بعد ضمان أمان نقل البيانات، فإن الخطوة التالية هي ضمان أمان بيانات الاتصال. إذا تم النظر فقط في البيانات التاريخية قصيرة المدى المستخدمة للتحقق من المعاملات، يتم نسخ البيانات نفسها احتياطيًا من قبل الشبكة بأكملها في شبكة التخزين المؤقتة. في حل يشبه DankSharding، يبلغ متوسط عدد النسخ الاحتياطية للبيانات 1/N فقط من عدد العقد في الشبكة بأكملها. ، يمكن أن يؤدي المزيد من تكرار البيانات إلى تقليل احتمالية فقدان البيانات، ويمكن أيضًا توفير المزيد من العينات المرجعية أثناء التحقق. لذلك، سيكون للتخزين المؤقت مستوى أعلى من أمان البيانات نسبيًا. في حل DA التابع لجهة خارجية، يستخدم DA الخاص بالسلسلة الرئيسية العقد العامة مع السلسلة الرئيسية، ويمكن نقل البيانات مباشرة من خلال عقد الترحيل هذه أثناء العملية عبر السلسلة، لذلك سيكون لديها أمان أعلى نسبيًا من حلول DA الأخرى.
2. تكاليف التخزين: أكبر عامل يؤثر على تكاليف التخزين هو مقدار تكرار البيانات. في حل التخزين قصير المدى للسلسلة الرئيسية DA، يتم تخزينه في شكل مزامنة بيانات لعقد الشبكة بأكملها. يجب نسخ أي بيانات مخزنة حديثًا احتياطيًا في عقدة الشبكة بأكملها، والتي تتمتع بأعلى تكلفة تخزين. تحدد تكلفة التخزين المرتفعة بدورها أن هذه الطريقة مناسبة فقط للتخزين المؤقت في شبكات TPS العالية. الطريقة الثانية هي طريقة تخزين Sharding، بما في ذلك Sharding في السلسلة الرئيسية و Sharding في DA لطرف ثالث. نظرًا لأن السلسلة الرئيسية غالبًا ما تحتوي على المزيد من العقد، فإن الكتلة المقابلة ستحتوي أيضًا على المزيد من النسخ الاحتياطية، وبالتالي فإن حل تقسيم السلسلة الرئيسية سيكون له تكاليف أعلى. أقل تكلفة تخزين هي سلسلة التخزين العامة DA التي تتبنى طريقة تخزين المكافآت. في ظل هذا المخطط، غالبًا ما يتقلب مقدار تكرار البيانات حول ثابت ثابت. في الوقت نفسه، تم إدخال آلية تعديل ديناميكية أيضًا في سلسلة التخزين العامة DA لجذب العقد لتخزين بيانات أقل احتياطيًا عن طريق زيادة المكافآت لضمان أمان البيانات.
3. سرعة قراءة البيانات: تتأثر سرعة تخزين البيانات بشكل أساسي بموقع تخزين البيانات في مساحة التخزين ومسار فهرس البيانات وتوزيع البيانات في العقد. من بينها، موقع تخزين البيانات على العقدة له تأثير أكبر على السرعة، لأن تخزين البيانات في الذاكرة أو SSD قد يتسبب في اختلاف سرعة القراءة بعشرات المرات. يستخدم تخزين السلسلة العامة DA في الغالب تخزين SSD، لأن الحمل على هذه السلسلة لا يشمل فقط بيانات طبقة DA ولكنه يتضمن أيضًا البيانات الشخصية ذات الاستخدام العالي للذاكرة مثل مقاطع الفيديو والصور التي تم تحميلها من قبل المستخدمين. إذا لم تستخدم الشبكة SSD كمساحة تخزين، فسيكون من الصعب تحمل ضغط تخزين ضخم وتلبية احتياجات التخزين طويلة الأجل. ثانيًا، بالنسبة إلى DA التابع لجهة خارجية والسلسلة الرئيسية DA التي تستخدم حالة الذاكرة لتخزين البيانات، يحتاج DA التابع لجهة خارجية أولاً إلى البحث في بيانات الفهرس المقابلة في السلسلة الرئيسية، ثم نقل بيانات الفهرس عبر السلسلة إلى DA التابع لجهة خارجية وإعادتها من خلال بيانات جسر التخزين. في المقابل، يمكن للسلسلة الرئيسية DA الاستعلام مباشرة عن البيانات من العقد وبالتالي تتمتع بسرعة استرداد البيانات بشكل أسرع. أخيرًا، ضمن السلسلة الرئيسية DA، تتطلب طريقة Sharding استدعاء Block من عقد متعددة واستعادة البيانات الأصلية. لذلك، بالمقارنة مع التخزين قصير الأجل بدون تخزين مجزأ، ستكون السرعة أبطأ.
4. عالمية طبقة DA: تقترب عالمية DA للسلسلة الرئيسية من الصفر لأنه من المستحيل نقل البيانات على سلسلة عامة ذات مساحة تخزين غير كافية إلى سلسلة عامة أخرى ذات مساحة تخزين غير كافية. في DA التابع لجهة خارجية، تعد براعة الحل وتوافقه مع سلسلة رئيسية محددة مؤشرات متناقضة. على سبيل المثال، في حل DA الخاص بالسلسلة الرئيسية المصمم لسلسلة رئيسية معينة، تم إجراء الكثير من التحسينات على نوع العقدة ومستوى إجماع الشبكة للتكيف مع السلسلة العامة. لذلك، ستلعب هذه التحسينات دورًا عند التواصل مع السلاسل العامة الأخرى. عائق كبير. ضمن DA التابع لجهة خارجية، تعمل سلسلة التخزين العامة DA بشكل أفضل من حيث التنوع مقارنة بـ DA المعياري. تحتوي سلسلة التخزين العامة DA على مجتمع مطور أكبر والمزيد من مرافق التوسع، والتي يمكن أن تتكيف مع ظروف السلاسل العامة المختلفة. في الوقت نفسه، تستحوذ سلسلة التخزين العامة DA على البيانات بشكل أكثر نشاطًا من خلال التقاط الحزم، بدلاً من تلقي المعلومات المنقولة من سلاسل عامة أخرى بشكل سلبي. لذلك، يمكنها ترميز البيانات بطريقتها، وتحقيق تخزين موحد لتدفقات البيانات، وتسهيل إدارة معلومات البيانات من سلاسل رئيسية مختلفة، وتحسين كفاءة التخزين.

مقارنة أداء حلول التخزين، مصدر الصورة: Kernel Ventures

6. ملخص

تخضع البلوكشين الحالية لعملية تحول من Crypto إلى Web3 الأكثر شمولاً. لا تجلب هذه العملية ثراء المشاريع على blockchain فقط. لاستيعاب التشغيل المتزامن للعديد من المشاريع على Layer1 مع ضمان تجربة مشاريع Gamefi و Socialfi، اعتمدت Layer1 ممثلة في Ethereum طرقًا مثل Rollup و Blobs لتحسين TPS. ومن بين سلاسل البلوكشين الجديدة، يتزايد أيضًا عدد سلاسل البلوكشين عالية الأداء. ولكن ارتفاع TPS لا يعني فقط الأداء العالي، ولكن أيضًا زيادة ضغط التخزين على الشبكة. بالنسبة للبيانات التاريخية الضخمة، يتم حاليًا اقتراح العديد من طرق DA القائمة على السلسلة الرئيسية والأطراف الثالثة للتكيف مع الزيادة في ضغط التخزين على السلسلة. كل طريقة تحسين لها مزايا وعيوب ولها قابلية تطبيق مختلفة في مواقف مختلفة.

تتمتع سلاسل الكتل التي تركز على الدفع بمتطلبات عالية جدًا لأمان البيانات التاريخية ولا تسعى إلى تحقيق TPS مرتفع بشكل خاص. إذا كان هذا النوع من السلاسل العامة لا يزال في مرحلة الإعداد، فيمكن اعتماد طريقة تخزين تشبه DankSharding، والتي يمكن أن تحقق زيادة كبيرة في سعة التخزين مع ضمان الأمن. ومع ذلك، إذا كانت سلسلة عامة مثل بيتكوين قد تشكلت بالفعل ولديها عدد كبير من العقد، فهناك مخاطر كبيرة في التحسينات المتهورة في طبقة الإجماع. لذلك، يمكن استخدام DA للسلسلة الرئيسية المخصصة ذات الأمان العالي في التخزين خارج السلسلة لتحقيق التوازن بين مشكلات الأمان والتخزين... ومع ذلك، تجدر الإشارة إلى أن وظائف blockchain ليست ثابتة ولكنها تتغير باستمرار. على سبيل المثال، اقتصرت الوظائف المبكرة لـ Ethereum بشكل أساسي على المدفوعات والمعالجة الآلية البسيطة للأصول والمعاملات باستخدام العقود الذكية. ومع ذلك، مع استمرار توسع مشهد بلوكتشين، تمت إضافة العديد من مشاريع Socialfi و Defi تدريجيًا إلى إيثريوم. اجعل Ethereum تتطور في اتجاه أكثر شمولاً. في الآونة الأخيرة، مع انفجار بيئة النقش على بيتكوين، ارتفعت رسوم المعاملات لشبكة بيتكوين ما يقرب من ٢٠ مرة منذ أغسطس. وهذا يعكس أن سرعة المعاملات لشبكة بيتكوين في هذه المرحلة لا يمكن أن تلبي طلب المعاملات، ويمكن للمتداولين فقط رفع الرسوم لإجراء المعاملات التي تتم معالجتها في أسرع وقت ممكن. والآن، يحتاج مجتمع بيتكوين إلى إجراء مقايضة، سواء لقبول الرسوم المرتفعة وسرعات المعاملات البطيئة أو تقليل أمان الشبكة لزيادة سرعات المعاملات ولكن مع التغلب على النية الأصلية لنظام الدفع. إذا اختار مجتمع Bitcoin الخيار الأخير، فعند مواجهة ضغط البيانات المتزايد، سيحتاج حل التخزين المقابل أيضًا إلى التعديل.

تتقلب رسوم معاملات شبكة بيتكوين الرئيسية، مصدر الصورة: OKLINK

تتمتع السلاسل العامة ذات الوظائف الشاملة بمتابعة أعلى لـ TPS، كما أن نمو البيانات التاريخية أكبر. من الصعب التكيف مع النمو السريع لـ TPS على المدى الطويل من خلال اعتماد حل يشبه DankSharding. لذلك، تتمثل الطريقة الأكثر ملاءمة في ترحيل البيانات إلى DA تابع لجهة خارجية للتخزين. من بينها، تتمتع DA الخاصة بالسلسلة الرئيسية بأعلى درجات التوافق وقد تتمتع بمزيد من المزايا إذا تم النظر فقط في مشكلات التخزين لسلسلة عامة واحدة. ولكن اليوم، عندما تزدهر السلاسل العامة للطبقة الأولى، أصبح نقل الأصول عبر السلاسل والتفاعل بين البيانات سعيًا مشتركًا لمجتمع بلوكتشين. إذا تم أخذ التطوير طويل الأجل لنظام blockchain بأكمله في الاعتبار، فإن تخزين البيانات التاريخية للسلاسل العامة المختلفة على نفس السلسلة العامة يمكن أن يزيل العديد من المشكلات الأمنية في عملية تبادل البيانات والتحقق منها. لذلك، قد يكون الفرق بين DA المعياري وطريقة DA للسلسلة العامة للتخزين خيارًا أفضل. وفي إطار فرضية التنوع الوثيق، يركز DA المعياري على توفير خدمات طبقة بلوكتشين DA، وتقديم بيانات تاريخية أكثر دقة لإدارة بيانات الفهرس، والتي يمكنها تصنيف بيانات السلسلة العامة المختلفة بشكل معقول، وتخزين بيانات السلسلة العامة. لديها مزايا أكثر من. ومع ذلك، لا يأخذ الحل أعلاه في الاعتبار تكلفة تعديل طبقة الإجماع على السلسلة العامة الحالية. هذه العملية محفوفة بالمخاطر للغاية. بمجرد حدوث المشاكل، قد تؤدي إلى نقاط ضعف نظامية وتتسبب في فقدان السلسلة العامة لإجماع المجتمع. لذلك، إذا كان الحل انتقاليًا أثناء عملية توسيع بلوكتشين، فقد يكون أبسط تخزين مؤقت للسلسلة الرئيسية أكثر ملاءمة. أخيرًا، تستند المناقشة أعلاه إلى الأداء أثناء التشغيل الفعلي. ومع ذلك، إذا كان الهدف من سلسلة عامة معينة هو تطوير بيئتها وجذب المزيد من أطراف المشروع والمشاركين، فقد تفضل أيضًا المشاريع التي تدعمها وتمولها مؤسستها... على سبيل المثال، عندما يكون الأداء العام معادلاً أو حتى أقل قليلاً من حلول تخزين السلسلة العامة، سيميل مجتمع Ethereum أيضًا إلى مشاريع الطبقة الثانية التي تدعمها مؤسسة Ethereum مثل ETHStorage لمواصلة تطوير نظام Ethereum البيئي.

بشكل عام، أصبحت وظائف blockchain اليوم أكثر تعقيدًا، مما يؤدي أيضًا إلى زيادة متطلبات مساحة التخزين. عند وجود عدد كافٍ من عُقد التحقق من Layer1، لا يلزم نسخ البيانات التاريخية احتياطيًا بواسطة جميع العقد في الشبكة بأكملها. فقط عندما يصل عدد النسخ الاحتياطية إلى قيمة معينة يمكن ضمان الأمان النسبي.. في الوقت نفسه، أصبح تقسيم العمل في السلاسل العامة أيضًا أكثر تفصيلاً. ، الطبقة الأولى مسؤولة عن الإجماع والتنفيذ، ومجموعة القوائم مسؤولة عن الحساب والتحقق، ويتم استخدام بلوكشين منفصل لتخزين البيانات. يمكن لكل جزء التركيز على وظيفة معينة دون التقيد بأداء الأجزاء الأخرى. ومع ذلك، فإن مقدار التخزين المحدد أو نسبة العقد التي يجب السماح بها لتخزين البيانات التاريخية يمكن أن يحقق توازنًا بين الأمان والكفاءة، وكيفية ضمان التشغيل البيني الآمن بين سلاسل الكتل المختلفة، فهذه مشكلة تتطلب من مطوري بلوكتشين التفكير فيها وتحسينها باستمرار. ومع ذلك، فإن المستثمرين ينتبهون إلى مشروع DA الرئيسي الخاص بالسلسلة على إيثريوم، لأن إيثريوم لديها بالفعل عدد كافٍ من المؤيدين في هذه المرحلة ولا تحتاج إلى الاعتماد على المجتمعات الأخرى لتوسيع نفوذها. ما نحتاجه أكثر هو تحسين وتطوير مجتمعك وجذب المزيد من المشاريع إلى نظام Ethereum البيئي. ومع ذلك، بالنسبة للسلاسل العامة في وضع اللحاق بالركب، مثل سولانا وأبتوس، فإن السلسلة الواحدة نفسها لا تتمتع بمثل هذه البيئة الكاملة، لذلك قد تكون أكثر ميلاً إلى توحيد الجهود مع المجتمعات الأخرى لبناء بيئة ضخمة عبر السلاسل لتوسيع النفوذ. وبالتالي فإن DA الناشئ من Layer1، وهو طرف ثالث عام يستحق المزيد من الاهتمام.

Kernel Ventures هو صندوق لرأس المال الاستثماري المشفر يديره مجتمع البحث والتطوير مع أكثر من 70 استثمارًا في المراحل المبكرة تركز على البنية التحتية والبرامج الوسيطة والتطبيقات اللامركزية، وخاصة ZK و Rollup و DEX وسلاسل الكتل المعيارية والمناطق الرأسية للمليارات من مستخدمي التشفير في المستقبل، مثل تجريد الحساب وتوافر البيانات وقابلية التوسع وما إلى ذلك. على مدى السنوات السبع الماضية، التزمنا بدعم نمو مجتمعات التنمية الأساسية وجمعيات بلوكتشين الجامعية في جميع أنحاء العالم.

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [mirror]. جميع حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [Kernel Ventures Jerry Luo]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.