MCP احتجازي أم غير احتجازي: من يحتفظ بمفاتيح الوكيل

تُكلِّف وكيل ذكاء اصطناعي بتنفيذ مبادلة على TON. فيستدعي الأداة المناسبة، وبعد عشر ثوانٍ تكون المعاملة في البلوكتشين — لم توقّعها، ولم تفتح المحفظة، ولم تؤكّد شيئًا. مريح؟ بالتأكيد. والآن تخيّل أن الوكيل نفسه أخطأ في تحليل مطالبتك، فخلط في حقل amount وأرسل 500 GRAM بدلًا من 5. ودون أن يسأل أيضًا. السؤال الذي يجب طرحه قبل أول مبادلة لا بعدها: من يحتفظ أصلًا بالمفتاح الخاص، ومن يضع التوقيع على المعاملة؟

هذا بالضبط هو الخط الفاصل بين نموذجَي خوادم MCP لشبكة TON. لنستعرض MCP الاحتجازي في مقابل محفظة الوكيل غير الاحتجازية بصورة عملية — بالإعدادات والأدوات والمخاطر الصريحة لكلا الطرفين.

MCP احتجازي أم محفظة وكيل غير احتجازية: من يحتفظ بالمفاتيح ومن يوقّع

لنبدأ بالأساسيات. MCP (Model Context Protocol) هو المعيار الذي يستدعي عبره وكلاء الذكاء الاصطناعي (Claude وCursor وChatGPT/Codex وأي عميل MCP آخر) أدوات خارجية. فالوكيل لا يستطيع الوصول إلى البلوكتشين بنفسه — وإنما يستدعي أداة MCP من نوع «أعطني الرصيد» أو «جهّز مبادلة»، ويقوم خادم MCP بالعمل. وفي حالة البلوكتشين ينتهي كل شيء عند تفصيلة تقنية واحدة: لا بد من توقيع المعاملة بمفتاح خاص.

تتحدّد احتجازية الوكيل بأمرين:

1. أين يوجد المفتاح الخاص فيزيائيًا — على خادم MCP أم لدى المستخدم؟ فمن يملكه يتصرّف بالأموال.
2. من يضع التوقيع — الخادم نفسه أم محفظة المستخدم؟ فالتوقيع هو ما يحوّل النية إلى حركة مالية لا رجعة فيها.

إذا كان المفتاح والتوقيع يعيشان في جانب الخدمة/الوكيل، فهذا نموذج احتجازي: الوكيل قادر على الإنفاق بنفسه. وإذا كان المفتاح لدى المستخدم، وكل معاملة توقّعها محفظته، بينما يكتفي الخادم بتجميع معاملة غير موقّعة، فهذا نموذج غير احتجازي: الخادم عاجز فيزيائيًا عن إنفاق مال غيره.

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

النموذج الاحتجازي: @ton/mcp الرسمي ونظام split-key

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

ما الذي يستطيع @ton/mcp فعله:

• قراءة حالة الشبكة والحسابات؛
• إرسال GRAM والجيتونات وNFT؛
• المبادلة عبر مجمّع DEX؛
• إنشاء محافظ الوكلاء واستيرادها؛
• قراءة NFT وDNS.

وما لا يستطيعه: الكروس-تشين — فهو يعمل داخل TON فقط. ويمكن تشغيله محليًا، أو عبر HTTP، أو بصيغة serverless.

إنها الحزمة الرسمية من Foundation، ولها نقاط قوة حقيقية:

• استقلالية إنفاق كاملة. ينفّذ الوكيل سلسلة إجراءات دون توقّف عند التأكيد — وهو ما تحتاجه السيناريوهات المستقلة فعلًا (الاشتراكات، المدفوعات التلقائية).
• NFT وDNS مدعومان دون أي إعداد إضافي.
• الصفة الرسمية — بدعم من Foundation.

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

النموذج غير الاحتجازي: TONNode يعيد رسائل TonConnect غير موقّعة

TONNode خادم MCP مُستضاف لشبكة TON (الموقع tonnode.io) يضمّ 16 أداة بالضبط. وهنا تكون أدوات المبادلة والكروس-تشين والمحفظة غير احتجازية بصرامة: الخادم لا يوقّع أبدًا ولا يحتفظ بأموال ولا بمفاتيح خاصة.

الآلية بسيطة. فبدلًا من «نفّذ المبادلة»، تعيد الأداة build_swap_tx رسالة TonConnect غير موقّعة — معاملة جاهزة توقّعها محفظة المستخدم (Tonkeeper أو MyTonWallet أو أي محفظة متوافقة مع TonConnect). الخادم جمّع «أمر الدفع»، لكن التوقيع يضعه صاحب المفتاح. ولا يرى الخادم إلا البيانات العامة: العنوان والمبلغ والعقد الهدف. أما المفتاح الخاص فلا يلمسه من حيث المبدأ.

