۱. تفاوت Transaction و Event Log چیست؟

در شبکه‌های مبتنی بر Ethereum Virtual Machine یا EVM، یک تراکنش دستور امضاشده‌ای است که می‌تواند وضعیت شبکه را تغییر دهد.

برای مثال، یک کاربر ممکن است با فراخوانی تابع یک قرارداد هوشمند، درخواست تبدیل USDT به ETH را ثبت کند.

اما هنگام اجرای همین تراکنش، چندین رویداد نیز ایجاد شود.

این رویدادها در بخش Logs ذخیره می‌شوند.

به زبان ساده:

1. Transaction: درخواست اجرای عملیات.
2. Receipt: نتیجه ثبت‌شده اجرای تراکنش.
3. Event Log: داده‌ای که قرارداد هنگام اجرا منتشر کرده است.
4. Execution Trace: اطلاعات جزئی‌تر درباره فراخوانی‌ها و اجرای عملیات.

این چهار مفهوم به یکدیگر مرتبط‌اند، اما یکسان نیستند.

۲. چرا Event Logs در Blockchain Forensics اهمیت دارند؟

فرض کنید کیف پول A تراکنشی با مقصد یک DEX Router ایجاد کرده است.

در نمای اولیه مشاهده می‌کنیم:

Wallet A → Router Contract

اما در Event Logs ممکن است این انتقال‌ها ثبت شده باشند:

Wallet A → Pool: 50,000 USDT

Pool → Wallet B: 49,700 USDC

اگر تحلیلگر صرفاً فیلد مقصد تراکنش را بررسی کند، ممکن است به اشتباه نتیجه بگیرد که دارایی به Router منتقل شده و مسیر آن پایان یافته است.

در حالی که Event Logs می‌توانند نشان دهند دارایی تبدیل شده و خروجی آن به Wallet B رسیده است.

نکته مهم: Event Logs برای بازسازی جریان دارایی بسیار مفیدند، اما همیشه تمام تغییرات وضعیت یا تمام جزئیات اجرای قرارداد را نشان نمی‌دهند. برای بررسی کامل‌تر ممکن است Execution Trace و تغییرات موجودی نیز لازم باشد.

۳. ساختار Transaction Receipt

Transaction Receipt مجموعه‌ای از اطلاعات مربوط به نتیجه اجرای تراکنش است.

در شبکه‌های EVM، اطلاعات مهم آن معمولاً شامل موارد زیر است:

فیلد

کاربرد در تحلیل

Transaction Hash

شناسایی تراکنش

Status

موفق یا ناموفق بودن اجرا

Block Number

محل ثبت در زنجیره

Gas Used

مقدار Gas مصرف‌شده

Logs

رویدادهای منتشرشده

Contract Address

آدرس قرارداد ایجادشده، در صورت وجود

Log Index

ترتیب رویداد در بلاک

برای تحلیلگر، بخش Logs اهمیت ویژه‌ای دارد؛ زیرا می‌تواند شامل انتقال‌های توکن، صدور مجوز، عملیات نقدینگی و سایر رویدادهای قراردادی باشد.

۴. Event Transfer در توکن‌های ERC-20

یکی از شناخته‌شده‌ترین رویدادهای استاندارد ERC-20، رویداد Transfer است.

ساختار مفهومی آن:

Transfer(address from, address to, uint256 value)

این Event سه داده اصلی دارد:

From: آدرس مبدأ

To: آدرس مقصد

Value: مقدار خام توکن

البته مقدار خام باید با توجه به تعداد Decimals توکن تفسیر شود.

برای مثال، اگر توکنی شش رقم اعشار داشته باشد، مقدار خام 50,000,000 نشان‌دهنده ۵۰ واحد توکن است، نه پنجاه میلیون واحد.

اشتباه در Decimals می‌تواند محاسبات مالی یک گزارش کارشناسی را کاملاً تغییر دهد.

۵. Topics و Data در Event Logs

در ساختار Logs معمولاً با دو مفهوم مواجه می‌شویم:

Topics

