من المسؤول عن البيانات؟ وما الذي يتغير عند وضعها على البلوكشين؟

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

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

البيانات لا تصبح أبداً بلا مالك

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

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

ما الذي يغيره البلوكشين — وما الذي لا يغيره

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

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

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

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

متى يتم الاحتفاظ بالبيانات خارج البلوكشين

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

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

الخيار العملي الافتراضي: الإثبات على البلوكشين، والتخزين خارجه

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

يفصل نموذج بيانات الاعتماد القابلة للتحقق (Verifiable Credentials) الخاص بـ W3C بين المصدر، والحامل، والموضوع، والمتحقق. يمكن للشخص إثبات حقيقة دون كشف سجل هوية كامل. الهدف هو جعل الثقة محمولة مع مشاركة أقل قدر من البيانات.

في بعض الأحيان، لا تحتاج إلى بلوكشين على الإطلاق. فقاعدة البيانات المدارة جيداً توفر التشفير، والتحكم في الوصول، وأحداث التدقيق الموقعة، والتصحيح السريع. يوفر سجل الشفافية باستخدام أشجار ميركل (مثل Certificate Transparency، RFC 9162) أدلة تضمين دون إجماع موزع. السؤال الحاسم ليس “هل يمكننا استخدام البلوكشين؟” بل “ما هو الفشل الذي نحاول منعه؟“

اختبار من سبعة أسئلة قبل المعاملة الأولى

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

ADAMANT: الديمومة للنقل، والخصوصية للمحتوى

تقدم ADAMANT مثالاً ملموساً على المقايضة المتعمدة. تستخدم الشبكة بلوكشين يعتمد على إثبات الحصة المفوض (Delegated Proof of Stake) كطبقة ثقة لا مركزية للاتصال. لا يحتاج العملاء إلى الوثوق بخادم شركة واحدة للحفاظ على سجل المعاملات المشترك.

لكن البلوكشين ليس عذراً لنشر نص عادي. وفقاً لوثائق ADAMANT، يتم تشفير أصول معاملات الرسائل قبل حزمها في معاملات، وتوقيعها، وبثها. تستخدم الدردشة الأساسية تشفيراً بالمفتاح العام الموثق يعتمد على NaCl box؛ وتستخدم سجلات المفتاح والقيمة NaCl secretbox. يقوم العميل بالعمل التشفيري محلياً.

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

المسؤولية ميزة

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

خريطة قرار عملية للاختيار بين البيانات خارج البلوكشين، والهجينة، وعلى البلوكشين.