Дизайн першого збору комісій за MOVE: як розрахувати витрати у блокчейні

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

процес

Щоб ефективно виконати, процес у блокчейні є:

1. Визначення принципів
2. Підготувати оцінкову рамку, визначити ціну для кожного виконання
3. Для MOVE створити систему вимірювання плати за паливо та безпечну алгебру плати за паливо
4. Імпортуйте рамки витрат на паливо вверх по течії
5. Зробіть рамки витрат пального свідомими до зберігання
6. Додаткова деталізація плану витрат на паливо

принципи

Визначені принципи:

1. Витрати на операції повинні бути безпосередньо пов'язані з доступними ресурсами мережі (, такими як CPU, пам'ять, мережа, зберігання I/O та використання простору тощо ). Після поліпшення технологій і процесів, витрати на паливо повинні знижуватися.

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. Подібно до циклів ЦП для розрахунку частини плати за паливо, доступ до даних є миттєвим дефіцитом, за який користувачі блокчейну конкурують на ринку зборів під час навантаження системи, крім того, вартість використання диска для запису даних у блокчейні є постійною. Команда розробила план плати за зберігання, враховуючи ці витрати.

Витрати на доступ і зберігання будь-якого елементу стану пов’язані з витратами на структуру даних, що відповідає верифікації всього стану у блокчейні. Ці витрати пов’язані з базою різних елементів стану ($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 закінчиться.