Ціна Movement Network (MOVE)

Movement Network — це архітектура блокчейн-мережі, побудована навколо технологічного стеку Move; MOVE є її нативним токеном. У whitepaper ця мережа описана як інфраструктура Move-ланцюгів, яка може розділяти та комбінувати впорядкування транзакцій, виконання, доступність даних і розрахунки, а не як один ізольований ланцюг, що складається лише з одного середовища виконання. Для користувачів ключовим є не сама назва «Move», а те, що транзакція проходить етапи впорядкування, виконання та підтвердження стану; кожен ланцюг може обирати відповідні компоненти відповідно до власних потреб. Whitepaper описує архітектуру та дизайн безпеки, а те, чи ввімкнено певну налаштовувану можливість у конкретному ланцюгу або застосунку, все одно залежить від його фактичного розгортання.

Основне мережеве призначення MOVE — надавати заставу стейкінгу для валідації: після блокування нативних токенів валідатори беруть участь у підтвердженні переходів стану та несуть через стейк економічні наслідки недобросовісних або помилкових підтверджень. Саме лише володіння MOVE не робить адресу валідатором автоматично; також необхідно відповідати умовам участі у валідації та технічним умовам мережі. Ця модель пов’язує результати валідації із заставою, яку можна покарати. Якщо валідатори підтверджують стан за протоколом, вони можуть отримувати відповідні стимули за правилами мережі; у разі визначеної протоколом нечесної поведінки стейк може бути скорочений. Конкретні винагороди, делегування, мінімальні пороги та умови виходу не можна виводити з архітектурного опису в whitepaper.

Мета whitepaper полягає в тому, щоб і MoveVM, і байткод EVM могли підключатися до однієї мережевої архітектури: MoveVM виконує контракти Move, а EVM — поширені в екосистемі Ethereum контракти EVM. Це вирішує проблему відмінних середовищ виконання під час розробки та міграції застосунків, а не прирівнює дві віртуальні машини до однієї мови чи автоматично забезпечує повну сумісність. Транзакції все одно мають бути інтерпретовані середовищем виконання, яке вони використовують, і змінити стан ланцюга, після чого вони переходять до відповідного процесу підтвердження або розрахунку. Тому фактичний досвід підтримки двох середовищ виконання також залежить від увімкненого в конкретному ланцюгу runtime, інструментів і застосунків; не можна лише з архітектурного опису робити висновок, що будь-який контракт працюватиме без змін.

Базовий шлях транзакції такий: спочатку секвенсор визначає порядок її обробки, потім рівень виконання запускає транзакцію в цьому порядку й створює новий стан, а зрештою рівні валідації та розрахунку підтверджують або гарантують цей стан. Упорядкування існує для того, щоб учасники мали спільну основу щодо послідовності обробки; виконання обчислює зміни стану; підтвердження або розрахунок визначає, за яких припущень безпеки цей стан може бути прийнятий. Ці рівні можуть бути розділені та скомбіновані, тому «транзакція швидко відображається як підтверджена» не обов’язково означає, що вона вже отримала всі гарантії базового розрахунку. Різні конфігурації можуть застосовувати швидке підтвердження разом з оптимістичним або zero-knowledge розрахунком; користувачам слід розрізняти підтвердження, показане застосунком, підтвердження валідаторами та остаточні гарантії, які надає рівень розрахунку, на який вони спираються.

Спільне впорядкування — це дизайн, за якого перевірюваний спільний компонент визначає порядок обробки транзакцій. Його функція не обмежується «чергою»: коли кільком Move-ланцюгам або застосункам потрібно покладатися на один порядок, спільне впорядкування може зменшити проблеми координації, що виникають через окреме впорядкування кожним із них, і створити спільну основу для міжланцюгової співпраці. Саме впорядкування не виконує контракти й окремо не доводить, що актив уже надійшов до іншого ланцюга. Після впорядкування транзакція все одно має бути виконана, перевірена та оброблена за відповідним механізмом розрахунку; спосіб реалізації міжланцюгових повідомлень, стану активів і остаточності залежить від конкретних міжланцюгових з’єднань і розгорнутих компонентів.

