بقلم جيري لو، كيرنيل فينتشرز

TL;DR

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

2. في مواجهة هذه المشكلة ، يحتاج المطورون إلى اقتراح مخطط تخزين بيانات تاريخي جديد على أساس مراعاة الأمان وتكلفة التخزين وسرعة قراءة البيانات وتعدد استخدامات طبقة DA.

3. في عملية حل هذه المشكلة ، ظهرت العديد من التقنيات والأفكار الجديدة ، بما في ذلك المشاركة ، DAS ، Verkle Tree ، المكونات الوسيطة DA ، إلخ. وحاولوا تحسين مخطط تخزين طبقة أجندة التنمية عن طريق تقليل تكرار البيانات وتحسين كفاءة التحقق من البيانات.

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

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

6. بشكل عام ، تتطور blockchain في اتجاه تقليل تكرار البيانات وتقسيم العمل متعدد السلاسل.

1. خلفية

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

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

2. مقاييس أداء DA

2.1 الأمن

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

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

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

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

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

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

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

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

2.4 القواسم المشتركة لطبقة DA

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

3. استكشاف التكنولوجيا المتعلقة ب DA

3.1 المشاركة

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

كيفية تخزين البيانات بعد المشاركة، مصدر الصورة: Kernel Ventures

3.2 DAS (أخذ عينات توافر البيانات)

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

كود الممحاة: بالنظر إلى العدد الهائل من المدققين على Ethereum ، فإن احتمال عدم تخزين الكتلة بواسطة أي عقدة يكاد يكون صفرا ، ولكن من الناحية النظرية لا يزال هناك احتمال حدوث مثل هذا الموقف المتطرف. من أجل التخفيف من هذا التهديد المحتمل لفقدان التخزين ، بدلا من تقسيم البيانات الأصلية مباشرة إلى كتل للتخزين ، يتم تعيين البيانات الأصلية إلى معاملات كثير الحدود من الدرجة n ، ثم يتم أخذ نقاط 2n على كثير الحدود ، وتختار العقدة عشوائيا واحدة منها للتخزين. بالنسبة لكثير الحدود من الدرجة n ، هناك حاجة فقط إلى نقاط n + 1 للاستعادة ، لذلك يجب تحديد نصف الكتل فقط بواسطة العقد لاستعادة البيانات الأصلية. من خلال كود الممحاة ، يتم تحسين أمان تخزين البيانات وقدرة الشبكة على استعادة البيانات.

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

3.3 وضع التحقق من بيانات طبقة DA

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

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

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

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

4. مخطط تخزين من فئة DA

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

فئة 4.1.1 DankSharding

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

4.1.2 التخزين قصير الأجل

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

4.2 DAs الطرف الثالث

4.2.1 سلسلة رئيسية مخصصة DA: EthStorage

** DA للسلسلة الرئيسية **:D أهم شيء في الطبقة A هو أمان نقل البيانات ، والأكثر أمانا في هذا الصدد هو DA للسلسلة الرئيسية. ومع ذلك ، فإن تخزين السلسلة الرئيسية محدود بمساحة التخزين والمنافسة على الموارد ، لذلك عندما تنمو كمية بيانات الشبكة بسرعة ، إذا كنت ترغب في تحقيق تخزين طويل الأجل للبيانات ، فسيكون DA التابع لجهة خارجية خيارا أفضل. إذا كان DA التابع لجهة خارجية يتمتع بتوافق أعلى مع الشبكة الرئيسية ، فيمكنه تحقيق مشاركة العقد والحصول على أمان أعلى في عملية تبادل البيانات. لذلك ، في إطار فرضية النظر في الأمن ، ستكون هناك مزايا ضخمة ل DA مخصصة للسلسلة الرئيسية. إذا أخذنا Ethereum كمثال ، فإن أحد المتطلبات الأساسية للسلسلة الرئيسية المخصصة DA هو أنه يمكن أن يكون متوافقا مع EVM لضمان قابلية التشغيل البيني مع بيانات وعقود Ethereum ، وتشمل المشاريع التمثيلية Topia و EthStorage وما إلى ذلك. من بينها ، يعد EthStorage حاليا الأكثر تطورا من حيث التوافق ، لأنه بالإضافة إلى التوافق على مستوى EVM ، فإنه يقوم أيضا بإعداد واجهات ذات صلة للتواصل مع أدوات تطوير Ethereum مثل Remix و Hardhat لتحقيق التوافق على مستوى أداة تطوير Ethereum.

