Биткоин: работа продолжается. Глава 12

Технические инновации из окопов

Перевод NADO Book by Sjors Provoost.

Проект перевода организован HypeCoinNews.

Способы активации

Софтфорк Taproot был активирован 13 ноября 2021 года, примерно через год после появления окончательной редакции кода. Это произошло куда быстрее, чем активация SegWit, и куда менее драматично, но тот год не был совсем уж лишен событий. В этой главе рассказывается, как софтфорки активировались в прошлом, какие способы активации рассматривались для Taproot и как он все-таки был активирован.

Мы посвятили этой теме пять эпизодов, и соответствующие QR-коды размещены в разных частях этой главы. Однако это далеко не однозначное сопоставление; ссылки приведены даже не в хронологическом порядке.

Софтфорки: введение

По мере приближения развертывания Taproot вопрос о том, как активировать софт-форки, снова стал предметом дискуссий в биткоин-сообществе.

Софтфорки, если вы помните — это обратно совместимые изменения протокола. Другими словами, любой, кто обновился, будет пользоваться преимуществами, которые дает обновление, но те, кто не обновится, все равно останутся с корректно работающим софтом.

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

Простым примером таких более строгих правил является BIP 66, который требует, чтобы любые новые подписи соответствовали строгому стандарту, в то время как ранее существовала некоторая (непреднамеренная) гибкость в способах кодирования подписей.

Может показаться парадоксальным, что строгие правила допускают больше возможностей, но в Главе 3, в разделе про будущие версии SegWit, мы объяснили, почему это так работает. В текущей главе нас меньше интересует, как работают софтфорки, и вместо этого мы сосредоточимся на том, как их активируют.

Есть несколько разных способов внедрить софтфорк. Можно сделать это случайным образом, а можно внедрить его в код намеренно. Также можно объявить дату (день Д) или высоту блока, начиная с которой применяются новые правила. Наконец — и именно так это обычно сейчас работает — можно получать сигналы от майнеров и активировать софтфорк, как только будет достигнут определенный порог.

Но то, как принимается решение о развертывании софтфорка, возможно, даже важнее, чем механика активации. А кто вообще решает?

Самые ранние софтфорки

Хотя на заре Биткоина этого термина еще не существовало, у него было много софтфорков, в основном связанных с закрытием дыр в безопасности у раннего прототипа. В 2013 году произошел даже случайный софтфорк, а в 2015-м случился случайный софтфорк, который едва не пропал из-за изменений OpenSSL (см. главу 4).

Самые ранние софтфорки в основном использовали в качестве метода активации высоту блока — другими словами, «начиная с вот этого будущего блока должно применяться новое правило». В идеале об этом объявляют заблаговременно, чтобы у людей было достаточно времени для обновления. В случае «секретного» софтфорка разработчики могли просто настаивать на том, чтобы люди обновлялись, а уже затем объяснять причину.

Вероятно, самым печально известным софтфорком всех времен остается ограничение размера блока в один мегабайт, введенное Сатоши в 2010 году. Софтфорк был выпущен 7 сентября 2010 года, а параметр activation_height для него был установлен на 79 400, и этот блок был добыт всего лишь неделю спустя.

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

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

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

Как осуществляются софтфорки?

Выпуск новой версии программного обеспечения, которая активирует софтфорк на заданной высоте — это одно. Но если его не запустят правильные люди и не сделают это вовремя, на самом деле он не возымеет эффекта. Если софтфорк выпущен в дикую природу…

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

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

Мы не знаем, сколько отдельных майнеров было в 2010 году, но вполне возможно, что они были в курсе этих обновлений. При этом на майнинге нельзя было сделать деньги: первая продажа пиццы состоялась только в мае того же года.

Даже в 2013г, когда произошел случайный софт-форк, достаточное количество майнеров запустило исправление всего за несколько часов. Но чрезвычайные ситуации — это не то же самое, что обычные софтфорки.

Кто принимает решения?

Первоначально Сатоши в одностороннем порядке решал, что нужно изменить, хотя в конечном итоге он не мог заставить кого-либо запускать новые версии, которые он выпустил, поэтому он не мог вносить совершенно произвольные спорные изменения. В данный момент разработка Биткойна ведется, если не залезать в дебри, в рамках процесса «приблизительного консенсуса», как описано в RFC 7282.

Любой может предложить изменение правил Биткоина. Но нужно не только убедить других в полезности изменения; также необходимо рассмотреть все технические возражения, которые выдвигаются против него. Например, если кто-то жалуется, что предложение нарушит работу его кошелька, автор предложения не может просто сказать «не повезло». Вместо этого он должен решить проблему. Может быть, он может предложить простое исправление для рассматриваемого кошелька, или изменить свое собственное предложение, чтобы оно ничего не ломало.

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

Предложения о хардфорке часто отклоняются только потому, что они ломают существующее программное обеспечение и требуют одновременного обновления от всех участников. То же самое предложение, вводимое как софтфорк, решает обе проблемы, поэтому его обычно предпочитают хард-форку. Вот почему небрежное предложение разработчика Bitcoin Core Люка Даша-младшего о том, что SegWit можно реализовать как софтфорк, изменило правила игры.

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

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

Сигнализирование (BIP 9)

Итак, если день Д или некая высота блока — не лучший критерий для активации софтфорка, как сделать лучше? Одна из идей заключалась в том, чтобы майнеры сигнализировали о готовности к софтфорку в создаваемых ими блоках. Первоначально это было реализовано путем увеличения номера версии блока. Сигнализация работает как механизм координации для сети, позволяющий выяснить, достаточно ли майнеров обновило свой софт.

Этот механизм был улучшен и формализован в BIP 9. Как часть механизма сигнализации, встроенного в код, существует начальная дата («стартовое время»), когда майнеры начинают сигнализировать, и крайний срок («тайм-аут»), после которого они сдаются, если «порог» не был достигнут. Подсчет ведется в раундах по 2016 блоков, то есть примерно двухнедельными периодами. Если в любом раунде, заканчивающемся до тайм-аута, достигается порог, то активируются новые правила. Это легко проверить каждому узлу в сети.

Значение 2016 взято в силу того, что это количество блоков в одном периоде корректировки сложности, т.н. периоде перенацеливания. На рисунке выше каждая стрелка представляет один период сигнализирования. Циклические стрелки указывают, что состояние остается прежним — например, когда софт-форк РАСПОЗНАН (это означает, что узел знает о нем, но еще не сигнализирует о поддержке), он останется таким, если MTP все еще меньше стартового времени. Начиная со стартового времени состояние переходит в ЗАПУЩЕНО. Состояние сохраняется таким, обозначая сигнализирование о поддержке. Для каждого периода — скажем, каждые две недели — мы проверяем, достаточно ли блоков подают сигнал. Если достаточно, мы переходим к следующему этапу, который называется ЗАФИКСИРОВАНО. Если недостаточно, и если достигнут тайм-аут, мы переходим к состоянию ОТВЕРГНУТО. ЗАФИКСИРОВАНО — это промежуточный период, когда новые правила еще не применяются, но через две недели софт-форк становится АКТИВНЫМ и его правила начинают применяться.

Механизм сигнализирования передает контроль за активацией обновления в руки майнеров в течение заранее определенного периода. Для успешной активации софт-форка требуется сигнальная готовность на уровне 95 процентов.

Дополнительным преимуществом этого механизма является возможность параллельного развертывания нескольких софтфорков. Каждому назначается определенный сигнальный бит.

BIP 9 успешно использовался для развертывания софтфорков CSV и SegWit, и его можно было бы использовать и для Taproot. Первое развертывание прошло гладко, но, как мы вскоре увидим, второе вызвало много скандалов и заняло гораздо больше времени, чем многие считали нужным. Это привело к опасениям, что, возможно, BIP 9 это не самый надежный механизм развертывания.

В результате было предложено несколько других механизмов, а также их вариации.

Всегда проверяйте блоки!

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

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

Пропуск проверки блоков - это рискованное занятие для майнеров даже без софт-форка, но при нормальных обстоятельствах общего согласия они могут избежать последствий. Однако при софтфорке, когда большинство майнеров применяет новые правила, а меньшинство — нет, когда один из таких майнеров случайно добывает недействительный блок, другие майнеры, не проводившие проверку, будут строить поверх него. Большинство проапгрейдившихся будет игнорировать все эти блоки, и как только их цепочка станет длиннее, все эти находящиеся в меньшинстве майнеры обнаружат, что их блоки устарели. Именно это произошло с BIP 66.

Первая драма, а также BIP 148/91

