Основная проблема: Под бинарным кодом — проверка доверия

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

За этим скачиванием скрыты годы инженерной работы, направленной на ответ на простой вопрос: «Почему кто-либо должен доверять этому программному обеспечению?» Ответ — не должен. Вы должны иметь возможность проверить.

В эпоху, когда атаки на цепочки поставок программного обеспечения становятся глобальными новостями — от скомпрометированных пакетов npm, библиотек с бэкдорами, злоумышленнических CI-серверов — процесс сборки Bitcoin Core остается тихим проектом дисциплины. Его методы могут казаться медленными и сложными по сравнению с беспрепятственной удобностью «push to deploy», но в этом и суть. Безопасность — не удобство.

Чтобы понять систему сборки Bitcoin Core, нужно разобраться в:

• Философии системы сборки Bitcoin Core
• Воспроизводимых сборках
• Минимизации зависимостей
• Отсутствии автоматических обновлений
• Непрерывной интеграции
• Постоянной адаптации

Философия системы сборки Bitcoin Core

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

Один из принципов в экосистеме Bitcoin — «не доверяй, проверяй». Запуск собственного узла — акт проверки, при котором каждое блокчейн-обновление и транзакция сверяются с правилами консенсуса. Но сама система сборки дает еще одну возможность проверить — на уровне программного обеспечения. Bitcoin — это деньги без доверенных посредников, а Bitcoin Core работает как программное обеспечение без доверенных создателей. Система сборки прилагает большие усилия, чтобы любой, где бы он ни находился, мог независимо воссоздать точно такие же бинарные файлы, которые размещены на сайте bitcoincore.org.

Эта философия восходит к эссе Кена Томпсона 1984 года Reflections on Trusting Trust, в котором предупреждалось, что даже чистый исходный код нельзя доверять, если компилятор, который его создал, был скомпрометирован. Разработчики Bitcoin усвоили этот урок. Как говорит участник Bitcoin Core Майкл Форд (fanquake):

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

Это утверждение — и техническая цель, и часть этики Bitcoin.

В сфере безопасности люди говорят о «поверхностях атак». Система сборки Bitcoin Core рассматривает сам процесс сборки как поверхность атаки, которую нужно минимизировать и защищать.

Воспроизводимые сборки: проверка до самого дна

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

«Доверенные третьи стороны — это дыры в безопасности» — Ник Szabo (2001)

Чтобы решить эти проблемы, архитектор Bitcoin Core создал конвейер сборки с использованием Guix — менеджера пакетов, предназначенного для создания воспроизводимых, детерминированных программных сред.

Когда выпускается новая версия Bitcoin Core, несколько независимых участников собирают бинарные файлы с нуля, используя Guix. Каждый сборщик работает в изолированной среде, которая гарантирует одинаковые инструменты, версии компиляторов и системные библиотеки. Если все сборщики дают одинаковый результат, они знают, что сборка детерминирована.

Затем участники криптографически подписывают полученные бинарные файлы и публикуют подписи в отдельном репозитории GitHub — guix.sigs, где хранятся подтверждения для каждой версии Bitcoin Core. Некоторые сборщики — разработчики Bitcoin Core, но это не обязательно, так как процесс подтверждения открыт для любого желающего. На самом деле, многие не участвующие в коде люди регулярно добавляют подписи.

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

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

Официальные бинарные файлы на bitcoincore.org — это не просто «создано хранителями Bitcoin Core». Это результат работы десятков независимых сборщиков. То, что вы скачиваете — это то, что все остальные собрали и проверили как подлинное.

Это проверка до самого дна.

Минимизация зависимостей: Меньше — значит больше доверия

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

За последние десять лет разработчики Bitcoin Core постепенно устраняли эти ненужные и иногда проблемные сторонние зависимости, такие как OpenSSL и MiniUPnP. Будь то внешняя библиотека или инструмент, эти зависимости добавляют сложность или скрытые предположения. Проекты вроде Boost и Libevent, ранее являвшиеся основой кода Core, постепенно выводятся из использования или заменяются более простыми, самостоятельными альтернативами.

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

Недавно Brink подчеркнул в своем блоге «Минимизация зависимостей»[1], что это не только вопрос простоты, а важнейшая часть обеспечения безопасности и автономии проекта. Каждая удаленная зависимость — это один внешний участник, которому проект должен доверять, и один потенциальный бэкдор.

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

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

Отсутствие автоматических обновлений

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

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

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

Непрерывная интеграция: движемся медленно и исправляем

В Кремниевой долине непрерывная интеграция и непрерывное развертывание (CI/CD) — признаки гибкой разработки. Быстро выпускай. Быстро исправляй. Пусть автоматизация делает остальное.

Bitcoin Core использует иной подход. Его системы CI созданы не для ускорения развертывания, а для защиты целостности. Автоматические сборки проверяют согласованность между платформами. Система сборки Bitcoin Core спроектирована так, чтобы быть максимально нейтральной к аппаратному обеспечению и операционным системам. Проект может создавать бинарные файлы для Linux, macOS и Windows, а также для различных архитектур, включая x86_64, aarch64 (ARM) и даже riscv64. Система непрерывной интеграции обеспечивает эту совместимость и целостность программного обеспечения, выполняя сотни тестов для каждого предложенного изменения.

Результат — культура, в которой «непрерывная интеграция» означает непрерывное тестирование, проверку и безопасность, а не постоянные инновации.

Двигайтесь медленно и исправляйте.

Постоянная адаптация: мы уже закончили?

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

Хотя система сборки Bitcoin Core стремится к детерминизму, сама она не может быть статичной. Мир, в котором она работает, постоянно меняется. Операционные системы, компиляторы, библиотеки и аппаратные архитектуры — все это обновляется. Каждое новое обновление macOS или glibc, каждое устаревание флага компилятора или появление новой архитектуры CPU вносит тонкие несовместимости, которые нужно решать. Система сборки, которая застывает, со временем перестанет собираться вообще.

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

Получите свой экземпляр «The Core Issue» уже сегодня!

Не упустите шанс стать обладателем The Core Issue — сборника статей, написанных многими разработчиками Core, в которых они рассказывают о своих проектах!

Этот материал — письмо редактора, опубликованное в последнем печатном выпуске Bitcoin Magazine, The Core Issue. Мы делимся им здесь в качестве предварительного взгляда на идеи, раскрываемые в полном выпуске.

[1]