** EthStorage **: EthStorage هي سلسلة عامة مستقلة عن Ethereum ، ولكن العقد التي تعمل عليها هي أفضل عقد Ethereum ، أي أن العقد التي تشغل EthStorage يمكنها أيضا تشغيل Ethereum في نفس الوقت ، ويمكن تشغيل EthStorage مباشرة من خلال رمز التشغيل على Ethereum. في نموذج التخزين الخاص ب EthStorage ، والذي يحتفظ فقط بكمية صغيرة من البيانات الوصفية على شبكة Ethereum الرئيسية للفهرسة ، ينشئ بشكل أساسي قاعدة بيانات لامركزية ل Ethereum. في الحل الحالي ، نفذت EthStorage التفاعل بين شبكة Ethereum الرئيسية و EthStorage من خلال نشر عقد EthStorage على شبكة Ethereum الرئيسية. إذا أرادت Ethereum إيداع البيانات ، فإنها تحتاج إلى استدعاء وظيفة put() في العقد ، ومعلمات الإدخال عبارة عن متغيرين بايت رئيسيين ، البيانات ، حيث تمثل البيانات البيانات المراد إيداعها ، والمفتاح هو تحديدها في شبكة Ethereum ، والتي يمكن اعتبارها مشابهة لوجود CID في IPFS. بعد تخزين زوج (المفتاح ، البيانات) بنجاح في شبكة EthStorage ، سيقوم EthStorage بإنشاء kvldx وإعادته إلى شبكة Ethereum الرئيسية ، والتي تتوافق مع المفتاح الموجود على Ethereum ، وتتوافق هذه القيمة مع عنوان تخزين البيانات الموجودة على EthStorage ، بحيث يتم الآن تغيير مشكلة تخزين كمية كبيرة من البيانات لتخزين زوج واحد (مفتاح ، kvldx) ، مما يقلل بشكل كبير من تكلفة تخزين شبكة Ethereum الرئيسية. إذا كنت بحاجة إلى إجراء مكالمة إلى البيانات المخزنة مسبقا ، فأنت بحاجة إلى استخدام وظيفة get() في EthStorage وإدخال معلمة المفتاح ، ويمكنك إجراء بحث سريع عن البيانات الموجودة على EthStorage من خلال kvldx المخزنة على Ethereum.

عقد EthStorage ، مصدر الصورة: Kernel Ventures

من حيث الطريقة التي تخزن بها العقد البيانات ، يستعير EthStorage من نمط Arweave. بادئ ذي بدء ، يتم تقسيم عدد كبير من أزواج (k ، v) من ETH ، ويحتوي كل تجزئة على عدد ثابت من أزواج البيانات (k ، v) ، والتي يوجد منها أيضا حد للحجم المحدد لكل زوج (k ، v) ، وذلك لضمان عدالة حجم عبء العمل في عملية تخزين المكافآت لعمال المناجم. لإصدار المكافآت ، تحتاج إلى التحقق مما إذا كانت العقدة تخزن البيانات. في هذه العملية ، يقسم EthStorage تجزئة (حجم تيرابايت) إلى عدد كبير من القطع ويحتفظ بجذر Merkle على شبكة Ethereum الرئيسية للتحقق من صحتها. بعد ذلك ، يحتاج المعدن إلى توفير nonce لإنشاء عناوين عدة أجزاء من خلال خوارزمية عشوائية مع تجزئة الكتلة السابقة على EthStorage ، ويحتاج المعدن إلى توفير بيانات هذه القطع لإثبات أنه قام بالفعل بتخزين التجزئة بأكملها. ومع ذلك ، لا يمكن تحديد nonce هذا بشكل تعسفي ، وإلا ستختار العقدة nonce مناسبا يتوافق فقط مع الجزء المخزن الخاص بها لاجتياز التحقق ، لذلك يجب أن تجعل هذه nonce القطعة التي تم إنشاؤها تلبي متطلبات الشبكة بعد الخلط والتجزئة ، ويمكن فقط للعقدة الأولى التي تقدم nonce وإثبات الوصول العشوائي الحصول على المكافأة.

4.2.2 وحدات DA: سيليستيا

** وحدة Blockchain **: في هذه المرحلة ، تنقسم المعاملات التي يجب تنفيذها بواسطة السلسلة العامة Layer1 بشكل أساسي إلى الأجزاء الأربعة التالية: (1) تصميم المنطق الأساسي للشبكة ، وتحديد المدققين بطريقة معينة ، وكتابة الكتل وتوزيع المكافآت على مشرفي الشبكة ، (2) حزم المعاملات ومعالجتها ونشر المعاملات ذات الصلة ، (3) التحقق من المعاملات التي سيتم وضعها على السلسلة وتحديد الحالة النهائية ، و (4) تخزين البيانات التاريخية والحفاظ عليها على blockchain. اعتمادا على الوظائف المنجزة ، يمكننا تقسيم blockchain إلى أربع وحدات ، وهي طبقة الإجماع ، وطبقة التنفيذ ، وطبقة التسوية ، وطبقة توفر البيانات (طبقة DA).

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

