مبادلة كروس-تشين من TON إلى Arbitrum: كيف تعمل

مبادلة كروس-تشين TON → Arbitrum: أموال عالقة بين شبكتين

سيناريو كلاسيكي: وكيلك الذكي يحتفظ برصيد في محفظة TON — GRAM أو USDT — بينما العقد الذي عليك دفع قيمته موجود على Arbitrum. هناك الغاز رخيص، وهناك السيولة، وهناك البروتوكول المطلوب. المسار المعتاد يبدو هكذا: تسحب إلى منصة تداول، تنتظر وصول الإيداع، تشتري ETH، تسحبه إلى Arbitrum، وتخسر في الفارق السعري والعمولات — وكل ذلك يدويًا، عبر خدمة احتجازية تسلّمها أموالك «لتحتفظ بها قليلًا». بالنسبة إلى إنسان هذه نصف ساعة من العناء. أما بالنسبة إلى وكيل مستقل فهي جدار مسدود: لا حساب له على منصة تداول، ولا KYC، ولا يجوز له بحكم التعريف أن يأتمن خادمًا غريبًا على مفتاحه الخاص. وفوق ذلك، كل جسر يعني تكاملًا منفصلًا، ونقطة فشل منفصلة، وأخبارًا تتكرر عن «اختراق جسر».

مبادلة الكروس-تشين TON → Arbitrum تحلّ هذه المشكلة تحديدًا: نقل القيمة من TON إلى شبكة أخرى بصفقة ذرّية واحدة، دون تسليم المفتاح الخاص لأحد. وفيما يلي كيف يعمل هذا تحت الغطاء، وكيف تربطه بوكيلك عبر خمس أدوات MCP من TONNode.

لماذا تبادل من TON إلى Arbitrum وما الشبكات المتاحة أيضًا

Arbitrum وجهة L2 شائعة فوق Ethereum: عمولة منخفضة، وبنية DeFi ناضجة، وكثير من البروتوكولات غير الموجودة على TON. الأسباب النمطية للانتقال إلى هناك تحديدًا:

• نقل USDT إلى منظومة يقبله فيها البروتوكول المطلوب؛
• الدخول في مركز على DEX أصلي في Arbitrum أو على بروتوكول عقود دائمة (perp)؛
• الدفع في الشبكة التي يدعمها الطرف المقابل.

في TONNode يدعم الكروس-تشين ست شبكات وجهة:

• Ethereum
• Arbitrum
• Base
• BNB Chain
• Polygon
• Avalanche

قيد مهم يجدر إبقاؤه في الذهن: TON هو المصدر دائمًا. التدفق يسير من TON إلى شبكة EVM، لا العكس. وTRON غير مدعومة حتى الآن — إن كان أحدهم ينتظر USDT-TRC20 مباشرة، فهذا المسار غير موجود، فلا تبنِ عليه منطق وكيلك. وArbitrum هنا مجرد واحدة من ست وجهات؛ وكل ما يرد أدناه صحيح حرفيًا أيضًا للانتقال TON → Ethereum أو TON → Base — لا يتغيّر سوى شبكة الوجهة في التسعيرة.

ما إسكرو HTLC ولماذا المبادلة ذرّية

السؤال الرئيسي في أي تبادل عبر السلاسل: كيف يمكن مبادلة أصل في الشبكة A بأصل في الشبكة B إذا لم يكن للشبكتين «حَكَم» مشترك؟ الخيار الساذج — أن تثق بوسيط — هو بالضبط ذلك الخطر الاحتجازي.

يستخدم TONNode إسكرو HTLC ذرّيًا (Hashed TimeLock Contract — عقد بقفل تجزئة ومؤقّت). والتشبيه: خزنتان، واحدة في كل شبكة، وكلتاهما تُفتَح بالمفتاح السرّي نفسه. ويعمل ذلك عبر خاصيتين:

• قفل التجزئة (hash lock). يُولَّد سرّ عشوائي S، وتُؤخذ منه التجزئة H = hash(S). والخزنتان — الإسكرو على TON والإسكرو على Arbitrum — تُقفلان على هذه التجزئة بشرط «تُسلَّم لمن يقدّم S بحيث يكون hash(S) == H». وما دام السر غير مكشوف، لا أحد يأخذ شيئًا؛ وبمجرد تقديم S على أحد الطرفين يصبح مرئيًا على الطرف الآخر أيضًا.
• المؤقّت (time lock). لكل خزنة مهلة. فإذا لم تتم الصفقة، عادت الأموال إلى مالكها الأصلي بعد انتهاء المهلة.

من هنا جاءت كلمة ذرّية: الصفقة إما أن تتم على الشبكتين معًا (كُشف السر — فنُفِّذ الإسكرو في الطرفين)، وإما ألّا تتم في أي مكان (انتهت المهلة — فحصل الاسترداد في الطرفين). ولا وجود هنا لحالة وسيطة من نوع «خرجت الأموال من TON ولم تصل إلى Arbitrum». هذا ليس جسرًا بمجمّع مشترك قابل للاختراق، بل ربطٌ بين عقدَي إسكرو مستقلَّين يزامنهما سرّ واحد.

