Resumen
Un "NEAR check" normalmente significa una de tres cosas: confirmar una transacción o cuenta en la blockchain de NEAR, verificar que tu endpoint RPC responde correctamente, o validar una interacción con una wallet o contrato antes de publicar. La vía más rápida es usar un explorador de bloques para consultas legibles por humanos y una llamada JSON-RPC para comprobaciones programáticas.
Esta página te ofrece las comprobaciones prácticas que los desarrolladores ejecutan con más frecuencia en NEAR: leer el saldo de una cuenta, obtener el resultado de una transacción, confirmar la altura de bloque y sondear un endpoint RPC para comprobar su estado. También explica cuándo basta con un endpoint público y cuándo conviene pasar a un proveedor RPC dedicado como OnFinality para tener un acceso constante.
NEAR usa una interfaz JSON-RPC con métodos como query, block y tx. Los ejemplos siguientes muestran cómo ejecutar esas comprobaciones con curl y con JavaScript, y cómo interpretar las respuestas para distinguir entre un problema de red, un problema de RPC y un bug de la aplicación.
Puntos clave
- Un NEAR check puede ser una consulta de transacción, una lectura de saldo de cuenta o una sonda de estado del RPC; cada una usa un método distinto.
- Los métodos JSON-RPC de NEAR como
query,blockytxcubren la mayoría de las necesidades de verificación sin necesidad de un indexador personalizado. - Los exploradores son mejores para consultas legibles por humanos; JSON-RPC es mejor para comprobaciones automatizadas en CI, monitorización o servicios de backend.
- Distingue entre una transacción fallida, un nodo RPC retrasado y una solicitud mal formada revisando la forma de la respuesta y la altura de bloque.
- Los endpoints públicos sirven para desarrollo y comprobaciones de bajo volumen; las comprobaciones en producción suelen necesitar un proveedor RPC dedicado con acceso predecible.
- OnFinality ofrece acceso a la API RPC de NEAR y opciones de nodos dedicados; consulta la página de redes compatibles para ver la disponibilidad actual.
¿Qué NEAR check necesitas realmente?
Antes de escribir una solicitud, decide qué estás verificando. La mayoría de las tareas de "NEAR check" se dividen en cuatro categorías: confirmar el resultado de una transacción, leer el estado de una cuenta o contrato, comprobar que un endpoint RPC está sano y validar una conexión de wallet o dApp. Cada una tiene un método distinto y un modo de fallo distinto.
Usa la tabla siguiente para elegir la herramienta adecuada. Si necesitas una vista legible por humanos, un explorador es más rápido. Si necesitas automatizar la comprobación, JSON-RPC es la capa correcta.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Resultado de la transacción | Hash de la transacción, estado de ejecución final y si el fallo está en la transacción o en el receipt | Una transacción puede incluirse en un bloque y aun así fallar durante la ejecución; comprobar solo la inclusión da un falso positivo |
| Saldo de la cuenta | ID de cuenta, saldo disponible, saldo en staking y uso de almacenamiento | Las cuentas de NEAR mantienen por separado los saldos líquidos y en staking; una comprobación de saldo que ignora el almacenamiento o el staking puede inducir a error |
| Estado del RPC | Última altura de bloque, tiempo de respuesta y tasa de errores en llamadas repetidas | Un nodo que responde pero va retrasado respecto a la cadena devolverá estado obsoleto y romperá las comprobaciones en silencio |
| Conexión de wallet o dApp | ID de red, claves de acceso de la cuenta y si la wallet apunta a mainnet o testnet | La mayoría de las comprobaciones "fallidas" en desarrollo son desajustes de red, no errores de la cadena |
Comprobaciones JSON-RPC de NEAR con curl
NEAR expone una interfaz JSON-RPC. El endpoint exacto depende del proveedor y de la red. Para producción o comprobaciones repetidas, usa un endpoint de un proveedor de confianza y guárdalo en una variable de entorno en lugar de codificarlo directamente.
El ejemplo siguiente muestra la forma de la solicitud para una comprobación de altura de bloque. Sustituye el endpoint por la URL RPC de NEAR de tu proveedor. Si estás evaluando OnFinality, confirma el endpoint actual de NEAR y el soporte de red en la página de redes compatibles antes de construir sobre él.
- Usa
blockconfinality: "final"para obtener un bloque finalizado reciente y confirmar que el nodo sigue la cadena. - Usa
queryconrequest_type: "view_account"para leer el saldo de una cuenta. - Usa
txcon el hash de la transacción y el ID de la cuenta remitente para obtener el resultado de una transacción. - Mantén el campo
idde JSON-RPC único por solicitud para poder correlacionar respuestas en los logs.
Cómo leer correctamente el resultado de una transacción de NEAR
La respuesta de una transacción de NEAR contiene más que un indicador de éxito. El status de nivel superior describe la transacción en sí, mientras que transaction_outcome y receipts_outcome describen la ejecución. Una transacción puede ser válida e incluirse mientras uno de sus receipts falla.
Cuando construyas una comprobación, inspecciona los resultados de los receipts en busca de estados de fallo en lugar de confiar solo en el resultado de nivel superior. Esta es la fuente más común de informes falsos de "éxito" en integraciones con NEAR.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Estado de nivel superior | Si la transacción se incluyó y se aceptó | Indica que la transacción llegó a la cadena, no que sus efectos tuvieran éxito |
| Resultados de los receipts | El estado de cada receipt y cualquier motivo de fallo | Las llamadas entre contratos pueden fallar después de que la transacción se acepte |
| Logs | Logs de ejecución en busca de mensajes de panic o errores a nivel de contrato | Los logs suelen contener el motivo real por el que falló una comprobación |
| Finalidad del bloque | Si el bloque es final u optimista | Los resultados optimistas pueden cambiar; los resultados finales son más seguros para comprobaciones de liquidación |
Sondear el estado del RPC de NEAR desde un script
Si tu comprobación trata realmente de si un endpoint es utilizable, sondéalo tal como lo usará tu aplicación. Una simple llamada de altura de bloque repetida en el tiempo revela retrasos, timeouts y errores intermitentes mejor que una sola solicitud.
Ejecuta la sonda desde la misma región y ruta de red que tu aplicación. Una comprobación que pasa desde tu portátil pero falla desde tu entorno de producción suele apuntar a la salida de red, al DNS o a reglas de acceso del proveedor, más que a la propia cadena de NEAR.
- Registra la última altura de bloque y compárala con la de un segundo proveedor o explorador para detectar retrasos.
- Rastrea los códigos de error por separado de los timeouts; indican problemas distintos.
- Sondea ambos métodos de lectura de los que dependes, como
queryyblock, no solo uno. - Configura alertas ante fallos sostenidos en lugar de una sola solicitud perdida para evitar ruido.
Cuándo basta con un endpoint público de NEAR y cuándo no
Los endpoints públicos son útiles para aprender, para comprobaciones puntuales y para el desarrollo temprano. Son compartidos, así que su comportamiento puede variar con la carga, y puede que no admitan todos los métodos o consultas históricas que necesitas.
Pasa a un proveedor RPC dedicado o gestionado cuando las comprobaciones formen parte de un flujo de trabajo de producción, cuando necesites acceso constante durante picos de tráfico o cuando necesites datos de archive para verificación histórica. OnFinality ofrece acceso a la API RPC e infraestructura de nodos dedicados; revisa la página de redes compatibles para confirmar la disponibilidad de NEAR y la página de precios para ajustar el volumen de solicitudes a un plan.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Desarrollo y comprobaciones puntuales | Disponibilidad del endpoint público y cobertura de métodos | El bajo volumen rara vez justifica infraestructura dedicada |
| Comprobaciones automatizadas en producción | Acceso predecible, failover y monitorización | Los endpoints compartidos pueden introducir latencia variable y límites de tasa |
| Verificación histórica | Disponibilidad de datos de archive para bloques y transacciones antiguos | Los nodos podados no pueden responder consultas históricas |
| Sondeo de alta frecuencia | Límites de solicitudes y aislamiento respecto a otras cargas de trabajo | Las sondas de estado no deberían competir por capacidad con el tráfico de usuarios |
Ruta de depuración para comprobaciones de NEAR fallidas
Cuando falla una comprobación de NEAR, trabaja de fuera hacia dentro: confirma la red, confirma el endpoint, confirma la solicitud y luego confirma la interpretación del resultado. La mayoría de los fallos se resuelven en uno de estos cuatro pasos.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Desajuste de red | Mainnet frente a testnet en el endpoint y en la configuración de la wallet | Las cuentas y transacciones no existen entre redes |
| Solicitud mal formada | Nombre del método JSON-RPC, tipos de parámetros y campos obligatorios | NEAR devuelve errores estructurados para parámetros no válidos que son fáciles de pasar por alto |
| Nodo obsoleto | Última altura de bloque comparada con una referencia | Un nodo retrasado devuelve estado antiguo y hace que transacciones válidas parezcan inexistentes |
| Interpretación errónea del resultado | Resultados de receipts y logs, no solo el estado de nivel superior | Las transacciones aceptadas pueden fallar durante la ejecución |
Preguntas frecuentes
¿Qué significa "NEAR check"?
Normalmente se refiere a verificar algo en la blockchain de NEAR: una transacción, el saldo de una cuenta, el estado de un contrato o el estado de un endpoint RPC. El método adecuado depende de qué estés comprobando.
¿Cómo compruebo una transacción de NEAR?
Usa un explorador de bloques de NEAR para una vista legible por humanos, o llama al método JSON-RPC tx con el hash de la transacción y el ID de la cuenta remitente. Inspecciona los resultados de los receipts, no solo el estado de nivel superior.
¿Cómo compruebo el saldo de una cuenta de NEAR?
Llama al método query con request_type: "view_account" y el ID de la cuenta. La respuesta incluye el saldo líquido, el saldo en staking y el uso de almacenamiento, que debes leer en conjunto.
¿Puedo comprobar el estado del RPC de NEAR con una simple solicitud?
Una sola llamada block confirma que el endpoint responde, pero las sondas repetidas en el tiempo son mejores para detectar retrasos y errores intermitentes. Compara la altura de bloque con una segunda fuente.
¿Necesito un proveedor RPC dedicado para las comprobaciones de NEAR?
No para desarrollo ni para comprobaciones ocasionales. Para flujos de trabajo de producción, sondeo de alta frecuencia o verificación histórica, un proveedor RPC gestionado o dedicado ofrece un acceso más predecible. Consulta las páginas de redes compatibles y precios de OnFinality para ver las opciones actuales.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
