Первоисточник: материал Shielded Labs | Перевод и адаптация: ruzcash
Прошло немногим больше шести недель с запуска испытательной сети Crosslink с вознаграждениями. Участники могут подключаться к ней как майнеры или финализаторы, вносить ZEC в стейкинг и получать выплаты. Мы хотим рассказать, как развивается сеть, с какими проблемами мы столкнулись, что узнали и над чем сейчас работаем.
Как и ожидалось на этом этапе, сеть ещё находится на ранней стадии, а программное обеспечение требует доработки. В разных версиях сети участники сталкивались со сбоями, проблемами синхронизации, остановкой финализации и другими ошибками. Особенно часто они затрагивали создание блоков, синхронизацию и восстановление сети. Некоторых участников это закономерно расстраивало. Другие помогали искать причины неполадок, координировать восстановление и разбираться в поведении системы на практике. Благодаря этому испытательная сеть уже дала полезные сведения о работе в реальных условиях, и достигнутый прогресс нас обнадёживает.
Мы стараемся по возможности устранять проблемы в работающей сети, а не перезапускать её после каждого крупного сбоя и испытывать только в идеальных условиях. Отказы, простои и сложности координации как раз относятся к ситуациям, которые должна выдерживать основная сеть. Работа с ними сейчас в итоге сделает систему надёжнее.
Остановка финализации BFT
Главная текущая проблема сети состоит в остановке слоя окончательной фиксации блоков. Такие остановки являются одной из самых спорных особенностей систем византийской отказоустойчивости (BFT). Если протокол больше не может безопасно достичь согласия, он прекращает окончательную фиксацию, чтобы не допустить отката транзакций. Так безопасность получает приоритет над доступностью. В применяемом Zcash доказательстве работы Накамото (PoW) выбран противоположный компромисс. Оно поддерживает доступность и продолжает создавать блоки даже в неблагоприятных условиях, но допускает откат транзакций при перестроении цепочки. Проще говоря, при ухудшении условий PoW чаще приводит к откатам, а BFT чаще останавливает финализацию.
В Crosslink остановка BFT прекращает окончательную фиксацию, однако PoW продолжает создавать блоки. Такое возможно, если из сети одновременно выходит значительная доля стейкинга. Пока неясно, восстановится ли сеть сама после возвращения финализаторов или участники сочтут необходимыми согласованные действия.
Разработчикам нередко хочется просто перезапустить сеть после сложного сбоя, как перезагружают неисправный компьютер. Однако остановки относятся к известному и ожидаемому поведению систем BFT, а испытательная сеть должна выявлять сложности эксплуатации в реальных условиях. Поэтому полезнее разобраться в таких ситуациях и научиться выходить из них. Мы повышаем надёжность программного обеспечения и улучшаем средства анализа, наблюдения и диагностики. В конечном счёте участники должны самостоятельно уметь обнаруживать и разбирать подобные события, согласовывать действия и восстанавливать сеть. Это сделает возможное будущее внедрение устойчивее.
Недавно мы выпустили новые средства наглядного представления и диагностики, которые показывают работу финализаторов и состояние сети. По недавней активности голосования можно определить, какие финализаторы находятся в сети, увидеть общую долю активного и отключённого стейкинга, проверить состояние отдельного финализатора и лучше понять положение сети BFT. В последних обновлениях также появились дополнительные фильтры и отображение прямых соединений финализаторов. Это стало возможным после улучшения одноранговой топологии сети.
Одна из главных целей этой работы состоит в том, чтобы предоставить участникам сведения для самостоятельных обоснованных решений, а не заставлять их полагаться на указания Shielded Labs. В основе архитектуры Crosslink лежит разделение обязанностей между участниками системы:
- Кошельки защищают пользователей.
- Майнеры включают транзакции в блоки и создают блоки.
- Финализаторы обеспечивают окончательность блоков.
- Участники стейкинга выбирают надёжных финализаторов.
- Пользователи штрафуют участников стейкинга, если те не выполняют свои обязанности.
Для этого мы разрабатываем средства восстановления. Они могут позволить пользователям согласовать экстренное обновление сети, если широкое сообщество решит, что оно необходимо. В том числе рассматриваются способы общественным решением сократить залог, делегированный финализаторам, которые долго не работают. Испытательная сеть и должна выявлять такие сложности эксплуатации и координации до обсуждения внедрения в основной сети.
Что дальше
Первоначально мы планировали развивать испытательную сеть с вознаграждениями по серии «сезонов». Каждый новый сезон фактически становился бы новой сетью с обновлённым программным обеспечением, новой историей консенсуса и дополнительными возможностями. Участники могли бы продолжать получать вознаграждения, переносить идентификаторы финализаторов и постепенно переходить во всё более зрелые сети.
После первых испытаний мы решили отказаться от регулярных перезапусков сети и запуска новых сезонов по заранее установленному расписанию. Как уже говорилось, работа со сбоями и восстановлением в действующей сети приносит больше пользы, чем постоянные сбросы и запуск с нуля. В ближайшее время этот подход может быть медленнее и сложнее, но он укрепит сеть и поможет намного лучше понять её поведение в реальных условиях.
Теперь мы будем развивать существующую сеть регулярными обновлениями программного обеспечения. Они повысят стабильность, исправят ошибки, расширят набор инструментов и постепенно добавят более зрелые возможности. Перезапуск состоится только тогда, когда он действительно потребуется для разработки[1]. По мере работы мы продолжим сообщать о состоянии сети, крупных проблемах, новых инструментах и изменениях в испытательной сети.
Распределение вознаграждений
Вместо привязки выплат к отдельным «сезонам» вознаграждения будут распределяться каждые шесть недель. Перед началом каждого периода мы объявим, сколько ZEC выделено на эти шесть недель.
Вскоре мы также опишем порядок выплат за первые шесть недель. Поскольку это первый период распределения, выплаты могут немного задержаться, пока мы завершаем подготовку инструментов и рабочих процедур. Сейчас планируется, что участник предоставит ключ просмотра кошелька испытательной сети и адрес Orchard в основной сети, на который следует отправить вознаграждение. Как и было указано изначально, сумма будет зависеть от cTAZ, заработанных майнингом и стейкингом за расчётный период, а не от общего остатка cTAZ.
У участников будет ограниченный срок для предоставления данных и получения выплат. Невостребованные ZEC после его окончания могут направить на дополнительные вознаграждения тем, кто особенно много помогал в испытаниях, поиске ошибок, подготовке отчётов и улучшении сети. Как уже сообщалось, Shielded Labs не будет получать вознаграждения в ZEC из испытательной сети.
Заключение
Мы благодарим всех, кто продолжал участвовать, несмотря на нестабильность и неизбежные сложности испытания программного обеспечения на этой стадии. Отзывы, сбои и редкие пограничные случаи, выявленные за первые шесть недель, уже заметно улучшили наше понимание системы и помогут определить следующий этап разработки.
Несмотря на сложности, многие участники продолжали оставлять полезные отзывы, проверять необычные случаи, сообщать об ошибках, создавать инструменты и помогать развитию сети. Особенно благодарим @zk_nd3r и @kenbak за постоянное участие, создание обозревателей блоков и вклад в важную инфраструктуру. Мы также отмечаем @dismad, @pacu, Orchard Guardian и Тома Зи за полезные отзывы и вклад на протяжении первых шести недель.
Мы понимаем, что текущее состояние сети иногда делает участие сложным и утомительным. На таком раннем этапе никто не обязан участвовать постоянно. Можно сделать перерыв и вернуться, когда сеть станет стабильнее и зрелее. По мере развития сети и инструментов объём ZEC для вознаграждений, как ожидается, будет расти. Мы также предполагаем, что сеть продолжит работать долго, вероятно, до конца 2026 года и в 2027 году. Примерно раз в шесть недель будут проходить практические занятия и встречи сообщества, поэтому возможностей присоединиться останется много.
Сноски
[1] Хотя мы отказываемся от плановых сезонных перезапусков, сеть всё ещё могут перезапустить, если это позволит упростить код или внести важные изменения в устройство системы, несовместимые с прежней версией. На этом этапе обратная совместимость не является основной целью, но по мере приближения к готовности основной сети её значение будет возрастать.
Zodl 3.5.0: голосование с помощью ZEC 
Комментировать статью