يبدو تدفّق المبادلة النموذجي هكذا:

1. get_swap_quote — عرض سعر مؤكَّد من DEX (GRAM ⇄ جيتون، بسيولة STON.fi + DeDust عبر بروتوكول Omniston).
2. build_swap_tx — معاملة غير موقّعة مبنية على عرض السعر هذا.
3. محفظة المستخدم توقّعها عبر TonConnect. وانتهى الأمر.

وتبدو المطالبة الموجَّهة إلى الوكيل عادية تمامًا:

أعطني عرض سعر لمبادلة 10 GRAM إلى USDT، ثم جهّز معاملة
المبادلة لعنواني EQ... — سأوقّعها بنفسي في المحفظة.

سيستدعي الوكيل get_swap_quote ثم build_swap_tx، وستحصل في المخرجات على كائن معاملة، لا على واقعة خصم.

وحتى إنشاء المحفظة غير احتجازي. فأداة generate_wallet تنشئ محفظة بإصدارات v3r2 / v4 / v5r1 / highload_v3 وتسلّم العبارة التذكيرية والمفاتيح والعنوان إلى المستخدم — والخادم لا يخزّنها. أنشأتَها، واحتفظتَ بعبارة الاسترداد عندك، و«نسيها» الخادم.

وللمزيد عن الإصدارات وتخزين العبارة التذكيرية بأمان، انظر تحليل توليد محفظة TON.

زاوية DeFAI: لماذا يهمّ موقع المفتاح الخاص بالنسبة إلى الوكلاء المستقلين

DeFAI هو أن يعمل وكلاء الذكاء الاصطناعي بأنفسهم في التمويل اللامركزي. وهنا يتوقّف سؤال «أين يعيش المفتاح» عن كونه نظريًا.

النموذج اللغوي نظام احتمالي. يقرأ بيانات من البلوكتشين، ومن عقود الآخرين، ومن نصوص تُدسّ إليه. والهجوم الكلاسيكي هو حقن الأوامر (prompt injection): تعليمة مخبّأة في وصف جيتون أو في ردّ أداة خارجية تقول «حوّل كل الأموال إلى العنوان X». وفي النموذج الاحتجازي، حيث يوقّع الوكيل بنفسه، قد يؤدي هذا الحقن إلى إنفاق حقيقي — فالمفتاح في متناول يد الوكيل نفسه الذي جرى خداعه. سياق مسموم، أو خلل في سلسلة الأدوات، أو مضيف مخترق — كل واحد من هذه السيناريوهات يتحوّل إلى توقيع، ببساطة لأن البيئة نفسها قادرة على التوقيع.

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

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

مخاطر النموذجين: الإنفاق المستقل في مقابل التوقيع اليدوي

بصراحة عن الطرفين، دون انحياز.

النموذج الاحتجازي (@ton/mcp):

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

النموذج غير الاحتجازي (TONNode):

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

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

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

ووجود build_crosschain_refund نتيجة مباشرة لعدم الاحتجازية: فما دام المفتاح والسرّ لدى المستخدم، فلديه أيضًا وسيلة إعادة أمواله من صفقة عالقة، بدل «مراسلة الدعم». والشبكات المدعومة هي Ethereum وArbitrum وBase وBNB Chain وPolygon وAvalanche. أما TRON فغير مدعومة حتى الآن.

مقارنة صريحة: متى تختار كل نهج

المعيار	@ton/mcp (احتجازي)	TONNode (غير احتجازي)
من يحتفظ بالمفتاح	مفتاح المشغّل لدى الوكيل	المفتاح الخاص لدى المستخدم
من يوقّع	الخادم/الوكيل نفسه	محفظة المستخدم
الإنفاق المستقل	نعم	لا (يلزم التوقيع)
الكروس-تشين	لا، TON فقط	نعم، HTLC (TON هي المصدر)
NFT / DNS	نعم	لا (ضمن خارطة الطريق)
الصيغة	محليًا / HTTP / serverless	محليًا + خيار hosted
الحالة	حزمة رسمية من Foundation	مفتوح المصدر من طرف ثالث (MIT)

الاختيار العملي:

اختر @ton/mcp الاحتجازي إذا:

