Redes de prueba para blockchain: Guía completa DevOps 2025
Antes de desplegar un smart contract en mainnet o ejecutar una transacción que involucre fondos reales, todo equipo DevOps necesita un entorno donde probar de forma segura. Las redes de prueba (testnets) y las redes de desarrollo local (devnets) cumplen exactamente esa función: replican el comportamiento de la red principal sin poner en riesgo activos reales. En esta guía cubrimos las testnets mas relevantes del ecosistema Ethereum, las herramientas para desarrollo local, estrategias de testing y como integrar todo en pipelines de CI/CD.
Que son las testnets y por que importan
Una testnet es una red blockchain independiente que utiliza el mismo protocolo que la red principal (mainnet) pero opera con tokens sin valor economico real. Su propósito es permitir a desarrolladores y operadores:
- Desplegar y probar smart contracts antes de la puesta en producción.
- Validar cambios en la infraestructura de nodos sin consecuencias financieras.
- Experimentar con nuevas versiones de clientes de ejecución y consenso.
- Realizar pruebas de carga y estres sobre la red.
- Entrenar a equipos en operaciones blockchain sin riesgo.
La diferencia fundamental con mainnet es que los tokens de testnet no tienen valor de mercado. Se obtienen gratuitamente a traves de faucets y el único coste es el tiempo y los recursos computacionales necesarios para operar nodos en estas redes.
Testnets publicas de Ethereum
Despues de la transición a Proof of Stake (The Merge), el ecosistema de testnets de Ethereum se reorganizo. Las redes de prueba activas actualmente son:
Sepolia
Sepolia es la testnet recomendada para desarrollo de aplicaciones y smart contracts. Sus caracteristicas principales:
- Conjunto de validadores controlado: Opera con un set de validadores permisionados, lo que la hace mas estable y predecible que redes abiertas.
- Tiempo de bloque: Aproximadamente 12 segundos, identico a mainnet.
- Soporte amplio: Todos los clientes principales de Ethereum la soportan.
- Faucets disponibles: Existen multiples faucets como el de Alchemy, Infura y el propio de Sepolia.
Sepolia es ideal para probar despliegues de dApps, interacciones con contratos y flujos de usuario completos.
Holesky
Holesky es la testnet diseñada específicamente para pruebas de infraestructura de staking y validadores:
- Red abierta de validadores: Cualquiera puede ejecutar un validador, lo que permite probar toda la infraestructura de staking.
- Gran cantidad de ETH de prueba: Distribuye cantidades significativas de ETH para facilitar pruebas de staking.
- Escala realista: Disenada para operar con una cantidad de validadores comparable a mainnet.
Si tu trabajo involucra operar validadores, probar configuraciones de clientes de consenso o evaluar infraestructura de staking, Holesky es la red indicada.
Redes de desarrollo local (devnets)
Para desarrollo iterativo rápido, las testnets publicas tienen una limitación: dependen de la red y sus tiempos de bloque. Las devnets locales eliminan esa dependencia.
Hardhat Network
Hardhat es uno de los frameworks de desarrollo mas populares para Ethereum. Su red local integrada ofrece:
// hardhat.config.js
module.exports = {
networks: {
hardhat: {
chainId: 31337,
mining: {
auto: true, // Mina un bloque por cada transaccion
interval: 0 // Sin delay entre bloques
},
accounts: {
count: 20,
accountsBalance: "10000000000000000000000" // 10000 ETH
}
}
}
};
Ventajas de Hardhat Network:
- Minado instantaneo: Cada transacción genera un bloque inmediatamente.
- Forking de mainnet: Permite hacer fork del estado real de mainnet para pruebas con datos reales.
- Console.log en Solidity: Facilita enormemente el debugging de smart contracts.
- Trazas detalladas: Muestra stack traces completos cuando una transacción falla.
Anvil (Foundry)
Anvil es la devnet local del framework Foundry, escrito en Rust, conocido por su velocidad:
# Iniciar Anvil con configuracion personalizada
anvil \
--fork-url https://eth-mainnet.alchemyapi.io/v2/TU_API_KEY \
--fork-block-number 18000000 \
--block-time 12 \
--accounts 10 \
--balance 10000 \
--port 8545
# Anvil expone un endpoint RPC compatible con cualquier herramienta Ethereum
Anvil destaca por:
- Rendimiento superior: Significativamente mas rápido que alternativas en JavaScript.
- Compatibilidad total con cheatcodes: Permite manipular el estado de la EVM para testing avanzado.
- Fork preciso: Soporta fork desde cualquier bloque de mainnet o testnets.
Ganache
Ganache fue una de las primeras herramientas de desarrollo local para Ethereum. Aunque su desarrollo ha sido descontinuado en favor de Hardhat y Foundry, sigue siendo utilizado en proyectos legacy:
# Iniciar Ganache CLI
ganache --port 8545 --networkId 1337 --accounts 10 --defaultBalanceEther 100
Para proyectos nuevos, se recomienda migrar a Hardhat Network o Anvil.
Faucets: obtención de tokens de prueba
Para interactuar con testnets publicas se necesitan tokens de prueba. Los faucets mas confiables incluyen:
- Alchemy Sepolia Faucet: Requiere cuenta de Alchemy, distribuye Sepolia ETH.
- Infura Sepolia Faucet: Integrado con el dashboard de Infura.
- Google Cloud Web3 Faucet: Disponible para Sepolia y Holesky.
- PoW Faucet: Algunos faucets requieren resolver un pequeño Proof of Work para evitar abuso.
Es comun que los faucets limiten la cantidad de ETH por solicitud y por período de tiempo. Para pruebas intensivas, conviene combinar multiples faucets o utilizar devnets locales.
Diferencias clave entre testnet y mainnet
Aunque las testnets replican el comportamiento de mainnet, existen diferencias importantes que todo equipo DevOps debe considerar:
| Aspecto | Mainnet | Testnet |
|---|---|---|
| Valor de tokens | Real | Ninguno |
| Validadores | Miles, distribuidos globalmente | Limitados o controlados |
| Estabilidad | Alta | Variable (pueden reiniciarse) |
| Gas prices | Fluctuantes segun demanda | Generalmente bajos y estables |
| Datos historicos | Completos desde genesis | Pueden ser reseteados |
| Disponibilidad de RPC | Alta, multiples proveedores | Menor, posibles interrupciones |
Un error comun es asumir que si algo funciona en testnet, funcionara identicamente en mainnet. Las condiciones de red, la competencia por espacio de bloque y el comportamiento de MEV son fundamentalmente diferentes.
Estrategias de testing para blockchain
Un enfoque robusto de testing para proyectos blockchain combina multiples niveles:
Tests unitarios
Verifican funciones individuales de smart contracts de forma aislada:
// test/Token.test.js (Hardhat + ethers.js)
describe("Token", function () {
it("debe asignar el supply total al deployer", async function () {
const [owner] = await ethers.getSigners();
const Token = await ethers.getContractFactory("Token");
const token = await Token.deploy(1000000);
expect(await token.balanceOf(owner.address)).to.equal(1000000);
});
});
Tests de integración
Verifican la interacción entre multiples contratos y componentes:
describe("DEX Integration", function () {
it("debe completar un swap entre dos tokens", async function () {
// Deploy de tokens y pool de liquidez
const tokenA = await deployToken("TokenA", 1000000);
const tokenB = await deployToken("TokenB", 1000000);
const dex = await deployDEX(tokenA.address, tokenB.address);
// Aprobar y ejecutar swap
await tokenA.approve(dex.address, 1000);
await dex.swap(tokenA.address, tokenB.address, 1000);
// Verificar balances resultantes
expect(await tokenA.balanceOf(dex.address)).to.equal(1000);
});
});
Tests en fork de mainnet
Permiten probar contra el estado real de la red:
# Ejecutar tests contra un fork de mainnet
npx hardhat test --fork https://eth-mainnet.alchemyapi.io/v2/TU_KEY
Tests en testnet pública
Validan el comportamiento en una red real con latencia y condiciones de red reales.
Integración con CI/CD
La integración de testing blockchain en pipelines de CI/CD es fundamental para equipos profesionales:
# .github/workflows/blockchain-tests.yml
name: Blockchain Tests
on: [push, pull_request]
jobs:
unit-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Instalar dependencias
run: npm ci
- name: Compilar contratos
run: npx hardhat compile
- name: Tests unitarios (red local)
run: npx hardhat test
- name: Tests con fork de mainnet
run: npx hardhat test --network hardhat
env:
FORK_URL: ${{ secrets.ALCHEMY_MAINNET_URL }}
testnet-deploy:
needs: unit-tests
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main'
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Instalar dependencias
run: npm ci
- name: Deploy a Sepolia
run: npx hardhat run scripts/deploy.js --network sepolia
env:
SEPOLIA_RPC_URL: ${{ secrets.SEPOLIA_RPC_URL }}
DEPLOYER_PRIVATE_KEY: ${{ secrets.DEPLOYER_PRIVATE_KEY }}
- name: Verificar contrato en Etherscan
run: npx hardhat verify --network sepolia ${{ env.CONTRACT_ADDRESS }}
Este pipeline ejecuta tests unitarios en una red local (rápido y sin dependencias externas), luego tests con fork de mainnet para validar interacciones reales, y finalmente despliega a Sepolia solo cuando el código llega a la rama principal.
Mejores prácticas DevOps para testnets
- Separar claramente los entornos: Mantener configuraciones independientes para devnet local, testnet y mainnet. Nunca reutilizar claves privadas entre entornos.
- Automatizar la obtención de fondos: Crear scripts que soliciten ETH de faucets automáticamente cuando los balances sean bajos.
- Monitorear las testnets: Aunque sean redes de prueba, monitorear la salud de los nodos y la conectividad evita sorpresas.
- Documentar las diferencias: Mantener un registro de las divergencias conocidas entre testnet y mainnet.
- Rotar testnets: Estar preparado para migrar si una testnet es descontinuada, como ocurrio con Ropsten y Rinkeby.
Conclusion
Las redes de prueba son una pieza fundamental en el ciclo de desarrollo blockchain. Desde las devnets locales como Hardhat Network y Anvil para iteración rápida, hasta las testnets publicas como Sepolia y Holesky para validación en condiciones reales, cada herramienta cumple un rol específico. La integración de estas redes en pipelines de CI/CD permite a los equipos DevOps mantener la calidad y seguridad del código antes de interactuar con mainnet, donde los errores tienen consecuencias economicas reales.