28 июня Tezos перейдет на обновление протокола Jakarta со встроенным L2-решением Transaction Optimistic Rollups. Пока что L2 поддерживает только транзакции tez, но все изменится с внедрением обновления Kathmandu.
23 июня Nomadic Labs опубликовала информацию о следующем обновлении Tezos — Kathmandu. В него вошли Smart Contract Optimistic Rollups (SCORUs), ускорение валидации блоков, интеграция функции проверяемой задержки и перманентный тестнет — Ghostnet. Рассказываем простым языком обо всех нововведениях.
SCORUs — L2 с поддержкой сторонних виртуальных машин
Ранее мы разбирали как работают Optimistic Rollups. Если коротко: пользователи отправляют токены в хранилище и получают их репрезентацию на L2. Роллап-операторы регулярно подводят итоги операций на L2 и публикуют их в L1. В результате:
- уменьшается нагрузка на узлы бейкеров;
- увеличивается максимальная пропускная способность Tezos;
- пользователям становится выгоднее работать с DeFi, потому что транзакционные комиссии на L2 будут в десять раз меньше, чем на L1.
Вот-вот Tezos активирует Jakarta и TORUs — роллапы для транзакций tez. А в Kathmandu будут SCORUs — роллапы с поддержкой выполнения смарт-контрактов.
Главная фича реализации SCORUs в Tezos — возможность имплементировать любое вычислительное устройство, если его семантику можно описать как способную производить криптографические доказательства виртуальную машину (Proof-producing Virtual Machine или PVM).
Если по-простому, то в L2 Tezos в теории можно будет внедрить хоть виртуальную машину Ethereum (EVM), хоть Java.
Core-разработчики в качестве доказательства концепта планируют запустить в тестнете стековую PVM с поддержкой инструкций на языке WebAssembly (Wasm). Сам Wasm поддерживает компиляцию с C++, Rust, Go, TypeScript и других высокоуровневых языков.
Особенность внедрения SCORUs — они появятся в мейннете через полгода, а может быть и позже. Разработчики Tezos ранее жаловались на слишком быстрое внедрение в протокол новых фич: они не успевали их опробовать и использовать в приложениях. Например, тикеты появились больше года назад, но сообщество все еще не выработало для них стандарты. Поэтому SCORUs в ближайшие шесть месяцев будет доступен только в тестнетах Mondaynet и Dailynet, чтобы у разработчиков было больше времени на эксперименты и поиск багов.
Validation Pipelining Project — ускорение работы с блоками
При валидации блока валидатор по очереди проверяет валидность каждой операции и затем их применяет (выполняет). Проверка валидности и применение происходят по очереди, при этом в операции может быть несколько таких проверок. В конце валидатор проверяет валидность финального состояния (state), признает блок валидным и распространяет его по сети.
Процесс можно сделать эффективнее, если разделить валидацию и применение операций. В таком случае валидатор сначала проверит валидность всех операций, потом начнет распространять блок и только затем применит все операции. В результате пропускная способность Tezos вырастет.
В Kathmandu будет реализована только первая часть проекта — разделение валидации и применения операций на разные модули. В следующем обновлении протокола разработчики адаптируют мемпул сети к работе с модулями. Узнайте больше в документации Nomadic Labs.
Verifiable Delay Function — улучшенная случайность
Tezos выбирает бейкера для создания следующего блока с помощью протокола, похожего на RANDAO. Бейкеры публикуют случайные числа, протокол хеширует их вместе с хешем предыдущего результата и сохраняет результат — зерно или энтропию. В начале каждого цикла сеть использует текущее зерно для генерации псевдослучайных чисел, которые и определяют счастливых бейкеров.
Этот способ работает, пока хоть один бейкер публикует действительно случайное число и не пытается подкрутить генератор псевдослучайных чисел в свою пользу.
В Kathmandu все также используется RANDAO, только возможно неслучайное зерно используется в качестве задачи для функции с проверяемой задержкой (VDF), чтобы сгенерировать действительно случайное зерно. Это решение повышает безопасность Детальнее — на Tezos Gitlab.
Event Logging — для работы с внешними приложениями
Новая фича для мостов и других приложений, у которых есть оффчейн-часть. Логи событий позволят контрактам создавать ончейн-сообщения, которые могут быстро прочесть внешние приложения. При этом инструкция публикации события — EMIT — не вызывает внешние контракты и за счет этого экономит газ.
Кроме инструкции EMIT для работы с логами событий появились специальные адреса ev1… и несколько команд. Узнайте больше в документации Event Logging.
Ghostnet — долгоживущий тестнет
G.-B. Fefe предложил сделать тестнет, который будет постоянно обновляться до новейшей версии протокола. Для этого создатель тестнета назначает специальный адрес, который может принудительно обновить всю сеть до новой версии. Такую сеть назвали Ghostnet.
Ghostnet — отличное нововведение для разработчиков, которые только-только перешли на Tezos и еще не разобрались с принципами названия сетей. Многие участники нашего хакатона публиковали контракты в Hangzhounet, который больше не поддерживается. Кроме того, при переходе на новый тестнет разработчикам приходится заново получать адрес и публиковать необходимые контракты. Приятно, что от этой рутины получилось избавиться.
Подписывайтесь на социальные сети Tezos Ukraine, чтобы ничего не пропустить:
- Telegram-канал
- Facebook.
- Twitter на русском и украинском языках
- Twitter на английском языке
- YouTube-канал
- hub на ForkLog
Изначально мы опубликовали этот материал в блоге Tezos Ukraine.