Цена Movement Network (MOVE)

Movement Network — это архитектура блокчейн-сети, построенная вокруг технологического стека Move; MOVE — её нативный токен. В white paper сеть описывается как инфраструктура Move-цепей, в которой упорядочивание транзакций, исполнение, доступность данных и расчёты можно разделять и комбинировать, а не как изолированную цепь, состоящую лишь из одной среды исполнения. Для пользователей ключевым является не само название «Move», а то, что транзакция проходит такие этапы, как упорядочивание, исполнение и подтверждение состояния; каждая цепь может выбирать нужные ей компоненты. White paper описывает архитектуру и модель безопасности, однако включена ли конкретная настраиваемая возможность в определённой цепи или приложении, зависит от фактического развёртывания.

Основное сетевое применение MOVE — предоставление стейкингового обеспечения для валидации: валидаторы блокируют нативные токены, участвуют в подтверждении переходов состояния и несут посредством стейка экономические последствия недобросовестного поведения или ошибочных подтверждений. Простое владение MOVE не делает адрес валидатором автоматически; также необходимо выполнить условия участия в валидации и технические требования сети. Эта схема связывает результаты валидации с обеспечением, которое может быть наказано. Валидаторы, подтверждающие состояние в соответствии с протоколом, могут получать стимулы по правилам сети; при определённом протоколом нечестном поведении стейк может быть конфискован. Конкретные вознаграждения, делегирование, минимальные пороги и условия выхода нельзя выводить из архитектурного описания в white paper.

Цель white paper — позволить MoveVM и байткоду EVM подключаться к одной сетевой архитектуре: MoveVM используется для исполнения контрактов Move, а EVM — для исполнения распространённых в экосистеме Ethereum контрактов EVM. Это решает различие сред исполнения при разработке и переносе приложений, а не означает, что две виртуальные машины являются одним языком или автоматически обеспечивают полную совместимость. Транзакция всё равно должна быть интерпретирована используемой ею средой исполнения и изменить состояние цепи, после чего она проходит соответствующий процесс подтверждения или расчёта. Поэтому фактический опыт поддержки двух сред исполнения также зависит от включённых в конкретной цепи рантаймов, инструментов и приложений; из одного лишь архитектурного описания нельзя сделать вывод, что любой контракт будет работать без изменений.

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

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

При участии в валидационном стейкинге сначала необходимо различать владение токенами, стейкинг и фактическую работу валидатора. Стейкинг предоставляет экономическое обеспечение, однако валидатор также несёт ответственность за подтверждение состояния; если протокол признает его поведение наказуемо нечестным, соответствующий стейк может быть конфискован. Поэтому участникам нельзя судить только по потенциальному вознаграждению: следует также проверить, открыт ли данный способ участия в конкретной сети, поддерживается ли делегирование, правила блокировки или выхода, операционные обязанности валидатора и условия применения конфискации. White paper подтверждает логику безопасности вознаграждений и наказаний, но в предоставленных материалах не устанавливает единый доступный пользователю порог или доходность.

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

Конструкция быстрой окончательности использует подтверждение валидаторами переходов состояния; white paper называет условием формирования быстрого подтверждения подтверждение более чем двумя третями общего объёма стейка. Этот порог связывает вес подтверждения с застейканными токенами: только состояние, поддержанное достаточным весом стейка, удовлетворяет условию быстрого подтверждения. Однако «быстрое подтверждение» и более широкие гарантии окончательного расчёта — не одно и то же. White paper также рассматривает схемы, сочетаемые с оптимистичным или zero-knowledge расчётом; последние затрагивают используемый уровень расчёта и механизм доказательств или споров. Поэтому следует оценивать конкретную конфигурацию используемой цепи, чтобы определить, когда транзакцию можно считать отвечающей необходимым требованиям окончательности.

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

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

Модульный расчёт позволяет цепи сочетать более быстрое локальное подтверждение с разными способами обеспечения расчёта. White paper предлагает сочетать быстрый расчёт с оптимистичным или zero-knowledge расчётом: первый опирается на конкретные споры или предположения, второй — на проверку доказательств; это не разные названия одного механизма. Практический смысл такого разделения на уровни состоит в том, что скорость, предположения безопасности и внешние зависимости расчёта нужно рассматривать вместе. Пользователям и разработчикам, которых интересуют междоменные активы, крупные суммы или необратимые операции, следует изучить конкретный путь расчёта, применяемый используемой цепью или приложением, а не считать все связанные с Movement транзакции полностью одинаковыми по окончательности.