تدفق مبادلة الكروس-تشين TON → Arbitrum خطوة بخطوة

التبادل كله خمس أدوات تُستدعى بالترتيب. وكل واحدة منها تؤدي شيئًا واحدًا بالضبط.

1. get_crosschain_quote — التسعيرة

تسأل: كم سأستلم على Arbitrum مقابل X GRAM (أو مقابل X USDT على TON). فتأتيك تسعيرة ثابتة للمسار — السعر، والعمولات، والبارامترات.

2. build_crosschain_swap_tx — معاملة HTLC غير موقّعة + السر

يجمّع الخادم معاملة غير موقّعة تُنشئ الإسكرو على جانب TON، ويسلّمك السر S (وهو المفتاح نفسه الذي يفتح الخزنتين). المعاملة لم تُرسل ولم تُوقّع بعد — توقّعها محفظة المستخدم عبر TonConnect. والسر يبقى عندك؛ وبه تُنهي التسوية لاحقًا.

3. track_crosschain_swap — مراحل الصفقة على الشبكتين

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

4. disclose_crosschain_secret — كشف السر لإتمام التسوية

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

5. build_crosschain_refund — صمّام الأمان

إذا تعلّقت الصفقة، جمّعت هذه الأداة معاملة استرداد الأموال من الإسكرو بعد انتهاء المهلة. ولهذا قسم منفصل أدناه.

مخطط التدفق:

get_crosschain_quote      → تسعيرة TON → Arbitrum
build_crosschain_swap_tx  → معاملة HTLC-tx غير موقّعة + السر  (توقّعها المحفظة)
track_crosschain_swap     → المراحل على TON وعلى Arbitrum
disclose_crosschain_secret→ كشف السر بعد التحقق على السلسلة
build_crosschain_refund   → استرداد إذا تعلّقت الصفقة

ويكفي الوكيلَ عند ذلك أمرٌ بلغة بشرية — فهو نفسه سيختار الأدوات ويستدعيها بالترتيب الصحيح:

بادِل 50 USDT من محفظة TON خاصتي إلى Arbitrum.
أولًا اعرض التسعيرة عبر get_crosschain_quote،
ثم جمّع معاملة إسكرو HTLC عبر build_crosschain_swap_tx
ودعني أوقّعها في المحفظة. بعد ذلك تابع المراحل على الشبكتين
واكشف السر فقط عندما يصبح إسكرو الوجهة جاهزًا على السلسلة.

ولا يطلب الوكيل مفتاحك الخاص في أي خطوة من هذه الخطوات.

غير احتجازي: الخادم لا يوقّع ولا يحتفظ بالمفاتيح

هذا ما يميّز المقاربة من جذورها. تُعيد build_crosschain_swap_tx رسالة TonConnect غير موقّعة — والتوقيع تضعه محفظة المستخدم لا الخادم. الخادم لا يوقّع أبدًا ولا يحتفظ بالأموال ولا بالمفاتيح الخاصة.

وماذا يعني ذلك عمليًا:

• يُسلَّم سرّ الـ HTLC لك في build_crosschain_swap_tx، ولا يبقى على الخادم؛ والكشف يحدث بفعلٍ واعٍ منك عبر disclose_crosschain_secret.
• تبقى الأموال طوال الوقت في إسكرو على السلسلة، لا في محفظة المزوّد.
• وحتى لو أراد الخادم أن «يستولي» على المال — فلا وسيلة لديه: لا مفاتيح عنده، والتوقيع ليس توقيعه، وكشف السر تبادر إليه أنت وحدك.

والقاعدة نفسها تسري على بقية أدوات «الكتابة» في TONNode: المبادلة وgenerate_wallet غير احتجازيتين بصرامة. وللمقارنة — @ton/mcp الرسمي من TON Foundation مبني بطريقة مختلفة: هو محفظة-وكيل احتجازية بنظام split-key، حيث يحتفظ الوكيل نفسه بمفتاح operator ويوقّع به. المقاربة عملية ولها مزاياها (إنفاق مستقل، وNFT، وDNS، والصفة الرسمية)، لكنها احتجازية وتعمل داخل TON فقط — ولا كروس-تشين فيها. ويختار TONNode عن وعي الحلّ المعاكس: التوقيع دائمًا على جانب المستخدم. وتفصيل أوفى عن هذا النموذج للوكلاء في تحليل لماذا يجب أن تكون مبادلة الوكيل غير احتجازية.

ماذا تفعل إذا تعلّقت الصفقة: الاسترداد من الإسكرو

الكروس-تشين شبكتان مستقلتان، وأحيانًا لا ينفّذ الطرف المقابل التزامه: لم يظهر الإسكرو في Arbitrum، أو تعطّلت التسوية. والأموال في هذه الحالة لا تضيع — هي في إسكروك على TON تحت المؤقّت.

