Cómo crear una cadena blockchain: desde el génesis hasta una red local verificable

Qué implica realmente crear una cadena

Una cadena blockchain no es un solo archivo ni un solo comando. Es un conjunto de parámetros acordados (ID de cadena, estado génesis, reglas de consenso, calendario de bifurcaciones), un conjunto de nodos que validan esos parámetros y una red peer-to-peer que propaga bloques entre ellos. Crear una cadena significa definir ese acuerdo y luego ejecutar software que lo haga cumplir.

Este artículo se centra en cadenas compatibles con EVM porque las herramientas están ampliamente documentadas y son fáciles de verificar. El mismo modelo mental se aplica a cadenas no EVM: define el génesis, configura el nodo, arráncalo y verifica a través de la interfaz RPC nativa de la cadena. Si solo necesitas conectarte a una red existente en lugar de crear una, el trabajo de selección de endpoints corresponde a RPC Assistant; esta página se mantiene en el flujo de creación y verificación.

• Génesis: el estado inicial y los parámetros de toda la cadena.
• Consenso: cómo se producen y finalizan los bloques.
• Configuración del nodo: directorio de datos, puertos, pares y exposición RPC.
• Verificación: demostrar que la cadena responde correctamente a llamadas estándar.

Requisitos previos y supuestos

Necesitas una máquina con Docker o un cliente EVM nativo instalado, un rango de puertos locales libres y familiaridad básica con la línea de comandos. Los ejemplos siguientes usan marcadores como RPC_URL y PRIVATE_KEY; nunca confirmes claves reales en un repositorio. Para redes de producción o compartidas, planifica infraestructura dedicada en lugar de un portátil, y revisa las opciones de nodo dedicado antes de exponer algo públicamente.

Supuestos: primero estás construyendo una cadena privada o de prueba, controlas todos los validadores iniciales y no puentearás activos reales hasta que la cadena haya sido revisada de forma independiente. Crear una cadena es sencillo; operarla de forma segura es el problema más difícil.

Definir el archivo génesis

El archivo génesis es la raíz de confianza de una nueva cadena. Cada nodo debe usar un archivo génesis idéntico byte a byte, o los nodos rechazarán los bloques de los demás. Como mínimo, define el ID de cadena, los saldos iniciales de las cuentas, el límite de gas y la configuración de consenso. El ejemplo siguiente es un génesis de desarrollo mínimo; reemplaza la dirección de asignación por una que controles.

Mantén el archivo génesis bajo control de versiones y registra su hash. Cuando más adelante cambies el consenso o los parámetros de bifurcación, estarás creando efectivamente una nueva cadena, así que trata esos cambios como rupturistas.

{
  "config": {
    "chainId": 1337,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0,
    "berlinBlock": 0,
    "londonBlock": 0,
    "clique": { "period": 5, "epoch": 30000 }
  },
  "difficulty": "0x1",
  "gasLimit": "0x1c9c380",
  "alloc": {
    "0x0000000000000000000000000000000000000001": {
      "balance": "0xde0b6b3a7640000"
    }
  }
}

Configurar e iniciar el primer nodo

Con el génesis definido, inicializa el directorio de datos del nodo y arráncalo con RPC habilitado solo en localhost. Los indicadores exactos dependen de tu cliente; el patrón es consistente: apunta al génesis, establece el directorio de datos, habilita el espacio de nombres HTTP RPC que necesites y restringe el enlace de host hasta que hayas verificado la cadena.

El comando siguiente usa un nombre genérico de binario de cliente como marcador. Sustituye el binario que instalaste y confirma los nombres de los indicadores en la documentación de ese cliente, ya que los indicadores difieren entre clientes y versiones.

# Initialize the data directory with the genesis file
your-client init --datadir ./chain-data genesis.json

# Start the node with local-only RPC
your-client \
  --datadir ./chain-data \
  --networkid 1337 \
  --http \
  --http.addr 127.0.0.1 \
  --http.port 8545 \
  --http.api eth,net,web3 \
  --mine \
  --miner.etherbase 0x0000000000000000000000000000000000000001

Verificar la cadena mediante JSON-RPC

Una cadena solo es real cuando responde a llamadas estándar. Usa curl para confirmar el ID de cadena y luego confirma que se están produciendo bloques. Establece RPC_URL en tu endpoint local, por ejemplo http://127.0.0.1:8545. Estas llamadas son de solo lectura y seguras de repetir.

