solana_rpc

Роль RPC Solana

Ansible-роль для развертывания узла Solana RPC. Эта роль настраивает программное обеспечение валидатора в режиме RPC, работая под пользователем solana. Сервис RPC устанавливается как пользовательский сервис, работающий под тем же пользователем.

Обновления

16/02 - С версии Solana 1.8.15 (основная сеть) и 1.9.6 (тестовая сеть) вам нужно будет указать solana_full_rpc_api: true, чтобы эта роль фактически создала полностью экспонированный узел RPC API.

Требования к оборудованию

Сервер RPC требует по крайней мере таких же характеристик, как и валидатор Solana, но обычно имеет более высокие требования. В частности, мы рекомендуем использовать 256 ГБ оперативной памяти для хранения индексов. Для получения дополнительной информации о требованиях к оборудованию, пожалуйста, смотрите https://docs.solana.com/running-validator/validator-reqs. Мы настоятельно рекомендуем использовать физический сервер (не Hetzner), а не облачного провайдера, если вы не знаете, что делаете (и тогда зачем вы читаете эту страницу?).

Перед развертыванием вам следует подготовить хост, чтобы директории, которые вы используете для вашей базы данных аккаунтов и местоположения бухгалтерии, были правильно настроены. Это может включать настройку папки tmpfs для аккаунтов и отдельную файловую систему (желательно на диске NVME) для бухгалтерии. Один из распространенных способов конфигурации может выглядеть так:

/solana/tmpfs - 100 ГБ раздел tmpfs для хранения состояния аккаунтов
/solana/ledger - 2 ТБ диск NVME для хранения бухгалтерии

Почему физический сервер, а не облако?

Облачные серверы (AWS, GCP и т.д.) обычно неподходящи для Solana по ряду причин:

Выходные данные очень дорогие, и Solana будет использовать много выходных данных
Производительность одного ядра обычно слишком низка и не может разогнаться так, как это может сделать физический сервер
Многие облачные провайдеры не хотят такой нагрузки, как у Solana, на своих дешевых инстансах, что приводит к использованию очень дорогих физических инстансов.

Почему не Hetzner?

Hetzner решил, что не хочет, чтобы услуги Solana RPC работали в их сети. Они активно блокируют подключения к узлам Solana и ограничивают трафик Solana. Не только ваш узел Solana будет бороться с поддержанием сети (в основной сети он, вероятно, никогда не догонит), но также Hetzner, скорее всего, закроет ваш аккаунт.

Требования к программному обеспечению

Ansible >= 2.7 (протестировано в основном на Ansible 2.8)
Ubuntu 18.04+ на целевой машине развертывания

Эта роль предполагает некоторую знакомость с процессом развертывания программного обеспечения валидатора Solana.

Переменные роли

