Руководство по Stake-взвешенному качеству обслуживания в Solana

Что такое Stake-взвешенное качество обслуживания (QoS)?

Stake-взвешенный QoS (Quality-of-Service) — это функция реализации, которая при включении позволяет лидерам (производителям блоков) идентифицировать и приоритизировать транзакции, проксируемые через стейкированный validator, в качестве дополнительного механизма защиты от Sybil-атак. Поскольку Solana является сетью с доказательством доли владения (proof of stake), вполне естественно распространить полезность stake-взвешивания на качество обслуживания транзакций. В рамках этой модели validator с долей 0,5% будет вправе передавать до 0,5% пакетов лидеру и сможет противостоять Sybil-атакам со стороны остальной части сети.

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

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

Кому выгоден Stake-взвешенный QoS?

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

Почему Stake-взвешенный QoS важен?

При включённом Stake-взвешенном QoS validator, удерживающий 1% доли, будет вправе передавать до 1% пакетов лидеру. Таким образом, validator с более высокой долей гарантированно получают более высокое качество обслуживания, что предотвращает злонамеренное «затопление» транзакций со стороны validator низкого качества (с меньшей долей), повышая общую защиту от Sybil-атак.

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

Кто должен включать Stake-взвешенный QoS?

Stake-взвешенный QoS следует включать на узлах validator, объединённых с хорошо проверенными RPC-узлами. Это полезно в таких ситуациях, как совместное размещение RPC и validator на одной инфраструктуре, где уровень доверия уже высок. Stake-взвешенный QoS лучше всего работает в конфигурациях с высоким уровнем доверия и требует предварительного соглашения между validator и RPC до включения функции. Настоятельно рекомендуется не пытаться включать Stake-взвешенный QoS с ненадёжными RPC.

Стейк следует применять к validator, производящим блоки. Делегировать стейк RPC-серверам не является необходимым, рекомендуемым или эффективным решением.

Как работает Stake-взвешенный QoS?

При включённом Stake-взвешенном QoS RPC-узлы, объединённые с validator, получают «виртуальную» долю в отношении того, как этот лидер обрабатывает входящий TPU (Transaction Processing Unit) трафик от данного RPC-узла — то, что в обычных условиях невозможно. По определению, RPC-узлы являются «нестейкированными» и «неголосующими», то есть «неконсенсусными», и не могут получить доступ к преимуществам приоритизации транзакций посредством стейкинга так, как это делают консенсусные узлы. Как использовать Stake-взвешенный QoS для включения транзакций в блоки? Включение Stake-взвешенного QoS требует настройки узла validator и RPC-узла для формирования отношений доверенного пира. Это предполагает отдельные шаги настройки как для узла validator, так и для RPC-узла, перечисленные ниже. Операторам, желающим включить Stake-взвешенный QoS, потребуется следующее перед началом:

validator со стейком, работающий в сети, И RPC-узел, соединённый в пару с validator

Stake-взвешенный QoS не будет работать, если ОБЕ стороны не настроены должным образом.

Настройка узла validator

На validator вам необходимо включить --staked-nodes-overrides /path/to/overrides.yml. Флаг --staked-nodes-overrides помогает validator приоритизировать транзакции, отправляемые из известных источников, применяя стейк к их транзакциям. Это позволяет validator приоритизировать определённые транзакции от известных хостов по сравнению с другими, обеспечивая использование Stake-взвешенного QoS с RPC-узлами. RPC-узлы не должны быть стейкированы никаким образом.

На сегодняшний день Stake-взвешенный QoS предоставляет stake-взвешенный приоритет для 80% TPU-ёмкости лидера. Однако существуют параметры конфигурации, которые можно использовать для виртуального назначения различных stake-весов TPU-пирам, включая назначение виртуального стейка нестейкированным пирам.

Файл переопределений для --staked-nodes-overrides выглядит следующим образом:

staked_map_id:
  pubkey1: 1000000000000000
  pubkey2: 4000000000000000

staked_map_id содержит карту соответствия публичного ключа идентификации (pubkey) и суммы стейка в lamport, применяемой к каждому RPC. При установке validator будет приоритизировать QUIC-соединения с RPC, найденным по данному публичному ключу идентификации, назначая определённое количество стейка их транзакциям. 80% TPU-ёмкости лидера будут распределены пропорционально на основе сумм в lamport, указанных в файле 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 для Stake-взвешенного QoS

Заключение

Stake-взвешенный QoS — это опциональная функция, появившаяся в версии v1.14 клиента Solana, ныне известного как Agave. Agave — это форк клиента Solana Labs, ставший активной ветвью разработки, используемой командой Anza — организацией, образованной бывшей инженерной командой Solana Labs.

Функция Stake-взвешенного QoS, скорее всего, окажется наиболее полезной для операторов RPC-инфраструктуры, которые находятся в позиции для установления доверенных отношений с операторами стейкированных узлов. Она также будет полезна для бирж, которые эксплуатируют как RPC-узлы, так и узлы validator и способны устанавливать соединения с высоким уровнем доверия внутри своей инфраструктуры.