Se puede acceder al servidor RPC del nodo substrate a través del protocolo websocket, que puede utilizarse como forma de acceder a la red subyacente y/o al nodo validador. Por defecto puedes acceder al servidor RPC de tu nodo desde localhost (por ejemplo para rotar claves o realizar otro tipo de mantenimiento). Para acceder desde otro servidor o desde una aplicación UI (como Polkadot-JS UI) se recomienda habilitar el acceso al nodo RPC sobre una conexión TLS y como tal encriptar la conexión entre el usuario final y el servidor RPC. Esto se puede conseguir configurando un proxy seguro. Muchos navegadores como Google Chrome bloquearán los extremos WS no seguros si provienen de un origen diferente.
NOTA
Habilitar el acceso remoto a tu nodo validador no debería ser necesario y no se sugiere, ya que a menudo puede conducir a problemas de seguridad.
Configurar un nodo #
La configuración de cualquier nodo basado en Substrate se basa en un proceso similar. Por ejemplo, todos compartirán por defecto la misma conexión websocket en el puerto 9944 en localhost. En este ejemplo, configuraremos un nodo polkadot sync en un servidor debian (como Ubuntu 22.04). Crea un nuevo servidor en el proveedor de tu elección o localmente en casa. Consulta Configurar un nodo completo para obtener instrucciones adicionales. Puedes elegir instalar desde el repositorio apt por defecto o construir desde cero. Las opciones de inicio en el proceso de configuración proporcionan una variedad de ajustes diferentes que pueden ser modificados.
Una configuración típica para un nodo RPC de archivo polkadot accesible externamente sería:
polkadot --chain polkadot --name myrpc --state-pruning archive --blocks-pruning archive --ws-max-connections 100 --rpc-cors all --rpc-methods Safe --ws-port 9944
O para un nodo RPC pruned (podado) por polkadot:
polkadot --chain polkadot --name myrpc --state-pruning 1000 --blocks-pruning archive --ws-max-connections 100 --rpc-cors all --rpc-methods Safe --ws-port 9944
A continuación se describen con más detalle las opciones de indicadores (flag) especificados.
Nodo de archivo frente a nodo pruned #
Un nodo pruned (reducido o podado) sólo conserva un número limitado de bloques finalizados de la red y no su historial completo. La mayoría de las acciones que se requieren con frecuencia se pueden completar con un nodo podado, como mostrar balances de cuentas, realizar transferencias, configurar claves de sesión, staking, etc. Un nodo de archivo tiene el historial completo (base de datos) de la red y se puede consultar de todo tipo de formas, como proporcionar información histórica sobre transferencias, historiales de balances y consultas más avanzadas sobre eventos pasados, etc.
Un nodo de archivo requiere mucho más espacio en disco. A principios de enero de 2023, el uso de disco de polkadot era de 115 GB para un nodo podado y de 765 GB para un nodo de archivo. Este valor aumentará con el tiempo. Para un nodo de archivo necesitas las opciones --state-pruning archive --blocks-pruning archive en tu configuración de inicio.
CONSEJO
La inclusión en la interfaz de Polkadot.js requiere un nodo de archivo.
Asegurar el servidor RPC #
La configuración de inicio del nodo te permite elegir qué exponer, cuántas conexiones exponer y desde dónde se debe permitir el acceso a través del servidor rpc.
Cuántas: Puedes establecer el máximo de conexiones a través de --ws-max-connections, por ejemplo --ws-max-connections 100
Desde dónde: por defecto localhost y polkadot.js tienen permitido acceder al servidor RPC, puedes cambiar esto configurando --rpc-cors, para permitir el acceso desde cualquier lugar que necesites --rpc-cors all
Qué: puedes limitar los métodos a usar con --rpc-methods, una forma fácil de ponerlo en modo seguro es --rpc-methods Safe
Asegurar el puerto ws #
Un puerto ws no seguro puede convertirse en un puerto wss seguro colocándolo detrás de un proxy habilitado para SSL. El servidor proxy apache2/nginx/otro con SSL redirige las peticiones al nodo rpc interno. Para ello necesitarás un certificado SSL. Hay diferentes estrategias para obtener un certificado, como usar un servicio como letsencrypt o autofirmado.
Obtener un certificado SSL #
Una forma sencilla de obtener un certificado SSL gratuito es seguir las instrucciones de LetsEncrypt (nginx/apache). Esto auto-generará un certificado SSL y lo incluirá en tu configuración.
Alternativamente, puedes generar un certificado autofirmado y confiar en la dirección IP raw de tu nodo cuando te conectes a él. Esto no es preferible ya que tendrás que poner el certificado en la whitelist (lista blanca) para acceder a él desde un navegador.
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/selfsigned.key -out /etc/ssl/certs/selfsigned.crt
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
Instalación de un servidor proxy #
Hay muchas implementaciones diferentes de un proxy websocket, algunos de los más utilizados son nginx y apache2, para los que se proporcionan ejemplos de configuración a continuación.
Nginx #
En un virtualhost habilitado para SSL añadir:
Opcionalmente se puede introducir alguna forma de limitación de velocidad:
Apache2 #
Puedes ejecutarlo en diferentes modos como prefork, worker o event. En este ejemplo, usamos event que funciona bien en entornos de mayor carga pero otros modos también son útiles dados los requerimientos.
El mod_proxy_wstunnel proporciona soporte para el tunnelling de conexiones web socket a un servidor backend websockets. La conexión se convierte automáticamente en una conexión websocket. En un virtualhost habilitado para SSL añade:
Opcionalmente se puede introducir alguna forma de limitación de velocidad:
Y editar /etc/apache2/mods-available/qos.conf
Conectando al Nodo #
Abre Polkadot-JS UI y haz clic en el logotipo en la parte superior izquierda para cambiar el nodo. Activa el toggle “Desarrollo” e introduce la dirección de tu nodo – ya sea el dominio o la dirección IP. Recuerda anteponer wss:// y si estás usando el puerto 443, añade :443, así: wss://ejemplo.com:443.