Когда код SegWit был готов, и пришло время его внедрения, вновь был использован механизм активации BIP 9, потому что раньше он хорошо себя показал. Но по прошествии месяцев ни в один из двухнедельных периодов ретаргетинга не был достигнут требуемый 95-процентный порог сигнализирования. Хотя по блокчейну этого не скажешь, оказалось, что несколько крупных майнеров использовали сигнал готовности BIP 9 или его отсутствие в качестве голосования, что, в свою очередь, блокировало обновление.

Они не выдвигали никаких технических возражений, поэтому ранее установленный грубый консенсус в стиле RFC 7282 остался нетронутым. Была ли это просто инерция и апатия? Было ли у них тайное техническое возражение против этого предложения?

Или майнеры были разочарованы разработчиками и не доверяли им, возможно, отчасти из-за языковых и культурных барьеров? Многие майнеры были китайцами, а многие разработчики были из западных стран.

В любом случае, BIP 9 не должен был быть референдумом, и, учитывая, как быстро майнеры смогли обновиться во время предыдущих софтфорков, этот тупик не имел большого смысла и разочаровал тех, кто хотел воспользоваться преимуществами функций SegWit, которые мы обсуждали в главе @сек:segwit. Один особенно разочаровывающий аспект этой ситуации заключается в том, что отсутствие сигнализирования сдерживало столь востребованное увеличение размера блока, которое предлагал SegWit.

В этот момент большинство разработчиков Bitcoin Core, возможно, были так же разочарованы, но предпочли остаться на консервативной стороне и просто дождаться «тайм-аута» и хоть каких-нибудь успехов. Когда нет единого мнения о новом образе действий, по умолчанию просто ничего не делают. Но это не должно останавливать никого другого.

Примерно в начале марта 2017 года группа людей сказала: «Эй, знаете что? Пришло время поменять механизм на День Д». Они выбрали 1 августа 2017 года в качестве даты и сказали, что с этого дня их узлы будут применять новые правила SegWit.

Если еще точнее, они потребовали, чтобы в этот день все блоки сигнализировали о SegWit. Эта сигнализация, в свою очередь, должна была привести к активации SegWit. Это был механизм BIP 148, и его обычно называли софт-форком, активируемым пользователем (UASF). Сходство этой аббревиатуры с соответствующим родом войск вооруженных сил США помогло в его маркетинге.

Вопрос: сработало ли это? Просто взглянув на блокчейн, этого не установишь. Если посмотреть на историю блоков, видно только то, что 95 процентов сигнализировали, и софт-форк был активирован. Это, конечно, очень примечательно, что активация произошла прямо перед 1 августа, а не в какую-то другую случайную дату, когда это еще могло произойти. Но нет никаких устаревших ветвей с несигналящими блоками, на которые мы могли бы указать как на свидетельство борьбы между майнерами и узлами UASF.

Как мы объясним ниже в разделе «LOT=true», вероятно, это здорово, что не произошло конфронтации в виде конкурирующих ветвей блокчейна.

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

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

Более подробно о том, к чему это все привело, рассказывается в книге Война за размер блока, упомянутой в конце главы 4. (Спойлер: они отменили хардфорк в последнюю минуту.) Для целей нашей главы интересно кратко объяснить идею снижения порога активации, которая была воспринята более положительно.

На следующий день в списке рассылки был предложен BIP 91. Он должен был работать следующим образом: если 80 процентов майнеров проголосовали "за", то (две недели спустя) все майнеры должны подать сигнал. И как только все майнеры подадут сигнал, будет достигнут 95-процентный порог. Это приведет к активации SegWit для всех вовлеченных лиц.

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

Как и в случае с UASF, просто взглянув на блоки, мы не можем точно сказать, что произошло.

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

Переосмысление процедуры активации и внедрение BIP 8

Под впечатлением от UASF, а также ввиду очевидной необходимости отладки работы BIP 9, был предложен BIP 8.

Он использует механизм сигнализации, аналогичный BIP 9, но основанный на высоте блока, а не на метках времени. Это упрощает рассмотрение реорганизаций, например, когда последний блок сигнального периода добывается непосредственно до "тайм-аута", софт-форк активируется, но затем, если бы появилась и вступила в силу альтернативная ветвь блоков, и эта альтернативная ветвь добавилась бы (то есть имела бы временные метки) непосредственно после "тайм-аута" , то — на той ветке, на том переписывании истории — софтфорк бы не активировался.

Недостаток использования высоты блока состоит в томя, что вы не можете предсказать, когда произойдет «таймаут», потому что это зависит от того, насколько быстро создаются блоки.

До сих пор BIP 8 был просто хорошей заменой BIP 9. Но где он действительно отличается, так это в том, что он устанавливает день Д в стиле UASF, чтобы обеспечить принудительное сигнализирование. На это указывает фаза НУЖНО_СИГНАЛИТЬ на рисунке, который в остальном не сильно отличается от того, что вы видели выше при разборе BIP 9.

Это означает, что день Д не активирует софтфорк сам по себе. Скорее, если незадолго до дня Д появится блок, который не сигнализирует о поддержке софтфорка, этот блок будет отклонен: именно так этот механизм заставляет всех сигнализировать ближе к финалу.

Как и в случае с UASF, это принудительное сигнализирование имеет смысл только в том случае, если есть другие узлы, у которых не установлено аналогичного дня Д.

Вот почему сама установка дня Д не является обязательной. Что именно здесь означает не обязательно? Это может означать, что есть две разных загружаемых версии софта: одна с включенным днем Д и одна без, предположительно выпущенные двумя различными командами с разными приоритетами. Также это может означать, что есть только одна скачиваемая версия, но она позволяет пользователю выбирать.

Это позволяет использовать постепенную эскалацию: возможно, сперва большая часть сообщества не сигнализирует о дне Д, а затем, по прошествии времени, это делает все больше узлов.

В этом смысле он формализует процесс, который неофициально происходил в 2017 году, в сущности, говоря: если вы хотите сделать что-то вроде UASF, пожалуйста, сделайте это определенным образом.

Как и его предшественник, UASF, это предложение не лишено проблем. В следующих абзацах описывается, как должно работать принудительное сигнализирование.

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

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

В любом сценарии, где существуют две альтернативные цепочки, пользователям, чей узел следует за одной ветвью, небезопасно совершать транзакции с пользователями, чей узел следует за другой ветвью. Фактически, для всех небезопасно использовать блокчейн в этот момент. С другой стороны, пока единственная существующая цепочка соответствует требованию об обязательном сигнализировании, беспокоиться не о чем. Некоторым читателям это может напомнить то, что говорит теория игр о гарантированном взаимном уничтожении (MAD).

Спорить много - To Argue a LOT

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

Когда дело дошло до процесса активации Taproot, возникли споры вокруг этого параметра LOT, который означает фиксацию по тайм-ауту. Если обратиться к приведенной выше схеме BIP 8, там на горизонтальной стрелке есть параметр фиксация по тайм-ауту. Если установлено значение false, мы переходим в состояние ОТВЕРГНУТО после истечения времени ожидания софт-форка. Но когда для него установлено значение true, то в самый последний период перенацеливания из 2106 блоков мы переходим к состоянию НУЖНО СИГНАЛИТЬ, за которым всегда следует ЗАФИКСИРОВАНО. Другими словами, мы фиксируем состояние прямо перед тайм-аутом, отсюда и название (LOT = Lock-in On Timout).

Другими словами, и при LOT=false, и при LOT=true майнеры могут сигнализировать об обновлении в течение одного года. Затем, если указанный пороговый процент — в случае Taproot, 90 процентов — будет достигнут, происходит его активация. Однако, если он не будет достигнут, могут произойти две вещи. При LOT=false срок действия обновления до Taproot истечет, но если сообщество решит повторить попытку, может быть введен новый период активации для новой версии софта. С LOT=true узлы начнут принимать только те блоки, которые сигнализируют об обновлении, что приводит к принудительной активации.

Сперва, в начале 2021 года, еще не была выпущена версия Bitcoin Core, которая бы активировала Taproot. Команда дожидалась результатов обсуждения в сообществе, каким должен быть соответствующий механизм активации. Таким образом, это другой контекст, чем во время дебатов UASF в 2017 году, когда существовала сборка Bitcoin Core BIP 9 на стадии ЗАПУЩЕНО. Между тем, в начале 2021 года дискуссия вращалась вокруг того, должен ли Bitcoin Core перейти от своей обычной системы развертывания BIP 9 к механизму BIP 8, и если да, то следует ли установить параметр LOT равным true или false.

