rpcpool.solana_rpc

Descripción general Versiones Perspectivas

Rol de RPC de Solana

Un rol de Ansible para desplegar un nodo RPC de Solana. Esto configura el software de validador en modo RPC ejecutándose bajo el usuario solana. El servicio RPC se instala como un servicio de usuario funcionando bajo este mismo usuario.

Actualizaciones

16/02 - A partir de Solana 1.8.15 (mainnet) y 1.9.6 (testnet), deberás especificar solana_full_rpc_api: true para que este rol cree un nodo RPC API completamente expuesto.

Requisitos de Hardware

Un servidor RPC requiere al menos las mismas especificaciones que un validador de Solana, pero generalmente tiene requisitos más altos. En particular, se recomienda utilizar 256 GB de RAM para almacenar índices. Para más información sobre los requisitos de hardware, consulta https://docs.solana.com/running-validator/validator-reqs. Se recomienda encarecidamente usar un proveedor de baremetal (no Hetzner) en lugar de un proveedor en la nube, a menos que sepas lo que haces (y entonces, ¿por qué estás leyendo esta página?).

Antes de realizar el despliegue, debes preparar el host para que el directorio que uses para tu base de datos de cuentas y tu ubicación del libro mayor estén correctamente configurados. Esto puede incluir configurar una carpeta tmpfs para las cuentas y un sistema de archivos separado (idealmente en una unidad NVME) para el libro mayor. Una forma común de configurar esto podría ser:

/solana/tmpfs - una partición tmpfs de 100 GB para almacenar el estado de las cuentas
/solana/ledger - un disco NVME de 2 TB para almacenar el libro mayor

¿Por qué bare metal y no nube?

Los servidores en la nube (AWS, GCP, etc.) son generalmente inapropiados para Solana por varias razones:

La salida es muy cara y Solana utiliza mucha salida.
El rendimiento de núcleo único generalmente es demasiado bajo y no puede aumentarse de la forma en que lo hace el baremetal.
Muchos proveedores de nube no quieren el tipo de carga de trabajo que Solana tiene en sus instancias de menor costo, llevándote a utilizar instancias baremetal muy caras.

¿Por qué no Hetzner?

Hetzner ha decidido que no quiere que los servicios RPC de Solana funcionen en su red. Bloquean activamente las conexiones a los puntos de entrada de Solana y limitan el tráfico de Solana. No solo tu nodo Solana tendrá dificultades para mantenerse al día con la red (en mainnet, probablemente nunca se pondrá al día), sino que Hetzner también es muy probable que cierre tu cuenta.

Requisitos de Software

Ansible >= 2.7 (principalmente probado en Ansible 2.8)
Ubuntu 18.04+ en la máquina de despliegue objetivo

Este rol asume cierto conocimiento del proceso de despliegue del software de validador de Solana.

Variables del Rol

