Solana RPC Nodes: Setup, Providers & Best Practices

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

Последнее обновление: июль 2025 г.

Публичные эндпоинты Solana могут быть полезны для разработки, но не являются универсальной гарантией работы в продакшене. Если dApp возвращает ошибки 429, зависает при запросах к аккаунтам или испытывает проблемы с отправкой под нагрузкой, путь RPC — это один из компонентов, который следует изучить наряду с конструкцией транзакции, комиссиями, срочными параметрами (expiry), сетевым взаимодействием и состоянием кластера.

Это руководство охватывает, что такое RPC-узел Solana, чем он отличается от узла-валидатора, как запросы проходят через систему, где взять URL публичных эндпоинтов, какие методы RPC наиболее важны, как подключиться через @solana/web3.js, каких управляемых провайдеров стоит оценить, чего на самом деле требует самостоятельный хостинг и как исправить ошибки ограничения частоты запросов, с которыми вы, вероятно, уже столкнулись.

Коротко о главном: Для разработки используйте бесплатные публичные эндпоинты Solana Foundation. Для продакшена используйте управляемых провайдеров, таких как Helius, QuickNode, Alchemy или Triton One. Самостоятельный хостинг дает больше операционного контроля, но все же требует планирования мощностей, политик доступа, мониторинга и актуальных рекомендаций по оборудованию.

Перейти к:

• Что такое Solana RPC-узлы?
• RPC-узел против узла-валидатора
• Как работают Solana RPC-узлы
• Типы Solana RPC-узлов
• Почему качество RPC-узла имеет значение: DeFi, NFT и производительность dApp
• Лучшие провайдеры Solana RPC-узлов
• Подключение вашего приложения с помощью @solana/web3.js
• Методы Solana RPC: что можно запрашивать
• Как запустить собственный Solana RPC-узел
• Распространенные ошибки Solana RPC и способы их исправления
• Часто задаваемые вопросы
• Выбор правильной стратегии Solana RPC

Что такое Solana RPC-узлы?

Solana RPC-узел — это сервер, который реализует Solana JSON-RPC API, принимая запросы от клиентских приложений и возвращая данные о состоянии блокчейна в ответ. dApps, кошельки, обозреватели блоков и автоматизированные скрипты используют эти узлы для чтения балансов аккаунтов, отправки транзакций и подписки на ончейн-события без необходимости хранения локальной копии реестра.

Исторические материалы указывают на теоретическую пропускную способность Solana около 65 000 TPS и целевую длительность слота около 400 миллисекунд. Ни то, ни другое не является гарантированным результатом в реальном времени: определения транзакций, пропущенные слоты, трафик голосования, рабочая нагрузка, состояние кластера и версии программного обеспечения — всё это влияет на наблюдаемую производительность. Целевой темп и объем состояний аккаунтов по-прежнему предъявляют значительные требования к инфраструктуре RPC.

Удаленный вызов процедур (Remote Procedure Call, RPC) — это шаблон взаимодействия, при котором программа на одной машине вызывает функцию на другой машине так, как если бы она была локальной, при этом сетевая сложность абстрагирована. Ваше dApp может запрашивать состояние аккаунта и отправлять транзакции через удаленный узел вместо того, чтобы хранить собственную копию реестра. Solana использует JSON-RPC 2.0 в качестве протокола передачи данных: легковесный формат, который направляет вызовы по имени метода через HTTP или WebSocket, а не по путям URL на основе ресурсов, как в REST API.

Solana Foundation управляет бесплатными публичными эндпоинтами по адресу https://api.mainnet-beta.solana.com и аналогичными URL для devnet и testnet. Эти эндпоинты применяют ограничения частоты запросов (rate limits) на каждый IP-адрес. Когда ваше приложение превышает эти лимиты, оно получает ошибки HTTP 429 Too Many Requests, что приводит к периодическим сбоям и ухудшению пользовательского опыта под нагрузкой.

RPC-узел против узла-валидатора: понимание разницы