Переход с BIP 9 на BIP 8 не вызывал особых споров, пока речь шла о его более консервативной инкарнации LOT=false. Но даже такое нельзя вводить бездумно, потому что при внесении любых изменений всегда есть риск, особенно в отношении чего-то столь важного, как код, который решает, какие правила применяются к блокам. Таким образом, все еще сохранялся вопрос: стоит ли переходить на BIP 8 с LOT=false?

Возможно, стоило бы сохранить совместимость с программным обеспечением от независимой группы, которая настаивала на LOT=true (совместимость не должна рассматриваться как одобрение). Но этот спор так и не был решен.

Настоящая полемика развернулась вокруг LOT=true.

Многие люди поддержали LOT=true, поскольку эта опция делала так, что майнеры не могут наложить вето. Контраргументом этому является то, что майнеры все равно не имеют права вето; они могут только задержать намеченную активацию. Это связано с тем, что владельцы узлов всегда могут переключиться на новую версию ПО для нод, где предусмотрен механизм дня Д, и вовсе обойтись без сигнализирования. Но на это потребуется время. ^[Если сообщество не дождется тайм-аута и активирует софт-форк в день Д, тогда любой, кто не обновится до новой версии с днем Д, будет думать, что софт-форк не получилось активировать. Обязательное сигнализирование позволяет избежать необходимости ждать, но за это приходится платить.] Если активация задерживается из-за отсутствия сигнализирования, и при этом LOT=false, то по истечении года обновление будет считаться несостоявшимся. После этого можно было бы развернуть любой новый механизм обновления и, возможно, без какого-либо сигнализирования.

Другим вариантом может быть даже начать с LOT=false, подождать полгода, а затем сказать: «Это занимает слишком много времени. Давайте добавим чуть-чуть риска и установим LOT=true».

Возможно, сами дебаты замедлили активацию Taproot: не было причин полагать, что майнеры будут возражать против Taproot, как некоторые ранее против SegWit, и не было политической драмы вокруг самого Taproot. Было вполне возможно, что BIP 9 или BIP 8 с активацией LOT=false прошли бы гладко, как это происходило в эпоху до SegWit. Но дебаты зашли в тупик, потому что Bitcoin Core, как правило, не выпускается с функциями, которые считаются спорными, а на тот момент все варианты активации были спорными, по крайней мере, для некоторых людей.

Ситуация не была патовой, потому что некоторые люди предпочитали LOT=true. Вспомним процесс грубого консенсуса RFC 7282. Пока люди не возражают против LOT=false (или BIP 9), их предпочтение LOT=true может быть проигнорировано. Потому что в этом случае остались бы только возражения против LOT=true и никаких возражений против LOT=false, и, таким образом, можно было бы внедрить то, против чего никто не возражает.

Но некоторые пошли дальше простого предпочтения LOT=true. Они заявили, что опция LOT=false небезопасна, то есть против нее все же были возражения. Таким образом, имели место два предложения, и против каждого были возражения. То, что эти возражения были поддержаны очень небольшим числом разработчиков, не имело значения. Их нужно было разрешить, т.е. продемонстрировать, что они ошибочны или каким-то образом уже неактуальны. И этот процесс мог и затянулся на какое-то время.

Сценарий разделения цепи

Основное возражение против LOT=true было таким же, как и против UASF: это может привести к разделению цепи. Вспомним приведенную выше ссылку на MAD. Часто звучащий аргумент за LOT=true заключается в том, что разделение цепи — это ужасно — особенно для майнеров, которые не смогут продать свои новые монеты, а значит, этого не произойдет. Предполагается, что этого достаточно, чтобы майнеры послушно сигнализировали. Такая теория игр выходит за рамки этой книги, но мы можем пояснить, на что будет похоже подобное разделение цепочки и почему это плохо.

Ниже приведен один из примеров того, как, если в одной части сети работает LOT=true, а в другой части LOT=false или более старая версия софта, может случиться неприятность в виде разделения цепи.

Допустим, вы используете версию Bitcoin Core с LOT=true и хотите активировать Taproot. Но в нашем сценарии остальной мир, включая большинство майнеров, этого не делает. Наступает день, и вы видите блок, который не сигнализирует правильно, а вы хотите, чтобы он сигнализировал правильно, поэтому вы говорите: «Этот блок теперь недействителен, поэтому я не собираюсь его принимать. Вместо этого я просто подожду, пока другой майнер не предложит блок, соответствующий моим критериям». Допустим, это происходит раз в каждые десять блоков, поэтому вы видите новые блоки, но они появляются очень-очень медленно.

До сих пор можно предположить, что это раздражает, и не более. А теперь давайте положим немного денег на кон. Что если вы пытаетесь, например, получить платеж?

Допустим, кто-то, кто держит узел с LOT=false, отправляет вам 1 BTC. Таким образом, в этом сценарии он находится на ветке, которая растет в 10 раз быстрее, чем ветка, которую видит ваш узел. Предположим также, что блоки на ней не заполнены полностью, поэтому отправитель использует низкую комиссию. На их ветке транзакция быстро подтверждается. Но вы находитесь на своей более короткой и медленной ветке, и все эти транзакции должны быть втиснуты в меньшее количество блоков. Эти блоки полностью заполнены. В вашей ветке транзакцию не подтверждают. Она так и сидит в мемпуле.

На самом деле это относительно благоприятный сценарий. Вы знаете, что не следует принимать неподтвержденные транзакции. У вас возникнут разногласия с контрагентом, вы скажете: «Не подтверждено», а он скажет: «Подтверждено». Если предположить, что вы в курсе про разделение цепи, то вы можете понять, что происходит.

Если бы вы предвидели эту ситуацию, вы бы попросили своего контрагента заплатить гораздо более высокую комиссию, чем предлагает его узел (и, возможно, вычесть ее из суммы). В противном случае вы могли бы использовать штуку под названием «Ребенок платит за родителя» (CPFP), взяв неподтвержденную транзакцию контрагента с низкой комиссией и потратив ее обратно на свой же адрес с очень высокой комиссией. Таким образом, совокупной платы достаточно, чтобы майнеры включили в блок обе транзакции.

Гораздо хуже сценарий, когда ваш контрагент пытается отправить вам монеты, которых нет в вашей ветке. Как такое может произойти? Одна из возможностей заключается в том, что тратится монета, которая происходит от монеты, созданной майнером в его ветке. Каждый блок содержит транзакцию coinbase, которая отправляет майнеру субсидию на блок (6,25 BTC на момент написания) плюс любые сборы за транзакцию. Каждая ветка будет иметь разную последовательность производящих блоки майнеров. Это означает, что в каждой ветке есть уникальные транзакции coinbase, которых нет в другой ветке. Это, в свою очередь, означает, что любые транзакционные расходы из такой транзакции coinbase не могут существовать в другой ветке.

То, что мы сейчас описали, называется воспроизведением транзакции. В случае хардфорка часто желательно предотвратить появление (воспроизведение) транзакций c одной стороны форка на другой стороне. Если для вас эта тема звучит увлекательно, то вам может понравиться презентация автора по ней. В противном случае вам достаточно просто понимать, что хотите ли вы предотвратить повтор или гарантировать его, это в любом случае означает массу проблем.

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

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

Но дальше все становится еще хуже.

Продолжим описанный выше сценарий с короткой веткой, имеющей параметр LOT=true и длинной веткой с LOT=false. Возможно, со временем рыночная цена монет на ветке LOT=true увеличится. Это повышение цен привлекает майнеров, а увеличение активности майнинга увеличивает скорость создания блоков в этой ветке. В свою очередь, это замедляет его на ветке LOT=false.

Это может привести к переломному моменту, когда LOT=true опередит ветку LOT=false. Ваш узел работает нормально. Он работал с веткой LOT=true еще тогда, когда она была короче, и продолжает делать это сейчас, когда она стала длиннее.

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

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

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

Снова переведем это на язык грубого консенсуса RFC 7282: действительно ли достаточно просто заявить, что этот сценарий не произойдет из-за наличия стимулов для его предотвращения? Неужели настолько маловероятно, что нам не нужен даже план на случай непредвиденных обстоятельств? В некоторых городах есть ядерные убежища, несмотря на доктрину MAD из теории игр, хотя в других городах их действительно перепрофилировали в торговые центры. Это больше похоже на политические дебаты, чем на техническую дискуссию.

Наконец, стоит отметить, что все проблемы, с которыми сталкиваются пользователи LOT=false в мире, где есть клиенты с LOT=true, также встречаются у пользователей, которые вообще не обновляли софт. Так что стоит подумать и об отказе от обязательных обновлений.

Клиент сLOT=true - не вредоносное ли это ПО?

