Nodos de Archivo de Polkadot y Substrate: Consulta de Estado Histórico a través de RPC

Respuesta Directa: Cómo Consultar el Estado Histórico en Polkadot

Para consultar el estado histórico en una cadena basada en Polkadot o Substrate, necesitas un nodo de archivo que conserve el trie de estado completo en cada bloque. A través de RPC, primero resuelves el hash del bloque para un número de bloque dado usando chain_getBlockHash, luego llamas a state_getStorage con ese hash para leer un valor de almacenamiento tal como existía en ese bloque. En un nodo completo podado, tales consultas fallan o devuelven el valor más reciente, porque el estado histórico no se conserva.

Esta guía explica el modelo de almacenamiento de Substrate, los métodos RPC exactos y un ejemplo ejecutable que puedes verificar tú mismo. También cubre errores comunes y compensaciones, para que puedas decidir cuándo es necesario un nodo de archivo y cómo acceder a uno.

¿Qué es un Nodo de Archivo en Polkadot y Substrate?

Polkadot y otras cadenas basadas en Substrate almacenan su estado como una base de datos clave-valor expuesta a través del runtime. El estado actual es un trie de Merkle, y cada bloque produce una raíz de estado que compromete todo el estado en ese punto. Un nodo completo podado conserva solo el estado reciente (típicamente los últimos cientos de bloques) más datos históricos suficientes para verificar la finalidad y servir cabeceras. Un nodo de archivo, en contraste, conserva el trie de estado completo para cada bloque, permitiéndote consultar los valores de almacenamiento exactos en cualquier bloque histórico.

La documentación de Polkadot distingue los tipos de nodo: un nodo de archivo almacena todo el estado histórico, mientras que un nodo podado no lo hace. Este es un comportamiento documentado de los nodos basados en Substrate, no una característica específica del proveedor. La compensación es el espacio en disco y el tiempo de sincronización, que varían según la cadena y la configuración; no se proporcionan cifras universales aquí porque dependen del tamaño de la cadena y de la configuración de poda.

Para una comparación más profunda entre nodos de archivo y completos en un contexto más amplio de blockchain, consulta nuestra guía nodo de archivo vs nodo completo.

• Nodo de archivo: conserva el trie de estado completo para cada bloque, permitiendo consultas de estado histórico.
• Nodo completo podado: mantiene solo el estado reciente; las consultas históricas son limitadas o no están disponibles.
• El estado de Substrate es almacenamiento clave-valor, no solo saldos de cuentas; cualquier elemento de almacenamiento puede consultarse históricamente.

El Modelo de Almacenamiento de Substrate y los Métodos RPC

Substrate expone el estado a través de un conjunto de claves de almacenamiento. Cada clave es un hash de un prefijo de pallet y un nombre de elemento de almacenamiento. Por ejemplo, el saldo de una cuenta se almacena bajo una clave derivada del almacenamiento Account del pallet System. Para leer un valor, proporcionas la clave de almacenamiento y opcionalmente un hash de bloque. Los métodos RPC que necesitas están documentados en los documentos RPC de polkadot.js y en la documentación RPC de Substrate.

Métodos clave para consultas históricas:

chain_getBlockHash – mapea un número de bloque a su hash. state_getStorage – lee un valor de almacenamiento en un hash de bloque dado (o el último bloque si se omite). state_getKeys / state_getPairs – lista claves de almacenamiento o pares clave-valor en un bloque específico. state_queryStorage – consulta cambios de almacenamiento en un rango de bloques, útil para rastrear cuándo cambió un valor.

Estos métodos funcionan en cualquier nodo Substrate, pero los datos históricos solo están disponibles si el nodo es un nodo de archivo. La documentación de infraestructura de nodos de Polkadot confirma que los nodos de archivo son necesarios para consultas de estado histórico.

• chain_getBlockHash – número de bloque a hash
• state_getStorage – leer un valor de almacenamiento en un hash de bloque
• state_getKeys / state_getPairs – enumerar almacenamiento en un bloque
• state_queryStorage – consultar cambios de almacenamiento en un rango de bloques

Ejemplo Ejecutable: Consulta de Saldo Histórico

El siguiente ejemplo en JavaScript utiliza la biblioteca @polkadot/api para conectarse a un nodo de archivo de Polkadot y consultar el saldo de una cuenta conocida en un bloque pasado. Puedes ejecutarlo con Node.js después de instalar la dependencia. Reemplaza el endpoint con la URL de tu propio nodo de archivo.

El ejemplo resuelve el número de bloque 10,000,000 a un hash, luego lee el almacenamiento System.Account para una cuenta específica. En un nodo de archivo, obtienes el saldo histórico real; en un nodo podado, puedes obtener un error o el valor más reciente.

Para verificar el resultado de forma independiente, puedes contrastarlo con un explorador de bloques que proporcione datos de saldo histórico, como Polkascan o Subscan, aunque estos son servicios de terceros.

// Instalar: npm install @polkadot/api
const { ApiPromise, WsProvider } = require('@polkadot/api');

