Пользовательская виртуальная машина (Custom VM)

Что такое пользовательская виртуальная машина?

Пользовательская виртуальная машина, или Custom VM, — это среда исполнения в блокчейне, разработанная по собственным правилам обработки транзакций, запуска программ, управления состоянием и учета вычислительных ресурсов.

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

Команда может создать Custom VM вместо использования существующей среды, например Ethereum Virtual Machine, если ей нужны иные характеристики производительности, безопасности, программирования, конфиденциальности или функциональности приложений.

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

У Custom VM могут быть собственный набор инструкций, структура аккаунтов, правила хранения данных, формат транзакций, модель комиссий, системные функции и язык смарт-контрактов.

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

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

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

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

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

Что делает виртуальная машина блокчейна?

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

Она получает транзакции или инструкции программы и применяет их к текущему состоянию блокчейна.

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

Затем она выполняет разрешенные операции: например, переводит токены, меняет данные контракта, выпускает NFT, обновляет позицию в кредитном протоколе или учитывает голос в управлении.

После исполнения VM формирует новое состояние, которое другие узлы могут независимо проверить.

В документации Ethereum Virtual Machine EVM описывается как децентрализованная виртуальная среда, которая одинаково исполняет код на узлах Ethereum.

Custom VM выполняет ту же общую задачу, но может использовать другую архитектуру и правила исполнения.

Обычно виртуальная машина не отвечает за все компоненты блокчейна.

Консенсус определяет, как узлы согласуют порядок блоков и их принятие, а VM — что делают упорядоченные транзакции.

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

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

Custom VM относится именно к слою исполнения, однако ее устройство может влиять и на остальные слои.

Зачем блокчейнам создавать Custom VM

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

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

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

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

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

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

Custom VM дает разработчикам возможность оптимизировать блокчейн под эти задачи.

Но за это приходится платить необходимостью самостоятельно создавать и поддерживать больше инфраструктуры.

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

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

Custom VM и Ethereum Virtual Machine

Ethereum Virtual Machine, или EVM, — это среда исполнения смарт-контрактов Ethereum, совместимость с которой стала широко распространенной в криптоиндустрии.

Разработчики обычно пишут контракты для EVM на Solidity или Vyper и компилируют их в байткод EVM.

EVM использует стековую архитектуру и измеряет объем исполнения в газе.

Крупная экосистема разработчиков EVM включает зрелые кошельки, библиотеки, фреймворки тестирования, инструменты безопасности и стандарты контрактов.

По большинству ключевых проектных решений Custom VM может отличаться от EVM.

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

Она также может поддерживать языки программирования, обычно не используемые для контрактов EVM.

Главное преимущество EVM — совместимость.

Главное преимущество Custom VM — возможность настроить среду исполнения под конкретную задачу.

Однако совместимость с EVM и пользовательская среда исполнения не всегда взаимоисключают друг друга.

В некоторых сетях используется собственная базовая VM, а поверх нее — интерпретатор или слой совместимости с байткодом EVM.

Например, в официальной документации EraVM описана архитектура, в которой оптимизированная для ZK VM остается основной средой исполнения, а интерпретатор EVM поддерживает байткод в стиле Ethereum.

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

Custom VM и пользовательская среда исполнения блокчейна

Термины Custom VM и «пользовательская среда исполнения блокчейна» иногда используют как синонимы, хотя различие может иметь значение.

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

Среда исполнения — более широкое понятие: оно охватывает логику обработки транзакций и определения переходов состояния блокчейна.

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

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

В документации Polkadot SDK по узлу и среде исполнения среда исполнения описывается как логика переходов состояния блокчейна, скомпилированная в WebAssembly для исполнения на разных платформах.

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

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

Поэтому в обсуждениях криптовалют термин Custom VM иногда используют неточно.

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

Основные компоненты Custom VM

Набор инструкций

Набор инструкций определяет низкоуровневые операции, которые могут выполнять программы.

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

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

Разработчики Custom VM должны обеспечить четкий и детерминированный смысл каждой инструкции.

Модель состояния

Модель состояния определяет, как блокчейн представляет аккаунты, балансы, контракты, токены, объекты и хранимые данные.

В некоторых VM используется глобальное состояние на основе аккаунтов, похожее на Ethereum.

В других применяются неизрасходованные выходы транзакций, независимые объекты, хранилища «ключ — значение» или записи для конкретных приложений.

Модель состояния существенно влияет на параллельное исполнение транзакций, дизайн кошельков, права контрактов и удобство разработки.