На этот раз первым релизом софта с кодом активации Taproot был не Bitcoin Core. Вместо этого два разработчика решили выпустить независимую модифицированную версию Bitcoin Core, которая включала BIP 8 с параметром LOT=true.

В мире opensource каждый может выпускать любую версию программного обеспечения, которую захочет. Точно так же каждый может бесплатно загрузить себе любой вариант, который он хочет. Однако, в дополнение к общим возражениям против LOT=true выше, есть и другие практические вопросы, о которых следует подумать при загрузке такой альтернативной реализации. Мы рассказали об этом выше. В частности, важно убедиться, что вы случайно не загружаете вредоносное ПО (см. главу 9).

Предложение пробного быстрого запуска

Чтобы выйти из этого тупика, на помощь пришло предложение о пробном быстром запуске. Было предложено следующее: «Вместо того, чтобы обсуждать, сигнализировать или нет, и приводить множество аргументов на эту тему, давайте просто по-быстрому попробуем запустить новинку. Предложенный график предполагал, что сигнализирование начнется в начале мая, продлится три месяца (до августа), а затем через три месяца, в ноябре, произойдет активация.

Спойлер: как мы и упоминали в начале главы, Taproot действительно был активирован 13 ноября 2021 года.

Эта схема довольно проста для понимания. По сравнению с BIP 9, разобранным выше, вводится только одна новая концепция: минимальная высота активации. Это добавляет задержку при переходе от ЗАБЛОКИРОВАНО к АКТИВИРОВАНО.

Хотя концептуально это почти то же самое, что и BIP 9, даты, выбранные для Taproot, сильно отличаются от тех, которые были выбраны ранее. Период ожидания перед сигнализированием (ОПРЕДЕЛЕНО), а также период сигнализирования (ЗАПУЩЕНО) намного короче, чем обычно (месяцы вместо полного года). Таким образом, мы могли бы определиться с результатом быстрее.

Быстро узнать результат — это здорово, но спешка может привести к тому, что майнеры станут использовать поддельные сигналы вместо того, чтобы обновляться. Таким образом, чтобы добавить запас прочности, переход от ЗАБЛОКИРОВАНО к АКТИВИРОВАНО был увеличен с обычного однократного периода (две недели) до фиксированной высоты блока, которой предполагалось достичь в ноябре 2021 года. Это было единственное требуемое изменение в коде (гораздо меньшее изменение, чем внедрение BIP 8).

Таким образом, «быстрая» часть относится к выяснению готовности майнеров или, по крайней мере, к выяснению того, нет ли у майнеров каких-то не высказанных ранее возражений или просто апатии. Остальная часть процесса была медленнее и больше походила на День Д. Как только порог по проценту сигнализирующих окажется достигнут, софт-форк будет высечен в камне, то есть будет предположительно состоявшимся, по крайней мере, если люди запустят полные узлы с новым ПО.

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

Пробный быстрый запуск, казалось, в достаточной степени снял возражения против BIP 9. С точки зрения возражающих, из-за того, что все было так быстро, их собственные планы относительно BIP 8 не требовалось откладывать.

Когда разногласия (временно) прекратились, многие разработчики прекратили препирательства и принялись писать код, который бы реализовывал пробный быстрый запуск.

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

И вот Taproot уже на этапе ЗАФИКСИРОВАНО!

Bitcoin Core v0.21.1 с кодом пробного быстрого запуска был выпущен 1 мая 2021 года.

Первый период ретаргетинга начался за неделю до этого релиза, 24 апреля 2021 года, и порог не был достигнут. Второй период ретаргетинга тоже не обеспечил порога, а вот третий оказался чудесен. 90-процентный порог сигнализирования был достигнут 12 июня 2021 года, а через несколько дней статус стал ЗАФИКСИРОВАНО. Он оставался таковым до ноябрьской активации.

Вспомним, что сигнал для софт-форка (BIP 9, BIP 8 или пробный быстрый запуск) — это просто битовый флаг в заголовке блока. Для установки этого бита майнеры используют отдельный софт. В то же время майнеры запускают полные узлы, которые уже на практике обеспечивают соблюдение правил консенсуса. Но если они не обновят свои собственные узлы, то узлы, будучи устаревшими, просто проигнорируют флаг, и не будут применять новые правила. Чтобы применять их, майнерам нужно на самом деле обновить программное обеспечение своего узла.

В целом, желательно, чтобы майнеры действительно обновляли свои узлы и не подделывали сигнал. Это одна из причин, почему время ожидания в BIP 9 было таким долгим. Но из-за того, что быстрый пробный запуск прошел в такой короткий срок, некоторые могли посчитать обновление своего софта слишком рискованным. Другие столкнулись с практическими проблемами при обновлении. Оператор майнингового пула Алехандро Де Ла Торре описал некоторые практические проблемы, с которыми он столкнулся в полевых условиях, в эпизоде подкаста.

В соответствующем разделе более подробно рассказывается о том, что должно было произойти, как только активация Taproot стала неизбежной, прежде чем его можно было бы и впрямь безопасно использовать в сети Биткоина. Мы также объясняем, как будущие версии Bitcoin Core будут работать с обновлениями Taproot, особенно в отношении кода кошелька. На момент написания статьи существует некоторая базовая поддержка кошелька Taproot, но она все еще находится в стадии разработки.

Двигаемся дальше

Поскольку быстрый пробный запуск прошел успешно, возможно, мы сможем использовать такой способ в качестве шаблона для активации софт-форков в будущем. Или мы могли бы интерпретировать отсутствие драмы как аргумент в пользу того, чтобы просто придерживаться BIP 9 или версии BIP 8 с LOT = false. Возможно, некоторые аспекты развертывания LOT = true можно сделать более безопасными.

Даже если такой механизм небезопасен по своей сути, может иметь смысл продолжить его разработку, имея уже готовый код на случай, если он когда-нибудь понадобится. Возможно, софт Bitcoin Core мог бы иметь его общую поддержку, даже если сам проект не рекомендует его использовать. Лучшее время для размышлений о таких вещах — это когда они еще не нужны.

Захоронение софтфорков

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

Как и в случае с предыдущими софтфорками, похоже, что будущий выпуск Bitcoin Core «похоронит» активацию Taproot. Это означает, что узел будет относиться к правилам Taproot так, как если бы они были активны с самого начала существования Биткоина. Это возможно, потому что при ретроактивном применении этих правил им не соответствует только один исторический блок. Этот блок может быть унаследован.

В этом разделе мы объясняем, в чем преимущества захоронения софтфорка, в частности, указываем, как это помогает разработчикам, когда они анализируют кодовую базу Bitcoin Core или когда проводят ее тестирование.

После этого мы обрисовываем потенциальный пограничный сценарий, когда захоронение софт-форков может, в худшем случае, разделить блокчейн Биткоина между обновленными и необновленными узлами. Разработчики Bitcoin Core, как правило, не рассматривают этот пограничный случай — очень длинную реорганизацию блока — как реальную проблему и/или считают, что это будет настолько серьезной проблемой, что скрытый софт-форк будет относительно незначительной ее частью. Однако, как мы поясняем, не все полностью согласны с этой оценкой.

Поддержите проект(ы) на цепочке

HCN имеет две активные краудфандинговые компании на TallyCoin, которые собирают средства ончейн:

https://tallycoin.app/@hypecoinnews/

/send 100 [email protected]

Приложение: Еще несколько эпизодов

Не все эпизоды подкаста Биткоин, разъяснения вошли в эту книгу. Вот некоторые другие эпизоды, которые вы можете послушать. Приведенные ниже описания в основном основаны на заметках к шоу, написанных соведущим Аароном ван Вирдумом.

Основы

Что такое xpub?

В этом эпизоде мы объясняем, что такое расширенный открытый ключ (xpub) и как он используется биткоин-кошельками. Расширенные ключи были впервые представлены в BIP 32 для создания так называемых иерархических детерминированных кошельков. Такие кошельки создают новый адрес каждый раз, когда пользователь хочет получить монеты. В отличие от более ранних кошельков, которые требовали хранить в безопасном месте каждый новый адрес, этим новым кошелькам требуется только одна резервная копия, обычно в виде мнемонической фразы из 12-24 слов BIP 39.

Replace-By-Fee (RBF)

В этом выпуске мы рассказываем о замене комиссии (Replace-By-Fee или RBF). RBF — это трюк, который позволяет заменить неподтвержденные транзакции конфликтующими транзакциями, которые включают более высокую комиссию.