El resultado esperado es un ID de cadena que coincida con tu génesis y un número de bloque que aumente con el tiempo. Si el ID de cadena es incorrecto, tu nodo está leyendo un génesis diferente. Si el número de bloque permanece en cero, la producción de bloques no está en marcha.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}'

Un procedimiento de medición repetible

No confíes en una sola llamada exitosa. Ejecuta un script corto que muestree la cadena a lo largo del tiempo y registre los resultados. La tabla siguiente es una plantilla: completa los valores observados de tu propia ejecución en lugar de copiar números de cualquier otro lugar. Esto mantiene tu verificación honesta y reproducible.

El fragmento de JavaScript siguiente automatiza el muestreo. Utiliza el fetch integrado disponible en Node.js moderno y escribe un resumen simple de aprobado/fallido. Reemplaza RPC_URL con tu endpoint.

const RPC_URL = process.env.RPC_URL;

async function call(method, params = []) {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
  });
  const json = await res.json();
  if (json.error) throw new Error(json.error.message);
  return json.result;
}

(async () => {
  const chainId = await call('eth_chainId');
  const first = await call('eth_blockNumber');
  await new Promise(r => setTimeout(r, 12000));
  const second = await call('eth_blockNumber');
  const advanced = parseInt(second, 16) > parseInt(first, 16);
  console.log({ chainId, first, second, advanced });
})();

Añadir un segundo nodo y confirmar el consenso

Un solo nodo demuestra que el software funciona; dos nodos demuestran que la red funciona. Inicia un segundo nodo con el mismo génesis e ID de red, luego conéctalo al primero usando la URL enode del primer nodo. Confirma que net_peerCount aumenta en ambos nodos y que ambos reportan el mismo hash del último bloque.

Si el segundo nodo rechaza bloques o nunca se sincroniza, las causas más comunes son un hash de génesis que no coincide, un ID de red diferente o un firewall que bloquea el puerto peer-to-peer. Compara el hash del génesis en ambas máquinas antes de depurar cualquier otra cosa.

Solución de problemas en el primer arranque

La mayoría de los fallos al crear una cadena se engloban en un pequeño número de categorías. Recórrelas en orden, porque los síntomas posteriores a menudo desaparecen una vez que se corrige una causa anterior.

Si el nodo sale inmediatamente, verifica que el directorio de datos se inicializó con el génesis correcto y que el binario admite los indicadores que pasaste. Si las llamadas RPC fallan, confirma que el servidor HTTP está habilitado y vinculado a la dirección a la que estás llamando. Si no se producen bloques, confirma la configuración de minería o validador y que la cuenta firmante esté desbloqueada o configurada correctamente.

• Discrepancia de génesis: los nodos rechazan pares silenciosamente; compara los hashes del génesis.
• Conflictos de puertos: otro proceso ocupa el 8545 o el puerto P2P.
• Espacio de nombres RPC deshabilitado: el método devuelve 'method not found'.
• Desfase de reloj: las marcas de tiempo provocan el rechazo de bloques en algunos motores de consenso.
• Disco insuficiente: el nodo deja de escribir y parece colgarse.

Limitaciones y compensaciones

Una cadena creada localmente es un artefacto de desarrollo, no una red de producción. No tiene seguridad económica, ni validadores independientes, ni resiliencia ante fallos del operador. Avanzar hacia producción requiere incorporación de validadores, monitoreo, gobernanza de actualizaciones y un plan para la disponibilidad de RPC.

Ejecutar tu propia capa RPC te da control pero añade carga operativa: tiempo de actividad, limitación de velocidad y actualizaciones de versión. Muchos equipos mantienen un nodo autoalojado para validación y usan un servicio gestionado para el tráfico de lectura público. La guía de endpoints RPC explica cómo pensar en esa división, y los precios de RPC ayudan a estimar el costo de servir tráfico externo.

Próximos pasos una vez que la cadena funciona

Una vez que tu cadena produce bloques y un segundo nodo se sincroniza, el siguiente trabajo es herramientas y acceso. Despliega un contrato de prueba, conecta una billetera y confirma que los registros y recibos se comportan como se espera. Luego decide cómo los desarrolladores externos llegarán a la cadena.

Si planeas exponer la cadena a otros equipos, revisa las opciones de servicio de API y la lista de redes compatibles para entender cómo se estructura el acceso gestionado. Para recomendaciones específicas de endpoints, usa RPC Assistant en lugar de adivinar URLs públicas. Mantén tu archivo génesis, la configuración del nodo y los scripts de verificación juntos para que cualquiera del equipo pueda reconstruir la cadena desde cero.