async function main() {
  // Usa tu propio endpoint de nodo de archivo
  const provider = new WsProvider('wss://rpc.polkadot.io');
  const api = await ApiPromise.create({ provider });

  // Número de bloque a consultar
  const blockNumber = 10000000;
  const blockHash = await api.rpc.chain.getBlockHash(blockNumber);
  console.log('Hash del bloque:', blockHash.toHex());

  // Cuenta a consultar (ejemplo: una dirección conocida)
  const address = '15oF4uVJwmo4TdGW7VfQxNLavjCXviqxT9S1MgbjMNHr6Sp5';
  const accountKey = api.query.system.account.key(address);

  // Leer almacenamiento en el bloque histórico
  const accountInfo = await api.rpc.state.getStorage(accountKey, blockHash);
  if (accountInfo.isEmpty) {
    console.log('No se encontraron datos (probablemente nodo podado o la cuenta no existía).');
  } else {
    const data = api.registry.createType('AccountInfo', accountInfo);
    console.log('Saldo libre en el bloque', blockNumber, ':', data.data.free.toString());
  }

  await api.disconnect();
}

main().catch(console.error);

// Salida esperada (ejemplo):
// Hash del bloque: 0x...
// Saldo libre en el bloque 10000000 : 1234567890

Errores Comunes y Soluciones

Al consultar el estado histórico, puedes encontrar varios problemas. Aquí están los más comunes y cómo resolverlos.

Si obtienes un error como State already discarded for ..., el nodo está podado y no tiene el estado histórico. La solución es usar un nodo de archivo. Si obtienes el valor más reciente en lugar del histórico, el nodo puede estar ignorando el parámetro de hash de bloque debido a una configuración incorrecta; asegúrate de pasar el hash correctamente y de que el nodo no esté detrás de un proxy que elimine parámetros.

Otro problema es usar una clave de almacenamiento incorrecta. Las claves de almacenamiento están hasheadas; debes usar el formato de clave correcto. El ejemplo anterior usa el método key() de la API para generar la clave, lo cual es confiable. Si construyes claves manualmente, verifica el hash.

Finalmente, pueden ocurrir límites de velocidad o tiempos de espera en endpoints públicos. Para uso en producción, considera un endpoint dedicado a través de nuestro Asistente RPC o un servicio gestionado.

• Error 'State already discarded' – el nodo está podado; cambia a un nodo de archivo.
• Devuelve el valor más reciente en lugar del histórico – verifica el parámetro de hash de bloque y la configuración del nodo.
• Clave de almacenamiento inválida – usa los métodos de generación de claves de la API.
• Límites de velocidad/tiempos de espera – usa un endpoint dedicado o gestionado.

Compensaciones y Limitaciones

Los nodos de archivo son esenciales para ciertos casos de uso, pero conllevan costos significativos. El espacio en disco y el tiempo de sincronización son mucho mayores que en los nodos podados. Las cifras exactas varían según la cadena y la configuración; para Polkadot, el tamaño del nodo de archivo está documentado como varias veces mayor que el de un nodo podado, pero no proporcionamos números específicos aquí porque cambian con el tiempo.

Incluso en un nodo de archivo, no todos los datos históricos están disponibles. Por ejemplo, el almacenamiento que ha sido migrado o eliminado puede no ser accesible. Además, consultar bloques muy antiguos puede ser lento porque el nodo debe recorrer el trie. Para análisis históricos complejos, podrías necesitar un indexador externo o un servicio de instantáneas.

Al decidir si ejecutar tu propio nodo de archivo o usar uno gestionado, considera tu frecuencia de consulta y requisitos de latencia. Servicios gestionados como el servicio API de OnFinality ofrecen nodos de archivo con alta disponibilidad, pero debes verificar sus políticas de retención con el proveedor.

Para más sobre rendimiento RPC, consulta nuestra guía de latencia RPC de Polkadot.

• El espacio en disco y el tiempo de sincronización son significativamente mayores para los nodos de archivo.
• El estado histórico puede no estar disponible para almacenamiento migrado o eliminado.
• Consultar bloques muy antiguos puede ser lento.
• Considera indexadores externos para consultas históricas complejas.

Guía de Decisión: Cuándo Usar un Nodo de Archivo

Usa un nodo de archivo cuando necesites responder preguntas como '¿Cuál era el saldo de esta cuenta en el bloque N?' o '¿Cuál era la emisión total en ese momento?'. Estas consultas son comunes en auditorías, investigación y desarrollo de dApps que necesitan contexto histórico.

Si solo necesitas el estado actual o historia reciente, un nodo completo podado es suficiente y más rentable. Para registros de eventos o historial de transacciones, puede que no necesites un nodo de archivo; un indexador como SubQuery puede proporcionar esos datos de manera más eficiente.

Para un inicio rápido, puedes usar un endpoint de archivo público, pero ten en cuenta los límites de velocidad. Para producción, considera un endpoint dedicado a través de precios RPC o un proveedor gestionado. Siempre prueba tus consultas contra un nodo de archivo conocido para asegurar la corrección.

• Usa nodo de archivo para consultas de almacenamiento histórico en bloques específicos.
• Usa nodo podado para estado actual y bloques recientes.
• Usa indexadores para historial de eventos/transacciones.
• Prueba consultas en un nodo de archivo conocido antes de confiar en ellas.

Próximos Pasos y Lecturas Adicionales

Ahora que entiendes cómo consultar el estado histórico en Polkadot, puedes explorar temas más avanzados. Si eres nuevo en Polkadot, comienza con nuestra visión general de la red Polkadot. Para más técnicas RPC, consulta nuestras guías sobre acceso a datos históricos de blockchain y endpoints RPC de Polkadot.

Si estás considerando ejecutar tu propio nodo, revisa la documentación oficial de Polkadot sobre infraestructura de nodos. Para soluciones gestionadas, consulta nuestro servicio API y precios RPC. Y no olvides explorar el centro de aprendizaje de OnFinality para más tutoriales.