RPC-узел предоставляет данные блокчейна внешним клиентам через JSON-RPC API. Узел-валидатор участвует в консенсусе и голосует за валидность блоков. Это два основных типа узлов в Solana, и они служат разным целям.

Узлы-валидаторы участвуют в консенсусе Tower BFT, механизме голосования на основе Proof-of-Stake. Proof of History (PoH), механизм криптографического упорядочивания Solana (не являющийся протоколом консенсуса), устанавливает очередность перед голосованием. Tower BFT — это уровень консенсуса; PoH отвечает за синхронизацию времени.

Gulf Stream, протокол пересылки транзакций Solana, отправляет транзакции напрямую текущим и будущим лидерам, минуя мемпул, который используют другие блокчейны. За процесс пересылки отвечают валидаторы. RPC-узлы этого не делают.

Запуск RPC-узла не требует, чтобы вы внесли SOL в стейкинг. Некоторые операторы запускают функции валидатора и RPC на одной физической машине, но логически эти роли остаются разделенными: одна голосует в консенсусе, другая обслуживает запросы клиентов. Что касается требований к оборудованию для самостоятельного хостинга RPC-узла, требования к RAM и хранилищу значительно выше, чем для одного только валидатора.

Как работают Solana RPC-узлы: архитектура и поток данных

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

Жизненный цикл JSON-RPC запроса

1. Клиентское приложение (dApp, кошелек или скрипт) отправляет HTTP POST запрос или сообщение WebSocket на URL-адрес эндпоинта RPC-узла.
2. Тело запроса содержит полезную нагрузку JSON-RPC 2.0 с четырьмя полями: jsonrpc, id, method, params.
3. RPC-узел получает запрос и направляет его соответствующему внутреннему обработчику на основе поля method.
4. Узел запрашивает необходимые данные в своей локальной реплике реестра или хранилище состояний аккаунтов.
5. Узел возвращает ответ в формате JSON, содержащий либо запрошенные данные, либо структурированный объект ошибки.

Конкретный пример getBalance:

// Запрос
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBalance",
  "params": ["ВашПубличныйКлючBase58", {"commitment": "confirmed"}]
}

// Ответ
{
  "jsonrpc": "2.0",
  "result": {
    "context": {"slot": 285823400},
    "value": 5000000000
  },
  "id": 1
}
// Примечание: значение указано в лампортах. Разделите на 1 000 000 000 для перевода в SOL.

В отличие от REST API, использующих URL-адреса на основе ресурсов, JSON-RPC направляет каждый вызов через единый эндпоинт, используя поле method. Разработчики с опытом работы в Ethereum узнают структуру запроса. Solana отличается тремя ключевыми аспектами: здесь нет мемпула (транзакции идут напрямую к текущему лидеру), состояние хранится в аккаунтах, а не в хранилище контрактов EVM, а слоты длительностью 400 мс примерно в 30 раз быстрее 12-секундного времени блока в Ethereum.

Уровни обязательств (Commitment Levels): processed, confirmed, finalized

Каждый RPC-вызов, считывающий состояние, принимает параметр commitment:

• processed: Самый последний слот, который увидел узел. Самый быстрый, но теоретически слот может быть отозван (откат).
• confirmed: Слот получил квалифицированное большинство голосов валидаторов. Высокая окончательность для большинства случаев использования dApp.
• finalized: Слот стал постоянной частью цепочки. Используется для операций с высокими ставками.

Что хранит RPC-узел Solana

Узел хранит две категории данных. Текущее состояние аккаунтов находится в оперативной памяти (RAM): это снимок каждого активного аккаунта на последнем подтвержденном слоте, необходимый для быстрого ответа на запросы. Исторические данные реестра хранятся на NVMe SSD: все записи транзакций, организованные по слотам. В мейннет-бета Solana накапливает примерно от 100 до 200 ГБ данных реестра в день. Такой рост объема хранилища в сочетании с длительностью слота 400 мс объясняет, почему для RPC-узлов требуется минимум 256 ГБ оперативной памяти и несколько терабайт быстрого хранилища.

