الكريبتو والاختراق — كوابيس القبعات السوداء

غالبًا ما يُصوَّر الكريبتو كحصن من التشفير، والإجماع اللامركزي، والسجلات غير القابلة للتعديل. لكن حقيقة هذه الأرض الرقمية الموعودة أكثر تعقيدًا وخطورة بكثير. تتحدث وسائل الإعلام الرئيسية عن اختراق مجال الكريبتو عادةً عبر حملات الهندسة الاجتماعية أو التصيد الاحتيالي، أو ببساطة عمليات الاحتيال حيث يُدفع مستخدم غير حذر لكتابة عنوان منصة تداول أو مفتاحه الخاص في موقع خبيث.

لكن هذا المقال سيتجاهل تمامًا تلك الإخفاقات البشرية. في هذا المقال، سنتحدث عن الاختراق البحت. هذه هي أرض الأمن السيبراني المنهار والأكواد البرمجية المعيبة بشدة التي تؤدي إلى اختراقات مروعة. هذه هي أحلام "القبعات السوداء" حيث يتم استخدام الكود كسلاح ضد منشئيه، مما يؤدي إلى استنزاف مئات الملايين من الدولارات في دقائق دون إطلاق رصاصة واحدة؛ مما يضعنا أمام أقصى درجات القصور المنطقي، وأخطاء المترجم البرمجي (compiler)، والسهو المعماري.

من أين تنشأ ثغرات العقود الذكية

يتطلب فهم الاختراق البحت للعقود الذكية البدء بشرح لواحدة من أشهر الحالات في تاريخ التمويل اللامركزي (DeFi)، والتي غيرت مسار إيثيريوم للأبد. في الأيام الأولى لسلاسل الكتل القابلة للبرمجة، كان هناك مشروع يسمى "The DAO". كان الهدف من الصندوق أن يكون نوعًا من صناديق رأس المال الاستثماري اللامركزية التي تُدار بالكامل بواسطة العقود الذكية — دون تدخل بشري.

جذب العقد ملايين الدولارات من عملة الإيثر من مستثمرين يأملون في التصويت على المقترحات وكسب المكافآت. ومع ذلك، لم يقم المطورون بتنفيذ عملية السحب بطريقة آمنة، وهو ما يُعرف بخطأ برمجى يسمى "إعادة الدخول" (Reentrancy).

إعادة الدخول (Reentrancy) — يقوم العقد الذكي باستدعاء عقد خارجي ولكنه لا يقوم بتحديث حالته الداخلية. على سبيل المثال — في مشروع "The DAO"، قامت دالة السحب أولاً بتحويل الأموال المطلوبة إلى المستخدم، وفقط بعد ذلك قامت بتحديث حالة المستخدم بالمبلغ المسحوب.

أدرك مخترق "القبعة السوداء" أنه بإمكانه أيضاً نشر عقد ذكي خبيث يتضمن دالة "fallback".

يتم استدعاء دالة الـ fallback كلما أرسلت منظمة The DAO أموالاً إلى هذا العقد الخبيث. لم تكتفِ دالة الـ fallback بقبول الأموال فحسب، بل قامت باستدعاء دالة السحب الخاصة بـ The DAO مرة أخرى على الفور. أدى ذلك إلى تشغيل دالة الـ fallback مرة أخرى، وهو ما نفذته The DAO، حيث لم يكن قد تم تحديث رصيد المخترق مسبقاً في وقت السحب الأول.

تكررت هذه العملية مراراً وتكراراً، مما أدى إلى سحب ملايين الدولارات من منظمة The DAO قبل أن تتمكن الشبكة من الاستجابة.

التداعيات والانقسام الكلي (Hard Fork)

كانت تداعيات هذا الاختراق لا تشبه أي شيء رأيناه من قبل. كانت الشبكة معرضة لخطر الانهيار؛ وسُرقت نسبة كبيرة من إجمالي عملة الإيثر (Ether) الموجودة. خلق هذا أزمة وجودية وتقنية للمجتمع، مما أدى في النهاية إلى قيام المجتمع بتنفيذ انقسام كلي (hard fork) للتراجع عن سجل البلوكشين وإعادة الأموال.

تسبب هذا القرار المثير للجدل في انقسام دائم، مما أدى إلى ظهور إيثيريوم (Ethereum) وإيثيريوم كلاسيك (Ethereum Classic). تُعد هذه الثغرة الأمنية تحديداً معروفة جيداً اليوم، ويتم الحد منها غالباً باستخدام نمط "الفحص-التأثير-التفاعل" (Checks-Effects-Interactions).

