کریپتو و هک — کابوس‌های کلاه سیاه

کریپتو اغلب به عنوان دژی از رمزنگاری، اجماع غیرمتمرکز و دفاتر کل تغییرناپذیر به تصویر کشیده می‌شود. اما حقیقت این سرزمین موعود دیجیتال بسیار پیچیده‌تر و خطرناک‌تر است. رسانه‌های جریان اصلی معمولاً درباره هک فضای کریپتو از طریق مهندسی اجتماعی یا کمپین‌های فیشینگ، یا صرفاً کلاهبرداری‌هایی صحبت می‌کنند که در آن فردی کاربر ناآگاه را وادار می‌کند آدرس صرافی یا کلید خصوصی خود را در یک سایت مخرب وارد کند.

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

منشأ اکسپلویت‌های قرارداد هوشمند کجاست

هک خالص قراردادهای هوشمند برای شروع نیاز به یک توضیح دارد — یکی از بدنام‌ترین موارد در تاریخ دیفای (DeFi) در آن زمان، که مسیر اتریوم را برای همیشه تغییر داد. در روزهای اولیه بلاک‌چین‌های برنامه‌پذیر، پروژه‌ای به نام The DAO وجود داشت. این صندوق قرار بود نوعی صندوق سرمایه‌گذاری خطرپذیر غیرمتمرکز باشد که به طور کامل توسط قراردادهای هوشمند مدیریت می‌شد — بدون هیچ انسانی.

این قرارداد میلیون‌ها دلار اتر از سرمایه‌گذارانی جذب کرده بود که امیدوار بودند به پروپوزال‌ها رأی دهند و پاداش کسب کنند. با این حال، توسعه‌دهندگان فرآیند برداشت را به شیوه‌ای امن پیاده‌سازی نکرده بودند، که منجر به باگی به نام «ورود مجدد» (Reentrancy) شد.

ورود مجدد (Reentrancy) — زمانی رخ می‌دهد که یک قرارداد هوشمند، قراردادی خارجی را فراخوانی می‌کند اما وضعیت داخلی (Internal State) خود را به‌روزرسانی نمی‌کند. برای مثال — در پروژه The DAO، تابع برداشت ابتدا وجوه درخواستی را به کاربر منتقل می‌کرد و تنها پس از آن وضعیت کاربر را با مبلغ برداشت شده به‌روزرسانی می‌کرد.

هکر کلاه سیاه متوجه می‌شود که می‌تواند یک قرارداد هوشمند مخرب با یک «تابع فال‌بک» (fallback function) نیز مستقر کند.

هر زمان که «دِ دائو» (The DAO) پولی به این قرارداد مخرب ارسال می‌کرد، تابع فال‌بک فراخوانی می‌شد. تابع فال‌بک صرفاً وجوه را نمی‌پذیرفت، بلکه بلافاصله دوباره تابع برداشتِ «دِ دائو» را فراخوانی می‌کرد. این کار بار دیگر موجب اجرای تابع فال‌بک می‌شد که «دِ دائو» آن را اجرا می‌کرد؛ چرا که موجودی هکر در زمان اولین برداشت هنوز به‌روزرسانی نشده بود.

این فرآیند بارها و بارها تکرار شد و پیش از آنکه شبکه بتواند واکنشی نشان دهد، میلیون‌ها دلار از «دِ دائو» خارج شد.

پیامدها و هارد فورک

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

این تصمیم جنجالی باعث ایجاد یک شکاف دائمی شد که به پیدایش اتریوم و اتریوم کلاسیک انجامید. این آسیب‌پذیری خاص امروزه کاملاً شناخته شده است و عمدتاً با استفاده از الگوی Checks-Effects-Interactions برطرف می‌شود.

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

با این حال، اگرچه حملات ورود مجدد (Reentrancy) پایه اکنون به راحتی توسط ابزارهای حسابرسی خودکار شناسایی می‌شوند، اما حملات ورود مجدد میان‌قراردادیِ ظریف همچنان می‌توانند در شرایط بسیار خاص و محدود رخ دهند؛ این امر نشان می‌دهد که حتی مفاهیم تثبیت‌شده نیز می‌توانند به حملات جدیدی تغییر شکل دهند.