Для получения полного справочника по Solana JSON-RPC API посетите docs.solana.com/api.

HTTP против WebSocket: Выбор правильного транспорта

Типы RPC-узлов Solana: публичные, частные и самостоятельные

Доступ к RPC-узлам Solana осуществляется тремя способами: через бесплатные публичные эндпоинты Solana Foundation, через управляемого частного провайдера или через узел под самостоятельным управлением, которым вы оперируете напрямую.

Публичные RPC-эндпоинты Solana (бесплатные)

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

Публичные эндпоинты накладывают лимит примерно 100 запросов за 10 секунд на один IP-адрес. Превышение этого порога возвращает ошибку HTTP 429 Too Many Requests. Эти эндпоинты подходят для разработки и тестирования. Для использования в продакшне см. сравнение провайдеров RPC Solana ниже.

Для получения полной документации по кластерам посетите docs.solana.com/clusters.

Частные и управляемые провайдеры RPC-узлов

Управляемый RPC-провайдер может предлагать выделенные эндпоинты, более высокие заявленные лимиты, поддержку WebSocket, целевые уровни обслуживания и несколько регионов; конкретные функции зависят от текущего тарифного плана. Четыре основных провайдера для Solana:

• Helius: нативный для Solana провайдер с расширенными RPC API и уведомлениями через веб-хук
• QuickNode: мультичейн-провайдер с географическим распределением и маркетплейсом дополнений
• Alchemy: мультичейн-провайдер с инструментами разработки корпоративного уровня
• Triton One: специалист, ориентированный на Solana, сфокусированный на чистой производительности RPC для институциональных рабочих нагрузок

Полное сравнение с ценами, поддержкой WebSocket и отличительными особенностями находится в разделе сравнения провайдеров.

Самостоятельные RPC-узлы Solana

Самостоятельный хостинг дает вам полный контроль над вашей RPC-инфраструктурой без лимитов на частоту запросов, но стоимость оборудования начинается от тысяч долларов, а текущее обслуживание DevOps является нетривиальным. Полные требования и обзор настройки приведены в разделе «Как запустить собственный RPC-узел Solana».

Почему качество RPC-узла имеет значение: DeFi, NFT и производительность dApp

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

DeFi Торговые и арбитражные боты

DeFi протоколы на Solana обрабатывают чувствительные ко времени транзакции, где задержка определяет результат. Торговый бот, вызывающий getLatestBlockhash и sendTransaction через публичный эндпоинт с ограничением частоты, рискует получить устаревший хэш блока или отмену транзакции во время тайм-аута 429. На временной шкале Solana с 400-миллисекундными слотами разница в 50 мс во времени ответа RPC может определить, попадет ли транзакция в целевой слот или полностью пропустит его.

Jupiter (агрегатор), Raydium (AMM/DEX), Drift (бессрочные контракты) и Marginfi (кредитование) — все они зависят от доступа к RPC с низкой задержкой. В отличие от Ethereum DeFi, транзакции Solana полностью минуют мемпул через Gulf Stream, направляясь сразу к текущему лидеру. Здесь нет очереди заказов, на которую можно было бы положиться, если ваш RPC-вызов придет с опозданием.

NFT Минтинг и мониторинг маркетплейсов

Минты высокопопулярных NFT генерируют всплески из сотен одновременных вызовов sendTransaction от покупателей, конкурирующих за ограниченное предложение. Публичный эндпоинт, ограниченный примерно 10 запросами в секунду, возвращает ошибки 429 большинству участников во время пиковых нагрузок. NFT маркетплейсы, такие как Magic Eden и Tensor, используют подписки WebSocket logsSubscribe для обнаружения событий минта в режиме реального времени, что требует провайдера, обеспечивающего стабильные WebSocket-соединения в больших масштабах.

