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

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

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

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

لذلك، حين أقيّمها، لا أركز على معدل المعاملات في الثانية (TPS)، بل على أمرين فقط: هل يتزايد عدد طلبات الاستعلام الحقيقية باستمرار؟ ومن هم الذين يدفعون فعلًا؟ الأول يتعلق بالطلب، والثاني يحدد ما إذا كان هذا الطلب حقيقيًا أم مصنوعًا بتكديس الدعم المالي.

@SpaceandTime يتوقف نجاح هذا المسار على ذلك، وكذلك رهان SXT على التقاط القيمة في $SXT . #SXT

#sxt $SXT