عصر منطق مقداردهی‌نشده و فراخوانی‌های Delegate Call

درس‌های آموخته‌شده از واقعه The DAO به سرعت توسط جامعه توسعه‌دهندگان جذب شد؛ جامعه‌ای که از آن زمان سیستم‌هایی با پیچیدگی روزافزون توسعه داده و برای صرفه‌جویی در هزینه گس و فراهم کردن مسیری آسان‌تر برای قابلیت ارتقا، به مفاهیمی همچون قراردادهای کتابخانه‌ای و الگوهای پروکسی روی آورده است. در میان این پیچیدگی، بردار جدیدی از هک خالص پدیدار شد که بدنام‌ترین نمونه آن، آسیب‌پذیری‌های کیف پول چندامضایی Parity بود.

پاریتی (Parity) یک کلاینت پرکاربرد اتریوم است و قرارداد هوشمندی برای یک کیف پول چندامضایی ارائه کرده بود که منطق اصلی آن در یک قرارداد کتابخانه‌ای مرکزی قرار داشت. هدف از این کار بهینه‌سازی مصرف منابع بود، زیرا به جای استقرار چندین‌باره یک کد یکسان، بسیاری از کیف پول‌ها می‌توانستند به همان کتابخانه واحد ارجاع دهند.

این دسته از آسیب‌پذیری ناشی از درک نادرست تابع delegatecall و متغیرهای وضعیت مقداردهی‌نشده بود. تابع delegatecall به یک قرارداد اجازه می‌دهد تا تابعی را از قراردادی دیگر اجرا کند، اما به آن تابع دسترسیِ مستقیم به فضای ذخیره‌سازی (Storage) قراردادِ فراخواننده را می‌دهد. در داخل قرارداد کتابخانه‌ای Parity، تابعی برای مقداردهی اولیه مالکان کیف پول وجود داشت.

اما خودِ قرارداد کتابخانه‌ای هرگز در واقع مقداردهی اولیه نشده بود.

یک هکر متوجه شد که می‌تواند تابع مقداردهی اولیه (initialization) را مستقیماً در قرارداد کتابخانه فراخوانی کرده و مدعی مالکیت آن شود. او پس از به‌دست آوردن مالکیت کتابخانه، تابعی را برای خودتخریبی (self-destruct) آن فراخوانی کرد.

مسدود شدن کیف‌پول‌های چندامضایی

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

این اتفاق خطر شدید قراردادهای منطقی مقداردهی‌نشده و ریسک‌های ظریف مرتبط با توابع delegatecall را آشکار کرد؛ مجموعه‌ای از ریسک‌ها که امروزه دانش عمومی به نظر می‌رسند، اما در آن زمان به خوبی درک نشده بودند. برای رفع این مشکل، توسعه‌دهندگان اکنون به اصلاح‌کننده‌های (modifiers) خاص مقداردهی اولیه تکیه می‌کنند که تضمین می‌کند یک قرارداد تنها یک بار مقداردهی شود. همچنین آن‌ها اغلب مقادیر ساختگی (dummy values) را در وضعیت قرارداد منطقی مستقرکننده قرار می‌دهند تا هیچ‌کس نتواند ادعای دریافت وجه کند.

اگرچه وقوع دقیقاً همین موقعیت امروزه بعید است، اما ریسک کلی مدیریت نادرست الگوی پروکسی (proxy pattern) همچنان موضوعی است که باید در هر معماری مناسب در امور مالی غیرمتمرکز با دقت در نظر گرفته شود.

سراب رمزنگاری پل‌های میان‌زنجیره‌ای

با گسترش اکوسیستم کریپتو به بیش از یک بلاک‌چین، تقاضا برای تعامل‌پذیری (interoperability) افزایش یافت که در قالب انواع مختلف پل‌های میان‌زنجیره‌ای ظهور کرد. این پروتکل‌ها اجازه می‌دهند دارایی‌ها در یک زنجیره قفل شده و معادل آن‌ها در زنجیره دیگر ضرب (mint) شود.

