آموزش ردیابی تراکنش‌های TON و Jetton؛
از پیام‌های داخلی تا شناسایی مقصد واقعی دارایی
در بسیاری از شبکه‌های بلاکچینی، بررسی یک تراکنش با شناسایی آدرس مبدأ، آدرس مقصد و مقدار انتقال آغاز می‌شود. اما در شبکه TON، معماری پیام‌محور و اجرای ناهم‌زمان قراردادهای هوشمند باعث می‌شود تحلیل تراکنش‌ها به رویکرد متفاوتی نیاز داشته باشد. فرض کنید قربانی اعلام می‌کند که ۱۵ هزار واحد از یک Jetton از کیف پول او خارج شده است. بررسی اولیه نشان می‌دهد تراکنشی از کیف پول قربانی به یک قرارداد هوشمند ارسال شده، اما آدرس قرارداد با آدرس شخص دریافت‌کننده یکسان نیست. آیا دارایی واقعاً به همان قرارداد منتقل شده است؟ آیا قرارداد فقط واسطه انتقال بوده؟ آیا Jetton موردنظر معتبر است؟ و چگونه می‌توان ادامه مسیر آن را شناسایی کرد؟ پاسخ این پرسش‌ها در شناخت معماری Jetton و بررسی زنجیره پیام‌های TON قرار دارد. فهرست مطالب ۱. تفاوت TON و شبکه‌های مبتنی بر EVM ۲. Jetton چیست و چگونه نگهداری می‌شود؟ ۳. ساختار انتقال Jetton ۴. تحلیل پیام‌های داخلی ۵. شناسایی قرارداد اصلی توکن ۶. بررسی Swap و انتقال دارایی ۷. خطاهای رایج در ردگیری TON ۸. تهیه گزارش کارشناسی
۱. تفاوت معماری TON با Ethereum
در شبکه Ethereum معمولاً تحلیلگر با یک تراکنش اصلی و مجموعه‌ای از Event Logs و فراخوانی‌های داخلی روبه‌رو می‌شود.
در TON، تعامل قراردادها از طریق پیام انجام می‌شود و اجرای یک عملیات ممکن است به چند تراکنش مرتبط در حساب‌های مختلف منجر شود.
برای مثال، انتقال یک Jetton می‌تواند شامل چند مرحله باشد:
User Wallet
↓
Sender Jetton Wallet
↓
Receiver Jetton Wallet
↓
Receiver Wallet
این ساختار به معنای چهار انتقال مستقل دارایی میان چهار مالک مختلف نیست.
برخی از این مراحل صرفاً بخشی از سازوکار اجرای انتقال هستند.
به همین دلیل تحلیلگر باید میان آدرس مالک، قرارداد Jetton Wallet و قرارداد اصلی توکن تفاوت قائل شود.
۲. Jetton چیست؟
Jetton استاندارد رایج توکن‌های قابل‌تعویض در شبکه TON است.
در معماری استاندارد، هر Jetton دارای یک قرارداد اصلی به نام Jetton Master و برای هر دارنده، یک قرارداد Jetton Wallet اختصاصی است.
Jetton Master
قرارداد اصلی توکن اطلاعاتی مانند عرضه، داده‌های توکن و کد کیف پول مربوط به آن را مدیریت می‌کند.
Jetton Wallet
قراردادی است که موجودی Jetton متعلق به یک مالک مشخص را نگهداری و عملیات انتقال را اجرا می‌کند.
فرض کنید کاربر A دو Jetton مختلف داشته باشد.
ممکن است برای هر توکن یک Jetton Wallet جداگانه وجود داشته باشد، در حالی که مالک هر دو همان آدرس اصلی کاربر A است.
بنابراین مشاهده چند قرارداد Jetton Wallet به معنای وجود چند مالک مستقل نیست.
۳. ساختار یک انتقال Jetton
در یک انتقال استاندارد، ابتدا کیف پول کاربر پیامی به Jetton Wallet خودش ارسال می‌کند.
سپس Jetton Wallet فرستنده، پیام داخلی را به Jetton Wallet گیرنده می‌فرستد.
در صورت وجود شرایط لازم، قرارداد گیرنده نیز پیام اطلاع‌رسانی برای کیف پول مالک ارسال می‌کند.
ساختار مفهومی:
Owner A
↓ transfer
Jetton Wallet A
↓ internal_transfer
Jetton Wallet B
↓ transfer_notification (optional)
Owner B
نکته مهم این است که پیام اطلاع‌رسانی همیشه وجود ندارد؛ بنابراین نبودن آن به‌تنهایی ثابت نمی‌کند انتقال ناموفق بوده است.
برای تعیین نتیجه باید وضعیت اجرای پیام‌ها و تغییر موجودی Jetton Walletها بررسی شود.
۴. Opcode چیست؟
پیام‌های استاندارد Jetton با شناسه‌های مشخصی شناخته می‌شوند.
برای مثال:
عملیات
Opcode
Transfer
0x0f8a7ea5
Internal Transfer
0x178d4519
Transfer Notification
0x7362d09c
Excesses
0xd53276db
این شناسه‌ها به تحلیلگر کمک می‌کنند نوع پیام را تشخیص دهد.
با این حال، صرف مشاهده یک Opcode برای اثبات اجرای صحیح انتقال کافی نیست. باید قرارداد فرستنده، گیرنده و نتیجه اجرای پیام نیز بررسی شود.
۵. چگونه یک تراکنش TON را بررسی کنیم؟
مرحله اول: شناسایی تراکنش اولیه
اطلاعات زیر را ثبت کنید:
- آدرس کیف پول قربانی
- شناسه تراکنش یا شناسه Trace
- زمان ثبت
- مقدار Jetton
- آدرس Jetton Master
- آدرس Jetton Wallet فرستنده
مرحله دوم: بررسی پیام خروجی
مشخص کنید کیف پول قربانی چه پیامی ارسال کرده است.
اگر پیام به Jetton Wallet خودش ارسال شده، این موضوع می‌تواند بخشی از روند عادی انتقال توکن باشد.
مرحله سوم: دنبال‌کردن Internal Transfer
پیام بعدی را بررسی کنید تا Jetton Wallet مقصد مشخص شود.
مرحله چهارم: شناسایی مالک مقصد
باید مالک Jetton Wallet گیرنده مشخص شود.
این مالک همان آدرسی است که برای ادامه تحلیل اقتصادی اهمیت دارد.
مرحله پنجم: بررسی تراکنش‌های بعدی
اکنون تاریخچه Jetton متعلق به مالک مقصد را بررسی کنید تا مشخص شود دارایی نگهداری، منتقل یا در یک سرویس DeFi استفاده شده است.
۶. چرا شناسایی Jetton Master اهمیت دارد؟
نام و نماد توکن در TON به‌تنهایی معیار معتبر بودن آن نیست.
ممکن است دو توکن مختلف نام USDT یا نامی مشابه داشته باشند.
بنابراین تحلیلگر باید آدرس Jetton Master را با منبع معتبر تطبیق دهد.
در غیر این صورت ممکن است یک توکن جعلی به اشتباه معادل دارایی اصلی در نظر گرفته شود.
این اشتباه در پرونده‌های مالی می‌تواند بسیار جدی باشد.
برای مثال، دریافت ۱۰ هزار واحد از توکنی با نام USDT لزوماً به معنای دریافت ۱۰ هزار دلار تتر معتبر نیست.
۷. تحلیل یک سناریوی فرضی
فرض کنیم قربانی ۲۰ هزار واحد از یک Jetton معتبر را از دست داده است.
مسیر اولیه:
Victim Wallet
↓
Victim Jetton Wallet
↓
Receiver Jetton Wallet
↓
Wallet A
سپس Wallet A دارایی را به یک DEX منتقل می‌کند.
Wallet A
↓
DEX
↓
Jetton X → TON
در این مرحله باید مشخص شود چه مقدار TON دریافت شده و دارایی خروجی به کدام آدرس رسیده است.
اگر تحلیلگر فقط به دنبال Jetton اولیه باشد، ممکن است مسیر را از دست بدهد.
اصل مهم همان دنبال‌کردن جریان ارزش است، اما در TON باید آن را با تحلیل پیام‌های مرتبط و نتیجه اجرای قراردادها ترکیب کرد.
۸. بررسی Swap در شبکه TON
برای بررسی Swap، مشاهده یک پیام به قرارداد DEX کافی نیست.
باید مشخص شود:
- چه دارایی‌ای وارد عملیات شده است؟
- آیا Swap موفق بوده است؟
- چه دارایی‌ای از عملیات خارج شده است؟
- دریافت‌کننده واقعی خروجی چه آدرسی است؟
- آیا عملیات شامل Refund یا مسیر چندمرحله‌ای بوده است؟
ممکن است بخشی از TON مشاهده‌شده در پیام‌ها صرفاً برای پرداخت کارمزد و اجرای قرارداد استفاده شده باشد.
بنابراین نباید هر انتقال TON را معادل جابه‌جایی ارزش اصلی پرونده در نظر گرفت.
۹. مفهوم Trace در TON
Trace نمایی از مجموعه تراکنش‌ها و پیام‌های مرتبط با یک عملیات است.
در تحلیل Forensics، مشاهده Trace می‌تواند به بازسازی مسیر اجرای قراردادها کمک کند.
اما باید دقت کرد که نمایش Trace در Explorer یک لایه تفسیری روی داده‌های زنجیره است.
برای پرونده‌های حساس بهتر است اطلاعات مهم با داده‌های خام و منابع مستقل تطبیق داده شوند.
۱۰. اشتباهات رایج
اشتباه اول: Jetton Wallet را مالک نهایی فرض کنیم
Jetton Wallet یک قرارداد است و باید مالک آن شناسایی شود.
اشتباه دوم: فقط نام توکن را بررسی کنیم
نام و نماد توکن ممکن است جعل شوند.
اشتباه سوم: هر پیام را انتقال مالی مستقل بدانیم
بعضی پیام‌ها برای اطلاع‌رسانی، بازگرداندن TON اضافی یا اجرای عملیات قراردادی هستند.
اشتباه چهارم: فقط یک TXID را بررسی کنیم
یک عملیات در TON ممکن است مجموعه‌ای از تراکنش‌ها و پیام‌های مرتبط ایجاد کند.
اشتباه پنجم: شکست بخشی از عملیات را نادیده بگیریم
باید وضعیت اجرا، Bounce و نتیجه نهایی عملیات بررسی شود.
۱۱. جدول پیشنهادی مستندسازی
مرحله
نوع رویداد
آدرس مرتبط
نتیجه
۱
Transfer Request
Wallet قربانی
درخواست انتقال
۲
Internal Transfer
Jetton Wallet مقصد
انتقال توکن
۳
Notification
Wallet مقصد
اطلاع‌رسانی در صورت وجود
۴
Swap
قرارداد DEX
تبدیل دارایی
۵
Transfer
Wallet بعدی
ادامه مسیر
در نسخه واقعی گزارش، باید آدرس کامل، شناسه تراکنش، مقدار و زمان هر رویداد نیز ثبت شود.
۱۲. تهیه گزارش کارشناسی برای مرجع قضایی
برای گزارش قضایی بهتر است ابتدا نتیجه به زبان ساده بیان شود:
«بررسی داده‌های ثبت‌شده در شبکه TON نشان می‌دهد دارایی موردنظر از کیف پول متعلق به شاکی خارج شده و پس از اجرای پیام‌های مرتبط با قرارداد توکن، به کیف پول مقصد منتقل شده است.»
سپس در صورت وجود شواهد کافی می‌توان ادامه داد:
«دارایی مذکور در مرحله بعد از طریق یک قرارداد صرافی غیرمتمرکز به دارایی دیگری تبدیل شده است.»
در پیوست، جزئیات فنی شامل آدرس‌های کامل، شناسه تراکنش‌ها، Jetton Master، پیام‌ها و خروجی قراردادها ارائه می‌شود.
همچنین باید روشن باشد که شناسایی یک آدرس مقصد به معنای احراز هویت مالک حقیقی آن نیست.
پرسش‌های متداول
آیا ردیابی Jetton با TON معمولی تفاوت دارد؟
بله. انتقال Jetton معمولاً از طریق قراردادهای Jetton Wallet و پیام‌های مرتبط انجام می‌شود، در حالی که انتقال TON بومی ساختار متفاوتی دارد.
آیا هر Jetton Wallet یک کاربر جداگانه است؟
خیر. یک مالک ممکن است برای توکن‌های مختلف چند Jetton Wallet داشته باشد.
آیا با مشاهده یک تراکنش می‌توان نتیجه Swap را مشخص کرد؟
گاهی Explorer نتیجه را نمایش می‌دهد، اما برای بررسی تخصصی باید پیام‌های مرتبط و تغییرات واقعی موجودی تحلیل شوند.
نتیجه‌گیری
ردیابی تراکنش‌های TON نیازمند شناخت معماری پیام‌محور شبکه و تفاوت میان Wallet اصلی، Jetton Wallet و Jetton Master است.
تحلیلگر باید به جای تمرکز بر یک تراکنش منفرد، مجموعه پیام‌ها و نتایج اجرای آن‌ها را بررسی کند.
این روش به‌ویژه در پرونده‌های مربوط به Jettonهای جعلی، سرقت توکن، Swap و انتقال دارایی از طریق DEX اهمیت دارد.
دعوت به اقدام: اگر در بررسی یک پرونده TON با چند قرارداد و پیام مرتبط روبه‌رو شده‌اید، پیش از نتیجه‌گیری درباره مقصد نهایی دارایی، ساختار Jetton و مالک واقعی قراردادهای دریافت‌کننده را تحلیل کنید.
بلاگ‌ها و مقالات
مشاهده همه
آموزش تحلیل Transaction Logs و Event Logs در بلاکچین؛
تصور کنید در حال بررسی یک پرونده سرقت رمزارز هستید. قربانی اعلام کرده که ۵۰ هزار USDT از کیف پولش خارج شده و شناسه تراکنش را نیز در اختیار شما قرار داده است. وقتی TXID را در یک Blockchain Explorer وارد می‌کنید، با اطلاعاتی مانند فرستنده، گیرنده، زمان، کارمزد و وضعیت تراکنش مواجه می‌شوید. اما یک نکته وجود دارد: آنچه در نمای اولیه Explorer دیده می‌شود، لزوماً تمام اتفاقات داخل تراکنش نیست. یک تراکنش ممکن است با چند قرارداد هوشمند تعامل کند، چندین Token Transfer ایجاد کند و عملیات پیچیده‌ای مانند Swap یا انتقال دارایی به آدرس ثالث انجام دهد. برای بازسازی این رویدادها، تحلیلگر باید از مشاهده سطحی تراکنش عبور کند و وارد بررسی Transaction Receipt، Event Logs و Execution Trace شود.
Peel Chain چیست؟
Peel Chain چیست؟ فرض کنید یک Wallet مقدار قابل توجهی Bitcoin در اختیار دارد و مالک آن نمی‌خواهد تمام موجودی را در یک تراکنش منتقل کند. در عوض چنین الگویی ایجاد می‌شود: Wallet A │ 10 BTC ↓ Wallet B ───→ 0.5 BTC │ 9.5 BTC ↓ Wallet C ───→ 0.7 BTC │ 8.8 BTC ↓ Wallet D ───→ 1 BTC │ 7.8 BTC ↓ Wallet E در هر مرحله مقدار کوچکی از موجودی جدا یا اصطلاحاً Peel می‌شود و بخش عمده به مرحله بعد می‌رود. به این ساختار Peel Chain گفته می‌شود.
چگونه تراکنش‌های DEX و Liquidity Pool را در تحقیقات Blockchain Forensics تحلیل کنیم؟
در یک پرونده ساده Blockchain Forensics ممکن است مسیر دارایی چنین باشد: Victim ↓ Wallet A ↓ Wallet B ↓ Exchange در چنین شرایطی دنبال‌کردن مسیر نسبتاً ساده است. اما کافی است Wallet B با یک صرافی غیرمتمرکز یا DEX تعامل کند. مسیر ناگهان به چیزی شبیه این تبدیل می‌شود: Wallet B ↓ DEX Router ↓ Liquidity Pool ↓ USDT → ETH ↓ Wallet B در این مرحله یکی از اشتباهات رایج این است که تحلیلگر تصور کند وجوه به آدرس Smart Contract منتقل شده و مسیر به پایان رسیده است. در حالی که در بسیاری از موارد، دارایی فقط تبدیل شده است. پژوهش‌های جدید حوزه Blockchain Forensics نیز نشان می‌دهند که گسترش DeFi، Bridgeها و تراکنش‌های پیچیده Smart Contract، ردگیری وجوه را از یک مسئله ساده دنبال‌کردن آدرس‌ها به تحلیل چندلایه جریان ارزش تبدیل کرده است. Doi
چگونه Timeline تراکنش‌های رمزارزی را برای یک پرونده Blockchain Forensics بسازیم؟
در بسیاری از پرونده‌های کلاهبرداری رمزارزی، اطلاعات زیادی وجود دارد اما مشکل اصلی جای دیگری است: رویدادها به ترتیب درست کنار یکدیگر قرار نگرفته‌اند. ممکن است پرونده شامل ده‌ها TXID، چند کیف پول، دو یا سه شبکه بلاکچینی، یک صرافی، یک DEX و تعداد زیادی آدرس واسط باشد. اگر این اطلاعات بدون ساختار ارائه شوند، حتی یک تحلیل فنی درست نیز می‌تواند برای مخاطب گیج‌کننده باشد. یکی از مؤثرترین روش‌ها برای حل این مشکل، ساخت Transaction Timeline است. Timeline به زبان ساده پاسخ می‌دهد: چه اتفاقی، در چه زمانی، برای چه مقدار دارایی و میان چه آدرس‌هایی رخ داده است؟
