Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 6
Спасибо за статью
Многое разъяснили, однако некоторые вещи так и остались непонятны
Где собственно храниться поле witness?
В стороне от блокчена, на каждой ноде?
Т.е. используя SegWit итоговое количество хранщихся данных не уменьшаеться, но позволяет старым версиям хранить меньше информации в ущерб функциональности?
Так же интересно, что именно из себя представляет «witness data» для траты транзации.
Не ясно за счет чего достигается Signature Verification Optimization.
Многое разъяснили, однако некоторые вещи так и остались непонятны
Где собственно храниться поле witness?
В стороне от блокчена, на каждой ноде?
Т.е. используя SegWit итоговое количество хранщихся данных не уменьшаеться, но позволяет старым версиям хранить меньше информации в ущерб функциональности?
Так же интересно, что именно из себя представляет «witness data» для траты транзации.
Не ясно за счет чего достигается Signature Verification Optimization.
Хорошие вопросы! Итак, по порядку:
1. Поле witness отделяется от транзакции. Вся witness-data хранится в отдельном merkle tree как и транзакции и является частью блока. Также стоит заметить, что witness merkle tree root не включается в заголовок блока — он содержится в выходе coinbase транзакции как дополнительные данные, после OP_RETURN.
2. Количество хранимых данных действительно уменьшается. Подписи нужны только для проведения полной валидации, поэтому, например, для новой ноды, которая только начинает синхронизировать блокчейн, отсутствует необходимость загружать witness данные для старых блоков, так как она не будет проверять их на валидность (проверять будут только некоторое число последних блоков).
1. Поле witness отделяется от транзакции. Вся witness-data хранится в отдельном merkle tree как и транзакции и является частью блока. Также стоит заметить, что witness merkle tree root не включается в заголовок блока — он содержится в выходе coinbase транзакции как дополнительные данные, после OP_RETURN.
2. Количество хранимых данных действительно уменьшается. Подписи нужны только для проведения полной валидации, поэтому, например, для новой ноды, которая только начинает синхронизировать блокчейн, отсутствует необходимость загружать witness данные для старых блоков, так как она не будет проверять их на валидность (проверять будут только некоторое число последних блоков).
В продолжение предыдущего ответа:
3. Witness data для траты транзакции это тот же самый scriptSig (например, signature + public key в случае P2WPKH).
4. На данный момент для каждого входа транзакции проводится следующая процедура:
4.1. Все входы удаляются, это происходит за O(n).
4.2. На место текущего проверяемого входа вставляется subScript (это locking script выхода, который мы тратим).
4.3. Берется двойной SHA-256 хеш и сравнивается с предоставленной подпиьсю при помощи публичного для проверки корректности.
Так как имеем n входов, получаем итоговую сложность в O(n^2), что может вылиться в очень долгое время валидации (транзакция, время валидации которой составляет 25 сек. из-за большого кол-ва входов). Сегвит решает эту проблему изменяя способ хеширования транзакции таким образом, что каждый байт транзакции будет хеширован не более 2ух раз.
3. Witness data для траты транзакции это тот же самый scriptSig (например, signature + public key в случае P2WPKH).
4. На данный момент для каждого входа транзакции проводится следующая процедура:
4.1. Все входы удаляются, это происходит за O(n).
4.2. На место текущего проверяемого входа вставляется subScript (это locking script выхода, который мы тратим).
4.3. Берется двойной SHA-256 хеш и сравнивается с предоставленной подпиьсю при помощи публичного для проверки корректности.
Так как имеем n входов, получаем итоговую сложность в O(n^2), что может вылиться в очень долгое время валидации (транзакция, время валидации которой составляет 25 сек. из-за большого кол-ва входов). Сегвит решает эту проблему изменяя способ хеширования транзакции таким образом, что каждый байт транзакции будет хеширован не более 2ух раз.
> включая ту самую уязвимость, мешающую реализации лайтнинга
Расскажите подробнее, о собственно какой уязвимости идет речь?
Расскажите подробнее, о собственно какой уязвимости идет речь?
Это не только позволяет уменьшить размер транзакций, делая блоки более вместительными
По факту там изменился способ подсчета размера транзакций. В байтах размер может быть даже больше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Segregated Witness для чайников