El despliegue asegura que el checksum de la versión del instalador de Solana que estás descargando coincida con uno dado en vars/main.yml. En caso de que quieras instalar una versión de Solana que no esté listada allí, es bueno que primero descargues y verifiques el checksum sha256 del script del instalador de Solana (https://raw.githubusercontent.com/solana-labs/solana/master/install/solana-install-init.sh).

Hay una gran cantidad de parámetros configurables para Solana. Muchos de estos tienen valores predeterminados funcionales, y puedes usar este rol para desplegar un nodo RPC de Solana sin cambiar ninguno de los valores predeterminados y deberías tener una experiencia decente. Si ejecutas este rol sin especificar ningún parámetro, configurará un nodo RPC mainnet estándar.

Variables Básicas

Estas son las variables básicas que configuran la configuración de los validadores. Tienen valores predeterminados, pero probablemente querrás personalizarlas según tu configuración.

Nombre	Valor predeterminado	Descripción
`solana_version`	stable	La versión de Solana a instalar.
`solana_full_rpc_api`	`true`	Si habilitar o no la API RPC completa. Eso es típicamente lo que querrás.
`solana_root`	/solana	Directorio principal para el libro mayor y las cuentas de Solana.
`solana_ledger_location`	/solana/ledger	Almacenamiento para el libro mayor de Solana (debe estar en NVME).
`solana_accounts_location`	/solana/ledger/accounts	Almacenamiento para la información de cuentas de Solana. Si usas tmpfs para cuentas, esto debe ser un subdirectorio de tu punto de montaje tmpfs (por ejemplo, `/solana/tmpfs/accounts` si tmpfs está montado en `/solana/tmpfs`).
`solana_snapshots_location`		Almacenamiento para los snapshots de Solana. Puede ser útil mantenerlo en un NVME separado del libro mayor.
`solana_keypairs`	`[]`	Lista de pares de claves para copiar en el nodo validador. Cada entrada en la lista debe tener una entrada `key` y `name`. Esto creará `/home/solana/<name>.json` conteniendo el valor de `key`.
`solana_generate_keypair`	true	Si generar o no un par de claves. Si no has especificado `solana_keypairs` y lo pones en true, se generará una nueva clave y se colocará en /home/solana/identity.json.
`solana_public_key`	`/home/solana/identity.json`	Ubicación de la identidad del nodo validador.
`solana_network`	mainnet	La red de Solana a la que este nodo debe pertenecer.
`solana_environment`	ver defaults/main.yml	Variables de entorno para especificar para el nodo validador, más importantes `RUST_LOG`.
`solana_enabled_services`	`[ solana-rpc ]`	Lista de servicios para iniciar automáticamente al arrancar.
`solana_disabled_services`	`[ ]`	Lista de servicios para establecer como desactivados.

Puertos

Los siguientes puertos necesitan configurarse para tu servidor RPC.

Nombre	Valor predeterminado	Descripción
`solana_gossip_port`	8001	Puerto para el tráfico de gossip (debe estar abierto públicamente en el firewall tanto para TCP como para UDP).
`solana_rpc_port`	8899 (+8900)	Puertos para RPC entrante (y websocket). Esto generalmente solo está abierto en localhost. Coloca un proxy como `haproxy` enfrente de estos puerto(s) y no los expongas públicamente.
`solana_rpc_bind_address`	127.0.0.1	Dirección para enlazar RPC. Esto debe ser típicamente localhost. Coloca un proxy como `haproxy` enfrente de esto para aceptar tráfico público.
`solana_dynamic_port_range`	8002-8020	Puerto para tráfico entrante de Solana. Puede necesitar estar abierto públicamente en el firewall para UDP.

De esta lista, puedes ver que necesitas al menos abrir del 8001 al 8020 en tu firewall para tráfico entrante en el caso predeterminado.

Para nodos RPC puros, puede ser posible cerrar los puertos de TPU y TPU forward. Estos puertos son asignados dinámicamente y puedes verlos mirando tu nodo en solana gossip. Si deseas establecer un firewall en ellos, puedes usar esta utilidad: https://github.com/rpcpool/tpu-traffic-classifier. Usando esta herramienta puedes bloquear el tráfico entrante de TPU y TPU forward en un nodo local ejecutando:

./tpu-traffic-classifier -config-file config.yml -our-localhost -tpu-policy DROP -fwd-policy DROP -update=false

Coloca esto en un servicio SystemD y puedes configurarlo para que inicie al arranque del nodo y dejarlo funcionando continuamente.

Variables Específicas de la Red

Los valores predeterminados para estas variables se especifican en vars/{{ solana_network }}-default.yml (por ejemplo, vars/mainnet-default.yml). También puedes especificar los tuyos proporcionando el archivo {{ solana_network }}.yml. Necesitarás especificar todas estas variables a menos que confíes en los valores predeterminados.

Nombre	Valor predeterminado	Descripción
`solana_network`	mainnet	La red de Solana a la que debe unirse este nodo.
`solana_metrics_config`	ver vars/mainnet-default.yml	El punto final de métricas.
`solana_genesis_hash`	ver vars/mainnet-default.yml	El hash de génesis para esta red.
`solana_entrypoints`	ver vars/mainnet-default.yml	Hosts de entrada.
`solana_known_validators`	ver vars/mainnet-default.yml	Validadores conocidos desde donde obtener snapshots y genesis bin al iniciar.
`solana_expected_bank_hash`	ver vars/mainnet-default.yml	Hash de banco esperado.
`solana_expected_shred_version`	ver vars/mainnet-default.yml	Versión de shred esperada.
`solana_index_exclude_keys`	ver vars/mainnet-default.yml	Claves a excluir de índices por razones de rendimiento.

Variables Específicas de RPC

Nombre	Valor predeterminado	Descripción
`solana_rpc_faucet_address`		Especificar un faucet RPC.
`solana_rpc_history`	true	Si proporcionar valores históricos a través de RPC.
`solana_account_index`	program-id spl-token-owner spl-token-mint	Qué índices habilitar. Estos mejoran enormemente el rendimiento pero ralentizan el tiempo de inicio y pueden aumentar los requisitos de memoria.

Variables de Rendimiento

Estas son variables que puedes ajustar para mejorar el rendimiento.

Nombre	Valor predeterminado	Descripción
`solana_snapshot_compression`		Si comprimir o no los snapshots. Especificar ninguno para mejorar el rendimiento.
`solana_snapshot_interval_slots`		Cada cuánto tomar snapshots. Aumenta para mejorar el rendimiento. El valor sugerido es 500.
`solana_pubsub_max_connections`	1000	Número máximo de conexiones pubsub permitidas.
`solana_bpf_jit`		Si habilitar BPF JIT. Predeterminado en devnet.
`solana_banking_threads`	16	Número de hilos de banca.
`solana_rpc_threads`		Número de hilos RPC (máximo predeterminado de hilos/núcleos en el sistema).
`solana_limit_ledger_size`	`solana default, 250 mio`	Tamaño del libro mayor local a almacenar. Para una época completa, establece un valor entre 350 mio y 500 mio. Para el mejor rendimiento establece 50 (valor mínimo).
`solana_accounts_db_caching`		Si habilitar la memoria caché de la base de datos de cuentas.
`solana_accounts_shrink_path`		Puedes querer especificar otra ubicación para el proceso de reducción de cuentas.

Bigtable

Puedes especificar credenciales de cuenta de Google Bigtable para consultar bloques que no están presentes en el libro mayor local.

Nombre	Valor predeterminado	Descripción
`solana_bigtable_enabled`	false	Habilitar acceso a bigtable.
`solana_bigtable_upload_enabled`	false	Habilitar carga a bigtable (las credenciales que proporciones abajo necesitan acceso de escritura).
`solana_bigtable_project_id`		Id del proyecto de bigtable.
`solana_bigtable_private_key_id`		Id de la clave privada de bigtable.
`solana_bigtable_private_key`		Clave privada de bigtable.
`solana_bigtable_client_email`		Correo electrónico del cliente de bigtable.
`solana_bigtable_client_id`		Id del cliente de bigtable.
`solana_bigtable_client_x509_cert_url`		URL del certificado de bigtable.

Para más información sobre BigTable consulta https://github.com/solana-labs/solana-bigtable.

Manejo de bifurcaciones

Ocasionalmente, devnet/testnet experimentará bifurcaciones. En este caso, usa los siguientes parámetros según lo indicado en Discord:

Nombre	Valor predeterminado	Descripción
`solana_hard_fork`		Bifurcación dura.
`solana_wait_for_supermajority`		Si el nodo debe esperar a la supermayoría.

Gobernador de CPU y configuraciones de Sysctl

Hay ciertas configuraciones que necesitas hacer para que tu nodo RPC funcione correctamente. Este rol puede ayudarte a realizar algunos de estos cambios de configuración estándar. Sin embargo, la optimización completa depende en gran medida de tu hardware, así que tómate el tiempo para familiarizarte con cómo configurar tu hardware correctamente.

Sin embargo, el elemento más importante de la optimización es el gobernador de rendimiento de la CPU. Esto controla el comportamiento de aumento y el uso de energía. En muchos hosts en centros de datos, están configurados para equilibrar rendimiento y uso de energía. En el caso de Solana, realmente necesitamos que funcionen a su máxima velocidad. Para establecer el gobernador de CPU de los servidores hay tres opciones:

Tienes acceso a la BIOS y configuras el ajuste de CPU en BIOS a max performance. Esto parece funcionar bien para sistemas HPE. En este caso, especifica la variable cpu_governor: bios. Esto a veces es necesario para sistemas AMD EPYC también.
Tienes acceso a la BIOS y configuras el ajuste de CPU en BIOS a os control. Este debería ser el predeterminado típico. En este caso puedes dejar la variable cpu_governor como predeterminada o configurarla explícitamente a cpu_governor: performance.
No tienes acceso a BIOS o configuraciones de gobernador de CPU. Si es posible, intenta establecer cpu_governor: performance. De lo contrario, ¡esperemos que tu proveedor lo haya configurado para un buen rendimiento!

La segunda configuración que necesitas hacer es editar varios parámetros del kernel para adaptarlos al caso de uso RPC de Solana.

Una opción es desplegar solana-sys-tuner junto con esta configuración para autotunear algunas variables por ti.

Una segunda opción, especialmente si eres nuevo en la optimización del rendimiento, es tuned y tune-adm de RedHat, donde el perfil throughput-performance es adecuado.

Finalmente, si despliegas a través de este rol, también puedes especificar una lista de valores sysctl para que este playbook los configure automáticamente en tu host. Esto permite un control completo y los establece de manera que se configuran de forma permanente. Aquí hay una lista de valores sysctl que hemos utilizado en rpcpool:

sysctl_optimisations:
  vm.max_map_count: 700000
  kernel.nmi_watchdog: 0
# Granularidad mínima de preemption para tareas dependientes de CPU:
# (predeterminado: 1 msec#  (1 + ilog(ncpus)), unidades: nanosegundos)
  kernel.sched_min_granularity_ns: '10000000'
# Granularidad de despertador SCHED_OTHER.
# (predeterminado: 1 msec#  (1 + ilog(ncpus)), unidades: nanosegundos)
  kernel.sched_wakeup_granularity_ns:  '15000000' 
  vm.swappiness: '30'
  kernel.hung_task_timeout_secs: 600
# esto significa que las estadísticas de memoria virtual se recopilan con menos frecuencia, pero es una compensación razonable por una latencia inferior
  vm.stat_interval: 10
  vm.dirty_ratio: 40
  vm.dirty_background_ratio: 10
  vm.dirty_expire_centisecs: 36000
  vm.dirty_writeback_centisecs: 3000
  vm.dirtytime_expire_seconds: 43200
  kernel.timer_migration: 0
# Un valor sugerido para pid_max es 1024 * <# de núcleos/hilos de cpu en el sistema>
  kernel.pid_max: 65536
  net.ipv4.tcp_fastopen: 3
# De solana systuner
# Referencia: https://medium.com/@CameronSparr/increase-os-udp-buffers-to-improve-performance-51d167bb1360
  net.core.rmem_max: 134217728
  net.core.rmem_default: 134217728
  net.core.wmem_max: 134217728
  net.core.wmem_default: 134217728

Ejemplos de Playbooks

Nodo de mainnet:

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: mainnet }

