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

لماذا يحتاج الوكيل إلى نقل القيمة من TON إلى Avalanche

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

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

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

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

الآلية الجوهرية هي ضمان HTLC الذرّي (hashed timelock contract، أي عقد ضمان بقفل زمني قائم على التجزئة). يبدو الاسم ثقيلًا، لكن الفكرة بسيطة، وأسهل شرح لها هو التشبيه بصندوق الأمانات في البنك.

تضع أموالك في صندوق لا يُفتح إلا بالمفتاح الصحيح — وهو السرّ. وللصندوق مؤقّت: إن لم يُدخَل المفتاح خلال المدة المحددة، عادت المحتويات إلى صاحبها. تخيّل الآن صندوقين من هذا النوع — واحدًا على TON وآخر على Avalanche — وأغلقهما بالقفل نفسه:

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

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

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

أدوات العمل عبر السلاسل الخمس: quote, build, track, disclose, refund

في TONNode، يُغطّى العمل عبر السلاسل بـخمس أدوات MCP بالضبط، تتكفّل كل واحدة منها بمرحلة واحدة من الصفقة:

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

خمس أدوات ليست عددًا «قليلًا». إنها بالضبط الخطوات الخمس التي تتألف منها المبادلة الذرّية فعليًا: التسعير، والإيداع، والمتابعة، والتسوية، والاسترداد عند الفشل. لا أداة زائدة ولا أداة ناقصة.

اللااحتجازية: الخادم لا يوقّع ولا يخزّن المفاتيح

هذه ليست صياغة تسويقية بل قيد معماري. فأدوات العمل عبر السلاسل والمبادلة والمحفظة في TONNode غير احتجازية بصرامة:

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

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

قارن ذلك بالنموذج الاحتجازي حيث يمسك المشغّل بالمفتاح ويوقّع بنفسه. للنموذجين معًا حقّ الوجود — وقد فصّلنا هذا الحدّ في مقال MCP الاحتجازي وغير الاحتجازي وفي تحليل المبادلة غير الاحتجازية للوكيل.

ما الشبكات المدعومة (ولماذا تكون TON دائمًا شبكة المصدر)

الشبكات الهدف للعمل عبر السلاسل هي: Ethereum وArbitrum وBase وBNB Chain وPolygon وAvalanche. أما TRON فغير مدعومة حتى الآن — لا تبنِ عليها أي عملية.

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

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

سيناريو خطوة بخطوة: مبادلة GRAM → Avalanche

لنجمع كل ما سبق. فيما يلي الترتيب الحقيقي للاستدعاءات؛ يمرّ الوكيل به بنفسه، ويكفيك أنت توقيع المعاملة في محفظتك.

الخطوة 1. عرض السعر. يطلب الوكيل السعر:

«أعطني عرض سعر عبر السلاسل: 500 GRAM من TON إلى USDC على Avalanche.»

خلف الكواليس تعمل get_crosschain_quote. يرى الوكيل المبلغ الناتج والمسار ومعاملات الأقفال الزمنية. وإن كان السعر مناسبًا، ننتقل إلى ما بعده.

الخطوة 2. تجميع معاملة ضمان HTLC.

«مناسب. جمّع المعاملة وفق عرض السعر هذا إلى عنواني على Avalanche 0x… وأعد لي رسالة TonConnect غير الموقّعة وتجزئة السرّ.»

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

الخطوة 3. متابعة الضمان المقابل.

«تابع الصفقة عبر track_crosschain_swap إلى أن يظهر على Avalanche ضمان مقابل يحمل تجزئتي.»

تعرض track_crosschain_swap المراحل على الشبكتين. ننتظر حتى يودِع صانع السوق الأصل الهدف في ضمانه على Avalanche تحت التجزئة H نفسها. وما دام الضمان المقابل غير موجود، فكشف السرّ ممنوع.

الخطوة 4. كشف السرّ وإتمام التسوية. حين تؤكّد المتابعة الجاهزية على السلسلة:

«الضمان المقابل موجود. تحقّق من الجاهزية على السلسلة واكشف السرّ عبر disclose_crosschain_secret.»

تتحقق disclose_crosschain_secret أولًا من الجاهزية (وجود الضمان المقابل، وتطابق المبالغ والتجزئة)، ثم تكشف السرّ. وهو يفتح الضمانين معًا: تحصل أنت على USDC على Avalanche، ويسحب الطرف المقابل GRAM من ضمان TON بالسرّ S نفسه. وبذلك تُغلق الصفقة ذرّيًا.

