چگونه تراکنش‌های DEX و Liquidity Pool را در تحقیقات Blockchain Forensics تحلیل کنیم؟
چگونه تراکنش‌های 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
DEX چیست؟
DEX یا Decentralized Exchange یک صرافی غیرمتمرکز است که معمولاً امکان تبدیل دارایی را بدون سپردن مستقیم دارایی به یک صرافی متمرکز فراهم می‌کند.
در ساده‌ترین حالت:
User
↓
DEX
↓
Token A → Token B
اما در سطح Blockchain ممکن است چندین قرارداد درگیر باشند:
Wallet
↓
Router Contract
↓
Liquidity Pool
↓
Token Contract
↓
Wallet
بنابراین مشاهده یک Contract Address به‌تنهایی اطلاعات کافی درباره اتفاق واقعی نمی‌دهد.
اولین سؤال: Transfer بوده یا Swap؟
فرض کنید Wallet مورد بررسی 100,000 USDT به یک Contract ارسال کرده است.
در نگاه اول ممکن است بنویسیم:
100,000 USDT به آدرس X منتقل شد.
اما اگر X یک DEX Router باشد، این توصیف ناقص است.
ممکن است اتفاق واقعی چنین باشد:
Wallet A
↓
100,000 USDT
↓
DEX
↓
31 ETH
↓
Wallet A
یعنی ارزش از بین نرفته است؛ فقط Asset تغییر کرده است.
در Blockchain Forensics باید جریان ارزش را دنبال کرد، نه فقط نام Token را.
مرحله اول: Transaction Hash را بررسی کنید
تحلیل را از TXID آغاز کنید.
حداقل این اطلاعات را ثبت کنید:
فیلد
مورد بررسی
Sender
ارسال‌کننده
To
مقصد اصلی تراکنش
Token Transfers
انتقال توکن‌ها
Internal Calls
فراخوانی‌های داخلی
Contract
قرارداد درگیر
Input Data
نوع عملیات
Events
رویدادهای ایجادشده
Timestamp
زمان
مشاهده فقط فیلد To می‌تواند گمراه‌کننده باشد.
مرحله دوم: Router را شناسایی کنید
بسیاری از DEXها از Router Contract استفاده می‌کنند.
ساختار ممکن است چنین باشد:
User
↓
Router
↓
Pool
بنابراین Router مالک نهایی وجوه نیست.
این موضوع از نظر گزارش‌نویسی اهمیت زیادی دارد.
نباید صرفاً گفته شود:
«وجوه به آدرس Router منتقل شده است.»
بهتر است عملکرد قرارداد نیز توضیح داده شود.
مرحله سوم: Token In و Token Out را پیدا کنید
مهم‌ترین سؤال در Swap:
چه چیزی وارد شد و چه چیزی خارج شد؟
مثلاً:
Input
100,000 USDT
Output
31.42 ETH
در گزارش می‌توان ثبت کرد:
نوع
دارایی
مقدار
Input
USDT
100,000
Output
ETH
31.42
حالا مسیر جدید باید براساس ETH ادامه پیدا کند.
اشتباه مهم: دنبال‌کردن فقط USDT
فرض کنید پرونده با سرقت USDT آغاز شده است.
تحلیلگر ممکن است دائماً عبارت زیر را جستجو کند:
USDT Transfer
اما مهاجم:
USDT
↓
DEX
↓
ETH
انجام داده است.
در این حالت جستجوی USDT متوقف می‌شود، اما ردگیری ارزش نباید متوقف شود.
مرحله چهارم: Liquidity Pool را بررسی کنید
Liquidity Pool معمولاً شامل دارایی‌هایی است که امکان Swap را فراهم می‌کنند.
برای مثال:
USDT / ETH Pool
کاربر USDT وارد می‌کند و ETH دریافت می‌کند.
از دید Forensic، Pool را نباید مانند یک کیف پول شخصی تحلیل کرد.
Pool ممکن است با هزاران کاربر تعامل داشته باشد.
بنابراین:
Interaction with Pool ≠ Ownership of Pool
این تفاوت در Entity Attribution بسیار مهم است.
مرحله پنجم: Recipient واقعی را پیدا کنید
گاهی خروجی Swap مستقیماً به همان Wallet بازمی‌گردد:
Wallet A
↓
DEX
↓
ETH
↓
Wallet A
اما همیشه این‌طور نیست.
ممکن است:
Wallet A
↓
DEX
↓
ETH
↓
Wallet B
در این حالت باید Wallet B به مسیر Investigation اضافه شود.
Multi-Hop Swap چیست؟
گاهی تبدیل فقط یک مرحله نیست.
مثلاً:
USDT
↓
WETH
↓
USDC
↓
TOKEN X
ممکن است همه این مراحل در یک تراکنش انجام شوند.
اگر تحلیلگر فقط اولین و آخرین Transfer را ببیند، بخش مهمی از ساختار تراکنش از دست می‌رود.
مثال پرونده
فرض کنیم 200,000 USDT سرقت شده است.
مسیر:
Victim
↓
Wallet A
↓
Wallet B
↓
DEX
در DEX:
200,000 USDT
↓
ETH
سپس:
ETH
↓
Wallet C
↓
Bridge
↓
Another Chain
اگر تحلیل در DEX متوقف شود، بخش اصلی مسیر مالی کشف نمی‌شود.
اما با دنبال‌کردن Asset Output می‌توان Investigation را ادامه داد.
Slippage و اختلاف مقدار
فرض کنید ارزش ورودی:
100,000 USDT
است.
خروجی ممکن است دقیقاً معادل 100,000 دلار نباشد.
دلایل مختلفی وجود دارد:
- Trading Fee
- Slippage
- Price Impact
- Gas
- تغییر لحظه‌ای قیمت
بنابراین Amount Matching در DEX نباید صرفاً براساس برابری عددی انجام شود.
آیا DEX باعث ناشناس شدن وجوه می‌شود؟
استفاده از DEX می‌تواند مسیر را پیچیده‌تر کند، اما به‌خودی‌خود به معنی حذف ردپای Blockchain نیست.
تعامل با قرارداد، Token Transferها و Eventها همچنان می‌توانند داده‌های قابل تحلیل ایجاد کنند.
چالش اصلی این است که تحلیلگر باید تفاوت میان:
Address Flow
و
Value Flow
را درک کند.
یک مدل مناسب برای تحلیل DEX
برای هر Swap این پنج مورد را ثبت کنید:
Sender
↓
DEX / Router
↓
Input Asset
↓
Output Asset
↓
Recipient
و سپس:
Recipient
↓
Next Transaction
را بررسی کنید.
گزارش قضایی چگونه نوشته شود؟
به جای عبارت پیچیده:
کاربر با Router Contract و Pair Contract پروتکل تعامل داشته و Eventهای متعدد ایجاد شده است.
می‌توان نوشت:
بررسی تراکنش نشان می‌دهد دارایی مورد بررسی در این مرحله از طریق یک صرافی غیرمتمرکز از USDT به ETH تبدیل شده و دارایی حاصل به آدرس بعدی منتقل شده است.
جزئیات فنی می‌تواند در پیوست گزارش قرار گیرد.
نتیجه‌گیری
در تحقیقات Blockchain Forensics، ورود وجوه به DEX به معنی پایان مسیر نیست.
در بسیاری از موارد فقط شکل دارایی تغییر کرده است:
USDT → ETH
ETH → USDC
USDC → Another Token
تحلیلگر باید به جای دنبال‌کردن صرف یک Token، جریان ارزش را دنبال کند.
این رویکرد مخصوصاً در پرونده‌هایی که شامل DeFi، Bridge و Chain Hopping هستند اهمیت بیشتری پیدا می‌کند. پژوهش‌های جدید Forensics نیز پیچیده‌ترشدن تحلیل در محیط‌های DeFi و چندزنجیره‌ای را مورد توجه قرار داده‌اند.
بلاگ‌ها و مقالات
مشاهده همه
آموزش تحلیل 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 گفته می‌شود.
چگونه Timeline تراکنش‌های رمزارزی را برای یک پرونده Blockchain Forensics بسازیم؟
در بسیاری از پرونده‌های کلاهبرداری رمزارزی، اطلاعات زیادی وجود دارد اما مشکل اصلی جای دیگری است: رویدادها به ترتیب درست کنار یکدیگر قرار نگرفته‌اند. ممکن است پرونده شامل ده‌ها TXID، چند کیف پول، دو یا سه شبکه بلاکچینی، یک صرافی، یک DEX و تعداد زیادی آدرس واسط باشد. اگر این اطلاعات بدون ساختار ارائه شوند، حتی یک تحلیل فنی درست نیز می‌تواند برای مخاطب گیج‌کننده باشد. یکی از مؤثرترین روش‌ها برای حل این مشکل، ساخت Transaction Timeline است. Timeline به زبان ساده پاسخ می‌دهد: چه اتفاقی، در چه زمانی، برای چه مقدار دارایی و میان چه آدرس‌هایی رخ داده است؟
چگونه تراکنش‌های Cross-Chain و Bridge را در بلاکچین ردیابی کنیم؟
در گذشته، ردیابی یک تراکنش رمزارزی معمولاً با دنبال‌کردن مسیر یک آدرس در یک شبکه مشخص انجام می‌شد. برای مثال، اگر وجوه روی شبکه TRON جابه‌جا می‌شد، تحلیلگر می‌توانست از یک Explorer مانند TRONSCAN شروع کند و انتقال‌های بعدی را بررسی کند. اما امروز بسیاری از فعالیت‌های رمزارزی محدود به یک بلاکچین نیستند. یک دارایی ممکن است ابتدا روی Ethereum قرار داشته باشد، سپس از طریق یک Bridge به شبکه دیگری منتقل شود و در نهایت از یک صرافی غیرمتمرکز، کیف پول شخصی یا صرافی متمرکز عبور کند. اینجاست که Cross-Chain Tracing اهمیت پیدا می‌کند. تحقیقات منتشرشده در سال ۲۰۲۶ نیز نشان می‌دهد که تحلیل تراکنش‌های Cross-Chain از تحلیل تک‌زنجیره‌ای دشوارتر است، زیرا اطلاعات مربوط به یک انتقال ممکن است میان زنجیره مبدأ، زنجیره مقصد و حتی سیستم‌های خارج از زنجیره توزیع شده باشد.