Nodo de testnet:

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: testnet }

Nodo de devnet:

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: devnet }

Iniciando el nodo RPC

Después del despliegue, puedes iniciar sesión en la máquina y ejecutar su -l solana para convertirte en el usuario de Solana.

Para ver el comando de validador de Solana generado para ti durante el despliegue, puedes revisar /home/solana/bin/solana-rpc.sh. Recuerda que cualquier cambio en este archivo se sobrescribirá la próxima vez que ejecutes esto en Ansible.

Para el primer inicio, deberías comentar --no-genesis-fetch y --no-snapshot-fetch en el archivo /home/solana/bin/solana-rpc.sh. Esto permitirá que Solana descargue los archivos básicos que necesita para el primer inicio. Recuerda activar nuevamente estas líneas después de haber iniciado el validador por primera vez.

Luego, inicia el proceso RPC de Solana ejecutando systemctl --user start solana-rpc. Puedes ver el estado del proceso ejecutando systemctl --user status solana-rpc. El primer inicio tomará algo de tiempo. Puedes monitorear el inicio ejecutando solana catchup --our-localhost.

Finalmente, para ver los registros de tu nodo RPC de Solana ejecuta journalctl --user -u solana-rpc -f.

Si es tu primera vez ejecutando un nodo de Solana, puedes encontrar más detalles sobre cómo operar el nodo en https://docs.solana.com/running-validator/validator-start y https://github.com/agjell/sol-tutorials/.