به دلیل حجم عظیم دارایی‌هایی که در اختیار داشتند، آن‌ها به «هانی‌پات‌های» (تله‌های عسل) رویایی برای هکرهای کلاه سیاه تبدیل شده بودند.

اکسپلویت پل ورم‌هول (Wormhole) یادآور واقعاً وحشتناکی است از اینکه چگونه نادیده گرفتن یک جزئیات جزئی در پیاده‌سازی می‌تواند باعث شکست کامل یک فرآیند پیچیده تأیید رمزنگاری شود. ورم‌هول امکان انتقال دارایی‌ها را بین شبکه‌های سولانا و اتریوم فراهم می‌کرد. این فرآیند مستلزم آن بود که گروهی از نگهبانان (Guardians) رویدادی را در یک زنجیره زیر نظر بگیرند و برای اثبات آن، پیامی را امضا کنند. سپس این امضاها پیش از ضرب (Mint) توکن‌های مذکور به عنوان توکن‌های جدید، توسط زنجیره مقصد تأیید می‌شدند.

نقطه ضعف در فرآیند تأیید امضا در قرارداد هوشمند سولانا بود. تأیید رمزنگاری توسط یک برنامه داخلی سولانا انجام می‌شد که توسط قرارداد فراخوانی می‌گشت. اما توسعه‌دهندگان ورم‌هول بررسی نکرده بودند که آیا برنامه فراخوانی‌شده واقعاً همان برنامه سیستمی اصلی است یا خیر. هکر نیز برنامه‌ای ساخته بود که صرف‌نظر از ورودی، همیشه پیام موفقیت‌آمیز (Success) برمی‌گرداند.

در مرحله بعد، به قرارداد ورم‌هول دستور داده شد تا از این برنامه جعلی برای اعتبارسنجی استفاده کند. با این فرض اشتباه که امضاها واقعاً معتبر هستند، قرارداد اقدام به ضرب صدها میلیون دلار اتریومِ رپد شده (Wrapped Ethereum) در شبکه سولانا کرد، در حالی که در طرف دیگر عملاً هیچ اتریومی قفل نشده بود. سپس هکر این توکن‌های تازه‌ضرب‌شده و بدون پشتوانه را دوباره به شبکه اتریوم بازگرداند و دارایی‌های واقعی پروتکل را تخلیه کرد.

این یک اجرای تمیز و بسیار فنی علیه مدل اعتبارسنجی حساب در شبکه سولانا بود. این مشکل با اعمال اعتبارسنجی سخت‌گیرانه‌تر برطرف شد تا اطمینان حاصل شود که پوسته تأیید (Verification Shell) واقعاً همان آدرس سیستمی رسمی و هاردکد شده است.

پیامدها بسیار گسترده بود و برای جلوگیری از فروپاشی سیستمی اکوسیستم دیفای سولانا، به کمک مالی اضطراری از سوی حامیان پروژه نیاز بود.

چنین آسیب‌پذیری‌ای ممکن است در آینده به دلیل ویژگی‌های منحصربه‌فرد پارادایم توسعه قراردادهای هوشمند، به‌ویژه در محیط‌های مبتنی بر مدل حساب‌محور (account-model-heavy) مانند سولانا، دوباره تکرار شود؛ مگر اینکه توسعه‌دهندگان، اعتبارسنجی و تایید دقیق حساب‌ها و برنامه‌ها را برای هر موجودیت خارجی که در قراردادهای هوشمندشان فراخوانی می‌شود، انجام دهند.

اکسپلویت پل نوماد (Nomad Bridge)

