Комплексные вычислительные сборы

Мотивация

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

Предложенное решение

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

Платеж

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

Плата будет рассчитываться исходя из:

1. Количество подписей
   • Фиксированная ставка за подпись
2. Количество блокировок записи
   • Фиксированная ставка за перезаписываемую учетную запись
3. Стоимость байта данных
   • Фиксированная скорость за байт суммы длин всех данных инструкций по транзакциям
4. Размеры аккаунта
   • Размеры счетов не могут быть известны заранее, но могут составлять значительную часть нагрузки, которую транзакция несет в сети. С плательщика будет взиматься плата за максимальный размер счета (10 млн) авансом, а разница будет возмещена после того, как станут известны фактические размеры счета.
5. Рассчитать бюджет
   • Каждой транзакции будет предоставлен бюджет вычислений по умолчанию для всей транзакции в размере 200 000 единиц с возможностью запроса большего бюджета с помощью инструкции по бюджету вычислений, но не более 1 млн единиц. Этот бюджет используется для ограничения времени, необходимого для обработки транзакции. Часть платы за бюджет вычислений будет взиматься авансом на основе суммы по умолчанию или запрошенной суммы. После обработки будет известно фактическое количество потребленных единиц, а плательщику будет возвращена разница, поэтому плательщик платит только за то, что использовал. Встроенные программы будут иметь фиксированную стоимость, в то время как стоимость программы BPF будет измеряться во время выполнения.
6. Предварительно скомпилированные программы
   • Предварительно скомпилированные программы выполняют ресурсоемкие операции. Работа, выполняемая предварительно скомпилированной программой, предсказуема на основе массива данных инструкции. Следовательно, стоимость будет назначена для каждой предварительно скомпилированной программы на основе анализа данных инструкции. Поскольку предварительно скомпилированные программы обрабатываются вне банка, стоимость их вычислений не будет отражаться в бюджете вычислений и не будет использоваться при принятии решений о планировании транзакций. Методы, используемые для определения фиксированной стоимости вышеуказанных компонентов, описаны в #19627.

Модель затрат

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

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

Кэшировать размеры учетных записей и использовать их вместо максимальных

https://github.com/solana-labs/solana/issues/20511

Ограничения вычислительных ресурсов для всей транзакции

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

Запрашиваемые ограничения бюджета вычислений и размеры кучи

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

Плата за сбои предварительно скомпилированной программы

https://github.com/solana-labs/solana/issues/20481

Регулирование ставок

Текущее регулирование ставок нуждается в переоценке. Плата регулируется до минимума, потому что количество подписей в каждом слоте намного меньше, чем «целевые» подписи на слот.

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

Детерминированные сборы

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

Детерминизм достигается двумя способами:

• очередь хэшей блоков содержит список последних (<=~2 минут) хэшей блоков и значение lamports_per_signature. Очередь хэшей блоков является одним из сериализованных членов моментального снимка, и поэтому хэш банка зависит от него.
• Учетные записи Nonce, используемые для автономной подписи, содержат значение lampports_per_signature в данных своей учетной записи.

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

В настоящее время это сопряжено со следующими проблемами:

• Предоставление клиентам объекта FeeCalculator (содержит lampports_per_signature) затрудняет разработку критериев оплаты из-за обратной совместимости. Эта проблема решается путем отказа от объекта FeeCalculator, и вместо этого новый API принимает сообщение и возвращает комиссию.
• Записи очереди Blockhash содержат специфику критериев комиссии и являются частью банковского хэша, поэтому изменение комиссий с течением времени требует больше работы / риска.
• Учетные записи одноразового использования хранят критерии комиссии непосредственно в данных своей учетной записи, поэтому изменение сборов с течением времени требует внесения изменений в данные учетной записи одноразового использования и размер данных.

Два решения последних двух проблем

• Избавьтесь от концепции детерминированных комиссий. Клиенты просят через RPC рассчитать текущую оценку комиссии, и фактическая комиссия оценивается при обработке транзакции. Изменения комиссий будут регулироваться и изменяться медленно в зависимости от нагрузки на сеть, поэтому разница в комиссиях будет небольшой в течение 2-минутного окна. Учетные записи Nonce больше не хранят критерии комиссий, а вместо этого сохраняют предельную комиссию. Если оцененная комиссия во время обработки превышает предел, транзакция не выполняется. Это решение полностью удаляет критерии оплаты из очереди хэшей и учетных записей одноразовых номеров, а также устраняет необходимость в развитии любого из них, если есть необходимость в изменении критериев оплаты.
• Сохранить концепцию детерминированных комиссий. Клиенты просят через RPC рассчитать текущую комиссию и передать блок-хеш, с которым будет связана эта комиссия. Очередь Blockhash и учетные записи nonce переключаются на версионный, но внутренний объект «Fee» (аналогичный «FeeCalculator»). Каждый раз, когда возникает необходимость в сборах для развития, объект сбора будет добавлять новую версию и новые записи очереди хэшей, а новые учетные записи nonce будут использовать новую версию.