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

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

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

ما مبادلة الكروس-تشين TON → BNB Chain ولماذا يحتاجها الوكيل

مبادلة الكروس-تشين هي تبادل أصلٍ في شبكة بأصلٍ في شبكة أخرى دون سجلّ مشترك بينهما. فـ TON وBNB Chain شبكتان مستقلتان، لكلٍّ منهما آلتها الافتراضية؛ ولا وجود لـ«مصرف» مشترك بينهما يعيد كتابة الأرصدة ببساطة. ومن هنا تأتي الحاجة إلى بروتوكول يزامن تحويلين مستقلين بحيث يصيران غير قابلين للفصل.

في TONNode يسير الكروس-تشين دائمًا من TON بوصفها المصدر إلى شبكة وجهة متوافقة مع EVM — وهي في حالتنا BNB Chain. ولا وجود للاتجاه المعاكس ولا لـ«BNB بوصفها مصدرًا»: فـ TON هي نقطة الانطلاق دائمًا. أنت تقفل GRAM أو جيتونًا على جانب TON، وتستلم الأصل على جانب BNB Chain.

GRAM هو Toncoin بعد إعادة تسميته في يونيو 2026. والشبكة لا تزال تُسمّى TON؛ الاسم الذي تغيّر هو اسم العملة وحده.

ولماذا يحتاج الوكيل إلى ذلك؟ لأن المهام الواقعية نادرًا ما تنغلق داخل شبكة واحدة. فوكيل الخزانة يحتفظ بأموالها بـ GRAM، بينما المورّد يريد الدفع على BNB Chain. وبوت التداول يرى فرصة مراجحة بين DEX على TON وأخرى على BNB. والمساعد ينفّذ تعليمة «حوّل ما يعادل 50 GRAM إلى الطرف المقابل على BSC». وفي كل هذه الحالات نحتاج إلى وسيلة لعبور الحدود بين الشبكات — بصورة حتمية، دون جهة احتجازية ودون تدخّل يدوي.

كيف يعمل إسكرو HTLC الذرّي: السر والتجزئة والمؤقّت

HTLC اختصارٌ لـ Hashed Timelock Contract، أي عقد بقفل تجزئة ومؤقّت. يبدو الاسم معقّدًا، لكن التشبيه بسيط.

تخيّل خزنتين: واحدة في TON وأخرى في BNB Chain. تُقفلان بـالقفل نفسه الذي لا يفتحه إلا مفتاح سرّي واحد — رقم عشوائي هو «السر» S. وما يوضع على البلوكتشين ليس السر نفسه، بل تجزئته H = hash(S) — أشبه ببصمة القفل. فيستطيع أي أحد أن يتحقق من أن المفتاح يناسب القفل، لكن لا سبيل إلى استخراج المفتاح من البصمة.

والخزنة على BNB Chain لا تملؤها أنت: الساق المقابلة يضعها الطرف المقابل — وهو resolver (صانع سوق) يقفل BNB تحت التجزئة H نفسها، على أمل أن يقبض GRAM الخاصة بك على جانب TON بالسرّ ذاته. ولهذا تكون الصفقة متناظرة: كلا الطرفين مقفَل بالقفل نفسه.

ثم يعمل شرطان:

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

والنتيجة هي الذرّية: إمّا أن تُنفَّذ الساقان معًا، وإمّا أن تعودا معًا. أما الحالة الوسطى التي تعطي فيها GRAM ولا تصلك BNB فلا وجود لها فيزيائيًا. ولا طرف ثالث هنا «يضمن» الصفقة — فالضمان تقدّمه رياضيات دالّة التجزئة ومنطق المؤقّتات داخل العقود. وهي الآلية نفسها التي تقوم عليها المبادلات الذرّية ومدفوعات Lightning، لكنها مكيَّفة لتناسب TON وEVM.

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

دورة حياة مبادلة الكروس-تشين في TONNode مغطّاة كاملةً بخمس أدوات MCP. يستدعيها الوكيل بالترتيب — كدرجات سُلَّمٍ لصفقة واحدة.

get_crosschain_quote — التسعيرة

تعيد تسعيرة صفقة TON → BNB Chain: كم تدفع على جانب TON وكم تستلم على جانب BNB Chain. بهذا تبدأ أي مبادلة — إذ يعرض الوكيل الأرقام على المستخدم قبل أن يُقفَل أي شيء.

build_crosschain_swap_tx — تجميع المعاملة + السر

