Todas las redes blockchain: cómo crear un inventario funcional para tu proyecto

Por qué una lista universal de todas las blockchains no se mantiene verdadera

Las búsquedas de todas las redes blockchain suelen devolver dos tipos de páginas: listas enciclopédicas que enumeran cientos de cadenas y explicaciones que definen qué es una blockchain. Ambas son puntos de partida útiles, pero ninguna es una referencia operativa confiable. Una lista de blockchains es un documento dinámico. Se lanzan nuevas redes de capa 1 y capa 2, las testnets se reinician o se deprecan, las bifurcaciones dividen cadenas existentes y algunas redes se cierran por completo. La propia lista de blockchains de Wikipedia incluye un aviso explícito de incompletitud por esta razón.

Para el trabajo de ingeniería, la pregunta no es "cuáles son todas las blockchains" en abstracto, sino "de qué redes depende mi sistema y cuál es la identidad verificada de cada una?". La identidad de una cadena se ancla en su chain ID, su bloque génesis y los metadatos de su moneda nativa. Esos son los campos que puedes probar. Los nombres y las descripciones de marketing no son comprobables y cambian con el tiempo.

Por lo tanto, esta guía trata el tema como un problema de inventario. Delimitarás la lista a tu proyecto, verificarás cada entrada contra un endpoint RPC en vivo y almacenarás los resultados en una tabla que puedas volver a ejecutar siempre que sospeches de una desviación.

• Las listas enciclopédicas son instantáneas y explícitamente incompletas.
• La identidad de una cadena es verificable mediante el chain ID y los datos del génesis.
• Tu inventario debe limitarse a las cadenas que tu código realmente utiliza.

Delimitar el inventario antes de recopilar nada

Antes de recopilar datos de cadenas, clasifica cada red con la que interactúa tu proyecto. La mayoría de las aplicaciones multicadena se dividen en cuatro categorías: redes de capa 1 de producción, rollups de capa 2 de producción, testnets usadas en CI o staging y cadenas de archivo o de solo lectura usadas para análisis. Cada categoría tiene diferentes requisitos de confiabilidad, y mezclarlas en una lista plana hace que la verificación sea ruidosa.

Un ejercicio de delimitación útil es buscar en tu base de código y en la configuración de infraestructura identificadores de cadena. Busca constantes de chain ID, variables de entorno de URL RPC, registros de despliegue de contratos y configuración de puentes. Todo lo que aparezca en un manifiesto de despliegue es crítico para producción; todo lo que aparezca solo en fixtures de prueba se puede verificar con menos frecuencia.

Una vez delimitado, asigna a cada cadena un rol: liquidación primaria, ejecución, disponibilidad de datos o referencia de solo lectura. Este rol determina con qué frecuencia vuelves a verificar la entrada y cuánta redundancia necesita el endpoint. Para la selección de endpoints en muchas cadenas, la guía de endpoints RPC multicadena en /en/learn/multi-chain-rpc-endpoints-guide cubre las ventajas y desventajas entre gateways compartidos y proveedores por cadena.

• Las L1 de producción, los rollups L2, las testnets y las cadenas de archivo necesitan cadencias de verificación separadas.
• Busca chain IDs, URL RPC y manifiestos de despliegue para encontrar dependencias implícitas.
• Asigna un rol a cada cadena para que el esfuerzo de verificación coincida con su criticidad.

El modelo mental: identidad de la cadena frente a identidad del endpoint

Una fuente común de errores es confundir una cadena con el endpoint que la sirve. La cadena es el libro contable canónico definido por su bloque génesis y sus reglas de consenso. El endpoint es un servicio que responde llamadas JSON-RPC sobre esa cadena. Una cadena puede ser servida por muchos endpoints, y un proveedor de endpoints puede servir muchas cadenas. Tu inventario debe registrar ambas capas por separado.

En la capa de cadena, registra el chain ID, el hash del bloque génesis cuando esté disponible, el símbolo y los decimales de la moneda nativa, y la URL del explorador de bloques. En la capa de endpoint, registra el proveedor, el patrón de URL, el método de autenticación y los límites de velocidad. Cuando falla una llamada, esta separación te indica si cambió la cadena o el endpoint.

Este modelo también explica por qué las comprobaciones de chain ID importan tanto. Un endpoint mal configurado que apunta a la red equivocada aceptará transacciones y las firmará para la cadena incorrecta sin problema. Verificar el chain ID antes de cada ruta de escritura es un seguro barato. La explicación sobre nonces en /en/learn/what-is-a-blockchain-nonce es un complemento útil para entender cómo la secuenciación de transacciones interactúa con la corrección del endpoint.