Развертывание обеспечивает, чтобы контрольная сумма для версии solana-installer, которую вы загружаете, совпадала с указанной в vars/main.yml. Если вы хотите установить версию solana, не указанную там, будет хорошо, если вы сначала загрузите и проверите контрольную сумму sha256 скрипта solana-installer (https://raw.githubusercontent.com/solana-labs/solana/master/install/solana-install-init.sh).

Существует множество настраиваемых параметров для Solana. Многие из них имеют рабочие значения по умолчанию, и вы можете использовать эту роль для развертывания узла Solana RPC, не изменяя никаких значений по умолчанию, и у вас должен быть приличный опыт. Если вы запустите эту роль, не указывая никаких параметров, она настроит стандартный узел RPC для mainnet.

Основные переменные

Это основные переменные, которые настраивают установку валидаторов. У них есть значения по умолчанию, но вы, вероятно, захотите настроить их в зависимости от вашей конфигурации.

Имя	Значение по умолчанию	Описание
`solana_version`	stable	Версия solana для установки.
`solana_full_rpc_api`	`true`	Включить ли полный RPC API или нет. Обычно это то, что вам нужно.
`solana_root`	/solana	Основная директория для бухгалтерии и аккаунтов Solana
`solana_ledger_location`	/solana/ledger	Хранилище для бухгалтерии Solana (должно быть на NVME)
`solana_accounts_location`	/solana/ledger/accounts	Хранилище для информации об аккаунтах Solana. Если вы используете tmpfs для аккаунтов, это должно быть подкаталогом вашей точки монтирования tmpfs (например, `/solana/tmpfs/accounts`, если tmpfs смонтирован на `/solana/tmpfs`)
`solana_snapshots_location`		Хранилище для снимков Solana. Может быть полезно хранить на отдельном NVME от вашей бухгалтерии.
`solana_keypairs`	`[]`	Список ключей для копирования на узел валидатора. Каждый элемент в списке должен иметь `key` и `name`. Это создаст `/home/solana/<name>.json`, содержащий значение `key`.
`solana_generate_keypair`	true	Генерировать ли ключевую пару или нет. Если вы не указали `solana_keypairs` и установили это в true, будет сгенерирован новый ключ и помещен в /home/solana/identity.json
`solana_public_key`	`/home/solana/identity.json`	Местоположение идентичности узла валидатора.
`solana_network`	mainnet	Сеть Solana, частью которой должен быть этот узел
`solana_environment`	смотрите defaults/main.yml	Переменные окружения, которые следует указать для узла валидатора, самое важное `RUST_LOG`
`solana_enabled_services`	`[ solana-rpc ]`	Список служб для автоматического запуска при загрузке
`solana_disabled_services`	`[ ]`	Список служб для отключения

Порты

Следующие порты необходимо настроить для вашего RPC сервера.

Имя	Значение по умолчанию	Описание
`solana_gossip_port`	8001	Порт для трафика общения (должен быть публично открыт в брандмауэре как для TCP, так и для UDP)
`solana_rpc_port`	8899 (+8900)	Порты для входящего RPC (и websocket). Обычно открыты только на localhost. Поместите прокси, например `haproxy`, перед этими портами и не открывайте их публично.
`solana_rpc_bind_address`	127.0.0.1	Адрес для привязки RPC. Обычно это localhost. Поместите прокси, например `haproxy`, перед этим для принятия публичного трафика.
`solana_dynamic_port_range`	8002-8020	Порт для входящего трафика Solana. Возможно, его нужно будет открыть в брандмауэре для UDP.

Из этого списка видно, что вам нужно, чтобы как минимум порты 8001-8020 были открыты в вашем брандмауэре для входящего трафика по умолчанию.

Для чистых узлов RPC может быть возможно закрыть порты TPU и TPU forward. Эти порты выделяются динамически, и вы можете видеть их, глядя на ваш узел в solana gossip. Если вы хотите их заблокировать, можете использовать эту утилиту: https://github.com/rpcpool/tpu-traffic-classifier. Используя этот инструмент, вы можете заблокировать входящий TPU и TPU forward на локальном узле, запустив:

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

Поместите это в сервис SystemD, и вы сможете запустить его при загрузке узла и оставить в непрерывной работе.

Специфические переменные сети

Значения по умолчанию для этих переменных указаны в vars/{{ solana_network }}-default.yml (например, vars/mainnet-default.yml). Вы также можете указать свои, предоставив файл {{ solana_network }}.yml. Вам нужно будет указать все эти переменные, если вы не полагаетесь на значения по умолчанию.

Имя	Значение по умолчанию	Описание
`solana_network`	mainnet	Сеть Solana, к которой должен присоединиться этот узел
`solana_metrics_config`	смотрите vars/mainnet-default.yml	Конечная точка метрик
`solana_genesis_hash`	смотрите vars/mainnet-default.yml	Генезис-хэш для этой сети
`solana_entrypoints`	смотрите vars/mainnet-default.yml	Хосты-узлы входа
`solana_known_validators`	смотрите vars/mainnet-default.yml	Известные валидаторы, с которых нужно загружать снимки и генезис на старте
`solana_expected_bank_hash`	смотрите vars/mainnet-default.yml	Ожидаемый банк-хэш
`solana_expected_shred_version`	смотрите vars/mainnet-default.yml	Ожидаемая версия обрывков
`solana_index_exclude_keys`	смотрите vars/mainnet-default.yml	Ключи, которые следует исключить из индексов по соображениям производительности

Специфические переменные RPC

Имя	Значение по умолчанию	Описание
`solana_rpc_faucet_address`		Укажите адрес RPC крана
`solana_rpc_history`	true	Предоставлять ли исторические значения через RPC
`solana_account_index`	program-id spl-token-owner spl-token-mint	Какие индексы активировать. Они значительно улучшают производительность, но замедляют время старта и могут увеличить требования к памяти.

Переменные производительности

Это переменные, которые вы можете настроить для повышения производительности.

Имя	Значение по умолчанию	Описание
`solana_snapshot_compression`		Сжимать ли снимки или нет. Укажите none, чтобы повысить производительность.
`solana_snapshot_interval_slots`		Как часто делать снимки. Увеличьте, чтобы повысить производительность. Рекомендуемое значение - 500.
`solana_pubsub_max_connections`	1000	Максимальное число соединений pubsub, разрешенных для установки.
`solana_bpf_jit`		Включить ли BPF JIT. По умолчанию на devnet.
`solana_banking_threads`	16	Количество потоков банковского обслуживания.
`solana_rpc_threads`		Количество потоков RPC (максимальное количество потоков/ядер в системе по умолчанию)
`solana_limit_ledger_size`	`solana default, 250 mio`	Размер локальной бухгалтерии для хранения. Для полного эпохи установите значение от 350 млн до 500 млн. Для наилучшей производительности установите 50 (минимальное значение).
`solana_accounts_db_caching`		Включить ли кэширование базы данных аккаунтов
`solana_accounts_shrink_path`		Вы можете указать другое местоположение для процесса сжатия аккаунтов

Bigtable

Вы можете указать учетные данные аккаунта Google Bigtable для запроса блоков, которые отсутствуют в локальной бухгалтерии.

Имя	Значение по умолчанию	Описание
`solana_bigtable_enabled`	false	Включить доступ к bigtable
`solana_bigtable_upload_enabled`	false	Включить загрузку в bigtable (учетные данные, которые вы предоставляете ниже, должны иметь доступ для записи)
`solana_bigtable_project_id`		Проект bigtable id
`solana_bigtable_private_key_id`		Частный ключ bigtable id
`solana_bigtable_private_key`		Частный ключ bigtable
`solana_bigtable_client_email`		Клиентская электронная почта bigtable
`solana_bigtable_client_id`		Клиентский идентификатор bigtable
`solana_bigtable_client_x509_cert_url`		URL сертификата bigtable

Для получения дополнительной информации о BigTable смотрите https://github.com/solana-labs/solana-bigtable .

Обработка форков

Иногда devnet/testnet могут испытывать форки. В таких случаях используйте следующие параметры, как указано в Discord:

Имя	Значение по умолчанию	Описание
`solana_hard_fork`		Хард-форк
`solana_wait_for_supermajority`		Должен ли узел ждать супербольшинства

Управление процессором и настройки Sysctl

Существуют определенные конфигурации, которые необходимо выполнить, чтобы ваш узел RPC работал правильно. Эта роль может помочь вам внести некоторые из этих стандартных изменений конфигурации. Однако полная оптимизация во многом зависит от вашего оборудования, поэтому вам нужно потратить время на ознакомление с оптимальной конфигурацией вашего оборудования.

Однако, самым важным элементом оптимизации является производительность процессора. Это контролирует поведение разгона и потребление энергии. На многих серверах в дата-центрах они настроены на баланс между производительностью и энергопотреблением. В случае Solana нам действительно нужно, чтобы они работали на полную мощность. Для настройки процессора сервера имеется три варианта:

У вас есть доступ к BIOS, и вы настраиваете параметр процессора BIOS на максимальная производительность. Это, как правило, работает хорошо для систем HPE. В этом случае укажите переменную cpu_governor: bios. Это иногда требуется и для систем AMD EPYC.
У вас есть доступ к BIOS, и вы настраиваете параметр процессора BIOS на управление ОС. Это должно быть стандартным значением по умолчанию. В этом случае вы можете оставить переменную cpu_governor по умолчанию или установить ее явно в cpu_governor: performance.
У вас нет доступа к BIOS или к настройкам процессора. Если возможно, попытайтесь установить cpu_governor: performance. В противном случае, надеюсь, ваш провайдер настроил это для хорошей производительности!

Второе изменение, которое необходимо внести, - это редактирование различных параметров ядра, чтобы соответствовать используемому случаю Solana RPC.

Один из вариантов - развернуть solana-sys-tuner вместе с этой конфигурацией, чтобы автоматически настроить некоторые переменные за вас.

Второй вариант, особенно если вы новичок в настройках производительности, - это tuned и tune-adm от RedHat, где профиль throughput-performance подходит.

Наконец, если вы развертываете через эту роль, вы можете также указать список значений sysctl, которые этот плейбук автоматически будет настраивать на вашем хосте. Это позволяет получить полный контроль и устанавливает их так, чтобы они были постоянно сконфигурированы. Вот список значений sysctl, которые мы использовали на rpcpool:

sysctl_optimisations:
  vm.max_map_count: 700000
  kernel.nmi_watchdog: 0
# Минимальная гранулярность прерывания для задач, связанных с ЦП:
# (по умолчанию: 1 мс # (1 + ilog(ncpus)), единицы: наносекунды)
  kernel.sched_min_granularity_ns: '10000000'
# Гранулярность пробуждения SCHED_OTHER.
# (по умолчанию: 1 мс # (1 + ilog(ncpus)), единицы: наносекунды)
  kernel.sched_wakeup_granularity_ns:  '15000000' 
  vm.swappiness: '30'
  kernel.hung_task_timeout_secs: 600
# это означает, что статистика виртуальной памяти собирается реже, но это разумный компромисс для более низкой задержки
  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
# Предполагаемое значение для pid_max - 1024 * <количество ядер/потоков в системе>
  kernel.pid_max: 65536
  net.ipv4.tcp_fastopen: 3
# От solana systuner
# Ссылка: 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

Примеры плейбуков

Узел основной сети:

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

Узел тестовой сети:

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

Узел девнет:

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

Запуск узла RPC

После развертывания вы можете войти в систему и запустить su -l solana, чтобы стать пользователем solana.

Чтобы увидеть сгенерированную командную строку валидатора Solana, вы можете взглянуть на /home/solana/bin/solana-rpc.sh. Помните, что любые изменения в этом файле будут перезаписаны в следующий раз, когда вы запустите этот Ansible.

При первом запуске вы должны закомментировать --no-genesis-fetch и --no-snapshot-fetch в файле /home/solana/bin/solana-rpc.sh. Это позволит Solana скачать основные файлы, необходимые для первого запуска. Не забудьте снова активировать эти строки после первого запуска валидатора.

Затем запустите процесс Solana RPC, выполнив systemctl --user start solana-rpc. Вы можете увидеть статус процесса, выполнив systemctl --user status solana-rpc. Первый запуск займет некоторое время. Вы можете отслеживать запуск, запустив solana catchup --our-localhost.

Наконец, чтобы увидеть логи вашего узла Solana RPC, выполните journalctl --user -u solana-rpc -f.

Если это ваш первый запуск узла Solana, вы можете найти более подробную информацию о том, как управлять узлом на https://docs.solana.com/running-validator/validator-start и https://github.com/agjell/sol-tutorials/.

Проверка узла RPC

Основная проверка после того, как вы убедитесь, что узел запустился, заключается в отслеживании догонок:

solana catchup --our-localhost

После этого вы можете продолжать проверять, правильно ли он обслуживает вызовы RPC.

Тестирование доступа RPC

Вы также можете попробовать несколько простых команд для проверки (спасибо 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"}
'

Тестирование доступа через вебсокеты

Легкий способ протестировать вебсокеты - установить утилиту wscat. Для этого вам нужно будет установить NodeJS и NPM, а затем запустить npm install wscat.

Затем вы можете подключиться к своему вебсокету следующим образом:

wscat -c localhost:8900

После этого вы получите командную строку, где сможете вручную вводить запросы на подписку вебсокетов:

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

Теперь вы должны начать получать регулярные обновления о слотах по мере их подтверждения вашим узлом RPC.

Узел RPC отстает/не догоняет

Самая типичная проблема производительности, с которой может столкнуться узел RPC, это то, что он постоянно отстает от сети и не может догнать.

Если он не может догнать при первом запуске, это обычно связано с неправильной конфигурацией. Наиболее распространенной проблемой являются частоты разгона вашего процессора (для получения дополнительной информации о конфигурации процессора смотрите выше):

Убедитесь, что ваш процессор достаточно современный (все, что меньше второго поколения EPYC от AMD или Cascade Lake от Intel, будет иметь трудности)
Проверьте, что ваш процессор не настроен на режим энергосбережения в BIOS и в настройках ядра
Наблюдайте за частотами процессора, когда вы запускаете solana с помощью watch -n 1 grep MHz /proc/cpuinfo, они обычно должны быть выше 3 ГГц на всех ядрах (просто правило). Вы не хотите видеть, чтобы какое-либо ядро опускалось до 1.4-1.8 когда-либо.

Если он когда-то мог догнать, но больше не может (или если исправление процессора не решило проблему):

Проверьте память/ЦП/сеть - у вас хорошие частоты ЦП, переносите ли вы в swap (недостаток памяти) или ваш провайдер ограничивает UDP-трафик?
- ЦП: Исправьте настройки производительности/разгона, получите процессор более нового поколения или процессор с лучшим разгонным коэффициентом (смотрите wikichip для деталей). Помните, что МГц не одинаковы для разных поколений. Broadwell 3.0 ГГц не такая же, как Cascade Lake 3.0 ГГц или EPYC третьего поколения 3.0 ГГц.
- Сеть: Проверьте ограничения пакетов UDP и подключение. Вам нужно как минимум 500 Мбит/с без ограничения UDP. Некоторые провайдеры любят блокировать или ограничивать UDP для защиты от DDoS. Это относится как к входящему, так и к исходящему трафику. Если у вас ограничения на входящие данные, ваш узел не сможет вовремя получать обрывки с сети. Проверьте свои брандмауэры.
- Память: Добавьте больше оперативной памяти. Solana не любит работать на swap, поэтому, если вы постоянно используете swap, вам нужно это исправить. Одно временное решение может заключаться в отключении индексов spl-token-owner / spl-token-mint. Они сильно разрослись.
- Диск: Убедитесь, что ваш NVME для хранения бухгалтерии и/или аккаунтов не поврежден или не умирает. Простая команда dmesg или запрос статуса SMART должны помочь вам это понять.
Есть ошибка, что после больших запросов getBlocks через RPC узел остается постоянно отстающим, попробуйте перезапустить узел, и если это поможет, то, возможно, это ваша проблема.
Пробовали ли вы его отключить и снова включить? Иногда это может помочь очистить вашу бухгалтерию и перезапустить.
Проверьте свои схемы трафика. Определенные схемы трафика RPC могут легко подтолкнуть ваш узел назад. Возможно, вам нужно добавить другой узел и разделить трафик RPC, или вам нужно ограничивать количество вызовов к проблемным запросам, таким как getProgramAccounts.

Доступ к историческим данным

По умолчанию, когда вы запускаете узел RPC, он начинает создавать свою локальную бухгалтерию из блоков, которые он получает через сеть Solana. Эта локальная бухгалтерия начинается с точки снимка аккаунтов, который вы загрузили, когда ваш узел запускался. Если вы не добавите --no-snapshot-fetch в вашу командную строку solana-validator, валидатор часто будет загружать снимок из сети во время запуска. Это оставит дыры или пропуски в вашей бухгалтерии между моментом, когда вы остановили узел RPC, и моментом, в который он загрузил снимок аккаунтов. Чтобы этого избежать, всегда указывайте --no-snapshot-fetch после первого запуска узла. Помните, что каждый раз, когда вы загружаете снимок, вы создаете дыру в локальной бухгалтерии.

Размер локальной бухгалтерии определяется параметром --limit-ledger-size, который измеряется в обрывках. Обрывок - это фиксированная единица данных. Конвертация между обрывками и блоками не фиксирована, так как блоки могут иметь разный размер. Поэтому очень трудно сказать, сколько истории, измеряемой во времени или в количестве блоков, ваш узел будет хранить. Вам нужно настроить это в соответствии с вашими нуждами. Хорошей отправной точкой может быть 250-350 миллионов обрывков, которые должны покрывать примерно одно эпоху, что в свою очередь должно означать, что это примерно 3 дня.

Точное количество данных, которые узел RPC будет хранить, также зависит от параметров --enable-cpi-and-log-storage и --enable-rpc-transaction-history. Эти параметры необходимы для того, чтобы узел сохранял и обслуживал полные данные о блоках и транзакциях.

Ваш узел может предоставить только данные, которые он сохранил в своей локальной бухгалтерии. Это означает, что ваша история всегда будет начинаться с момента, когда вы запустили узел (фактически: с момента снимка, на котором вы запустили узел). Если сеть в настоящее время находится в слоте N, и вы получили снимок на слоте M, то ваш узел начнет восстанавливать свою историю между слотом M и слотом N. Это происходит во время catchup, когда узел обрабатывает (воспроизводит) все, что произошло между M и N, пока не догонит сеть и не сможет обрабатывать все текущие входящие данные.

Узел может (теоретически) хранить столько историй, сколько вы сможете разместить на высокоскоростном хранилище (например, если вы /не/ указываете --limit-ledger-size или задаете этому большое значение). Однако это не масштабируется до генезиса. Чтобы получить всю историю, вы можете воспользоваться встроенной поддержкой Google BigTable. Вы можете настроить свой узел на загрузку данных в экземпляр Google BigTable, где они могут быть постоянно доступны для исторического запроса. Вы также можете настроить свой узел для поддержки запросов к экземпляру BigTable. В этом случае для любых запросов, которых узел не имеет в своей локальной бухгалтерии, он сделает запрос к Google BigTable, и если найдет там, сможет извлечь данные оттуда.

Некоторые провайдеры RPC и Фонд Solana имеют копии BigTable, которые ведут историю с генезиса. Для получения дополнительной информации смотрите https://github.com/solana-labs/solana-bigtable .

Индексы и производительность: или, почему мой RPC такой медленный?

Существуют три индекса, которые валидатор Solana генерирует: program-id, spl-token-mint, spl-token-owner. Последние два используются для поддержки запросов либо через getTokensByOwner, getTokenLargestAccounts, либо через getTokensByDelegate. Они также используются для поддержки запросов getProgramAccounts, которые используют конкретные фильтры.

Эти индексы стали расти до огромных размеров. Если вам не нужно, чтобы эти запросы выполнялись быстро для вашего узла RPC, то вам следует удалить их, поскольку вы значительно уменьшите использование памяти узла и улучшите время запуска.

Если вам действительно нужны эти вызовы RPC, то вам действительно нужно активировать индексы через флаг индекса аккаунта, в противном случае эти вызовы будут выполняться неприемлемо медленно. Это потребует много ОЗУ - обычно мы не рекомендуем разворачивать их с менее чем 512 ГБ доступной памяти.

В качестве альтернативы вы можете использовать плагины Geyser, такие как плагин postgres, которые могут помочь ускорить запросы без зависимости от индексов в памяти: https://github.com/rpcpool/solana-geyser-park.

Проблемы безопасности

Безопасность - это широкая область, и вы не можете полагаться на небольшое руководство в репозитории GitHub. Обычно вам, как минимум, следует убедиться, что ваш сервер RPC не открывает напрямую порты 8899 и 8900 без какого-либо прокси и контроля доступа перед ним. Легкий способ сделать это - использовать nginx или HAproxy в качестве обратного прокси. Вы можете добавить поддержку SSL и аутентификацию таким образом с помощью встроенных инструментов каждого из этих приложений.

Чтобы быть в безопасности, вы можете убедиться, что ваш rpc-bind-address установлен на 127.0.0.1 (по умолчанию для этой роли), чтобы он отвечал только на локальные запросы.

Другие плейбуки

Обычно вы захотите развернуть обратный прокси перед Solana RPC. HAproxy - отличный вариант, и у нас есть плейбук для настройки HAproxy для сервера solana rpc здесь.