Соланівські RPC-вузли: налаштування, постачальники та найкращі практики

RPC-вузли Solana надають інтерфейси для читання, подання та підписки, які застосунки використовують для зв'язку з мережею. Функції постачальників, ліміти, ціни, вимоги до обладнання та показники продуктивності змінюються з часом, тому рішення для робочого середовища (production) слід перевіряти на відповідність поточній документації та результатам тестів під навантаженням.

Останнє оновлення: липень 2025 року

Публічні кінцеві точки Solana можуть бути корисними для розробки, але не є універсальною гарантією обслуговування у продакшні. Якщо dApp повертає помилки 429, зависає на запитах акаунтів або має проблеми з поданням під навантаженням, шлях RPC є одним із компонентів, який слід перевірити разом із побудовою транзакції, комісіями, строковістю, мережею та умовами кластера.

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

Стисло (TL;DR): Для розробки використовуйте безкоштовні публічні кінцеві точки Solana Foundation. Для продакшну використовуйте керованого постачальника, такого як Helius, QuickNode, Alchemy або Triton One. Власний хостинг пропонує більше операційного контролю, але все одно вимагає планування потужностей, політик доступу, моніторингу та відповідності актуальним рекомендаціям щодо обладнання.

Перейти до:

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

Що таке RPC-вузли Solana?

RPC-вузол Solana — це сервер, який реалізує 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 та сховища суттєво вищі, ніж для одного лише валідатора.

Як працюють RPC-вузли Solana: архітектура та потік даних

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 ГБ даних реєстру на день в основній мережі mainnet-beta. Таке зростання обсягу сховища у поєднанні зі слотами тривалістю 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. Ці ендпоїнти підходять для розробки та тестування. Для використання у продакшні див. порівняння провайдерів Solana RPC нижче.

Повну документацію щодо кластерів див. на 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. У 400-мілісекундному графіку слотів Solana різниця в 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 мс порівняно з блоком Ethereum тривалістю приблизно 12 секунд означає, що 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 раніше керував службою Solana RPC під брендом Shadow. Перевірте поточний стан на genesysgo.com перед оцінкою.

Усі основні постачальники пропонують безкоштовні рівні або пробні плани, достатні для розробки та тестування. Ліміти частоти запитів стають проблемою для продуктивного середовища лише тоді, коли ваш додаток обслуговує реальних користувачів у великих масштабах.

Як оцінити постачальника Solana RPC

Вибір постачальника залежить від вашого навантаження:

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

Підключення вашого додатка до вузла Solana RPC за допомогою @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: Ініціалізація підключення та перевірка балансу

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 очікує статусу "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 проти WebSocket RPC підключень: коли і що використовувати

WebSocket-з'єднання використовують wss:// замість https://. Більшість керованих постачальників надають обидві точки доступу в межах одного плану.

// WebSocket-підписка: моніторинг змін акаунта в реальному часі
const publicKey = new PublicKey("ВашПублічнийКлючАкаунтаТут");

// WebSocket-підписка: моніторинг змін облікового запису в режимі реального часу const publicKey = new PublicKey("ВашПублічнийКлючОбліковогоЗаписуТут");

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 Too Many Requests від публічної кінцевої точки Solana означає, що ваша програма перевищила ліміт запитів на IP-адресу. Існують три стратегії для вирішення цієї проблеми:

1. **Перейдіть на керованого приватного постачальника.** Helius, QuickNode, Alchemy та Triton One пропонують плани, розраховані на виробничий трафік. Див. порівняння приватних постачальників Solana RPC.
2. **Впровадьте експоненційне відкладання.** У разі відповіді 429 повторіть спробу із затримкою, яка подвоюється з кожною спробою (див. код нижче).
3. **Пакетне зчитування облікових записів за допомогою `getMultipleAccounts`.** Отримання 20 облікових записів за один виклик споживає один запит замість 20.

// Exponential backoff wrapper for any RPC call
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) {
        // Wait 500ms, then 1s, then 2s, then 4s, then 8s
        const waitMs = 500 * Math.pow(2, attempt);
        await new Promise((resolve) => setTimeout(resolve, waitMs));
        attempt++;
      } else {
        throw error;
      }
    }
  }
  throw new Error("Max retries exceeded");
}

Методи RPC Solana: Що можна запитувати

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

Методи HTTP RPC

getRecentBlockhash застарів. Натомість використовуйте getLatestBlockhash. Заміна також повертає lastValidBlockHeight, що дозволяє надійно обробляти Строковий термін дії транзакцій.

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

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

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

Повний довідник методів, включаючи параметри, типи повернення та коди помилок, див. в API-документація Solana RPC.

Як запустити власний RPC-вузол Solana: Вимоги та огляд налаштування

Самостійне розміщення RPC-вузла Solana надає повний контроль, відсутність обмежень швидкості та максимальну конфіденційність даних. Інвестиції в обладнання сягають тисяч доларів, а підтримка працездатності вузла вимагає спеціалізованих DevOps-ресурсів. Великі протоколи, біржі та команди з наявними інфраструктурними можливостями є цільовою аудиторією цього шляху.

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

