مبادلة عبر السلاسل من TON إلى Base: كيف تعمل فعليًا

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

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

وهناك طريق آخر: ضمان HTLC الذرّي. فيما يلي نستعرض كيف تنفّذ مبادلة عبر السلاسل من TON إلى Base بحيث لا يستطيع أي وسيط في أي لحظة أن يمسّ مفاتيحك أو أموالك، وكيف يُستدعى هذا التدفق كاملًا من وكيل ذكاء اصطناعي عبر خمس أدوات MCP في TONNode.

لماذا المبادلة من TON إلى Base، ولماذا هي ليست جسرًا عاديًا

شبكة Base هي طبقة ثانية (L2) فوق Ethereum من Coinbase، مبنية على OP Stack. إليها تهاجر السيولة، وإليها تتّجه بروتوكولات DeFi، وأكثر فأكثر يكون العقد الذي يفترض بوكيلك التعامل معه موجودًا هناك تحديدًا. أما رأس مالك الأصلي فهو على TON — إما بعملة GRAM (وهي Toncoin بعد إعادة تسميته في يونيو 2026؛ أما الشبكة فما زالت تُسمّى TON) أو بـ USDT على TON.

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

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

كيف يعمل ضمان HTLC الذرّي بين TON وBase

اختصار HTLC يعني hashed timelock contract، أي عقد ضمان بشرطَي فتح اثنين: بصمة السرّ (hash) والقفل الزمني (timelock). وأسهل تصوّر له هو خزنتان: واحدة على TON وأخرى على Base. وكلتاهما تُفتحان بالمفتاح نفسه — وهو السرّ. وما دام السرّ لم يُكشف، تبقى الخزنتان مقفلتين.

• قفل البصمة. تُحجَز الأموال على الشبكتين تحت بصمة السرّ نفسها h = hash(s). ولا يمكن فتح الضمان إلا بإبراز السرّ s نفسه الذي تتطابق بصمته.
• القفل الزمني. لكل خزنة مهلة. فإن لم تُنفَّذ الصفقة في وقتها، عادت الأموال إلى صاحبها بعد انتهاء القفل الزمني.

والمخطط بصورة مبسّطة:

1. يُولَّد سرّ عشوائي s وبصمته h = hash(s).
2. تُحجَز أموالك على TON داخل عقد ضمان بشرط: «تُسلَّم لمن يُبرز s؛ وتُعاد إلى المرسِل إن لم يُبرَز s قبل الموعد النهائي».
3. وعلى Base يحجز الطرف المقابل (الـ resolver الذي يوفّر سيولة الوجهة) أمواله تحت البصمة h نفسها — بقفل زمني أقصر.
4. تكشف أنت s لتستلم الأموال على Base. وفي تلك اللحظة يصبح s علنيًا على السلسلة.
5. يرى الطرف المقابل السرّ s المكشوف فيستلم الأموال المحجوزة على TON.

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

وفي مخطط TONNode تكون TON دائمًا هي مصدر الصفقة، بينما Base (أو أي شبكة أخرى مدعومة) هي الوجهة.

الأدوات الخمس للمبادلة عبر السلاسل في TONNode MCP

TONNode هو خادم MCP مُستضاف لشبكة TON يضمّ 16 أداة بالضبط. وMCP (Model Context Protocol) هو المعيار الذي يستدعي عبره وكلاء الذكاء الاصطناعي (Claude وCursor وChatGPT/Codex وأي عميل MCP) أدوات خارجية. أما مجموعة العمل عبر السلاسل فهي 5 أدوات بالضبط، وهي متاحة في جميع الخطط:

• get_crosschain_quote — عرض السعر: كم ستحصل عليه على Base مقابل أموالك من TON، مع مراعاة المسار والأقفال الزمنية.
• build_crosschain_swap_tx — تبني معاملة ضمان HTLC غير موقّعة لشبكة TON وتعيدها مع السرّ. ومحفظة المستخدم هي التي توقّعها عبر TonConnect.
• track_crosschain_swap — تعرض مراحل الصفقة على الشبكتين: هل حُجزت الأموال على TON، وهل حجز الطرف المقابل على Base، وهل كُشف السرّ، وهل اكتملت الصفقة.
• disclose_crosschain_secret — تكشف السرّ لإتمام التسوية، لكن فقط بعد التأكيد على السلسلة من جاهزية الساق المقابلة من الصفقة.
• build_crosschain_refund — تبني معاملة غير موقّعة لاسترداد الأموال من الضمان إن تعطّلت الصفقة وانتهى القفل الزمني.

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

التدفق الكامل: عرض السعر ← التجميع ← التتبّع ← كشف السرّ

أولًا اربط الخادم. محليًا ومجانًا: حزمة @tonnode/mcp مفتوحة المصدر (رخصة MIT)، وتعمل عبر بروتوكول ADNL الأصلي لشبكة TON دون طبقات HTTP وسيطة:

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

وبعد ذلك يجري العمل كله عبر مطالبات (prompts) توجّهها إلى الوكيل، وهو يفكّكها بنفسه إلى استدعاءات أدوات.

الخطوة 1. عرض السعر.

أعطني عرض سعر لمبادلة عبر السلاسل: 200 USDT من TON إلى USDC على Base.
استخدم get_crosschain_quote.

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

