تأكيد صحة البيانات

التحقق من صحة البيانات هو عملية توضيح دقة وسلامة وجودة مجموعة من البيانات قبل استخدامها.

ما هو التحقق من صحة البيانات؟

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

تشكل البيانات أساس جميع الحلول ، وغني عن القول أنه لكي يكون الحل فعالاً ، يجب أن تكون البيانات دقيقة. في Web3 ، يعتمد المطورون والمحللون والمشاركون في الشبكة جميعًا على البيانات من أجل استمرار عمل blockchains. بالنسبة لهؤلاء اللاعبين ، يعد استخدام البيانات الصحيحة أمرًا بالغ الأهمية من أجل منع أي أخطاء أو تناقضات أو مخاطر على المستخدم أو تنازلات تهدد سلامة المشروع.

الحاجة إلى الصلاحية في Web3

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

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

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

تحديات التحقق من الصحة وعدم الكفاءة

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

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

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

حل لامركزي

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

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

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

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

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

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

مؤلف: فابيان ريو ، المؤسس المشارك والرئيس التنفيذي لشركة KYVE ، أحد حلول بحيرة البيانات Web3.

بدأ فابيان رحلته كمسؤول تقني في شركة محلية ناشئة لتكنولوجيا التعليم. بدأ هاكاثون في عام 2019 شغفه بـ Web3 ، وبعد ستة أشهر أسس أول مشروع ناجح له ArVerify ، وهو نظام KYC على السلسلة الذي شهد اعتمادًا كبيرًا في Arweave Ecosystem. بعد فترة وجيزة في عام 2021 ، شارك في تأسيس KYVE ، بحيرة بيانات Web3 اللامركزية ، مع جون ليتي.

مرحباً بعودتك!

ادخل الى حسابك بالأسفل

استعادة كلمة السر.

رجاءً ادخل اسم المستخدم او بريدك الإلكتروني لإستعادة كلمة السر الخاصة بك.

Exit mobile version