Модель облікових записів Solana зберігає весь стан програми в окремих облікових записах. Повноцінний RPC-вузол повинен зберігати поточний стан усіх активних облікових записів у оперативній пам'яті для швидких відповідей на запити, а також історичні дані ledger на NVMe SSD. Зростання сховища на 100-200 ГБ на день в основній мережі (mainnet-beta) означає, що оператори повинні планувати безперервне обертання ledger.

Потрібно сім етапів. Кожен крок посилається на офіційну документацію 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, щоб ініціювати синхронізацію з нещодавнього стану, а не відтворювати з генезису.
6. Запустіть вузол та відстежуйте прогрес синхронізації, використовуючи solana catchup для відстеження відставання вузла від кінчика кластера.
7. Налаштуйте правила брандмауера, щоб відкрити порти 8899 та 8900 лише для авторизованих IP-адрес. Не виставляйте свій RPC-порт публічно без автентифікації.

Синхронізація зі знімка займає 1-3 дні на рекомендованому обладнанні. Синхронізація з генезису займає значно більше часу і не рекомендується.

Фізичні сервери зазвичай коштують від 500 до 1500 доларів на місяць залежно від специфікацій та географії дата-центру. Хмарні еквіваленти коштують дорожче через накладні витрати віртуалізації на робочих навантаженнях з інтенсивним використанням сховища. Зростання сховища на 100-200 ГБ на день змушує вибирати між попереднім виділенням величезних томів або автоматизацією очищення ledger.

Для команд, які оцінюють рішення "збудувати проти купити", порівняйте вартість керованих постачальників у розділі порівняння постачальників перед тим, як замовляти обладнання.

Поширені помилки RPC Solana та як їх виправити

429 Надто багато запитів

Ваш додаток перевищив ліміт запитів на IP-адресу на публічній кінцевій точці Solana. Щоб виправити це:

1. Перейдіть на приватного провайдера. Helius, QuickNode, Alchemy та Triton One пропонують тарифні плани, розраховані на промисловий трафік. Дивіться порівняння приватних RPC-провайдерів Solana.
2. Впровадьте експоненціальну затримку (backoff). При отриманні відповіді 429 повторіть спробу із затримкою, яка подвоюється при кожній наступній спробі. Приклад коду наведено в розділі обробки лімітів запитів.
3. Групуйте читання акаунтів за допомогою getMultipleAccounts. Отримання даних 20 акаунтів за один виклик споживає один запит замість 20.

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

Транзакція, надіслана через sendTransaction, не потрапляє в блокчейн. Можливо, термін дії blockhash закінчився або мережа перевантажена. Щоб виправити це:

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

Помилки ліміту запитів getProgramAccounts

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

Поширені запитання: RPC-вузли Solana

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

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

Яка різниця між RPC-вузлом Solana та вузлом-валідатором?

Вони виконують різні ролі. RPC-вузол надає дані зовнішнім клієнтам через JSON-RPC API, не бере участі в консенсусі та не отримує винагород за стейкінг. Вузл-валідатор голосує за валідність блоків у кожному слоті, потребує застейканих SOL і отримує винагороди в SOL за правильні голоси. Деякі оператори запускають обидва типи вузлів на одному обладнанні, але логічно ці ролі залишаються розділеними.

Чи безкоштовна публічна RPC-кінцева точка Solana?

Так. Публічні кінцеві точки Solana Foundation за адресами api.mainnet-beta.solana.com, api.devnet.solana.com та api.testnet.solana.com є безкоштовними. Вони обмежують кількість запитів приблизно до 100 за 10-секундний інтервал на одну IP-адресу. Ці кінцеві точки достатні для розробки та тестування, але не підходять для промислових dApps, що обслуговують реальних користувачів.

Як уникнути лімітів запитів на публічному RPC Solana?

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

Яке обладнання потрібне для власного RPC-вузла Solana?

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

Скільки часу займає синхронізація RPC-вузла Solana?

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

Яка різниця між HTTP та WebSocket RPC з'єднаннями в Solana?

HTTP RPC використовує модель запит-відповідь без збереження стану. Ваш додаток надсилає один запит і отримує одну відповідь, що підходить для разових запитів, таких як getBalance або sendTransaction. WebSocket RPC використовує постійне з'єднання з моделлю підписки. Ваш додаток підписується на події в Блокчейн і отримує push-сповіщення, коли ці події відбуваються. Використовуйте WebSocket для будь-яких функцій вашого dApp у реальному часі.

Як промисловим dApps оцінювати RPC-провайдера Solana?

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

Пов'язані посібники Solana

• Пояснення поширення блоків Solana Turbine
• Пояснення слотів і часу блоку в Solana (400 мс)

Дослідити SOL на Bybit

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

Вибір правильної RPC-стратегії Solana для вашого випадку

Існує три шляхи, і більшість команд одразу зрозуміють, який із них відповідає їхньому поточному етапу.

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

Наступні кроки:

• Зареєструйтеся на безкоштовному рівні для розробки: helius.dev або quicknode.com
• Ознайомтеся з повним довідником методів Solana JSON-RPC: docs.solana.com/api
• Перевірте апаратні характеристики перед підготовкою до власного хостингу: Як запустити власний RPC-вузол Solana