ينص هذا النمط على وجوب قيام العقد بالتحقق من جميع الشروط أولاً، وعندها فقط سيكون قادراً على تحديث حالته الداخلية، ويجب ألا يستدعي العقود الخارجية إلا في المرحلة الأخيرة تماماً.

ومع ذلك، ورغم أن هجمات "إعادة الدخول" (reentrancy) الأساسية بات من السهل جداً اكتشافها الآن بواسطة أدوات التدقيق الآلية، إلا أن هجمات إعادة الدخول المعقدة وعبر العقود لا تزال ممكنة في ظروف خاصة ونادرة جداً، مما يظهر أن حتى المفاهيم الراسخة يمكن أن تتحول إلى هجمات جديدة.

عصر المنطق غير المهيأ ونداءات التفويض (Delegate Calls)

استوعب مجتمع المطورين الدروس المستفادة من حادثة "The DAO" بسرعة، ومنذ ذلك الحين طوروا أنظمة تزداد تعقيداً، وربطوا أنفسهم بمفاهيم مثل عقود المكتبات وأنماط الوكيل (proxy patterns) لتوفير رسوم الغاز وتسهيل عملية الترقية. ومع هذا التعقيد، ظهر مسار إضافي للاختراق الصرف، وكان المثال الأكثر شهرة على ذلك هو ثغرات محفظة Parity متعددة التوقيع.

تُعد Parity عميلاً واسع الاستخدام في شبكة إيثيريوم، وقد قدمت عقداً ذكياً لمحفظة متعددة التوقيع يكمن منطقها الأساسي في عقد مكتبة مركزي. كان الهدف من ذلك هو كفاءة استخدام الموارد، حيث ستتمكن العديد من المحافظ من الإشارة إلى نفس المكتبة بدلاً من نشر نفس الكود عدة مرات.

تعود فئة هذه الثغرة إلى سوء فهم دالة delegatecall ومتغيرات الحالة غير المهيأة. تتيح دالة delegatecall للعقد تنفيذ وظيفة من عقد آخر ولكنها تمنح تلك الوظيفة حق الوصول إلى مساحة تخزين العقد المستدعي. وكان يوجد داخل عقد مكتبة Parity وظيفة لتهيئة مالكي المحفظة.

ولكن عقد المكتبة نفسه لم يتم تهيئته فعلياً أبداً.

اكتشف أحد المخترقين أنه بإمكانه استدعاء دالة التهيئة مباشرة في عقد المكتبة، والادعاء بأنه مالك المكتبة. وبعد الاستحواذ على ملكية المكتبة، قام باستدعاء دالة لتدميرها ذاتياً.

تجميد المحافظ متعددة التوقيع

تعطلت المحافظ متعددة التوقيع التي كانت تعتمد على تلك المكتبة فوراً بمجرد تدمير المكتبة. فُقد كل المنطق البرمجي اللازم لمعالجة المعاملات، أو السماح بسحب الأموال، أو حتى مجرد الاستعلام عن الرصيد. وخلال هذه العملية، وبسبب خطأ معماري بحت، لم تُسرق مئات الملايين من الدولارات من عملة الإيثريوم، بل تم تجميدها فعلياً بدلاً من ذلك.

لقد سلط ذلك الضوء على الخطر الشديد للعقود البرمجية غير المهيأة والمخاطر الدقيقة المرتبطة بدوال delegatecall؛ وهي مجموعة من المخاطر التي تبدو اليوم من البديهيات، لكنها لم تكن مفهومة جيداً في ذلك الوقت. ولإصلاح ذلك، يعتمد المطورون الآن على "معدلات تهيئة" (initialization modifiers) خاصة تضمن إمكانية تهيئة العقد مرة واحدة فقط، وغالباً ما يضعون قيماً وهمية في حالة عقد المنطق الخاص بالناشر لضمان عدم تمكن أي شخص من المطالبة بالدفع.

ورغم أن تكرار الموقف نفسه بالضبط مستبعد اليوم، إلا أن الخطر العام المتمثل في سوء إدارة "نمط الوكيل" (proxy pattern) لا يزال أمراً يجب مراعاته بعناية في أي هيكلية تمويل لامركزي رصينة.