در حالی که ورم‌هول (Wormhole) یک حمله هماهنگ‌شده در جهتی خاص بود، اکسپلویت پل نوماد ثابت کرد که چگونه یک نقص منطقی ساده می‌تواند پروتکلی را دچار چنان هرج‌ومرجی کند که به یک آشفته‌بازار تمام‌عیار تبدیل شود. نوماد برای پیاده‌سازی این پیام‌رسانی میان‌زنجیره‌ای، از مدل رول‌آپ خوش‌بینانه (optimistic rollup) استفاده می‌کرد که برای اثبات اعتبار پیام به درخت مرکل (Merkle tree) متکی بود. توسعه‌دهندگان هنگام استقرار به‌روزرسانی پروتکل، در مقداردهی اولیه «ریشه مورد اعتماد» (trusted root) مرتکب اشتباهی کلیدی شدند.

این اتفاق به این دلیل رخ داد که آن‌ها ریشه مورد اعتماد را روی «هش صفر» تنظیم کردند؛ یعنی همان مقدار پیش‌فرض برای یک متغیر مقداردهی‌نشده در زبان سولیدیتی. این امر باعث شد هر پیامی که به‌طور صریح اعتبارسنجی نشده بود، به هش صفر ارجاع داده شود که اکنون توسط قرارداد به عنوان یک ریشه مورد اعتمادِ معتبر شناخته می‌شد. در اصل، یک هکر متوجه شد که می‌تواند تراکنشی ایجاد کند که از قرارداد درخواست برداشت وجوه داشته باشد و چون هشِ اثبات (proof) برابر با هش صفر می‌شد، قرارداد همیشه آن را می‌پذیرفت.

این هک به دلیل سادگی و هرج‌ومرج شدیدی که به دنبال داشت، منحصربه‌فرد بود. پس از اینکه هکر اولیه اکسپلویت را انجام داد، سایر کاربران نیز وارد معرکه شدند. هیچ توانایی فنی خاصی برای هک کردن نیاز نبود؛ تنها کافی بود اطلاعات تراکنش هکر کپی و جای‌گذاری شود، آدرس مقصد به آدرس خودشان تغییر یابد و تراکنش در شبکه ارسال شود. صدها عامل مختلف در عرض چند ساعت، نزدیک به دویست میلیون دلار از پل نوماد (Nomad bridge) را تخلیه کردند.

این یک شکست کلاسیک در امنیت سایبری بود: یک خط کد مقداردهی اولیه که اشتباه پیکربندی شده بود و کل سیستم امنیتی رمزنگاری را دور زد. این مشکل با وصله کردن منطق مقداردهی اولیه «ریشه صفر» (zero root) و رد کردن صریح آن به عنوان یک ریشه معتبر، برطرف شد. کاربران این پل بهای آن را پرداختند و این یادآوری تلخی بود که هنگام توسعه قراردادهای هوشمند، یک کاراکتر جا افتاده یا یک مقدار پیش‌فرض اشتباه می‌تواند عملاً کل یک پروتکل را به خطر بیندازد.

اجتناب از این باگ خاص با انجام تست‌های دقیق بسیار ساده است، با این حال، دسته بزرگتری از خطاهای مقداردهی اولیه همچنان گریبان‌گیر سیستم‌ها هستند.

باگ‌های کامپایلر و دستکاری بازار

یکی از هولناک‌ترین انواع هک خالص زمانی است که نقص نه در کد توسعه‌دهنده، بلکه در ابزارهایی است که برای کامپایل کردن آن استفاده شده است. این موضوع در جریان اکسپلویت پروتکل Curve Finance که لرزه بر پیکره دیفای (DeFi) انداخت، به ما یادآوری شد. به عنوان یک صرافی غیرمتمرکز (DEX) پیشرو برای استیبل‌کوین‌ها، بخش بزرگی از قراردادهای اصلی Curve به زبان Vyper نوشته شده بود؛ یک زبان قرارداد هوشمند پایتونیک که بر امنیت و سادگی تأکید دارد.

خوشبختانه، توسعه‌دهندگان Curve محافظ‌های ورود مجدد (reentrancy guards) را در قراردادهای هوشمند خود پیاده‌سازی کرده بودند تا از آن‌ها در برابر دقیقاً همان نوع حمله‌ای که پروژه The DAO را ویران کرده بود، دفاع کنند. اما در یک نسخه قدیمی خاص از کامپایلر Vyper، آن باگ نهفته بود.