Кошельки вызывают getBalance и getTokenAccountBalance для каждого актива пользователя, а также getAccountInfo для чтения ончейн-метаданных. Кошелек, обслуживающий 10 000 активных пользователей, может генерировать десятки тысяч RPC-запросов в минуту. Частный RPC-провайдер с достаточной мощностью QPS (запросов в секунду) обеспечивает выполнение этих запросов без ухудшения пользовательского опыта. QPS здесь относится к пропускной способности RPC-запросов, а не к пропускной способности транзакций на уровне сети Solana.

Ончейн-аналитика, индексаторы и интеграции с биржами

Аналитические платформы и индексаторы многократно вызывают getBlock, чтобы воспроизвести полную историю транзакций реестра Solana. Полная историческая синхронизация последовательно отправляет тысячи запросов getBlock. Самостоятельные RPC-узлы или выделенные тарифные планы корпоративного уровня — единственные варианты, которые надежно выдерживают такой объем. Централизованные биржи, использующие собственные RPC-узлы Solana, применяют аналогичные паттерны высокой пропускной способности для сверки балансов пользователей и обнаружения депозитов в больших масштабах.

Время слота в Solana (400 мс) по сравнению с примерно 12-секундным временем блока в Ethereum означает, что dApp на Solana обращается к RPC примерно в 30 раз чаще за единицу времени для аналогичных операций, что делает производительность RPC-узла несоизмеримо более критичной здесь, чем в большинстве других сетей. Если вы сталкиваетесь с лимитами частоты запросов под трафиком в продакшне, переход на частного RPC-провайдера является самым прямым решением.

Сравнение провайдеров RPC-узлов Solana

Для большинства продакшн-dApps вопрос не в том, использовать ли управляемого RPC-провайдера, а в том, какой из них подходит для вашей рабочей нагрузки. В таблице представлены четыре основных варианта, а бесплатный публичный эндпоинт Solana Foundation взят в качестве базового уровня.

Информация о ценах в этой таблице была актуальна на момент публикации. Тарифные планы, цены и функции провайдеров часто меняются. Проверяйте актуальные данные непосредственно на сайте каждого провайдера перед выбором.

Последнее обновление: июль 2025 г.

Helius предлагает RPC-методы, ориентированные на Solana, вебхуки и функции парсинга транзакций. Возможности, квоты, цены, регионы и условия обслуживания следует проверять непосредственно на helius.dev и тестировать с предполагаемой рабочей нагрузкой.

QuickNode предлагает мультичейн RPC-инфраструктуру, региональные эндпоинты и дополнительные плагины. Проверяйте текущее покрытие Solana, квоты, цены и условия обслуживания на quicknode.com, затем протестируйте необходимые методы и регионы.

Alchemy предлагает мультичейн-инфраструктуру для разработчиков, включающую поддержку Solana. Подтвердите текущий охват методов, поведение WebSocket, лимиты, регионы и цены на alchemy.com, прежде чем рассматривать его как эквивалент другого провайдера.

Triton One предлагает инфраструктуру Solana для высокопроизводительных нагрузок. Задержка, доступность, географическое покрытие, лимиты и коммерческие условия требуют прямой проверки на triton.one и тестирования под конкретную нагрузку.

GenesysGo ранее управляла RPC-сервисом Solana под брендом Shadow. Проверьте текущий статус на genesysgo.com перед оценкой.

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

Как выбрать RPC-провайдера Solana

Выбор подходящего провайдера зависит от вашей рабочей нагрузки:

Заявления провайдеров о задержке не всегда сопоставимы напрямую. p50 — это медианное время ответа, в то время как p99 охватывает 1% самых медленных запросов и может иметь значение для операций, критичных ко времени. Фактические результаты зависят от набора методов, нагрузки, географической близости, кэширования и лимитов тарифного плана, поэтому протестируйте ожидаемую схему запросов перед выбором платного тарифа.

Подключение вашего приложения к RPC-узлу Solana с помощью @solana/web3.js

