Radix Engine: лучшая модель для «закрепления»

В моем предыдущая статья Я рассказал, как Radix Engine удалось избежать некоторых недостатков MoveVM Sui. Обобщить:

• MoveVM от Sui слишком низкоуровневый и универсальный, что делает среду программирования DeFi громоздкой.
• Radix Engine ориентирован на высокоуровневую логику активов и бизнес-логику, что позволяет разработчикам сосредоточиться на логике DeFi, а не на деталях низкого уровня.

MoveVM Суи следует оригиналу Философия Эфириума «чистого, простого и красивого» протокола, который делегирует все на прикладной уровень. Это дает разработчикам свободу исследовать любую область, включая неизвестные на тот момент.

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

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

• Обеспечьте соблюдение общесистемных стандартов/внедрений . Самоуверенный стандарт позволяет упростить разработку/обслуживание/инструментарий для всего стека, поскольку API не фрагментированы (например, ERC-20, ERC-721 или ERC-404), а понимание поведения не требует интерпретации байт-кода (не более того). Коврик ERC-20 тянется). Это дает разработчикам и конечным пользователям более безопасный и последовательный опыт работы с DeFi.
• Выполняйте логику ближе к аппаратному обеспечению . Поскольку для корректности системной логики не требуется, чтобы ее выполнял интерпретатор, выполнение этой логики может выполняться как можно ближе к аппаратному обеспечению.
• Распараллелить выполнение. Имея собственные знания о поведении определенных объектов, легче принимать решения статического анализа перед выполнением, что позволяет выполнять параллельное выполнение.

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

Этот баланс поддержки абстракции (т. е. будущих/разнообразных потребностей пользователей) при сохранении производительности/безопасности/удобства использования (т. е. закрепления) на самом деле является очень старой проблемой информатики. В последние десятилетия при проектировании операционных систем пытались решить аналогичную проблему: как мы можем поддерживать ряд абстрактных приложений, сохраняя при этом быструю, безопасную и удобную систему?

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

Давайте начнем с рассмотрения текущего отраслевого стандарта — виртуальной машины Ethereum («EVM»).

EVM как виртуальная машина

EVM достаточно прост, чтобы его можно было смоделировать как виртуальную машину («VM») со следующими кодами операций:

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

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

В этой модели любая форма «закрепления» требует изменений в EVM или аппаратном обеспечении виртуальной машины. Например, для закрепления поддержки подписи BLS потребуется добавить новую прекомпиляцию. Реализация ЭИП-2938 потребует добавления новых кодов операций. Расширение того, что закреплено, неизбежно приводит к увеличению и усложнению виртуальной машины и вынуждает разработчика протокола принимать то или иное решение, которое описывает Виталик.

Общая проблема этой модели заключается в том, что дихотомия абстракция/закрепление слишком связана с дихотомией программного обеспечения/аппаратного обеспечения. То есть закрепление любой логики в протоколе приводит к ее внедрению в виртуальную машину. Невозможно выразить «встроенное программное обеспечение» или программное обеспечение, которое является частью системы.

Операционные системы решили эту дихотомию с помощью понятия «системное программное обеспечение». Давайте посмотрим поближе.

Модель операционной системы

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

\С точки зрения «закрепления» ядро и его модули являются закрепленными частями системы, но обладают гибкостью программного обеспечения. Модули ядра, виртуальные машины («ВМ») и системные процессы пользовательского пространства являются еще более «мягкими», поскольку они абстрагированы от самого ядра.

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

Radix Engine как операционная система

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

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

• Наследовать свойства изоляции слоя, в котором он находится . Например, закрепленный пакет, хотя и закреплен, не может получить доступ к произвольному состоянию, но должен следовать границам уровня приложения. Это аналогичный тип безопасности, который можно увидеть в драйверах пользовательского пространства или в конструкции микроядра. То есть риск снижается за счет изоляции каждой части системы, чтобы любые обновления в системе (закрепление) не подвергали риску всю систему.
• Доступ к функциям уровня, на котором он находится. Например, закрепленный пакет может наследовать функции аутентификации и/или возможности обновления, предоставляемые системой.
• Разделить управление. Такая модульная конструкция позволяет внедрять инновации в каждом из этих модулей параллельно и с разной скоростью.

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

Прикладной уровень

Уровень приложения отвечает за определение логики высокого уровня. Байт-код, описывающий эту логику, наряду с другой статической информацией, упакован в исполняемый формат, называемый Package. Затем пакеты сохраняются в реестре и доступны для выполнения.

Приложения, написанные на Scrypto, языке на основе Rust, который мы создали для разработки DeFi, живут на этом уровне. Программы Scrypto компилируются в программы WASM с доступом к набору экспортируемых функций, которые позволяют программе получать доступ к службам системы/ядра. Этот API системного вызова похож на линукс системные вызовы , которые обеспечивают доступ к общему вводу-выводу.

Уровень виртуальной машины

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

В настоящее время Radix Engine поддерживает две виртуальные машины: виртуальную машину Scrypto WASM, используемую для выполнения приложений Scrypto, и собственную виртуальную машину, которая выполняет собственные пакеты, скомпилированные в среду хоста.