کامپایلر با موفقیت کد وایپر (Vyper) که برای انسان خوانا بود را به بایت‌کدی خوانا برای ماشین تبدیل کرد که قرار است در ماشین مجازی اتریوم اجرا شود، اما در توزیع قفل ورود مجدد (reentrancy lock) در چندین تابع عملکرد خوبی نداشت.

کد امن بود، توسعه‌دهندگان آن را دقیقاً همان‌طور که باید می‌نوشتند نوشتند، اما کامپایلر از پشت به آن‌ها خنجر زد و بایت‌کدی دارای آسیب‌پذیری تولید کرد. این بدان معناست که یک هکر کلاه سیاه متوجه شد و دریافت که برخی از استخرهای نقدینگی Curve در برابر ورود مجدد بین‌تابعی (cross-function reentrancy) آسیب‌پذیر هستند. آن‌ها از این موضوع سوءاستفاده کردند تا ده‌ها میلیون دلار از این استخرها خارج کنند.

این هک به‌ویژه از این جهت موذیانه بود که هیچ راهی برای شناسایی آن با حسابرسی سنتی کد منبع وجود نداشت؛ چرا که کد منبع صحیح بود. آسیب‌پذیری تنها در بایت‌کد کامپایل‌شده وجود داشت. این اتفاق کل صنعت را وادار کرد تا در اعتماد خود به کامپایلرها و زیرساخت‌ها تجدیدنظر کنند. این مشکل با به‌روزرسانی کامپایلر Vyper و انتقال استخرهای آسیب‌پذیر به قراردادهای جدیدی که به‌صورت ایمن کامپایل شده بودند، برطرف شده است.

نتیجه این اتفاق، یک بحران اعتماد بزرگ و درک این موضوع بود که امنیت باید تا پایین‌ترین لایه‌های پشته فناوری نفوذ کند. باگ‌های کامپایلر البته نادر هستند، اما پیش‌بینی آن‌ها نیز تقریباً غیرممکن است، بنابراین چنین کابوسی در سطح زیرساخت می‌تواند به‌راحتی دوباره رخ دهد.

وام‌های آنی (Flash loans) — نوع جدیدی از ابزارهای مالی که با توسعه امور مالی غیرمتمرکز پدید آمدند — ماهیت هک خالص را به‌طور اساسی تغییر دادند. وام‌های آنی به کاربر اجازه می‌دهند تا مقدار تقریباً نامحدودی رمزارز را بدون وثیقه دریافت کند، به شرطی که وام پیش از پایان همان تراکنش بازپرداخت شود. در صورتی که وجه تسویه نشود، کل تراکنش معکوس می‌شود - گویی اصلاً اتفاق نیفتاده است.

وام‌های آنی (Flash loans) که معمولاً با هدف آربیتراژ یا لیکوئیدیشن انجام می‌شوند، نقدینگی لازم را برای هکرهای کلاه سیاه فراهم کردند تا از نقص‌های منطقی عمیق در مکانیسم‌های بازار سوءاستفاده کنند. با استفاده از هک «اویلر فایننس» (Euler Finance) به عنوان یک مطالعه موردی، اویلر یک پروتکل وام‌دهی برای سپرده‌گذاری و کسب سود بود. کاربران همچنین می‌توانستند دارایی‌های سپرده‌گذاری شده خود را به ذخایر پروتکل اهدا کنند؛ تابعی که در پروتکل donateToReserves نامیده می‌شد.

اما توسعه‌دهندگان یک بررسی سلامت (health check) بسیار مهم را در آن تابع نادیده گرفتند. آن‌ها نه بررسی کردند که آیا حسابی که اهداکننده از آن پول برداشت کرده، پس از اهدا در وضعیت تراز باقی می‌ماند یا خیر. مهاجم مقدار زیادی دارایی را از طریق یک وام آنی قرض گرفت و آن را در اویلر سپرده‌گذاری کرد. سپس، آن‌ها تابع donateToReserves را برای اهدای بخشی از سپرده خود فراخوانی کردند.

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

