Guía de Subnet (L1) de Avalanche: Arquitectura, Despliegue y Verificación RPC

Alcance y respuesta directa

Una subnet de Avalanche es un conjunto dinámico de validadores que acuerdan validar una o más blockchains. Desde la actualización Avalanche9000, el ecosistema llama cada vez más a estas redes L1s de Avalanche, pero la primitiva subyacente de la P-Chain sigue siendo una subnet. Una subnet no hereda el entorno de ejecución de la C-Chain; define su propia membresía de validadores, y cada blockchain desplegada en ella define su propia VM, génesis y reglas de gas.

Este artículo cubre el modelo mental, una ruta de despliegue ejecutable usando Avalanche CLI y subnet-evm, y un procedimiento de diagnóstico para verificar un endpoint RPC de subnet. Asume que tienes familiaridad básica con cadenas EVM, una terminal y acceso a un nodo de Avalanche o a un proveedor RPC gestionado. La selección de endpoints concretos está fuera del alcance aquí; usa el Asistente RPC para recomendaciones de proveedores y redes.

• Comportamiento documentado: registro de subnets en la P-Chain, staking de validadores y carga de plugins de VM.
• Recomendaciones: aislar el tráfico RPC, fijar los IDs de cadena y monitorear la altura de bloque independientemente de tu aplicación.
• Mediciones que debes ejecutar: latencia, tiempo de bloque y finalidad en tu propio endpoint.

Requisitos previos y supuestos

Antes de desplegar, confirma las versiones de las herramientas y el financiamiento. Avalanche CLI envuelve las operaciones de nodo y subnet, pero aún necesita un nodo de Avalanche accesible y una clave financiada en la P-Chain para el registro de validadores. El stake mínimo exacto y el calendario de tarifas cambian con las actualizaciones de la red, así que lee la documentación actual de Avalanche en lugar de confiar en cifras antiguas.

También necesitas una especificación de cadena: elección de VM (subnet-evm para compatibilidad con EVM), asignación de génesis, ID de cadena y configuración de tarifas. Mantén esto bajo control de versiones. Para opciones de alojamiento de nodos, consulta infraestructura de nodos dedicada y el directorio de redes.

• Avalanche CLI instalado y en tu PATH.
• Una clave de la P-Chain con suficiente AVAX para transacciones de subnet y validador.
• Un JSON de génesis y un ID de cadena reservados para tu red.
• Un plan para la exposición RPC, ya sea autoalojado o a través de un proveedor gestionado.

Cómo encajan las subnets y L1s en Avalanche

Avalanche tiene tres cadenas principales: la X-Chain para operaciones de activos, la C-Chain para contratos EVM y la P-Chain para validadores y subnets. Una subnet se registra en la P-Chain, luego se le agregan validadores mediante staking. Cada blockchain en la subnet se identifica por un ID de blockchain y ejecuta un plugin de VM. La Red Primaria valida las X-, C- y P-Chains; los propios validadores de una subnet validan sus blockchains.

Esta separación es el modelo mental central: la subnet es el conjunto de validadores y la blockchain es la máquina de estado. Una sola subnet puede alojar múltiples blockchains, y un validador puede pertenecer a múltiples subnets si cumple con los requisitos de stake. La comunicación entre subnets utiliza Avalanche Interchain Messaging (ICM) y Teleporter, que retransmiten mensajes entre cadenas en lugar de compartir estado directamente.

subnet-evm y la capa de ejecución

subnet-evm es la implementación EVM utilizada para la mayoría de las L1s de Avalanche. Admite objetivos de gas configurables, mercados de tarifas, precompilados y actualizaciones de estado. El repositorio independiente ava-labs/subnet-evm ha sido archivado y su código se trasladó a AvalancheGo, así que fija la versión de tu nodo y lee las notas de la versión de AvalancheGo en lugar de clonar el repositorio archivado.

La configuración de génesis controla la asignación inicial, el ID de cadena y los parámetros de tarifas. Cambiar el génesis después del lanzamiento requiere una actualización de estado coordinada, así que trátalo como un contrato inmutable con tus usuarios. Para una comparación más amplia de entornos de ejecución, consulta la guía de endpoints RPC.

Desplegar una subnet local para verificación

Un despliegue local es la forma más rápida de validar tu génesis y supuestos RPC antes de gastar fondos en una red pública. Avalanche CLI puede crear una red local con una subnet y una blockchain subnet-evm. Los comandos a continuación usan marcadores de posición para nombres y rutas; sustituye tus propios valores.

Después del despliegue, la CLI imprime la URL RPC y el ID de blockchain. Registra ambos. La red local es efímera, así que no la uses para datos de producción.

avalanche blockchain create myl1 --vm subnet-evm --genesis ./genesis.json
avalanche blockchain deploy myl1 --local
# Expected output includes:
# RPC URL: http://127.0.0.1:<port>/ext/bc/<blockchainID>/rpc
# Blockchain ID: <blockchainID>

Verificar un endpoint RPC de subnet con curl

