Nuestra experiencia en la migración de Ethermint a Evmos
Por Vitaliy Obrevko
- Publicado el
- Actualizado el
- 6 min de lectura

Nuestro proyecto reciente se enfrentó a desafíos por culpa de Ethermint, una blockchain obsoleta basada en la EVM. Para resolverlos, decidimos pasar a una nueva solución blockchain basada en Evmos. Este artículo describe nuestro recorrido, desde los problemas iniciales hasta una transición fluida.
Puntos clave
- La blockchain basada en Ethermint se detenía sin aviso cada 2 o 3 meses aproximadamente y obligaba a reiniciar los nodos a mano, y su equipo había enmudecido, así que pasamos a Evmos.
- Los valores del nonce en la nueva cadena Evmos no pueden coincidir con los de la antigua cadena Ethermint, así que desvinculamos la base de datos del nonce y la asociamos a los números de bloque.
- Un script guardó el estado de todos los tokens emitidos, los saldos y los contratos inteligentes, y simulamos las 2.253 transacciones que debíamos completar en bloques separados de la nueva cadena.
- Desde el paso a Evmos el proyecto ha tenido una disponibilidad del 100 %, una mejora clara frente a las frecuentes interrupciones de la antigua cadena Ethermint.
- A octubre de 2026, el repositorio de Ethermint en GitHub está archivado y es de solo lectura desde el 4 de abril de 2024, y su aviso indica que el equipo responsable centró su trabajo en Evmos.
Pasamos la blockchain EVM de nuestro proyecto de Ethermint a Evmos después de que la cadena antigua se detuviera aproximadamente cada 2 o 3 meses. Uno de los desafíos más importantes fue el nonce, porque sus valores en Evmos no pueden coincidir con los de Ethermint, así que vinculamos la base de datos a los números de bloque y simulamos en bloques separados las 2.253 transacciones que debíamos completar.
En el mundo cambiante de la tecnología blockchain, mantenerse al día con los últimos avances es fundamental para conservar la eficiencia y la fiabilidad. Nuestro proyecto reciente se enfrentó a desafíos importantes por culpa de Ethermint, una blockchain obsoleta basada en la EVM. Para resolverlos, decidimos pasar a una nueva solución blockchain basada en Evmos. Este artículo describe nuestro recorrido, desde la identificación de los problemas iniciales hasta una transición fluida con una disponibilidad del 100 %.
El problema con Ethermint
Nuestro proyecto se apoyaba inicialmente en una blockchain basada en Ethermint que, aunque funcionaba, resultó ser cada vez menos fiable. Aproximadamente cada 2 o 3 meses, la blockchain se detenía de forma inesperada y obligaba a reiniciar los nodos manualmente. Este problema interrumpía nuestras operaciones y suponía un riesgo importante para la satisfacción y la confianza de los usuarios.
Ante la falta total de actividad del equipo de Ethermint y la disponibilidad de alternativas, resultó evidente que seguir con la blockchain basada en Ethermint no era sostenible a largo plazo.
La decisión de cambiar a Evmos
Tras una investigación y una reflexión minuciosas, decidimos cambiar a una solución blockchain basada en la siguiente versión de Ethermint, Evmos. Evmos busca ser compatible con la EVM y los contratos inteligentes. Por eso, si ya tiene una aplicación EVM funcionando en Ethereum o en una cadena compatible con la EVM, puede migrar fácilmente a Evmos y ofrecer su aplicación al ecosistema Cosmos.
La decisión obedeció a varios factores, entre ellos la arquitectura mejorada de Evmos y su compatibilidad con nuestros sistemas existentes. Esperábamos un funcionamiento más fluido y menos interrupciones, algo fundamental para mantener la confianza de los usuarios y la eficiencia operativa. La fase de planificación incluyó evaluaciones detalladas y análisis de riesgos para asegurar una transición bien fundamentada.
A octubre de 2026, el repositorio de Ethermint en GitHub fue archivado por su propietario el 4 de abril de 2024 y es de solo lectura. Su aviso indica que el equipo responsable ha centrado por completo su trabajo en Evmos y que el repositorio ya no recibe mantenimiento. Los equipos que hoy quieran compatibilidad con la EVM en una cadena Cosmos SDK también pueden mirar Cosmos EVM, que se describe a sí mismo como una bifurcación (fork) de evmOS.
Cómo resolvimos el problema del nonce
Un nonce es un número o valor que solo se puede usar una vez. Los nonces se emplean con frecuencia en protocolos de autenticación y en funciones hash criptográficas. En el contexto de la tecnología blockchain, un nonce es un número pseudoaleatorio que se utiliza como contador durante el proceso de minería.
Uno de los desafíos más importantes que afrontamos durante la transición fue el problema con los valores del nonce. Los valores del nonce en la nueva blockchain Evmos no pueden coincidir con los de la antigua blockchain Ethermint. Esta discrepancia suponía un obstáculo importante, ya que parte de los datos de los clientes y de las funciones del backend dependían de ese valor.
La solución a este problema consiste en desvincular por completo la base de datos de ese valor y asociarla a los números de bloque (algo que, en realidad, debería haberse hecho desde el principio).
Fase de transición, migración de tokens, saldos y contratos
Ejecutamos un script que guardó el estado de todos los tokens emitidos, los saldos de los usuarios y el estado de los contratos inteligentes.
const pullAccounts = async (db: DB) => {
console.log('Pulling accounts...')
const accounts = await db.select().from(wallet_account);
const addresses = accounts.map(a => a.address);
const dataDir = path.join(__dirname, '../data', ENV, 'accounts.json');
await fs.writeFile(dataDir, JSON.stringify(addresses, null, 2));
console.log(`Pulled ${addresses.length} accounts`);
}
const pullProjects = async (db: DB) => {
console.log('Pulling projects...');
const projects = await db.select().from(project);
const ids = projects.map(p => p.nft_contract_id);
const txs = await db.select().from(transaction).where(inArray(transaction.id, ids));
const dataDir = path.join(__dirname, '../data', ENV, 'projects.json');
await fs.writeFile(dataDir, JSON.stringify(txs, null, 2));
console.log(`Pulled ${txs.length} projects`);
}
const pullTokens = async (db: DB) => {
console.log('Pulling tokens...');
const tokens = await db.select().from(token);
const ids = tokens.map(t => t.blockchain_reference);
const txs = await db.select().from(transaction).where(inArray(transaction.id, ids.map(Number)));
const dataDir = path.join(__dirname, '../data', ENV, 'tokens.json');
await fs.writeFile(dataDir, JSON.stringify(txs, null, 2));
console.log(`Pulled ${txs.length} tokens`);
}
const main = async () => {
console.log(`Pulling ${ENV} data...`);
const {db, close} = await getDb();
await pullAccounts(db);
await pullProjects(db);
await pullTokens(db);
console.log('Done');
close();
};En ese momento, los nuevos nodos ya estaban listos para arrancar.
El siguiente paso fue la generación del bloque génesis en la nueva blockchain. Queríamos lanzar de inmediato una nueva blockchain a partir del punto en que se quedó la antigua, pero seguía pendiente el problema de vincular el backend a los bloques.
La salida a esta situación fue simular el número mínimo de transacciones en bloques separados. Por suerte, solo teníamos que completar 2.253 transacciones.
Un ejemplo de script que despliega contratos y transfiere tokens por lotes
const provider = new ethers.JsonRpcProvider('http://160.90.206.47:8545');
const admin = new ethers.Wallet('3AEAFFCOOAE4983C5B9E2B4CEC570C65A3160678B9BDD5CEB3D8BE503198B85E', provider);
const batchTransfer = async () => {
const addresses = await fs.readFile(path.join(__dirname, `../data/${ENV}/accounts.json`), 'utf-8');
const batchTransfer = new ethers.Contract(batchTransferAddress, BatchTransferABI, admin);
await batchTransfer.batchTransfer(JSON.parse(addresses), { gasPrice: 0, value: addresses.length });
console.log('Addresses topped up');
}
const deployProjects = async () => {
const projects = JSON.parse(await fs.readFile(path.join(__dirname, `../data/${ENV}/projects.json`), 'utf-8'));
const p = projects[1];
const data = p.payload.replace('02f93ff48205398205038080832e97488080b93f9f', '')
const tx = await admin.sendTransaction({
value: 0,
data,
gasLimit: 15000000,
gasPrice: 0,
})
await tx.wait();
const receipt = await provider.getTransactionReceipt(tx.hash);
const newContractAddress = receipt.contractAddress;
console.log(newContractAddress);
p.newContractAddress = newContractAddress;
await fs.writeFile(path.join(__dirname, `../data/${ENV}/projects.json`), JSON.stringify(projects, null, 2));
}
const deployTokens = async () => {
const tokens = JSON.parse(await fs.readFile(path.join(__dirname, `../data/${ENV}/tokens.json`), 'utf-8'));
for (const t of tokens) {
const data = '0x' + t.payload.slice(44);
const tx = await admin.sendTransaction({
value: 0,
data,
gasLimit: 15000000,
gasPrice: 0,
})
await tx.wait();
const receipt = await provider.getTransactionReceipt(tx.hash);
const newContractAddress = receipt.contractAddress;
console.log(newContractAddress);
t.newContractAddress = newContractAddress;
await fs.writeFile(path.join(__dirname, `../data/${ENV}/tokens.json`), JSON.stringify(tokens, null, 2));
}
}
const main = async () => {
await batchTransfer();
await deployProjects();
await deployTokens();
}
main()
.then(() => process.exit(0))
.catch((error) => {
console.error(error);
process.exit(1);
});Configurar la nueva blockchain fue sencillo y las primeras pruebas indicaron que todo funcionaba como se esperaba. Así era de esperar, ya que Evmos se creó con la expectativa de facilitar el traslado desde cualquier otra blockchain basada en la EVM.
Sin embargo, al profundizar en el proceso de integración, nos encontramos con varios desafíos específicos de los requisitos de nuestro proyecto.
Cómo garantizar una experiencia de usuario fluida
Un objetivo principal de nuestra transición era que fuera invisible para los usuarios, de modo que no notaran interrupciones ni cambios en la funcionalidad. Lograrlo exigió una planificación y una ejecución meticulosas. Empleamos varias estrategias para garantizar una experiencia de usuario fluida, entre ellas pruebas exhaustivas, despliegues por fases y monitorización continua.
Nuestro enfoque se centró en mantener la integridad de los datos y de las interacciones de los usuarios durante toda la transición. Al simular escenarios reales y realizar pruebas rigurosas, pudimos identificar y resolver posibles problemas antes de que afectaran a los usuarios. Este enfoque proactivo fue decisivo para lograr una transición fluida y mantener la confianza de los usuarios.
Cómo logramos una disponibilidad del 100 %
Cuando se resolvieron todos los desafíos, sustituimos con éxito la antigua blockchain por la nueva solución basada en Evmos. Desde la transición hemos logrado una disponibilidad del 100 %, una mejora importante frente a las frecuentes interrupciones que sufríamos con el sistema antiguo.
Para mantener este alto nivel de fiabilidad, implantamos prácticas sólidas de monitorización y mantenimiento. La monitorización continua del rendimiento nos permite detectar y resolver posibles problemas de forma proactiva, lo que garantiza un servicio ininterrumpido para nuestros usuarios. El éxito de esta transición ha reforzado la importancia de elegir la solución blockchain adecuada y el valor de una planificación y unas pruebas exhaustivas.
Siguiente paso
Sobre el autor
Categoría:Desarrollo de softwareBlockchain
Volver al blog


