چرا آدرس تتر مسدود می‌شود

وقتی در یک گروه تلگرامی قرار است تتر TRC-20 بپذیرید، «تمیز بودن» یک آدرس فقط به این محدود نیست که همین حالا در فهرست مسدودها نباشد. در شبکهٔ ترون، بخشی از فرایند مسدودسازی تتر پیش از اثرگذاری، روی بلاک‌چین ثبت و برای همه قابل مشاهده می‌شود. این فاصله کوتاه، هم یک نشانهٔ مهم برای پذیرندهٔ پرداخت است و هم دلیلی برای دقت بیشتر: وضعیت امروز یک آدرس، همیشه تمام داستانِ پرداختی را که در راه است نشان نمی‌دهد.

مسدودسازی تتر دقیقاً چیست؟

تتر TRC-20 روی قرارداد TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t در ترون اجرا می‌شود. در این قرارداد، مسدودشدن به معنای ناپدیدشدن موجودی نیست. موجودی آدرس همچنان دیده می‌شود، اما دیگر قابل انتقال نیست. برای معامله‌گری که موجودی را در کیف‌پول می‌بیند ولی نمی‌تواند آن را جابه‌جا کند، همین تفاوت تعیین‌کننده است.

سه تابع دارای اختیار ویژه در این قرارداد، مسیر اصلی را روشن می‌کنند:

addBlackList(address)

این تابع یک آدرس را به فهرست مسدودها اضافه می‌کند. پس از اجرای آن، موجودی تتر آدرس باقی می‌ماند اما انتقال‌پذیر نیست.

removeBlackList(address)

این تابع آدرس را از فهرست مسدودها خارج می‌کند؛ یعنی اثر مسدودسازی را برمی‌دارد.

destroyBlackFunds(address)

این تابع موجودیِ مسدودشده را می‌سوزاند و عرضهٔ کل را کاهش می‌دهد. بنابراین مسدودسازی لزوماً پایان کار نیست: موجودیِ مسدودشده می‌تواند بعداً به‌طور کامل از بین برود.

چه کسی این توابع را اجرا می‌کند؟

این اختیار در دست یک فرد یا یک کیف‌پول عادی نیست. مالک قرارداد تتر، آدرس TBPxhVAsuzoFnKyXtc1o2UySEydPHgATto است: یک قرارداد MultiSigWallet به سبک Gnosis. تنظیم آن ۲ از ۳ است؛ سه امضاکننده دارد و برای اجرای تصمیم، تأیید دو امضاکننده لازم است.

برای یک معامله‌گر عادی، معنای عملی این ساختار ساده است: مسدودسازی یک تصمیم تک‌امضایی و لحظه‌ای نیست. ابتدا یک امضاکننده درخواست را روی زنجیره ثبت می‌کند و همان درخواست، یک شناسهٔ تراکنش می‌گیرد. سپس امضاکنندهٔ دوم آن را تأیید می‌کند. وقتی آستانهٔ ۲ از ۳ کامل شد، فراخوانی ذخیره‌شده خودکار اجرا می‌شود.

در درخواست نخست، دادهٔ فراخوانیِ addBlackList(target) ثبت می‌شود و رخدادهای Submission و Confirmation منتشر می‌شوند. آدرس هدف در این لحظه هنوز مسدود نیست. در تأیید دوم، رخدادهای Confirmation، Execution و در قرارداد تتر AddedBlackList دیده می‌شوند؛ از همان لحظه، وجه مسدود است. در مواردی که فراخوانی داخلی برگردد، رخداد ExecutionFailure ثبت می‌شود؛ در کل تاریخ اندازه‌گیری‌شده، ۳ مورد از این نوع دیده شده است.

یافتهٔ کلیدی: پیش از مسدودسازی، هشدار روی زنجیره وجود دارد

مهم‌ترین یافتهٔ اندازه‌گیری‌های زنجیره‌ای ما این است: در ترون، مسدودسازی تتر پیش از اثرگذاری به‌صورت عمومی روی بلاک‌چین اعلام می‌شود. فاصلهٔ میان ثبت درخواست نخست و اجرای آن، پنجرهٔ هشدار است. در ۹۰ روز آخرِ داده‌ها، میانهٔ این فاصله ۸٫۴ دقیقه بوده است؛ این رقم از اندازه‌گیری‌های زنجیره‌ای خودمان در مرداد ۱۴۰۵، برابر با ۲۰۲۶-۰۸-۰۸، به دست آمده است؛ اما دنبالهٔ آن تا ساعت‌ها ادامه دارد.

