ما هي تقنية توافر البيانات Data Availability وأهمية مشاريعها؟

سنتعرف في هذا المقال على تقنية توافر البيانات Data Availability، وهي واحدة من التقنيات التي ظهرت مؤخرًا لحل مشاكل وتحسين أداء شبكات البلوكتشين، وسنتعرف على أهمية هذه التقنيات ومستقبل مشاريعها.

مشكلة توسع البلوكتشين

• في مقال سابق على المدوّنة تحدثنا عن المعضلة الثلاثية للبلوكتشين، وهي عدم إمكانية تحقيق التوسع، اللا مركزية والأمان لشبكات البلوكتشين معًا، وتعتمد أغلب المشاريع على التضحية بأحد هذه الأركان الثلاثة.

• مثلًا مشروع Ethereum قام بالتضحية بالتوسع لصالح اللا مركزية والأمان، ومشروع Solana قام بالتضحية باللا مركزية لصالح التوسع والأمان.. وهكذا.

• ركن القابلية للتوسع “Scalability“ تحديدًا حصل على الاهتمام الأكبر من قبل المطورين، من أجل حل معضلة البلوكتشين الثلاثية، وظهرت الكثير من الأفكار التي تحاول حل قابلية البلوكتشين للتوسع؛ دون الإخلال بلا مركزية الشبكة أو أمانها.

• أبرز الأفكار التي ظهرت في الآونة الأخيرة كانت التنفيذ الموازي للمعاملات، والذي طبقته مشاريع مثل Solana | Sui | Aptos وغيرهم، وكذلك فكرة تجزئة البلوكتشين Sharding، والتي طبقتها مشاريع مثل Near | MultiversX وغيرها.

• فكرة أخرى تم تطويرها لحل هذه المشكلة وهي تبني معمارية مختلفة للبلوكتشين قائمة على التصميم النمطي وتجزئة مهام عمل الشبكة نفسها، وهذه الفكرة هي ما سنناقشها في مقال اليوم، وسنتعرف على ما هو هذا التصميم وفائدته؟ وكيف يتم استغلال تقنيات Data Availability داخل هذه التصميم؟

تصميم البلوكتشين غير القابل للتجزئة “Monolithic Blockchain“

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

  1. تنفيذ المعاملات Execution:

     • هي عملية قيام العُقد بمعالجة المعاملات التي قام بها المستخدمون بإنشائها، والتحقق من صحّة هذه المعاملات، وضمان توافقها مع قواعد الشبكة.

  2. تحقيق الإجماع Consensus:

     • تتفق العُقد على صّحة الكتلة المقترحة والمعاملات الموجودة بها، ويتم الموافقة على تضمين الكتلة.

  3. تسوية المعاملات Settlement:

     • يتم تسوية المعاملات بشكل نهائي على الشبكة عبر إضافة الكتلة إلى سجل الكتل. (أحيانًا قد تحتاج التسوية النهائية إلى إضافة عدد من الكتل بعد الكتلة الموجود بها المعاملة، تفاديًا لمخاطر حدوث Fork للشبكة).

  4. ضمان نشر / توافر البيانات Data Availability:

     • عُقد الشبكة مسئولة عن الاحتفاظ بالسجل الكامل للشبكة، والذي يضم كافّة الكتل والمعاملات التي حدثت على الشبكة. حتى الشبكات التي توفر إمكانية وجود عُقد خفيفة “Light Nodes“ لا تحتاج للاحتفاظ بالسجل بالكامل؛ يجب أن يكون لديها عُقد “Full Nodes“ تحتفظ بالسجل الكامل، لضمان التحقق من أن بيانات معينة تم نشرها على الشبكة، وضمان الوصول لهذه البيانات.

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

التصميم النمطي للبلوكتشين “Modular Blockchain“

• أحد هذه الحلول هو التوجه إلى معمارية مختلفة لتصميم شبكات البلوكتشين، وهو التصميم النمطي. هذا يعني فصل مهام البلوكتشين الرئيسية (التنفيذ | التسوية | الإجماع)؛ على عكس شبكات البلوكتشين المتكاملة “Monolithic Blockchain“.

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

• على سبيل المثال؛ مشاريع الطبقات الثانية على الإيثريوم وتحديدًا الـ Rollups، تتولى مهمة تنفيذ المعاملات، وتعتمد على الطبقة الأولى “الإيثريوم“ للقيام بباقي المهام مثل التسوية توافر البيانات.

• هذا التصميم يوفر للطبقات الثانية وسيلة للتوسع بالسماح لها بنقل جزء من مهام عملها إلى الطبقة الأولى، ويسمح أيضًا للطبقة الأولى بتحقيق نوع ما من التوسع من خلال نقل مهمة تنفيذ المعاملات “Execution“ إلى الطبقات الثانية.

