Правда о локальных рынках комиссий Solana

Практические выводы

• Локальные рынки комиссий (LFM) позволяют Solana устанавливать детализированные комиссии для отдельных частей состояния в зависимости от уровня конкуренции за них. Транзакции платят комиссии с учетом конкретного состояния, в которое они записывают данные. Благодаря этому локальные точки перегрузки не повышают комиссии во всем блокчейне. 
• LFM необходимы для реализации концепции Solana как масштабируемого единого базового уровня, на котором все приложения беспрепятственно сосуществуют. Без LFM резкий рост комиссий в одной части сети повышает комиссии для всех транзакций. Эта проблема часто встречается в других сетях, которые при определении стоимости пространства блока полагаются исключительно на глобальные рынки комиссий.
• Когда в конце 2023 года экономическая активность в Solana начала расти, проявилось несколько критических недостатков первоначальной реализации LFM. Самым заметным из них была недетерминированная приоритизация планировщика. Транзакции в основном упорядочивались по времени поступления к сборщику блока, а комиссии за приоритет учитывались лишь во вторую очередь.
• В мае 2024 года обновление клиента Agave до версии v1.18 представило новый планировщик транзакций и усовершенствованную формулу расчета приоритета транзакций. Планировщик строит граф зависимостей, чтобы эффективнее управлять обработкой и приоритизацией конфликтующих транзакций в разных потоках. Это крупное обновление значительно улучшило способность протокола детерминированно упорядочивать транзакции.
• Полезный показатель эффективности LFM — сравнение медианной и средней комиссий за приоритет транзакций. Ожидается, что комиссии для состояния без конкуренции (медиана на уровне 50-го процентиля) останутся низкими. Комиссии для состояния с высокой конкуренцией должны резко расти вместе со спросом, повышая среднее значение. Недавние данные подтверждают эту закономерность. В ноябре 2024 года средняя комиссия за транзакции без голосования достигла исторического максимума — более 0,0003 SOL. При этом медианная комиссия оставалась стабильной на уровне 0,00000861 SOL, то есть примерно в 35 раз ниже.
• Сегодня LFM Solana работают, но их еще можно значительно улучшить. Анализ нагрузки потоков банковского этапа, проведенный инженерами Anza, указывает на ошибку планировщика, которая не позволяет клиенту валидатора использовать всю доступную мощность. В результате клиент Agave задействует лишь часть своего потенциала. Кроме того, формальная спецификация порядка транзакций отсутствует.
• Текущим API комиссий за приоритет не хватает возможностей для предоставления разработчикам детерминированных результатов. Каждый крупный поставщик RPC предлагает собственный API комиссий за приоритет, что может стать мягкой формой привязки к поставщику. Базовая реализация RPC API с открытым исходным кодом не учитывает важную динамику сети, включая влияние Jito, поэтому оценки комиссий оказываются неточными.
• Без детерминированного метода расчета комиссий за приоритет разработчики часто перестраховываются и переплачивают, чтобы гарантировать обработку своих транзакций. Другой вариант — чрезмерное использование чаевых Jito как альтернативного механизма даже для транзакций, которым не требуется место в начале блока.
• Для дальнейшего улучшения структуры комиссий Solana предложены различные стратегии. Среди них экспоненциальные комиссии за блокировку записи и динамические базовые комиссии. Сети еще предстоит найти способы применять экономическое противодействие, чтобы сделать спам невыгодным и при этом сохранить низкие комиссии для реальных пользователей.

Введение

Рынки комиссий — это экономические механизмы, предназначенные для эффективного распределения дефицитного пространства блока между наиболее ценными транзакциями за счет динамической корректировки комиссий. Готовность транзакции платить комиссию выступает показателем ее ценности. LFM развивают эту общую концепцию, устанавливая детализированные комиссии для отдельных частей состояния в зависимости от уровня конкуренции за них. Две транзакции считаются конфликтующими, если обращаются к одному состоянию: обе выполняют запись либо одна выполняет чтение, а другая — запись в один аккаунт.

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

