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

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

الجواب التقليدي في هذه الصناعة هو جسر (bridge) بوسيط تسلّمه أموالك «ليحتفظ بها مؤقتًا». وهذه الجسور تحديدًا هي التي تُخترق وتُسرق منها مئات الملايين. وهذا غير مقبول لوكيل مستقل: فهو يحتاج إلى تبادل إمّا أن يتم بالكامل، وإمّا أن يستعيد فيه كل طرف أمواله كاملةً — دون وسيط موثوق. وهذا بالضبط ما تحلّه المبادلة عبر السلاسل من TON إلى Ethereum عبر إسكرو HTLC ذرّي. وفيما يلي نفكّك بنيتها من الداخل، بالأدوات الحقيقية لخادم MCP TONNode — بلا احتجاز وبلا سحر.

ما المبادلة عبر السلاسل من TON إلى Ethereum ولماذا هي ذرّية

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

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

ولا يتحقق هذا بالثقة في وسيط، بل بالتشفير والمهل الزمنية — أي بآلية HTLC.

إسكرو HTLC الذرّي بكلمات بسيطة: الهاش والسر والمهلة

HTLC اختصار لـ Hash Time-Locked Contract — أي «عقد مقفل بالهاش وبالوقت». يبدو الاسم معقّدًا، لكن الفكرة مألوفة تمامًا. تخيّل خزنة بنكية بقُفلين:

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

وإليك كيف يحقّق هذا الذرّية عبر شبكتين منفصلتين:

1. على جانب TON يُجمَّد رصيدك من GRAM/USDT في الإسكرو تحت الهاش H.
2. الطرف المقابل (صانع سوق) يرى التجميد، فيعكس الإسكرو نفسه على Ethereum تحت الهاش H ذاته — أي يحجز لك ETH.
3. ولكي تسحب ETH على Ethereum، تكشف السر S. لكن كشف S يجعله علنيًا على البلوكتشين.
4. يرى الطرف المقابل S، وبهذا السر نفسه يسحب أموالك من إسكرو TON.

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

التدفق الكامل في خمس أدوات: quote → build → track → disclose/refund

في TONNode، تبادُل HTLC كله مقسَّم إلى خمس أدوات. وترتيب الاستدعاءات يعيد إنتاج منطق HTLC حرفيًا.

1. get_crosschain_quote — عرض السعر

نبدأ بمعرفة الشروط: كم ستستلم من ETH (أو USDT على Ethereum) مقابل أموالك على TON، مع أخذ السيولة والرسوم في الحسبان. تعيد الأداة سعر الصرف والمبلغ المتوقع عند الخروج وتفاصيل المسار. وهذه عملية قراءة محضة — لا تجمّد شيئًا ولا توقّع شيئًا.

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

هنا تولد الصفقة. تعيد الأداة معاملة غير موقّعة ستجمّد أموالك في إسكرو HTLC تحت هاش السر، وتعيد — على حِدة — السر S نفسه. والنقطة الحاسمة: السر يذهب إليك، ولا يبقى على الخادم. أما المعاملة فتوقّعها محفظتك عبر TonConnect، والخادم لا يلمس التوقيع إطلاقًا. وهذا السر تحديدًا هو ما ستكشفه لاحقًا لإتمام الصفقة — وإن تعثّرت الصفقة، تعود إليك الأموال المجمّدة بانتهاء المهلة، دون كشف السر.

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

بعد أن توقّع معاملة الإسكرو وترسلها، تحتاج إلى معرفة موضع الصفقة الآن: هل جُمِّدت أموالك على TON؟ وهل ظهر الإسكرو المقابل على جانب Ethereum؟ وهل صار كل شيء جاهزًا للتسوية؟ تُظهر track_crosschain_swap المراحل على الشبكتين في آنٍ واحد — فهي نظرتك الموحّدة إلى البلوكتشينين معًا. استدعِها إلى أن تبلغ الصفقة حالة «جاهزة لكشف السر».

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

حين يؤكّد التتبّع أن الطرف المقابل جاهز ومجمَّد على السلسلة، تكشف أنت السر. وهذه هي الخطوة النهائية: الكشف يُطلق التسوية — فتسحب أنت ETH، ويسحب الطرف المقابل بالسر نفسه ما لديك من GRAM/USDT. والمهم أن تستدعيها بعد التحقق من الجاهزية على السلسلة فقط عبر track_crosschain_swap — فكشف السر قبل أوانه يعني تسليم المفتاح قبل أن يمتلئ النصف الثاني من الخزنة.

