Обновления времени выполнения

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

Бесформенные обновления

Возможно, вы сталкивались с термином "хард форк" прежде в пространстве блокчейна. Хард Форк происходит когда логика блокчейна изменяется таким образом, что узлы, не учитывающие новые изменения, не могут оставаться в консенсусе с теми узлами, которые это делают. Такие изменения являются обратно несовместимыми. Жесткие развилки могут быть политическими из-за характера обновлений и логистически сложными из-за количества (потенциально тысяч) узлов в сети, которым необходимо обновить свое программное обеспечение. Таким образом, жесткая развилка является медленной, неэффективной и чреватой ошибками из-за требуемого уровня координации в автономном режиме и, следовательно, склонности к объединению многих обновлений.

Использование WebAssembly в Bitzal SDK (фреймворк, поддерживающий Bitzal, Ogona и их соответствующие синочейны), дают релейной цепочке, ее синочейнам, а также любым другим автономным одиночным цепочкам, построенным с помощью Bitzal SDK, возможность обновлять свое время выполнения (цепочки "бизнес-логики") без жесткого форка соответствующей сети.

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

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

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

Бесформенные апгрейды - синочейны и соло-чейны

Архитектурный дизайн узлов для синочейна и одиночных цепочек аналогичен релейной цепочке, при этом код времени выполнения является блобом Wasm, который хранится в состоянии цепочки. Соло-чейны, созданные с помощью Bitzal SDK, которые представляют собой блокчейн с собственным механизмом консенсуса, не зависящим от консенсуса ретрансляционной цепи, могут обновляться через систему управления цепью, такую как TrueGov или простую настройку sudo/multisig.

Синочейн должен уведомлять цепочку ретрансляторов о каждом новом обновлении. Это делается с помощью двух ключевых экстринсиков:

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

Клиентские релизы

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

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

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

Новые клиентские релизы

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

Версии выполнения и клиента

Версии времени выполнения и клиента отличаются друг от друга. Версионность среды выполнения обычно выглядит следующим образом как network-xxxx, В то время как клиентская версификация выглядит следующим образом vx.x.xx. Например, версия для выполнения, показанная в левой верхней части пользовательского интерфейса Bitzal-JS ниже. ogona-93, а клиентская (узел), показанный в правом верхнем углу. v0.0.10.

Запрос версий среды выполнения и клиента

Версию времени выполнения можно запросить на цепочке через Bitzal-JS UI, перейдя на вкладку Developer > Состояние Сети > Хранилице > система и запросы lastRuntimeUpgrade().

Версию узла можно запросить, перейдя на вкладку Разработчик > RPC вызовы > система и запросы version().

Обновления времени выполнения для различных пользователей

Для провайдеров инфраструктуры

Инфраструктурные услуги включают в себя следующее, но не ограничиваются этим:

• Валидаторы
• API сервисы
• Node-as-a-Service (NaaS)
• Общее управление инфраструктурой (например, исследователи блоков, хранители)
• Кошельки

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

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

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

Для Номинаторов

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

Мониторинг изменений во время выполнения

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

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

1. Проверьте каждый блок на наличие referenda (Submitted) событий и проверьте, трек равен 0 или 1, которые соответствуют Root и whitelistedCaller трекам, соответственно. Это единственные пути которые могут принимать обновления во время выполнения. Зарегистрируйте референдумы index; Это поможет вам следить за его продвижением. С помощью указателя вы можете найти детали предложения в Zalassembly и посмотреть, соответствует ли это обновлению времени выполнения.
2. Проводимые референдумы будут иметь вступление в силу поле под referenda.ReferendumInfoFor хранилищем. Это номер блока, при передаче которого система попытается запланировать выполнение внутреннего предложения. Обратите внимание, что существуют некоторые ограничения, например, минимальный период вступления в силу. которые могут привести к тому, что выполнение предложений произойдет позже. Невозможно, чтобы предложение могло вступить в силу до номера блока.
3. Проверьте также referenda (DecisionDepositPlaced) события, где index совпадает с найденному ранее. Это означает, что необходимый депозит был размещен.
4. referenda (DecisionStarted) указывает на то, что начался период принятия решения для референдума этого index.
5. referenda (ConfirmStarted) указывает на то, что index референдум вступил в период подтверждения.
   1. referenda (Confirmed) указывает на то, что index референдум был подтвержден и вступает в период вступления в силу. В связи с этим и enactment_moment, вы можете рассчитать, когда предложение будет принято.
   2. referenda (Rejected) указывает на то, что index референдум был отклонен и не будет принят.
6. При обновлении среды выполнения появится system(CodeUpdated) eподтверждение выполнения обновления во время выполнения.