Verificando el nodo RPC

La verificación básica después de que hayas confirmado que el nodo ha iniciado es rastrear el catchup:

solana catchup --our-localhost

Después de esto, puedes continuar verificando que esté sirviendo correctamente las llamadas RPC.

Probando acceso RPC

También puedes intentar algunos comandos de validación sencillos (gracias buffalu: https://gist.github.com/buffalu/db6458d4f6a0b70ac303027b61a636af):

curl http://localhost:8899 -X POST -H "Content-Type: application/json" -d '
  {"jsonrpc":"2.0","id":1, "method":"getSlot", "params": [
      {
        "commitment": "processed"
      }
    ]}
'

curl http://localhost:8899  -X POST -H "Content-Type: application/json" -d '
  {"jsonrpc":"2.0","id":1, "method":"getSlot"}
'

Probando acceso websocket

La forma más fácil de probar websockets es instalar la utilidad wscat. Para hacerlo, necesitarás instalar NodeJS y NPM y luego ejecutar npm install wscat.

Luego puedes conectarte a tu websocket de la siguiente manera:

wscat -c localhost:8900

Desde allí, obtendrás un símbolo del sistema donde puedes ingresar manualmente tus solicitudes de suscripción a websocket:

> {"jsonrpc":"2.0", "id":1, "method":"slotSubscribe"}

Ahora deberías comenzar a recibir actualizaciones regulares sobre los slots a medida que son confirmados por tu nodo RPC.

Nodo RPC retrasándose/no alcanzando

El problema de rendimiento más común que puede enfrentar un nodo RPC es que sigue retrasándose con respecto a la red y no puede alcanzarla.

Si no puede alcanzarla la primera vez que lo iniciaste, esto se debe típicamente a una mala configuración. El problema más común son las frecuencias de aumento de tu CPU (para más detalles sobre la configuración de la CPU, consulta arriba):

Verifica que tu CPU sea lo suficientemente reciente (cualquier cosa < EPYC de 2ª generación en AMD o < Cascade Lake en Intel tendrá dificultades).
Verifica que el gobernador de tu CPU no esté configurado en modo de ahorro de energía en la BIOS y en tus configuraciones de kernel.
Observa las frecuencias de la CPU al ejecutar Solana con watch -n 1 grep MHz /proc/cpuinfo, necesitarás que esté > 3ghz en todos los núcleos típicamente (regla general). No deseas ver ningún núcleo bajando a 1.4-1.8 nunca.

Si solía poder alcanzarla pero ya no (o si arreglar la CPU no lo resolvió):

Verifica la memoria/CPU/red: ¿tienes buenas frecuencias de CPU, estás utilizando memoria swap (no suficiente memoria) o tu proveedor está limitando paquetes UDP?
- CPU: Arregla la configuración del gobernador/rendimiento de la CPU, consigue una CPU de nueva generación o una CPU con mejor turbo en todos los núcleos (consulta wikichip para detalles). Recuerda que MHz no es lo mismo entre diferentes generaciones. Broadwell a 3.0 GHz no es lo mismo que Cascade Lake a 3.0 GHz o EPYC de 3ª generación a 3.0 GHz.
- Red: Verifica la limitación de paquetes UDP y conectividad. Necesitas al menos un ancho de banda de 500 mbps sin ninguna limitación en UDP. Algunos proveedores tienden a bloquear o limitar UDP para protección DDoS. Esto se aplica tanto a la entrada como a la salida. Si te están limitando en la entrada, tu nodo no recibirá fragmentos de la red a tiempo. Verifica tus firewalls para que no
- Memoria: Consigue más RAM. A Solana no le gusta funcionar en swap, así que si estás utilizando swap con regularidad, necesitas solucionarlo. Una solución temporal puede ser desactivar los índices de spl-token-owner / spl-token-mint. Se han vuelto muy grandes.
- Disco: Verifica que tu NVME para almacenar el libro mayor y/o cuentas no esté fallando o esté muerto. Un simple dmesg o consulta de estado SMART debería ser capaz de decirte.
Existe un error que después de una intensa llamada a getBlocks a través de RPC, el nodo permanece permanentemente atrasado, intenta reiniciar el nodo y si eso ayuda, ese puede ser tu problema.
¿Has probado desconectarlo y volver a conectarlo? A veces ayuda limpiar tu libro mayor y reiniciar.
Verifica tus patrones de tráfico. Ciertos patrones de tráfico RPC pueden facilmente hacer que tu nodo se retrase. Quizás necesites agregar otro nodo y dividir tu tráfico RPC o necesitas limitar tus llamadas a consultas problemáticas como getProgramAccounts.

Acceso a datos históricos

Por defecto, cuando inicias el nodo RPC, comenzará a construir su libro mayor local a partir de los bloques que recibe a través de la red de Solana. Este libro mayor local comienza desde el punto de la instantánea de cuentas que descargaste al iniciar tu nodo. Si no agregas --no-snapshot-fetch a tu línea de comandos de solana-validator, el validador a menudo extraerá una instantánea de la red al iniciar. Esto dejará agujeros o lagunas en tu libro mayor entre el punto donde detuviste tu nodo RPC y el punto en el que descargó la instantánea de cuentas. Para evitar esto, siempre especifica --no-snapshot-fetch después de la primera vez que inicies el nodo. Recuerda que cada vez que extraigas una instantánea crearás un agujero en el libro mayor local.

El tamaño del libro mayor local se determina por el parámetro --limit-ledger-size, que se mide en fragmentos. Un fragmento es una unidad de datos fija. La conversión entre fragmentos y bloques no es fija, ya que los bloques pueden tener tamaños variables. Por lo tanto, es muy difícil decir cuánto historial, medido en tiempo o en número de bloques, almacenará tu nodo. Tendrás que ajustarlo de acuerdo con tus necesidades. Un buen punto de partida puede ser de 250 a 350 millones de fragmentos, lo que debería cubrir aproximadamente una época, que a su vez debería significar aproximadamente 3 días.

La cantidad exacta de datos que almacenará el nodo RPC también depende de los parámetros --enable-cpi-and-log-storage y --enable-rpc-transaction-history. Estos son necesarios para que el nodo retenga y sirva todos los datos de bloques y transacciones.

Tu nodo solo puede proporcionar datos que ha almacenado en su libro mayor local. Esto significa que tu historial siempre comenzará desde el punto en el que iniciaste el nodo (en realidad, la instantánea en el slot en el que iniciaste el nodo). Si la red está actualmente en el slot N y tú extrajiste una instantánea en el slot M, entonces tu nodo comenzará a reconstruir su historia entre el slot M y el slot N. Esto es lo que está sucediendo durante el catchup, el nodo está procesando (reproduciendo) todo lo que ha sucedido entre M y N hasta que se pone al día con la red y puede procesar toda la información entrante actual.

El nodo puede (en teoría) almacenar tanto historial como puedas montar en un almacenamiento de alta velocidad (por ejemplo, si no especificas --limit-ledger-size o le das un valor enorme). Sin embargo, esto no se escala desde el génesis. Para obtener todo el historial, puedes usar el soporte integrado de Google BigTable. Puedes configurar tu nodo para cargar datos a una instancia de Google BigTable, donde pueden estar permanentemente disponibles para consultas históricas. También puedes configurar tu nodo para soportar consultas a una instancia de BigTable. En este caso, para cualquier consulta que el nodo no tenga en su libro mayor local, realizará una solicitud a Google BigTable y, si lo encuentra en Google BigTable, podrá extraer los datos desde allí.

Algunos proveedores de RPC y la Fundación Solana tienen copias de BigTable que retroceden hasta el génesis. Para más información sobre esto, consulta https://github.com/solana-labs/solana-bigtable.

Índices y rendimiento: o, ¿por qué es tan lento mi RPC?

Hay tres índices que genera el validador de Solana: program-id, spl-token-mint, spl-token-owner. Los dos últimos se utilizan para soportar consultas a través de getTokensByOwner, getTokenLargestAccounts o vía getTokensByDelegate. También se utilizan para soportar consultas de getProgramAccounts, que emplean filtros específicos.

Estos índices han comenzado a crecer enormemente. Si no necesitas que estas consultas sean rápidas para tu nodo RPC, deberías eliminarlas ya que reducirás considerablemente el uso de memoria de tu nodo y también mejorarás los tiempos de inicio.

Si SÍ necesitas estas llamadas RPC, entonces SÍ necesitas activar los índices mediante la bandera de índice de cuentas, de lo contrario, estas llamadas se ejecutarán intolerablemente lentas. Esto requerirá mucha RAM; generalmente no recomendamos implementar esto con menos de 512 GB de RAM disponible.

Una alternativa a esto podría ser usar complementos Geyser, como el complemento de Postgres, que pueden ayudar a acelerar las consultas sin depender de índices en memoria: https://github.com/rpcpool/solana-geyser-park.

Preocupaciones de seguridad

La seguridad es un campo amplio y no puedes confiar en una pequeña guía en un repositorio de GitHub. Típicamente, al menos deberías asegurarte de que tu servidor RPC no exponga los puertos 8899 y 8900 directamente sin ningún tipo de proxy y control de acceso enfrente. Una forma sencilla de hacer esto es usar nginx o HAproxy como proxy inverso. Puedes agregar soporte SSL y autenticación de esta manera a través de las herramientas integradas de cada uno de estos.

Para estar seguro, puedes asegurarte de que tu rpc-bind-address esté establecido en 127.0.0.1 (el valor predeterminado para este rol) para que solo responda a solicitudes localmente.

Otras playbooks

Normalmente querrás desplegar un proxy inverso delante del Solana RPC. HAproxy es una gran opción y tenemos un playbook para configurar HAproxy para un servidor RPC de Solana aquí.

Otras guías y documentos

Estas son algunas otras guías, recursos y documentos escritos sobre Solana RPC:

No hacemos ninguna afirmación sobre la precisión o calidad de cualquiera de estos documentos. ¡Por favor, revísalos y forma tu propia opinión sobre qué documentos seguir!