• Identidad de la cadena: chain ID, hash del génesis, moneda nativa, explorador.
• Identidad del endpoint: proveedor, URL, autenticación, límites de velocidad, métodos soportados.
• Verifica el chain ID en cada ruta de escritura para evitar errores de firma entre cadenas.

Recopilar cadenas candidatas de múltiples fuentes

Ninguna fuente única enumera todas las blockchains de forma completa, así que triangula. Comienza con el registro de cadenas mantenido por tu proveedor de wallet o SDK, haz referencias cruzadas con directorios de exploradores de bloques y agrega cualquier cadena que aparezca en tu propio grafo de dependencias. Trata cada fuente como un generador de candidatos, no como la verdad.

Para cada candidato, registra la fuente de la que provino y la fecha en que lo capturaste. Esta procedencia importa cuando dos fuentes discrepan sobre un chain ID o un símbolo de moneda. Las discrepancias son comunes en cadenas bifurcadas y en testnets que reutilizan nombres.

Cuando necesites un endpoint concreto para una cadena específica, el RPC Assistant cubre recomendaciones de redes individuales. Por ejemplo, la guía de endpoints RPC de Arbitrum en /en/learn/arbitrum-rpc-endpoints y la guía de proveedores de Solana en /en/learn/best-solana-rpc-provider abordan la elección de endpoints por cadena. Úsalas para la selección de endpoints y mantén este artículo centrado en el método de inventario.

• Triangula desde registros de wallets, directorios de exploradores y tu propio código.
• Registra la procedencia y la fecha de captura de cada candidato.
• Resuelve las discrepancias probando contra datos de la cadena en vivo, no confiando en la fuente que más insiste.

Verificar chain IDs y metadatos con curl

La verificación más rápida es una llamada JSON-RPC directa. El método eth_chainId devuelve el chain ID como una cadena hexadecimal. Compáralo con tu valor esperado después de convertirlo a decimal. El siguiente script itera sobre una lista de candidatos e imprime un resultado de aprobado o fallido para cada entrada.

Reemplaza RPC_URL_* con tus endpoints reales. No codifiques endpoints públicos directamente en scripts de producción; usa variables de entorno o un gestor de secretos.

#!/usr/bin/env bash
set -euo pipefail

declare -A CHAINS=(
  [ethereum]="${RPC_URL_ETHEREUM}"
  [arbitrum]="${RPC_URL_ARBITRUM}"
  [base]="${RPC_URL_BASE}"
)

declare -A EXPECTED=(
  [ethereum]=1
  [arbitrum]=42161
  [base]=8453
)

