لايت-سيرفر TON يردّ not ready: السبب وكيف تُزيل الخطأ

لايت-سيرفر not ready: أرسلت طلبًا بسيطًا — فجاءك الردّ «not ready»

تكتب وكيلًا يُفترض به أن يتحقّق من رصيد محفظة أو أن يستدعي get-method لعقد ما. الكود سليم، والعنوان سليم، وإعداد اللايت-سيرفر مأخوذ من global-config.json الرسمي. لكنك بدلًا من الإجابة تتلقّى بانتظام إمّا not ready وإمّا لا شيء إطلاقًا — يظلّ الاتصال معلّقًا ثم ينقطع بمهلة ADNL. والأنكى أن الأمر لا يتكرّر دائمًا: في الصباح يعمل، وتحت الحمل لا يعمل. مألوف؟ هذه ليست علّة في كودك، ولا هي «TON معطّلة». هذا سلوك متوقَّع تمامًا للايت-سيرفرات العامة من الإعداد العالمي. لنفهم لماذا يظهر TON liteserver not ready، وما الذي يفيد فعلًا على جانب العميل وما الذي لا يفيد.

ماذا يعني «not ready» ومهلة ADNL في لايت-سيرفر TON

not ready ردٌّ مباشر من اللايت-سيرفر: «لم أُزامِن بعد، لا أستطيع أن أجيبك». في TON مستويان للبلوكتشين: الماستر-تشين (masterchain) والـ basechain (وركتشين 0) الذي ينقسم إلى شارد-تشينات/شاردات (shardchains). الماستر-تشين أشبه بفهرس الكتاب، والشاردات هي الفصول نفسها بما فيها من معاملات وحالات حسابات. وكثيرًا ما تستقبل العقدة رأس الماستر-تشين قبل أن تلحق بكتل الشارد المقابلة. في تلك اللحظة يسبق الماستر-تشين الـ basechain، بينما حالة الحساب تعيش في آخر كتلة شارد — فلا سبيل للتحقّق منها بعد. فتردّ العقدة بصدق not ready بدل أن تسلّمك بيانات قديمة أو ناقصة.

ومهلة ADNL عَرَضٌ مجاور للعلّة نفسها. وADNL هو بروتوكول النقل الأصلي في TON الذي يتخاطب به اللايت-سيرفر مع العميل (لا وجود لـ HTTP هناك إطلاقًا). فحين تُثقَل العقدة، لا تردّ على طلب ADNL ضمن النافذة المتاحة، فيسقط العميل بمهلة زمنية قبل أن يبلغ منطق العمل أصلًا.

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

لماذا تسقط اللايت-سيرفرات العامة من الإعداد العالمي تحت الحمل

جذر المشكلة عاديّ جدًّا. فاللايت-سيرفرات في ton.org/global-config.json مشتركة ومحدودة. إنه مورد عام يقصده في الوقت نفسه آلاف المطورين والبوتات والمفهرِسات والوكلاء من العالم كلّه. ولمثل هذا المورد ثلاثة قيود بنيوية:

• حمل مشترك. أنت تتقاسم المجمّع مع المنظومة بأسرها. وعند الذروة فإمّا ألّا تلحق العقدة برأس الشبكة (ومن هنا not ready)، وإمّا ألّا تردّ في الوقت المناسب (مهلة ADNL).
• لا سجل عميق. العُقد العامة لا تحتفظ بأرشيف عميق. فإن احتجت إلى معاملة قديمة بزوج lt/hash فقد لا تكون موجودة هناك أصلًا — وعن العمل مع السجل هناك مقالة مستقلة عن lt وhash.
• بلا أي ضمانات. إنه مورد «كما هو». لا أولوية لك، ولا أحد يَعِدك بسعة تمرير: اليوم حالفك الحظ، وغدًا لا.

أي أن not ready ليس مصادفة يمكن «انتظار انقضائها»، بل سلوك حتميّ لمورد مشترك تحت الحمل. ولن يستطيع أيُّ كود تكتبه أن يجعل عقدةً مُثقَلة تخصّ غيرك تُزامِن أسرع.

إصلاحات جانب العميل: إعادة المحاولة وتدوير النقاط والمهل

