حالات الرسائل والتحويلات في ADAMANT

يُميّز ADAMANT بين حالة تسليم الرسائل وحالة تحويلات العملات الرقمية. تُتتبع الرسائل داخل سلسلة كتلة ADAMANT، بينما تُحقَق التحويلات عبر سلسلة الكتلة الأصلية لكل رمز. مبدأ أساسي للخصوصية: لن يُطبّق ADAMANT أبدًا حالة “تم القراءة” للرسائل، لأن ذلك سيُسرب نشاط المستلم.

حالات الرسائل

تُعتبر الرسائل الواردة مُسلّمة دائمًا لأنها تُقرأ مباشرة من سلسلة الكتلة، وبالتالي لا تُعرض حالة لها. تمر الرسائل الصادرة بثلاث مراحل: جارٍ الإرسال (معلق)، تم التسليم إلى العقدة (قبلت العقدة المعاملة)، وفي سلسلة الكتلة (تأكيد إضافي عند معرفة الكتلة). يجب أن يحدث الانتقال من “جارٍ الإرسال” إلى “تم التسليم” بسرعة لتجربة واجهة مستخدم سلسة. تُحدَّث الحالات في قائمة الدردشة وفي داخل الدردشات الفردية.

عند تفعيل المقابس (sockets)، تُعيد المقابس المعاملات غير المؤكدة بمجرد وصولها إلى العقدة. عند هذه النقطة، تكون الحقول مثل block_timestamp وheight وblockId وconfirmations بقيمة null. تُكرّر المقابس استجابات واجهة برمجة التطبيقات REST — تصل الرسائل فورًا عبر المقبس، بينما توفر REST التحديثات كل ~10 ثوانٍ (SOCKET_ENABLED_TIMEOUT) كحل بديل للموثوقية. لا يستخدم ADAMANT عمداً حالة “تم التسليم إلى المستلم” لأنها تتعارض مع فلسفة الخصوصية، كما أنها غير موثوقة تقنيًا عندما يكون المستلم غير متصل.

إذا فشل التسليم إلى العقدة أو رُفضت المعاملة من سلسلة الكتلة، تُعلّم الرسالة بحالة لم تُرسَل.

حالات تحويلات العملات الرقمية

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

يبدأ التحويل بحالة معلق (جارٍ الإرسال أو الفحص). بمجرد تأكيد العقدة بوجود المعاملة، تصبح مسجّلة. ثم يستمر ADAMANT بالفحص حتى الوصول إلى حالة نهائية: نجاح (تم التأكيد في الشبكة)، فشل (رُفضت من الشبكة)، أو غير متسق (تم اكتشاف تناقض). تُعرّف قواعد فحص المعاملات لكل عملة في مستودع adamant-wallets ضمن txFetchInfo. تم توثيق المواصفة في AIP-12.

بالنسبة لتحويلات ADM تحديدًا، تأتي الحالة مباشرة مع المعاملة: إذا كانت confirmations > 0، يُعلّم التحويل بنجاح؛ وإذا كانت confirmations = 0، تبقى الحالة معلقة أو مسجّلة.

آلية فحص الحالة في الخلفية

تتطلب فحص حالة سلاسل الكتلة غير-ADM طلبات إضافية إلى عقدة أو واجهة برمجة تطبيقات. يستخدم ADAMANT آلية في الخلفية تفحص فقط المعاملات المرئية للمستخدم، وتقف بمجرد استلام الحالة النهائية. تعتمد تكرارات الفحص على عمر المعاملة (جديدة مقابل قديمة)، ونظام يحد من عدد المحاولات للمعاملات المعلقة، بينما يسمح بعدد غير محدود من المحاولات للمعاملات المسجّلة. تعمل عمليات الفحص فقط عند توفر اتصال بالشبكة وعند توفر عقد العملة ذات الصلة، لتجنب إهدار المحاولات في حالة عدم الاتصال.

تُصنّف المعاملة على أنها جديدة إذا تم بثها للتو من التطبيق، أو إذا كان زمنها يقع ضمن حد زمني X دقيقة من الوقت الحالي. وإلا فهي قديمة. يمكن أن يكون الحد الزمني ثابتًا أو محسوبًا لكل عملة على حدة:

const isNew = (admTransferTimestamp) =>
  Date.now() - admTransferTimestamp < newPendingTxFetchAttempts * newPendingTxFetchInterval;

يُضمن هذا التمييز أن تُفحص المعاملات الأحدث بشكل متكرر أكثر، بينما تُحقق المعاملات الأقدم بشكل أقل تشددًا.

مثال: تحويل بيتكوين

الثوابت من adamant-wallets:

"txFetchInfo": {
    "newPendingInterval": 10000,
    "oldPendingInterval": 3000,
    "registeredInterval": 40000,
    "newPendingAttempts": 20,
    "oldPendingAttempts": 3
}

لتحويل معلق جديد، يتحقق التطبيق كل 10 ثوانٍ (newPendingInterval) لمدة تصل إلى 20 محاولة (newPendingAttempts)، مما يعطي نافذة إجمالية تقارب 200 ثانية. إذا كشفت العقدة عن المعاملة (حتى مع 0 تأكيدات)، تصبح مسجّلة. إذا بقيت غير مرئية بعد جميع المحاولات، تُعلّم بحالة فشل.

بالنسبة للمعاملات المسجّلة، يتحقق التطبيق كل 40 ثانية (registeredInterval) بعدد غير محدود من المحاولات حتى تأكيد المعاملة (≥1 تأكيد) أو حتى تُعيد العقدة خطأ.

يمكن للمستخدم إعادة الفحص يدويًا بالنقر على أيقونة الحالة في الدردشة، ما يعيد تعيين الحالة إلى معلقة ويُفعّل دورة تحقق جديدة. لا تُخزّن حالات التحويل محليًا؛ عند تسجيل الدخول باستخدام كلمة مرور أو رمز PIN أو بصمة إصبع، تُعاد مراجعة الحالات من جديد.

اكتشاف عدم الاتساق

يُعلّم التحويل بحالة غير متسق عندما لا تتطابق البيانات المسجّلة في رسالة ADAMANT مع البيانات المستخرجة من سلسلة كتلة الرمز. يُرفع علم التناقض إذا تحقق أي مما يلي: يختلف المبلغ بأكثر من ~0.1–0.5٪، يختلف عنوان المرسل، يختلف عنوان المستلم، أو يختلف زمن رسالة ADAMANT وزمن معاملة سلسلة الكتلة بأكثر من 3 ساعات.

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

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

عرض واجهة المستخدم

تُظهر لقطات الشاشة أدناه تطور حالة التحويل في تطبيق ADAMANT PWA وتطبيق iOS.

DASH في الدردشة PWA-dev v4.9.0 — 2025-03-04

بعد تأكيد التحويل (~10 ثوانٍ)	تظهر المعاملة في الدردشة كمعلقة	تفاصيل المعاملة — معلقة (~دقيقتين)

تأكيد دون تفاصيل (~5 ثوانٍ)	تأكيد مع تفاصيل — نهائي

DASH في الدردشة iOS v3.11.0 — 2025-03-04

بعد التأكيد (~3 ثوانٍ)	تظهر المعاملة في الدردشة كمعلقة	تفاصيل المعاملة — معلقة (~دقيقتين)

تأكيد مع تفاصيل — نهائي