تخيل عدة جهات تحتاج إلى تسجيل عمليات مشتركة، ولا تريد أن تكون نسخة السجل تحت تصرف جهة واحدة فقط. كيف تتفق على ما حدث وترتيبه؟ وكيف تكتشف محاولة تغيير ما سبق تسجيله؟ البلوكتشين إحدى الطرق لمعالجة هذا النوع من المشكلات، لكنها لا تجعل كل مشروع يحتاج إليها، ولا تثبت صحة كل معلومة تدخلها.
يساعد فصل الفكرة التقنية عن أسعار العملات على فهمها. فالسؤال في هذا المقال هو تنظيم السجل والتحقق منه، وليس تقييم أصل مالي. سنستخدم مثالًا تعليميًا عن متابعة شحنة لشرح أين تفيد البنية الرقمية، وأين تبقى الحاجة إلى إجراءات وأشخاص ومصادر موثوقة في العالم الفعلي.
ما السجل الموزع؟
السجل قائمة منظمة بعمليات أو أحداث، وتوجد في النظام الموزع نسخ أو أدوار موزعة بين عقد مشاركة. أما البلوكتشين فتجمع سجلات في كتل ترتبط بطريقة تجعل التلاعب بالتاريخ قابلًا للكشف وصعبًا ضمن افتراضات التشغيل. يعرض تقرير NIST رقم 8202 المبادئ والفروق بين الشبكات المفتوحة والمقيدة بالمشاركة.
في المثال الافتراضي، تسجل شركة النقل استلام صندوق، ويسجل المستودع وصوله، ثم تؤكد جهة أخرى تسليمه. قد نرغب في امتلاك تاريخ مشترك تستطيع الجهات مراجعته. لكن قبل اختيار التقنية يجب تحديد من يكتب، ومن يقرأ، ومن يتحقق، وكيف يعالج الخطأ أو النزاع.
كيف ترتبط الكتل؟
تستخدم أنظمة البلوكتشين دوال تجزئة تنتج بصمة رقمية للبيانات. وقد يتضمن تعريف الكتلة رابطًا ببصمة كتلة سابقة، فتتشكل سلسلة من العلاقات. تغيير بيانات سابقة يغير البصمة المتوقعة، ولذلك لا يكفي تعديل نسخة محلية والادعاء بأن التاريخ المشترك أصبح مختلفًا.
قدمت ورقة بيتكوين الأصلية تصميمًا يجمع التوقيعات الرقمية وربط الكتل وإثبات العمل لمشكلة محددة، هي سجل نقد إلكتروني بين أطراف متعددة دون الاعتماد على الوسيط التقليدي نفسه. ليست كل شبكة بلوكتشين نسخة مطابقة لهذا التصميم، ولا تستخدم جميعها آلية التحقق ذاتها.
للتقريب، تخيل دفترًا يشير كل فصل فيه إلى بصمة الفصل الذي سبقه. إذا غير أحدهم فصلًا قديمًا، تظهر مشكلة في العلاقات التالية. لكن التشبيه لا يكفي وحده لصنع نظام آمن؛ إذ نحتاج إلى قواعد تحدد النسخة المقبولة وصلاحيات المشاركين وما يحدث عندما تتعارض الرسائل.
لماذا لا تكفي البصمات وحدها؟
قد تحاول عقدة اقتراح تاريخ، وتقترح عقدة أخرى تاريخًا مختلفًا. هنا تدخل آلية الإجماع: مجموعة قواعد تساعد المشاركين على التحقق من العمليات واختيار امتداد مقبول للسجل. توجد ترتيبات مختلفة بحسب نوع الشبكة وافتراضات الثقة والموارد ومن يسمح له بالمشاركة.
توضح وثائق إيثريوم عن آليات الإجماع أن إثبات العمل أو إثبات الحصة ليس الوصف الكامل لبروتوكول الإجماع وحده؛ توجد أيضًا قواعد اختيار السلسلة والتعامل مع التعارض. لذلك فعبارة «لدينا بلوكتشين» لا تخبرنا تلقائيًا كيف يعمل الأمان أو متى نعد العملية مستقرة.
في مثال الشحنة، قد تتفق مؤسسات معروفة على إدارة عقد محددة بصلاحيات معلنة. هذا تصميم مختلف عن شبكة مفتوحة تسمح بمشاركة جهات لا تعرف بعضها مسبقًا. ولا يمكن مقارنة التصميمين بمجرد القول إن أحدهما يستخدم كلمة «موزع» أكثر من الآخر.
ما الذي يعنيه صعوبة التغيير؟
تصف الصعوبة علاقة بين التصميم والموارد والحوافز والقواعد، وليست وعدًا بأن جميع الشبكات غير قابلة لأي تعديل تحت أي ظرف. كما قد توجد إجراءات لإصلاح تطبيق أو تغيير قواعده، وقد تختلف طريقة التعامل مع سجل خاطئ بين نظام وآخر. السؤال المفيد هو: من يستطيع فعل ماذا، وبأي موافقة، وما الأثر الذي يبقى ظاهرًا؟
إذا سجل موظف رقم صندوق خاطئًا، فإن اكتشاف التلاعب الرقمي ليس هو المشكلة الوحيدة. نحتاج إلى طريقة معلنة لتسجيل تصحيح وربطه بالحدث السابق، وإلى توضيح من يراجع الخطأ. إخفاء هذا الإجراء خلف عبارة «التاريخ لا يتغير» يجعل النظام أصعب في الفهم والمحاسبة.
هل العقد الذكي يفهم الاتفاق؟
العقد الذكي برنامج ينفذ قواعد محددة على المنصة. لا يكتسب معرفة بالعالم لمجرد اسمه، ولا يفسر تلقائيًا النوايا التي لم تكتب في قواعده. إذا أردنا أن يعتمد على وصول شحنة أو درجة حرارة مستودع، فهناك حاجة إلى وسيلة تنقل بيانات خارج السلسلة إليه.
تسمى بعض هذه الوسائل أوراكل. توضح وثائق البيانات الخارجية والعقود الذكية كيف تصل المعلومات من خارج الشبكة إلى البرامج التي تعمل عليها. وهنا يعود سؤال الثقة: من قدم القياس، وكيف تحققنا منه، وهل يمكن تعطله أو التلاعب به؟
لنفترض أن جهازًا معطوبًا أرسل أن الشحنة بقيت في درجة الحرارة المطلوبة. يمكن للسجل حفظ هذه الرسالة بدقة، لكنه لا يحول الجهاز المعطوب إلى شاهد صحيح. لهذا ينبغي فصل سلامة تخزين البيانات عن صدق البيانات نفسها، وفحصهما بإجراءات تناسب كل مستوى.
متى تكون قاعدة بيانات عادية أوضح؟
إذا كانت جهة واحدة مسؤولة ومعترفًا بدورها، وتحتاج إلى سجل داخلي قابل للتدقيق، فقد تكفي قاعدة بيانات مع صلاحيات وتوثيق وتدقيق جيد. أما إذا كانت المشكلة مشاركة سجل بين أطراف لها استقلال ومصالح متباينة، فقد تستحق بعض تصاميم السجلات الموزعة الدراسة. هذه نقطة بداية للتحليل وليست قاعدة شراء جاهزة.
اكتب متطلباتك أولًا: حجم البيانات، وسرية المعلومات، وسرعة الاستجابة، وصلاحيات التعديل، والتكلفة، والتعامل مع الأخطاء. ثم قارن حلولًا تحقق المتطلبات نفسها. لا تكون المقارنة عادلة إذا منحنا حلًا مزايا افتراضية وألزمنا الآخر بأسوأ تنفيذ ممكن.
أسئلة تكشف جودة أي عرض
اطلب وصفًا واضحًا للأطراف الموثوق بها، وما الذي تتحقق منه العقد، وكيف تدخل البيانات الخارجية، ومن يدير مفاتيح الوصول، وما إجراءات فقدانها أو تغيير الصلاحيات. واطلب مثالًا لخطأ حقيقي وكيف سيظهر تصحيحه في النظام، بدل الاكتفاء بعرض يعمل في الظروف المثالية.
البلوكتشين وسيلة لبناء اتفاق قابل للتحقق على سجل مشترك ضمن افتراضات معينة. وفائدتها تتضح حين تعالج مشكلة محددة لا يحلها ترتيب أبسط بالكفاءة المطلوبة، مع بقاء الصلة بين السجل والعالم الخارجي موضوعًا يحتاج إلى تصميم ومسؤولية واضحة.
الخلاصة في سطر: البلوكتشين سجل مشترك يصعب تغييره ضمن افتراضات معينة، لكنه لا يثبت صحة ما يُكتب فيه عن العالم الخارجي.
المصادر وروابط التحقق
تفضّل المشاهدة على القراءة؟
أفكار مشابهة بشرح سريع في فيديوهات قصيرة على مصفوفة النجاح — يوتيوب، تيك توك، وتليجرام.
