تهدف خوارزمية فحص الصحة إلى جعل ADAMANT أكثر محفظة رقمية موثوقة. تُطبَّق على جميع العُقد، بما في ذلك عُقد ADM وعُقد العملات، وكذلك الخدمات مثل info-service وIPFS. تقوم الخوارزمية بتقييم ارتفاع العُقدة (node height)، والإصدار الأدنى المدعوم، وتستخدم النقطة النهائية الأكثر إفادة المتاحة، مثل /api/node/status لـ ADM. وتتجاهل العُقد المعطَّلة من قبل المستخدم، وتخزن قائمة العُقد محليًا بشكل مستقل عن إعداد “البقاء مسجلاً دخولك”.
تشمل حالات العُقدة: معطَّلة من قبل المستخدم، غير مدعومة (بسبب الإصدار أو عُقدة HTTP عبر PWA-HTTPS)، وغير متاحة. إذا كانت العُقدة غير متاحة، فإن الخوارزمية تتحقق أولًا من النطاق (domain)، ثم من alt_ip إذا فشل النطاق. بمجرد توفر النطاق، لا يتم التحقق من alt_ip مرة أخرى لتجنب الطلبات الإضافية. إذا كان كلاهما غير متاح، تحاول الخوارزمية مرة أخرى عند الطلب التالي.
يعتمد اكتشاف العُقدة المتاحة والمتماثلة (in-sync) على عتبات ارتفاع العُقدة (HEIGHT_EPSILON). تُعتبر العُقدة الوحيدة التي تستجيب فقط هي المتاحة. تُصنَّف مجموعة العُقد ضمن العتبة على أنها نشطة (Active)، بينما تُصنَّف العُقد خارج العتبة على أنها متماثلة (أو “غشّاش”). تختلف العتبات حسب العملة: ADM تساوي 10، BTC تساوي 2، ETH تساوي 5، DOGE تساوي 3، DASH تساوي 3، وLSK تساوي 5. على سبيل المثال، تكون عُقد BTC عند 815,000 و815,001 نشطتين كليهما، لكن العُقدة عند 815,010 تكون متماثلة.
أثناء الفحص الصحي الأولي أو بعد فقدان الاتصال، قد تُصنَّف أول إجابة من عُقدة على أنها نشطة بدلًا من متماثلة. إن انتظار فحص كامل مدته 10 ثوانٍ سيؤدي إلى تجميد التطبيق. ولحل هذه المشكلة، يتم تحديث الحالات إلى نشطة أو متماثلة فقط بعد استجابة 30% من العُقد؛ وإلا تُحفظ الحالات السابقة. ويُشار إلى هذا بأنه فحص أولي. بالنسبة للفحوصات اللاحقة، يتم تحديث الحالات فقط بعد استجابة 100% من العُقد لمنع العُقد المعلقة ذات البيانات القديمة من التصنيف خطأً على أنها متماثلة.
لتجنب إرباك المستخدمين، تُعرض حالة بصرية “جار التحديث…” أثناء الفحص الأولي الجارٍ للعُقد في حالات غير محددة أو غير متاحة. وتظهر كنقطة رمادية مع نص باهت.
يقيس كل طلب فحص صحي زمن الاستجابة (Ping)، وتُعتبر العُقدة ذات زمن الاستجابة الأقل هي الأسرع. يكون إعداد “تفضيل العُقدة الأسرع” افتراضيًا لا (No) لـ ADM، ونعم (Yes) للعُقد العملات، ويعمل بشكل منفصل بين عُقد العملات ومؤشرات الفهرسة (indexers).
تُجرى فحوصات الصحة بشكل مستقل عن حالة اتصال الإنترنت، لأن تقرير نظام التشغيل بـ”عدم وجود اتصال بالإنترنت” غير موثوق. إذا لم يكن هناك اتصال، فسيكون الناتج ببساطة عدم توفر عُقد متاحة. يتم تحديث الحالتين hasEnabledNodes وhasAvailableNodes عندما تكون ثلاث عُقد على الأقل مستجيبة أو عند اكتمال الفحص، مما يحسّن تجربة بدء التشغيل من خلال تجنب تجميد التطبيق لمدة 10 ثوانٍ. يتم منع الفحوصات المتداخلة؛ إذ كان هناك خطأ سابق يستخدم setInterval() بدلًا من setTimeout() تسبب في عاصفة طلبات عند استعادة التطبيق من الخلفية.
تُفعَّل فحوصات الصحة عند بدء التطبيق، أو استعادة الاتصال، أو عند فتح شاشة العُقد، أو عند تحديث قوائم العُقد. وتختلف الفترات المنتظمة (normalUpdateInterval) حسب نوع العُقدة، وتتراوح بين 3 إلى 8 دقائق. إذا فشلت جميع العُقد النشطة، يتم إجراء فحص صحي إضافي.
عند إرسال طلبات HTTP، تتجاهل الخوارزمية حالة “عدم وجود اتصال بالإنترنت” ولا تنتظر اكتمال الفحص الصحي بالكامل. بل تختار العُقدة الأسرع أو عُقدة نشطة عشوائية. إذا فشل الطلب بسبب انتهاء المهلة، تحاول العُقدة التالية وتُصنَّف العُقدة الفاشلة على أنها غير متاحة. ولا تُعد أخطاء HTTP مثل 404 فشلًا. تُكمل الطلبات المعلقة دائمًا بعد استعادة الاتصال، مما يضمن عدم انقطاع عمليات مثل حفظ قائمة جهات الاتصال.