Для перехода с публичного эндпоинта Solana Foundation на частного провайдера требуется изменить всего одну строку в вашем приложении: строку URL, передаваемую в конструктор Connection.

Примечание к версии: Примеры кода в этом разделе используют @solana/web3.js v1.x, текущий стандарт индустрии. Solana Labs разрабатывает v2.0 с существенно иным API. Если вы используете v2.0, обратитесь к официальной документации v2.0 для поиска эквивалентных методов.

Установка и подключение

Шаг 1: Установите пакет

npm install @solana/web3.js

Шаг 2: Создайте экземпляр Connection и запросите баланс

import { Connection, PublicKey, LAMPORTS_PER_SOL } from "@solana/web3.js";

// Получайте эндпоинт из переменной окружения — никогда не прописывайте частный URL в коде
const RPC_ENDPOINT = process.env.RPC_URL ?? "https://api.devnet.solana.com";

const connection = new Connection(RPC_ENDPOINT, "confirmed");

async function getWalletBalance(address: string): Promise<void> {
  const publicKey = new PublicKey(address);

  // getBalance возвращает лампорты; разделите на LAMPORTS_PER_SOL (10^9), чтобы получить SOL
  const balanceLamports = await connection.getBalance(publicKey);
  const balanceSOL = balanceLamports / LAMPORTS_PER_SOL;

  console.log(`Баланс: ${balanceSOL} SOL`);
}

Шаг 3: Чтение данных аккаунта

async function getAccountData(address: string): Promise<void> {
  const publicKey = new PublicKey(address);

  // getAccountInfo возвращает null, если аккаунт не существует
  const accountInfo = await connection.getAccountInfo(publicKey);

  if (!accountInfo) {
    console.log("Аккаунт не найден");
    return;
  }

  console.log("Программа-владелец:", accountInfo.owner.toBase58());
  console.log("Длина данных (байты):", accountInfo.data.length);
  console.log("Лампорты:", accountInfo.lamports);
}

Шаг 4: Отправка транзакции

import {
  Transaction,
  SystemProgram,
  Keypair,
  sendAndConfirmTransaction,
} from "@solana/web3.js";

async function transferSOL(
  sender: Keypair,
  recipientAddress: string,
  amountSOL: number
): Promise<string> {
  const recipient = new PublicKey(recipientAddress);
  const lamports = amountSOL * LAMPORTS_PER_SOL;

  const transaction = new Transaction().add(
    SystemProgram.transfer({
      fromPubkey: sender.publicKey,
      toPubkey: recipient,
      lamports,
    })
  );

  // sendAndConfirmTransaction ожидает подтверждения (commitment: "confirmed") перед завершением
  const signature = await sendAndConfirmTransaction(connection, transaction, [sender]);
  return signature;
}

Шаг 5: Настройка переключения эндпоинтов на основе окружения

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

// config/rpc.ts
const RPC_ENDPOINTS: Record<string, string> = {
  "mainnet-beta": "https://api.mainnet-beta.solana.com",
  "devnet":       "https://api.devnet.solana.com",
  "private":      process.env.PRIVATE_RPC_URL ?? "",
};

const NETWORK = process.env.SOLANA_NETWORK ?? "devnet"; export const connection = new Connection(RPC_ENDPOINTS[NETWORK], "confirmed");

Примечание по безопасности: Никогда не прописывайте URL вашего частного RPC-эндпоинта в коде JavaScript на стороне клиента. URL, доступный в браузере, раскрывает ваш API ключ любому, кто просматривает сетевой трафик. Направляйте его через серверный прокси или эндпоинт бэкенд-API.

Полный справочник API @solana/web3.js см. на solana-labs.github.io/solana-web3.js.)

HTTP vs. WebSocket RPC-соединения: когда использовать каждое

Соединения WebSocket используют wss:// вместо https://. Большинство управляемых провайдеров предоставляют оба эндпоинта в рамках одного тарифного плана.