Глобальные рынки комиссий, напротив, устанавливают единую стоимость доступа к состоянию сети. Все транзакции на равных конкурируют за включение независимо от аккаунтов, с которыми они взаимодействуют. Модель комиссий Ethereum, реализованная в EIP-1559, — показательный пример глобального рынка комиссий. EIP-1559 корректирует динамическую базовую комиссию с учетом спроса в сети, чтобы поддерживать оптимальное использование вычислительных ресурсов (газа) в каждом блоке. По мере заполнения блока комиссии растут для всех транзакций. Кошельки рассчитывают комиссии на основе текущей базовой комиссии и лимита газа транзакции. Этот подход закреплен на уровне протокола и обеспечивает предсказуемый расчет комиссий, однако не изолирует точки высокого спроса от остальной сети. Если комиссии резко растут, они растут для всех транзакций.

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

В этой статье мы стремимся представить доступный анализ LFM Solana. Работа разделена на следующие разделы:

• Основы комиссий Solana: Дает читателям базовое представление о том, как сегодня обрабатываются транзакции в Solana.
• Ранние проблемы локальных рынков комиссий: Рассматривает первоначальные проблемы и недостатки ранних реализаций LFM.
• Обновление центрального планировщика v1.18: Описывает ключевое обновление 2024 года, которое значительно улучшило работу LFM.
• Оценка эффективности локальных рынков комиссий: Представляет данные, помогающие понять текущее состояние LFM в Solana.
• Текущие проблемы и направления улучшения: В этом разделе рассматриваются нерешенные проблемы и области, требующие внимания, чтобы LFM смогли полностью реализовать свой потенциал.
• Предлагаемые решения: Рассматривает предложенные решения для совершенствования LFM и создания более эффективных экономических стимулов для дифференцированного ценообразования пространства блока.

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

Основы комиссий Solana

Комиссия за транзакцию Solana состоит из двух частей: базовой комиссии и комиссии за приоритет. Сейчас базовая комиссия фиксирована и составляет 5 000 лампортов за подпись. Большинство транзакций Solana имеют одну подпись. Комиссия за приоритет выражается в микролампортах (то есть миллионных долях лампорта) за каждую запрошенную вычислительную единицу (CU). Комиссии списываются с аккаунта плательщика комиссии (подписанта). Если у плательщика недостаточно лампортов для оплаты транзакции, она отклоняется. На момент написания статьи сборщик блока сохраняет 50% базовой комиссии и комиссии за приоритет в качестве стимула включить транзакцию в блок. Остальные 50% сжигаются. После успешного голосования по предложению SIMD-096 в мае прошлого года сборщик блока будет получать 100% комиссий за приоритет. Например: 

Транзакция имеет одну подпись и запрашивает 500 000 CU. Отправитель устанавливает комиссию за приоритет в размере 50 000 микролампортов за каждую запрошенную CU. Общая комиссия за транзакцию составляет 5 000 лампортов + (500 000 запрошенных CU * 50 000 микролампортов за запрошенную CU) = 25 000 лампортов, или 0,000025 SOL.

Вычислительные ресурсы валидаторов ограничены, а протокол ограничивает общий объем вычислительных ресурсов на блок 48 миллионами CU. Это значение определили эмпирически с учетом объема данных, который валидаторы способны обработать за время блока в 400 миллисекунд. Максимальное число CU на аккаунт в одном блоке ограничено 12 миллионами, а максимальный объем вычислений на транзакцию — 1,4 миллиона CU. Размер сообщения транзакции также ограничен 1 232 байтами. Это минимальная единица передачи IPv6 (1280 байт) за вычетом заголовков.

Чтобы предотвратить нецелевое использование вычислительных ресурсов, каждой транзакции в Solana назначается вычислительный бюджет. По умолчанию сеть устанавливает максимальный лимит в 200 000 вычислительных единиц (CU) на инструкцию. Однако транзакции могут задать собственный лимит вычислительных единиц, включив инструкцию `SetComputeUnitLimit`, что позволяет эффективнее распределять ресурсы. В кодовой базе клиента Agave перечислена стоимость различных операций в CU.

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

Ранние проблемы локальных рынков комиссий Solana

Когда в конце 2023 года экономическая активность в Solana начала расти, проявилось несколько критических недостатков первоначальной реализации LFM. Примерно в это время Eugene Chen из Ellipsis Labs представил подробный анализ этих проблем в статье Umbra Research «Комиссии Solana, часть 1». Ниже кратко изложены основные тезисы Chen.