برای نگهداری اطلاعات شاخص‌گذاری‌شده استفاده می‌شوند. در رویدادهای غیرناشناس، Topic اول معمولاً شناسه امضای Event است.

Data

بخشی از اطلاعات غیرشاخص‌گذاری‌شده Event را نگهداری می‌کند.

برای تفسیر درست این داده‌ها، معمولاً باید ABI قرارداد مشخص باشد.

ABI یا Application Binary Interface توضیح می‌دهد که توابع و رویدادهای قرارداد چگونه تعریف شده‌اند.

اگر ABI معتبر در اختیار باشد، داده‌های خام به اطلاعات خوانا تبدیل می‌شوند.

اما اگر ABI وجود نداشته باشد، تحلیلگر ممکن است ناچار به بررسی امضاهای شناخته‌شده و ساختار باینری داده شود.

۶. تفاوت Event Log با Internal Transaction

این دو مفهوم نباید اشتباه گرفته شوند.

Event Log داده‌ای است که قرارداد هنگام اجرا منتشر می‌کند.

اما آنچه Explorerها گاهی با عنوان Internal Transaction نمایش می‌دهند، معمولاً نمایی استخراج‌شده از فراخوانی‌های داخلی EVM است.

برای مثال:

Wallet A → Contract X

سپس در اجرای قرارداد:

Contract X → Contract Y

و بعد:

Contract Y → Wallet B

ممکن است همه این اتفاق‌ها در قالب یک تراکنش اصلی رخ داده باشند.

برای مشاهده ساختار فراخوانی‌ها، ابزارهای Trace می‌توانند اطلاعاتی ارائه دهند که از Logs به‌تنهایی قابل استخراج نیست.

۷. روش عملی تحلیل یک تراکنش پیچیده

برای بررسی حرفه‌ای، مراحل زیر را انجام دهید.

مرحله اول: شناسایی تراکنش

TXID، شبکه، شماره بلاک و زمان را ثبت کنید.

مرحله دوم: بررسی وضعیت

مشخص کنید تراکنش موفق بوده یا Revert شده است.

در تراکنش ناموفق نیز ممکن است Gas مصرف شده باشد، اما تغییرات وضعیت اجرای ناموفق معمولاً بازگردانده می‌شوند.

مرحله سوم: شناسایی قرارداد

بررسی کنید آدرس مقصد EOA است یا Smart Contract.

مرحله چهارم: استخراج Logs

تمام Eventهای مرتبط را همراه آدرس قرارداد منتشرکننده و Log Index ثبت کنید.

مرحله پنجم: Decode

با استفاده از ABI معتبر، داده‌های Event را تفسیر کنید.

مرحله ششم: بررسی Execution Trace

اگر رویدادها توضیح کاملی از جریان دارایی نمی‌دهند، فراخوانی‌های داخلی را نیز بررسی کنید.

مرحله هفتم: تطبیق موجودی

تغییر موجودی آدرس‌های مهم را با داده‌های استخراج‌شده مقایسه کنید.

۸. مثال عملی: انتقال دارایی از طریق قرارداد

فرض کنید قربانی متوجه خروج ۸۰ هزار USDT شده است.

بررسی اولیه نشان می‌دهد:

Victim Wallet → Contract A

اما تحلیل Logs این اطلاعات را آشکار می‌کند:

مرحله

مبدأ

مقصد

دارایی

۱

Victim

Contract A

80,000 USDT

۲

Contract A

Pool

80,000 USDT

۳

Pool

Wallet B

79,600 USDC

۴

Wallet B

Wallet C

79,500 USDC

این جدول یک سناریوی فرضی است.

با این تحلیل، مسیر دارایی در Contract A متوقف نمی‌شود.

همچنین مشخص می‌شود که ادامه بررسی باید روی USDC انجام شود.

۹. آیا Event Logs همیشه قابل اعتمادند؟

Event Logs ثبت‌شده در Receipt یک تراکنش معتبر، بخشی از داده‌های زنجیره هستند؛ با این حال، معنای یک Event را نباید بدون بررسی قرارداد قطعی فرض کرد.