الخطوة 2. تجميع المعاملة غير الموقّعة.

جمّع معاملة ضمان HTLC وفق عرض السعر هذا عبر build_crosschain_swap_tx.
عنواني على TON هو EQ…، وعنوان الاستلام على Base هو 0x…

والناتج رسالة TonConnect غير موقّعة تحتوي على ضمان HTLC، إضافة إلى سرّ الصفقة. السرّ ملكك فاحتفظ به؛ والخادم لا يخزّنه. وتُحجَز الأموال في الضمان على TON تحت بصمة هذا السرّ. أما التوقيع فتضعه محفظتك عبر TonConnect — والخادم لا يلمس التوقيع إطلاقًا.

الخطوة 3. التتبّع.

تحقّق من حالة الصفقة عبر track_crosschain_swap بالبصمة h….
هل حجز الطرف المقابل الأموال على Base؟

تعرض الأداة المراحل على الشبكتين. وينتظر الوكيل حتى تصبح أموال الطرفين مقفلة تحت البصمة نفسها.

الخطوة 4. كشف السرّ.

الأموال محجوزة على Base. اكشف السرّ لإتمام التسوية
عبر disclose_crosschain_secret.

لا يكشف الوكيل السرّ إلا بعد أن تؤكّد track_crosschain_swap الجاهزية على السلسلة. والكشف يُنفّذ الضمانَين ذرّيًا: تستلم أنت الأموال على Base، ويغلق الطرف المقابل جانبه على TON اعتمادًا على السرّ العلني. وبذلك تُغلق الصفقة.

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

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

اللااحتجازية: لماذا لا يحتفظ الخادم بمفاتيحك أبدًا

هذه ليست صياغة تسويقية، بل خاصية معمارية. فخادم TONNode لا يوقّع المعاملات أبدًا، ولا يخزّن الأموال أو المفاتيح الخاصة أبدًا. وكل ما يقدّمه للخارج هو رسائل TonConnect غير موقّعة وبيانات (عروض أسعار، وحالات، وسرّ خاص بصفقتك أنت).

ولنفصّل خطوة بخطوة أين يوجد كل شيء:

• المفتاح الخاص لمحفظتك على TON — عندك أنت وحدك، داخل المحفظة.
• السرّ s — يُولَّد عند التجميع ويُسلَّم إليك؛ ولا يبقى على الخادم.
• توقيع معاملة HTLC — تضعه محفظتك عبر TonConnect.
• الأموال على TON — داخل عقد ضمان تحت شرط تشفيري، لا في حساب وسيط.

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

ما الشبكات المدعومة إلى جانب Base (ولماذا TRON غير مدعومة بعد)

TON هي المصدر دائمًا، أما شبكة الوجهة فيمكن أن تكون أيًّا من:

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

شبكة TRON غير مدعومة حتى الآن. والسبب تقني لا أيديولوجي: فضمان HTLC الذرّي يتطلب دلالات متوافقة لأقفال البصمة والوقت، وسلوكًا متوقَّعًا للعقود على جانب الوجهة. فإن كان سيناريو عملك مرتبطًا بـ TRON، فلا تبنِ منطق الوكيل عليه، إذ لا وجود له في مجموعة العمل عبر السلاسل الحالية. وحين نضيفه سينعكس ذلك في خارطة الطريق: tonnode.io/roadmap.

كيف تربط الخادم، وماذا لو تعطّلت الصفقة: الاسترداد

وللإنتاج بسعة تمرير مضمونة تُستخدم النقطة الطرفية المُستضافة بمفتاحك الخاص:

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

والأدوات الـ16 كلها متاحة على جميع المفاتيح، بما فيها مجموعة العمل عبر السلاسل كاملة. وأنت تدفع مقابل سعة التمرير فقط، لا مقابل الوصول إلى الأدوات:

• Hobby — مجانية إلى الأبد، 60 طلبًا/دقيقة. ويُصدَر المفتاح فور تسجيل الدخول، دون بطاقة بنكية.
• Pro — $29 شهريًا، 300 طلب/دقيقة.
• Scale — $199 شهريًا، 1200 طلب/دقيقة.

وماذا لو لم يُتمّ الطرف المقابل الصفقة؟

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

تعطّلت الصفقة وانتهى القفل الزمني. جمّع معاملة استرداد
الأموال من الضمان عبر build_crosschain_refund.

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

من أين تبدأ

المبادلة عبر السلاسل من TON إلى Base تكفّ عن كونها فعل إيمان بجسرٍ ما حين يتولّى مسؤوليتها قفل البصمة والقفل الزمني بدلًا من جهة احتجازية غريبة. خمس أدوات، ولااحتجازية صارمة، وست شبكات وجهة — وكل هذا يستدعيه وكيلك عبر إعداد MCP واحد.

وأسرع طريقة للتجربة هي الحصول على مفتاح Hobby المجاني (يُصدَر فور تسجيل الدخول، دون بطاقة بنكية) وتشغيل تدفق TON إلى Base من وكيلك:

• مفتاح Hobby المجاني ← tonnode.io/dashboard?plan=hobby
• الخطط والأسعار ← tonnode.io/pricing
• الأدوات الـ16 كلها ← tonnode.io/mcp
• خارطة الطريق ← tonnode.io/roadmap