Память и хранилище

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

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

В Custom VM могут быть предусмотрены специальные структуры хранения, снижающие затраты или упрощающие создание доказательств.

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

Учет ресурсов

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

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

EVM использует газ, тогда как другие среды исполнения могут учитывать вычислительные единицы, веса, циклы или отдельные категории ресурсов.

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

Функции хоста и системные вызовы

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

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

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

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

Как транзакции исполняются в Custom VM

Транзакция обычно попадает в блокчейн через узел или RPC-эндпоинт.

Сеть проверяет базовые параметры, такие как формат, подписи, комиссии и защиту от повторного воспроизведения.

Консенсус или ПО для создания блоков определяет положение транзакции относительно других транзакций.

Затем Custom VM загружает транзакцию, соответствующее состояние и программу, которую необходимо исполнить.

Она проверяет разрешения и инициализирует контекст исполнения.

VM обрабатывает инструкции и отслеживает потребление ресурсов.

Если исполнение завершается успешно, изменения состояния сохраняются.

Если исполнение завершается ошибкой, VM обычно отменяет часть или все изменения состояния согласно правилам протокола.

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

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

Это требование называется детерминированным исполнением.

Детерминированность Custom VM

Детерминированность означает, что одинаковые входные данные должны давать одинаковые результаты на каждом честном узле.

Это требование не позволяет валидаторам расходиться во мнениях о правильном состоянии блокчейна.

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

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

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

Внешняя информация обычно поступает через оракул или проверенное сообщение, а не через неограниченный веб-запрос.

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

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

Песочница и изоляция

Custom VM обычно запускает программы в песочнице, ограничивающей их доступ к операционной системе узла.

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

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

Она также ограничивает глубину вызовов, размер стека, рост памяти и время исполнения.

Надежная изоляция защищает валидаторов от вредоносных программ, загружаемых пользователями.

Она также защищает контракты от несанкционированного доступа со стороны других контрактов.

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

Поэтому реализация Custom VM требует тщательных аудитов, фаззинг-тестирования, проверки зависимостей и безопасного проектирования компилятора.

Стековые и регистровые Custom VM

Стековая VM выполняет многие операции, помещая значения в стек и извлекая их, когда инструкции используют эти данные.

Известный пример стековой виртуальной машины — EVM.

Регистровая VM хранит рабочие значения в именованных или пронумерованных регистрах.

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

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

Ни одна из архитектур не является безусловно лучшей для любого блокчейна.

Стековые системы могут иметь более простой байткод и развитый набор инструментов.

Регистровые системы могут давать преимущества при исполнении или компиляции для определенных типов задач.

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

Custom VM и параллельное исполнение

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

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

Custom VM можно спроектировать так, чтобы она определяла, какие данные состояния транзакция считывает или изменяет.

Транзакции, не конфликтующие друг с другом, можно исполнять на нескольких ядрах процессора.

Это может повысить пропускную способность приложений с большим количеством независимых пользователей.

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

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

Также она может использовать оптимистичное исполнение и повторно запускать транзакции при обнаружении конфликтов.

Параллельная обработка повышает производительность только при корректной работе планирования, выявления конфликтов и фиксации состояния.

Разработчикам важно понимать модель параллелизма: две транзакции могут вести себя по-разному по отдельности и при одновременной конкуренции за одни и те же данные.

Custom VM и языки смарт-контрактов

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

VM может поддерживать Rust, C, C++, Move, языки, совместимые с WebAssembly, или специально созданный язык смарт-контрактов.

Язык влияет на безопасность, продуктивность разработчиков, размер контракта и сложность компилятора.

Язык со строгой системой типов и правилами владения может предотвратить некоторые ошибки до развертывания.

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

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

Из-за ошибки компилятора развернутый байткод может работать не так, как исходный код разработчика.

Зрелой экосистеме нужны воспроизводимые сборки, проверка исходного кода, отслеживание версий компилятора и независимый аудит безопасности.

Custom VM и WebAssembly

WebAssembly, или Wasm, — переносимый двоичный формат инструкций, который может служить основой исполнения в блокчейне.

Блокчейн может компилировать среду исполнения или смарт-контракты в Wasm и запускать их в контролируемой среде.

Wasm поддерживает несколько исходных языков и обеспечивает платформонезависимый формат исполнения.

Polkadot SDK хранит логику исполнения блокчейна в двоичном файле Wasm и позволяет обновлять ее через процедуры управления в блокчейне.

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

