Главная / Следующие шаги для перехода Zcash на PoS

Следующие шаги для перехода Zcash на PoS

20 июля, 2023

Все новости про Zcash в социальной сети «X» (бывший Twitter) | Интересные видео про Zcash на YouTube

Переведено из блога Electric Coin Company | автор Nathan Wilcox I 19 июля 2023

Автор перевода и примечений ruzcash

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

В Electric Coin Co. (ECC) мы изучаем возможность перехода в Zcash от текущего консенсуса Proof-of-Work (PoW) к консенсусу Proof-of-Stake (PoS). Мы предлагаем рассмотреть шаг на этом пути, который мы называем Trailing Finality Layer (TFL) — (Примечание ruzcash — этот технический термин можно перевести как «Слой окончательной обработки»). В случае его внедрения он будет объединён с существующим консенсусом Zcash, а результирующий протокол консенсуса в этот момент будет представлять собой гибрид PoW и PoS.

Общая цель состоит в том, чтобы обеспечить завершенность и PoS в Zcash с минимальными нарушениями. Завершенность — это гарантия того, что после завершения работы блока этот блок и содержащиеся в нём транзакции не могут быть отменены. Завершенность может сократить задержки в некоторых случаях (например, время ожидания депозита на централизованной бирже) и обеспечить новые усовершенствования, такие как более безопасные межцепочечные мосты.

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

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

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

Примите участие

Если вы заинтересованы в обратной связи или сотрудничестве по этому проекту, пожалуйста, свяжитесь с нами! Хорошая возможность узнать больше и присоединиться к обсуждению — это посетить (лично или виртуально) семинар по интерактивному дизайну завершающего слоя Zcash, который я провожу на Zcon4. Также не стесняйтесь написать мне по адресу nathan@electriccoin.co о своей заинтересованности. Нам нужны участники из самых разных областей, включая технические, продуктовые, общественные, а также все пользователи Zcash, которые захотят принять участие в разработке предложения.

Предыстория перехода на PoS

ECC ранее в блоге поделилась нашим обоснованием того, почему мы считаем, что в наилучших интересах нынешних и будущих пользователей ZEC перевести протокол на Proof-of-Stake в блоге «Стоит ли Zcash переходить с Proof of Work на Proof of Stake?». Также была видео-презентация на ZCON3: Мотивация перехода на PoS — Зуко Уилкокс.

В 2022 году мы опубликовали общий обзор нашего подхода к исследованию Proof-of-Stake, более подробную статью о подходе, фокусе и дальнейших шагах, а также выступили с презентацией Zcon3, посвященной основным проблемам проектирования Proof of Stake.

Примечание ruzcash: некоторые аргументы и контр-аргументы я писал в собственной статье. Замечу, что по некоторым пунктам моё мнение трансформировалось, но кому интересно — загляните: Что известно о переходе zcash на pos и опрос держателей ZEC. Там есть подробности некоторых точек зрения из ветки форума сообщества.

Путь перехода к Proof of Stake

Этот подход к переходу от PoW к hybrid к PoS был реализован Ethereum с развертыванием цепочки маяков (hybrid), а затем слиянием (pure PoS).

Наше видение перехода к Proof-of-Stake включает в себя как минимум два основных этапа:

Переход Zcash от текущей модели proof-of-work к гибридной системе PoW/PoS.
Переход Zcash от гибридной системы PoW/PoS к чистому PoS.

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

Такой подход к переходу от PoW к гибридной системе к PoS был реализован в Ethereum с развертыванием Beacon Chain (гибридная система), а затем The Merge (чистый PoS).

Цели проектирования гибридной системы PoW/PoS

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

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

В двух словах о слое Trailing Finality Layer

Гибридный протокол PoW/PoS, который мы предполагаем реализовать в ECC, по своей структуре напоминает современный протокол Zcash NU5 с новым слоем Trailing Finality Layer. Мы называем его слоем, поскольку существующие узлы и большая часть их логики будут продолжать работать в прежнем режиме с минимальными изменениями, в то время как большая часть новой функциональности будет обеспечиваться новыми, дополнительными компонентами и сетевыми протоколами.

На левом рисунке показана текущая сеть Zcash с деталью, иллюстрирующей, как два узла связаны друг с другом в контексте всей сети. Справа показано добавление TFL после развертывания: каждый узел продолжает иметь свой первоначальный компонент PoW, но теперь имеет дополнительный компонент TFL. Компоненты PoW, как и раньше, соединяются друг с другом, а компоненты TFL используют отдельные соединения с другими компонентами TFL.

Этот новый уровень обеспечивает блокчейну гарантию завершенности: после того как блоки добыты, они могут быть завершены, то есть не могут быть отозваны. Эта гарантия распространяется на все транзакции внутри блоков. Она является трейлинговой, поскольку это свойство завершённости следует за системой PoW-майнинга «позади неё».