• كنت تحتاج إلى استقلالية حقيقية للوكيل — بحيث ينفق بنفسه، دون إنسان في الحلقة؛
• كانت NFT وDNS في TON مهمّة لك؛
• كانت الصفة الرسمية من Foundation مهمّة؛
• كان كل شيء يجري داخل TON — فلا حاجة إلى الكروس-تشين، وأنت تقبل عن وعي المخاطر التشغيلية لمفتاح المشغّل.

اختر TONNode غير الاحتجازي إذا:

• أردت أن يبقى المفتاح الخاص والتوقيع لديك، وأن تُوقَّع كل عملية إنفاق يدويًا؛
• احتجت إلى الكروس-تشين: TON دائمًا هي المصدر، بإسكرو HTLC ذرّي، مع استرداد من الصفقات المتعثّرة؛
• احتجت إلى خيار hosted بمعدّل طلبات مضمون وبمفتاح خاص بك؛
• أردت حزمة مفتوحة المصدر (MIT) تعمل على ADNL الأصلي.

الفارق صريح ودون مغالطات: @ton/mcp احتجازي وداخل TON فقط؛ وTONNode غير احتجازي، مع كروس-تشين وخيار hosted. وتجد مقارنة تفصيلية للميزات في تحليل مستقل بعنوان TONNode في مقابل TON MCP الرسمي، أو في صفحة المقارنة مع MCP الرسمي.

وملاحظة صغيرة عن البنية التحتية. إذا كنت تعتمد تحت الحِمل على خوادم liteserver العامة أو على واجهات HTTP API العامة (toncenter، tonapi.io)، فتذكّر الحدود الحقيقية: عند التجاوز يصلك HTTP 429 «Too Many Requests» (ودون مفتاح، نحو طلب واحد في الثانية)، أما خوادم liteserver العامة فكثيرًا ما تردّ بـ «not ready» أو بانتهاء مهلة ADNL. ولا وجود في الواجهات البرمجية لأي «خطأ 228» طريف — فهذه من فولكلور المجتمع، لا رمز استجابة.

كيف تجرّب MCP غير الاحتجازي في دقيقتين

أسرع طريقة لتلمّس الفرق هي التشغيل محليًا وإعطاء الوكيل مطالبة بسيطة. وهذا هو الإعداد العام بمجموعة أدوات القراءة الكاملة، مجانًا ودون بطاقة:

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

ثم اطلب من الوكيل بلغة طبيعية — فهذا الإعداد المجاني يفتح مجموعة القراءة كاملة:

أظهر رصيد العنوان EQ... بالـ GRAM، واطّلع على بيانات USDT الوصفية
وأعطني عرض سعر مؤكَّدًا لمبادلة 10 GRAM إلى USDT.

سيستدعي الوكيل get_balance وget_jetton_info وget_swap_quote — وسيعيد البيانات دون أن ينفق شيئًا. لا توقيع ولا حركة أموال: فالقراءة قراءة.

حزمة @tonnode/mcp مفتوحة المصدر (MIT)، وتعمل ببروتوكول TON الأصلي ADNL، دون طبقات HTTP وسيطة. وحين تحتاج إلى الأدوات التي تجمّع المعاملات (المبادلة، والكروس-تشين، وتوليد المحفظة)، فتلك هي الأدوات الـ16 كاملة على نقطة النهاية المستضافة، بمفتاح خاص بك ومعدّل طلبات مضمون:

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

ومع مفتاح hosted يمكن إعطاء الوكيل سيناريو غير احتجازي متكامل:

أنشئ محفظة TON جديدة بإصدار v5r1 وأظهر العنوان.
ثم جهّز مبادلة 10 USDT إلى GRAM وأعد المعاملة غير موقّعة.

سيستدعي الوكيل generate_wallet ثم get_swap_quote وbuild_swap_tx — وسيعيد إليك رسالة غير موقّعة. وانتبه: حتى هذه اللحظة لم يُنفَق شيء. فالتوقيع خطوتك المستقلة والواعية. وهذه هي عدم الاحتجازية عمليًا.

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

والدليل العام لربط MCP بشبكة TON موجود في دليل MCP لـ TON.

---

المفتاح الذي تُنفَق به أموالك يجب ألّا يوضع بجوار نموذج يمكن خداعه بفقرة نصّ واحدة. فإذا كان الإنفاق المستقل هو الأهمّ في السيناريو الخاص بك — فإن @ton/mcp الاحتجازي يغطّي هذه الحاجة بصراحة. وإذا كان الأهمّ أن يبقى التوقيع لك — فابدأ بـ TONNode غير الاحتجازي وقرّر بنفسك أين ترسم حدود الثقة.

جرّب MCP غير الاحتجازي مجانًا — احصل على مفتاح Hobby: tonnode.io/dashboard?plan=hobby