النموذج الأدنى لسجل أحداث الأصل للترميز: إصدار، نقل، رهن، تجميد، استرداد (والحقول المطلوبة)

إذا لم نتمكّن من الإجابة عبر استعلام واحد عن سؤال: «ما الذي حدث لهذه الوحدة ومتى؟» فلن تكفي طبقة التوكن وحدها لبناء الثقة.

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

مقدمة

نستعرض هنا نموذجاً عملياً حدّياً لـ سجل أحداث الأصل يصلح لمنتجات RWA (أصول العالم الحقيقي التي تُدار رقمياً أو تُمثَّل بتوكنات). النموذج محايد تقنياً؛ يمكن تنفيذه في قاعدة بيانات تقليدية أو نظام سجلات مؤسسي، ثم ربطه لاحقاً بمسارات الترميز أو البلوكشين عند الحاجة.

هدفنا هو بناء أساس قابل للتنفيذ لدى فرق التقنية والعمليات: أقل مجموعة من أنواع الأحداث مع قائمة حقول مطلوبة تجعل حالة الأصل قابلة للاستعلام والتدقيق وتقلّل مخاطر البيع المزدوج.

المشكلة

تظهر النزاعات غالباً عندما نعتمد على «حالة حالية» قابلة للتعديل فقط، مثل حقل واحد يعبّر عن المالك الحالي أو الحالة.

عند الكتابة فوق السجل نفقد القدرة على إثبات:

• من غيّر الحالة،
• متى تغيّرت،
• ما هي الحالة السابقة،
• وما الدليل الذي استند إليه التغيير.

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

ما هو سجل الأحداث دون تعقيد مصطلحات

سجل الأحداث هو خط زمني للحقائق.

بدلاً من تحديث «المالك = B» مباشرة، نضيف حدثاً جديداً:

• نقل من A إلى B في وقت T،
• سجّله عامل/خدمة R،
• ومدعوم بدليل E.

بهذا الأسلوب تصبح «الحالة الحالية» نتيجة مشتقة من الأحداث. ويمكن إعادة تشغيل الأحداث للوصول إلى نفس النتيجة دائماً، وهو ما يمنحنا قابلية تدقيق حقيقية.

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

أقل أنواع الأحداث التي نحتاجها

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

1) إصدار (Issue)

إنشاء وحدة أصل جديدة في السجل وتحديد الحائز/المالك الأول.

2) نقل (Transfer)

تحويل الوحدة من حائز إلى آخر.

3) رهن/تقييد مالي (Pledge)

تسجيل أن الوحدة مرهونة لصالح طرف مستفيد، ما يقيّد التحويل عادةً أو يجعله مشروطاً.

4) تجميد (Freeze)

فرض قيد تشغيلي يمنع بعض العمليات، وغالباً يمنع التحويل. وقد يكون لأسباب تشغيلية أو لمعالجة عدم تطابق أو نزاع.

5) استرداد/إخراج من التداول (Redeem)

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

6) إلغاء/تصحيح (Cancel/Correct)

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

الحقول المطلوبة: مشتركة وخاصّة بكل حدث

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

حقول مشتركة لكل الأحداث

هذه هي الحقول الدنيا التي نحتاجها غالباً:

• event_id: معرّف فريد عالمياً للحدث.
• event_type: نوع الحدث.
• asset_unit_id: معرّف فريد لوحدة الأصل.
• sequence_no: رقم تسلسلي لكل asset_unit_id لتثبيت ترتيب الأحداث.
• event_time: وقت وقوع الحدث (وقت الأعمال).
• recorded_time: وقت تسجيله في النظام.
• actor_id: معرّف الجهة التي أرسلت/سجّلت الحدث.
• parties/roles: معرّفات الأطراف والأدوار (المُصدِر، الحائز الحالي، الحائز الجديد، المستفيد من الرهن…).
• state_before / state_after أو state_before_hash / state_after_hash: تمثيل واضح لما تغيّر قبل/بعد.
• evidence_ref: مرجع الأدلة الداعمة مع بياناتها الوصفية.
• verifier_id (اختياري لكنه مفيد): من تحقّق من الأدلة أو أجرى فحصاً.
• idempotency_key: لمنع تكرار تسجيل نفس الحدث عند إعادة المحاولة.

حقول خاصة بكل حدث

الإصدار