С помощью RBF пользователи могут существенно увеличить комиссию за транзакцию, чтобы стимулировать майнеров включать ее в блок. Мы подробно описываем три преимущества RBF: возможность «ускорить» транзакцию (1), что, в свою очередь, может привести к более эффективному рынку комиссий за пространство в блоке (2), и потенциал более эффективного использования пространства в блоках за счет обновления транзакций на те, что включают больше получателей (3).

Основной недостаток RBF состоит в том, что он немного упрощает двойную трату неподтвержденных транзакций, что также было причиной споров о двойных тратах, которые доминировали в заголовках в начале 2021 года.

Мы обсуждаем некоторые решения для снижения этого риска, в том числе «opt-in RBF», который реализован в настоящее время в Bitcoin Core.

Наконец, мы подробно объясняем, как работает opt-in RBF и какие условия должны быть выполнены, прежде чем транзакция будет считаться заменяемой. В процессе мы отмечаем некоторые сложности, связанные с этой версией RBF — например, в контексте сети Lightning.

Signet

Signet — это новый тип тестовой сети для Биткоина. В этом выпуске мы обсуждаем первоначальную версию блокчейна для публичного тестирования (тестнет) и обрисовываем ее проблемы. Затем мы объясняем, почему сигнеты по своей природе похожи на тестнет, но более надежны и могут централизованно управляться. Сигнет — их может быть больше одной — обеспечивается путем добавления дополнительного требования к подписи для проверки блокировки (отсюда и «sig»).

Мемпулы, Ребенок Платит за Родителя и Ретрансляция пакетов

В этом эпизоде мы обсуждаем пулы памяти Биткоина (мемпулы), опцию Ребенок Платит за Родителя (Child Pay For Parent или CPFP) и ретрансляцию пакетов.

Ретрансляция пакетов — это проект, над которым Глория Чжао работает в рамках своей стипендии Brink. Это сделало бы сеть Lightning более надежной (помимо других преимуществ). Мемпулы — это наборы неподтвержденных транзакций, хранящиеся в узлах. Затем узлы пересылают эти неподтвержденные транзакции из своего мемпула другим узлам. Майнеры обычно выбирают те транзакции из своего мемпула, которые включают самые высокие комиссии, и включают их в добываемые ими блоки.

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

В этом эпизоде мы подробно рассказываем о том, как ретранслятор пакетов может обеспечить CPFP — даже в случаях, когда транзакции с низкой комиссией удаляются из мемпулов — путем объединения транзакций в пакеты. Мы также исследуем, почему это легче сказать, чем сделать.

Смерть мемпулу, да здравствует мемпул!

Здесь мы обсуждаем недавнюю ветку в списке рассылки разработчиков Биткоина под названием «Смерть мемпулу, да здравствует мемпул».

В треде инженер Blockstream Лиза «niftynei» Нейгут предлагает избавиться от пула памяти (мемпула), представляющего собой набор неподтвержденных транзакций, который биткоин-узлы используют для обмена транзакциями по сети, а биткоин-майнеры для создания новых блоков. Она утверждает, что систему Биткоина можно значительно упростить, если вместо этого пользователи будут просто отправлять свои транзакции напрямую майнерам (или майнинг-пулам).

В эпизоде мы объясняем, как это будет работать и почему это не так просто, как может показаться. Мы обращаемся к ответам в ветке, рассматривая причины, по которым избавление от мемпула на самом деле не очень хорошее решение для такой системы, как Биткоин. Особое внимание уделяется последствиям, которые это может иметь для конфиденциальности и децентрализации майнинга. Также мы рассматриваем некоторые другие компромиссы, на которые необходимо пойти, чтобы заставить систему Биткоина работать без мемпула.

Процесс предложений по улучшению Биткоина (BIP)

В этом эпизоде мы объясняем, что такое предложения по улучшению Биткоина (Bitcoin Improvement Proposals или BIP) и как работает процесс BIP. Мы обсудим, почему процесс BIP - это полезное, но необязательное соглашение в техническом сообществе Биткоина.

Во-первых, мы объясняем, чем является BIP, а чем точно не является. Мы также объясняем, что BIP требуют только улучшения кода Биткоина, которые затрагивают другие проекты. Затем мы немного углубляемся в историю процесса BIP, отметив, что формат был представлен разработчиком Libbitcoin Амиром Тааки, а позже обновлен держателем Bitcoin Knots Люком Дашем-младшим.

Наконец, мы рассказываем, как работает сам процесс BIP, то есть как предложение может быть преобразовано в BIP и в конечном итоге реализовано в софте. Мы также кратко объясняем, как процесс BIP может быть нарушен и почему это не будет иметь большого значения.

Использование ресурсов

Компактная фильтрация на стороне клиента (Neutrino)

В этом выпуске мы обсуждаем компактную фильтрацию на стороне клиента, также известную как Neutrino. Это решение для использования Биткоина без необходимости загружать и проверять всю цепочку блоков и не жертвуя своей конфиденциальностью в пользу кого-либо, кто управляет полным узлом (и, следовательно, загружал и проверял всю цепочку блоков).

Загрузка и проверка всего блокчейна Биткоина может занять пару дней даже на стандартном ноутбуке, а на смартфонах и других компьютерах с ограниченной производительностью требуется гораздо больше времени. Вот почему многие люди предпочитают использовать легкие клиенты. Они не так безопасны, как полные биткоин-узлы, но для их работы требуется меньше вычислительных ресурсов.

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

Компактная фильтрация на стороне клиента — это новое решение для достижения целей, аналогичных SPV, но без потери конфиденциальности. Вкратце, это работает за счет того, что операторы полных узлов создают криптографическую структуру данных, которая сообщает пользователю легкого клиента, мог ли блок содержать активность, относящуюся к запрошенным адресам, поэтому пользователь может отслеживать свои средства, загружая только небольшое подмножество всех блоков Биткоина.

Мы объясняем более детально, как это работает, и обсуждаем некоторые компромиссы этого решения.

Компактные блоки

Мы объясняем, как одноранговая сеть Биткоина становится более эффективной и быстрой с помощью компактных блоков.

Компактные блоки — это, как следует из названия, компактные версии блоков Биткоина, которые использовались узлами Bitcoin Core, начиная с версии 0.13. Компактные блоки содержат минимальное количество данных, необходимых узлам Биткоина для восстановления целых блоков. В частности, компактные блоки исключают большинство данных транзакций и вместо этого содержат короткие идентификаторы транзакций. Биткоин-узлы могут использовать эти короткие идентификаторы, чтобы выяснить, какие транзакции из их мемпулов следует включить в блоки.

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

Вы также можете посмотреть презентацию Грега Максвелла о достижениях в распространении блоков или прочитать расшифровку.

Erlay

В этом эпизоде мы обсуждаем протокол Erlay. Erlay — это предложение уменьшить пропускную способность, необходимую для работы узла Биткоина. Он был предложен и разработан исследователями Университета Британской Колумбии Глебом Науменко, Александрой Федоровой и Иваном Бесчастных; инженером Blockstream Питером Вуилле; и независимым участником Bitcoin Core Грегори Максвеллом.

Биткоин-узлы используют полосу пропускания для приема и передачи как данных блоков, так и данных транзакций. Уменьшение пропускной способности, необходимой узлу для всего этого, удешевит работу узла. Или, как вариант, это позволило бы узлам подключаться к большему количеству одноранговых узлов без увеличения использования полосы пропускания.

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

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

Атаки

Атака искажения времени

В этом эпизоде мы объясняем «атаку искажения времени» на Биткоин. Потенциальное исправление против этой атаки включено в софт-форк Great Consensus Cleanup, предложенный Мэттом Коралло, однако ко времени написания в его разработе не наблюдалось особого прогрессса.

Атаки PSBT и RBF

В этом эпизоде мы разбираем и объясняем частично подписанные биткойн-транзакции (PSBT) и транзакции с заменой комиссии (RBF), а также некоторые действительно хитрые атаки, которые были обнаружены.

PSBT — это формат данных, который позволяет кошелькам и другим инструментам обмениваться информацией о биткоин-транзакциях и подписях, необходимых для ее завершения.

Цензура майнинг-пулов

В этом эпизоде мы обсуждаем появление Mara Pool, американского пула по майнигу биткойнов, который — на момент записи этого эпизода — утверждал, что полностью соответствует законодательству США. Это означает, что он применяет проверки по борьбе с отмыванием денег (AML) и придерживается санкционного списка Управления по контролю за иностранными активами (OFAC). Хотя детали не были обнародованы, это, по-видимому, означает, что данный пул не будет включать транзакции в блоки, если эти транзакции отправляют монеты на (или с) включенные в черный список OFAC биткоин-адреса.