این عدد، زمان پخش تراکنش تا قرارگرفتن در بلاک نیست. زمان بلاک ترون ۳ ثانیه است و هر یک از دو تراکنش می‌تواند در بلاک بعدی ثبت شود. فاصلهٔ مهم، فاصلهٔ Submission تا Execution است: تأخیر عملیاتی میان امضای اول و امضای دوم، نه تأخیر فنیِ خود پروتکل.

دلیل وجود این شکاف همان چندامضایی بودن فرایند است. امضاکنندهٔ نخست درخواست را پیشنهاد می‌کند؛ امضاکنندهٔ دوم باید آن را تأیید کند. این سازوکار برای جلوگیری از مسدودسازی یک‌جانبه طراحی شده و بهای آن، فاصله‌ای عمومی میان پیشنهاد و اجراست.

در نمونهٔ ۹۰ روز آخر با ۹۸۹ مسدودسازی، ۱۵٫۲٪ در یک دقیقه، ۳۷٫۷٪ در سه دقیقه، ۵۱٫۱٪ در ۱۰ دقیقه و ۹۸٫۸٪ در ۲۴ ساعت اجرا شده‌اند. کمینه ۳۰ ثانیه، صدک ۹۰ برابر ۴٫۱ ساعت و بیشینه ۷۱٫۸ ساعت بوده است. پس پنجره وجود دارد، اما زمانِ قابل اتکایی برای آن وجود ندارد.

این پنجره برای پذیرش پرداخت چه معنایی دارد؟

اگر پیش از دریافت یا اعتباردادن به یک پرداخت، درخواستِ در انتظارِ addBlackList برای آدرس فرستنده یا مسیر مرتبط با آن دیده شود، آن را یک هشدار عملیاتی بدانید، نه حکم قطعی. آدرس هنوز مسدود نشده است؛ با این حال، درخواست مسدودسازی به‌طور عمومی ثبت شده و ممکن است با تأیید دوم اجرا شود.

برای پذیرندهٔ پرداخت در معاملهٔ P2P یا OTC، این یعنی بررسی مستقیم وضعیت فعلی کافی نیست. باید میان «درخواست مسدودسازی ثبت شده» و «مسدودسازی اجرا شده» فرق گذاشت و تا روشن‌شدن وضعیت، دربارهٔ اعتبار دادن به پرداخت با احتیاط عمل کرد. اعلام «مسدود شده» پیش از Execution هم نادرست است، چون بعضی درخواست‌ها اجرا نمی‌شوند.

این نشانه به‌خصوص برای آدرس‌هایی مهم است که پرداختی از آن‌ها می‌رسد. در یک مورد بررسی‌شده، تنها انتقال تتر در فاصلهٔ میان پیشنهاد تا اجرای مسدودسازی، انتقالی هدفمند بوده است؛ بخشی از موجودی جابه‌جا شد و باقی‌مانده در آدرس مسدود ماند. یک مقصد می‌تواند در بررسی مستقیمِ وضعیت مسدودی، پاک نشان داده شود اما تتر را در همان پنجره از آدرسی دریافت کرده باشد که پیشنهاد مسدودسازی‌اش از قبل روی زنجیره دیده می‌شد.

اگر پرداختی به دلیل مسدودسازی برایتان گیر کرده است، راهنمای عملیِ وقتی تتر مسدود می‌شود چه کار کنیم را بخوانید. این راهنما وعدهٔ بازیابی وجه نمی‌دهد؛ تصمیم نهایی دربارهٔ وضعیت آن موجودی در اختیار سازوکار قرارداد است.

موجودی مسدودشده ممکن است سوزانده شود

نباید مسدودشدن را صرفاً یک محدودیت انتقال تصور کرد. destroyBlackFunds(address) می‌تواند موجودیِ مسدودشده را بسوزاند و عرضهٔ کل تتر را کاهش دهد. بنابراین نه وجودِ موجودیِ قابل مشاهده، و نه گذشت زمان، نشانه‌ای از امکان انتقال یا بازگشت آن نیست.

برای معامله‌گر، نقطهٔ اتکا باید مشاهدهٔ دقیق رویدادهای روی زنجیره باشد: Submission یعنی پیشنهادِ در انتظار، Execution همراه با AddedBlackList یعنی مسدودسازی اجرا شده، و destroyBlackFunds یعنی سوختن موجودیِ مسدودشده. در بازاری که پرداخت‌ها اغلب در گفت‌وگوی تلگرامی نهایی می‌شوند، همین تمایزهای کوچک از یک برداشت سطحی محافظت می‌کند.