La primera comprobación es la identidad de la cadena. Llama a eth_chainId y compara el resultado hexadecimal con el ID de cadena de tu génesis. Una discrepancia generalmente significa que estás apuntando a la blockchain incorrecta o que un proxy está enrutando a la C-Chain. La segunda comprobación es la producción de bloques: llama a eth_blockNumber dos veces con un retraso y confirma que la altura avanza.

Usa marcadores de posición para el endpoint. Nunca confirmes credenciales reales en el control de código fuente.

RPC_URL="https://your-subnet-rpc.example/ext/bc/<blockchainID>/rpc"

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 verificación de estado en JavaScript

Para una verificación continua, automatiza las comprobaciones y registra los resultados en una tabla. El script a continuación mide el ID de cadena, la altura de bloque y la latencia de ida y vuelta. No afirma un tiempo de bloque específico porque eso depende de tu génesis y conjunto de validadores.

Ejecútalo según un calendario y almacena la salida. Una tabla de resultados con columnas para marca de tiempo, ID de cadena, altura de bloque, latencia y estado hace visibles las regresiones.

const RPC_URL = process.env.RPC_URL;

async function call(method, params = []) {
  const start = Date.now();
  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();
  return { result: json.result, latencyMs: Date.now() - start };
}

(async () => {
  const chainId = await call('eth_chainId');
  const block1 = await call('eth_blockNumber');
  await new Promise(r => setTimeout(r, 5000));
  const block2 = await call('eth_blockNumber');
  console.log({
    chainId: chainId.result,
    block1: parseInt(block1.result, 16),
    block2: parseInt(block2.result, 16),
    latencyMs: chainId.latencyMs
  });
})();

Interpretar los resultados de la verificación

Un endpoint saludable devuelve un ID de cadena estable, una altura de bloque que aumenta entre muestras y una latencia consistente con tu ruta de red. Si el ID de cadena es correcto pero la altura es estática, el validador puede estar sincronizándose, la blockchain puede estar pausada o tu solicitud puede estar llegando a una caché. Si el ID de cadena es incorrecto, verifica el ID de blockchain en la ruta de la URL y cualquier regla de enrutamiento del proxy inverso.

Registra mediciones en lugar de adivinar. La tabla a continuación es una plantilla; complétala con tus propias observaciones.

• | Comprobación | Método | Esperado | Observado |
• | Identidad de cadena | eth_chainId | Coincide con el génesis | (registrar) |
• | Producción de bloques | eth_blockNumber x2 | La altura aumenta | (registrar) |
• | Latencia | Solicitud cronometrada | Dentro de tu SLO | (registrar) |
• | Finalidad | eth_getBlockByNumber | Bloque aceptado | (registrar) |

Solución de problemas comunes de RPC de subnet

Conexión rechazada o 502 generalmente significa que el nodo no está en ejecución, el puerto RPC no está expuesto o un balanceador de carga no tiene un backend saludable. Una respuesta 200 con un error JSON-RPC como method not found sugiere que estás hablando con una VM diferente o una versión de nodo más antigua. Los tiempos de espera bajo carga a menudo indican agotamiento de recursos en el nodo en lugar de un problema de protocolo.

Para problemas a nivel de validador, verifica el registro en la P-Chain y el estado del stake. Un validador que no está en el conjunto de validadores de la subnet no producirá ni validará bloques para esa subnet. Para operaciones de nodo más amplias, consulta la guía de alojamiento de nodos de blockchain.

• Confirma que el ID de blockchain en la ruta RPC coincide con la blockchain desplegada.
• Revisa los registros del nodo en busca de errores de carga del plugin de VM.
• Verifica que el validador esté registrado y con stake en la P-Chain.
• Prueba desde una ruta de red diferente para descartar problemas locales de DNS o firewall.

Limitaciones y compensaciones

Las subnets intercambian seguridad compartida por soberanía. Tú eliges y financias tu conjunto de validadores, por lo que la seguridad es una función de tu diseño de staking, no de la Red Primaria. Esa flexibilidad permite tokens de gas personalizados, membresía con permisos y rendimiento específico de la aplicación, pero también significa que eres responsable del tiempo de actividad, las actualizaciones y la respuesta a incidentes.

La mensajería entre subnets agrega latencia y complejidad en comparación con las llamadas en la misma cadena. Si tu aplicación depende de la composabilidad atómica con la liquidez de la C-Chain, evalúa si una L1 es la opción adecuada antes de comprometerte. Para opciones de RPC gestionado, compara precios de RPC y el servicio de API.

Próximos pasos

Después de la verificación local, despliega en una red pública con un conjunto pequeño de validadores y luego ejecuta el script de verificación de estado continuamente. Documenta tu ID de cadena, hash de génesis y URL RPC en un runbook. Cuando estés listo para elegir un endpoint de producción, usa el Asistente RPC para recomendaciones concretas de proveedores y redes en lugar de adivinar a partir de una lista.

Para lecturas relacionadas, consulta qué es un nonce de blockchain y la guía de endpoints RPC multicadena.