Сегвит биткоин что это

SegWit биткоина: что это простыми словами и как влияет на масштабирование

Segwit — это обновление сети биткоина, которое произошло в августе 2017 года. В этой статье мы объясним, что такое Сегвит, зачем он нужен и как он может помочь в масштабировании сети.

Читайте в статье

Что такое Segwit

Segwit — это обновление протокола Bitcoin, который разделяет цифровую подпись (также известную как «свидетель», он же «the witness» от транзакции. Это позволяет разместить больше транзакций в блоке размером 1 МБ.

Название Segwit является сокращением от Segregated Witness. Впервые его упомянули для широкой общественности в декабре 2015 года. Это сделал разработчик Питер Вьюэлл на конференции по масштабированию BTC. Решение должно преодолеть следующую проблему:

• Транзакции записываются в бокчейн в виде связанных блоков.
• Блоки нельзя нарушать, так как они идут последовательно и подтверждают друг друга.
• Блоки были ограничены емкостью в 1 Мб, а это около 2700 транзакций. Эта цифра не подходит для всемирной сети, которая должна обрабатывать платежи регулярно и быстро.
• Плюс ко всему, добыча блока занимает около 10 минут. Если транзакций много, начинается огромная очередь.
• Каждая транзакция состоит из трех частей: подписи, вводом и выводом (или входом и выходом). Здесь и скрывается проблема.

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

Подпись была равна 4. Вместо 4 я пишу 04, или 4-4+4, или 14:4 и т. д. Математически это все еще «4», а значит, подпись действительна. Но если хешировать эти данные, то получатся разные версии — это зависит от записи значения, а не от самого значения.

В реальной жизни могло бы быть так:

• Я перечисляю тебе деньги транзакцией Х.
• Ты не дожидаешься подтверждения, переводишь их продавцу транзакцией Y.
• Продавец тоже ничего не ждет и отправляет тебе товар.
• Ты меняешь технические вещи в моей транзакции, так что транзакция X отклоняется, а Y недействительна.
• Платежи не состоялись, а сделка в реальности совершилась.

Хэш — это идентификатор транзакции в блокчейне. Изменять его нельзя по ряду причин. Это меняет данные первого уровня, а значит, осложняет работу оффчейн-приложений, типа Lightning Network.

SegWit перемещает подпись в конец данных транзакции, поэтому идентификатор транзакции создается из всего, кроме цифровой подписи.

С внедрением segwit сеть получила несколько преимуществ:

• удвоена емкость сети,
• транзакции дешевле и быстрее,
• исправлена гибкость транзакций, описанная выше. Это было ключевым недостатком блокчейна BTC.
• Новые возможности для разработчиков.

Принятие Segwit увеличивается. Почти 50% всех биткоин-транзакций используют адреса SegWit. Хотя все ноды не будут использовать сегвит, поскольку многим майнерам он не нравится. Низкие комиссии влияют на их прибыль, а другие цепочки поверх BTC не приносят денег.

Адреса Segwit начинаются с «3», а устаревшие адреса начинаются с «1».

Это краткосрочное решение долгосрочных проблем. Некоторые разработчики жалуются, что протокол SegWit недостаточно далеко решает проблему масштабируемости. Они утверждают, что только значительные изменения в размере и способе обработки транзакций помогут платформе масштабироваться в будущем.

Но также считается, что SegWit и Lightning Network вместе позволят биткоину обрабатывать миллионы (или более) транзакций в секунду.

Как работает SegWit

Прежде чем вы сможете понять SegWit, вы должны сначала понять, как обрабатываются транзакции в сети.

Для простоты представим блок, содержащий только одну транзакцию. Если Майк отправит Бобу 1 BTC, он добавит в блок важные данные:

• Его вход и выход
• Открытый ключ получателя и сумму BTC, которую он отправляет Бобу
• Его открытый ключ
• Его цифровая подпись

Открытый ключ и цифровая подпись Майка должны быть включены в блок. Они доказывают, что сделка является законной. Цифровая подпись включена в блок как скрипт (вы можете думать о скрипте как о коде). Так же, как люди подписывают чеки, чтобы авторизовать их, пользователи сети BTC должны подписывать транзакции.

Цифровые подписи занимают много места, которое в противном случае могло бы использоваться для данных транзакций. Когда тысячи транзакций инициируются одновременно, им не хватает места для входа в один и тот же блок. Пользователи должны платить комиссию за транзакцию, чтобы майнеры брали в блок их переводы.

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

60% данных, которые занимают подписи транзакции, перемещаются в ее конец. Segregated Witness, таким образом, — это способ удаления свидетеля (подписи) из транзакции. Размер значительно уменьшается.

До SegWit максимальный размер блока Биткойна составлял 1 МБ, то есть после достижения этого лимита блок больше не мог принимать новые транзакции. SegWit внедрил новый способ измерения размера транзакций. SegWit измеряет блоки, используя так называемый вес блока.

Вот формула, используемая для расчета веса блока:

(размер tx с удаленными данными свидетеля)*3 + (размер tx)

Узлы SegWit теоретически могут получать блоки, которые очень близки к 4 МБ. На практике блок SegWit не будет превышать 2 МБ.

Поскольку это софтфорк, старые ноды тоже могут обрабатывать транзакции.

История принятия SegWit

Раньше вся статья была посвящена тому, как пережить сегвит и что делать с биткоином. Теперь мы оставили исторические разделы для тех, кто хочет понять, как это было и чего ожидало сообщество.

Первый и оригинальный вариант был предложен группой разработчиков Bitcoin Core. Их код SegWit, определенный BIP141, активируется, если 95 процентов хэш-мощностей в течение одного периода сложности будут готовы в течение двух недель. Если майнеры, которые сигнализируют о готовности, действительно будут поддерживать обновление, риски форка в блокчейне и валюте биткоина минимальны.

Однако сегмент пользователей Bitcoin планирует активировать SegWit с BIP148 UASF. Начиная с 1 августа, их узлы будут отклонять все блоки, которые не сигнализируют о готовности к BIP141.

• Если это предложение поддержано большинством майнеров (по хэш-силе), эти майнеры должны всегда требовать самую длинную действующую цепочку, готовую к SegWit, и избегать разделения.
• Но если это предложение поддерживается меньшинством майнеров, «цепочка BIP148» может отделиться от текущего протокола.

Нью-йоркское соглашение, также называемое «Сильбертское соглашение» или «SegWit2x», планирует активировать SegWit через BIP91. Как и BIP148, все узлы BIP91 будут отклонять любые блоки, которые не сигнализируют о готовности к BIP141. Но в отличие от BIP148, узлы BIP91 будут делать это только после того, как 80% будут поддерживать BIP91 в течение примерно двух дней. Это также должно минимизировать вероятность раскола.

Тем не менее, второй шаг Нью-йоркского соглашения — это решение удвоить размер базового блока. Это изменение вероятнее всего может привести к хардфорку (что и случилось — апдейт 2019 года).

Теперь этапы активации SegWit по датам:

14 июля: установка BTC1

Бета-версия BTC1 была выпущена 30 июня. Но согласно дорожной карте SegWit2x, 14 июля — это тот день, когда подписавшие Нью-йоркское соглашение должны фактически установить бета-версию BTC1 и протестировать ее для себя.

Однако это не должно влиять на обычных пользователей.

21 июля: BIP91 сигналы для запуска

Команда разработчиков SegWit2x нацелена на то, чтобы 21 июля настал тот момент, когда узлы BTC1 фактически запущены и начались сигналы от майнеров.
Это также не должно влиять на обычных пользователей.

Но если вы майнер, вы можете помочь активировать SegWit, просигнализиров о своей готовности к BIP91.

23 июля: lock-in BIP91

Полная активация BIP91 требует, чтобы из 336 блоков (один период) 269 блоков должны сигнализировать о готовности. Это около 80% хэш-мощностей.

Опять же, это не должно влиять на обычных пользователей.

Но если вы майнер и BIP91 активируется, у вас есть день или два, чтобы соответствовать софт-форку BIP91. Если вы этого не сделаете, рискуете добывать недопустимые блоки.

25 июля: активация BIP91

25 июля создадутся еще 336 блоков после «блокировки», BIP91 вступит в силу. Любые блоки, которые не сигнализируют о готовности для SegWit (c BIP141), теперь будут отклонены.

Это все равно не должно влиять на обычных пользователей.

29 июля: крайний срок BIP91

Если майнеры хотят избежать «раскола» в блокчейне и валюте Биткоина, 29 июля — главный день для них. Нужно, чтобы была подготовлена совместимость с BIP148 UASF, до которого останется два дня.

Если BIP91 не активировался к крайнему сроку, в блокчейне биткоина пойдет раскол. Майнеру нужно решить, в какой цепи добывать блоки с 1 августа: в цепи BIP148 или в оригинальной цепи (Legacy).

31 июля: дедлайн BIP14

Технически, 31 июля — второй дедлайн для майнеров, чтобы избежать раскола. Должно пройти две недели, в течение которых 95% хэш-мощностей будут сигнализировать о принятии SegWit.

На следующий день активируется BIP148, что делает его третьим и окончательным дедлайном для майнеров, чтобы избежать форка.

1 августа, в 00:00 UTC, все узлы BIP148 начнут отклонять любые блоки, которые не сигнализируют о готовности к SegWit. Если BitcoinCore—BIP141 или BTC1—BTC91 заблокированы и/или активированы во время, не должно быть раскола.

Если ни одно из этого не произошло, большинство майнеров (по хэш-силе) теперь имеют последний шанс избежать разрыва цепи: поддерживая BIP148 самостоятельно. Это гарантирует, что они всегда будут запрашивать самую длинную действующую цепочку в соответствии со всеми текущими узлами биткоина и активируют SegWit через BIP141.

В итоге блокчейн разделился: это запустило целую волну форков. О них подробно в статье Все форки биткоина.

Источник

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?

Так если все так хорошо, в чем же проблема? Обновление имеет немало противников в сети, так как несмотря на все очевидные преимущества, оно имеет и свои слабые стороны. Рассмотрим некоторые из аргументов против.

• Так как segwit является софт-форком, обновлены будут далеко не все клиенты, а значит в сети будут находится одновременно два вида UTXO, и такие важные изменения как устранение уязвимости id транзакций и хеширование за линейное время не будут применены к не сегвитовским выходам, а значит сеть все еще будет уязвима к атакам, основанным на изменяемости id транзакций, а также к проблеме квадратичного времени хеширования.
• Segwit может уменьшить безопасность сети. Количество нод, проводящих полную валидацию, сильно уменьшится, так как только принявшие segwit смогут проверять witness часть транзакций.
• Segwit не может быть отменен. Если его отменить и откатить все изменения обратно, все segwit-выходы станут доступными каждому.
• Segwit пытается решить все проблемы сразу и, как следствие, огромное количество кода изменено. Это усложняет дальнейшую работу и увеличивает вероятность появления багов, которые будет сложнее устранить.

Conclusion

Несмотря на то, что, возможно, для проблем, решаемых SW, могут быть предоставлены более элегантные решения, мы считаем, что на данный момент это отличный способ повысить масштабируемость сети, а также сделать возможным внедрение таких технологий как Lightning Network, подробный разбор которой мы также проведем в следующих статьях.

Источник