تعيد معاملة إسكرو HTLC غير موقّعة، ومعها السر. والمعاملة توقّعها محفظة المستخدم عبر TonConnect، لا الخادم. أما السر S فيُولَّد هنا ويبقى لدى المستخدم/الوكيل — وبه تُفَكّ الساق الثانية لاحقًا. الخادم ولّد المعاملة والتجزئة، لكن التوقيع وملكية السر يبقيان لدى المستخدم.

track_crosschain_swap — تتبّع المراحل

تُظهر مراحل الصفقة على الشبكتين معًا — على TON وعلى BNB Chain: هل قُفلت الساق على TON، وهل ظهرت الساق المقابلة على BNB Chain، وهل كُشف السر، وهل اكتملت التسوية. وهي عينا الوكيل: فبلا تتبّع لا يعرف متى يكون كشف السر آمنًا ولا متى يحين وقت الاسترداد.

disclose_crosschain_secret — كشف السر

تكشف السر لإتمام التسوية — لكن لا تفعل ذلك إلا بعد التحقق من الجاهزية على السلسلة. فالأداة لا تسلّم S جزافًا: إذ تتأكد أولًا من أن الساق المقابلة على BNB Chain موجودة فعلًا ومن أن الشروط مستوفاة. وهذا يحميك من حالةٍ تكشف فيها السر ثم لا تجد شيئًا تقبضه من الجهة الأخرى.

build_crosschain_refund — الاسترداد من الإسكرو

تجمّع معاملة إعادة الأموال من الإسكرو إذا تعلّقت الصفقة — بعد انتهاء المهلة. وهي أيضًا معاملة غير موقّعة لـ TonConnect. حبل النجاة الذي سنعود إليه في النهاية.

لماذا هذا غير احتجازي: الخادم لا يوقّع ولا يخزّن المفاتيح

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

ولنفصّل ذلك في حالة الكروس-تشين تحديدًا:

• build_crosschain_swap_tx تعيد معاملة بلا توقيع. والتوقيع تضعه محفظة المستخدم — Tonkeeper أو MyTonWallet أو أي محفظة متوافقة مع TonConnect. وما لم يؤكّد المستخدم المعاملة، لا يُقفل شيء.
• السر S يذهب إلى العميل. ولا يستطيع الخادم أن يسحب الأموال من الإسكرو خِلسةً: فذلك يتطلب توقيع المالك، وهو لا يملكه.
• وحتى الاسترداد معاملة غير موقّعة: فالمستخدم هو من يبادر إلى الإرجاع، لا الخادم.

والخلاصة العملية: اختراق الخادم لا يؤدي إلى سرقة الأموال — إذ لا شيء هناك يمكن أخذه: لا مفاتيح، ولا تواقيع، ولا تحكّم في الإسكرو. وأقصى ما يمكن أن «يتعطّل» هو حجب الخدمة (فلا يحصل الوكيل على تسعيرة)، لا ضياع المال.

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

ما الشبكات المدعومة (ولماذا لا وجود لـ TRON بعد)

الكروس-تشين في TONNode يسير دائمًا من TON إلى شبكة وجهة متوافقة مع EVM. والوجهات المدعومة:

• Ethereum
• Arbitrum
• Base
• BNB Chain (حالتنا)
• Polygon
• Avalanche

TRON غير مدعومة بعد. والسبب تقني: يتطلب إسكرو HTLC الذرّي أن تتعامل شبكة الوجهة مع عقود قفل التجزئة والمؤقّت بالطريقة نفسها ضمن بروتوكول الإسكرو المختار. والشبكات الستّ المذكورة متوافقة مع EVM وتنسجم مع هذا النموذج؛ أما TRON — ورغم التشابه الظاهري — فتعمل بنموذجها الخاص وتحتاج إلى تنفيذ إسكرو منفصل. وما دام غير موجود، فلا وجود لـ TRON في القائمة، ونحن لا نقدّم ما نتمنّاه على أنه واقع.

وللزوج الأشهر — TON → Ethereum — تحليل منفصل: مبادلة كروس-تشين من TON إلى Ethereum. الآلية نفسها، ولا يتغيّر سوى شبكة الوجهة.

تشغيل مبادلة TON → BNB خطوة بخطوة عبر MCP

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

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

وهنا توضيح مهم: أدوات الكروس-تشين الخمس غير متاحة عبر npx العام المحلي — فهناك قراءة فقط. صفقة الكروس-تشين تمرّ عبر نقطة نهاية مُستضافة بمفتاح خاص بك، ويكفيها مفتاح Hobby المجاني:

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