قبل أن تغيّر البنية التحتية، اعصر ما يمكن عصره من جانب العميل. هذه الأساليب تعمل فعلًا، لكن لها سقفًا — فالعُقد تبقى مشتركة على أي حال.

1. إعادة المحاولة مع تراجع أُسّي

كثيرًا ما يكون not ready عابرًا: فبعد 200–800 مللي ثانية يكون اللايت-سيرفر نفسه قد طبّق كتلة الشارد المطلوبة. وإعادةُ محاولةٍ بسيطة بتأخير متصاعد تزيل نسبة ملموسة من الأخطاء.

async function withRetry<T>(fn: () => Promise<T>, tries = 4): Promise<T> {
  let lastErr: unknown;
  for (let i = 0; i < tries; i++) {
    try {
      return await fn();
    } catch (e) {
      lastErr = e;
      // نعيد المحاولة على 'not ready' ومهل ADNL، لا على أخطاء منطق العمل
      await new Promise((r) => setTimeout(r, 200 * 2 ** i));
    }
  }
  throw lastErr;
}

2. تدوير النقاط الطرفية

احتفظ في مجمّعك بعدّة لايت-سيرفرات من الإعداد، وانتقل إلى التالي إن ردّ الحاليُّ بـ not ready أو سقط بمهلة. فعقدة متأخّرة قد تجاورها أخرى لحقت بالفعل.

3. رفع المهلة

مهلة ADNL الافتراضية قاسية أحيانًا على عقدة عامة مُثقَلة. وهامش صغير (بضع ثوانٍ) يقلّل الانقطاعات الكاذبة. لكن إن رفعت المهلة إلى ما لا نهاية فأنت تكدّس طلبات معلّقة فحسب؛ وهذا تخدير لا علاج.

وثمّة أسلوب مفيد مستقل: فحص صحة خفيف قبل الطلب الحقيقي. وget_masterchain_info (رأس الماستر-تشين) مثاليّ لذلك: فهذه العملية بالذات هي أوّل من يعيد seqno حديثًا حين تكون العقدة قد لحقت برأس الشبكة، ولا تعيد not ready إلا حين لم تلحق العقدة برأس الماستر-تشين نفسه. أعادت seqno حديثًا؟ إذن العقدة في الخدمة، ويمكنك تنفيذ get_account_state وget_balance وrun_get_method.

خلاصة صادقة: إعادة المحاولة + التدوير + المهل تدفع معدّل الأخطاء إلى الأسفل، لكنها لا تزيل السبب. فالعُقد العامة مُثقَلة بحكم التصميم — وأنت لا تفعل أكثر من أن تطرق البابَ بلطف أكبر، والطابور خلفه هو الطابور نفسه. وتجد مقاربات أخرى للوصول إلى TON مجموعةً في مراجعة بدائل toncenter لعام 2026.

حلٌّ بلا عقدة خاصة: مفتاح TONNode المستضاف على لايت-سيرفرنا

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

TONNode خادم MCP مستضاف لشبكة TON. وMCP (Model Context Protocol) معيار يتيح لوكلاء الذكاء الاصطناعي (Claude وCursor وChatGPT/Codex وأي عميل MCP) استدعاء الأدوات. فبدل أن يحلّل كودك الإعداد العالمي ويرقص حول not ready، يستدعي الوكيل أداة جاهزة، وخلفها نقطة مستضافة https://mcp.tonnode.io/mcp بمفتاح Bearer خاص بك. هذه سعة تمرير مضمونة بدل طابور مشترك.

حزمة @tonnode/mcp مفتوحة المصدر (MIT، وموجودة على npm وGitHub باسم tonnode/mcp) تعمل عبر بروتوكول TON الأصلي ADNL، بلا طبقات HTTP وسيطة. أي أنك لا تستبدل النقل ببوابة HTTP بطيئة، بل تبقى على ADNL الصادق نفسه — لكن بوصول ذي أولوية تحت مفتاحك.

وللتشخيص وللقراءة اليومية ستنفعك:

• get_masterchain_info — رأس الماستر-تشين، فحص صحة طبيعيّ.
• get_account_state — حالة الحساب وأعلامه وآخر معاملة فيه.
• get_balance — الرصيد بعملة GRAM.
• run_get_method — أيّ get-method للقراءة فقط في العقد.

