Обзор предстоящего релиза Bitcoin Core 0.15 – повышение производительности и другие улучшения

На недавнем митапе для разработчиков биткоина в Сан-Франциско была презентована новая версия программного обеспечения Bitcoin Core v0.15, готовящаяся к релизу. Детальный доклад с описанием ключевых изменений подготовил Грегори Максвелл из Blockstream.

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

Уровень активности разработчиков



С февраля 2017 года, когда началась работа над Bitcoin Core 0.15, было сделано 627 запросов на включение кода от 95 авторов, которые содержали 1081 коммитов (изменений). Таким образом, в среднем создавалось по 6 коммитов каждый день, что в сравнении с другими криптовалютными проектами само по себе является достаточно примечательной цифрой.

Еще одной особенностью стало то, что 20% коммитов были связаны с тестовой сетью. Значительная их часть была создана jnewbery из Chaincode Labs, который впервые присоединился к команде разработчиков Bitcoin Core в ноябре 2016 года и с тех пор демонстрирует исключительно высокую активность.

В общей сложности было изменено / добавлено 52 000 строк кода, что также можно считать очень высоким показателем.

Основной фокус: производительность
По словам Максвелла, при работе над v0.15 рассматривалось несколько областей, но основное внимание было направлено в первую очередь на общую производительность ПО. Одна из причин – быстрый рост блокчейна биткоина, который требует более быстрого в работе софта. Как отметил Максвелл, с учетом активации протокола Segregated Witness разработчики поняли, что блокчейн будет расти еще более быстрыми темпами, и поэтому возникло желание максимально оптимизировать производительность.

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

Chainstate (UTXO)
Говоря об улучшении производительности, одним из важнейших направлений работы стала полная переработка базы данных Chainstate (UTXO), то есть выходов неизрасходованных транзакций. В Chainstate хранится информация, необходимая для валидации новых блоков. Нынешняя структура базы данных используется с версии 0.80, и еще при ее первоначальной имплементации производительность выросла примерно в 40 раз.



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

Обратной стороной этого нововведения, впрочем, стало 15-процентное увеличение размера самой базы данных на диске (до 2,8 Гб), но, как отмечают разработчики, общее улучшение производительности это сполна компенсирует.

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

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

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

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

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

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

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

Ускорение работы платформы
Новая версия официального клиента биткоина обещает более быструю работу всей платформы. При реализации алгоритма хеширования SHA256 использована сборка SSE4, в результате чего на 5% выросла первоначальная скорость загрузки блока, и почти на 10% выросла скорость соединения с новым блоком. В версии 0.15 эта опция, впрочем, по умолчанию не активирована, поскольку внедрена она была только за три дня до прекращения добавления функционала и к тому же испытывала проблемы на компьютерах под MacOS.

Кэширование валидации скриптов
Еще одним существенным усовершенствованием в новой версии Bitcoin Core стал механизм кэширования валидации скриптов. Начиная с версии 0.7 биткоин имеет механизм кэширования, который, если говорить в целом, запоминает каждый массив публичных ключей для подписи сообщений и позволяет их валидировать намного быстрее, чем если бы они были в обычном кэше. Примечательно, что этот апдейт был последним, который в свое время был предложен Сатоши Накамото и затем пролежал еще год в почтовом ящике Гэвина Андресена.

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

Грегори Максвелл отдельным пунктом отвечает на вопрос, который был поднят еще в 2012 году: почему не использовать тот факт, что транзакция уже оказалась в мемпуле, как показатель того, что она уже валидирована и ее просто стоит принять. По его словам, проблема в том, что правила для транзакций, попадающих в мемпул, отличаются от правил для транзакций в блоке. Предполагается, что они представляют собой подмножество, однако из-за ошибок в ПО могут превратиться в супермножество, и в прошлом уже были баги при обработке мемпула, которые приводили к появлению невалидных транзакций.

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

По этой причине в версии 0.15 появился отдельный механизм кэширования валидации скриптов. Он кэширует участки с ключами и флагом проверки, какие именно правила применимы к транзакциям. Все правила валидации, за исключением порядкового номера и времени создания блоков, являются функцией хеша транзакции, и все это также кэшируется. Для SegWit-транзакций — это wtxid, а не просто txid. Присутствие этого механизма кэширования ускоряет время принятия новых блоков нодами на 50%.

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

Мультикошелек
По словам Максвелла, пользователи еще с 2011 года просили добавить поддержку мультикошелька, и в версии 0.15 это, наконец, было сделано. Таким образом, появится возможность одновременной загрузки сразу нескольких кошельков. Правда, на данный момент в GUI-интерфейсе эта опция пока не отображается и появится в следующем релизе. В версии 0.15 она доступна в интерфейсе командной строки (CLI) и для удаленного вызова процедур (RPC). Эту функцию пока можно считать экспериментальной и предназначенной скорее для тестирования.

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

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

Еще одним нововведением стало добавление в пользовательский интерфейс функции Replace-by-Fee. Эта функция позволяет принудительно повысить размер комиссии, если транзакция не подтверждается долгое время, и ранее она была доступна только для RPC.

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

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

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

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

Источник

 

высокой активностью со стороны разработчиков,

 

Как вы это поняли?