Блокчейн с Wasm все равно использует Custom VM, если он задает собственные функции хоста, стоимость ресурсов, правила состояния и обработку транзакций.

Wasm обеспечивает основу для исполнения, но то, как она работает в криптоиндустрии, определяют окружающие правила среды исполнения сети.

Custom VM и блокчейны для конкретных приложений

Блокчейн для конкретного приложения проектируется вокруг одного приложения, рынка или вида деятельности.

Вместо использования общей VM для несвязанных приложений такая сеть может разработать правила исполнения специально для своих пользователей.

В официальном обзоре Cosmos SDK объясняется, что разработчики могут объединять готовые модули и создавать собственные под требования приложения.

В блокчейн для торговли можно встроить собственное сопоставление ордеров и средства контроля рисков.

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

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

Исполнение для конкретного приложения может быть эффективнее, поскольку распространенные операции становятся функциями протокола, а не сложными смарт-контрактами.

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

Custom VM в роллапах

Роллап исполняет транзакции вне базового блокчейна и отправляет данные, обязательства или доказательства в слой расчетов.

Поскольку роллап контролирует свое ПО для исполнения, он может использовать Custom VM вместо точного копирования VM базового уровня.

Custom VM может снизить затраты на создание доказательств, поддерживать другие модели аккаунтов или предоставлять специализированные функции приложения.

Однако пользовательская среда исполнения может осложнить совместимость с существующими кошельками, контрактами и инструментами разработки.

Для поддержки активов и приложений из другой экосистемы разработчикам могут понадобиться мосты или интерпретаторы.

Роллапу также необходимо определить, как слой расчетов будет проверять результаты Custom VM.

Оптимистичный роллап может использовать доказательства мошенничества или игры разрешения споров.

ZK-роллап может отправлять доказательства корректности, подтверждающие, что Custom VM соблюдала свои правила.

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

Таким образом, Custom VM становится частью модели безопасности и совместимости роллапа.

Custom VM и модульные блокчейны

Модульная архитектура блокчейна разделяет исполнение, консенсус, доступность данных и расчеты на отдельные компоненты.

Это разделение дает командам роллапов больше свободы при выборе или создании Custom VM.

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

Один слой исполнения может использовать EVM, а другой — Wasm, VM с нулевым разглашением или специализированный конечный автомат.

Эта гибкость — одно из главных преимуществ модульной архитектуры.

Однако команда должна определить, как Custom VM получает данные, проверяет сообщения, взаимодействует с мостами и формирует результаты, которым могут доверять другие системы.

Высокая производительность VM не делает модульную сеть безопасной, если данные недоступны или мост может быть взломан.

Custom VM и доказательства с нулевым разглашением

Виртуальная машина с нулевым разглашением, или zkVM, исполняет программы и одновременно создает криптографическое доказательство корректности исполнения.

Во многих случаях это доказательство можно проверить эффективнее, чем повторять все вычисления.

В документации RISC Zero по zkVM описана система, которая доказывает корректность исполнения произвольного кода Rust.

В ее технической спецификации указано, что VM реализует 32-битный набор инструкций RISC-V.

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

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

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

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

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

Доказательство может подтвердить, что VM следовала своим правилам, даже если экономическая модель приложения вредна или в его коде есть ошибка.

Custom VM и совместимость с EVM

Custom VM может быть совместима с EVM, не будучи ее точной копией.

Совместимость с EVM обычно означает, что разработчики могут развертывать контракты Solidity или использовать привычные инструменты Ethereum с минимальными изменениями.

Эквивалентность EVM — более сильное утверждение: поведение среды исполнения почти полностью соответствует EVM Ethereum.

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

Интерпретатор может исполнять байткод EVM внутри Custom VM.

Слой совместимости может воспроизводить API Ethereum при использовании другого внутреннего состояния или системы доказательств.

Каждый способ предполагает компромиссы в производительности, работе газа, отладке, предположениях о контрактах и сложности обновления.

Разработчикам не следует считать, что сеть, совместимая с EVM, во всех нестандартных случаях работает точно как Ethereum.

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

Преимущества пользовательской виртуальной машины

Первое преимущество Custom VM — производительность, оптимизированная для конкретного приложения.

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

Второе преимущество — гибкая модель состояния.

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

Третье преимущество — более эффективное параллельное исполнение.

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

Четвертое преимущество — специализированная безопасность.

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

Пятое преимущество — эффективное создание криптографических доказательств.

Custom VM может использовать инструкции и структуру памяти, разработанные для систем доказательств с нулевым разглашением.