• واحدة من مهام البلوكتشين التي تم التركيز عليها كأحد العناصر التي تُقيد توسع البلوكتشين هي توافر أو نشر البيانات “Data Availability“، وهذه المهمة ظهرت من أجل كثير من المشروعات المتخصصة في القيام بها، من أجل السماح لشبكات البلوكتشين الأخرى بالتوسع. فكيف يتم ذلك؟

توافر / نشر البيانات “Data Availability/Publishing“

• في البداية مصطلح توافر البيانات “Data Availability“ هو مصطلح غير دقيق لا يعبر عن التقنية وما تقدمه، والمصطلح الأدق هو نشر البيانات “Data Publishing“، وسنتعرف على الفرق إن شاء الله لاحقًا.

• فكرة مشاريع نشر البيانات تقوم على التخصص في مهمة محددة من مهام شبكات البلوكتشين، وهي السماح للمستخدم بالتحقق من بيانات معينة من المفترض أنه تم نشرها من قبل على بلوكتشين ما، وهل هذه البيانات كانت في يومٍ من الأيام جزءًا من سجل الكتل لشبكة معينة؟

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

• الأمر الآخر أن هذه المشاريع توفر حلًا لمشكلة توسع شبكات البلوكتشين من خلال تولي مهمة التحقق من نشر البيانات، وتخفيف هذا العبء من على كاهل عُقد الشبكة كما سنتعرف في هذا المقال إن شاء الله.

الفرق بين العُقد الكاملة والخفيفة

• لنفهم دور العُقد في تقنية نشر البيانات؛ يجب أن نتعرف أولًا على الفرق بين نوعين من العُقد، وكيف تحاول هذه التقنية استغلال النوع الأخف من العُقد لحل الكثير من مشاكل البلوكتشين.

• ذكرنا في جزء سابق أن هناك نوعين من العُقد، العقد الكاملة “Full Nodes“، وهي العُقد التي تتولى عملية تدقيق المعاملات، وتحتفظ بالسجل الكامل للبلوكتشين، والعُقد الخفيفة “Light Nodes“ أو “Light Clients“، وهي تشارك في عمل الشبكة عبر الاعتماد على العُقد الكاملة للوصول إلى بيانات سجل الكتل، لأنها لا تقوم بتخزين هذا السجل، ولهذا سُميت بهذا الاسم.

• تقوم العُقد الخفيفة بالتفاعل مع جزء صغير من البيانات يُسمى رؤوس الكتل “Block Headers“، وهذه الرؤوس تحتوي على ملخص لبيانات الكتل، لكنها لا تحتوي معلومات أخرى مثل بيانات معاملات الكتلة على سبيل المثال، ويكون دور هذه العُقد تسهيل التفاعل مع البلوكتشين وطلب البيانات منها بالنسبة للمستخدم العادي، دون حاجة إلى متطلبات ضخمة مثل ضرورة تحميل سجل الكتل بالكامل.

  

• لكن بسبب عدم احتفاظها بالسجل واعتمادها على العُقد الكاملة للوصول إلى البيانات، لا يتم الاعتماد على هذه العُقد في عملية تدقيق المعاملات قبل إضافتها للكتلة، لأنها ببساطة لا تمتلك الآليات للقيام بذلك.

• وبالتالي؛ يكون دور هذه العُقد التحقق من صحّة حالة الشبكة بشكل عام من خلال مقارنة بيانات رؤوس الكتل التي لديها ببيانات الشبكة. هذه البيانات تكون مشفرة غير قابلة للتعديل. ولهذا؛ في حالة المطابقة يمكن للعُقد الخفيفة التأكد من سلامة سجل الكتل دون حاجة للمشاركة في عملية تدقيق المعاملات. هذا بالإضافة إلى أدوار أخرى مثل طلب بيانات من السجل دون حاجة لتحميل السجل بالكامل وغير ذلك.

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

دور تقنية Data Availability في توسع شبكات البلوكتشين

• بعد كل هذه الفقرات التمهيدية؛ سنتعرف الآن على كيف يتم توظيف هذه التقنية من أجل حل مشكلة توسع شبكات البلوكتشين، وما هي التطويرات التي يمكن لهذه التقنية أن تقدمها للمساهمة في تحسين أداء هذه الشبكات.

1) حل مشكلة توسع البلوكتشين

• مشكلة توسع شبكات البلوكتشين واحدة من أسوأ المشاكل التي تعاني منها الكثير من المشاريع أبرزها البتكوين. فمعدل المعاملات الممكن معالجتها في الثانية الواحدة لا يتجاوز سبع معاملات، وهو ما يضع حدًا على إمكانات الشبكة، وحجم الاستخدام الذي يمكنها أن تصل إليه بسبب محدودية الكتلة.