السراب التشفيري للجسور العابرة للشبكات

مع انتشار النظام البيئي للعملات الرقمية في أكثر من شبكة بلوكتشين واحدة، ظهر طلب على التوافقية التشغيلية، وهو ما تجلى في الأنواع المختلفة من الجسور العابرة للشبكات. تسمح هذه البروتوكولات بحجز الأصول في شبكة ما وصك تمثيل لها في الشبكة الأخرى.

نظرًا للحجم الهائل من الأصول التي تحتفظ بها، فقد كانت بمثابة "مصائد عسل" يحلم بها مخترقو القبعات السوداء.

ويُعد استغلال جسر Wormhole تذكيرًا مرعبًا حقًا بكيفية تسبب تفصيل صغير تم إهماله أثناء التنفيذ في فشل عملية تحقق تشفيري معقدة ببساطة. سمح Wormhole بنقل الأصول بين شبكتي Solana وEthereum، وكان ذلك يتطلب مجموعة من "الحراس" (guardians) لمراقبة حدث ما على إحدى السلاسل وتوقيع رسالة لإثبات ذلك. ثم يتم التحقق من هذه التوقيعات بواسطة السلسلة المستهدفة قبل صك الرموز المذكورة كرموز جديدة.

كانت نقطة الضعف تكمن في عملية التحقق من التوقيع في عقد Solana الذكي؛ حيث كان يتم التحقق التشفيري بواسطة برنامج مدمج في شبكة Solana يستدعيه العقد. لكن مطوري Wormhole لم يتحققوا من أن البرنامج الذي يتم استدعاؤه هو برنامج النظام الفعلي. كما قام المخترق بإنشاء برنامج يعيد دائمًا رسالة نجاح، بغض النظر عن ماهية المدخلات.

بعد ذلك، تم توجيه عقد Wormhole لاستخدام هذا التطبيق المزيف لعملية التحقق. وبناءً على الافتراض الخاطئ بأن التوقيعات كانت صالحة بالفعل، مضى العقد قدمًا وصك ما قيمته مئات الملايين من الدولارات من الإيثيريوم المغلف (wrapped Ethereum) في شبكة Solana، دون أن يتم حجز أي إيثيريوم فعليًا على الجانب الآخر. ثم قام المخترق بتحويل هذه الرموز المصكوكة حديثًا وغير المدعومة مرة أخرى إلى شبكة Ethereum، مما أدى إلى إفراغ البروتوكول من أصوله الحقيقية.

لقد كان تنفيذًا متقنًا وتقنيًا للغاية استهدف نموذج التحقق من الحسابات في شبكة Solana. وتم إصلاح ذلك من خلال فرض تحقق أكثر صرامة للتأكد من أن غلاف التحقق (verification shell) هو بالفعل عنوان النظام الرسمي المكتوب برمجيًا بشكل ثابت.

كانت التداعيات هائلة، مما استلزم تدخلًا لإنقاذ المشروع من قبل الداعمين له من أجل منع حدوث انهيار نظامي في نظام التمويل اللامركزي (DeFi) في شبكة Solana.

قد تتكرر مثل هذه الثغرة في المستقبل بسبب الخصائص الفريدة لنموذج تطوير العقود الذكية، لا سيما في البيئات التي تعتمد بشكل كبير على نموذج الحسابات مثل شبكة Solana، وذلك إذا لم يقم المطورون بإجراء عمليات تحقق ومصادقة صارمة للحسابات والبرامج لكل كيان خارجي يتم استدعاؤه داخل عقودهم الذكية.

استغلال جسر Nomad

بينما كان هجوم Wormhole هجومًا منسقًا في اتجاه محدد، أثبت استغلال جسر Nomad مدى سهولة أن يؤدي خلل منطقي بسيط إلى ترك البروتوكول غارقًا في فوضى عارمة تشبه حالة "المباح للجميع". ولتنفيذ المراسلة عبر السلاسل (cross-chain messaging)، استخدم Nomad نموذج "التجميع المتفائل" (optimistic rollup) الذي اعتمد على "شجرة ميركل" (Merkle tree) لإثبات صحة الرسالة. وقد ارتكب المطورون خطأً جوهريًا في تهيئة "الجذر الموثوق" (trusted root) عند نشر تحديث للبروتوكول.