یک قرارداد مخرب می‌تواند رویدادی با نام آشنا منتشر کند، بدون آنکه رفتاری مطابق انتظار یک قرارداد استاندارد داشته باشد.

به همین دلیل، در موارد حساس باید داده‌های Logs با اجرای واقعی قرارداد، کد آن و تغییرات موجودی تطبیق داده شوند.

این موضوع به‌ویژه در بررسی توکن‌های ناشناخته و قراردادهای مشکوک اهمیت دارد.

۱۰. مستندسازی Event Logs برای گزارش کارشناسی

برای هر رویداد مهم، اطلاعات زیر را نگهداری کنید:

1. Network و Chain ID
2. TXID و Block Number
3. Contract Address
4. Event Signature
5. Log Index
6. داده خام Topics و Data
7. نتیجه Decode و ABI مورد استفاده
8. زمان استخراج اطلاعات
9. منبع داده و ابزار تحلیل

در گزارش نهایی بهتر است میان داده خام و تفسیر کارشناس تفکیک روشنی وجود داشته باشد.

برای مثال:

مشاهده: قرارداد X رویداد Transfer با مقصد Y منتشر کرده است.

تحلیل: با بررسی تغییر موجودی و Execution Trace، انتقال واقعی دارایی به Y نیز تأیید شده است.

این دو گزاره از نظر قدرت اثباتی یکسان نیستند.

۱۱. اشتباهات رایج تحلیلگران

یکی از خطاها، برابر دانستن تعداد Eventهای Transfer با تعداد تراکنش‌های مستقل است. یک تراکنش ممکن است ده‌ها Event تولید کند.

اشتباه دیگر، تفسیر رویدادها بدون توجه به قرارداد منتشرکننده است.

همچنین نباید از وجود Event به‌تنهایی نتیجه گرفت که یک شخص مشخص مالک آدرس دریافت‌کننده است.

Event Logs درباره رفتار قرارداد اطلاعات می‌دهند، نه لزوماً هویت واقعی کاربران.

پرسش‌های متداول

آیا برای تحلیل Event Logs باید برنامه‌نویسی بلد باشیم؟

خیر. بسیاری از Explorerها اطلاعات Decode‌شده ارائه می‌کنند، اما آشنایی با ABI، JSON-RPC و ابزارهای تحلیل EVM برای پرونده‌های پیچیده مزیت مهمی است.

آیا Logs تراکنش ناموفق قابل بررسی‌اند؟

Receipt وضعیت شکست را ثبت می‌کند، اما Logs حاصل از اجرای Revert‌شده به‌عنوان رویدادهای نهایی تراکنش باقی نمی‌مانند. برای تحلیل جزئیات شکست ممکن است Trace لازم باشد.

آیا Event Logs در TRON نیز وجود دارند؟

بله. قراردادهای سازگار با TVM می‌توانند رویدادهایی با ساختار مشابه منتشر کنند، هرچند ابزارها و جزئیات شبکه ممکن است متفاوت باشند.

نتیجه‌گیری

در Blockchain Forensics، TXID نقطه شروع تحلیل است، نه پایان آن.

بررسی Transaction Receipt، Event Logs و Execution Trace می‌تواند اطلاعاتی را آشکار کند که در نمای معمول Explorer دیده نمی‌شوند.

مهم‌ترین اصل این است که تحلیلگر میان رویداد منتشرشده، اجرای واقعی قرارداد، تغییر موجودی و انتساب هویت تفاوت قائل شود.

چنین رویکردی هم دقت ردیابی وجوه را افزایش می‌دهد و هم کیفیت گزارش کارشناسی را بهبود می‌بخشد.

دعوت به اقدام: اگر در بررسی یک تراکنش با چندین قرارداد هوشمند یا انتقال توکن مواجه شده‌اید، پیش از نتیجه‌گیری درباره مقصد نهایی دارایی، ساختار Event Logs و Execution Trace آن را بررسی کنید.