Дизайн першої плати за паливо для MOVE: як розраховується плата за паливо у блокчейні?
Вимірювання комісії за паливо є основною концепцією багатьох блокчейнів, вона визначає абстрактний обсяг обчислювальних і сховищних ресурсів, необхідних для виконання та зберігання транзакцій у блокчейні. Плани комісій за паливо визначають витрати, що понесені під час всіх виконань у блокчейні, для обчислення витрат на комісію за паливо, що використовуються під час виконання транзакцій.
процес
Для ефективного виконання, процес у блокчейні є:
визначення принципів;
підготовка оцінювальної рамки для визначення ціни кожного виконання;
для MOVE створити систему вимірювання плати за паливо та безпечну алгебру плати за паливо;
імпортувати рамки плати за паливо вгору;
надає рамці витрат на паливо свідомість зберігання;
Додатково уточнити план витрат на паливо.
принципи
Визначеними принципами є:
Вартість операцій повинна бути безпосередньо пов'язана з доступними ресурсами в мережі (, такими як CPU, пам'ять, мережа, зберігання I/O та використання простору тощо ). Коли технології та процеси покращуються, витрати на паливо повинні знижуватися.
Витрати на паливо повинні встановлюватися у блокчейні та можуть безперешкодно налаштовуватися.
Плата за паливо може запобігти DoS-атакам на фіксовані ресурси в мережі, можливо, знадобиться швидко коригувати відповідно до стану мережі через пропозиції з управління.
Ціна на паливо відображає прагнення до прискореного зростання та забезпечення доступності блокчейну для всіх.
Заохочення робити хороші вибори в дизайні - наприклад, пріоритет безпеки, модульність, асерти та інші події.
обчислення вартості пального
Коли користувачі подають транзакцію, вони також повинні вказати дві кількості в угоді:
Максимальна кількість комісії за паливо: вимірюється в одиницях комісії за паливо. Це максимальна кількість одиниць комісії за паливо, яку користувач готовий витратити на виконання транзакції.
Ціна на паливо: розраховується в восьмиричній системі, де 1 восьмиричний = 0.00000001 APT(=$10^{-8}$). Це ціна, яку користувач готовий сплатити за паливо.
У процесі виконання, з交易 буде стягнуто:
фіксовані витрати, фіксована база плюс додаткові витрати на великі транзакції.
витрати на виконання, використовуються для виконання MOVE команди.
Читання витрат, що використовується для читання даних з постійного зберігання.
витрати на запис, призначені для зберігання даних у постійному сховищі.
Кінцеві комісійні збори за транзакцію можна розрахувати, помноживши загальну кількість витрачених одиниць пального ( на ціну одиниці пального. Наприклад, якщо транзакція спожила 670 одиниць пального, а користувач вказав ціну одиниці пального 100 Octa, то кінцеві комісійні збори за транзакцію становитимуть 670 * 100 = 67000 Octa = 0.00067 APT.
Якщо під час виконання транзакції закінчаться витрати на паливо, то відправник буде стягувати плату відповідно до максимального обсягу витрат на паливо, і всі зміни, зроблені цією транзакцією, будуть скасовані.
) створити таблицю плану витрат на паливо
1. Основні налаштування
План збору пального має кілька складових, які не пов'язані з деталями окремої операції, включаючи розмір транзакції та максимальну одиницю збору пального ###, що відрізняється від максимальної кількості збору пального, зазначеної користувачем у транзакції (.
2. Обсяг угод
Для більшості транзакцій розмір транзакції може бути на рівні тисячі байтів. Однак, вихід модуля Move може легко становити кілька тисяч байтів, тоді як сам каркас має приблизно 100 КБ. Розмір більшості користувацьких модулів зазвичай коливається від 4КБ до 40КБ. Спочатку ми встановили значення розміру транзакції на 32КБ, але, враховуючи реакцію спільноти, яка вимагала більше місця для спрощення розробки додатків, ми відкоригували розмір транзакції на 64КБ.
Дуже великі обсяги угод можуть призвести до збільшення вартості пропускної здатності всієї мережі і можуть негативно вплинути на продуктивність. Якщо це буде зловживатися, пул пам'яті може бути заохочений ігнорувати угоди більшого обсягу, тому наш підхід полягає в досягненні балансу між максимальним обсягом угод і їх доступністю.
3. Максимальна одиниця плати за паливо
Максимальна одиниця плати за паливо в плані плати за паливо визначає, скільки операцій може виконати транзакція. Зверніть увагу! Це відрізняється від максимальної кількості плати за паливо, зазначеної користувачем у транзакції.
Максимальна одиниця плати за паливо в плані плати за паливо безпосередньо впливає на те, як довго може виконуватись транзакція; її занадто високе встановлення може призвести до негативного впливу на продуктивність у блокчейні. Наприклад, користувач може забути про інкремент у циклі while, що призводить до безкінечного циклу, що є поширеною помилкою. Ми виявили, навіть після того, як ми провели найбільше оновлення фреймворку, ми все ще не досягаємо максимального значення плати за паливо в плані плати за паливо ), встановленого на 1,000,000(, на 90%.
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### скажіть про свої занепокоєння щодо плану витрат на паливо та долучайтеся до обговорення в спільноті.
проголосувати за пропозицію з управління, пов'язаною з витратами на паливо.
) Як налаштувати витрати на паливо?
План витрат пального зберігається як конфігурація у блокчейні, але може бути змінений через пропозиції щодо управління, і нові інструкції або рідні функції можуть бути безперешкодно додані.
План витрат на паливо було розроблено як масштабований, що дозволяє оновлювати його через пропозиції з управління. Завдяки постійному вдосконаленню Move VM і врахуванню відгуків користувачів, параметри витрат на паливо можуть коригуватися з часом.
Інколи формула витрат пального може вимагати складних змін, які виходять за межі конфігурації у блокчейні. Ці формули витрат пального зазвичай кодуються на Rust і відрізняються за допомогою позначок характеристик витрат пального у блокчейні. Щоб оновити ці формули, необхідно оновити програмне забезпечення вузлів з новою формулою та відрізняти їх за допомогою різних позначок характеристик витрат пального. Потім програмне забезпечення вузлів має бути випущене та широко впроваджене операторами вузлів, і, нарешті, необхідно опублікувати та затвердити пропозицію щодо управління, щоб використовувати нову версію витрат пального.
) Майбутня робота
Це перша працездатна структура витрат на паливо для MOVE. Це вимагатиме значних змін у Move VM та Core. Ми сподіваємося, що ця робота прокладе шлях для майбутніх зусиль:
1### Зниження витрат на виконання, наявність реальної моделі витрат на паливо показує, де компілятор і віртуальна машина є ефективними, команда може поліпшити більшість з них для зниження витрат на виконання.
2### Розрахунок багатовимірних витрат пального, дозволяє користувачам визначати окремий бюджет для виконання та зберігання. Таким чином, користувачі не повинні платити високі ціни за витрати на пальне через тривалі часи виконання погано написаних додатків. Це також дозволить більш детально визначати максимальні ціни на витрати пального для транзакцій у блокчейні;
3) полегшення об'ємного стану, наразі немає простих способів зменшити набір станів, окрім контракту ) або користувача ), який явно видаляє об'єкти. Користувачі, які платять за видалення даних, можуть отримати можливості для арбітражу, створюючи зберігання в дешевий час та видаляючи його в дорогий. Відкладання вирішення цього завдання може зменшити мотивацію розробників для видалення даних у блокчейні. Команда досліджує концепцію TTL для кожного проекту, яка дозволить видаляти невикористані елементи стану після закінчення терміну дії TTL.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
4 лайків
Нагородити
4
4
Репост
Поділіться
Прокоментувати
0/400
ImpermanentLossEnjoyer
· 8год тому
Хто витримає цю дорогу вартість пального?
Переглянути оригіналвідповісти на0
rekt_but_resilient
· 8год тому
Собаки знають, що газ для move дорогою до непристойності.
Переглянути оригіналвідповісти на0
0xSleepDeprived
· 8год тому
move також почне знімати гроші, важко витримати
Переглянути оригіналвідповісти на0
EthSandwichHero
· 8год тому
Тільки ці витрати на пальне? криптосвіт новачок розкривається
MOVE мова рекомендує механізм плати за пальне: як точно розрахувати витрати на виконання у блокчейні
Дизайн першої плати за паливо для MOVE: як розраховується плата за паливо у блокчейні?
Вимірювання комісії за паливо є основною концепцією багатьох блокчейнів, вона визначає абстрактний обсяг обчислювальних і сховищних ресурсів, необхідних для виконання та зберігання транзакцій у блокчейні. Плани комісій за паливо визначають витрати, що понесені під час всіх виконань у блокчейні, для обчислення витрат на комісію за паливо, що використовуються під час виконання транзакцій.
процес
Для ефективного виконання, процес у блокчейні є:
визначення принципів;
підготовка оцінювальної рамки для визначення ціни кожного виконання;
для MOVE створити систему вимірювання плати за паливо та безпечну алгебру плати за паливо;
імпортувати рамки плати за паливо вгору;
надає рамці витрат на паливо свідомість зберігання;
Додатково уточнити план витрат на паливо.
принципи
Визначеними принципами є:
Вартість операцій повинна бути безпосередньо пов'язана з доступними ресурсами в мережі (, такими як CPU, пам'ять, мережа, зберігання I/O та використання простору тощо ). Коли технології та процеси покращуються, витрати на паливо повинні знижуватися.
Витрати на паливо повинні встановлюватися у блокчейні та можуть безперешкодно налаштовуватися.
Плата за паливо може запобігти DoS-атакам на фіксовані ресурси в мережі, можливо, знадобиться швидко коригувати відповідно до стану мережі через пропозиції з управління.
Ціна на паливо відображає прагнення до прискореного зростання та забезпечення доступності блокчейну для всіх.
Заохочення робити хороші вибори в дизайні - наприклад, пріоритет безпеки, модульність, асерти та інші події.
обчислення вартості пального
Коли користувачі подають транзакцію, вони також повинні вказати дві кількості в угоді:
Максимальна кількість комісії за паливо: вимірюється в одиницях комісії за паливо. Це максимальна кількість одиниць комісії за паливо, яку користувач готовий витратити на виконання транзакції.
Ціна на паливо: розраховується в восьмиричній системі, де 1 восьмиричний = 0.00000001 APT(=$10^{-8}$). Це ціна, яку користувач готовий сплатити за паливо.
У процесі виконання, з交易 буде стягнуто:
фіксовані витрати, фіксована база плюс додаткові витрати на великі транзакції.
витрати на виконання, використовуються для виконання MOVE команди.
Читання витрат, що використовується для читання даних з постійного зберігання.
витрати на запис, призначені для зберігання даних у постійному сховищі.
Кінцеві комісійні збори за транзакцію можна розрахувати, помноживши загальну кількість витрачених одиниць пального ( на ціну одиниці пального. Наприклад, якщо транзакція спожила 670 одиниць пального, а користувач вказав ціну одиниці пального 100 Octa, то кінцеві комісійні збори за транзакцію становитимуть 670 * 100 = 67000 Octa = 0.00067 APT.
Якщо під час виконання транзакції закінчаться витрати на паливо, то відправник буде стягувати плату відповідно до максимального обсягу витрат на паливо, і всі зміни, зроблені цією транзакцією, будуть скасовані.
) створити таблицю плану витрат на паливо
1. Основні налаштування
План збору пального має кілька складових, які не пов'язані з деталями окремої операції, включаючи розмір транзакції та максимальну одиницю збору пального ###, що відрізняється від максимальної кількості збору пального, зазначеної користувачем у транзакції (.
2. Обсяг угод
Для більшості транзакцій розмір транзакції може бути на рівні тисячі байтів. Однак, вихід модуля Move може легко становити кілька тисяч байтів, тоді як сам каркас має приблизно 100 КБ. Розмір більшості користувацьких модулів зазвичай коливається від 4КБ до 40КБ. Спочатку ми встановили значення розміру транзакції на 32КБ, але, враховуючи реакцію спільноти, яка вимагала більше місця для спрощення розробки додатків, ми відкоригували розмір транзакції на 64КБ.
Дуже великі обсяги угод можуть призвести до збільшення вартості пропускної здатності всієї мережі і можуть негативно вплинути на продуктивність. Якщо це буде зловживатися, пул пам'яті може бути заохочений ігнорувати угоди більшого обсягу, тому наш підхід полягає в досягненні балансу між максимальним обсягом угод і їх доступністю.
3. Максимальна одиниця плати за паливо
Максимальна одиниця плати за паливо в плані плати за паливо визначає, скільки операцій може виконати транзакція. Зверніть увагу! Це відрізняється від максимальної кількості плати за паливо, зазначеної користувачем у транзакції.
Максимальна одиниця плати за паливо в плані плати за паливо безпосередньо впливає на те, як довго може виконуватись транзакція; її занадто високе встановлення може призвести до негативного впливу на продуктивність у блокчейні. Наприклад, користувач може забути про інкремент у циклі while, що призводить до безкінечного циклу, що є поширеною помилкою. Ми виявили, навіть після того, як ми провели найбільше оновлення фреймворку, ми все ще не досягаємо максимального значення плати за паливо в плані плати за паливо ), встановленого на 1,000,000(, на 90%.
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### скажіть про свої занепокоєння щодо плану витрат на паливо та долучайтеся до обговорення в спільноті.
) Як налаштувати витрати на паливо?
План витрат пального зберігається як конфігурація у блокчейні, але може бути змінений через пропозиції щодо управління, і нові інструкції або рідні функції можуть бути безперешкодно додані.
План витрат на паливо було розроблено як масштабований, що дозволяє оновлювати його через пропозиції з управління. Завдяки постійному вдосконаленню Move VM і врахуванню відгуків користувачів, параметри витрат на паливо можуть коригуватися з часом.
Інколи формула витрат пального може вимагати складних змін, які виходять за межі конфігурації у блокчейні. Ці формули витрат пального зазвичай кодуються на Rust і відрізняються за допомогою позначок характеристик витрат пального у блокчейні. Щоб оновити ці формули, необхідно оновити програмне забезпечення вузлів з новою формулою та відрізняти їх за допомогою різних позначок характеристик витрат пального. Потім програмне забезпечення вузлів має бути випущене та широко впроваджене операторами вузлів, і, нарешті, необхідно опублікувати та затвердити пропозицію щодо управління, щоб використовувати нову версію витрат пального.
) Майбутня робота
Це перша працездатна структура витрат на паливо для MOVE. Це вимагатиме значних змін у Move VM та Core. Ми сподіваємося, що ця робота прокладе шлях для майбутніх зусиль:
1### Зниження витрат на виконання, наявність реальної моделі витрат на паливо показує, де компілятор і віртуальна машина є ефективними, команда може поліпшити більшість з них для зниження витрат на виконання.
2### Розрахунок багатовимірних витрат пального, дозволяє користувачам визначати окремий бюджет для виконання та зберігання. Таким чином, користувачі не повинні платити високі ціни за витрати на пальне через тривалі часи виконання погано написаних додатків. Це також дозволить більш детально визначати максимальні ціни на витрати пального для транзакцій у блокчейні;
3) полегшення об'ємного стану, наразі немає простих способів зменшити набір станів, окрім контракту ) або користувача ), який явно видаляє об'єкти. Користувачі, які платять за видалення даних, можуть отримати можливості для арбітражу, створюючи зберігання в дешевий час та видаляючи його в дорогий. Відкладання вирішення цього завдання може зменшити мотивацію розробників для видалення даних у блокчейні. Команда досліджує концепцію TTL для кожного проекту, яка дозволить видаляти невикористані елементи стану після закінчення терміну дії TTL.