Отсутствие стимулов точно запрашивать CU

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

Стимулы использовать внепротокольные механизмы приоритета

Сжигание 50% комиссий за приоритет стимулирует отправителей транзакций обходить протокол: вступать в сговор со сборщиками блоков и договариваться о внесетевых платежах за приоритетный доступ. Об этом свидетельствует растущее использование аукционов Jito. Валидаторы с клиентом Jito-Agave получают больше комиссий и могут эффективно распределять эту прибыль между делегировавшими им стейкерами через комиссионные вознаграждения Jito MEV. По мере распространения клиентов Jito-Agave пакеты Jito во многих сценариях зарекомендовали себя как более эффективный сервис доставки транзакций. 

Недетерминированная приоритизация планировщика

Ни консенсус Solana, ни планировщик не обеспечивают строгий порядок транзакций на основе комиссий за приоритет. Транзакции в основном упорядочиваются по времени поступления к сборщику блока, а комиссии за приоритет учитываются лишь во вторую очередь. Более высокая комиссия за приоритет может повысить вероятность включения при конкуренции за состояние, но процесс упорядочивания остается недетерминированным. Дополнительную непредсказуемость создают колебания сетевой задержки до достижения блока обработки транзакций (TPU) и внутренние колебания задержки планировщика.

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

Обновление центрального планировщика v1.18

Первоначальная реализация планировщика клиента Agave давала лишь слабую гарантию того, что транзакции с высокой комиссией за приоритет будут иметь больше шансов попасть в конкретный блок. Блок обработки транзакций (TPU) лидера использует шесть параллельных потоков: четыре обрабатывают транзакции без голосования, а два зарезервированы для транзакций голосования. Каждый из четырех потоков транзакций без голосования ведет собственную очередь, где входящие транзакции ожидают группировки в записи для выполнения. Ранее транзакции распределялись между этими потоками случайным образом, а очереди независимо приоритизировали пакеты, не учитывая пакеты, обрабатываемые другими потоками.

В этой системе каждый поток циклически проходит по своей очереди, пытаясь заблокировать и выполнить транзакции. Завершив текущий цикл, поток получает дополнительные пакеты и запускает процесс заново. Такая структура затрудняет эффективное использование комиссий за приоритет. Например, транзакция с высоким приоритетом может находиться в начале очереди одного потока, а другой поток в это же время может обрабатывать транзакцию с более низкой комиссией за приоритет, затрагивающую тот же аккаунт и находящуюся в конце его очереди. Комиссии за приоритет влияли на порядок транзакций только внутри отдельных потоков, но не между всеми потоками. В результате каждая очередь применяла гибридный механизм упорядочивания, сочетавший обработку по принципу «первым пришел — первым обслужен» (FIFO) с учетом комиссии за приоритет. Однако общего порядка между потоками не существовало.

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

В мае 2024 года обновление клиента Agave до версии v1.18 представило новый планировщик транзакций, также известный как центральный планировщик. В обновленной структуре центральный планировщик строит граф зависимостей — prio-graph, чтобы эффективнее управлять обработкой и приоритизацией конфликтующих транзакций во всех потоках. Это крупное обновление значительно улучшило способность Solana детерминированно упорядочивать транзакции: транзакции с более высокой комиссией за приоритет стали чаще попадать в блоки.

Prio-graph — это направленный ациклический граф (DAG), который динамически обновляется при добавлении новых транзакций. Транзакции организуются в графе в цепочки выполнения, обрабатываемые в порядке временного приоритета. Для конфликтующих транзакций порядок вставки определяет комиссия за приоритет. Такой подход сводит к минимуму конкуренцию за блокировки, обеспечивает плавное выполнение пакетов транзакций и сокращает задержки из-за конфликтов ресурсов. Для повышения производительности и эффективности обработки проверка предварительной компиляции транзакций перенесена в рабочие потоки. 

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

Более подробное описание центрального планировщика можно найти в нашей предыдущей статье в блоге Helius об обновлении Agave 1.18.

Более эффективный расчет приоритета

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

Обновленная формула:

Приоритет = (Комиссия за приоритет * Запрошенные вычислительные единицы) + Базовая комиссия / 

(1 + Запрошенные CU выполнения + CU подписей + CU блокировок записи)

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