• عندما بدأ الصراع في مجتمع البتكوين من أجل زيادة حجم كتلة البتكوين من أجل توسعة الشبكة، والسماح بعدد معاملات أكثر؛ مع الحفاظ على معدل رسوم مقبول؛ كانت الحجة الأبرز للفريق الرافض أن زيادة حجم الكتلة سيؤدي لزيادة حجم البلوكتشين بشكل متسارع، وذلك سيؤدي بدوره إلى صعوبة تشغيل عُقدة على الشبكة للأفراد، بسبب الحاجة إلى عتاد قوي ومكلّف.

• هذا الأمر في تصورهم كان سيؤدي إلى انخفاض عدد المدققين على شبكة البتكوين، وبالتالي قد يؤثر ذلك على لا مركزية الشبكة، وبالتالي على درجة أمانها.

  

• مسألة تضخم حجم البلوكتشين يمكن أن تصبح أسوأ في حالة الشبكات التي طبّقت تقنيات متطورة لتحسين معدل الإنتاجية “TPS“، حيث يمكن لسجل الكتل أن يزيد حجمه بعدد كبير من الجيجابايت بشكل يومي كنتيجة لذلك، وبالتالي تصبح عملية تشغيل عُقدة على الشبكة حكرًا على الشركات والمؤسسات وليس الأفراد.

• الآن؛ ماذا إذا قمنا بالسماح لشبكات البلوكتشين بزيادة معدل الإنتاجية وزيادة حجم الكتلة؛ دون القلق من تضخم حجم سجل الكتل، لأننا سنعتمد على شبكات أخرى للتعامل مع هذه البيانات؟

  

• يمكنك أن ترى نتيجة تطبيق هذه التقنية إذا نظرت لطبقات الإيثريوم الثانية مثل Arbitrum أو Base على سبيل المثال. هذه الشبكات تمتلك معدل إنتاجية مرتفع، وتوفر سرعة في إتمام المعاملات، وكذلك رسوم منخفضة، لعدة أسباب منها نقل مهمة التعامل مع بيانات البلوكتشين إلى شبكة أخرى، وذلك من خلال نشر هذه المعاملات على بلوكتشين الإيثريوم.

• بالتالي؛ يمكن للمشاريع المتخصصة في تقنية Data Availability أن تسمح لمشاريع البلوكتشين بتطوير الشبكات الخاصّة بها، وتحسين معدل إنتاجيتها دون القلق من مسألة تضخم حجم البلوكتشين. هذا بالإضافة إلى زيادة لا مركزية الشبكة من خلال خفض الحد الأدنى لمتطلبات الحواسيب التي يمكنها تشغيل عُقدة.

2) التحقق من نشر البيانات

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

• ذكرنا أيضًا أن العُقد الكاملة هي التي تقوم بعملية تدقيق المعاملات والتأكد من صحتها، لأنها تمتلك سجل البلوكتشين بالكامل، بالإضافة إلى موارد الحوسبة اللازمة لذلك، وعلى عكس العُقد الخفيفة Light Nodes.

• تقدم تقنية Data Availability حلًا لهذه المشكلة، وذلك من خلال السماح للعُقد الخفيفة بالمشاركة في عملية تدقيق المعاملات جنبًا إلى جنب مع العُقد الكاملة، وذلك من خلال الاعتماد على تقنيات مثل Data Availability Sampling وكذلك Erasure Encoding وغيرها من التقنيات. (سيتم شرح هذه التقنيات بالتفصيل في المقال القادم إن شاء الله).

  الآن ما فائدة هذه التقنيات؟

  

• لدينا نوع من أنواع الهجمات الخبيثة التي يمكن تنفيذها ضد شبكات البلوكتشين وهو هجوم حجب البيانات “Data Withholding Attack“. هذا الهجوم باختصار يعتمد على قيام مدقّق على الشبكة باقتراح كتلة تحتوي على معاملة أو أكثر غير صالحة، وحجب بيانات هذه المعاملة.

• إذا كانت أغلبية المدققين على الشبكة يعملون بشكل خبيث مع مقترح الكتلة، يمكنهم التصويت على صحّة هذه الكتلة. بالرغم من أن العُقد الكاملة ستقوم برفض هذه الكتلة، لكن هذه الهجوم قد يؤدي لمشاكل خطيرة تبدأ من توقف الشبكة إلى إمكانية سرقة أموال منها وغير ذلك من المشاكل.

• لهذا؛ فالتقنيات التي ذكرناها (Data Availability Sampling & Erasure Encoding) ببساطة تسمح للعُقد الخفيفة بالتحقق من وفرة / نشر البيانات المقترحة داخل الكتلة، بدون حاجة إلى تحميل كل بيانات تلك الكتلة، وبالتالي يمكن لهذه العُقد التحقق من ما إذا قام مقترح الكتلة بحجب أي جزء من بيانات الكتلة، دون حاجة إلى تحميل هذه البيانات.

