Глоссарий / Протокол и обновления
Пакетная проверка
- Что такое пакетная проверка?
- Пакетная проверка проверяет множество подписей Schnorr в одном уравнении эллиптической кривой вместо проверки по одной и возвращает один общий результат: успех или неудачу для всего набора.
Определено в BIP-340.
Верификатор объединяет u подписей, умножает все, кроме первой, на случайный скаляр и решает набор одним уравнением вместо u. BIP-340 был создан для этого и закрепил размер подписей в 64 байта, тогда как стандартизированный ECDSA вообще не поддается пакетной проверке, если не добавлены дополнительные данные свидетеля. Пакетирование является выбором каждого верификатора, поэтому оно меняет то, как быстро узел проверяет историю, и ничего не меняет в ваших биткоинах.
Как это работает
Пакетная проверка описана в BIP-340 как BatchVerify: она принимает u публичных ключей по 32 байта, u сообщений и u подписей по 64 байта и дает один ответ для всех них.
Сначала идут веса. Верификатор детерминированно генерирует u-1 целых чисел в диапазоне от 1 до n-1, где n является порядком кривой, из генератора, инициализированного хешем всех входных данных пакета: ключей, сообщений и подписей в равной мере. BIP-340 называет SHA256 безопасным хешем для инициализации, а ChaCha20 безопасным способом растянуть его в 256-битные целые числа, пропуская те, что выходят за пределы диапазона.
Затем пакет сводится к одной проверке: взвешенная сумма значений s, умноженная на порождающую точку, должна быть равна результату применения тех же весов к точкам R и к вызову каждой подписи, умноженному на ее собственный публичный ключ. Эти u отдельных проверок превращаются в одно сравнение, которому BIP-340 приписывает значительное ускорение.
Такое ускорение оплачивается ценой на каждую подпись. BatchVerify поднимает каждое значение r обратно на кривую, чего одиночная проверка никогда не делает: Verify пересчитывает R из s и вызова, а затем проверяет только, что его координата x равна r.
Гарантия намеренно асимметрична. Если все подписи в пакете действительны, BatchVerify всегда завершается успешно; если недействительна хотя бы одна, она завершается успешно с пренебрежимо малой вероятностью. Виновника она при этом не называет, поэтому верификатор, которому нужно знать, какая подпись недействительна, проверяет их по одной.
Где это видно
Пакетная проверка существует целиком на стороне верификатора в сети, поэтому она никогда не появляется в интерфейсе кошелька или в оценке комиссии.
Она окупается у узла, который обрабатывает сразу несколько лет трат Taproot, а не у кошелька, отправляющего платеж. BIP-340 нигде не предписывает пакетирование: определение задает проверка одной подписи, а пакет является тем, что верификатор может выбрать. BIP требует алгоритма, описанного на уровне байтов, той точности, которой не хватало разбору DER до BIP-66, чтобы никто не мог построить подпись, действительную для одних верификаторов и недействительную для других. Поскольку верификатор выбирает собственные пакеты, именно это свойство обеспечивает то, что пакетная и одиночная проверка могут различаться лишь с пренебрежимо малой вероятностью, даже против злоумышленника, пытающегося заставить их разойтись.
Пакетирование также объясняет решения внутри BIP-340, которые в отдельности выглядят произвольными. Подписи могли бы принять более короткую форму, в которой для целевого уровня безопасности в 128 бит достаточно хеша в 16 байт, и BIP от нее отказался: короткие хеши хрупки, когда вместе работают не доверяющие друг другу подписанты, а более длинная форма, несущая R, является той, что поддерживает пакетирование. Публичные ключи занимают 32 байта вместо обычных для биткоина 33 байт сжатого кодирования, что выбрано ради компактности, а координата y, которая при этом опускается, закреплена как четная, а не оставлена неоднозначной, потому что и эффективная проверка, и пакетирование нуждаются в ее однозначности.
ECDSA не получает ничего из этого. BIP-340 приводит это как одну из причин сменить схему подписей: стандартизированную формулировку нельзя проверять пакетно эффективнее, чем по отдельности, если не добавлены дополнительные данные свидетеля.
Пакетная проверка vs MuSig2
Пакетная проверка и MuSig2 обе удешевляют множество подписей, но только MuSig2 меняет то, что передается в сеть.
MuSig2 объединяет нескольких подписантов в один ключ и одну обычную подпись в 64 байта до того, как транзакция дойдет до сети, поэтому его выигрыш состоит в конфиденциальности и месте в блоке, и он действует по схеме n из n: каждый подписант должен участвовать. Пакетная проверка оставляет каждую подпись на месте и перестраивает только арифметику, которую выполняет валидатор, без чьего-либо участия и даже ведома: узел может пакетно проверять подписи, сделанные незнакомцами с разницей в годы, в несвязанных транзакциях.