Первый дизайн платы за топливо MOVE: как рассчитывать потребление в блокчейне

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

процесс

Чтобы эффективно выполнить, процессы в блокчейне:

1. Определение принципов
2. Подготовить оценочную рамку, определить цену для каждого исполнения
3. Создание системы измерения топливных сборов и безопасной алгебры топливных сборов для MOVE
4. Импортировать рамки платы за топливо upstream
5. Сделать структуру топливных сборов осознанной к хранению
6. Дальнейшая детализация плана топливных расходов

принцип

Определенные принципы:

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

2. Топливный сбор должен устанавливаться в блокчейне и может быть бесшовно настроен.

3. Топливный сбор может предотвратить DoS-атаки на фиксированные ресурсы сети и может потребоваться быстрое изменение через治理建议 в зависимости от состояния сети.

4. Цена на топливо отражает видение ускоренного роста и поддержания распространенности в блокчейне.

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

Расчет стоимости топлива

При подаче транзакции пользователю необходимо указать два количества:

Максимальное количество топлива: Измеряется в единицах топлива. Это максимальное количество единиц топлива, которое пользователь готов потратить на выполнение транзакции.

Цена на топливо: рассчитывается в восьмеричной системе, 1 восьмеричная = 0.00000001 APT(=$10^{-8}$). Это цена топлива, которую пользователь готов заплатить.

В процессе выполнения сделки будет взиматься:

1. Фиксированные затраты, фиксированная база плюс дополнительные расходы на крупные сделки.
2. Исполнительные затраты, используемые для выполнения команды MOVE.
3. Чтение затрат, используемых для чтения данных из постоянного хранилища.
4. Стоимость записи, используемая для записи данных в постоянное хранилище.

Конечная стоимость транзакции может быть рассчитана как общее количество потребленных единиц топлива, умноженное на цену за единицу топлива. Например, если транзакция потребляет 670 единиц топлива, а указанная пользователем цена за единицу топлива составляет 100 Octa, то конечная стоимость транзакции равна 670 * 100 = 67000 Octa = 0.00067 APT.

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

Создание таблицы планирования топливных сборов

1. Основная конфигурация

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

2. Масштаб сделки

Большинство объемов транзакций может находиться в пределах килобайтов. Однако, публикация модуля MOVE может легко достигать нескольких тысяч байт, а сам фреймворк составляет около 100 КБ. Размеры модулей большинства пользователей обычно находятся в диапазоне от 4 КБ до 40 КБ. Изначально размер транзакции был установлен на уровне 32 КБ, но в ответ на запросы сообщества о предоставлении большего пространства для упрощения разработки приложений, размер транзакции был увеличен до 64 КБ.

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

3. Максимальная единица платы за топливо

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

Максимальный единичный расход топлива в плане расхода топлива напрямую влияет на то, как долго может выполняться транзакция; установка слишком высокого значения может негативно повлиять на производительность в блокчейне. Например, пользователь может забыть добавить инкремент в цикл while, что приведет к бесконечному циклу, что является распространенной ошибкой. Даже при максимальном обновлении фрейма, это все еще меньше, чем максимальная единица расхода топлива плана расхода топлива (, установленная на 90% от 1,000,000).

4. Выполнение

Для оценки затрат на выполнение была построена эталонная структура, и при выполнении этой структуры использовался Valgrind для анализа MOVE VM. Его выводом является набор аннотированных исходных кодов, который сообщает, сколько машинных инструкций было сгенерировано каждой строкой кода.

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

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

5. Хранение

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

Доступ и хранение любого элемента состояния будут порождать затраты, связанные с проверкой структуры данных, относящейся к состоянию всей блокчейн-сети. Эти затраты зависят от базиса различных элементов состояния ($2^{256}$). Также существует затрат, пропорциональный размеру каждого элемента. Для выполнения операции с элементом состояния плата составляет (, за исключением особых случаев, описанных в следующем разделе ):

Хранение топливного сбора = item_fee + (byte_fee * bytes)

читать, создавать и писать

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

Чтение – это самая распространенная операция, которая ограничивается только мгновенной нехваткой ресурсов. Следовательно, стоимость чтения калибруется на основе IOPS диска (, стоимостного проекта ) и пропускной способности, указанной в эталонной аппаратной спецификации.

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

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

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

Учитывая вышесказанное, мы определили 6 параметров топливного сбора, которые составляют общую стоимость топливного сбора. См. ниже:

per_item_read:корректировка в соответствии с IOPs per_byte_read:Калибровка в соответствии с фактической пропускной способностью per_item_create: Калибровка в зависимости от общего целевого проекта per_byte_create: Калибровка в зависимости от общей целевой величины - первый 1KB, содержащийся в каждом элементе. per_item_write: То же, что и per_item_read per_byte_write: То же, что и per_byte_create

Стабильная стоимость единицы топлива

Независимо от того, какова рыночная стоимость выполнения операций в APT или фиатной валюте, каждая операция и сама транзакция требуют фиксированной единицы затрат относительно стоимости хранения и выполнения. Фиксированная единица затрат на топливо помогает сохранить план расходов на топливо неизменным и отвязать его от свободной рыночной стоимости APT. Кроме того, правильный выбор точности десятичных знаков для единицы топлива помогает сохранить план расходов на топливо неизменным. Учитывая это, команда представляет единицу топлива с точностью примерно до 3 знаков. Таким образом, стоимость транзакции перевода составляет примерно 700 единиц топлива.

участие сообщества

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

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

Как скорректировать стоимость топлива?

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

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

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

Будущая работа

Это первая жизнеспособная структура комиссии за топливо для MOVE. Она требует значительных изменений в MOVE VM и Core. Мы надеемся, что эта работа проложит путь для будущих проектов:

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

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

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