تجمّع build_crosschain_refund معاملة استرداد غير موقّعة — أيضًا لتوقّعها بمحفظتك. وبعد انتهاء المهلة تخرج الأموال من الإسكرو عائدةً إلى عنوانك على TON:

الصفقة لم تتم، والإسكرو معلّق.
جمّع معاملة الاسترداد عبر build_crosschain_refund ودعني أوقّعها.

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

قاعدة عملية للوكيل: إذا طال الوقت ولم يُظهر track_crosschain_swap إسكرو وجهة جاهزًا، واقتربت المهلة من الانتهاء — لا تكشف السر، بل استدعِ build_crosschain_refund.

كيف تربط أدوات الكروس-تشين بوكيل ذكاء اصطناعي

أدوات الكروس-تشين الخمس كلها جزء من خادم MCP الخاص بـ TONNode. وMCP (Model Context Protocol) معيار تُستدعى بموجبه الأدوات من Claude وCursor وChatGPT/Codex وأي عميل MCP آخر. ويتم الربط بملف إعداد واحد.

محليًا، بالمجان (إعداد عام، الطقم الكامل لأدوات القراءة):

{
  "mcpServers": {
    "ton": {
      "command": "npx",
      "args": ["-y", "@tonnode/mcp"]
    }
  }
}

التشغيل المحلي المجاني يعطي الطقم الكامل لأدوات القراءة. أما أدوات الكروس-تشين والمبادلة (تجميع الصفقات — build_crosschain_swap_tx، وtrack_crosschain_swap، وdisclose_crosschain_secret، وbuild_crosschain_refund) فتعمل بمفتاح hosted — بما في ذلك مفتاح Hobby المجاني (انظر قسم الباقات أدناه).

Hosted (سعة تمريرية مضمونة، مفتاح خاص بك):

{
  "mcpServers": {
    "ton": {
      "type": "http",
      "url": "https://mcp.tonnode.io/mcp",
      "headers": { "Authorization": "Bearer tn_live_…" }
    }
  }
}

حزمة @tonnode/mcp مفتوحة المصدر (MIT)، وهي على npm وGitHub (tonnode/mcp)، وتعمل ببروتوكول TON الأصلي ADNL دون طبقات HTTP وسيطة.

وتوضيحان تقنيان حتى لا يتعثّر الوكيل. GRAM هو Toncoin بعد إعادة التسمية (تمّت في يونيو 2026)، والشبكة نفسها لا تزال تُسمّى TON؛ فإذا تعامل الوكيل مع «GRAM» في التسعيرة فهو العملة الأصلية ذاتها. ورسوم مفتاح hosted يمكن دفعها بـ GRAM أو USDT على شبكة TON عبر TonConnect، أو بـ BTC/ETH/SOL وعملات أخرى عبر حساب xRocket في Telegram — ويُسلَّم المفتاح تلقائيًا بعد إتمام الدفع.

الباقات وما تشمله

جميع أدوات TONNode الـ16 — بما فيها الخمس الخاصة بالكروس-تشين — متاحة في أي باقة. فأنت تدفع مقابل السعة التمريرية فقط، لا مقابل «فتح» الميزات:

• Hobby — مجانًا إلى الأبد، 60 طلبًا/دقيقة؛
• Pro — 29 دولارًا شهريًا، 300 طلب/دقيقة؛
• Scale — 199 دولارًا شهريًا، 1200 طلب/دقيقة.

ويُسلَّم مفتاح Hobby المجاني فور تسجيل الدخول، ودون بطاقة.

باختصار

مبادلة الكروس-تشين TON → Arbitrum في TONNode هي إسكرو HTLC ذرّي: سرّ واحد يربط خزنتين في شبكتين، ولذلك إما أن تتم الصفقة كاملة، وإما أن تُرجَع بانتهاء المهلة. وخمس أدوات تغطي التدفق كله — التسعيرة، وتجميع معاملة HTLC غير موقّعة مع السر، وتتبّع المراحل على الشبكتين، وكشف السر بعد التحقق من الجاهزية على السلسلة، والاسترداد عند التعثّر — ويبقى الخادم في أثناء ذلك غير احتجازي: لا يوقّع ولا يحتفظ بأموال ولا بمفاتيح. والآلية نفسها تعمل للاتجاهات الأخرى: انظر تحليلَي مبادلة TON → Ethereum وTON → Base، وكذلك لماذا يُعدّ أول نقل للقيمة عبر السلاسل من TON عبر MCP أمرًا مهمًا.

وإن أردت التجربة على وكيل حيّ — احصل على مفتاح Hobby المجاني (كل الأدوات الـ16، بما فيها الكروس-تشين، 60 طلبًا/دقيقة، دون بطاقة) وألقِ نظرة على صفحة الأدوات.