Комиссии Solana в теории и на практике

Введение

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

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

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

Комиссии в теории

Система комиссий Solana состоит из двух компонентов: базовой и приоритетной комиссий. В общих чертах каждый компонент в идеале выполняет следующую функцию:

• Базовые комиссии: право использовать ресурсы сети
• Приоритетные комиссии: определяют порядок в очереди транзакций лидера

Базовая комиссия

Базовая комиссия, которая сейчас составляет 0,000005 SOL (5 000 лампортов) за подпись, служит основой стоимости транзакции. Адрес платит ее за право использовать ресурсы сети. Это единоразовый платеж, который вносится в сеть заранее независимо от фактического объема ресурсов, использованных для выполнения транзакции, и даже от того, будет ли транзакция вообще выполнена. Транзакции Solana заранее запрашивают определенное количество вычислительных единиц (CU). Если этот лимит превышен, транзакция завершается с ошибкой. Поэтому сейчас у разработчиков практически нет финансовых стимулов минимизировать запросы вычислительных единиц.

Приоритетные комиссии

Кроме того, пользователи могут заплатить приоритетную комиссию, чтобы ускорить транзакции и повысить вероятность их включения в блок. Пользователь платит за приоритет, но не получает детерминированной гарантии. Уже ведется работа над повышением детерминированности транзакций. Значительные изменения планировщика ожидаются в версии 1.18.

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

Стимул для валидаторов включать транзакции с приоритетными комиссиями существует вне среды выполнения. Лидеры получают 50% приоритетной комиссии за включение транзакции в свой блок, а остальные 50% сжигаются.

Сегодня большинство валидаторов (более 80%) используют неизмененные версии клиента Solana Labs или Jito-Solana. Это означает, что валидаторы передают «производство блоков» стандартному планировщику. Некоторые участники экосистемы Solana называют «упорядочивание блока» «производством блока», хотя в Ethereum это означает совершенно иное. Некоторые команды изменили код клиента и реализовали более сложный планировщик, который дает больше контроля над порядком транзакций. Благодаря этому некоторые из них могут извлекать MEV, меняя порядок транзакций или проводя сэндвич-атаки.

Недетерминированность приоритетной комиссии

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

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

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

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

Комиссии на практике

Включение транзакций

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

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

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

Приоритетные комиссии

На практике мы видим, что приоритетные комиссии далеки от совершенства, но работают в масштабе всей сети. Транзакции с приоритетными комиссиями чаще включаются в блоки, а повышение приоритетной комиссии увеличивает вероятность включения.

Данные Helius RPC показывают, что транзакции с приоритетными комиссиями чаще попадают в блоки и во всех случаях делают это быстрее:

21 января средние приоритетные комиссии резко выросли из-за аирдропа mockJUP, который проводился в рамках подготовки к настоящему аирдропу JUP на следующей неделе. Несмотря на значительные изменения спроса на пространство блока, реальные пользователи почти не заметили изменений в доле и времени включения транзакций.

Такой UX в основном обеспечивает метод Solana RPC getRecentPrioritizationFees, с помощью которого разработчики могут точно определить приоритетную комиссию для добавления к транзакции. Эндпоинт возвращает список приоритетных комиссий за последние 150 блоков, с которыми была успешно включена хотя бы одна транзакция с соответствующим адресом и входными параметрами. Это дает представление о минимальном необходимом размере приоритетной комиссии, но практическая польза таких данных довольно ограничена. В качестве альтернативы Helius предлагает API приоритетных комиссий, который выполняет дополнительные расчеты и точнее оценивает приоритетную комиссию.

Хотя в теории приоритетные комиссии работают примерно так, как задумано, предстоящие изменения планировщика в версии 1.18 сделают включение транзакций более детерминированным. Это должно сократить объем спама, попадающего ончейн, поскольку доминирующая стратегия больше не будет требовать массовой отправки транзакций для включения в блок.

Базовая комиссия

Базовая комиссия в Solana определенно слишком низкая. Блоки переполняются, а комиссия не изменяется динамически и поэтому не может достичь цены пространства блока, уравновешивающей рынок. В Ethereum динамическая базовая комиссия реализована с помощью механизма управления EIP-1559, который анализирует последние блоки и стремится поддерживать загрузку на уровне 50%.

Solana устанавливает фиксированную цену в 5 000 лампортов за подпись — обычно одна подпись на транзакцию. Такая комиссия неэффективна, поскольку базовая комиссия не отражает изменений спроса на пространство блока и ресурсы валидаторов. В результате роль рыночного механизма фактически переносится на приоритетную комиссию. Это еще сильнее перегружает сеть, поскольку валидаторы обрабатывают дополнительные транзакции, которые, скорее всего, никогда не будут включены. Кроме того, доминирующая стратегия заключается в отправке большого числа транзакций с минимальными приоритетными комиссиями. Это создает значительные негативные внешние эффекты для UX всех участников сети.

Стимулы

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

Кроме того, RPC, которые сейчас считаются валидаторами с нулевым стейком, тоже начнут оцениваться с учетом веса стейка. RPC смогут самостоятельно привлекать стейк без партнерства с валидатором. Приложения нередко запускают собственные валидаторы для усиления вертикальной интеграции. Это дает им дополнительный контроль над пользовательским опытом и цепочкой поставок транзакций и MEV.

Хотя экономические стимулы указывают на тенденцию к централизации стейка, в Solana не произошло масштабной концентрации капитала ради преимуществ, связанных с весом стейка. Причин может быть несколько:

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

Заключение

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

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

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

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