طلب eth_chainId نفسه: العنوان الذي أدرجته الجهة الرسمية للشبكة الرئيسية لم يُعِد الاستجابة، بينما أعادها عنوان شبكة الاختبار بشكل طبيعي. لا يجوز تحريف هذه النتيجة والقول إن الشبكة الرئيسية توقفت. ما تكشفه هو مشكلة من نوع آخر. إن إدراج @Dusk نقطة الدخول في الوثائق لا يثبت سوى أن العنوان معلَن، ولا يثبت أن جهازي أنشأ اتصالًا موثوقًا به معها. فما بين وجود الوثائق وإمكانية استخدام العميل، توجد الشهادات والشبكة وهوية السلسلة.
ضيّقت نطاق المتغيرات إلى أدنى حد. أبقيت العميل ومحتوى POST والمهلة البالغة 15 ثانية كما هي، ولم أغيّر سوى نقطة نهاية RPC. في 24 أغسطس 2026، عند الساعة 00:08، أعادت شبكة الاختبار 0x2e9، ثم أعادت الكتلة 0x11bc06. أما الشبكة الرئيسية فتوقفت عند TLS مع التحقق الصارم من الشهادة؛ كانت حالة HTTP هي 000، ونتيجة التحقق 20، ولم يُحصل أصلًا على معرّف السلسلة في طبقة التطبيق.
أهم ما يقدمه هذا الاختبار المقارن ليس إصدار حكم بشأن سلامة الشبكة. فقد يكون سبب فشل TLS الصارم سلسلة الشهادات، وقد يظهر الفشل فقط على مسار اتصالي الحالي. أما ما يمكن إثباته فنطاقه واضح: فعلى الأقل، في بيئة العميل هذه، لم يجتز عنوان الوثائق بعد اختبار قابلية الاستخدام. وكتابة أن فشل اتصال واحد يعني تعطّل الشبكة كلها ستكون تصرفًا أكثر تسرعًا من تجاهل الفشل نفسه.
كنت أرى نقطة RPC فأبدأ بإعداد المحفظة. لكن عليّ الآن تغيير الترتيب. الاتصال الموثوق هو الباب، ومعرّف السلسلة هو رقم المنزل، واستمرار تقدّم الكتل هو ما يثبت أن أحدًا موجود في الداخل. لا ينبغي المخاطرة بأموال حقيقية قبل اجتياز كل خطوة. في هذه المرة، أمكن مواصلة التحقق من النقاط الثلاث كلها على شبكة الاختبار، أما الشبكة الرئيسية فتوقفت عند الخطوة الأولى. والفرق ليس في السرعة، بل في إمكانية الانتقال إلى التحقق التالي.
لكي تكون نقطة دخول EVM لدى $DUSK قابلة للاستخدام فعلًا، يجب أن نرى في الوقت نفسه أن الشهادة موثوقة، وأن معرّف السلسلة يطابق المتوقع، وأن ارتفاع الكتلة يواصل التغيّر. ما لم تجتمع الأدلة الثلاثة، لن أضع عليها سوى وسم «قيد التحقيق»، لا «قابلة للاستخدام»، وبالتأكيد لن أكتب أن الشبكة الرئيسية معطلة. وأبسط إجراء يوفّر المال على المستخدم العادي واضح أيضًا: أجرِ هذه الفحوص الثلاثة قبل التحويل، وتوقف إذا لم تظهر نتيجة أيٍّ منها.
الوثائق تعطيك العنوان، أما الاختبار الفعلي فيمنحك إذن الدخول. #dusk
ضيّقت نطاق المتغيرات إلى أدنى حد. أبقيت العميل ومحتوى POST والمهلة البالغة 15 ثانية كما هي، ولم أغيّر سوى نقطة نهاية RPC. في 24 أغسطس 2026، عند الساعة 00:08، أعادت شبكة الاختبار 0x2e9، ثم أعادت الكتلة 0x11bc06. أما الشبكة الرئيسية فتوقفت عند TLS مع التحقق الصارم من الشهادة؛ كانت حالة HTTP هي 000، ونتيجة التحقق 20، ولم يُحصل أصلًا على معرّف السلسلة في طبقة التطبيق.
أهم ما يقدمه هذا الاختبار المقارن ليس إصدار حكم بشأن سلامة الشبكة. فقد يكون سبب فشل TLS الصارم سلسلة الشهادات، وقد يظهر الفشل فقط على مسار اتصالي الحالي. أما ما يمكن إثباته فنطاقه واضح: فعلى الأقل، في بيئة العميل هذه، لم يجتز عنوان الوثائق بعد اختبار قابلية الاستخدام. وكتابة أن فشل اتصال واحد يعني تعطّل الشبكة كلها ستكون تصرفًا أكثر تسرعًا من تجاهل الفشل نفسه.
كنت أرى نقطة RPC فأبدأ بإعداد المحفظة. لكن عليّ الآن تغيير الترتيب. الاتصال الموثوق هو الباب، ومعرّف السلسلة هو رقم المنزل، واستمرار تقدّم الكتل هو ما يثبت أن أحدًا موجود في الداخل. لا ينبغي المخاطرة بأموال حقيقية قبل اجتياز كل خطوة. في هذه المرة، أمكن مواصلة التحقق من النقاط الثلاث كلها على شبكة الاختبار، أما الشبكة الرئيسية فتوقفت عند الخطوة الأولى. والفرق ليس في السرعة، بل في إمكانية الانتقال إلى التحقق التالي.
لكي تكون نقطة دخول EVM لدى $DUSK قابلة للاستخدام فعلًا، يجب أن نرى في الوقت نفسه أن الشهادة موثوقة، وأن معرّف السلسلة يطابق المتوقع، وأن ارتفاع الكتلة يواصل التغيّر. ما لم تجتمع الأدلة الثلاثة، لن أضع عليها سوى وسم «قيد التحقيق»، لا «قابلة للاستخدام»، وبالتأكيد لن أكتب أن الشبكة الرئيسية معطلة. وأبسط إجراء يوفّر المال على المستخدم العادي واضح أيضًا: أجرِ هذه الفحوص الثلاثة قبل التحويل، وتوقف إذا لم تظهر نتيجة أيٍّ منها.
الوثائق تعطيك العنوان، أما الاختبار الفعلي فيمنحك إذن الدخول. #dusk