Через некоторое время после записи эпизода пул изменил курс и объявил, что не будет подвергать транзакции цензуре.

В этом эпизоде мы обсуждаем перспективы цензуры майнинга, что это будет означать для Биткоина и что с этим можно сделать. Мы рассматриваем под более широким углом, на что было бы похоже, если бы такая практика была принята многими. Мы рассматриваем, чего могут добиться пулы майнинга в своей политике цензуры, если они когда-либо приблизятся к контролю над большей частью хэш-мощности, и что потенциально смогут сделать пользователи Биткоина в таком сценарии (если вообще что-либо смогут).

Кошельки

Интеграция аппаратных кошельков в Bitcoin Core

Мы обсуждаем интеграцию аппаратных кошельков в Bitcoin Core - это один из текущих проектов, в которых Щорс регулярно участвует.

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

Безопасность аппаратных кошельков и кошелек Jade

К соведущему Аарону присоединяются Лоуренс Наум из Blockstream, один из разработчиков аппаратного кошелька Jade, и Бен Кауфман, один из разработчиков Spectre Desktop — программного инструментария для аппаратных кошельков.

Они рассказывают о том, что такое аппаратные кошельки, и обсуждают компромиссы при разработке различных моделей, уделяя особое внимание устройствам Trezor, Ledger и Coldcard. В этом свете Лоуренс и Бен объясняют, что такое безопасные элементы и безопасные чипы, и почему некоторые аппаратные кошельки в большей мере, чем другие, предпочитают использовать такие чипы.

Затем Лоуренс объясняет, на какие компромиссы идет кошелек Jade. Он также подробно описывает, какой дополнительный серверный слой безопасности используется для защиты кошелька Jade, и кратко описывает некоторые дополнительные различия в дизайне аппаратных кошельков, например те, которые ориентированы на удобство использования.

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

Bitcoin Beach

Соведущий Аарон беседует с разработчиком Bitcoin Beach Wallet Николасом Берти в Эль-Зонте, Сальвадор, который получил название Bitcoin Beach, чтобы обсудить Bitcoin Beach Wallet, биткоин-кошелек с поддержкой лайтнинга, специально разработанный для использования в небольшом прибрежном городке Центральной Америки, который часто посещают серферы, а теперь и биткоинеры.

Они обсуждают плюсы и минусы кастодиальных и некастодиальных лайтнинг-кошельков, а Николас объясняет, почему он решил сделать Bitcoin Beach Wallet кошельком с общим хранилищем, и что это означает.

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

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

Chivo

В этом выпуске мы обсуждаем приложение Chivo, биткоин-кошелек и платежный терминал, предоставляемый правительством Сальвадора. Приложение Chivo - это софт с закрытым исходным кодом. Вместо анализа исходного кода и дизайна приложения нам пришлось полагаться на личный опыт работы с кошельком и платежным терминалом.

Выпуск начинается с некоторой общей информации о кошельке Chivo, например, почему он был разработан и кто его разработал (насколько об этом известно). Мы обсуждаем опыт Аарона в использовании кошелька и размышляем, что это означает в плане дизайна. После этого мы обсуждаем дизайн платежного терминала, включенного в приложение, а также кратко касаемся банкоматов Chivo, развернутых по всей стране. Наконец, мы обсуждаем разницу в философии между дизайном приложения Chivo и культурой бесплатного и открытого программного обеспечения Биткоина.

Платежные пулы

В этом выпуске мы объясняем, что такое платежные пулы и зачем им нужен Taproot. Мы обсуждаем, как на практике работает объединения UTXO, и то, как платежные пулы могут работать с сетью Лайтнинг.

Для получения дополнительной информации см. статью Аарона.

Учетные записи Easypaysy

Мы обсуждаем easypaysy, предложенную Хосе Фемениасом - систему учетных записей для Биткоина, на блокчейне Биткоина. Одна из функций, которую она поддерживает - скрытые метки адресов. Мы обсудим несколько вариантов использования. Наконец, мы объясняем, что такое безотказность.

Аарон также написал статью об easypaysy для журнала Bitcoin Magazine.

Лайтнинг

О сети Лайтнинг можно написать целую книгу. Многие и впрямь это сделали, см., например. Освоение сети Лайтнинг, протокола второго уровня над блокчейном для мгновенных платежей в биткоинах Андреас М. Антонопулос и Олаолува Осунтокун (он же Roasbeef).

В этой книге не рассматривается Lightning, но есть несколько выпусков подскаста Bitcoin, Explained, где это делается.

Основы

Тут мы обсуждаем основы сети Лайтнинг, протокола второго уровня над Биткоином, для более дешевых, быстрых и, возможно, более конфиденциальных транзакций. Мы объясняем, что сеть Лайтнинг работает как способ масштабирования, поскольку позволяет пользователям совершать транзакции вне блокчейна через двунаправленные платежные каналы: два пользователя могут платить друг другу произвольное количество раз без записи этих транзакций в блокчейне. Далее мы объясняем, как в протоколе Лайтнинг обеспечивается безопасность этих транзакций вне сети, то есть как каждый из участников в любой момент может гарантированно получить свои соответствующие средства из платежного канала.

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

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

Ошибка RBF в Bitcoin Core

Мы обсуждаем CVE-2021-31876, ошибку в коде Bitcoin Core, которая влияет на дочерние транзакции Replace-By-Fee (RBF). В системе "Распространенные уязвимости и риски" (Common Vulnerabilities and Exposures, CVE) предлагается обзор общеизвестных программных ошибок. Антуан Риар обнаружил и раскрыл новую ошибку в коде Bitcoin Core, и она была добавлена в обзор CVE.

Мы объясняем, что ошибка влияет на то, как логика RBF обрабатывается программным обеспечением Bitcoin Core. Когда одна неподтвержденная транзакция имеет флаг RBF (это означает, что ее следует считать заменяемой, если по сети транслируется конфликтующая транзакция с более высокой комиссией), любая последующая транзакция, которая тратит монеты из исходной транзакции, также должна считаться заменяемой — даже если вторая транзакция сама по себе не имеет флага RBF. Однако программное обеспечение Bitcoin Core этого не делает, а это означает, что вторая транзакция по факту не будет считаться заменяемой.

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

Маршрутизация

К нам присоединился лайтнинг-разработчик Джуст Джагер, чтобы обсудить все, что касается сетевой маршрутизации Лайтнинга.

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

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

Джуст объясняет, как лайтнинг-узлы в настоящее время создают карту сети Лайтнинга и какая информация обо всех (общедоступных) платежных каналах включена в эту карту. Затем он описывает, на основании чего лайтнинг-узлы рассчитывают лучший путь по сети, чтобы достичь получателя платежа, и как производительность этого маршрута влияет на будущие вычисления при поиске пути.

Наконец, мы обсудим некоторые (потенциальные) оптимизации для улучшения сетевой маршрутизации Лайтнинга, такие как схемы ребалансировки и trampoline-платежи.

Оптимально надежные и дешевые платежные потоки в сети Лайтнинг

В этом выпуске мы берем интервью у другого эксперта по маршрутизации в Лайтнинге, Рене Пикхардта. Мы обсуждаем его статью Оптимально надежные и дешевые платежные потоки в сети Лайтнинг.

Цитируя аннотацию:

Сегодня платежные маршруты в сети Лайтнинга находятся путем поиска кратчайших путей на графике комиссий. Мы совершенствуем этот подход в двух измерениях. Во-первых, мы учитываем вероятность того, что платеж действительно возможен, поскольку распределение баланса в каналах неизвестно. Во-вторых, мы используем потоки с минимальными затратами как правильное обобщение кратчайших путей ко многоэтапным платежам (multi-part payments, MPP). В частности, мы показываем, что при правдоподобных предположениях о распределении баланса мы можем найти наиболее вероятный MPP для любого заданного набора отправителей, получателей и сумм, находя (обобщенный) целочисленный поток минимальных затрат с отделимой и выпуклой функцией затрат. Для этой задачи оптимизации известны как точные алгоритмы с полиномиальным временем, так и аппроксимации. Мы представляем поэтапный алгоритм расчета потока с минимальной стоимостью для доставки больших сумм платежей через сеть Лайтнинг. Этот алгоритм работает, обновляя распределения вероятностей с помощью информации, полученной как от успешных, так и от неудачных путей на предыдущих этапах. Во всех наших экспериментах было достаточно однозначного числа этапов для доставки платежей, размер которых был близок к общему локальному балансу отправителя. Ранние эксперименты показывают, что наш подход увеличивает размер платежей, которые могут быть надежно доставлены, на несколько порядков по сравнению с текущим уровнем техники. Мы видим, что поиск самых дешевых многоэтапных платежей является NP-сложной задачей, в рамках текущей структуры комиссий, и предлагаем отказаться от базовой комиссии, чтобы сделать такой поиск линейной задачей потока минимальных затрат. Наконец, мы обсуждаем возможности максимизации вероятности при одновременном снижении платы за поток. Хотя в общем виде это также оказывается сложной задачей — даже в случае с одним путем — на практике она оказывается на удивление решаемой.