الخطوة 5 (عند الفشل فقط). الاسترداد. إن لم يظهر الضمان المقابل وتعطّلت الصفقة، فلا نكشف السرّ. ننتظر انقضاء المهلة ونستدعي build_crosschain_refund:

«تعطّلت الصفقة وانقضت المهلة. جمّع معاملة الاسترداد عبر build_crosschain_refund.»

تجمّع الأداة معاملة تعيد GRAM من ضمان TON إليك؛ ويوقّعها المستخدم بمحفظته. وخسارة الأموال بسبب طرف مقابل متعطّل مستحيلة بحكم التصميم — فالقفل الزمني يحميها.

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

ربط خادم MCP وما التالي

لنوضّح مفترقًا مهمًا فورًا كي لا تضيّع وقتك. حزمة @tonnode/mcp مفتوحة المصدر (رخصة MIT، على GitHub باسم tonnode/mcp)، وتعمل عبر بروتوكول ADNL الأصلي لشبكة TON دون طبقات HTTP وسيطة. وتشغيلها محليًا بالإعداد العام يمنحك مجموعة القراءة كاملة (8 أدوات قراءة: الرصيد، وحالة الحساب، والمعاملات، وطرق get وغيرها) — وهذا يكفي لقراءة TON، لكن لا وجود فيها للمبادلة ولا للعمل عبر السلاسل ولا للمحفظة. وهذا هو الإعداد المحلي لعميل MCP (Claude أو Cursor أو Codex أو أي عميل متوافق مع MCP):

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

أما أدوات العمل عبر السلاسل الخمس الواردة في هذا المقال (وكذلك المبادلة وتوليد المحفظة) فلا تعمل إلا عبر النقطة الطرفية المُستضافة mcp.tonnode.io بمفتاح Bearer. ومفتاح Hobby مجاني ويُصدَر فور تسجيل الدخول دون بطاقة بنكية (60 طلبًا/دقيقة)، لكنه مفتاح مُستضاف بالتحديد، لا npx محلي مجرّد. وإليك إعداد خط أنابيب العمل عبر السلاسل:

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

وبضع حقائق تزيل الأسئلة:

• في TONNode 16 أداة إجمالًا. وجميع الأدوات الستّ عشرة متاحة على كل الخطط — أنت تدفع مقابل سعة التمرير فقط، لا مقابل «فتح ميزات». والفرق بين الإعدادين أعلاه ليس في المجموعة بل في نقطة الاتصال: npx المحلي يمنح القراءة فقط، أما النقطة الطرفية المُستضافة بمفتاح فتفتح المجموعة كاملة، بما فيها أدوات العمل عبر السلاسل الخمس.
• GRAM هو Toncoin بعد إعادة تسميته في يونيو 2026. والشبكة ما زالت تُسمّى TON؛ لم يتغيّر سوى اسم العملة.
• مفتاح Hobby المجاني — 60 طلبًا في الدقيقة، دون بطاقة بنكية، وهذا يكفي لتشغيل خط أنابيب العمل عبر السلاسل كاملًا.

ما التالي

إن كان وكيلك يعيش على TON بالفعل وتحتاج إلى إيصال القيمة إلى Avalanche (أو Ethereum أو Base أو Arbitrum أو BNB Chain أو Polygon)، فركّب السلسلة get_crosschain_quote → build_crosschain_swap_tx → track_crosschain_swap → disclose_crosschain_secret واحتفظ بـbuild_crosschain_refund بوصفها وثيقة تأمين. أما لماذا يُستحسن أصلًا إنجاز العمل عبر السلاسل من TON عبر MCP لا عبر منصة تداول، فقد تناولناه على حدة في هذا المقال.

احصل على مفتاح Hobby المجاني واربط أدوات العمل عبر السلاسل الآن: tonnode.io/dashboard?plan=hobby. لا حاجة إلى بطاقة بنكية، و60 طلبًا/دقيقة تكفي لتشغيل خط الأنابيب كاملًا ورؤية HTLC الذرّي وهو يعمل.

لمعاينة الأدوات الستّ عشرة كلها — صفحة الأدوات. ولمعرفة ما هو قيد العمل تاليًا — خارطة الطريق.