Sei ha comenzado a implementar su actualización de almacenamiento Eidos, reconstruyendo cómo la red de capa 1 almacena y verifica los datos en cadena mientras su hoja de ruta Giga apunta a un rendimiento de 200,000 transacciones por segundo.
Resumen
- Sei ha comenzado la implementación gradual de Eidos a través de su actualización de mainnet v6.6.
- Eidos está reconstruyendo la arquitectura de almacenamiento de la red mientras Giga apunta a 200,000 TPS.
- El estado EVM se está separando en una base de datos dedicada, mientras que FlatKV y LtHash están planificados para etapas posteriores.
- La migración está diseñada para ejecutarse mientras Sei permanece en línea, con los sistemas de almacenamiento existentes y nuevos operando en paralelo.
Sei dijo en una actualización técnica del 12 de agosto que Eidos está diseñado para eliminar las restricciones de almacenamiento que podrían impedir que la capa de ejecución de la red opere a las velocidades planificadas bajo Giga. La actualización es el componente de almacenamiento de una revisión de arquitectura de tres partes que también incluye Autobahn para el consenso y Ares para la ejecución de transacciones.
Los primeros componentes de Eidos ya han llegado a mainnet a través de Sei v6.6, aunque el sistema de almacenamiento completo se está introduciendo por etapas. El estado EVM ha comenzado a moverse a una base de datos dedicada, mientras que FlatKV, LtHash, el nuevo almacenamiento de recibos y los sistemas de archivo fuera del nodo están programados para versiones posteriores.
La actualización Eidos de Sei cambia cómo se almacena el estado
En el centro de Eidos hay un cambio en la forma en que Sei planea mantener y verificar el estado de la Máquina Virtual de Ethereum.
Sei dijo que los árboles de Merkle tradicionales requieren que los nodos recalculen múltiples hashes cuando un valor cambia porque cada actualización altera la cadena de hashes que conduce a la raíz del árbol. A medida que aumenta la cantidad de datos almacenados, los cambios de estado individuales pueden requerir trabajo adicional en la base de datos.
Eidos está destinado a reemplazar esa estructura para el estado EVM con FlatKV, un sistema de almacenamiento de clave-valor plano donde un cambio de estado individual requiere una sola escritura. La verificación se manejará usando LtHash, o hash de celosía, que mantiene una huella digital continua del estado.
Bajo el diseño descrito por Sei, LtHash puede actualizar esa huella digital en tiempo constante cuando el estado cambia. En lugar de recalcular una ruta de hashes a través de un árbol de Merkle, un nodo elimina la contribución del valor antiguo y agrega el nuevo, dejando la cantidad de trabajo por actualización sin cambios a medida que el estado se expande.
El cambio técnico está directamente vinculado a los objetivos de rendimiento descritos para Giga. Como informó crypto.news en mayo de 2025, Sei Labs publicó su libro blanco de Giga con un diseño que apunta a 200,000 transacciones por segundo, 5 gigagas de rendimiento y finalidad por debajo de 400 milisegundos.
A ese rendimiento, Sei dijo que la red también tendría que escribir cientos de miles de entradas de base de datos cada segundo. La ejecución más rápida de transacciones proporcionaría un beneficio limitado si la capa de almacenamiento no pudiera procesar los cambios de estado y el historial de transacciones a una velocidad comparable.
Los datos EVM se están moviendo a una base de datos separada
Otra parte de Eidos separa el estado EVM de otros datos manejados por los nodos de Sei.
Antes del cambio, Sei dijo que el estado EVM compartía una base de datos con otra información en la cadena. La nueva arquitectura le da al estado EVM su propio almacén dedicado, evitando que las consultas históricas compitan directamente con el procesamiento de transacciones en vivo y reduciendo el trabajo de base de datos impuesto a los módulos que no son EVM.
La división comenzó a llegar a mainnet en la versión v6.6 durante agosto. Sei también introdujo una ruta de poda reconstruida para eliminar datos que los nodos ya no necesitan mantener en almacenamiento activo.
Según la red, los cambios de poda redujeron un proceso de limpieza de entre ocho y 18 minutos a aproximadamente cinco minutos durante las pruebas y la operación. Los nodos que anteriormente podían quedarse cientos de bloques detrás de la punta de la cadena permanecieron dentro de unos 60 bloques después del cambio, dijo Sei.
Los bloques y los recibos de transacciones también se están asignando a un motor de almacenamiento separado llamado LittDB. Sei describió los bloques y los recibos como datos que se escriben una vez, se leen repetidamente y finalmente se archivan, lo que hace que sus requisitos de almacenamiento sean diferentes del estado de cuentas y contratos que se actualiza con frecuencia.
Los puntos de referencia internos citados por Sei sitúan el rendimiento de escritura de LittDB por encima de un gigabyte por segundo mientras maneja alrededor de 55,000 lecturas puntuales por segundo. Un nuevo almacén de recibos sostuvo más de 150,000 escrituras por segundo durante pruebas de referencia de varias horas que incluyeron recolección de basura. Sei advirtió que la cifra mide el motor de almacenamiento y no debe tratarse como rendimiento de transacciones de blockchain.
El historial más antiguo se alejará de los nodos activos
Eidos también cambia cuánta información histórica se espera que los nodos individuales mantengan localmente.
Sei dijo que el estado de acceso frecuente y el historial reciente de la cadena permanecerán en almacenamiento local rápido, mientras que los registros históricos más antiguos se moverán a sistemas de archivo diseñados para capacidad. Los exploradores, indexadores y usuarios que auditan transacciones históricas aún podrán recuperar la información archivada, según la red.
Reducir la cantidad de datos antiguos mantenidos en nodos activos tiene como objetivo evitar que las consultas históricas consuman recursos necesarios para las transacciones actuales. Sei dijo que los requisitos de almacenamiento crecientes pueden, de otro modo, obligar a los operadores a usar hardware más rápido y más caro a medida que aumenta el rendimiento de la red.
El trabajo de infraestructura sigue a esfuerzos anteriores para aumentar el acceso al ecosistema EVM de Sei. MetaMask añadió soporte nativo para Sei en agosto de 2025, permitiendo a los usuarios acceder a aplicaciones basadas en Sei, intercambiar activos y puentear tokens directamente a través de la billetera. En ese momento, Sei procesaba más de 4.2 millones de transacciones diarias y tenía más de 11 millones de usuarios activos mensuales, según cifras citadas en el informe.
Un acuerdo de distribución separado anunciado en diciembre de 2025 pedía que Xiaomi preinstalara una billetera Sei en nuevos teléfonos inteligentes vendidos fuera de China continental y los Estados Unidos. Las empresas también planearon soporte para pagos con stablecoins utilizando activos como USDC, con despliegues iniciales de pagos planificados para Hong Kong y la Unión Europea.
La migración de Eidos se ejecuta mientras Sei permanece en línea
Para los operadores de nodos, Sei está llevando a cabo la migración de almacenamiento sin detener la blockchain.
La red dijo que los sistemas de almacenamiento existentes y de reemplazo operarán en paralelo mientras los datos se mueven en lotes de bloque a bloque. El despliegue se controla a través de la gobernanza y se ha diseñado con un proceso de reversión si surgen problemas.
Antes del despliegue, los nodos sombra reprodujeron el tráfico de la red principal contra los nuevos sistemas de almacenamiento mientras se verificaban continuamente los hashes de integridad, según Sei. Las pruebas mostraron que los tiempos de bloque permanecieron en gran medida sin cambios mientras los procesos de migración operaban en segundo plano.
Eidos es la tercera reconstrucción de almacenamiento emprendida por Sei. La red reemplazó anteriormente su arquitectura de almacenamiento original de Cosmos con SeiDB, seguida de la separación de almacenamiento de estado que ahora se está introduciendo en la red principal. FlatKV, LittDB y el sistema de archivo fuera del nodo formarán la siguiente etapa a medida que lleguen a través de versiones posteriores.
Los usuarios y desarrolladores de aplicaciones no necesitan tomar medidas durante la migración, según Sei, con saldos, contratos inteligentes, registros históricos y puntos finales RPC existentes permaneciendo disponibles. Los operadores de nodos han recibido una guía de migración que cubre banderas de configuración y el proceso de reversión documentado para el nuevo sistema de almacenamiento.