Під час участі у стейкінгу для валідації спершу потрібно розрізняти володіння токенами, стейкінг і фактичну роботу валідатора. Стейкінг надає економічну заставу, але валідатор також несе відповідальність за підтвердження стану; якщо протокол визнає його винним у нечесній поведінці, яка підлягає покаранню, відповідний стейк може бути скорочений. Тому учасники не повинні оцінювати участь лише за потенційними винагородами: також слід підтвердити, чи відкрита конкретна мережа для такого способу участі, чи підтримує вона делегування, правила блокування або виходу, операційні обов’язки валідатора та умови застосування скорочення. Whitepaper підтверджує логіку безпеки винагород і покарань, але в наданому матеріалі не встановлює єдиного порогу чи дохідності, доступних для дій користувача.

Move Stack — це модульний фреймворк для побудови Move-ланцюгів. Його суть полягає в тому, щоб розглядати виконання, впорядкування, доступність даних і розрахунок як компоновані рівні, а не вимагати, щоб кожен ланцюг використовував цілком однакову реалізацію; розробники можуть обирати відповідну конфігурацію залежно від потреб ланцюга та підключатися до ширшої архітектури Movement. Модульність не означає, що всі комбінації від природи мають однакову продуктивність або безпеку. Те, на які компоненти впорядкування, доступності даних і розрахунку фактично спирається ланцюг, безпосередньо впливає на спосіб його підтвердження та припущення безпеки; слід керуватися опублікованим описом розгортання цього ланцюга.

Дизайн швидкої остаточності передбачає, що валідатори підтверджують переходи стану; у whitepaper підтвердження понад двома третинами загального обсягу стейку визначено як умову формування швидкого підтвердження. Цей поріг пов’язує вагу підтвердження із застейканими токенами: лише стан, підтриманий достатньою вагою стейку, відповідає умові швидкого підтвердження. Проте «швидке підтвердження» і ширші гарантії остаточного розрахунку — не одне й те саме. Whitepaper також розглядає поєднання з оптимістичним або zero-knowledge розрахунком; останній охоплює рівень розрахунку, на який спираються, і механізм доказів або спорів. Отже, момент, коли транзакцію можна вважати такою, що відповідає потрібній вимозі остаточності, слід визначати за конкретною конфігурацією використовуваного ланцюга.

Інтероперабельність тут означає, що різні ланцюги можуть координувати інформацію та спільно використовувати інфраструктуру, а не просто одночасно користуватися однаковою назвою чи токеном. Дизайн Movement розглядає спільне впорядкування та міжланцюгові з’єднання як основу підтримки співпраці Move-ланцюгів, щоб вони не мусили працювати повністю в ізольованих середовищах впорядкування й координації. Втім, можливість передати певний актив, види повідомлень, які можна передавати, і час завершення все одно визначаються конкретним мостом або міжланцюговим протоколом та його правилами валідації і розрахунку. Спільне впорядкування може допомогти створити умови для координації, але не замінює валідацію активів і стану, необхідну для кожної міжланцюгової операції.

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

Модульний розрахунок дозволяє ланцюгу поєднувати швидші локальні підтвердження з різними способами забезпечення розрахунку. Whitepaper пропонує поєднувати швидкий розрахунок з оптимістичним або zero-knowledge розрахунком: перший спирається на конкретні спори або припущення, другий — на перевірку доказів; це не різні назви одного механізму. Практичне значення цього поділу на рівні полягає в тому, що швидкість, припущення безпеки та зовнішні залежності розрахунку потрібно розуміти разом. Користувачі та розробники, яких цікавлять міждоменні активи, великі суми або незворотні операції, повинні перевіряти конкретний шлях розрахунку, який використовує відповідний ланцюг або застосунок, а не вважати всі пов’язані з Movement транзакції такими, що мають цілком однакову остаточність.