Оценка эффективности локальных рынков комиссий

В этом разделе мы рассмотрим данные, относящиеся к LFM Solana. 

Медианные и средние комиссии за транзакции

При эффективной работе LFM комиссии за транзакции с состояниями без конкуренции, например за простые переводы стейблкоинов, должны оставаться низкими. В то же время комиссии за транзакции, обращающиеся к состояниям с высокой конкуренцией, например к спекулятивным токенам с низкой ликвидностью, должны резко расти вместе со спросом. Полезный показатель для оценки этой динамики — сравнение медианной и средней комиссий за приоритет транзакций. Медианная комиссия — это комиссия, которую платит пользователь на 50-м процентиле. Она отражает типичные затраты. Средняя комиссия рассчитывается путем деления суммы всех комиссий на общее число транзакций и показывает общие тенденции.

Недавние данные подтверждают ожидаемую закономерность. В ноябре 2024 года экономическая активность в Solana достигла рекордного уровня, а средняя комиссия за транзакции без голосования установила исторический максимум — более 0,0003 SOL. Несмотря на это, медианная комиссия оставалась стабильной на уровне 0,00000861 SOL, то есть примерно в 35 раз ниже. Для сравнения: в апреле 2024 года аналогичный всплеск экономической активности поднял среднюю комиссию выше 0,0002 SOL, а медианная комиссия выросла до 0,00001862 SOL и была примерно в 10 раз ниже. Это расхождение демонстрирует эффективность изоляции комиссий: она защищает обычных пользователей от скачков стоимости в периоды высокого спроса и сохраняет удобство использования для сценариев, не связанных со спекуляциями.

При анализе аналогичных данных сети на базе EVM, например управляемой Coinbase сети Ethereum L2 Base без LFM, наблюдается сильная корреляция между медианной и средней комиссиями за транзакции. При росте спроса глобальные базовые комиссии повышаются, поэтому средняя и медианная комиссии меняются почти синхронно. Кроме того, разница между ними заметно меньше. Например, 5 декабря 2024 года средняя комиссия за транзакцию в Base резко выросла до $0,1115, а медианная — до $0,0228, то есть была примерно в пять раз ниже.

Доля отмененных транзакций

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

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

Доля отмененных транзакций достигла пика в апреле 2024 года и составила 75,7% всех транзакций без голосования. После развертывания ключевых обновлений, включая центральный планировщик Agave 1.18, этот показатель значительно снизился.

Когортный анализ Blockworks Research за последние семь дней (6–13 января 2024 года) показывает, что доля отмен зависит от уровня активности. У адресов, выполняющих 1–5 транзакций в день (преимущественно розничные пользователи), доля отмен составляет 1,4%. Для адресов с 6–50 транзакциями в день она возрастает до 4,6%. У адресов, выполняющих более 10 000 транзакций в день, доля отмен достигает 66,7%. Более того, адреса с высокой активностью, выполняющие свыше 100 000 транзакций в день (боты), отвечают за 95,2% всех отмененных транзакций. В декабре 2024 года общая доля отмен среди всех транзакций без голосования составляла 41,2%. Это указывает на то, что значительная часть вычислительных ресурсов сети расходуется на обработку неудачных арбитражных сделок.

Текущие проблемы и направления улучшения

Несмотря на значительный прогресс, планировщик клиента валидатора Agave по-прежнему сталкивается с проблемами. Следующий анализ нагрузки потоков банковского этапа, проведенный инженером Anza Alessandro Decina, демонстрирует существующие недостатки и направления для улучшения.

Поток планировщика: Это наиболее важный поток для создания блоков. Планировщик принимает все входящие транзакции, затем сортирует и планирует их выполнение. 

Потоки транзакций голосования: Два выделенных потока обрабатывают транзакции голосования отдельно от пользовательских транзакций.

Потоки транзакций без голосования: Четыре потока получают транзакции в соответствии с расписанием планировщика и обрабатывают пользовательские транзакции.

Потоки приема QUIC: Потоки Tokio управляют приемом транзакций по протоколу QUIC, когда валидатор является лидером. Во время перегрузки в начале 2024 года эти потоки были существенным узким местом.

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

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

Наблюдаемость

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