Eltoo и SIGHASH_ANYPREVOUT

Мы рассмотрели эту тему дважды, поэтому на выбор есть два выпуска. В выпуске 35 мы объясняем, что это такое, а в выпуске 48 к нам присоединяется один из авторов, разработчик c-lightning Кристиан Декер, чтобы объяснить это своими словами.

Во-первых, мы обсудили SIGHASH_ANYPREVOUT, предлагаемый новый флаг sighash, который позволит использовать более чистую версию сети Лайтнинг и других протоколов второго уровня. Флаги sighash включаются в биткоин-транзакции, чтобы указать, какая часть транзакции подписана требуемыми закрытыми ключами.

Это может быть (почти) вся транзакция или отдельные ее части. Подписание только определенных частей обеспечивает некоторую гибкость в настройке транзакции даже после ее подписания, что иногда может быть полезно. Мы объясняем, что SIGHASH_ANYPREVOUT — это новый тип флага sighash, который будет подписывать большую часть транзакции, но не входные данные. Это означает, что входные данные можно поменять местами, если новые входные данные будут по-прежнему совместимы с подписью.

SIGHASH_ANYPREVOUT будет особенно полезен в контексте Eltoo, предлагаемого протокола второго уровня, который позволит создать новую версию сети Лайтнинг. В настоящее время пользователям Лайтнинга из соображений безопасности необходимо хранить старые данные канала, а если они случайно передают некоторые из этих данных в неподходящее время, они могут быть сурово наказаны. Мы обсуждаем, как SIGHASH_ANYPREVOUT может покончить с этим требованием.

Bolt 12 — регулярные платежи и т.д.

Мы обсуждаем Основание 12 Технологии Лайтнинга (Basis of Lightning Technology 12 или BOLT 12), недавно предложенную спецификацию сети Лайтнинг для «офферов», которые представляют собой разновидность «мета-инвойсов», созданную разработчиком c-lightning Расти Расселом.

В то время как монеты на базовом уровне Биткоина отправляются на адреса, сеть Лайтнинг использует инвойсы. В инвойсах сообщается запрошенная сумма, узел назначения и хэш секрета, который используется для маршрутизации платежей. Это работает, но имеет ряд ограничений — в частности, то, что сумма должна быть номинирована в биткоинах (в отличие от деноминированных в фиате), а также то, что инвойс может быть использован только один раз.

BOLT 12, реализованный в c-lightning, представляет собой способ, по сути, направить плательщика к узлу, на который должен идти платеж, чтобы запросить новый инвойс. Хотя оффер BOLT 12 может быть статическим и многократно используемым — он всегда относится к одному и тому же узлу — получатель платежа может генерировать новые офферы на лету по запросу, что обеспечивает гораздо большую гибкость.

Наконец, мы обсуждаем, как новые сообщения BOLT 12 передаются по сети Лайтнинг посредством обновления спецификации BOLT 7 для ретрансляции сообщений.

Сайдчейны и многое другое

Лайтнинг — не единственный путь масштабирования Биткоина, хотя на данный момент он разрабатывается наиболее активно. Еще один подход - это сайдчейны, и их можно при желании комбинировать с Лайтнингом.

Хотя общепринятого определения того, что такое сайдчейн, не существует, общая идея заключается в том, что вы создаете отдельный блокчейн со своими собственными правилами, который каким-то образом привязан к блокчейну Биткоина. Преимущество этого подхода, в теории, заключается в том, что только узлы, которые обслуживают конкретный сайдчейн, должны его проверить, в то время как остальная часть сети должна только убеждаться, что количество биткоинов, покидающих сайдчейн, не превышает количество поступающих в него.

Мы обсуждаем в подкасте некоторые из этих идей, часто с помощью специального соведущего из Утрехта Рубена Сомсена.

Драйвчейны

Драйвчейн — это сайдчейн-проект, возглавляемый Полом Шторцем.

Это должно сделать монеты сайдчейна взаимозаменяемыми с биткоинами, и, следовательно, они должны иметь равную стоимость. В некотором смысле сайдчейны позволяют пользователям «перемещать» биткоины между блокчейнами, где они подчиняются другим правилам протокола, что обеспечивает большую емкость транзакций, большую конфиденциальность и другие преимущества. Мы объясняем, что Драйвчейн состоит из двух основных инноваций.

Первая — это слепой объединенный майнинг (Blind Merged Mining, BMM), который позволяет биткоин-майнерам защищать драйвчейн с помощью существующей хеш-мощности, но без обязательной проверки всего, что происходит в сайдчейне.

Вторая — это арбитры хэшрейта (Hashrate Escrows), которые позволяют майнерам «перемещать» монеты из блокчейна Биткоина в сайдчейн и обратно.

Также мы обсуждаем некоторые преимущества и сложности Драйвчейна — в первую очередь последствия для безопасности, связанные с предоставлением майнерам возможности контролировать процесс привязки к конкетному блокчейну. Мы рассматриваем аргументы о том, почему этот процесс совместим по стимулам (что важно для безопасности) — или почему может быть несовместим.

Вечные Односторонние Привязки (Perpetual One-Way Pegs)

Рубен объясняет свое предложение комбинировать слепой объединенный майнинг и вечные односторонние привязки для создания сайдчейна нового типа. Плохая новость: это не сделает вас богатым, но может помочь масштабировать Биткоин!

Во-первых, он вводит концепцию цепи слепого слияния. Затем он объясняет варианты использования вечной односторонней привязки и того, что такое объединенный майнинг. Затем мы переходим к вечным односторонним привязкам и пытаемся ответить на вопрос: почему монета сайдчейна может хоть что-нибудь стоить?

Запись в блоге Рубена также объясняет эту концепцию.

Софтчейны

На этот раз мы обсуждаем одно из собственных предложений Рубена - софтчейны.

Софтчейны — это тип сайдчейнов с двухсторонней привязкой, в которых используется новый тип механизма консенсуса: доказательства мошенничества с proof-of-work (или, как предпочитает их называть Сьорс, индикаторы мошенничества с proof-of-work). Используя этот механизм консенсуса, пользователи не проверяют содержимое каждого блока, а только проверяют заголовок proof-of-work, как это делают клиенты с упрощенной проверкой платежей (Simplified Payment Verification, SPV). Но, используя доказательства мошенничества с proof-of-work, пользователи проверяют все содержимое блоков каждый раз, когда происходит разветвление блокчейна. Это предлагает промежуточную по уровню безопасности модель безопасностью полного узла и безопасностью SPV.

Рубен объясняет, что, используя доказательство мошенничества с proof-of-work в сайдчейнах для создания Софтчейнов, полные биткоин-узлы могут проверять целые сайдчейны с минимальными затратами. Эта новая модель может быть полезна для определенных типов сайдчейнов, в первую очередь для сайдчейнов с «увеличением размера блока», которые не делают ничего особенного, но предлагают большую емкость транзакций. Мы также обсуждаем некоторые недостатки модели Софтчейн.

Стейтчейны

Мы обсуждаем еще одно из предложений Рубена: стейтчейны для Биткоина. Стейтчейны позволяют вам отправлять ключи вместо UTXO, плюс предлагается довольно много улучшений масштабирования и функциональности.

Вы также можете глянуть презентацию Рубена о стейтчейнах в журнале Bitcoin Magazine, а также статью Аарона в журнале Bitcoin Magazine.

RSK, федеративные сайдчейны и Powpeg

Мы обсуждаем переход RSK от федеративной модели сайдчейна к Powpeg, новому способу организации проекта.

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

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

До сих пор RSK делал это, привязывая монеты к адресу с мультиподписью, закрытые ключи которого контролировались группой известных компаний (это известно как модель федеративной боковой цепи). Для разблокировки монет требовалось большинство, и оно подписывало транзакцию разблокировки только в том случае, если и когда соответствующие монеты боковой цепи были заблокированы.

Теперь RSK переходит на модель Powpeg, в которой ключи к мультиподписному адресу контролируются специальными аппаратными модулями с защитой от несанкционированного доступа, которые, в свою очередь, запрограммированы на разблокировку монет в блокчейне Биткоина только в том случае, если и когда соответствующие монеты в сайдчейне заблокированы, и транзакции по блокировке этих монет имеют значительное количество подтверждений.