وحدات DA: يعتبر النهج المعقد لفصل طبقة DA عن أعمال blockchain وتسليمها إلى سلسلة عامة واحدة حلا قابلا للتطبيق للبيانات التاريخية المتزايدة للطبقة 1. لا يزال الاستكشاف في هذه المنطقة في مراحله المبكرة ، حيث يعد سيليستيا المشروع الأكثر تمثيلا في الوقت الحالي. فيما يتعلق بطريقة التخزين المحددة ، تستعير Celestia من طريقة تخزين Danksharding ، وهي تقسيم البيانات إلى كتل متعددة ، واستخراج جزء منها من كل عقدة للتخزين ، والتحقق من سلامة البيانات مع التزام KZG متعدد الحدود. في الوقت نفسه ، تستخدم Celestia ترميز محو 2D RS المتقدم لإعادة كتابة البيانات الأصلية في شكل مصفوفة kk ، وأخيرا يمكن استرداد 25٪ فقط من البيانات الأصلية. ومع ذلك ، فإن تخزين تجزئة البيانات يضاعف بشكل أساسي ضغط تخزين العقد على الشبكة بأكملها بعامل على إجمالي حجم البيانات ، ولا يزال ضغط التخزين وحجم البيانات للعقد يحافظان على النمو الخطي. مع استمرار الطبقة 1 في تحسين سرعة المعاملة ، قد يستمر ضغط تخزين العقد في الوصول إلى عتبة غير مقبولة في يوم من الأيام. لحل هذه المشكلة ، تم تقديم مكون IPLD في Celestia للمعالجة. بالنسبة للبيانات الموجودة في مصفوفة kk ، لا يتم تخزينها مباشرة على Celestia ، ولكن في شبكة LL-IPFS ، ويتم الاحتفاظ فقط برمز CID لتلك البيانات على IPFS في العقدة. عندما يطلب المستخدم جزءا من البيانات التاريخية ، ترسل العقدة CID المقابل إلى مكون IPLD ، وتستخدم CID لاستدعاء البيانات الأولية على IPFS. إذا كانت البيانات موجودة على IPFS ، يتم إرجاعها من خلال مكونات وعقد IPLD ، وإذا لم تكن كذلك ، فلا يمكن إرجاعها.

كيف تتم قراءة بيانات سيليستيا ، مصدر الصورة: سيليستيا كور

** Celestia **: بأخذ Celestia كمثال ، يمكننا الحصول على لمحة عن تطبيق blockchain المعياري في حل مشكلة تخزين Ethereum. سترسل عقدة Rollup بيانات المعاملات التي تم تعبئتها والتحقق منها إلى Celestia وتخزن البيانات على Celestia ، وفي هذه العملية ، تقوم Celestia بتخزين البيانات فقط دون الكثير من الوعي ، وأخيرا وفقا لحجم مساحة التخزين ، ستدفع عقدة Rollup رموز tia المقابلة إلى Celestia كرسوم تخزين. يستفيد التخزين في Celstia من DAS وترميز المحو المشابه لذلك الموجود في EIP4844 ، ولكن يتم ترقية ترميز المحو متعدد الحدود في EIP4844 إلى ترميز محو 2D RS ويتم ترقية أمان التخزين مرة أخرى ، مما يتطلب كسور 25٪ فقط لاستعادة بيانات المعاملة بالكامل. بشكل أساسي ، إنها مجرد سلسلة عامة منخفضة التكلفة لنقاط البيع ، وإذا كنت ترغب في حل مشكلة تخزين البيانات التاريخية في Ethereum ، فأنت بحاجة إلى العديد من الوحدات المحددة الأخرى للعمل مع Celestia. على سبيل المثال ، من حيث عمليات التجميع ، فإن أحد أكثر أوضاع التجميع الموصى بها على موقع Celestia الرسمي هو Sovereign Rollup. تختلف عن عمليات التجميع الشائعة في الطبقة 2 ، يتم حساب المعاملة والتحقق منها فقط ، أي اكتمال تشغيل طبقة التنفيذ. يشمل Sovereign Rollup عملية التنفيذ والتسوية بأكملها ، مما يقلل من معالجة المعاملات على Celestia ، والتي يمكن أن تزيد من أمان عملية المعاملة الإجمالية عندما يكون أمان Celestia العام أضعف من Ethereum. فيما يتعلق بضمان أمان البيانات التي تسميها Celestia على شبكة Ethereum الرئيسية ، فإن الحل الأكثر شيوعا هو العقد الذكي لجسر الجاذبية الكمومية. بالنسبة للبيانات المخزنة على Celestia ، فإنه يولد جذر Merkle (إثبات توفر البيانات) ويظل على عقد جسر الجاذبية الكمومية على شبكة Ethereum الرئيسية ، وفي كل مرة تستدعي Ethereum بيانات تاريخية على Celestia ، فإنها تقارن نتيجة التجزئة الخاصة بها مع Merkle Root ، وإذا حدث ذلك ، فهذا يعني أنها بالفعل بيانات تاريخية حقيقية.

4.2.3 متجر سلسلة عامة DA

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

كيف يتم بناء كتل Arweave ، مصدر الصورة: Arweave Yellow-Paper

5. مقارنة شاملة

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

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

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

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

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

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

6. ملخص

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

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

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

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

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

المصدر: التمويل الذهبي