بدأت Sei في طرح ترقية تخزين Eidos الخاصة بها، والتي تعيد بناء كيفية تخزين شبكة الطبقة الأولى للبيانات على السلسلة والتحقق منها، حيث تستهدف خارطة طريق Giga الخاصة بها إنتاجية تبلغ 200,000 معاملة في الثانية.
قالت Sei في تحديث تقني بتاريخ 12 أغسطس إن Eidos مصممة لإزالة قيود التخزين التي قد تمنع طبقة التنفيذ للشبكة من العمل بالسرعات المخطط لها ضمن Giga. الترقية هي مكون التخزين من إصلاح معماري ثلاثي الأجزاء يتضمن أيضًا Autobahn للإجماع و Ares لتنفيذ المعاملات.
وصلت مكونات Eidos الأولى بالفعل إلى الشبكة الرئيسية من خلال Sei v6.6، على الرغم من أن نظام التخزين الكامل يتم تقديمه على مراحل. بدأت حالة EVM في الانتقال إلى قاعدة بيانات مخصصة، بينما تم جدولة FlatKV و LtHash وتخزين الإيصالات الجديد وأنظمة الأرشفة خارج العقدة للإصدارات اللاحقة.
في صميم Eidos يكمن تغيير في الطريقة التي تخطط بها Sei للحفاظ على حالة آلة إيثريوم الافتراضية (EVM) والتحقق منها.
قالت Sei إن أشجار ميركل التقليدية تتطلب من العقد إعادة حساب العديد من التجزئات عند تغيير قيمة ما لأن كل تحديث يغير سلسلة التجزئات المؤدية إلى جذر الشجرة. ومع زيادة كمية البيانات المخزنة، يمكن أن تتطلب تغييرات الحالة الفردية عملاً إضافيًا في قاعدة البيانات.
من المقرر أن تحل Eidos محل هذا الهيكل لحالة EVM باستخدام FlatKV، وهو نظام تخزين قيم المفتاح المسطح حيث يتطلب تغيير الحالة الفردي عملية كتابة واحدة. سيتم التعامل مع التحقق باستخدام LtHash، أو التجزئة الشبكية، الذي يحافظ على بصمة جارية للحالة.
وفقًا للتصميم الذي وصفته Sei، يمكن لـ LtHash تحديث تلك البصمة في وقت ثابت عند تغيير الحالة. فبدلاً من إعادة حساب مسار التجزئات عبر شجرة ميركل، تقوم العقدة بإزالة مساهمة القيمة القديمة وتضيف القيمة الجديدة، مما يترك مقدار العمل لكل تحديث دون تغيير مع توسع الحالة.
يرتبط التغيير التقني بشكل مباشر بأهداف الأداء المحددة لـ Giga. كما ذكرت crypto.news في مايو 2025، أصدرت Sei Labs ورقتها البيضاء Giga بتصميم يستهدف 200,000 معاملة في الثانية، وإنتاجية 5 جيجاجاس، ونهائية أقل من 400 مللي ثانية.
عند هذه الإنتاجية، قالت Sei إن الشبكة سيتعين عليها أيضًا كتابة مئات الآلاف من إدخالات قاعدة البيانات كل ثانية. وبالتالي، فإن تنفيذ المعاملات بشكل أسرع سيوفر فائدة محدودة إذا لم تتمكن طبقة التخزين من معالجة تغييرات الحالة وسجل المعاملات بمعدل مماثل.
جزء آخر من Eidos يفصل حالة EVM عن البيانات الأخرى التي تتعامل معها عقد Sei.
قبل هذا التغيير، قالت Sei إن حالة EVM كانت تشارك قاعدة بيانات مع معلومات أخرى على السلسلة. تمنح البنية الجديدة حالة EVM مخزنها المخصص، مما يمنع الاستعلامات التاريخية من التنافس مباشرة مع معالجة المعاملات الحية ويقلل من عبء عمل قاعدة البيانات المفروض على الوحدات النمطية غير EVM.
بدأ الفصل في الوصول إلى الشبكة الرئيسية في إصدار v6.6 خلال أغسطس. كما قدمت Sei مسار تقليم (pruning) مُعاد بناؤه لإزالة البيانات التي لم تعد العقد بحاجة للاحتفاظ بها في التخزين النشط.
وفقًا للشبكة، قللت تغييرات التقليم إحدى عمليات التنظيف من بين ثماني و18 دقيقة إلى حوالي خمس دقائق أثناء الاختبار والتشغيل. وقالت Sei إن العقد التي كانت تتخلف سابقًا بمئات الكتل عن رأس السلسلة بقيت ضمن حوالي 60 كتلة بعد التغيير.
يتم أيضًا تخصيص محرك تخزين منفصل للكتل وإيصالات المعاملات يسمى LittDB. وصفت Sei الكتل والإيصالات كبيانات تُكتب مرة واحدة، تُقرأ بشكل متكرر، وتُأرشف في النهاية، مما يجعل متطلبات تخزينها مختلفة عن حالة الحساب والعقود التي يتم تحديثها بشكل متكرر.
تشير المعايير الداخلية التي استشهدت بها Sei إلى أن إنتاجية كتابة LittDB تتجاوز واحد جيجابايت في الثانية بينما تتعامل مع حوالي 55,000 قراءة نقطية في الثانية. وحافظ مخزن الإيصالات الجديد على أكثر من 150,000 عملية كتابة في الثانية خلال اختبارات الأداء التي استمرت لعدة ساعات وشملت جمع البيانات غير المرغوب فيها. حذرت Sei من أن هذا الرقم يقيس محرك التخزين ولا ينبغي اعتباره إنتاجية معاملات البلوكتشين.
تغير Eidos أيضًا مقدار المعلومات التاريخية التي يُتوقع من العقد الفردية الاحتفاظ بها محليًا.
قالت Sei إن الحالة التي يتم الوصول إليها بشكل متكرر وسجل السلسلة الأخير سيبقون على التخزين المحلي السريع، بينما ستنتقل السجلات التاريخية الأقدم إلى أنظمة أرشيفية مصممة للقدرة. سيظل بإمكان المستكشفين والفهارس والمستخدمين الذين يدققون المعاملات التاريخية استرداد المعلومات المؤرشفة، وفقًا للشبكة.
يهدف تقليل كمية البيانات القديمة المحفوظة على العقد النشطة إلى منع الاستعلامات التاريخية من استهلاك الموارد اللازمة للمعاملات الحالية. وقالت Sei إن متطلبات التخزين المتزايدة يمكن أن تجبر المشغلين على استخدام أجهزة أسرع وأكثر تكلفة مع زيادة إنتاجية الشبكة.
يأتي عمل البنية التحتية بعد جهود سابقة لزيادة الوصول إلى نظام Sei البيئي لـ EVM. أضافت MetaMask دعم Sei الأصلي في أغسطس 2025، مما يسمح للمستخدمين بالوصول إلى التطبيقات المستندة إلى Sei، وتبديل الأصول، وربط الرموز المميزة مباشرة عبر المحفظة. في ذلك الوقت، كانت Sei تعالج أكثر من 4.2 مليون معاملة يوميًا وكان لديها أكثر من 11 مليون مستخدم نشط شهريًا، وفقًا للأرقام المذكورة في التقرير.
دعت اتفاقية توزيع منفصلة أُعلن عنها في ديسمبر 2025 شركة Xiaomi لتثبيت محفظة Sei مسبقًا على الهواتف الذكية الجديدة التي تُباع خارج البر الرئيسي للصين والولايات المتحدة. وخططت الشركات أيضًا لدعم مدفوعات العملات المستقرة باستخدام أصول مثل USDC، مع عمليات نشر أولية للمدفوعات مخطط لها في هونغ كونغ والاتحاد الأوروبي.
بالنسبة لمشغلي العقد، تقوم Sei بتنفيذ ترحيل التخزين دون إيقاف سلسلة الكتل.
قالت الشبكة إن أنظمة التخزين الحالية والبديلة ستعمل جنبًا إلى جنب بينما تنتقل البيانات على دفعات من كتلة إلى أخرى. يتم التحكم في الطرح من خلال الحوكمة وقد تم تصميمه مع عملية استعادة (rollback) إذا ظهرت مشاكل.
قبل النشر، قامت العقد الظلية بإعادة تشغيل حركة مرور الشبكة الرئيسية (mainnet traffic) مقابل أنظمة التخزين الجديدة بينما تم فحص تجزئات التكامل بشكل مستمر، وفقًا لـ Sei. أظهرت الاختبارات أن أوقات الكتل بقيت دون تغيير إلى حد كبير بينما كانت عمليات الترحيل تعمل في الخلفية.
تعد Eidos إعادة البناء الثالثة للتخزين التي قامت بها Sei. استبدلت الشبكة سابقًا بنية تخزين Cosmos الأصلية الخاصة بها بـ SeiDB، تلاها فصل مخزن الحالة الذي يتم تقديمه الآن على الشبكة الرئيسية. ستشكل FlatKV و LittDB ونظام الأرشفة خارج العقدة المرحلة التالية عند وصولها من خلال الإصدارات اللاحقة.
لا يحتاج المستخدمون ومطورو التطبيقات إلى اتخاذ أي إجراء خلال عملية الترحيل، وفقًا لـ Sei، مع بقاء الأرصدة والعقود الذكية والسجلات التاريخية ونقاط نهاية RPC الحالية متاحة. وقد تم تزويد مشغلي العقد بدليل ترحيل يغطي علامات التكوين وعملية الاستعادة الموثقة لنظام التخزين الجديد.
