Что нового в Bitcoin Core v0.15

Это статья о возможностях и улучшениях в Bitcoin Core v0.15. Сегодня я расскажу о небольшом изменении реализации Мэттом Коралло, которое дает огромный импульс производительности для узлов, которые находятся в синхронизации и не отстают от блок-цепи.
Проверка блока: теперь до 50% быстрее!
Кэширование скриптов ( PR 10192 )
Это еще одно отличное повышение производительности, на этот раз в новое время проверки блока, когда узел обновляется до кончика цепи. В нормальных условиях блоки теперь будут проверяться примерно на 40-50% быстрее.
Как мы можем добиться такого резкого ускорения? Это начинается с наблюдения, что, как только ваш узел работает и работает некоторое время, каждый раз, когда он получает блок, он уже видел большинство транзакций внутри этого блока. Это связано с тем, что шахтер, создавший блок, собирает транзакции для блока из той же сети P2P, к которой подключен ваш узел, и поэтому ваш узел уже видел транзакции по мере их распространения по этой сети.
В ранних версиях Bitcoin Core почти каждая транзакция была бы дважды проверена - сначала, когда она была получена как неподтвержденная транзакция и принята в ваш мейбл, и снова, когда она была получена в блоке. Выполнение одной и той же вычислительной задачи дважды является очевидной целью оптимизации, и первым большим улучшением здесь было добавление кэш-сигнатуры в v0.7. Подтверждение подписи включает в себя математику эллиптической кривой и является самой дорогой частью проверки подлинности скрипта, поэтому, если мы сможем сэкономить время на проверку подписи, это большая победа. После v0.7, если Bitcoin Core получил неподтвержденную транзакцию, которая была проверена и принята в mempool, она будет кэшировать результат проверки подписи. Затем, если он получил блок, содержащий эту же транзакцию, вместо повторной проверки подписей, он просто будет искать результат в своем кеше.
Это небольшое изменение приводит к огромному повышению производительности в период проверки блока.
Очевидный вопрос: почему не кэшировать действительность всей транзакции? Разве это не будет еще больший выигрыш в производительности? К сожалению, это невозможно, поскольку транзакция действительна для контекста . Это означает, что транзакция может быть действительной в одном блоке, но недействительна в другом блоке. Вот один из способов, по которым может произойти консенсусная ошибка, если мы кэшировали транзакцию:
Главный наконечник цепи находится на высоте 1000
Транзакция A принимается с nLockTime, установленным в блок 1001. Он оценивается как действительный, так как следующий блок будет иметь высоту 1001.
Шахтер реорганизует блок 1000 из основной цепи путем создания блока 1000 'поверх блока 999. Блок 1000' включает в себя транзакцию А.
Результатом является разделение цепей. Те узлы, которые впервые увидели транзакцию A перед повторной организацией, рассматривают блок 1000 ', чтобы быть действительными, поскольку они уже оценили транзакцию A как действительную. Те узлы, которые не видели транзакцию A перед повторной организацией, видят блок 1000 'как недействительный, поскольку транзакция A недействительна в любом блоке до 1001.
Поэтому мы не можем просто кэшировать действительность транзакции, не внося риска для консенсусного провала, но мы можем ( и делать ) кэшировать срок действия подписи. Мэтт заметил, что мы можем сделать что-то между ними: мы можем кэшировать действительность сценариев внутри транзакции, не кэшируя действительность всей транзакции. Существенно, что в транзакции Bitcoin действительность скриптаSigs не является контекстуальной для любой внешней информации. Это действительно важный момент, и последние BSP-запросы CLTV (Check Locktime Verify) и CSV (Check Sequence Verify) были тщательно разработаны для сохранения этого свойства.
Мэтт добавляет кэш кеша в дополнение к кэшу подписи, поэтому из v0.15, если мы получим неподтвержденную транзакцию, мы будем кэшировать как результаты проверки подписи ECDSA, так и результаты оценки входных сценариев.
В отличие от изменений в цепочке счисления Pieter на цепочку, это не было особенно большим изменением кода (+449 строк, -43 строки по сравнению с +1109 строк, -1055 строк для изменения Pieter), но не стоит недооценивать трудности. Люди пытались сделать подобные вещи до этого и ввели консенсусные ошибки, подобные описанным выше. См. Например, PR 6077 и PR 5835 . Ценность вклада Мэтта заключается в том, что он глубоко понимает консенсусный код и больше опыта в написании и поддержании этого кода, чем кто-либо другой. Очень немногие люди могли реализовать что-то подобное без введения консенсусных ошибок.
Результатом этого изменения является то, что проверка нового блока примерно в среднем на 40-50% быстрее. Огромное улучшение!
Вывод
Окончание биткойн Core v0.15 было выпущено на этой неделе и доступно для загрузки с bitcoincore.org . В этом выпуске представлены несколько действительно приятных новых пользовательских функций и некоторые существенные улучшения производительности, а также закладываются основы для дальнейших улучшений и функций в версии v.16. Есть целый ряд небольших изменений, которые я здесь не включил.