// WebSocket-подписка: отслеживание изменений аккаунта в реальном времени
const publicKey = new PublicKey("YourAccountPublicKeyHere");

const connectionWithWS = new Connection(
  process.env.RPC_URL ?? "https://api.devnet.solana.com",
  {
    commitment: "confirmed",
    wsEndpoint: process.env.WSS_URL ?? "wss://api.devnet.solana.com",
  }
);

// onAccountChange возвращает идентификатор подписки, используемый для последующей очистки
const subscriptionId = connectionWithWS.onAccountChange(
  publicKey,
  (accountInfo, context) => {
    console.log("Учетная запись изменена в слоте:", context.slot);
    console.log("Новый баланс лампортов:", accountInfo.lamports);
  },
  "confirmed"
);

// Удалите подписку, когда она больше не нужна:
// connectionWithWS.removeAccountChangeListener(subscriptionId);

Обработка ограничений скорости и ошибок 429

Ошибка 429 «Слишком много запросов» от общедоступной конечной точки Solana означает, что ваше приложение превысило ограничение скорости для данного IP-адреса. Для решения этой проблемы существует три стратегии:

1. Переключитесь на управляемого частного поставщика. Helius, QuickNode, Alchemy и Triton One предлагают планы, рассчитанные на производственный трафик. См. сравнение частных поставщиков RPC Solana.
2. Реализуйте экспоненциальное отступление (exponential backoff). При получении ответа 429 повторите попытку с задержкой, которая удваивается при каждой попытке (см. код ниже).
3. Пакетное чтение данных учетных записей с помощью getMultipleAccounts. Запрос 20 учетных записей одним вызовом расходует один запрос вместо 20.

// Обертка с экспоненциальным отступлением для любого RPC-вызова
async function withRetry<T>(
  fn: () => Promise<T>,
  maxRetries: number = 5
): Promise<T> {
  let attempt = 0;
  while (attempt < maxRetries) {
    try {
      return await fn();
    } catch (error: any) {
      const is429 = error?.message?.includes("429");
      if (is429 && attempt < maxRetries - 1) {
        // Подождите 500 мс, затем 1 с, затем 2 с, затем 4 с, затем 8 с
        const waitMs = 500 * Math.pow(2, attempt);
        await new Promise((resolve) => setTimeout(resolve, waitMs));
        attempt++;
      } else {
        throw error;
      }
    }
  }
  throw new Error("Превышено максимальное количество повторных попыток");
}

Методы RPC Solana: Что можно запрашивать

API Solana JSON-RPC предоставляет более 80 методов. Таблица ниже охватывает те, которые разработчики dApp используют регулярно.

Методы HTTP RPC

getRecentBlockhash устарел. Вместо него используйте getLatestBlockhash. Замена также возвращает lastValidBlockHeight, что позволяет надежно обрабатывать истечение срока действия транзакций.

Методы подписки WebSocket

Подписки WebSocket подходят для любого dApp, которому необходимо реагировать на ончейн-события без опроса. accountSubscribe срабатывает при изменении данных конкретной учетной записи, что полезно для отслеживания кошелька пользователя или учетной записи состояния программы Solana (эквивалент смарт-контракта в Ethereum). logsSubscribe передает журналы транзакций, соответствующие фильтру идентификатора программы, что используется протоколами DeFi, такими как Jupiter и Raydium, для обнаружения событий обмена по мере их возникновения.

Anchor, наиболее широко используемый фреймворк для разработки программ Solana, генерирует клиентские приложения TypeScript, которые под капотом вызывают эти методы через @solana/web3.js. Конфигурация RPC применяется идентично для dApp на базе Anchor.

Полный справочник методов, включая параметры, типы возвращаемых значений и коды ошибок, см. в документации API RPC Solana.)

Как запустить собственный узел RPC Solana: Требования и обзор настройки

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

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

Требования к оборудованию меняются по мере роста сети. Проверяйте текущие спецификации в официальной документации Solana по адресу docs.solana.com/running-validator) перед закупкой оборудования.

