Localhost RPC Endpoints

Uso de localhost RPC Endpoints en Backpack

Esto tiene como objetivo ser una explicación no técnica de por qué el uso de http://localhost:XXXX o http://127.0.0.1:XXXX como un endpoint RPC personalizado dentro de Backpack (y algunas otras billeteras) no funciona.

Contexto

Cuando los ingenieros quieren probar o desarrollar contra datos o programas on-chain dentro de un entorno aislado, ejecutar un RPC en localhost suele ser la opción.

Esto funciona hasta que los sistemas periféricos y aplicaciones que no son locales también necesitan conectarse o enviar solicitudes a este entorno de ejecución de localhost.

Problema

Usar las direcciones de localhost y 127.0.0.1 desde una perspectiva de redes es como referirse a uno mismo (es decir, usar las palabras yo or me).

Backpack, junto con algunas otras billeteras populares, lee los activos de tus direcciones/billeteras desde servidores remotos y APIs que no viven ni se ejecutan en el cliente. Cuando inicias sesión en Backpack, la aplicación móvil o web hace una solicitud a un servidor remoto pidiendo información sobre tu billetera: saldos, historial de transacciones, tenencia de NFTs, etc.

Cuando configuras un endpoint RPC personalizado dentro de la aplicación Backpack, se usa como sustituto de los valores predeterminados que están preconfigurados en diferentes lugares:

1. Serialización de transacciones y envío

2. Verificación de estado

3. Recuperación de metadatos de la cadena de bloques/red

4. Indicar a la API de Backpack que lea los datos directamente desde la cadena en lugar de otras fuentes de datos más rápidas

Configurar un localhost RPC puede afectar los primeros tres de diferentes maneras, pero el #4 es importante. Ya que la API de Backpack es un servidor remoto, cuando se le indica obtener datos de la cadena desde un endpoint RPC en http://localhost:XXXX, lo que entiende es:

"Hay un nodo RPC de la cadena que estoy ejecutando y debería enviarle solicitudes."

Esto obviamente no es correcto, porque para el servidor, localhost no es el laptop de un usuario ejecutando el nodo RPC, posiblemente en un país diferente. En cambio, el RPC personalizado siempre debe configurarse a un endpoint accesible públicamente que no haga referencia a redes locales o sistemas internos ni a nombres reservados.

Entonces, ¿cómo uso mi RPC de prueba que está ejecutándose en localhost?

Solución

El punto clave es que el endpoint del RPC personalizado debe ser accesible públicamente.

Existen muchas herramientas y aplicaciones que te permiten tunelizar tus aplicaciones ejecutándose en localhost al espacio público (algunos ejemplos):

• ngrok (preferido)

• localtunnel

• serveo

...y muchos otros.

Estas aplicaciones te permiten elegir un puerto en tu red interna local y exponerlo a Internet público mediante tunelización local con nombres de dominio públicos efímeros que son alcanzables desde redes externas.

Usando ngrok, todo lo que necesitas hacer después de crear y verificar una cuenta es ejecutar el siguiente comando para configurar un túnel local para tu endpoint RPC, al que puedes luego establecer el RPC personalizado en la billetera:

$ ngrok http 8080 # whichever port number you want

¿Por qué algunas dApps funcionan sin esto?

Estos son algunos casos en los que, incluso sin un túnel localhost tunnel, configurar el RPC personalizado a localhost aún puede funcionar.

Esto depende completamente de la implementación de las dApps a las que estés conectado. Si el sitio web de la dApp está programado para ejecutar consultas en la cadena directamente desde el código del cliente, probablemente aún funcione porque las solicitudes de red al RPC realmente se están realizando desde el código que se ejecuta en tu navegador, y por lo tanto, dentro del mismo espacio de red que tu RPC localhost .

Esa es la única excepción a la necesidad de tunelización local.