Helius предлагает RPC-метод `getPriorityFeeEstimate`, который рекомендует комиссии на основе исторических данных как глобального рынка, так и LFM. Разработчики могут передать сериализованную подписанную транзакцию либо список ключей аккаунтов, участвующих в транзакции. Метод поддерживает настраиваемые уровни комиссии за приоритет, разделенные на шесть процентилей: минимальный, низкий, средний, высокий, очень высокий и небезопасный максимальный. По умолчанию рекомендуется средний уровень (50-й процентиль). Комиссии рассчитываются на основе данных из 50 последних слотов.

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 encoded serialized transaction
     "options": {
       "recommended": true
     }
   }
 ]
}

Выше: пример полезной нагрузки для getPriorityFeeEstimate с сериализованной транзакцией в кодировке base58.

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

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

Предлагаемые решения

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

Экспоненциальные комиссии за блокировку записи

SIMD-0110, предложенный в январе 2023 года Tao Zhu (Anza) и Anatoly Yakavenko, представляет новый механизм управления перегрузкой через динамические комиссии для аккаунтов с высокой конкуренцией. Механизм отслеживает экспоненциальное скользящее среднее (EMA) использования вычислительных единиц (CU) для аккаунтов с блокировкой записи и повышает стоимость блокировки записи для аккаунтов, которые стабильно демонстрируют высокую загрузку.

Для реализации такой системы среда выполнения Solana поддерживает LRU-кеш (Least Recently Used) публичных ключей аккаунтов с высокой конкуренцией и соответствующих им модулей расчета стоимости вычислительных единиц (CUP). CUP отслеживают EMA использования CU аккаунта и по запросу предоставляют обновленную ставку стоимости.

Механизм динамически корректирует комиссии за блокировку записи. Если EMA использования CU аккаунта превышает целевой порог, ставка блокировки записи повышается. И наоборот, если использование опускается ниже целевого значения, ставка снижается. Начальные параметры включают:

• Целевой уровень использования — 25% от максимального лимита CU аккаунта.
• Начальная ставка блокировки записи — 1 000 микролампортов за CU.
• Темп корректировки стоимости — 1% на блок.

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

После публикации SIMD-0110 вызвал оживленные дискуссии в сообществе. Однако сейчас предложение неактивно и имеет статус закрытого.

Динамические базовые комиссии

Еще одним долгосрочным решением для улучшения LFM Solana может стать внедрение глобальных и индивидуальных для каждого аккаунта динамических базовых комиссий (DBF). Известными сторонниками этого подхода являются Jarry Xiao и Eugene Chen из Ellipsis Labs.

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

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

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

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

Пример похожей формы экономического противодействия — программа Metaplex Candy Machine, которая в 2022 году ввела налог на ботов для борьбы со спамом. Налог на ботов — необязательная плата за недействительные транзакции. Обычно это сравнительно небольшая сумма, чтобы не затрагивать реальных пользователей, допустивших добросовестную ошибку. Налог оказался эффективным: средства снайперов минта быстро иссякли, и спам прекратился.

Заключение

LFM Solana работают, но их еще можно значительно улучшить:

• Улучшение механизмов комиссий за приоритет: RPC-вызовы комиссий за приоритет требуют улучшения. В идеале разработчикам нужен простой и детерминированный способ устанавливать комиссии, гарантирующий включение транзакции в один из нескольких следующих блоков.
• Экономическое противодействие спаму: Сеть должна найти способы экономически противодействовать ботам в периоды высокой экономической активности, сохраняя при этом низкие комиссии для реальных пользователей.
• Обучение разработчиков: Разработчикам следует отказаться от статических комиссий за транзакции в приложениях и реже использовать внепротокольные механизмы вроде Jito для обычных транзакций.
• Дальнейшая оптимизация планировщика: Планировщик транзакций необходимо дополнительно оптимизировать, чтобы в периоды высокого спроса использовались все рабочие потоки.

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

Дополнительные материалы

• Комиссии Solana, часть 1 - Umbra Research
• К многомерным комиссиям Solana - Umbra Research
• Локальные рынки комиссий необходимы для масштабирования Ethereum - Eclipse Labs
• Локальные рынки комиссий Solana нереальны | Eugene Chen - Lightspeed Podcast
• Банковский этап и планировщик Solana - A.Fitzgerald