• issuer_id
• initial_holder_id
• quantity أو خصائص الوحدة
• asset_spec_ref: مرجع مواصفات الأصل وإصداره/نسخته
• evidence_ref

النقل

• from_holder_id
• to_holder_id
• transfer_basis: سبب/أساس النقل (بيع، تسوية، نقل داخلي)
• consideration_ref (عند الحاجة): مرجع الفاتورة/الدفع
• evidence_ref

الرهن

• pledgor_id: الراهن
• pledgee_id: المستفيد
• pledge_scope: رهن كامل الوحدة أو جزء منها
• release_conditions_ref (عند الحاجة)
• effective_from / effective_to
• evidence_ref

التجميد

• freeze_reason_code: سبب التجميد
• freeze_scope: نطاق المنع (تحويل فقط، استرداد فقط، كل العمليات)
• requested_by_id و approved_by_id (عند تطبيق حوكمة)
• effective_from / effective_to
• evidence_ref

الاسترداد

• redeemer_id
• redemption_method: طريقة الاسترداد
• settlement_ref (عند الحاجة): مرجع التسوية/التسليم
• evidence_ref

الإلغاء/التصحيح

• replaces_event_id: الحدث الذي يتم تصحيحه
• correction_reason
• evidence_ref

إطار عملي: نبدأ بالاستعلامات التي نحتاجها

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

استعلامات شائعة في عمليات RWA:

1. هل هذه الوحدة قابلة للتحويل الآن؟
   • نحتسب آخر حائز، وأي رهن فعّال، وأي تجميد فعّال، وحالة الاسترداد.
2. ما التاريخ المعتمد لهذه الوحدة؟
   • نعرض الأحداث مرتبة وفق sequence_no مع مراجع الأدلة.
3. ما الوحدات المرهونة أو المجمّدة حالياً؟
   • نبحث عن أحداث رهن/تجميد فعّالة لم يُنهها انتهاء زمني أو رفع قيد مسجّل.

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

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

مثال مبسط

نفترض مثالاً افتراضياً لوحدة مخزنية مرقّمة WU-2026-00017 ضمن سجل أصول.

1. حدث إصدار (E1) ينشئ الوحدة ويحدد الحائز الأول «الطرف A» مع مرجع دليل الإصدار.
2. حدث نقل (E2) يحوّل الوحدة من «A» إلى «B» مع دليل تعليمات نقل موقّعة.
3. حدث رهن (E3) يقيّد الوحدة لصالح «C» باعتبارها ضماناً.
4. يصل طلب نقل جديد، لكن استعلام «قابلة للتحويل؟» يعيد «لا» بسبب وجود رهن فعّال.
5. حدث تجميد (E4) يضيف قيداً مؤقتاً بسبب عدم تطابق تشغيلي مع مرجع الموافقة.
6. حدث استرداد (E5) يخرج الوحدة من التداول بعد انتهاء القيود أو رفعها، مع مرجع تسوية/تعليمات.

جوهر المثال أن الثقة تأتي من إمكانية الدفاع عن الإجابة عبر السجل: كل تغيير حالة له حدث ومعرّف ودليل.

المخاطر والقيود

سجل الأحداث يقوّي التتبع والتدقيق، لكنه لا يضمن وحده كل عناصر الثقة من دون طبقات مكملة:

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

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

الخلاصة

يصبح التوكن أكثر جدارة بالثقة عندما نلتزم بأن كل تغيّر حالة يُسجّل كحدث قابل للاستعلام، بمعرّف فريد ومسار أدلة.

ومع نموذج حدّي للأحداث يشمل: إصدار، نقل، رهن، تجميد، استرداد، وتصحيح، نستطيع بناء سجل يجيب بشكل سريع وقابل للتدقيق عن السؤال التشغيلي الأهم: «هل هذه الوحدة قابلة للتحويل الآن، ولماذا؟»

الأسئلة الشائعة

1) هل نحتاج إلى البلوكشين لتطبيق هذا النموذج؟

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

2) لماذا نفصل بين الرهن والتجميد؟

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

3) لماذا لا نكتفي بالحالة الحالية مع ملفات PDF؟

لقطة الحالة الحالية مع مستندات مبعثرة يصعب التحقق منها. الأحداث تربط التغيير بالوقت والجهات والأدلة بطريقة يمكن الاستعلام عنها وإعادة بنائها بثقة.