وعلى المفتاح المُستضاف تكون الأدوات الـ16 كلها — بما فيها أدوات الكروس-تشين الخمس — متاحة في أي باقة، ابتداءً من Hobby المجانية. فأنت تدفع مقابل السعة التمريرية وحدها (Hobby — مجانًا، 60 طلبًا/دقيقة؛ Pro — 29 دولارًا شهريًا، 300 طلب/دقيقة؛ Scale — 199 دولارًا شهريًا، 1200 طلب/دقيقة). فالكروس-تشين ليس محبوسًا خلف باقة أعلى — لكن npx المحلي لا يصلح له، إذ يلزمه مفتاح مُستضاف.

والآن التشغيل نفسه. يمكن أن يكون الأمر الموجَّه إلى الوكيل بشريًا تمامًا:

«بادِل 50 GRAM من محفظة TON خاصتي إلى BNB Chain على العنوان 0x…. أظهر التسعيرة أولًا، ثم جمّع المعاملة — سأوقّعها بنفسي.»

وما يجري تحت الغطاء:

1. التسعيرة. يستدعي الوكيل get_crosschain_quote (المصدر TON، والوجهة BNB Chain، والمبلغ 50 GRAM) ويُظهر كم سيصل على جانب BNB Chain.
2. التجميع. بعد موافقتك يستدعي الوكيل build_crosschain_swap_tx، فيحصل على معاملة إسكرو HTLC غير موقّعة وعلى السر S. وأنت تؤكّد المعاملة في محفظتك عبر TonConnect. فتُقفل الأموال في الإسكرو على جانب TON تحت التجزئة H.
3. التتبّع. يستدعي الوكيل track_crosschain_swap دوريًا ويراقب المراحل على الشبكتين: هل قُفلت ساق TON، وهل ظهرت الساق المقابلة على BNB Chain (يضعها resolver تحت التجزئة H نفسها).
4. الكشف والتسوية. ما إن يُظهر track_crosschain_swap الجاهزية حتى يستدعي الوكيل disclose_crosschain_secret. فتتحقق الأداة من الجاهزية على السلسلة وتكشف S — فيصير السر مرئيًا في BNB Chain، وتُنفَّذ الساقان، وتصل BNB إلى عنوانك.
5. التأكيد. ويُظهر track_crosschain_swap الأخير أن الجانبين كليهما قد سُوّيا. أُغلقت الصفقة.

وجوهر الأمر أنك ترى حالة الصفقة على الشبكتين في أي لحظة، ولا توقّع إلا ما تراه. وإن كانت الفلسفة العامة لأول نقل للقيمة من TON عبر MCP تهمّك، فهي مشروحة في أول نقل للقيمة عبر السلاسل من TON.

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

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

الأموال ليست مقفلة إلى الأبد. فما إن تنتهي المهلة دون أن تكتمل الصفقة، حتى يستدعي الوكيل build_crosschain_refund ويحصل على معاملة استرداد غير موقّعة من الإسكرو. توقّعها بمحفظتك عبر TonConnect — فتعود GRAM المقفلة إليك. ولا وجود لـ«أموال علقت إلى الأبد»: فهذا ضمان مدمج في العقد نفسه، لا وعدٌ من خدمة.

وقد يكون الأمر الموجَّه إليه هكذا:

«مبادلتي عبر الكروس-تشين إلى BNB Chain لم تكتمل. تحقّق من الحالة، وإن انتهت المهلة فأعِد أموالي.»

سيستدعي الوكيل track_crosschain_swap، ويتأكد من أن التسوية لم تتم ومن أن المهلة قد انقضت، ثم يجمّع الاسترداد عبر build_crosschain_refund ويسلّمك المعاملة لتوقّعها.

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

---

احصل على المفتاح المجاني واربط الكروس-تشين

أدوات الكروس-تشين الخمس جزء من الطقم القياسي المكوّن من 16 أداة — ولا حاجة إلى شرائها إضافيًا. خذ مفتاح Hobby المجاني (60 طلبًا/دقيقة، دون بطاقة، ويُصدَر فور تسجيل الدخول) واربط TONNode بوكيلك: tonnode.io/dashboard?plan=hobby.

وإن أردت أولًا أن تطّلع على الطقم الكامل المكوّن من 16 أداة وعلى بارامتراتها، فصفحة الأدوات هنا: tonnode.io/mcp.

هكذا يكفّ الكروس-تشين من TON إلى BNB Chain عن كونه مسألة «ثِق بالجسر» ويصير استدعاء أداة عاديًا — ذرّيًا وغير احتجازي، ومع ضمان استرداد إذا ساء شيء ما.