for name in "${!CHAINS[@]}"; do
  url="${CHAINS[$name]}"
  hex=$(curl -s -X POST "$url" \
    -H 'Content-Type: application/json' \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' \
    | python3 -c 'import sys,json; print(json.load(sys.stdin)["result"])')
  actual=$((hex))
  if [[ "$actual" -eq "${EXPECTED[$name]}" ]]; then
    echo "PASS $name chainId=$actual"
  else
    echo "FAIL $name expected=${EXPECTED[$name]} actual=$actual"
  fi
done

Verificar la salud del endpoint y el progreso de bloques con JavaScript

El chain ID por sí solo no demuestra que un endpoint esté saludable. Un endpoint puede informar el chain ID correcto mientras está retrasado respecto de la cabeza de la cadena o falla al servir estado histórico. Agrega una segunda comprobación que compare el último número de bloque del endpoint con un endpoint de referencia o con el explorador público de la cadena.

El siguiente script consulta eth_blockNumber y eth_getBlockByNumber para el último bloque, luego imprime la marca de tiempo del bloque. Una gran diferencia entre la marca de tiempo del bloque y la hora real indica un endpoint retrasado. Ejecuta esto desde la misma región que tu carga de trabajo de producción, porque la latencia y la disponibilidad varían según la geografía.

Esta es una medición que debes ejecutar tú mismo. No asumas que el uptime publicado por un proveedor refleja tu región o tu combinación de métodos.

const endpoints = {
  ethereum: process.env.RPC_URL_ETHEREUM,
  arbitrum: process.env.RPC_URL_ARBITRUM,
};

async function rpc(url, method, params = []) {
  const res = await fetch(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;
}

for (const [name, url] of Object.entries(endpoints)) {
  const blockHex = await rpc(url, 'eth_blockNumber');
  const block = await rpc(url, 'eth_getBlockByNumber', [blockHex, false]);
  const ts = Number(BigInt(block.timestamp) * 1000n);
  const lagSeconds = Math.round((Date.now() - ts) / 1000);
  console.log(`${name} block=${Number(blockHex)} lag=${lagSeconds}s`);
}

Registrar los resultados en una tabla reproducible

Almacena la salida de la verificación en una tabla para que puedas comparar ejecuciones a lo largo del tiempo. La siguiente tabla es una plantilla; complétala con los valores que producen tus scripts. No copies números de ninguna fuente externa, incluido este artículo.

Ejecuta la tabla según un calendario, como mínimo antes de cada despliegue a producción y después de cualquier cambio de proveedor. Mantén las ejecuciones históricas en control de versiones para que puedas correlacionar incidentes con desviaciones de endpoints. Si operas infraestructura dedicada, la guía de nodos dedicados en /en/dedicated-node explica cómo controlar directamente la capa de endpoints en lugar de depender de un gateway compartido.

Solución de problemas comunes del inventario

Cuando falla una verificación, la causa suele caer en una de cuatro categorías. Distinguirlas rápidamente ahorra tiempo.

Primero, discrepancia de chain ID. Esto casi siempre significa que la URL del endpoint apunta a una red diferente de la prevista, a menudo una testnet o una bifurcación. Verifica la URL con la documentación de tu proveedor y confirma que la variable de entorno esté configurada en el entorno correcto.

Segundo, retraso de bloque. Un endpoint retrasado puede tener límite de velocidad, estar geográficamente distante o servir un nodo podado. Compáralo con un segundo endpoint para la misma cadena. Si ambos están retrasados, la propia cadena puede estar experimentando problemas de finalidad.

Tercero, método no soportado. Algunos endpoints restringen consultas históricas o métodos de depuración. Si tu inventario incluye lecturas de archivo, verifica esos métodos explícitamente en lugar de asumir que el éxito de eth_chainId implica soporte completo.

Cuarto, fallo de autenticación. Las claves API expiran, rotan o están limitadas a cadenas específicas. Una respuesta 401 o 403 debe registrarse de forma distinta a un error JSON-RPC para que puedas dirigirla a la rotación de guardia correcta.

• Discrepancia de chain ID: URL incorrecta o entorno incorrecto.
• Retraso de bloque: límites de velocidad, distancia o estado podado.
• Método no soportado: verifica las llamadas de archivo y depuración por separado.
• Fallo de autenticación: claves API expiradas o mal delimitadas.

Limitaciones y compensaciones de cualquier inventario de cadenas

Todo inventario es una instantánea. Las cadenas se lanzan, las testnets se reinician y los proveedores cambian sus listas de redes soportadas. Una lista precisa hoy puede ser incorrecta el próximo trimestre. Presupuesta la reverificación en lugar de asumir completitud.

También hay una compensación de costos. Verificar cada cadena en cada despliegue es costoso en tiempo y llamadas API. Clasifica tus comprobaciones por niveles: cadenas de liquidación críticas en cada despliegue, cadenas de ejecución a diario, testnets semanalmente, cadenas de archivo bajo demanda. Esto ajusta el esfuerzo de verificación al radio de impacto.

Por último, sé cauteloso al tratar cualquier lista de terceros como autoritativa. Las listas mantenidas por proveedores de wallets optimizan la compatibilidad con wallets, no las necesidades de tu aplicación. Las listas mantenidas por exploradores optimizan la cobertura del explorador. Ninguna sustituye la prueba de los métodos específicos que llama tu código.

Próximos pasos: automatizar y ampliar el inventario

Mueve los scripts de verificación a tu canal de CI como puerta previa al despliegue. Haz que la compilación falle si el chain ID de una cadena de producción no coincide con el valor esperado. Esto detecta desviaciones de configuración antes de que lleguen a los usuarios.

Amplía el inventario con direcciones de contratos por cadena. Una entrada de cadena está incompleta sin las direcciones de los contratos que llama tu aplicación, y esas direcciones difieren entre redes. Almacénalas junto con los metadatos de la cadena para que una sola consulta devuelva todo lo necesario para construir una transacción.

Para la selección de endpoints entre las cadenas de tu inventario, revisa los precios y la cobertura de red en /en/pricing/rpc y /en/networks, y consulta el RPC Assistant para recomendaciones por cadena. La guía de alojamiento de nodos blockchain en /en/learn/blockchain-node-hosting-guide cubre el lado operativo de ejecutar tus propios nodos para cadenas donde los endpoints compartidos son insuficientes.

Vuelve a ejecutar la tabla de verificación después de cada cambio de proveedor y después de cada actualización importante de la cadena. Trata el inventario como un artefacto vivo, no como un documento único.

• Agrega comprobaciones de chain ID a CI como puerta previa al despliegue.
• Registra las direcciones de contratos por cadena junto con los metadatos de la cadena.
• Vuelve a verificar después de cambios de proveedor y actualizaciones de cadena.