نبردی مستمر میان کد و پیامد

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

برای از بین بردن این ریسک‌ها، این صنعت یک سیستم دفاعی جامع دارد. این موارد عبارتند از:

۱. حسابرسی‌های انسانی کد توسط شرکت‌های امنیتی مستقل شخص ثالث. ۲. ابزارهای تایید رسمی (Formal Verification) که به صورت ریاضی ثابت می‌کنند کد دقیقاً طبق برنامه اجرا می‌شود. ۳. پاداش‌های بسیار بزرگ برای کشف باگ (Bug Bounty) که به هکرهای کلاه سفید پرداخت می‌شود تا نواقص را پیش از افراد بدخواه بیابند. ۴. استفاده از قفل‌های زمانی (Time Locks) و کنترل‌های کلید مدیریت چندامضایی (Multi-sig) برای کند کردن روند انتشار به‌روزرسانی‌های مخرب. ۵. استفاده از پروتکل‌های بیمه غیرمتمرکز برای ارائه پوشش در صورت وقوع رخنه امنیتی.

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

پیچیدگی روزافزون امور مالی غیرمتمرکز، که در آن توسعه‌دهندگان پروتکل‌های پیچیده‌ای را با ادغام ده‌ها قرارداد هوشمند دیگر و فعالیت در چندین بلاک‌چین مختلف می‌سازند، مسیرهای جدید و بی‌سابقه‌ای را برای حملات ایجاد می‌کند.

از آنجایی که مهاجمان تنها با تخیل خود محدود می‌شوند و برای موفقیت فقط کافی است یک مسیر نفوذ کارآمد پیدا کنند، بخش دفاعی همواره در حال واکنش نشان دادن و همیشه یک قدم عقب‌تر است. این یک نبرد همیشگی خواهد بود که در آن سازندگان آینده‌ی غیرمتمرکز با سوءاستفاده‌کنندگان از آن جدال می‌کنند. کابوس‌های هک همه‌جانبه به تغییر شکل خود ادامه می‌دهند تا یادآور این نکته باشند: در دنیایی که «کد قانون است»، یک غلط تایپی می‌تواند همه چیز را از بین ببرد.

در حالی که هر خط کد به معنای واقعی کلمه صدها هزار دلار ارزش دارد، کارایی و دقت در عملیات روزمره برای تضمین بالاترین سطح عملکرد، به اندازه امنیت اهمیت دارد. کاربران هنگام مدیریت دارایی‌های دیجیتال، به‌ویژه استیبل‌کوین‌ها، همواره با چالش هزینه‌های شبکه مواجه هستند. اکنون، هر زمان که USDT ارسال می‌کنید، اگر این کاری است که برای انتقال سرمایه به دفعات انجام می‌دهید، می‌دانید که هزینه تراکنش USDT می‌تواند به شکلی تغییر کند که به سرمایه شما آسیب بزند.

به عنوان یک شرکت‌کننده فعال در این اکوسیستم، یافتن روشی ارزان برای انتقال USDT حیاتی است. اینجاست که ابزارهای خاص به شما مزیت‌هایی می‌دهند. سرویس netts: «ماشین‌حساب انتقال USDT» دقیقاً برای تقویت همین کاربردها ایجاد شده است.

وقتی تتر را در شبکه TRON انتقال می‌دهید، این تراکنش مقداری انرژی (Energy) و پهنای باند (Bandwidth) مصرف می‌کند؛ اگر هیچ‌کدام از آن‌ها را نداشته باشید، شبکه بر اساس کارمزد USDT شما، مقداری TRX می‌سوزاند.

تخمین‌گر Netts که میزان دقیق انرژی و پهنای باند مورد نیاز را از قبل محاسبه می‌کند، به این معناست که کاربران می‌توانند با اجاره انرژی به جای سوزاندن TRX، به میزان قابل توجهی صرفه‌جویی کنند و دارایی‌های خود را در فضایی که حتی کوچک‌ترین واحد توکن‌ها نیز اهمیت دارد، به بهینه‌ترین شکل ممکن مدیریت و حفظ نمایند.