На этой неделе я разобрался с piecrust, потому что документация постоянно называла это одной вещью — «VM» — и мне хотелось понять, из чего оно реально состоит на уровне компонентов. В whitepaper оно разделено на два
piecrust — сам виртуальный WASM-машина. Она выполняет модули смарт-контрактов в песочнице с модульной средой. В whitepaper описывается, что она построена вокруг переносимости, безопасности и модульности. Она выполняет фактическое исполнение кода контракта и интегрирует стандарты конфиденциальности и криптографии Dusk на уровне исполнения.
piecrust-uplink — набор инструментов, ориентированный на разработчиков. Он помогает в разработке, развертывании и управлении смарт-контрактами. Это прослойка между разработчиком, который пишет код контрактов на Rust, и лежащей в основе VM, которая его выполняет.
Принцип проектирования: в whitepaper явно рассматривается модульность как свойство, обеспечивающее «готовность к будущему». Разделяя VM и инструментарий разработчика, можно обновлять или расширять одну часть, не требуя переработки другой.
VM может улучшить свою модель исполнения; инструментарий может улучшить опыт разработчика — и при этом никого не вынуждают меняться одновременно.
Практический вывод для тех, кто строит (builders): piecrust-uplink — это то, с чем вы взаимодействуете как разработчик.
Понимать, что это toolkit, оборачивающий VM, а не сама VM, особенно важно, когда вы отлаживаете обновления контрактов или думаете о том, что происходит на уровне исполнения, в отличие от уровня интерфейса для разработчика.
Я думаю, что это важнее всего для команд, планирующих долгоживущие развертывания контрактов.
Если модель исполнения piecrust изменится в будущем обновлении протокола, изменится компонент VM, но uplink-инструментарий это скрывает. Это верно только в том случае, если разделение сохранено аккуратно.
Вопрос в том, версионируются ли piecrust и piecrust-uplink независимо, или любое обновление VM требует соответствующего обновления uplink, которое сломает инструменты контрактов для уже существующих развертываний. @Dusk
$DUSK #dusk
piecrust — сам виртуальный WASM-машина. Она выполняет модули смарт-контрактов в песочнице с модульной средой. В whitepaper описывается, что она построена вокруг переносимости, безопасности и модульности. Она выполняет фактическое исполнение кода контракта и интегрирует стандарты конфиденциальности и криптографии Dusk на уровне исполнения.
piecrust-uplink — набор инструментов, ориентированный на разработчиков. Он помогает в разработке, развертывании и управлении смарт-контрактами. Это прослойка между разработчиком, который пишет код контрактов на Rust, и лежащей в основе VM, которая его выполняет.
Принцип проектирования: в whitepaper явно рассматривается модульность как свойство, обеспечивающее «готовность к будущему». Разделяя VM и инструментарий разработчика, можно обновлять или расширять одну часть, не требуя переработки другой.
VM может улучшить свою модель исполнения; инструментарий может улучшить опыт разработчика — и при этом никого не вынуждают меняться одновременно.
Практический вывод для тех, кто строит (builders): piecrust-uplink — это то, с чем вы взаимодействуете как разработчик.
Понимать, что это toolkit, оборачивающий VM, а не сама VM, особенно важно, когда вы отлаживаете обновления контрактов или думаете о том, что происходит на уровне исполнения, в отличие от уровня интерфейса для разработчика.
Я думаю, что это важнее всего для команд, планирующих долгоживущие развертывания контрактов.
Если модель исполнения piecrust изменится в будущем обновлении протокола, изменится компонент VM, но uplink-инструментарий это скрывает. Это верно только в том случае, если разделение сохранено аккуратно.
Вопрос в том, версионируются ли piecrust и piecrust-uplink независимо, или любое обновление VM требует соответствующего обновления uplink, которое сломает инструменты контрактов для уже существующих развертываний. @Dusk
$DUSK #dusk