Если мы посмотрим конкретно на виртуальную машину Scrypto WASM, она будет выглядеть так:

По сути, это может выглядеть так же, как модель EVM, но есть два существенных отличия:

• Удаление прямого доступа к хранилищу. Вместо того, чтобы каждый смарт-контракт мог получить доступ только к своему хранилищу, любое чтение/запись состояния осуществляется посредством системных вызовов. Этот уровень косвенности позволяет реализовать в системе множество интересных вещей, таких как совместное использование состояния между приложениями, виртуализация состояний и т. д. Этот уровень косвенности аналогичен косвенности, обеспечиваемой виртуальная память или Linux файловые дескрипторы .

  
  

• Добавление системных вызовов . Системные вызовы — это механизм, с помощью которого уровень приложений может получить доступ к сервисам системного уровня, например, вызывать другие приложения или записывать данные в объект. Эти системные вызовы аналогичны инструкциям программного прерывания в реальных процессорах (например, ИНТ. инструкция в x86).

Системный уровень

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

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

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

Уровень ядра

Уровень ядра отвечает за две основные функции Radix Engine: доступ к хранилищу и связь между приложениями. Это чем-то похоже на ответственность традиционной операционной системы за доступ к диску и сети.

Для Radix Engine это включает в себя следующее низкоуровневое управление:

• Убедитесь, что семантика перемещения/заимствования сохраняется при любом вызове или записи данных. Правило единственного владельца и правила заимствования применяются ядром. При невыполнении любого из этих правил транзакция будет паниковать.
• Управляйте временными и постоянными объектами. Объект может находиться в глобальном пространстве в любой момент времени или может принадлежать кадру вызова. Ядро поддерживает правильные указатели на эти объекты во время выполнения, поскольку ссылки на эти объекты передаются.
• Управляйте обновлениями состояния транзакций. Ядро отслеживает обновления состояния, которые произошли во время транзакции и которые впоследствии будут зафиксированы в базе данных в конце транзакции.

Закрепленное программное обеспечение

Как эти уровни связаны с закреплением в протоколе DLT? Подобно уровню ядра в операционных системах, эти средние уровни Radix Engine обеспечивают косвенное направление, необходимое для отделения дихотомии абстракции/закрепления от дихотомии программного/аппаратного обеспечения и создания понятия «закрепленного программного обеспечения».

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

Давайте рассмотрим несколько примеров закрепления, которые в настоящее время работают в сети Radix, и посмотрим, как они реализованы.

Закрепленные ресурсы

Основным отличием платформы Radix DeFi/Web3 является идея о том, что ресурс (т. е. актив) является фундаментальным примитивом, который следует понимать отдельно от бизнес-логики. Закрепление этой концепции позволяет всем децентрализованным приложениям, кошелькам и инструментам иметь общее представление о том, как выглядит интерфейс и поведение актива, что значительно упрощает компоновку.

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

• Собственный пакет, который обрабатывает логику объектов ресурсов, таких как Buckets, Vaults и Proofs.

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

  
  

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

Закрепленные разрешения и роялти

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

Модульность отделения бизнес-логики от системной логики также обеспечивает удобные параметры разработки/отладки, такие как возможность предварительного просмотра транзакции без обычных проверок аутентификации (хотите смоделировать результат отправки куда-то 10 миллионов долларов США? При отключенной авторизации ваша транзакция предварительного просмотра может займись чеканкой!).

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

• Собственные пакеты аутентификации и роялти, которые позволяют уровню приложения получать доступ к аутентификации/роялти любого объекта (например, для получения правила аутентификации для доступа к методу или для требования роялти).

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

  
  

  
  

Закрепленная транзакция

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

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

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

С другой стороны, Radix Engine использует традиционный шаблон ОС и закрепляет язык приложений (похожий на язык сценариев терминала, такой как bash) для вызова и составления системных вызовов в одной транзакции.

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

Закрепленный BLS

Подписи BLS являются важным криптопримитивом, поскольку они допускают возможность пороговых подписей. К сожалению, выполнение такой логики в WASM быстро расходует максимальную единицу стоимости. В недавнем обновлении Anemone мы закрепили BLS, запустив его в исходном виде, и обнаружили 500-кратный прирост производительности по сравнению с WASM.

Поскольку логика BLS не имеет состояния, ее можно легко добавить в качестве дополнительной предварительной компиляции к виртуальной машине Scrypto WASM.

Заключение

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

Используя модель операционной системы в качестве вдохновения, Radix Engine решает эту проблему, добавляя уровень косвенности между «программным обеспечением» и «аппаратным обеспечением». Это позволяет Radix Engine выражать понятие «закрепленного программного обеспечения» и позволяет протоколу легко добавлять, изменять и выражать новые встроенные системы без принятия компромиссных решений с высокими ставками.

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

DeFi не станет исключением. По мере роста спроса на более быструю, безопасную и более удобную платформу DeFi, за этим последует более широкое внедрение. Radix Engine был разработан с учетом этого и обеспечивает масштабируемую и безопасную структуру, необходимую для расширения внедрения в будущем.