Модель Solana, основанная на учетных записях, хранит все состояния программы в отдельных учетных записях. Полный RPC-узел должен хранить текущее состояние всех активных учетных записей в оперативной памяти для быстрых ответов на запросы, а также исторические данные журнала на NVMe SSD. Рост хранилища на 100–200 ГБ в день в mainnet-beta означает, что операторы должны планировать постоянную ротацию журналов.

Обзор процесса настройки

Требуется семь этапов. Каждый шаг ссылается на официальную документацию Solana для получения полной информации о конфигурации.

1. Подготовьте оборудование, соответствующее или превосходящее указанные выше характеристики.
2. Установите операционную систему и настройте параметры ядра Linux: увеличьте лимиты дескрипторов файлов ulimit и настройте сетевые параметры sysctl для большого объема UDP-трафика Solana.
3. Установите Solana CLI и бинарный файл валидатора agave (ранее solana-validator) из официального канала выпуска Solana Labs.
4. Настройте узел для режима RPC, передав флаг --no-voting для отключения участия в консенсусе и установите --rpc-port 8899 (HTTP) и --rpc-pubsub-port 8900 (WebSocket).
5. Загрузите снимок из репозитория снимков Solana Foundation для начальной синхронизации с недавнего состояния, а не для воспроизведения с момента genesis.
6. Запустите узел и отслеживайте прогресс синхронизации, используя solana catchup для отслеживания отставания узла от пика кластера.
7. Настройте правила брандмауэра, чтобы открыть порты 8899 и 8900 только для авторизованных IP-адресов. Не раскрывайте свой RPC-порт публично без аутентификации.

Время синхронизации и текущее обслуживание

Синхронизация снимка занимает 1–3 дня на рекомендуемом оборудовании. Синхронизация с genesis занимает значительно больше времени и не рекомендуется.

«Bare metal» обычно стоит от 500 до 1500 долларов в месяц в зависимости от спецификаций и географии дата-центра. Облачные аналоги стоят дороже из-за накладных расходов на виртуализацию при нагрузках, интенсивно использующих хранилище. Рост хранилища на 100–200 ГБ в день заставляет выбирать между предварительным выделением огромных объемов или автоматизацией очистки журналов.

Команды, оценивающие решение «сделать или купить», должны сравнить затраты на управляемых поставщиков в разделе сравнения поставщиков, прежде чем приступать к закупке оборудования.

Распространенные ошибки RPC Solana и как их исправить

429 Слишком много запросов

Ваше приложение превысило лимит запросов для IP-адреса на общедоступной конечной точке Solana. Чтобы исправить это:

1. Переключитесь на управляемого частного поставщика. Helius, QuickNode, Alchemy и Triton One предлагают тарифы, рассчитанные на рабочую нагрузку продакшена. См. сравнение частных поставщиков RPC Solana.
2. Реализуйте экспоненциальную задержку. При ответе 429 повторите попытку с задержкой, которая удваивается при каждой попытке. Пример кода приведен в разделе обработки лимитов запросов.
3. Группируйте чтение аккаунтов с помощью getMultipleAccounts. Получение 20 аккаунтов одним вызовом расходует один запрос вместо 20.

Тайм-ауты подтверждения транзакций

Транзакция, отправленная через sendTransaction, не была принята. Хеш блока мог истечь, или сеть могла быть перегружена. Чтобы исправить это:

1. Вызовите getLatestBlockhash непосредственно перед созданием транзакции. Не используйте getRecentBlockhash (устарел).
2. Проверьте lastValidBlockHeight из ответа и повторите попытку до достижения этой высоты.
3. Используйте sendAndConfirmTransaction вместо необработанного sendTransaction для автоматической повторной попытки при временных сбоях.

Сбои лимитов запросов getProgramAccounts

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

Часто задаваемые вопросы: RPC-узлы Solana

Что такое RPC-узел Solana?