وإن كنت في بداياتك مع MCP على TON، فاطّلع على دليل MCP لشبكة TON.

كيف تربطه: npx محليًا أو نقطة مستضافة بمفتاح

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

مجموعة أدوات القراءة الكاملة تعمل محليًا بلا أي إعداد إضافي، عبر الإعداد العام، بلا بطاقة وبلا مفتاح:

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

هذا ممتاز للتطوير وللتجارب المحلية. لكن تذكّر: npx المحلي تحت الغطاء ما زال يقصد اللايت-سيرفرات المشتركة نفسها، ولذلك لا ينقذك من not ready تحت الحمل — بل ينقذك من العبث بالاعتماديات ويمنحك واجهة أدوات موحّدة.

مستضاف بمفتاح

لكي تبتعد عن العُقد المشتركة، حوّل النقل إلى HTTP-MCP بمفتاح Bearer خاص بك (أمّا استدعاء الأدوات نفسه فيذهب إلى عقدتنا عبر ADNL):

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

كيف يبدو ذلك عمليًا مع الوكيل

بعد الربط يكفي الوكيلَ طلبٌ نصّيّ عادي — وسيختار الأدوات بنفسه:

أوّلًا get_masterchain_info لفحص الصحة. ثم get_account_state للعنوان EQC… — أظهِر الحالة وآخر معاملة. بعدها get_balance للعنوان نفسه.

تحت الغطاء هذه سلسلة: get_masterchain_info (العقدة حيّة ولحقت بالرأس) ← get_account_state (الحالة والأعلام وآخر معاملة) ← get_balance (رصيد GRAM). ولا إعادة محاولات حول طابور غيرك — فالطلب يذهب إلى سعة تمرير مضمونة. وبالمناسبة، GRAM هو Toncoin بعد إعادة تسميته (جرت إعادة التسمية في يونيو 2026)؛ أما الشبكة فما زالت تُسمّى TON.

المفتاح المجاني Hobby (60 طلبًا/دقيقة) يُصدَر فور تسجيل الدخول، بلا بطاقة. ثم مع النمو: Pro بـ 29 دولارًا/شهر و300 طلب/دقيقة؛ وScale بـ 199 دولارًا/شهر و1200 طلب/دقيقة. وتفصيل مهم: أدوات TONNode الـ16 كلّها متاحة على جميع الخطط — فأنت تدفع مقابل سعة التمرير فقط، لا مقابل الوظائف.

لايت-سيرفر مخصّص لك — عند الطلب، لا خدمة ذاتية

أحيانًا لا تكفي الخطة المستضافة ويلزمك لايت-سيرفر مخصّص (single-tenant) — لحركتك أنت وحدها، بلا جيران إطلاقًا. هذا الخيار موجود، لكن بصراحة: إنه ليس خدمة ذاتية. لا يوجد في لوحة التحكم زرّ «فعِّل single-tenant» — بل يُرتَّب الأمر يدويًا: راسِلنا لنناقش الحمل والتهيئة.

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

باختصار

• not ready = العقدة غير مُزامَنة: الماستر-تشين يسبق الشارد، وحالة الحساب في آخر كتلة شارد لا يمكن التحقّق منها بعد.
• اللايت-سيرفرات العامة من الإعداد العالمي مشتركة ومحدودة: not ready، ومهل ADNL، ولا سجل عميق. ولا تخلط هذا بـ HTTP 429 لدى toncenter/tonapi — تلك طبقة أخرى.
• إصلاحات جانب العميل (إعادة المحاولة مع التراجع، وتدوير النقاط، والمهل) تخفّض معدّل الأخطاء لكنها لا تزيل السبب.
• get_masterchain_info هو فحص الصحة لديك: لا يُظهر not ready إلا حين لا تكون العقدة قد لحقت برأس الماستر-تشين أصلًا.
• والعلاج الحقيقي هو مغادرة المورد المشترك إلى سعة تمرير مضمونة.

خذ مفتاح Hobby المستضاف مجانًا وتوقّف عن تلقّي «not ready» على العُقد المشتركة ← tonnode.io/dashboard?plan=hobby

ثم مع نمو الحمل — الخطط والأسعار وخريطة الطريق.