نقشه حداقلی رویدادهای دارایی برای توکنیزه‌سازی: صدور، انتقال، وثیقه‌گذاری، تعلیق، بازخرید (با فیلدهای ضروری)
اگر نتوانیم با یک استعلام بگوییم «چه رویدادی، چه زمانی، روی این واحد رخ داد»، لایه توکن به‌تنهایی قرار نیست اعتماد بسازد.
اگر نتوانیم با یک استعلام بگوییم «چه رویدادی، چه زمانی، روی این واحد رخ داد»، لایه توکن به‌تنهایی قرار نیست اعتماد بسازد.
توکنیزه‌سازی می‌تواند رهگیری و برنامه‌پذیری انتقال را بهتر کند؛ برای کامل شدن این مزیت، لازم است پشت توکن یک «لایه حقیقت عملیاتی» داشته باشیم. این لایه حقیقت، رجیستری رویداد است: ثبت ساخت‌یافته همه تغییرات وضعیت، همراه با شناسه‌های یکتا و مسیر مدرک.
مقدمه
در این مقاله یک مدل رجیستری رویداد دارایی با حداقل اجزای لازم را مرور می‌کنیم؛ مدلی که برای تیم‌های فناوری و عملیات قابل اجرا باشد و وابسته به یک فناوری خاص نباشد. می‌توانیم آن را ابتدا در یک پایگاه داده معمولی پیاده کنیم و اگر بعداً لازم شد، به ریل‌های توکنیزه‌سازی یا بلاکچین متصل کنیم.
هدف ما روشن است: تعریف چند نوع رویداد ضروری و یک چک‌لیست فیلد برای هر رویداد، تا وضعیت دارایی قابل استعلام، قابل حسابرسی و در برابر دوباره‌فروشی مقاوم‌تر شود.
طرح مسئله
بخش زیادی از اختلاف‌ها زمانی شکل می‌گیرد که فقط یک «وضعیت جاری» قابل تغییر نگه می‌داریم؛ مثلاً یک ستون ساده به نام «وضعیت» یا «مالک فعلی». در این حالت، با هر به‌روزرسانی، ردپا از بین می‌رود و بعداً اثبات این موارد دشوار می‌شود:
- چه کسی وضعیت را تغییر داده است.
- تغییر دقیقاً در چه زمانی رخ داده است.
- وضعیت قبل از تغییر چه بوده است.
- چه مدرکی پشت آن تغییر قرار داشته است.
چالش اصلی معمولاً در «قیدها» دیده می‌شود. یک واحد در یک سامانه قابل انتقال به نظر می‌رسد، اما در واقع وثیقه شده یا به‌صورت موقت تعلیق شده است. وقتی این قیدها رویداد مشخص نداشته باشند، سازگاری داده بین سامانه‌ها به کار دستی، تطبیق‌های زمان‌بر و اختلاف برداشت تبدیل می‌شود.
رجیستری رویدادها یعنی چه؟
رجیستری رویدادها را می‌توانیم به‌عنوان «تایم‌لاین واقعیت‌ها» ببینیم.
به‌جای این‌که مقدار «مالک = B» را روی رکورد قبلی بنویسیم، یک رویداد جدید ثبت می‌کنیم:
- انتقال از A به B در زمان T
- ثبت‌شده توسط عامل R
- همراه با ارجاع به مدرک E
در این طراحی، «وضعیت جاری» یک خروجی محاسباتی از روی رویدادهاست. همین نگاه باعث می‌شود بتوانیم تاریخچه را بازپخش کنیم و به همان وضعیت امروز برسیم؛ یعنی حسابرسی‌پذیری واقعی ایجاد می‌شود.
برای فهم شهودی، می‌توانیم رجیستری‌های متعارف را به‌عنوان یک قیاس در نظر بگیریم: اعتماد فقط در عکسِ امروز نیست، در زنجیره تغییرات ثبت‌شده هم هست. این صرفاً یک مثال ذهنی است و به‌خودی‌خود به معنی توکنیزه‌سازی نیست.
رویدادهای حداقلی که لازم داریم
برای بسیاری از محصولات مبتنی بر دارایی واقعی، یک مدل حداقلی با شش نوع رویداد کفایت می‌کند. اسم‌ها ممکن است در سازمان‌ها فرق کند، اما معنا و اثر عملیاتی باید روشن بماند.
۱) صدور (Issue)
ایجاد یک واحد جدید دارایی در رجیستری و تعیین دارنده اولیه.
۲) انتقال (Transfer)
جابجایی واحد از یک دارنده به دارنده دیگر.
۳) وثیقه‌گذاری (Pledge)
اعمال قید وثیقه روی واحد به نفع یک ذی‌نفع. این رویداد معمولاً انتقال را مسدود می‌کند یا انتقال را مشروط می‌سازد.
۴) تعلیق (Freeze)
اعمال محدودیت عملیاتی برای جلوگیری از برخی عملیات، معمولاً انتقال. تعلیق می‌تواند برای کنترل ریسک یا رسیدگی به عدم‌انطباق‌های فرایندی استفاده شود.
۵) بازخرید (Redeem)
خارج کردن واحد از گردش و علامت‌گذاری به‌عنوان تسویه‌شده/بازخریدشده، به‌طوری که انتقال‌های بعدی ممکن نباشد.
۶) ابطال یا اصلاح (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: مصوبه/تأییدیه و مستندات
راهکار یا چارچوب عملی: طراحی بر اساس استعلام‌ها
ثبت رویداد زمانی ارزش عملیاتی دارد که پرسش‌های پرتکرار را سریع و قابل دفاع پاسخ دهد. یک روش کاربردی این است که استعلام‌ها را از ابتدا تعریف کنیم و بعد مطمئن شویم اسکیمای رویداد همه داده‌های لازم را دارد.
چند استعلام رایج در عملیات دارایی‌های واقعی:
- «آیا این واحد الان قابل انتقال است؟»
- باید بتوانیم آخرین دارنده، وثیقه‌های فعال، تعلیق‌های فعال و وضعیت بازخرید را محاسبه کنیم.
- «تاریخچه معتبر این واحد چیست؟»
- باید بتوانیم رویدادها را با ترتیب روشن و مدرک همراه، نمایش دهیم.
- «کدام واحدها در حال حاضر وثیقه یا تعلیق دارند؟»
- باید بتوانیم رویدادهای فعال را پیدا کنیم؛ با پایان زمانی یا با رویداد آزادسازی/رفع تعلیق.
در عمل معمولاً یک جدول «وضعیت جاری» هم برای سرعت نگه می‌داریم، اما آن را خروجیِ مشتق‌شده می‌بینیم. منبع حقیقت همچنان لاگ رویداد است.
همچنین در ایران و بازارهای مشابه، تأکید بر «شناسه یکتا» و تبادل ساخت‌یافته اطلاعات رسید/موجودی بین سامانه‌ها در قواعد و روندهای ثبت و انبارداری برجسته است. این جهت‌گیری، از نگاه معماری، دلیل قوی‌تری برای طراحی رویدادمحور با شناسه‌های سازگار ایجاد می‌کند، حتی پیش از آن‌که اتصال به بلاکچین مطرح شود.
یک مثال ساده
فرض کنیم یک رجیستری برای واحدهای مبتنی بر قبض انبار به‌صورت فرضی طراحی کرده‌ایم و یک واحد با شناسه WU-2026-00017 در آن گردش دارد.
- رویداد صدور با شناسه E1 این واحد را ایجاد می‌کند و دارنده اولیه را «طرف A» ثبت می‌کند و به سند صدور ارجاع می‌دهد.
- رویداد انتقال با شناسه E2 واحد را از «طرف A» به «طرف B» منتقل می‌کند و مدرک دستور انتقال را نگه می‌دارد.
- رویداد وثیقه‌گذاری با شناسه E3 نشان می‌دهد «طرف B» این واحد را به نفع «طرف C» وثیقه کرده است.
- درخواست انتقال جدید می‌آید، اما استعلام «قابل انتقال بودن» پاسخ منفی می‌دهد، چون وثیقه فعال است.
- رویداد تعلیق با شناسه E4 به دلیل یک عدم‌انطباق عملیاتی، انتقال را موقتاً محدود می‌کند و مرجع تأیید را ثبت می‌کند.
- رویداد بازخرید با شناسه E5 پس از رفع قیدها ثبت می‌شود و واحد را از گردش خارج می‌کند.
نکته کلیدی این است که اعتماد از «قابلیت پاسخ‌گویی رجیستری» می‌آید: هر تغییر وضعیت باید یک رویداد با شناسه و مدرک داشته باشد.
ریسک‌ها و محدودیت‌ها
رجیستری رویدادها رهگیری و حسابرسی را تقویت می‌کند، اما برای اجرای قوی‌تر، چند لایه مکمل هم باید همسو باشند:
- اگر هویت طرفین و عاملان ثبت رویداد قابل اتکا نباشد، «چه کسی چه کرد» همچنان محل اختلاف می‌ماند.
- اگر مدارک پشتیبان ناقص یا غیرقابل راستی‌آزمایی باشد، رویدادها بیشتر شبیه ادعا می‌شوند تا سند.
- اگر حاکمیت روشن نباشد، مثلاً مشخص نباشد چه کسی حق تعلیق یا اصلاح دارد، خودِ لاگ هم می‌تواند محل مناقشه شود.
با هم‌راستاسازی هویت، مدیریت مدارک، سطح دسترسی و اختیارات عملیاتی، مدل رویدادی به یک زیرساخت محکم تبدیل می‌شود که بعداً می‌تواند به ریل‌های توکنیزه‌سازی وصل شود.
جمع‌بندی
توکن زمانی قابل اعتماد می‌شود که هر تغییر وضعیت دارایی به‌صورت یک رویداد قابل استعلام ثبت شود و شناسه یکتا و مسیر مدرک داشته باشد.
با یک مدل حداقلی شامل «صدور، انتقال، وثیقه‌گذاری، تعلیق، بازخرید و اصلاح»، می‌توانیم رجیستری‌ای بسازیم که مهم‌ترین پرسش عملیاتی را سریع و قابل دفاع پاسخ دهد: «این واحد الان قابل انتقال است یا نه، و بر چه مبنایی؟»
پرسش‌های متداول
۱) برای پیاده‌سازی این مدل حتماً به بلاکچین نیاز داریم؟
خیر. می‌توانیم رجیستری رویداد را در یک پایگاه داده معمولی بسازیم و بعداً در صورت نیاز، لایه‌های توزیع‌شده یا ثبت بر بستر بلاکچین را اضافه کنیم.
۲) چرا وثیقه و تعلیق را جداگانه تعریف می‌کنیم؟
چون ماهیت و اثر عملیاتی متفاوت دارند و بیشتر اختلاف‌ها دقیقاً حول همین قیدها شکل می‌گیرد. جدا بودن این رویدادها باعث می‌شود «قابل انتقال بودن» قابل محاسبه و قابل حسابرسی باشد.
۳) آیا نگه داشتن وضعیت جاری و چند فایل پیوست کافی نیست؟
وضعیت جاری بدون تاریخچه قابل اتکا، به سختی پاسخ‌گوی حسابرسی و اختلاف است. رویدادها هر تغییر را به زمان، عامل، طرفین و مدرک وصل می‌کنند و همین اتصال، استعلام‌پذیری را واقعی می‌کند.