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

Свежая жалоба со свежим примером

В посте на форуме от 9 ноября разработчик ValarDragon включил удаление обновлений consensus branch ID в число семи целей NU8 — следующего обновления — с заявленной целью покончить с практикой «ломать кошельки при каждом NU».

У жалобы есть свежий пример. NU7 активировалось на прошлой неделе на блоке 3 543 405, не затронув формат транзакций, и, как отметил участник форума strahncryptography в той же ветке, каждому кошельку всё равно понадобился новый релиз или новая прошивка, прежде чем можно было снова тратить средства. Все, кто использовал изолированный от сети телефон или неподдерживаемое устройство, оказались заблокированы.

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

Что именно ломается

Каждая подпись Zcash привязывается к consensus branch ID — метке действующего набора правил. ZIP 200, один из предложений по улучшению Zcash (ZIP), описывающих правила протокола, ввёл его для того, чтобы транзакция, подписанная для одной цепочки, не могла быть повторена (replay) на форке с общей историей. Когда обновление активируется, ID меняется, и всё, подписанное под старым, оказывается недействительным.

ZIP развёртывания NU7 прямо оговаривает это для только что состоявшегося обновления: транзакции версий 5 и 6 сохранили структуру, но транзакция всё равно не действительна через активацию, поскольку её подписи привязаны к branch ID. Сохранённые и подписанные офлайн транзакции, добавляется в документе, требуют тех же проверок активации, что и обычные.

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

Хранилище, которое не успевает подписать

Даниэль Горгонья (Daniel Gorgonha), разработчик хранилища Konclave формата t-of-n в Deega Labs, позже в ветке описал практические издержки. Konclave сначала формирует транзакцию, а затем собирает пороговые подписи, поэтому каждый требуемый подписант должен действовать в пределах окна истечения срока транзакции — примерно 50 минут. Обновление, приходящееся на середину этого окна, обнуляет всё.

Цифра в 50 минут берётся из ZIP 203, который удерживал срок истечения по умолчанию примерно на этом уровне через три изменения времени блока. С NU7 это означает 120 блоков при целевом интервале в 25 секунд. Это значение кошелька по умолчанию, настраиваемое на каждом узле, а транзакцию можно построить вовсе без срока истечения, установив поле в ноль.

Так что проблему времени уже можно решить — по крайней мере там, где кошелёк открывает доступ к настройке. Граница обновления — нет. Хранилище могло бы дать своим участникам неделю на подписание и всё равно потерять транзакцию в момент смены branch ID. Горгонья запросил возможность отказа, которую только что предложил nuttycom, чтобы группа могла собирать подписи часами или днями на свой собственный риск.

Три пути выхода, каждый с подвохом

Удалить привязку к branch ID. Это первоначальное предложение ValarDragon. Инженер Electric Coin Company (ECC) str4d ответил, что защита от повторов была жёстким требованием со стороны бирж и других участников экосистемы, когда писался ZIP 200, поэтому любое удаление требует заменяющего механизма — в идеале такого, который покрывает и враждебные форки, созданные исключительно для нарушения главной цепочки.

Сохранить по умолчанию, дать пользователям отказаться. nuttycom, также из ECC, предложил варианты подписания в рамках ZIP 248, которые пропускают и branch ID, и высоту истечения срока. Выбравшие их пользователи отказываются от части защиты от повторов и получают транзакции, переживающие обновление. Существующий алгоритм, который, по словам nuttycom, отлично работает для подавляющего большинства транзакций, останется безопасным значением по умолчанию. str4d уже отмечал, что такой вариант будет легко определить, как только ZIP 248 станет активным.

Усомниться, решает ли это хоть что-то для кошельков. strahncryptography утверждал, что варианты устраняют проблему долговечности транзакций, но не устаревания: если branch ID не зашит в код, пользователь должен указать правильный сам, что возвращает ту же нагрузку на программное обеспечение кошелька. Защита от повторов на дружественных форках имеет ценность, написал он, но выгоды следует взвесить.

Ветка не разрешила разногласия. Она лишь сузила вопрос: стоит ли создавать вариант с opting-in для тех пользователей, которым он нужен, и от чего эти пользователи отказались бы.

Во что обойдётся отказ

Риск повтора проще всего представить на примере только что произошедшего обновления. Только для NU7 ZIP 259 отменил обычное требование, чтобы старое узловое ПО само себя устарело до активации: операторы, никогда не обновлявшиеся, могут оставаться онлайн и продолжать следовать ветке до NU7. Транзакция, чья подпись не привязана к конкретной ветке, — именно тот случай, который может быть принят обеими.

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

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

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

Долгоживущая подпись не обновляет старое устройство

ZIP 248 — расширяемый формат транзакций, от которого зависит всё это, — всё ещё черновик. str4d сказал, что его дизайн стабилен уже более полугода и что он провёл прошлую неделю, обновляя его для развёрнутых с тех пор изменений консенсуса. Он не был назначен ни на какое обновление, и вариантов с отказом в нём пока нет.

Даже когда они появятся, аппаратному кошельку или офлайн-подписанту всё равно понадобится ПО, понимающее новый формат. ZIP 248 запрещает кошелькам конструировать или подписывать компоненты, которые они не могут разобрать. Польза для совместимости реальна, но приходит она через релизы кошельков — тот шаг, который, по словам strahncryptography, постоянно сбоит.

И ничто из этого не помогает транзакциям в устаревшем формате. ZIP 259 отмечает, что запрет транзакций версии 4 в NU7 покрывает прозрачные и Sapling-расходы, а также Sprout, и что повторное подписание не может их спасти; единственное решение — перестроить платёж в поддерживаемой версии. Coindoo на прошлой неделе описал более сложный случай — монеты Sprout, для которых вообще нет замещающего формата.

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

Практические рекомендации

Если вы управляете групповым кошельком:

• Активация — это высота блока, а не дата; ZIP развёртывания для каждого обновления публикует её заранее.
• Не открывайте раунд подписания, который может пересечь эту высоту.
• Всё подготовленное до активации придётся перестроить после неё, даже если никто ещё не подписал.

Если вы храните монеты на старом устройстве:

• Прежде чем тратить, проверьте, добавила ли его прошивка или приложение поддержку NU7.
• Застрявший расход из поддерживаемого пула — проблема кошелька, а не потерянные средства.
• Транзакции версии 4, сохранённые до 6 ноября, не могут быть повторно подписаны в действительность.

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

Что дальше

Конец января — цель ValarDragon, а не утверждённый график. str4d в той же ветке усомнился, достаточно ли двух с половиной месяцев для пула Tachyon из того же списка, и пункт о branch ID встретил самое резкое сопротивление из всех семи. Выйдет ли NU8 с возможностью отказа, заменой защиты от повторов или без того и другого — решится в процессе ZIP, а не на форуме.