البلوكشين نظام مشترك للاتفاق على التاريخ واستخلاص الحالة الحالية
البلوكشين دفتر أستاذ رقمي موزّع تحتفظ به حواسيب متعددة. يسجّل المعاملات التي اجتازت التحقق وفق ترتيب متفق عليه، ويربط السجلات اللاحقة بما سبقها. ومن التاريخ المقبول يستطيع المشاركون تحديد الحالة الراهنة للنظام.
هذا التعريف أنفع من القول إنها مجرد سلسلة من الكتل. فالكتل بنية لتخزين البيانات؛ أما الغاية الأوسع فهي التنسيق: أن تعمل أطراف وبرمجيات لا تخضع لمالك واحد لقاعدة بيانات اعتماداً على سجل متسق.
تقنية السجلات الموزّعة مفهوم أوسع؛ والبلوكشين نموذج منها ينظّم السجلات المقبولة في كتل متصلة تشفيرياً. وهناك سجلات موزّعة أخرى تستخدم هياكل بيانات أو أساليب ترتيب مختلفة.
يصف تقرير المعهد الوطني الأمريكي للمعايير والتقنية (NIST) حول البلوكشين هذه السجلات بأنها تكشف العبث وتقاومه. وهذه صياغة دقيقة: إعادة كتابة التاريخ صعبة في التشغيل المعتاد للشبكة، لكن وصفه بأنه «غير قابل للتغيير مطلقاً» تبسيط مضلل.
التعريف الأساسي: تنسّق البلوكشين حالة مشتركة بجمع الطلبات الموقّعة، وقواعد التحقق، والتاريخ المرتب، والروابط التشفيرية، وآلية الفصل بين نسخ التاريخ المتنافسة.
الحالة المشتركة تجيب عن سؤال بسيط: ما الذي يُعد صحيحاً داخل النظام الآن؟
يحتاج كل نظام للمعاملات إلى إجابة راهنة: من يستطيع إنفاق عملة معينة؟ كم يبلغ رصيد حساب؟ من هو مالك الرمز المسجّل؟ وما بيانات العقد بعد أحدث عملية صحيحة؟
في النظام المركزي، يتولى مشغّل واحد حفظ هذه الإجابات: البنك يدير قاعدة بيانات الحسابات، والمنصة تحتفظ بسجلات الملكية، ومعالج الدفع يتابع حالة المعاملات. وتعتمد الجهات الأخرى على قاعدة بيانات ذلك المشغّل وإجراءاته.
توزّع البلوكشين هذه الوظيفة. تحتفظ العُقد بنسخ من التاريخ المعني أو تتحقق منها، وتطبّق قواعد مشتركة لحساب الحالة. وتصف المقدمة التقنية لإيثريوم الشبكة بأنها قاعدة بيانات عامة تتشارك حواسيب عديدة تحديثها. ليست الفائدة في نسخ البيانات وحده؛ بل في إمكانية تقارب النسخ إلى الحالة الصحيحة نفسها.
- الحالة: أحدث وضع صحيح للأرصدة وحقوق التحكم وبيانات العقود وسائر سجلات الدفتر.
- التاريخ: تسلسل التغييرات التي تم التحقق منها وأنتجت الحالة الحالية.
- القواعد: شروط البروتوكول التي تحدد صلاحية أي تغيير مقترح.
- الاتفاق: عملية اختيار ترتيب مقبول واحد عندما تظهر تواريخ مرشحة متنافسة.
لا تعني الحالة المشتركة وصول كل رسالة إلى كل عقدة في اللحظة نفسها. فهناك تأخير، وقد تتباين آراء العقد مؤقتاً. الخاصية الأهم هي التقارب: أن يتمكن المشاركون الصالحون في النهاية من معرفة التاريخ المقبول واشتقاق الحالة ذاتها.
الكتل تجعل التاريخ أسهل ترتيباً وتحققاً وأكثر مقاومة للتعديل الخفي
تصل المعاملات باستمرار، لكن الشبكة تحتاج إلى سجل مرتب. في أنظمة كثيرة تُجمع المعاملات المقبولة في كتل، وتحتوي كل كتلة مرجعاً أو التزاماً تشفيرياً بالكتلة السابقة، فيتكوّن تسلسل زمني مترابط.
تجعل هذه الصلة التشفيرية التغييرات التاريخية قابلة للاكتشاف. فإذا تغيّرت بيانات قديمة تغيّرت بصمتها أو التزاماتها، ولم تعد المراجع اللاحقة متطابقة؛ عندها يمكن للعُقد التي تتحقق من السلسلة رفض النسخة المعدلة.
يعرّف دليل مطوري بيتكوين السلسلة بأنها سجل عام مرتب ومؤرّخ للمعاملات يساعد على منع الإنفاق المزدوج وتعديل السجلات السابقة. كذلك تجمع إيثريوم المعاملات في كتل وتربطها بالتاريخ السابق وفق ما تشرحه وثائق الكتل في إيثريوم.
الكتلة 104 ← مرجع الكتلة 103
التزامات المعاملات
التزام الحالة الناتجة
↓
الكتلة 105 ← مرجع الكتلة 104
التزامات معاملات جديدة
التزام حالة جديدةلذلك لا تؤمّن السلسلة التخزين فحسب، بل تاريخاً قابلاً للتدقيق. ويمكن تفسير الحالة الحالية والتغييرات المقبولة التي أدت إليها، وليس الاكتفاء بعرض النتيجة.
سجل المعاملات والحالة الحالية مرتبطان، لكنهما ليسا الشيء نفسه
يروي تاريخ المعاملات ما تغير؛ وتبيّن الحالة الراهنة حصيلة جميع التغييرات الصحيحة حتى لحظة معينة. وهذا الفصل مهم لأن شبكات البلوكشين لا تمثل الحالة بالطريقة نفسها.
تستخدم بيتكوين نموذج مخرجات المعاملات غير المنفقة (UTXO). فالقيمة القابلة للإنفاق هي مخرج من معاملة سابقة لم يُستهلك في معاملة لاحقة. يوضح دليل معاملات بيتكوين كيف تستهلك المعاملات مخرجات قائمة وتنشئ أخرى جديدة.
وتستخدم إيثريوم حالة قائمة على الحسابات. وتوضح وثائق آلة إيثريوم الافتراضية بنية تضم الحسابات والأرصدة وشيفرات العقود والتخزين. وتنقل المعاملة الصحيحة النظام من حالة إلى أخرى وفق قواعد التنفيذ.
وقد تفصل الشبكات المصرّح بها بين المفهومين بصورة أوضح. تصف وثائق دفتر Hyperledger Fabric تاريخ الكتل إلى جانب قاعدة بيانات «حالة العالم» التي تحتفظ بالقيم الحالية لتسريع الوصول إليها.
فكرة أساسية: التاريخ يشرح كيف تغير النظام؛ والحالة تصف آخر نتيجة. يحتاج تحليل البلوكشين إلى المفهومين حتى لو خزّنتهما الشبكات أو عرضتهما بطرق مختلفة.
البلوكشين لا تلغي الثقة، بل تعيد توزيعها على القواعد والبرمجيات والاقتصاد والتشغيل
يُساء فهم وصف الشبكات بأنها «لا تتطلب الثقة». فهي لا تخلق عالماً تختفي فيه الثقة؛ وإنما تقلّل حاجة المشاركين إلى الثقة بجهة واحدة تملك سلطة منفردة على سجل المعاملات.
- قواعد البروتوكول: يعتمد المشاركون على تطبيق البرمجيات الصحيحة لقواعد المعاملات والحالة.
- التشفير: تجعل التوقيعات والتجزئة والالتزامات التشفيرية التفويض والتغيير قابلين للتحقق.
- حوافز الإجماع: يعمل المعدّنون أو المدققون أو الأقران المصرّح لهم ضمن قواعد وحوافز تؤثر في سلوكهم.
- الاعتماد التشغيلي: تظل المحافظ والواجهات والحفظ والوصول إلى العُقد والبيانات الخارجية مواضع ثقة.
هكذا تتغير المخاطر ولا تختفي. ربما يقل اعتماد المستخدم على سجل مصرفي واحد، لكنه يصبح أكثر اعتماداً على حماية المفاتيح، وسلامة البرمجيات، ومشاركة الشبكة، وصحة البيانات الخارجية وإجراءات الاسترداد.
لذلك لا يكفي السؤال «هل النظام لامركزي؟». ينبغي السؤال عن الصلاحيات التي وُزّعت، والتبعيات التي بقيت مركّزة، وما الذي يجب الوثوق به لكي تظل النتيجة صحيحة.
التحقق يختبر القواعد؛ والإجماع يحدد التاريخ الصحيح الذي يصبح مرجعاً للشبكة
التحقق والإجماع وظيفتان مرتبطتان لكن مختلفتان. يسأل التحقق: هل تتوافق المعاملة أو الكتلة مع قواعد البروتوكول؟ ويسأل الإجماع: أي ترتيب صحيح ينبغي اعتماده كتاريخ مشترك عند وجود مرشحين متعددين؟
قد تفحص العقدة التوقيعات والأرصدة المتاحة وتنسيق المعاملة ونتائج تنفيذها وبنية الكتلة. تمنع هذه الاختبارات انتقالات الحالة غير الصحيحة، ثم تحسم آلية الاتفاق الترتيب وتساعد الشبكة على التقارب.
- سؤال التحقق: هل تسمح قواعد البروتوكول بهذه المعاملة أو الكتلة المقترحة؟
- سؤال الإجماع: أي ترتيب صالح ينبغي أن تتعامل معه جميع الجهات باعتباره التاريخ المقبول؟
تعالج إثبات العمل وإثبات الحصة والتصويت المتحمّل للأخطاء البيزنطية والنماذج المفوّضة وأنظمة الترتيب المصرّح بها هذا السؤال بطرق مختلفة. وتؤثر المفاضلات في نهائية التسوية، والإنتاجية، والمشاركة، ومقاومة الرقابة، وتكلفة إعادة كتابة التاريخ.
حدّ مهم: لا يقرر الإجماع ما إذا كان الادعاء عن العالم الخارجي صحيحاً؛ بل يقرر صلاحية الانتقال وفق قواعد الشبكة والتاريخ الذي ستعترف به.
الملكية على السلسلة تعني عادة القدرة المعترف بها على تفويض تغيير لاحق في الحالة
يقال أحياناً إن «العملات داخل المحفظة»، لكنها عبارة ناقصة تقنياً. سجل الأصل موجود في الحالة المشتركة؛ أما المحفظة فتدير بيانات الاعتماد اللازمة لتفويض المعاملات المؤثرة في ذلك السجل.
في نظام العملة الأصلية، لا تُنفق القيمة إلا إذا استوفت المعاملة شرطاً تشفيرياً محدداً. وفي الشبكات القائمة على الحسابات، قد تُربط الأرصدة بعنوان ويُسمح بالتغييرات التي يفوضها المفتاح المناسب أو منطق العقد.
يسمح ذلك بتحكم رقمي قوي يمكن للشبكة التحقق منه من دون الرجوع إلى مسؤول حسابات مركزي. لكنه يفرض مسؤولية صعبة: فقدان بيانات التفويض أو كشفها قد يعني فقدان التحكم العملي في الأصل.
تمييز ضروري: التحكم المسجّل على السلسلة ليس دائماً مساوياً للملكية القانونية. قد يمثل الرمز مطالبة أو عضوية أو إيصالاً أو أصلاً مادياً، بينما يعتمد أثره القانوني على العقود والحفظ والجهات المصدرة والتنظيم والقضاء خارج الشبكة.
المحافظ تدير التفويض، بينما تحتفظ البلوكشين بسجل الأصول
يُستخدم المفتاح الخاص لإنشاء توقيع رقمي يُثبت أن طلباً ما صدر بتفويض من صاحب السر المقابل، من دون الكشف عن السر نفسه. وتشرح وثائق حسابات إيثريوم العلاقة بين الحسابات وتشفير المفتاح العام.
يمكن للمحفظة إنشاء المفاتيح وعرض العناوين وبناء المعاملات وتوقيع الطلبات ومراقبة الأرصدة والاتصال بخدمات الشبكة. تحتفظ بعض المحافظ بالمفاتيح على جهاز المستخدم، بينما قد تتحكم جهات الحفظ بالمفاتيح نيابة عن العملاء. ويمكن لمحافظ العقود الذكية فرض شروط تفويض إضافية.
لذلك ليست الحفظ الذاتي مجرد خيار في واجهة المستخدم، بل تحمّل الفرد أو المؤسسة مسؤولية أمن المفاتيح والنسخ الاحتياطي والاسترداد وسياسات التوقيع والتحقق من المعاملات.
نموذج التحكم: يحدد دفتر السجل الشروط التي تتحكم في الأصل؛ وتساعد المحفظة الطرف المخوّل على استيفائها.
العملات الأصلية والرموز قد يحمل كلاهما قيمة، لكنهما يقعان في طبقتين مختلفتين
تنتمي العملة الأصلية إلى نظام المحاسبة الأساسي للبروتوكول. توجد بيتكوين بموجب قواعد معاملات شبكتها، وتوجد إيثر ضمن نموذج حسابات إيثريوم وتنفيذها. وتُستخدم الأصول الأصلية كذلك عادة لدفع رسوم الشبكة.
أما الرمز فيعرّفه عادة منطق برنامج يعمل فوق البلوكشين. يحدد معيار ERC-20 وظائف شائعة للأرصدة والتحويلات والعرض والموافقات. ويحدّث عقد الرمز سجلاته ضمن الحالة الأوسع لإيثريوم.
هذا الفرق عملي: رمز الأصل وحده لا يحدد مسار الدفع. يجب معرفة الشبكة وعقد الرمز وشكل العنوان وأصل دفع الرسوم وسلوك التسوية. تعرض وثائق العملات المدعومة في OxaPay بيانات الأصول والشبكات، بينما يسرد مرجع الشبكات المدعومة شبكات البلوكشين بصورة منفصلة.
- عملة أصلية: يحددها البروتوكول الأساسي وتدخل غالباً في رسوم الشبكة أو آلية أمنها.
- رمز: تحدده شيفرة عقد أو تطبيق، ويعتمد على الشبكة الأساسية للتنفيذ والتسوية.
تثبت البلوكشين ما قبلته قواعدها، لا صحة كل ادعاء خارجي
يمكن للبلوكشين تقديم دليل قوي عن سجلها الداخلي: أن معاملة وُقّعت وتحققت منها الشبكة ورتبتها وأدرجتها واحتفظت بها وفق قواعدها، وأن حالة معينة نتجت من هذه الأحداث.
لكن الشبكة لا تستطيع وحدها إثبات أصالة سلعة شُحنت أو صحة نقل ملكية عقار قانونياً. ولا تتحقق ذاتياً من بيانات الطقس التي يقدمها وسيط خارجي أو من احتياطيات جهة مصدرة. تدخل هذه الحقائق عبر أشخاص ومؤسسات وأجهزة وعقود ومدققين وخدمات بيانات.
- دليل داخلي قوي: تفويض المعاملة وترتيبها وإدراجها وانتقال الحالة وتنفيذ العقد المسجّل.
- اعتماد خارجي: الهوية والملكية القانونية وجودة الاحتياطيات وحالة الشحن وبيانات السوق وغيرها من الحقائق خارج الشبكة.
والخصوصية ليست مضمونة أيضاً؛ فالمعاملات على الشبكات العامة قد تكون مرئية على نطاق واسع، والعناوين المستعارة ليست مرادفاً لإخفاء الهوية. وتناقش أبحاث NIST حول خصوصية السجلات الموزعة التوتر بين مقاومة العبث ومتطلبات الخصوصية.
الشبكات العامة والمصرّح بها توزّع السلطة بطرق مختلفة
تتيح الشبكات العامة المفتوحة عادة مشاركة واسعة في إرسال المعاملات أو التحقق منها أو المساهمة في أمنها الاقتصادي. صُممت قواعدها لبيئة قد لا يعرف المشاركون فيها بعضهم أو يثق بعضهم ببعض.
أما الشبكات المصرّح بها فتقيّد المشاركة بالهوية أو التحكم التنظيمي أو سياسة العضوية أو المدققين المسموح لهم. Hyperledger Fabric مثال لمنصة سجل موزع مؤسسية مصرح بها، مع حوكمة وعضوية قابلتين للضبط.
| السؤال | عامة بلا إذن | مصرّح بها |
|---|---|---|
| من يمكنه المشاركة؟ | مشاركة واسعة أو مفتوحة غالباً | هويات أو مؤسسات معتمدة |
| كيف توزّع الثقة؟ | البروتوكول والاقتصاد والتحقق المفتوح | الحوكمة والعضوية والأقران المخوّلون |
| الأولوية المعتادة | حيادية الوصول ومقاومة الرقابة | الخصوصية والأداء والتحكم المؤسسي |
لا يتفوق أي نموذج في جميع الحالات. يعتمد التصميم المناسب على الجهة التي يجب أن تتحقق من السجل أو تحدّثه، وكيف تُحل النزاعات، وما إذا كانت المشاركة المفتوحة ضرورة أم مخاطرة.
تكون البلوكشين مفيدة حين تحتاج أطراف مستقلة إلى حالة مشتركة دون احتكار السجل
البلوكشين ليست دائماً أفضل قاعدة بيانات. فعندما يدير العملية مشغّل موثوق واحد، تكون قاعدة البيانات التقليدية غالباً أسرع وأقل تكلفة وأسهل تصحيحاً وحماية للخصوصية.
تصبح البلوكشين أنسب إذا احتاج مشاركون مستقلون إلى اقتراح التغييرات أو التحقق منها، أو إلى تاريخ قابل للتدقيق، أو إذا كان منح طرف واحد صلاحية إعادة كتابة السجل يمثل خطراً أو اعتماداً مفرطاً.
- مؤشر إيجابي: تحتاج عدة جهات إلى التحقق من السجل المتغير نفسه.
- مؤشر إيجابي: يجب ألا يستطيع طرف واحد إعادة كتابة التاريخ بمفرده.
- مؤشر ضعيف: يملك مشغّل موثوق مسبقاً جميع البيانات والقرارات.
- مؤشر ضعيف: يجب أن تكون البيانات قابلة للحذف أو التصحيح أو سرية تماماً افتراضياً.
لا بد أيضاً من تبرير كلفة نسخ البيانات والإجماع وإدارة المفاتيح والحوكمة والمراقبة والتكامل. المشروع الذي يحتاج مجرد جدول بيانات مشترك لا ينبغي تحويله إلى بلوكشين لمجرد جاذبية المصطلح.
في المدفوعات تسجّل البلوكشين التسوية، وتفسّر البنية التحتية معناها التجاري
يمكن للسلسلة تسجيل انتقال القيمة وفق قواعد الشبكة. لكن التاجر ما زال يحتاج إلى تحديد العميل والطلب، والتأكد من الأصل والشبكة والمبلغ واللحظة الآمنة لتسليم السلعة أو الخدمة.
هنا يأتي دور بنية الدفع التحتية: ربط حالة السلسلة بالفواتير ومعرّفات الطلبات ومنطق سعر الصرف وتحديثات الحالة والسجلات المحاسبية وإجراءات الدعم.
تصف وثائق خدمات التجار لدى OxaPay إصدار فواتير العملات الرقمية وتدفقات الدفع ذات العلامة التجارية والعناوين الثابتة. وتوفّر خدمة التجار في OxaPay وMerchant API طبقة للأعمال لإنشاء المدفوعات وتتبعها عبر الأصول والشبكات المدعومة.
- طبقة البلوكشين: تتحقق من انتقالات القيمة وتسجلها وفق قواعد الشبكة.
- طبقة الدفع: تربط هذه الانتقالات بالفواتير والطلبات والحالات والإجراءات التشغيلية.
مبدأ التاجر: تحدد البلوكشين حالة الشبكة؛ وتحدد البنية التحتية للدفع معنى هذه الحالة بالنسبة للأعمال.
خمس عبارات مبسطة وراء كثير من سوء الفهم حول البلوكشين
تؤدي العبارات المختصرة التالية إلى استنتاجات خاطئة عندما تُعامل على أنها حقائق مطلقة:
- «لا يمكن تغيير بيانات البلوكشين أبداً». الأدق أن تعديل التاريخ المقبول يصبح أصعب مع مرور الوقت، لكن الأمان يعتمد على الشبكة والإجماع والمشاركة وعمق التأكيد.
- «البلوكشين تلغي الثقة». هي تقلل الاعتماد على مالك واحد للسجل وتوزع الثقة بين القواعد والتشفير والبرامج والحوافز والعمليات.
- «المحفظة تخزن العملات». تحتفظ الشبكة بسجل الأصول، بينما تدير المحفظة بيانات الاعتماد اللازمة للتحكم.
- «السجل العام يعني إخفاء الهوية». السجل العام مرئي، والعناوين المستعارة قابلة للتحليل والربط أحياناً بهويات حقيقية.
- «البلوكشين تثبت صحة كل ما سُجّل». هي تثبت قبول الشبكة للبيانات أو الانتقال وفق قواعدها؛ أما الحقائق الخارجية فتحتاج إلى أدلة مستقلة.
أوضح نموذج ذهني: آلة حالة مشتركة بذاكرة قابلة للتدقيق
ينشئ المشاركون طلبات موقّعة. تتحقق العُقد من صحة تلك الطلبات، وترتّب الشبكة التغييرات المقبولة، وتحفظ الكتل أو الالتزامات المكافئة التاريخ المتفق عليه. ثم يستطيع كل مشارك اشتقاق الحالة الراهنة أو التحقق منها.
طلب موقّع
↓
التحقق وفق البروتوكول
↓
ترتيب المعاملات
↓
التاريخ المقبول
↓
الحالة المشتركة الحالية
↓
إمكان تفويض تغييرات جديدةتنبثق الملكية الرقمية من هذه العملية؛ فالشبكة تحدد الشروط التي يجب استيفاؤها قبل نقل الأصل المسجّل، وتتيح المفاتيح والعقود والتوقيع المتعدد وغيرها من أدوات التفويض طلب ذلك النقل.
يوضح النموذج أيضاً الحدود: يمكن للنظام تنسيق حقيقة داخلية عالية النزاهة، لكنه لا يلغي التبعيات الخارجية ولا يضمن الخصوصية ولا يصحح البيانات الخاطئة ولا يحل محل الإجراءات التجارية والقانونية.
الخلاصة: ليست قيمة البلوكشين في وضع البيانات داخل كتل؛ بل في توفير تاريخ قابل للتحقق وحالة مشتركة وطريقة واضحة لتفويض التغييرات عندما لا ينبغي لطرف واحد امتلاك السجل المرجعي الوحيد.
المراجع البروتوكولية والمؤسسية التي استند إليها التحليل
تستند التعريفات والفروق التقنية هنا إلى الوثائق الرسمية للبروتوكولات والمنشورات المؤسسية التالية، التي تتناول بالتفصيل بنية السجلات والمعاملات والحالة والتشفير وتصميم الدفاتر الموزعة.