Поскольку этот гибридный протокол полностью полагается на PoW при производстве новых блоков, он устойчив к остановкам, как Биткойн или нынешний Zcash, хотя гарантия окончательности может дать сбой, о чем мы расскажем далее. Эта парадигма дизайна имеет как теоретический, так и практический опыт: она анализируется в научной статье «Ebb-and-Flow Protocols» («Протоколы приливов и отливов»), и именно эта парадигма используется в Ethereum как в гибридном дизайне цепочки Beacon до Merge, так и в текущем Ethereum.

Почему завершённость имеет значение

PoW-консенсус Накамото, появившийся в Bitcoin и унаследованный Zcash, обеспечивает вероятностную завершенность. Это означает, что вероятность того, что блок может быть отменен, снижается по мере того, как добывается все больше блоков.

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

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

Пример: мост с пониженным уровнем доверия

Чтобы донести эту мысль до читателя, рассмотрим ценный пример использования моста с пониженным уровнем доверия: ZEC, отправленные в мост, должны быть заблокированы, пока в другой сети выпускается эквивалентное количество прокси-токенов.

Если откат возвращает депозит в мост после того, как прокси-токены были выпущены в другом месте, то эти ZEC больше не заблокированы в мосте, а прокси-токены теперь не обеспечены. Это нарушает привязку моста, и многие пользователи моста одновременно потеряют средства. Если разработчики моста решат потребовать достаточное количество блоков PoW, чтобы сделать вероятность этого события астрономически малой, то выпуск прокси-токенов в другой сети будет происходить с чрезвычайно большой задержкой.

Пример: биржевые депозиты

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

Биржи пытаются решить эту проблему, требуя большего количества блоков PoW для достижения достаточно низкой вероятности этого события. Однако здесь необходимо соблюдать баланс: Если биржа вводит задержку на n-блоков, вероятность всё равно не является «астрономически малой», поэтому пользователи испытывают неудобства в течение n-блоков, а биржа по-прежнему несёт практический риск возникновения события «нависания» обязательств.

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

Завершенность

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

Пояснение (нажать)

В негибридном протоколе PoS с финализацией эквивалентные "остановки" на самом деле являются остановками всей сети. А сильной стороной гибридной конструкции является то, что PoW не обязательно должен останавливаться, а если он не останавливается, то пользователи, не зависящие от окончательности, могут продолжать пользоваться сетью.

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

Завершенность в той или иной степени решает все три проблемы:

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

В приведенных выше примерах:

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

В итоге для пользователей некоторые важные операции (такие, как обмен активов или пополнение депозитов) теперь будут проходить быстрее и безопаснее в большинстве случаев. Иногда окончательная обработка может приостанавливаться. Когда финализация возобновится, она «догонит» цепь PoW, поэтому пользователи, которым не нужна гарантия завершённости, смогут продолжать использовать этот гибридный протокол, как они используют Zcash сегодня, и не пострадают, если финализация остановится.

Текущее состояние и нерешенные вопросы

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

Неполный перечень вопросов, которые еще предстоит решить, включает в себя:

Приемлем ли в целом такой подход для сообщества Zcash?
Как будет распределяться новая эмиссия ZEC между PoW, PoS и потенциальным преемником фонда разработчиков? Это, пожалуй ключевой вопросы как для майнеров, так и для потенциальных стейкеров или делегаторов.
- Как мы можем интегрировать любые другие изменения в механике эмиссии, такие как Фонд устойчивого развития Zcash?
Все механизмы учёта, необходимые для PoS, например, как работает бондинг (привязка), как работает делегирование, какие виды слэшинга могут иметь место, задержки и механика вывода средств и т.д.
Как операции с PoS будут взаимодействовать со всеми остальными операциями с электронной книгой Zcash, такими как экранированные пулы и т.д.? Это будет ключевым моментом для понимания того, как взаимодействуют конфиденциальность и стейкинг.
Должна ли вершина цепи когда-либо останавливаться, чтобы сокращать разрывы между завершённым блоком и вершиной цепи?
Подробный анализ безопасности, включая экономическую безопасность, анализ случаев захвата PoW, захвата PoS, сетевой безопасности (особенно с учётом двух отдельных сетевых протоколов/слоёв).
Как мы можем гарантировать, что мобильные экранированные кошельки являются полноценными участниками? Например, можем ли мы гарантировать, что они смогут безопасно и эффективно делегировать долю и управлять позициями делегирования доли? Сюда относятся как вопросы UX, например, потоки пользовательского интерфейса делегирования, так и вопросы реализации, например, изменения протокола lightwalletd.
Как безопасно и своевременно интегрировать любые изменения протокола TFL с другими предлагаемыми изменениями протокола, например: Фонд устойчивого развития Zcash, з ащищенные активы Zcash, усилия по созданию мостов и интеграции с Namada и т.д.
Выбор конкретного финализирующего PoS-протокола. В настоящее время мы сосредоточились на использовании Tendermint и ABCI в качестве способа быстрого создания прототипов и проверки дизайна.
Прототипы, тестовые сети, архитектура кода и т.д.

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

Следующие шаги

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

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

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

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