Посібник із якості обслуговування з урахуванням стейку на Solana

Що таке якість обслуговування з урахуванням стейку (QoS)?

QoS з урахуванням стейку (Quality-of-Service) — це функція реалізації, яка за умови увімкнення дозволяє лідерам (виробникам блоків) ідентифікувати та пріоритизувати транзакції, що проксуються через стейкований validator, як додатковий механізм захисту від сибіл-атак. Оскільки Solana є мережею з підтвердженням частки, природно розширити корисність зважування за стейком на якість обслуговування транзакцій. За цією моделлю validator із часткою 0,5% матиме право передавати до 0,5% пакетів лідеру та зможе протистояти сибіл-атакам з боку решти мережі.

Оператори, які увімкнуть цю функцію, підвищать безпеку та продуктивність мережі, зменшивши ймовірність того, що validator з низьким або нульовим стейком (нижчої якості) зможуть "заглушити" транзакції, що надходять від validator вищої якості (з вищим стейком) (тобто посилений захист від сибіл-атак).

Одна з потенційних переваг впровадження QoS з урахуванням стейку може бути реалізована за наявності певних угод між Validators та RPC-вузлами. RPC-вузли можуть розміщувати більше транзакцій у блоках, погодившись на пірингування з Validators, а Validators можуть продавати більше пропускної здатності RPC-вузлам. Ці угоди мають укладатися безпосередньо між операторами RPC та Validators і включати виконання кроків, описаних нижче в цьому документі, для завершення пірингування.

Кому вигідний QoS з урахуванням стейку?

Комерційні оператори RPC-інфраструктури та біржі, швидше за все, стануть одними з основних бенефіціарів QoS з урахуванням стейку. Оператори RPC опиняться в ідеальному становищі для придбання або укладання угод зі стейкованими validators, що дозволить їм досягти кращого відсотка транзакцій, розміщених у блоках загалом. Біржі (або інші суб'єкти), які розміщують власні вузли validator та RPC-вузли на одній інфраструктурі, зможуть увімкнути цю функцію внутрішньо, будучи впевненими, що RPC-вузлам, які працюють на їхній власній інфраструктурі, можна довіряти.

Чому QoS з урахуванням стейку важливий?

За умови увімкнення QoS з урахуванням стейку, validator із часткою 1% матиме право передавати до 1% пакетів лідеру. Таким чином, validators з вищим стейком гарантовано отримують вищу якість обслуговування, що запобігає зловмисному переповненню транзакцій validator нижчої якості (з меншим стейком), підвищуючи загальний захист від сибіл-атак.

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

Хто повинен увімкнути QoS з урахуванням стейку?

QoS з урахуванням стейку слід увімкнути на вузлах validator у парі з надійними RPC-вузлами. Це корисно в ситуаціях, коли RPC та validator працюють на одній інфраструктурі, де рівень довіри вже є високим. QoS з урахуванням стейку найкраще працює в конфігураціях з високим рівнем довіри та вимагає, щоб validator та RPC заздалегідь дійшли згоди перед увімкненням функції. Настійно рекомендується, щоб Validators не намагалися увімкнути QoS з урахуванням стейку з ненадійними RPC.

Стейк слід застосовувати до validators, що виробляють блоки. Делегування стейку RPC-серверам не є необхідним, рекомендованим або ефективним.

Як працює QoS з урахуванням стейку?

За умови увімкнення QoS з урахуванням стейку, RPC-вузли, що утворюють пару з validator, отримують "віртуальний" стейк щодо того, як цей лідер обробляє вхідний TPU (Transaction Processing Unit) трафік від цього RPC-вузла — те, що в звичайних умовах неможливо. За визначенням, RPC-вузли є "нестейкованими" і "не голосуючими", тобто "не консенсусними", і не можуть отримати доступ до переваг пріоритетних транзакцій шляхом стейкування так само, як це роблять консенсусні вузли. Як використовувати QoS з урахуванням стейку для розміщення транзакцій? Увімкнення QoS з урахуванням стейку вимагає налаштування вузла validator та RPC-вузла для формування відносин довіреного пірингу. Це передбачає окремі кроки налаштування як для вузла validator, так і для RPC-вузла, наведені нижче. Операторам, що бажають увімкнути QoS з урахуванням стейку, перед початком знадобиться наступне:

validator зі стейком, що працює в мережі, ТА RPC, що утворює пір із validator

QoS з урахуванням стейку не працюватиме, якщо ОБИДВІ сторони не налаштовані належним чином.

Налаштування вузла Validator

На validator вам потрібно буде увімкнути --staked-nodes-overrides /path/to/overrides.yml. Прапор --staked-nodes-overrides допомагає validator пріоритизувати транзакції, що надсилаються з відомих джерел, для застосування стейку до їхніх транзакцій. Це може допомогти validator пріоритизувати певні транзакції від відомих хостів над іншими, вмикаючи використання QoS з урахуванням стейку з RPC. RPC не повинні бути стейковані будь-яким чином.

Наразі QoS з урахуванням стейку надає пріоритет з урахуванням стейку для 80% TPU-ємності лідера. Однак існують параметри конфігурації, які можна використовувати для віртуального призначення різних вагових коефіцієнтів стейку TPU-пірам, включаючи призначення нестейкованим пірам віртуального стейку.

Файл перевизначень для --staked-nodes-overrides виглядає так:

staked_map_id:
  pubkey1: 1000000000000000
  pubkey2: 4000000000000000

staked_map_id містить відображення ідентифікаційного pubkey на суму стейку в lamports, що застосовується до кожного RPC. Після встановлення validator пріоритизуватиме QUIC-з'єднання з RPC, знайденим за цим ідентифікаційним publicKey, призначаючи певну суму стейку їхнім транзакціям. 80% TPU-ємності лідера буде розподілено пропорційно на основі сум у lamports, зазначених у файлі staked-nodes-overrides, та існуючого стейку кластера.

Налаштування RPC-вузла

На RPC вам потрібно буде використовувати --rpc-send-transaction-tpu-peer для пересилання транзакцій до конкретного лідера. Точне використання: --rpc-send-transaction-tpu-peer HOST:PORT. Host — це IP-адреса лідера, на якому увімкнено staked-nodes-overrides, а Port — це QUIC TPU-порт цього хоста. QUIC TPU-порт лідера можна визначити, здійснивши RPC-виклик до getClusterNodes.

Пірингування виглядатиме наступним чином:

Діаграма пірингування RPC з Validator для QoS з урахуванням стейку

Висновок

QoS з урахуванням стейку — це опціональна функція, що з'явилася у версії v1.14 клієнта Solana, нині відомого як Agave. Agave — це форкована версія клієнта Solana Labs, яка стала активною гілкою, що використовується командою Anza — організацією, що виникла зі складу колишньої інженерної команди Solana Labs.

Функція QoS з урахуванням стейку, найімовірніше, буде корисною для операторів RPC-інфраструктури, які мають можливість встановлювати довірені відносини з операторами стейкованих вузлів. Вона також буде корисною для бірж, які керують як RPC-вузлами, так і вузлами validator та здатні встановлювати з'єднання з високим рівнем довіри всередині своєї інфраструктури.