Шестое преимущество — удобство для пользователей.

На уровне VM можно реализовать восстановление аккаунта, оплату комиссий третьей стороной, разрешения на отдельные сессии или предсказуемые комиссии.

Седьмое преимущество — функции на уровне протокола.

Нативные активы, книги ордеров, правила конфиденциальности или управление можно встроить непосредственно в среду исполнения.

Риски и ограничения Custom VM

Первый риск — ошибки реализации.

Новая VM прошла меньше испытаний в реальных условиях, чем зрелая среда исполнения, используемая многими сетями.

Второй риск — недостаток инструментов для разработчиков.

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

Третий риск — ограниченная совместимость с экосистемой.

Существующие контракты, кошельки и инфраструктура могут работать только после доработки.

Четвертый риск — сложность спецификации.

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

Пятый риск — централизация обновлений.

Если одна команда может менять VM без надежного контроля со стороны управления, пользователям приходится доверять, что эта команда не внедрит вредоносные изменения.

Шестой риск — незрелая экосистема безопасности.

Аудиторы могут иметь небольшой опыт работы с новым форматом байткода или моделью исполнения.

Седьмой риск — неверная оценка стоимости ресурсов.

Неправильные тарифы на ресурсы могут удешевить атаки типа «отказ в обслуживании» или сделать легитимные приложения слишком дорогими.

Восьмой риск — фрагментация.

Слишком большое количество несовместимых Custom VM может разделить разработчиков, ликвидность, инструменты и пользователей между изолированными экосистемами.

Требования безопасности к Custom VM

Безопасная Custom VM должна обеспечивать детерминированное исполнение в разных реализациях узлов и аппаратных средах.

Она должна изолировать недоверенные программы от операционной системы валидатора.

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

Необходимо учитывать потребление всех ресурсов, которые могут исчерпать злоумышленники.

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

Нужно определить порядок отмены изменений состояния при ошибке исполнения.

Необходимо предотвращать повторное использование подписей между транзакциями, блокчейнами или доменами.

Привилегированные функции хоста и системные контракты должны быть защищены от неавторизованных вызовов.

Компилятор и верификатор байткода должны отклонять некорректные или небезопасные программы.

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

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

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

Обновления Custom VM

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

Изменять правила VM нужно осторожно: все узлы должны начать применять новые правила в нужный момент работы блокчейна.

Из-за неправильного обновления сеть может разделиться, если одни узлы принимают транзакции, которые другие отклоняют.

Некоторые блокчейны согласуют обновления VM через запланированные выпуски ПО и хардфорки.

В других обновляемая среда исполнения хранится ончейн, а изменения утверждаются через управление.

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

Пользователям следует выяснить, кто может одобрять обновления Custom VM и предусмотрена ли задержка перед их вступлением в силу.

Неизменяемая VM снижает риски управления, но затрудняет срочное исправление ошибок.

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

Как разработчикам оценивать Custom VM

Сначала разработчикам следует изучить языки программирования VM и зрелость ее компилятора.

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

Следует проверить, можно ли сверить опубликованный исходный код контракта с развернутым.

Необходимо изучить инструменты отладки, локального тестирования, тестнета, развертывания и мониторинга.

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

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

Нужно проверить, поддерживают ли сеть существующие кошельки, кастодиальные решения, индексаторы и инфраструктура.

Следует выяснить, применимы ли заявленные показатели производительности к реальным приложениям, а не только к простым тестовым транзакциям.

Также необходимо изучить полномочия по обновлению: даже на безопасную программу могут повлиять изменения среды исполнения.

Как пользователям криптовалют оценивать блокчейн с Custom VM

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

Следует проверить, как долго Custom VM работает в основной сети.

Важно выяснить, публикует ли сеть аудиты, технические спецификации, отчеты об инцидентах и уведомления об обновлениях.

Нужно понять, отображает ли кошелек сведения о транзакции в удобочитаемом формате.

Следует проверить, зависят ли активы от мостов при переводе между сетью Custom VM и другими сетями.

Важно знать комиссии сети, правила финальности, модель секвенсора и порядок вывода средств.

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

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

Custom VM может предоставить полезные функции, но пользователи по-прежнему сталкиваются с рисками смарт-контрактов, мостов, кошельков, управления и рынка.

Распространенные сценарии использования Custom VM

Custom VM применяют в высокопроизводительных сетях смарт-контрактов, которым нужно параллельное исполнение.

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

Они применяются в блокчейн-играх, требующих большого количества недорогих обновлений состояния.

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

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