حدث هذا لأنهم ضبطوا الجذر الموثوق على "هاش صفري" (zero hash) — وهي القيمة الافتراضية لمتغير غير مهيأ في لغة Solidity. أدى ذلك إلى أن أي رسالة لم يتم التحقق منها صراحةً كانت تعود تلقائيًا إلى الهاش الصفري، والذي أصبح العقد يعتبره الآن جذرًا موثوقًا وصالحًا. وبشكل أساسي، أدرك أحد المخترقين أنه يمكنه إنشاء معاملة تطلب من العقد سحب الأموال، وبما أن إثبات الهاش كان يطابق الهاش الصفري، فإن العقد كان يقبله دائمًا.

كان هذا الاختراق فريدًا من نوعه بسبب بساطته والفوضى العارمة التي أعقبته. فبعد أن قام المخترق الأول بتنفيذ الاستغلال، شارك مستخدمون آخرون في الأمر. لم تكن هناك حاجة لأي قدرات تقنية في الاختراق، بل كان الأمر مجرد نسخ ولصق لمعلومات معاملة المخترق، وتغيير عنوان الوجهة إلى عناوينهم الخاصة، ثم إرسالها إلى الشبكة.

استنزفت مئات الجهات المختلفة جسر Nomad بما يقرب من مائتي مليون دولار في غضون ساعات قليلة.

لقد كان فشلاً نموذجياً في الأمن السيبراني: سطر واحد من كود التهيئة الذي تم تكوينه بشكل خاطئ أدى إلى تجاوز نظام الأمان التشفيري بالكامل. تمت معالجة ذلك من خلال إصلاح منطق تهيئة الجذر الصفري ورفضه صراحةً كجذر صالح. دفع مستخدمو الجسر الثمن، وكان هذا تذكيراً قاسياً بأنه عند تطوير العقود الذكية، يمكن لحرف مفقود أو قيمة افتراضية خاطئة أن تعرض بروتوكولاً بأكمله للخطر فعلياً.

إن تجنب هذه الثغرة تحديداً هو أمر بديهي مع إجراء اختبارات دقيقة، ومع ذلك، لا تزال الفئة الأكبر من أخطاء التهيئة تؤرق الأنظمة بشكل نشط.

ثغرات المترجم والتلاعب بالسوق

أحد أكثر أنواع الاختراقات الصريحة رعباً هو عندما لا يكون الخلل في كود المطور، بل في الأدوات المستخدمة لترجمته. لقد تذكرنا ذلك خلال استغلال Curve Finance الذي أحدث هزات في أسس التمويل اللامركزي (DeFi). وباعتبارها منصة تداول لامركزية (DEX) رائدة للعملات المستقرة، فقد كُتبت معظم عقود Curve الأساسية بلغة Vyper، وهي لغة عقود ذكية شبيهة بلغة بايثون تركز على الأمان والبساطة.

ولحسن الحظ، كان مطورو Curve قد طبقوا حواجز حماية من "إعادة الدخول" (reentrancy guards) في عقودهم الذكية، مما وفر حماية ضد هذا النوع تحديداً من الهجمات التي عصفت بـ The DAO. ولكن داخل إصدار قديم محدد من مترجم Vyper، كانت تلك الثغرة كامنة.

نجح المترجم البرمجي في تحويل كود "فايبر" (Vyper) المفهوم للبشر إلى "كود بايت" (bytecode) قابل للقراءة آلياً ليتم تنفيذه على آلة إيثيريوم الافتراضية، لكنه لم يفلح في توزيع قفل إعادة الدخول (reentrancy lock) بشكل جيد عبر وظائف متعددة.

كان الكود آمناً، حيث كتبه المطورون تماماً كما ينبغي، إلا أن المترجم البرمجي خذلهم وأنتج "كود بايت" يحتوي على ثغرات. وهذا يعني أن أحد مخترقي "القبعات السوداء" لاحظ ذلك وأدرك أن بعض أحواض سيولة "Curve" عرضة لهجمات إعادة الدخول عبر الوظائف، فاستغل هذا الأمر للاستيلاء على عشرات الملايين من الدولارات من تلك الأحواض.

كان هذا الاختراق خبيثاً بشكل خاص لأنه لم تكن هناك طريقة لاكتشافه عبر التدقيق التقليدي للكود المصدري؛ فقد كان الكود المصدري صحيحاً، بينما وجدت الثغرة فقط في "كود البايت" المترجم. دفع هذا الحدث الصناعة بأكملها إلى إعادة النظر في ثقتها بالمترجمات البرمجية والبنية التحتية. وقد تمت معالجة المشكلة من خلال تحديث مترجم "فايبر" وترحيل الأحواض المعرضة للخطر إلى عقود جديدة تم تجميعها بشكل آمن.

