Обновления Zcash – апрель 2026

На основе материалов сообщеста (источники приведены) | Автор: ruzcash

Предстоящие обновления Zodl

Разработчики кошелька Zodl готовят к выпуску релиз 3.4.0. В него войдут оставшиеся доработки для Keystone, включая настройку Wallet Birthday Height и функцию ресинхронизации. На практике это особенно важно для тех, кто [очет привязать ранее настроенный Keystone Wallet к новому кошельку Zcash в уже установленном приложении Zodl. Сейчас без этих функций аккаунт Keystone может показывать нулевой баланс, потому что ориентируется на высоту создания основного аккаунта Zodl. Также капитан сообщил, что команда уже завершила дизайн интеграций с Maya Protocol и Ledger. 👀

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

Источник: форум сообщества

Hey, this is planned for Zodl Vault.

— Josh Swihart 🛡 (@jswihart) April 17, 2026

• Привет, Джош! Как насчет добавления в приложение Zodl функции «аварийного переключателя», которая будет переводить средства на любой выбранный адрес, если ты не подтвердишь свое существование в течение заданного времени? Представь, сколько держателей ZEC не имеют возможности передать свои монеты своим семьям, если с ними что-то случится. Объяснить им это не так просто, да и к тому же, если они совершат хотя бы одну ошибку при переводе, то потеряют всё.

• Привет, это запланировано для Zodl Vault.

В Zcash устранили несколько уязвимостей в узлах

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

Первое раскрытие было опубликовано 31 марта. Выяснилось, что узлы zcashd в некоторых условиях мог пропускать проверку доказательств для транзакций из Sprout при подключении нового блока. Это создавало риск только для самого Sprout, первого экранированного пула Zcash, который закрыт для новых пополнений ещё с 2020 года и сейчас содержит около 25,4 тысячи ZEC. Zebra этой проблеме не была подвержена. Исправление вошло в zcashd v6.12.0, а основные майнинговые пулы развернули патч ещё до публичного раскрытия.

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

Публичное раскрытие информации от 31 марта.

Второе раскрытие вышло 17 апреля и уже касалось нескольких проблем сразу. Одна из них позволяла специально сформированной Orchard-транзакции аварийно завершать работу нод. Другая создавала расхождение между zcashd и Zebra в проверке некоторых полей транзакции, а ещё одна затрагивала внутреннюю защитную проверку – турникет, которая следит за тем, чтобы движение ZEC между разными пулами оставалось согласованным. Все эти проблемы закрыли в zcashd v6.12.1 и Zebra v4.3.1. До публикации патчи успели получить пулы, представляющие большую часть хешрейта, в том числе новый пул Foundry, использующий Zebra в майнинговой инфраструктуре.

Эта уязвимость не была использована. Все средства пользователей, в том числе средства в пуле Sprout, находятся в безопасности. Не могла быть использована для увеличения общего объема предложения ZEC. Эта уязвимость не могла быть использована для нарушения конфиденциальности пользователей Zcash.

Публичное раскрытие информации от 17 апреля.

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

Zcash cybersecurity defenders never sleep. https://t.co/cwQLlRt6kD

— zooko🛡🦓🦓🦓 ⓩ (@zooko) April 18, 2026

 Специалисты по кибербезопасности Zcash никогда не отдыхают.

Отдельно стоит напомнить, что всё это происходит на фоне постепенного вывода узлов zcashd из центральной роли в экосистеме Zcash. Ещё в 2023 году Zcash Foundation и ECC объявили о переносе основной работы над протоколом с zcashd на Zebra, а сам переход с тех пор стал одним из приоритетов для команд разработки. В планах Zcash Foundation на 2026 год прямо сказано, что после NU7 именно Zebra должна стать единственной консенсусной реализацией узла, а связка Zebra, Zaino и Zallet рассматривается как замена предыдущему-стеку zcashd.

Вышло исследование влияния 25-секундных блоков на работу кошельков

В социальной сети «X» опубликовано исследование о том, как более частый выпуск блоков может повлиять на работу мобильных кошельков и других пользовательских приложений. Речь идёт о предложении сократить интервал между блоками с 75 до 25 секунд. Такое изменение должно ускорить работу сети: новые блоки будут появляться чаще, а кошельки и другие приложения смогут быстрее получать данные о транзакциях. При этом главный технический вопрос здесь был простым: если блоков станет в три раза больше, не начнут ли кошельки работать заметно медленнее.

По итогам тестов автор пришёл к выводу, что само по себе увеличение числа блоков почти не влияет на скорость синхронизации кошелька. Он проверил это на практических тестах, описание которых приведено в исследовании. В качестве примера автор приводит один из замеров, где переход от 48 блоков в час к 144 увеличил время обработки всего на 18 миллисекунд, то есть примерно на 2%. Объяснение в том, что при одинаковой нагрузке решающую роль играет не число блоков само по себе, а общий объём данных, который кошелёк должен обработать.

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

Пожалуйста, оставьте это поле пустым.

Подпишитесь на рассылку!

Никакого спама!
Только новости и видео PRO.ZCASH

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