RPC-узел Solana — это сервер, реализующий API Solana JSON-RPC, принимающий запросы от клиентских приложений и возвращающий данные о состоянии блокчейна. dApps, кошельки и обозреватели блоков используют их для чтения балансов аккаунтов, получения истории транзакций и отправки подписанных транзакций в сеть без запуска локальной копии реестра.

Они выполняют разные роли. RPC-узел предоставляет данные внешним клиентам через API JSON-RPC, не участвует в консенсусе и не получает вознаграждений за стейкинг. Узел-валидатор голосует за валидность блоков в каждом слоте, требует наличие застейканного SOL и получает вознаграждение в SOL за правильные голоса. Некоторые операторы запускают оба на одном оборудовании, но роли логически разделены.

Да. Общедоступные конечные точки Solana Foundation по адресам api.mainnet-beta.solana.com, api.devnet.solana.com и api.testnet.solana.com бесплатны. Они применяют лимит запросов примерно в 100 запросов за 10-секундный интервал на IP-адрес. Эти конечные точки достаточны для разработки и тестирования, но не подходят для продакшн-dApps, обслуживающих реальных пользователей.

Три подхода работают вместе: переключитесь на управляемого частного RPC-поставщика для продакшн-трафика; реализуйте экспоненциальную задержку для повторных попыток с возрастающими интервалами ожидания; и группируйте несколько чтений аккаунтов в одиночные вызовы getMultipleAccounts вместо выдачи одного getAccountInfo на каждый аккаунт.

Минимум: 12-ядерный процессор, 256 ГБ ОЗУ DDR4, 2 ТБ NVMe SSD и выделенное сетевое подключение 1 Гбит/с. Рекомендуется для продакшена: 24-ядерный процессор, 512 ГБ ОЗУ, 2x 2 ТБ NVMe SSD и сеть 10 Гбит/с. Проверяйте текущие спецификации в документации валидатора Solana, так как требования возрастают по мере роста сети.

Планируйте от 1 до 3 дней с использованием недавнего снимка на рекомендуемом оборудовании. Синхронизация с нуля займет значительно больше времени. Solana Foundation предоставляет официальные снимки для ускорения процесса.

HTTP RPC использует модель stateless request-response. Ваше приложение отправляет один запрос и получает один ответ, что подходит для одноразовых запросов, таких как getBalance или sendTransaction. WebSocket RPC использует постоянное соединение с моделью подписки. Ваше приложение подписывается на ончейн-события и получает push-уведомления, когда эти события происходят. Используйте WebSocket для любой функции реального времени в вашем dApp.

Helius и QuickNode — два часто обсуждаемых варианта, но видимость в сообществе не является доказательством пригодности или производительности. Helius подходит для команд, разрабатывающих исключительно на Solana, которым нужны расширенные API, нативные для Solana. QuickNode подходит для команд, поддерживающих несколько блокчейнов в рамках одного аккаунта. Triton One — это вариант для институциональных нагрузок, где задержка p99 является основным ограничением. Правильный выбор зависит от вашей рабочей нагрузки и того, что важнее: функции, специфичные для Solana, или поддержка нескольких блокчейнов.

Связанные руководства по Solana

• Распространение блоков Solana Turbine
• Слоты и время блока Solana

Исследуйте SOL на Bybit

Читатели могут ознакомиться с текущей рыночной информацией по SOL) или спот-рынком SOL/USDT.). Эти ссылки предоставляют рыночную информацию и доступ; они не подтверждают техническое утверждение и не подразумевают, что SOL подходит для каждого читателя.

Существует три пути, и большинство команд сразу поймут, какой из них соответствует их текущему этапу.

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

Следующие шаги:

• Зарегистрируйтесь для получения бесплатного уровня для разработки: helius.dev или quicknode.com
• Ознакомьтесь с полным справочником методов Solana JSON-RPC: docs.solana.com/api
• Изучите спецификации оборудования перед выделением ресурсов для самостоятельного хостинга: How to Run Your Own Solana RPC Node