وكانت النتيجة أزمة ثقة كبرى وإدراكاً بأن الأمن يجب أن يمتد ليشمل كافة طبقات البنية التقنية. إن أخطاء المترجمات البرمجية نادرة بطبيعة الحال، ولكن من المستحيل تقريباً التنبؤ بها، لذا فإن كابوساً كهذا على مستوى البنية التحتية قد يتكرر بسهولة.

أما القروض السريعة (Flash loans) — وهي نوع جديد من الأدوات المالية التي ظهرت مع تطور التمويل اللامركزي — فقد أحدثت تحولاً جذرياً في طبيعة عمليات الاختراق المحضة. تتيح القروض السريعة للمستخدم اقتراض كمية غير محدودة تقريباً من العملات الرقمية دون الحاجة لتقديم ضمانات، شريطة سداد القرض قبل اكتمال المعاملة نفسها. في حال لم تتم تسوية الأموال، يتم عكس المعاملة بأكملها — وكأنها لم تحدث من الأساس.

وفرت القروض العاجلة (Flash loans)، التي تُستخدم عادةً لأغراض المراجحة أو التصفيات، السيولة اللازمة لمخترقي القبعات السوداء لاستغلال ثغرات منطقية عميقة في آليات السوق. وبالاستعانة باختراق "أويلر فاينانس" (Euler Finance) كدراسة حالة، فقد كان "أويلر" بروتوكول إقراض مخصصاً للإيداعات وتحقيق الأرباح. كما كان بإمكان المستخدمين التبرع بأصولهم المودعة لصالح احتياطيات البروتوكول، وهي دالة تُسمى donateToReserves داخل البروتوكول.

لكن المطورين أغفلوا إجراء فحص سلامة (health check) بالغ الأهمية في تلك الدالة تحديداً؛ إذ لم يتحققوا مما إذا كان الحساب الذي سحب منه المتبرع الأموال سيظل مستوفياً لشروط الملاءة بعد عملية التبرع. اقترض المهاجم كمية كبيرة من الأصول عبر قرض عاجل وأودعها في بروتوكول Euler، ثم استدعى دالة donateToReserves للتبرع بجزء من إيداعه.

وفي غياب فحص السلامة، وافق البروتوكول على التبرع، مما دفع حساب المخترق إلى حالة إفلاس مصطنعة تماماً. قام المخترق لاحقاً بتنفيذ عملية تصفية لحسابه الخاص، ونظراً لأن العمليات الحسابية الكامنة وراء مكافآت التصفية في Euler معقدة، وكان القرض العاجل ضخماً للغاية، انتهى الأمر بالمصفي بالاستحواذ على قيمة من البروتوكول تفوق ما قام بإيداعه.

أعاد المهاجمون القرض العاجل ولاذوا بالفرار بنحو مائتي مليون دولار. لم يكن الأمر فشلاً تشفيرياً أو خطأً في المترجم البرمجي (compiler bug)، بل كان مجرد فشل صريح في المنطق المالي داخل الكود. في هذه الحالة، نسي المطورون ببساطة إدراج سطر برمجى واحد يتحقق من سلامة الحساب بعد إجراء معين. وتألف الإصلاح من توفير فحص السلامة المناسب وإعادة صياغة منطق إدارة المخاطر في البروتوكول بالكامل.

كان لهذا الأمر تداعيات خطيرة، حيث تسبب في توقف البروتوكول واستغرق الأمر شهوراً من المفاوضات لاسترداد جزء من رأس المال.

تمثل مثل هذه الثغرات المنطقية، حيث تتفاعل الآليات المالية المعقدة مع بعضها البعض بطرق غير مقصودة، الشكل الأكثر انتشاراً وخطورة للاختراق الصرف اليوم. ستزداد تعقيدات البروتوكول، ومن المرجح أن يكون تكرار هذا النوع من السهو المنطقي أمراً مؤكداً تقريباً.

صراع مستمر بين البرمجية والتبعات

