Что такое native segwit
Segregated Witness для чайников
Масштабируемость биткоина является одной из его главных проблем, над решением которой активно работают. Одним из представителей этих решений является, например, технология Lightning network, но ее реализация пока что не представляется возможной ввиду некоторых уязвимостей. Другое решение — Segregated Witness также направлено на повышение масштабируемости, но ко всему прочему решает еще и целый ряд проблем, включая ту самую уязвимость, мешающую реализации лайтнинга. В этой статье мы рассмотрим основные преимущества Segregated Witness, а также опишем механизм его работы.
Segregated witness, или как многие его называют SegWit, это софт-форк, описанный в серии BIP’ов (141, 142, 143, 144 и 145), главной целью которого является оптимизация структуры транзакций и блоков с помощью вынесения подписей (то, что называют ‘scriptSig‘, ‘witness‘ или же ‘unlocking script‘) из транзакции в отдельную струтуру. Это не только позволяет уменьшить размер транзакций, делая блоки более вместительными, но и решает проблему их «изменяемости» (transaction malleability, именно об этой уязвимости мы и говорили выше), что очень важно для технологий наподобие платежных каналов или лайтнинга, пологающихся на строение транзакции биткоина.
How it works
Before we begin
Для начала кратко напомним, что из себя представляет платежная система в биткоине. В ней нет ничего наподобие списка балансов как это может быть реализовано в каком-нибудь банке. Вместо этого, баланс каждого адреса представлен набором транзакций, отправленных на этот адрес, где транзакция — это структура, в которой главными являются входы (inputs) и выходы (outputs). Входы — это транзакции, на которые мы ссылаемся, чтобы потратить (если точнее то это не транзакции полностью, а их конкретные выходы, т.к в одной транзакции мы можем переводить средства на несколько адресов), а выходы — это адреса, на которые мы хотим перевести средства. Вот так выглядит структура транзакции биткоина:
Поле PubKey script (далее scriptPubKey) в выходах это то, что называют locking script. Оно нужно для того, чтобы только владелец адреса, на который перечисляются срества, смог воспользоваться этим выходом. Поле Signature Script (далее scriptSig) еще называют unlocking script — оно «отпирает» locking script, предоставляя доказательство владения адресом.
Подробнее о транзакциях, а также о работе запирающего и отпирающего скрипта можно почитать здесь.
Backward compability
На самом деле, Segregated Witness меняет не только строение транзакции, но и ее выходы. Это, однако, не значит, что в одной и той же транзакции не могут быть потрачены как традиционные UTXO (unspent transaction outputs), так и сегвитовские — просто первые будут ожидать «доказательства» внутри входа (поле scriptSig), а вторые — снаружи.
Так как Segregated Witness все-таки является софт-форком, его обновления могут быть проигнорированы, а значит более старые системы должны как-то обрабатывать сегвитовские выходы. Дело в том, что для старых нод или кошельков эти выходы выглядят как доступные всем, то есть они могут быть потрачены с пустой подписью, что все еще валидно. Принявшие обновление ноды и кошельки конечно же будут искать все подписи снаружи входов в специальном поле ‘witness’.
Examples
Pay-to-Witness-Public-Key-Hash
Теперь давайте взглянем на примеры транзакций и на то, как они изменятся с Segregated Witness. Мы начнем со стандартной Pay-to-Public-Key-Hash (P2PKH) транзакции.
Нас интересуют выходы, а именно их поля «scriptPubKey». Рассмотрим типичный locking script:
C Segregated Witness он будет выглядеть так:
Как видите, сегвитовский выход намного проще традиционного — он состоит из двух значений, которые будут помещены на стэк исполнения скрипта. Как мы уже упомянули ранее, для старых версий клиента биткоина этот выход будет виден как доступный любому, так как он не требует подписи. А вот для обновленного клиента первое число интерпретируется как номер версии, а второе как аналог запирающего скрипта (witness program). На самом деле, здесь должен быть использован хеш сжатого публичного ключа, об этом мы расскажем немного позже.
Теперь давайте рассмотрим транзакцию, в которой этот выход будет потрачен. В традиционном случае это выглядело бы так:
Однако, чтобы потратить сегвитовский выход, транзакция должна иметь пустое поле sriptSig и содержать все подписи в отдельном месте:
Warning
Несмотря на то, что традиционные клиенты могут обрабатывать сегвитовские транзакции (напомню, что их выходы выглядят как доступные всем для старых клиентов), они не могут тратить их выходы, так как они просто не знают, как это сделать: кошелек старого типа попытается потратить сегвитовский выход с пустой подписью, однако эта транзакция на самом деле не валидна (ноды, имеющие Segregated Witness, не пропустят такую транзакцию). Это значит, что отправитель должен знать, поддерживает ли кошелек получателя segwit или нет, чтобы создавать выходы нужного типа.
Начиная с BIP 143 выходы должны быть созданы с помощью хеша сжатого публичного ключа. Если вы создадите выход используя обычный адрес или несжатый публичный ключ, этот выход будет неиспользуемым.
Pay-to-Witness-Script-Hash
Следующим очень важным типом транзакции является P2SH — он позволяет отправлять транзакции на хеш скрипта вместо хеша публичного ключа (обычный адрес биткоина). Чтобы потратить выход P2SH транзакции нужно предоставить скрипт (его называют redeem script), хеш которого совпадает с хешем скрипта на который отправлены средства, а также подписи/пароли/что-то еще в зависимости от скрипта. Используя такой подход можно отправлять биткоины на адрес, защищенный способом, о котором нам ничего не известно, а также сильно экономить место — в случае, например, кошелька с мультиподписью (multisignature wallet) locking script был бы действительно большим, если бы мы хранили все «замки» полностью, а не только их хеш.
Итак, рассмотрим в качестве примера кошелек с мультиподписью, требующий наличия 2ух подписей из 5. В традиционном виде locking script выхода P2SH транзакции выглядит так:
Чтобы потратить его, нужно предоставить redeem script, определяющий условие мультиподписи 2 из 5, а также 2 подписи и все это должно находится во входе транзакции:
Теперь давайте взглянем, как бы все это выглядело, если бы и отправитель и получатель использовали Segregated Witness.
Locking script выхода:
Опять же, как и в случае с P2PKH транзакцией полученный скрипт намного проще. Здесь 1ое значение это номер версии, а второе — 32 байтный SHA256 хеш redeem script’a (witness program). Эта хеш-функция была выбрана для того, чтобы как-то отличать witness program P2WPKH от оной для P2WSH по длине хеша (32 байта SHA256 и 20 байт RIPEMD160(SHA256(script))).
Транзакция, использующая этот выход:
Embedding Segregated Witness inside P2SH
Итак, мы убедились, что использование Segregated Witness имеет свои преимущества, однако для приведенных выше примеров и отправитель и получатель должны быть обновлены, что возможно далеко не всегда. Рассмотрим, например, такую ситуацию:
Алиса хочет отправить биткоинов Бобу, но у нее нет сегвит-кошелька, в то время как у Боба он есть. Конечно же, они могут просто использовать стандартную транзакцию, однако Боб хочет использовать segwit для сокращения комиссии.
В таком случае Боб может создать P2SH адрес, содержащий в себе segwit скрипт. Для Алисы он будет виден как самый обычный P2SH адрес и она сможет без каких либо проблем перевести на него средства, а Боб сможет потратить этот выход используя сегвит-транзакцию и получив скидку на комиссию (о новой метрике установления комиссии для сегвит транзакций мы расскажем ниже).
Таким образом оба типа сегвит-транзакций — P2WSH и P2WPKH могут быть реализованы внутри P2SH.
P2SH(P2WPKH)
Для использования P2WPKH транзакции внутри P2SH Бобу нужно создать witness program из своего публичного ключа. Затем результат нужно хешировать и преобразовать в P2SH адрес:
Создаем witness program:
Как обычно — 1ое число это версия и 2ое это 20 байтный хеш публичного ключа. Полученный скрипт затем хешируется SHA256 и потом RIPEMD160, выдавая очередной 20 байтный хеш.
HASH160 от witness program P2WPKH:
И преобразовываем в адрес:
Locking script выхода отправленного на этот адрес будет выглядеть как скрипт для обычного P2SH адреса:
Теперь рассмотрим как Боб может потратить этот выход:
Сначала предоставленный нами redeem script (в нашем случае это witness program) будет хеширован и, если он равен хешу, указанному в locking script’e, то он будет выполнен и будут проверены подписи в поле «witness».
P2SH(P2WSH)
Точно также любой P2WSH скрипт может быть реализован внутри P2SH. Возьмем multisig скрипт 2 из 5, рассмотренный ранее. Все шаги будут практически идентичны случаю P2SH(P2WPKH):
Для начала, опять же, создаем witness program:
1ое число — версия, 2ое — 32 байтный SHA256 хеш нашего скрипта мультиподписи. Далее шаги повторяются — берем HASH160 от witness program и преобразовываем в обычный P2SH адрес. Для использования выхода, отправленного на этот адрес, в scriptSig нужно записать witness program, а все подписи и полный скрипт мультисига в поле witness.
Segregated witness benefits
Теперь, когда мы разобрались с технической частью, рассмотрим основные преимущеста segregated witness.
Transaction malleability
Одной из самых важных проблем, которые решает segwit является «изменяемость» транзакций, а если точнее, то их ID, являющиеся хешами. Разберемся немного подробнее.
В традиционном случае подписи, находящиеся внутри транзакции во входах, могут быть изменены третьей стороной без их инвалидации. Это позволяет изменять ID транзакции, являющийся ее хешем, не меняя никаких «фундаментальных» полей вроде входов/выходов/количества средств. Таким образом транзакция все еще валидна, однако теперь имеет другой ID, что создает возможность для разного рода атак, например denial-of-service.
Segwit решает эту проблему, т.к все подписи находятся снаружи транзакции, а значит не хешируются и их изменение никак не повлияет на ID транзакции. Также вводится отдельный идентификатор wtxid — он хеширует не только транзакцию но и всю witness часть, так что если транзакция передается без witness данных, то txid равен wtxid.
Решение данной проблемы позволяет создавать цепочки неподтвержденных транзакций без какого-либа риска — очень важное свойство для таких протоколов как Lightning Network.
Network and Storage Scaling
Witness данные зачастую составляют самую большую часть транзакции. В скриптах наподобие multisig’a они могут занимать до 75% места используемого транзакцией. Благодаря segwit’y передача подписей становится опциональной — нода запрашивает их только если собирается проводить валидацию транзакции. SPV (simple payment verification) клиенты или ноды, не поддерживающие сегвит, в таком случае могут не загружать лишние данные, экономя место на диске.
Block size increase and lower transaction fees
Segwit транзакции обходятся дешевле, нежели традиционные за счет скидки на хранение witness данных. Если быть точнее, то было изменено само понятие «размера» для segwit транзакций. Вместо обычного размера для них было введено понятие «виртуального размера» (virtual size) — все данные, хранящиеся в «witness», учитываются с коэффицентом в 0.25, что также позволяет разместить в блоке больше транзакций. Рассмотрим на примере.
Пусть у нас есть традиционная транзакция размером в 200 байт. В блок размера 1 МB поместится 5000 таких. Теперь возьмем ее segwit эквивалент, где примерно 120 байт это witness данные. Тогда ее vsize = 80 + 0.25 * 120 = 110 и теперь уже 9090 таких транзакций влезут в блок. Также при комиссии, допустим, в 40 satoshi/byte для 1ой транзакции мы получим комисси в 8000 сатоши, а для 2ой 4400 сатоши, что практически в два раза меньше.
Script Versioning
Как вы уже могли заметить, каждый locking script имеет байт, отвечающий за версию скрипта. Использование версий позволяет вносить дополнения и изменения (изменения в синтаксисе, новые операторы и тд.) в виде софт-форков.
Signature Verification Optimization
Segregated Witness также оптимизирует работу алгоритмов с подписями (CHECKSIG, CHECKMULTISIG и тд.). До segwit’a количество хеш-вычислений увеличивалось квадратично от количества подписей, в то время как в обновлении сложность алгоритма понижена до O(n).
So what is the problem?
Так если все так хорошо, в чем же проблема? Обновление имеет немало противников в сети, так как несмотря на все очевидные преимущества, оно имеет и свои слабые стороны. Рассмотрим некоторые из аргументов против.
Conclusion
Несмотря на то, что, возможно, для проблем, решаемых SW, могут быть предоставлены более элегантные решения, мы считаем, что на данный момент это отличный способ повысить масштабируемость сети, а также сделать возможным внедрение таких технологий как Lightning Network, подробный разбор которой мы также проведем в следующих статьях.
SegWit и Native SegWit — В чём разница?
Как Вы могли заметить, при добавлении аккаунта Bitcoin в Ledger Live, кроме стандартной учётной записи Legacy, вам предлагается два варианта: Native SegWit и SegWit. Хотя можно легко определить разницу между адресом Native SegWit (начинающимся с “bc1”) и адресом SegWit (начинающимся с “3”), мы хотели бы более подробно рассмотреть, что именно это означает.
SegWit (P2SH) и Native SegWit (bech32) не являются первыми форматами адресов, которые существуют для биткойн-аккаунтов. Самый первый из них был Legacy, где адреса начинались с “1″. По мере того как цена Биткойна начала расти, сборы, уплачиваемые за каждую транзакцию, тоже стали выглядеть более дорогими. Скорость транзакций также была более медленной.
Предложение SegWit (Segregated Witness) в своё время было сильно оспорено – фактически, первоначальное предложение, известное как SegWit2x, было фактически отброшено и заменено тем, что мы теперь знаем как SegWit. В августе 2017 года состоялся софтфорк, реализующий SegWit. С тех пор его быстро приняли, и он начал становиться новым стандартом.
Так что же изменил SegWit?
SegWit уменьшил размер данных каждой транзакции. Это было сделано путём отделения определённых данных подписи транзакции от транзакции. Делая транзакции меньше по размеру, больше транзакций может поместиться в один блок биткойнов. Это, в свою очередь, делает сеть Биткойнов более масштабируемой, а её транзакции — более быстрыми. Более того, это значительно снижает транзакционные сборы за каждую биткойн-транзакцию. SegWit также включил решения для масштабирования второго уровня, что привело к появлению сети Lightning.
Native SegWit, также известный как bech32, является последним шагом в форматах адресов. Он ещё более экономичен по весу, чем его предшественник. Это означает ещё более высокую скорость транзакций по сравнению с транзакциями SegWit, лучшую масштабируемость и ещё более низкие комиссии за транзакцию. Вдобавок к этому, bech32 имеет лучшее обнаружение ошибок и, для лучшей читаемости, делает адреса только в одном (нижнем) регистре. Вот почему это самый популярный вариант… если поддерживается.
Единственным недостатком bech32 является то, что пока не все основные платформы поддерживают этот формат адресов. Хотя транзакции между устаревшими, SegWit и Native SegWit полностью совместимы, всё ещё существует довольно много бирж и поставщиков кошельков, которые пока не поддерживают отправку BTC на адрес bc1. Таким образом, при добавлении учётной записи в Ledger Live вам будет предоставлена возможность добавления Native SegWit и/или адреса SegWit.
Выводы:
- SegWit – уменьшил размер данных о транзакциях, чтобы обеспечить более быстрые транзакции, лучшую масштабируемость и снижение комиссий. Native SegWit (bech32) ещё больше расширил это и включает в себя ещё более низкие сборы. Ещё не все биржи и поставщики кошельков поддерживают отправку биткойнов на адреса Native SegWit. Возможны транзакции между всеми 3 типами адресов.
При подготовке статьи использовались материалы сайта ledger.com.
Если Вам понравилась эта страничка, расскажите о ней своим друзьям (кнопки социальных сетей — внизу страницы). Также вы можете оставить отзыв или поддержать материально.
Segregated Witness (SegWit). Причины и последствия обновления
Содержание
Что такое SegWit?
Основная идея SegWit заключается в реорганизации данных в блоке таким образом, чтобы подписи размещались отдельно от информации о транзакциях. Другими словами, обновление SegWit состоит из отделения свидетелей (подписей) от транзакций. Это позволяет увеличить пропускную способность сети за счет увеличения количества транзакций в блоке.
Поскольку биткоин может предоставить только около 7 транзакций в секунду, обработка перевода в сети иногда может занимать большой промежуток времени по сравнению с традиционными платежными решениями и финансовыми сетями, которые могут обрабатывать тысячи транзакций в секунду.
Преимущества предусмотренные в SegWit
Увеличение пропускной способности
Одно из самых основных преимуществ SegWit является увеличение вместительности блока. Благодаря удалению подписей из данных о транзакциях на выходе, появляется возможность вместить большее количество транзакций в одном блоке.
Без SegWit данные подписи могут занимать до 65% всего блока. SegWit позволяет удалять подписи из входных данных о транзакциях. Это приводит к увеличению вместительности блока с 1 МБ до примерно 4 МБ.
Обратите внимание, что SegWit не предполагает увеличение размера самого блока. Это инженерное решение, позволяющее задействовать весь потенциал блока без необходимости увеличения его текущего размера (что возможно только в случае хардфорка). Фактический размер блока по-прежнему остается 1 МБ, но эффективный предельный размер составит 4 МБ.
Увеличение скорости транзакций
Увеличенная скорость транзакций также помогла снизить операционные расходы в сети биткоина. До обновления обычным делом было заплатить более 30$ за транзакцию. SegWit резко снизил стоимость комиссии до менее чем 1$.
Исправление пластичности транзакций
Одним из основных проблемных моментов биткоина была возможность подделать криптографическую подпись транзакции. Если в подпись внесли хотя бы малейшие изменения, это может привести к повреждению ее идентификатора, что соответственно повлияет на всю транзакцию между двумя сторонами. Поскольку данные, хранящиеся в блокчейне практически неизменны, подобные транзакции могут навсегда остаться в его истории.
SegWit и Lightning Network
SegWit и SegWit2x
Основное различие между SegWit и SegWit2x заключается в том, что вариант с хардфорком не только изменяет порядок пакетирования транзакций, но также и увеличивает размер блока (с 1 Мб до 2 Мб). Подобные изменения могут увеличить нагрузку на узлы и майнеров, по причине обработки большего объема данных.
Еще одно заметное отличие заключается в том, что обновление SegWit было поддержано и реализовано биткоин-сообществом. Такое событие породило концепцию под названием UASF (от англ. user-activated soft fork), которая означает активируемый пользователями софтфорк.
С другой стороны, в SegWit2x было предложено существенное изменение одного из фундаментальных правил, которое регулирует работу биткоина. Но поскольку разработчики так и не смогли прийти к единому мнению относительно принятия и реализации обновления, развитие SegWit2x в конечном итоге было приостановлено.
Заключение
Реализация SegWit ознаменовало собой крупнейшее обновление протокола биткоина, а тот факт, что его поддержало и осуществило децентрализованное сообщество, делает его еще более интересным.
Софтфорк SegWit стал важным шагом в решении многих проблем связанных с биткоином и другими блокчейн-сетями, особенно в отношении масштабируемости. Благодаря комбинации SegWit и протоколов второго уровня, блокчейны могут более эффективно обрабатывать большее количество транзакций за меньшую стоимость.
Несмотря на то, что это мощное и инновационное решение, на данный момент не все участники сети полностью приняли обновление. В настоящее время процент биткоин-адресов использующих SegWit составляет около 53%.
Binance вводит поддержку SegWit. Что это значит для пользователей?
Одна из крупнейших криптовлаютных бирж Binance вводит поддержку Segregated Witness или SegWit для депозитов в Биткоине. Напомним, SegWit, реализованный в 2017 году, представляет собой обновление протокола главной криптовалюты, предназначенное для масштабирования сети Биткоина и исправления связанных с этим ошибок. SegWit известен тем, что отделяет подписи от данных транзакции. Это обновление протокола позволяет хранить больше транзакций в одном блоке, тем самым увеличивая пропускную способность BTC.
Напомним, SegWit непосредственно относится к блокам Биткоина, тему которых мы подробно разобрали в отдельном материале. С помощью обновления каждый из них начал вмещать информации о большем количестве транзакций, что положительно сказалось на производительности сети.
Всё же технические особенности блокчейна первой криптовалюты ограничены, а блок в идеале добавляется к цепочке раз в десять минут. Соответственно, апдейт сохранил эту особенность, но позволил сети обрабатывать большее количество переводов.
Мы проверили актуальные данные по поведению Биткоина. Сегодня курс первой криптовалюты находится на уровне 26 861 доллара, что ниже результата суточной давности на 3 процента. При этом капитализация проекта Сатоши Накамото балансирует на уровне полутриллиона долларов. Вот график стоимости BTC за последние две недели. За этот срок Биткоин подорожал на 40.2 процента.
График курса Биткоина за две недели
Новый апгрейд для Binance
Изначально поддержка SegWit была введена Binance только для выводов, но после недавнего времени она также расширена и на депозиты клиентов биржи. Уже сейчас пользователи могут выбрать SegWit-адреса для перевода монет. Главная особенность так называемого формата Bech32-адресов заключается в том, что последние начинаются с “bc1” и не чувствительны к регистру, то есть разницы между заглавными и строчными буквами нет. Формат ввели в Bitcoin Core 0.16.0. Вот цитата из официального анонса торговой площадки, которую приводит Cointelegraph.
Обратите внимание, что SegWit должен помочь снизить комиссии. Однако если вы неправильно отправите несовместимые активы на адрес, ваши средства не будут возвращены и это приведет к их безвозвратной потере.
То есть пользователям нужно быть ещё более внимательными при работе с криптовалютами, поскольку в случае чего монеты можно потерять.
Окно депозита с SegWit на Binance
Отметим, что это очень важное замечание: если вы отправите другую криптовалюту или те же биткоины на несовместимый адрес, ваши монеты будут утеряны. Довольно часто это, казалось бы, очень простое правило игнорируют.
Мы уже писали о подобных историях, когда элементарная человеческая невнимательность приводила к потере большого объема средств. К примеру, в марте этого года трейдер потерял эквивалент 9 тысяч долларов, поскольку скорее всего по ошибке оставил ордер на покупку другой криптовалюты вместо Биткоина. Естественно, деньги вернуть не удалось. Подробнее о ситуации мы писали здесь.
По данным платформы transactionfee, примерно две трети транзакций в Биткоине уже используют SegWit. То есть апгрейд от Binance — это просто дань прогрессу в разработке главной криптовалюты. Хоть она и считается больше средством сохранения капитала, нежели быстрой платежной системой, пропускная способность и низкие комиссии в BTC тоже очень важны.
Мы уточнили актуальную информацию по комиссиям в сети Биткоина. Вчера средняя стоимость перевода в блокчейне первой криптовалюты составляла эквивалент 8 доллара. При этом показатель сети Эфириума находился практически в два раза ниже.
Комиссии в сети Биткоина и Эфириума
Мы считаем, что инициатива руководства криптовалютной биржи Binance заслуживает похвалы. Безусловно, с момента релиза SegWit прошло много времени, однако в данном случае внедрение технологии всё же лучше, чем её игнорирование. Надеемся, в дальнейшем ситуация с комиссиями в сети первой криптовалюты будет улучшаться. Впрочем, когда Биткоин вновь окажется в центре массового внимания как средство инвестиции, переводы в данной криптовалюте могут легко подорожать в несколько раз.
Еще больше интересного ищите в нашем крипточате. Также не забудьте подписаться на нас в Яндекс Дзене, где появляются статьи, которых нет на сайте.