Их используют в роллапах, которым нужны эффективные доказательства корректности.

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

Их используют в слоях совместимости, которым нужно эффективно проверять межсетевые сообщения.

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

Распространенные заблуждения о Custom VM

Одно из заблуждений — будто у каждого блокчейна без EVM есть традиционная Custom VM.

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

Другое заблуждение — будто Custom VM автоматически работает быстрее EVM.

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

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

Специализированная VM может снижать одни риски, но создавать новые риски реализации и нехватки инструментов.

Четвертое заблуждение — будто совместимость с EVM означает полное соответствие поведению Ethereum.

В совместимых системах могут отличаться исполнение, комиссии, предварительно скомпилированные контракты, финальность и инфраструктура.

Пятое заблуждение — будто zkVM гарантирует безопасность любого приложения.

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

Шестое заблуждение — будто пользователям никогда не нужно знать, какую VM использует блокчейн.

VM может влиять на поддержку кошельков, комиссии за транзакции, безопасность контрактов, стандарты активов, активность разработчиков и требования к мостам.

Будущее пользовательских виртуальных машин

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

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

Одна среда может запускать контракты EVM, а другая — нативные программы Wasm, RISC-V или приложения для конкретных задач.

Интерпретаторы и слои компиляции могут упростить перенос приложений между разными VM.

Усовершенствования доказательств с нулевым разглашением могут сделать эффективной проверку более универсальных программ.

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

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

Долгосрочная задача — найти баланс между специализацией и совместимостью.

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

Наиболее сильные экосистемы Custom VM, вероятно, будут сочетать технические преимущества со зрелыми инструментами, четкими спецификациями, тщательными аудитами и надежными мостами.

Вопросы и ответы

Что такое Custom Virtual Machine в криптоиндустрии?

Custom Virtual Machine — это среда исполнения в блокчейне, созданная по собственным правилам запуска программ, обработки транзакций, управления состоянием и учета вычислительных ресурсов.

Что означает Custom VM?

Custom VM — виртуальная машина, созданная или измененная под конкретные потребности блокчейна, роллапа, блокчейна приложения или системы доказательств.

Custom VM и EVM — одно и то же?

Нет. EVM — конкретная среда исполнения, тогда как Custom VM может использовать другие инструкции, модели состояния, языки, комиссии и правила безопасности.

Зачем блокчейну использовать Custom VM?

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

Может ли Custom VM поддерживать Solidity?

Да. Custom VM может поддерживать Solidity через пользовательский компилятор, интерпретатор EVM или слой совместимости, хотя ее поведение может не полностью соответствовать Ethereum.

Среда исполнения блокчейна и VM — одно и то же?

Не всегда: среда исполнения в широком смысле определяет логику переходов состояния, а VM обычно исполняет байткод согласно заданному набору инструкций.

Что такое zkVM?

zkVM — виртуальная машина, которая исполняет программы и создает криптографические доказательства того, что исполнение соответствовало заданным правилам.

Custom VM быстрее EVM?

Некоторые Custom VM могут быстрее выполнять определенные типы задач, однако реальная производительность также зависит от консенсуса, хранилища, сети, оборудования и архитектуры приложения.

Безопасны ли Custom VM?

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

Какие языки программирования поддерживают Custom VM?

Custom VM могут поддерживать Solidity, Rust, C, C++, Move, языки, совместимые с Wasm, или специально созданные языки смарт-контрактов.

Может ли Custom VM исполнять транзакции параллельно?

Да, если Custom VM способна определять транзакции, обращающиеся к независимым аккаунтам, объектам или областям хранилища.

Нужен ли Custom VM газ?

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

Можно ли обновить Custom VM?

Да. Многие Custom VM обновляются с помощью хардфорков, управления, замены среды исполнения или обновляемых контрактов роллапа.

Каков главный недостаток Custom VM?

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

Влияет ли Custom VM на пользователей криптовалют?

Да. Она может влиять на комиссии за транзакции, поддержку кошельков, финальность, безопасность контрактов, доступность приложений, стандарты активов и требования к мостам.

Заключение

Custom Virtual Machine — специализированная среда исполнения в блокчейне, определяющая обработку транзакций, контрактов и изменений состояния.

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

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

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

Однако пользовательская среда исполнения возлагает на разработчиков дополнительную ответственность.

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

Custom VM не следует оценивать только по заявленной скорости транзакций.

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

Лучшие Custom VM сочетают существенные технические улучшения с понятной документацией и зрелыми практиками безопасности.

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