إذا نظرت إلى الأحداث التاريخية لهذه الاختراقات الضخمة، فسترى نمطاً واضحاً بسهولة. نادراً ما تكون هذه الثغرات ناتجة عن فشل في آليات إجماع البلوكشين الأساسية. بل هي إخفاقات في المنطق البشري المكتوب في برمجية غير قابلة للتغيير. وبغض النظر عما إذا كان الأمر يتعلق بتحديث حالة خاطئ، أو مسار برمجية غير مكتوب لوكيل (proxy)، أو فحص تشفيري تم تجاوزه، أو خطأ في المترجم (compiler)، أو غياب فحص الثبات المالي، فإن المشكلة الأساسية تكمن دائماً في خطأ في تصميم العقد الذكي في المقام الأول.

وللقضاء على هذه المخاطر، يمتلك القطاع نظام دفاع شاملاً، يتضمن ما يلي:

1. عمليات تدقيق برمجية بشرية من طرف ثالث بواسطة شركات أمنية مستقلة. 2. أدوات التحقق الرسمي التي تثبت رياضياً أن البرمجية تعمل تماماً كما هو مخطط لها. 3. مكافآت اكتشاف ثغرات ضخمة جداً تُدفع لمخترقي القبعة البيضاء للعثور على العيوب قبل أن يفعل الأشرار ذلك. 4. استخدام أقفال الإصدار الزمني وضوابط مفاتيح الإدارة متعددة التوقيع لإبطاء نشر أي تحديث خبيث. 5. استخدام بروتوكولات التأمين اللامركزي لتوفير التغطية في حالة حدوث اختراق.

ومع ذلك، لا يزال اختراق القبعة السوداء قائماً، حتى مع زيادة تطور هذه التدابير الدفاعية. إن نقطة الانطلاق في تطوير البرمجيات هي أن التعقيد يخلق فرصاً للفشل.

إن التعقيد المتزايد للتمويل اللامركزي، مع قيام المطورين ببناء بروتوكولات معقدة تدمج العشرات من العقود الذكية الأخرى وتعمل عبر سلاسل كتل متعددة، يخلق مسارات جديدة وغير مسبوقة للهجوم.

وبما أن المهاجمين لا يحدهم سوى خيالهم الخاص، فما عليهم سوى العثور على مسار واحد ناجح لتحقيق هدفهم، بينما يظل الدفاع دائماً في حالة رد فعل ومتأخراً باستمرار. سيكون هذا صراعاً أبدياً حيث يتساجل بناة المستقبل اللامركزي مع مستغليه. ستستمر كوابيس الاختراق الشامل في التحور كذكرى دائمة: في عالم تكون فيه البرمجية هي القانون، يمكن لخطأ مطبعي واحد أن يسلب كل شيء.

ومع كون كل سطر برمجية يستحق حرفياً مئات الآلاف من الدولارات، فإن الكفاءة والدقة في العمليات اليومية لا تقل أهمية عن الأمان لضمان أعلى مستوى من الأداء. يواجه المستخدمون بانتظام أعباء تكاليف الشبكة عند إدارة الأصول الرقمية، وخاصة العملات المستقرة. والآن، كلما قمت بإرسال USDT، إذا كان هذا أمراً تفعله غالباً لتحويل رأس المال، فأنت تعلم أن تكلفة معاملة USDT هذه يمكن أن تتغير بشكل كبير بما يضر برأس مالك.

وبصفتك مشاركاً نشطاً في هذا النظام البيئي، فإن العثور على طريقة تحويل رخيصة لعملة USDT يعد أمراً بالغ الأهمية. وهنا تمنحك أدوات محددة مزايا إضافية. لقد تم إنشاء خدمة netts: حاسبة تحويل USDT لتعزيز هذه التطبيقات تحديداً.

عندما تقوم بتحويل تيذر (Tether) في شبكة TRON، فإنه يستهلك منك بعضاً من الطاقة (Energy) ونطاق التردد (Bandwidth)؛ وإذا لم تكن تمتلك أياً منهما، فستقوم الشبكة بحرق عملات TRX الخاصة بك بناءً على رسوم USDT.

إن أداة التقدير Netts التي تحسب بدقة الطاقة ونطاق التردد المطلوبين مسبقاً تعني أن المستخدمين يمكنهم توفير مبالغ طائلة من خلال استئجار الطاقة بدلاً من حرق TRX، مما يضمن إدارة أصولك بأكبر قدر ممكن من الكفاءة في عالمٍ يمثل فيه كل جزء من الرمز الرقمي أهمية بالغة.