مآخذ على تقنية نشر البيانات “Data Publishing“

• بعدما تحدثنا بشكل مفصل عن مشاكل البلوكتشين التي أدت لظهور مشاريع مخصّصة لتقنية نشر البيانات، سأتحدث سريعًا على بعض المآخذ أو السلبيات في هذه التقنية.

عدم ضمان وفرة دائمة للبيانات

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

• هذا يعني أن شبكات البلوكتشين ما زالت في حاجة إلى حلولٍ أخرى للاحتفاظ بالسجل الخاصّ بها، وهذا قد يكون حله توفير البلوكتشين نفسها لخدمة تخزين البيانات كما تفعل بلوكتشين Sui على سبيل المثال، أو استخدام تقنيات مشاريع تخزين البيانات مثل Filecoin | Arweave وغيرها.

مشاكل ضمان أمن الشبكة

• استخدام هذه الطريقة لتحقيق القابلية للتوسع يعني اعتماد البلوكتشين على أطراف خارجية لضمان أمن الشبكة الخاصّ بها. فبهذه الطريقة تعتمد شبكات البلوكتشين على شبكات أخرى للتعامل مع البيانات الخاصّة بها.

• على سبيل المثال، بيانات المستخدمين على مشاريع الطبقات الثانية على الإيثريوم تعتمد على وفرة البيانات الخاصّة بها على بلوكتشين الإيثريوم. هذا يعني أن أي شيء يحدث لتلك البيانات على الإيثريوم سيؤثر بدوره على مستخدمي الطبقات الثانية وهكذا.

• لهذا؛ فتقنية Data Availability تنزع عن شبكات البلوكتشين استقلاليتها، وتؤدي إلى حاجاتها المستمرة للاعتماد على جهات خارجية للتعامل مع البيانات الخاصّة بها.

عيوب التصميم النمطي للبلوكتشين

• بالرغم من تقديمه لتحسينات على أداء شبكات البلوكتشين؛ يؤدي التصميم النمطي للبلوكتشين “Modular Blockchain“ إلى خلق مشاكل أخرى منها:

1. تعقيد عمل الشبكة: فصل مهام الشبكة وتوزيعها على طبقات مختلفة يؤدي لتعقيد عمل الشبكة، وزيادة صعوبة تحسين وتطوير أدائها.

2. ارتفاع تكلفة التشغيل: بسبب الحاجة إلى الاعتماد على جهات خارجية في أمور مثل نشر البيانات؛ يؤدي ذلك إلى تحميل الشبكة تكاليف إضافية.

3. تشتيت المستخدمين والسيولة: هذا يمكن رؤيته بوضوح على الإيثريوم، حيث تم نقل مهمة تنفيذ المعاملات للطبقات الثانية، وذلك أدى لانخفاض نشاط الطبقة الأولى، تشتيت السيولة والمستخدمين على طبقات مختلفة.

4. مخاطر أمن الشبكة: كما ذكرت في الفقرة السابقة؛ فاعتماد الشبكات على نقل بعض مهامها لأطراف خارجية يُعد خطرًا على أمن الشبكة، خصوصًا في مهام مثل التنفيذ والإجماع.

مستقبل تقنية نشر البيانات “Data Publishing“

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

• أيضًا بالنظر إلى توجه صناديق الاستثمار في الفترة الأخيرة؛ سنجد العديد من المشاريع التي حصلت على تمويلات ضخمة في هذا المجال منها Celestia | EigenLayer (EigenDA) | Avail وغيرها من المشاريع.

• حتى المشاريع القائمة حاليًا أصبح لديهم توجه لبناء طبقات لنشر البيانات خاصّة بهم، مثل مشروع Near على سبيل المثال الذي قام بتطوير طبقة خاصّة لهذا الغرض NearDA.

• كذلك سنجد انتشار مشاريع الطبقات الثانية بشكل كبير في السنوات الأخيرة، وهي بدورها مشاريع تحتاج إلى بنية تحتية خارجية للتعامل مع البيانات الخاصّة بها، وهذا قد يدفعها إلى البحث عن مشاريع في مجال نشر البيانات للقيام بذلك.

• من ناحية أخرى؛ لا توجد منافسة ضخمة في هذا المجال، فهناك مشاريع قليلة فقط لديها التقنيات والأدوات اللازمة للسيطرة على الحصّة الأكبر في هذا المجال. ولذلك؛ فالاستثمار في مشروع من هذه المشاريع قد يكون خيارًا جيدًا لتنويع محفظتك الاستثمارية.

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

• إذا كان لديك أي استفسار عن شيء ورد في المقال يمكنك تركه في تعليق بالأسفل وسأقوم بالإجابة عليها إن شاء الله.

• يمكنك أيضًا التعليق بالعملة التي تريد أن تكون موضوع التحليل القادم إن شاء الله.