Мы объясняем, как именно это работает, и обсуждаем некоторые компромиссы безопасности Powpeg.

Прочие способы использования блокчейна RGB

К нам присоединился Рубен Сомсен, чтобы обсудить токены RGB - биткоин-протокол второго уровня для поддержки систем альтернативных валют и токенов (например, популярных в настоящее время невзаимозаменяемых токенов или NFT).

Мы объясняем, что блокчейн Биткоина использовался пользователями для хранения данных с первых дней существования проекта. Первоначально это делалось с помощью бесполезных выходов транзакций, а это означало, что все пользователи Биткоина должны были хранить эти данные локально. Функция под названием OP_RETURN позже снизила эту нагрузку. Мы также объясняем, что люди уже давно используют блокчейн Биткоина для размещения систем альтернативных валют и токенов.

Несколько лет назад Сьорс также выступил с презентацией об RGB и более ранних попытках использования блокчейна Биткоина для хранения неденежных сущностей.

OpenTimestamps

В этом эпизоде мы обсуждаем OpenTimestamps, проект по ведению отметок времени на основе Биткоина, разработанный консультантом по прикладной криптографии и бывшим участником Bitcoin Core Питером Тоддом. OpenTimestamps использует безопасность блокчейна Биткоина для добавления отметки времени к любому типу данных, что позволяет неопровержимо доказать, что эти данные существовали в определенный момент времени.

Мы объясняем, что практически любой объем данных может быть помечен временной меткой в блокчейне Биткоина с минимальными затратами, потому что OpenTimestamps использует деревья Меркла, криптографический прием для объединения данных в единый компактный хэш. Затем этот хэш включается в биткоин-транзакцию, что делает все данные, объединенные в хеш, такими же неизменяемыми, как и любая другая биткоин-транзакция.

Примерно в то время, когда был записан эпизод, Питер предложил интересную демонстрацию OpenTimestamps, поскольку он доказал, что открытый ключ, используемый Google для подписи вызвавшего разногласия письма Хантеру Байдену, существовал еще в 2016 году.

Мы также обсуждаем некоторые другие возможности, которые предлагает система временных меток, такая как OpenTimestamps, а также ее ограничения. Наконец, Аарон дает небольшой контекст истории криптографических отметок времени, на которых основывался whitepaper Биткоина.

Мы присвоили исходному тексту этой книги отметку времени, чтобы вы могли убедиться, что черновая версия существовала еще в марте 2022 года:

c=86a7cd200acb1812b6b2f8be27c8380ea44c9470
git verify-commit $c
git cat-file -p $c > meta/commit
ots verify meta/commit.ots

Приведенный выше сценарий проверки также находится в репозитории исходного кода вместе с файлом временной метки .ots, который вам необходим для проверки: https://btcwip.com/ots

Discreet Log Contracts

В этом выпуске к нам снова присоединился местный эксперт по сайдчейнам и протоколам второго уровня Рубен Сомсен, на этот раз для обсуждения Discreet Log Contracts (DLC).

DLC — это тип смарт-контрактов для Биткоина, который впервые предложил Тадж Дрийя, соавтор whitepaper Lightning Network. По сути, DLC — это способ делать ставки, но это означает, что в конечном итоге их можно использовать для всех видов финансовых инструментов, включая фьючерсные рынки, страховки и стейблкоины.

В начале выпуска мы обсуждаем то, что можно считать чем-то вроде прото-DLC, а именно вид мультиподписной транзакции для ставок на спорт, когда два участника добавляют нейтральную третью сторону («оракул»), которая, если потребуется, может разрешить ставку в пользу одной или другой стороны. Однако мы объясняем, почему это решение имеет ряд недостатков, таких как сложность его масштабирования.

Далее мы продолжаем объяснять, как DLC решили эти проблемы, используя инструмент, напоминающий каналы оплаты, применяемые в сети Lightning. При такой структуре оракулы просто должны опубликовать криптографически подписанное сообщение об исходе события, которое может быть использовано выигравшим участником пари для создания транзакции вывода из платежного канала.

Наконец, мы объясняем, как первоначальную концепцию DLC можно упростить с помощью подписей адаптера, своего рода «неполной подписи», которую можно сделать полной, используя подписанное сообщение от оракула. С подписями адаптера для DLC больше не требуется отдельная транзакция вывода средств, поскольку победитель может запросить средства напрямую из платежного канала.

Software Releases

Bitcoin Core v0.21

В этом эпизоде мы обсуждаем Bitcoin Core 0.21.0, 21-й основной релиз программного клиента Bitcoin Core. Bitcoin Core — старейшая и наиболее важная реализация узла Биткоина, которую часто также считают эталонной реализацией протокола Биткоина.

Руководствуясь примечаниями к выпуску Bitcoin Core 0.21.0, мы обсуждаем наиболее важные изменения в этом выпуске. К ним относятся новая политика мемпула для ретрансляции транзакций, поддержка Tor v3, одноранговые привязки при перезапуске узла, BIP 157 (Neutrino) для легких клиентов, новая тестовая сеть под названием Signet, BIP 339 (ретранслятор wtxid), код Taproot, изменения RPC, включая новый RPC для отправки, ZeroMQ, дескрипторные кошельки, новая система баз данных SQLite и деноминация комиссии в виде сатоши за байт.

Для каждой из новых функций мы обсуждаем, что это за функции, как они изменят использование Биткоина (Core) и — где это уместно — какова конечная цель нововведения. (При разработке Bitcoin Core новые функции часто являются частью более крупного процесса.) Для каждой функции, которую мы обсуждали в предыдущем выпуске Bitcoin, Explained, мы также указываем соответствующий номер выпуска.

Bitcoin Core v22.0

В этом выпуске мы обсуждаем Bitcoin Core 22.0, следующий крупный релиз программного клиента Bitcoin Core.

Первое из обсуждаемых обновлений — поддержка аппаратного кошелька в графическом пользовательском интерфейсе (GUI). Хотя поддержка аппаратного кошелька была развернута в нескольких предыдущих релизах Bitcoin Core, теперь она полностью доступна в графическом интерфейсе. Второе важное обновление — это поддержка Invisible Internet Project (I2P), конфиденциальный слой интернета, наподобие Tor. Также мы кратко коснулись различий между I2P и Tor.

Третье обновление, обсуждаемое в эпизоде — это поддержка Taproot. Хотя логика активации Taproot уже была включена в Bitcoin Core 0.21.1, Bitcoin Core 22.0 — это первый крупный релиз Bitcoin Core, готовый поддерживать Taproot, хотя и с ограниченной функциональностью.

Четвертое обновление, которое мы обсуждаем — это обновление логики testmempoolaccept, которое прокладывает путь к более крупному обновлению ретранслятора пакетов. В будущих релизах это может позволить передавать транзакции по сети Биткоина пакетами, включающими несколько транзакций одновременно.

Кроме того, мы кратко обсуждаем расширение для создания мультиподписных адресов, новую опцию NAT-PMP и многое другое.

Синхронизация старых биткоин-узлов

Мы обсуждаем исследование, проведенное соучредителем и техническим директором CasaHODL Джеймсоном Лоппом, а также исследование Сьорса по синхронизации старых узлов Биткоина.

Всякий раз, когда новый биткоин-узел подключается к сети, он должен сначала синхронизироваться с остальной частью сети Биткоина: он должен загрузить и проверить всю цепочку блоков до самого последнего блока, чтобы быть в курсе текущей ситуации по владению биткоинами. Однако это может занять некоторое время, и чем дальше, тем больше, поскольку блокчейн продолжает расти. Чтобы компенсировать это и улучшить взаимодействие с пользователем в целом, разработчики Bitcoin Core стремятся повысить производительность кода Bitcoin Core, чтобы новые версии синхронизировались быстрее, чем их предшественники.

В этом выпуске мы рассказываем об улучшении производительности клиентов Bitcoin Core с течением времени, что было недавно проанализировано в двух постах в блоге Джеймсона. Сначала мы объясняем, почему у некоторых очень старых биткоин-клиентов вообще возникают проблемы с синхронизацией текущего состояния блокчейна, указав на некоторые ошибки в этом раннем софте, а также проблемы, связанные с зависимостями, и сложности использования сегодня таких старых клиентов (некоторые из них мы рассмотрели в главе 4). Затем мы суммируем некоторые из наиболее важных улучшений производительности, которые были включены с течением времени в новые выпуски Bitcoin Core.

На рисунке на следующей странице показан результат анализа за 2017 год.

/send 100 [email protected]