4b. build_crosschain_refund — استعادة أموالك إن تعثّرت الصفقة

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

والمسار كله بشكل تخطيطي:

get_crosschain_quote      → كم سأستلم
build_crosschain_swap_tx  → معاملة HTLC غير موقّعة + السر (السر لديك)
        ↓ (وقّعتها في المحفظة وأرسلتها)
track_crosschain_swap     → المراحل على TON وعلى Ethereum
   ├─ جاهز على السلسلة →  disclose_crosschain_secret   → التسوية
   └─ معلّق، انتهت المهلة →  build_crosschain_refund      → الاسترداد

وبعد ربط الخادم، يكفي أن تطلب من الوكيل بلغة بشرية عادية — وهو يبني سلسلة الأدوات بنفسه:

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

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

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

وماذا يعني ذلك عمليًا في إسكرو HTLC:

• build_crosschain_swap_tx تعيد معاملة غير موقّعة — وما لم توقّعها أنت بمحفظتك عبر TonConnect، لا يُجمَّد شيء.
• السر S تحتفظ به أنت، لا الخادم. ودون سرّك لا يستطيع أحد إتمام التسوية نيابةً عنك.
• والاسترداد بانتهاء المهلة (build_crosschain_refund) يُجهَّز بدوره كمعاملة غير موقّعة تنتظر توقيعك.
• وحتى المحفظة المولَّدة (أداة generate_wallet) تُسلَّم إليك ولا يبقى منها شيء على الخادم.

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

وللمقارنة: @ton/mcp الرسمي من TON Foundation هو محفظة-وكيل احتجازية تحتفظ بمفتاح المشغّل (operator) وتوقّع بنفسها، وتعمل داخل TON فقط دون أي عمليات عبر السلاسل. والفرق صريح: هناك إنفاق مستقل ثمنه الثقة بمن يحمل المفتاح، وهنا لا احتجاز، مع القدرة على الخروج خارج حدود TON.

الشبكات المدعومة: Ethereum وArbitrum وBase وBNB وPolygon وAvalanche

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

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

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

كيف تربط MCP وتنفّذ أول مبادلة عبر السلاسل

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

محليًا ومجانًا

الإعداد العام، بمجموعة أدوات القراءة كاملةً، يُركَّب بأمر واحد — npx -y @tonnode/mcp:

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

أضف هذا إلى إعدادات عميل MCP لديك (Claude Desktop أو Cursor أو Codex أو أي عميل متوافق مع MCP)، وعندها تصبح أدوات get_crosschain_quote وbuild_crosschain_swap_tx وtrack_crosschain_swap وdisclose_crosschain_secret وbuild_crosschain_refund متاحة للوكيل. وحزمة @tonnode/mcp مفتوحة المصدر (رخصة MIT)، ومنشورة على npm وGitHub (tonnode/mcp)، وتعمل ببروتوكول TON الأصلي ADNL، دون طبقات HTTP وسيطة.

مُستضاف — بمفتاحك الخاص

وللحصول على سعة تمريرية مضمونة، اربط نقطة النهاية المستضافة بمفتاحك الخاص:

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

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

أول مبادلة في دقيقة

1. احصل على مفتاح Hobby المجاني — دون بطاقة، ويُمنح فور تسجيل الدخول.
2. اكتب الإعداد (المحلي أو المستضاف).
3. أعطِ الوكيل الأمر النصي من القسم أعلاه، ووقّع معاملة الإسكرو بمحفظتك.

باختصار

لا يلزم أن يقوم التعامل بين سلاسل مختلفة على الثقة. فإسكرو HTLC الذرّي يمنح ضمانة «الكل أو لا شيء»، وبنية TONNode غير الاحتجازية تضمن ألّا تغادر أموالك ولا مفاتيحك ولا سرّك نطاق سيطرتك في أي لحظة. وخمس أدوات — get_crosschain_quote وbuild_crosschain_swap_tx وtrack_crosschain_swap وdisclose_crosschain_secret وbuild_crosschain_refund — تغطي دورة حياة الصفقة كاملةً، بما فيها الاسترداد الطارئ.

ويمكنك التحقق من ذلك على مبادلة حقيقية مجانًا: احصل على مفتاح Hobby ونفّذ أول مبادلة عبر السلاسل — دون بطاقة بنكية، و60 طلبًا في الدقيقة تكفي وتزيد. أما استعراض الأدوات الـ16 كلها فتجده في صفحة MCP.