Перевод статьи Джеймсона Лоппа подготовили Nikita Kolodin и RainDogDance

Вопрос о том, кто контролирует код в репозитории Bitcoin Core на гитхабе, продолжает возникать снова и снова. Этот довод часто преподносится как свидетельство наличия центральной точки контроля протокола биткоина. Я убеждён, что сам вопрос обманчив, поскольку подразумевает неминуемое существование авторитарной власти — а эта модель неприменима к биткоину. Обывателю, конечно, может быть неочевидно, почему это так, поэтому цель этой статьи — объяснить, как работает Bitcoin Core и, на более высоком уровне, как развивается сам протокол биткоина.

История Bitcoin Core

Bitcoin Core — это, скорее, главное место разработки протокола биткоина, а не орган управления и контроля. Если оно по какой-либо причине прекратит своё существование, возникнет новое. Выбор конкретной платформы (в настоящее время — репозиторий на гитхабе) — это скорее вопрос удобства, а не определения или же аутентичности проекта. На самом деле, мы уже не раз наблюдали, как разработка биткоина переезжала на другие платформы и даже меняла имена.

• В начале 2009 года исходный код биткоина представлял собой простой файл .rar, размещённый на SourceForge. Первые разработчики просто обменивались патчами с Сатоши по электронной почте.
• 30 октября 2009 года Sirius (Марти Мальми) создал репозиторий для разработки биткоина на SourceForge
• В 2011 году проект переехал с SourceForge на GitHub
• В 2014 году проект был переименован в Bitcoin Core.

Не доверяй никому

Хотя в репозитории на гитхабе некоторые разработчики имеют статус «дежурных» (maintainer — статус с определёнными административными правами в данном репозитории — прим. перев.), имеющих полномочия добавление кода в основную ветвь — они скорее занимаются техническим обслуживанием репозитория, а не контролируют его. Если бы любой человек мог добавлять код в основную ветку, это очень быстро превратилось бы в хаос. Bitcoin Core следует принципам наименьших привилегий: любые полномочия, предоставляемые отдельным лицам, легко отзываются, если ими злоупотребляют.

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

Bitcoin Core не сводит вопрос надёжности кода к безопасности аккаунтов на гитхабе, поэтому он имеет систему непрерывной интеграции, проверяющей PGP-ключи доверенных лиц, которые должны подписывать каждое слияние кода (merge commit — слияние нового кода с уже находящимся в репозитории — прим. перев.). Хотя все знают, кто владеет этими ключами, всё-таки небезопасно предполагать, что так будет всегда — ключ могут украсть, и мы не сможем об этом узнать до тех пор, пока его владелец не уведомит об этом других дежурных. Таким образом, ключи для слияния кода также не гарантируют идеальную защиту; они просто усложняют задачу добавления произвольного кода злоумышленником.

Ключи к царству

На момент написания статьи доверенными отпечатками PGP являются:

71A3B16735405025D447E8F274810B012346C9A6
133EAC179436F14A5CF1B794860FEB804E669320
32EE5C4C3FA15CCADB46ABE529D4BCB6416F53EC
B8B3F1C0E58C15DB6A81D30C3648A882F4316B9B
CA03882CB1FC067B5D3ACFE4D300116E1C875A3D

Эти ключи принадлежат следующим людям:

Владимир ван дер Лаан <laanwj@protonmail.com>
Питер Вулле <pieter.wuille@gmail.com>
Ионас Шнелли <dev@jonasschnelli.ch>
Марко Фальке <marco.falke@tum.de>
Сэмюэль Добсон <dobsonsa68@gmail.com>

Значит ли это, что мы доверяем этим пяти людям? Не совсем. Ключи не являются доказательством личности — теоретически, они могут попасть в руки других людей. В чём вы действительно можете убедиться, запустив скрипт verify-commits в питоне?

python3 contrib/verify-commits/verify-commits.py
Using verify-commits data from bitcoin/contrib/verify-commits
All Tree-SHA512s matched up to 309bf16257b2395ce502017be627186b749ee749
There is a valid path from “HEAD” to 82bcf405f6db1d55b684a1f63a4aabad376cdad7 where all commits are signed!

Скрипт verify-commits — это проверка аутентичности кода, которую любой разработчик может запустить на своем компьютере. При выполнении скрипт проверяет PGP-подпись, стояющую на каждом слиянии кода, начиная с номера 82bcf405… в декабре 2015 года — в сумме более 3400 слияний на момент написания этой статьи. Если скрипт завершается успешно, то это значит, что каждая строка кода, которая была добавлена или изменена с того момента, прошла через процесс разработки Bitcoin Core и была подписана кем-то с ключом дежурного. Хоть это и не даёт железную гарантию того, что никто не мог ввести вредоносный код (дежурный может захотеть навредить проекту или у него могут украсть ключи), это значительно снижает вероятность атаки. А кто вообще такие дежурные и как они получили свои роли? Об этом мы поговорим чуть позже.

Многоуровневая безопасность

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

Безопасность пул-реквестов

(Pull request — запрос на объединение нового кода с уже находящимся в репозитории — прим. перев.)

1. Совершенно любой человек может свободно предложить изменения, улучшающие код проекта, открыв свой пул-реквест в репозитории bitcoin/bitcoin.
2. Разработчики проверяют пул-реквесты, чтобы убедиться, что они не являются вредоносными. Любой желающий может свободно просматривать пул-реквесты и высказывать своё мнение о них — для участия в Bitcoin Core не нужно проходить проверки или сдавать экзамены. Если пул-реквест доживает до момента, когда разумных оснований не добавить его в основную ветку больше нет, дежурный выполняет слияние.
3. Дежурные разработчики Bitcoin Core установили скрипт, предотвращающий случайное выполнение слияний кода в репозитории, если их ещё не подписали.
4. Иногда такие слияния датируются с помощью OpenTimestamps.
5. Travis Continuous Integration system (система непрерывной интеграции Travis — прим. перев.) регулярно запускает скрипт для проверки аутентичности истории разработки и для проверки подписей всех слияний основной ветвки разработки: они должны соотноситься с одним из доверенных PGP-ключей.
6. Любой желающий может запустить скрипт для проверки PGP-подписей всех слияний после декабря 2015 года. Я сам запустил его во время написания этой статьи, и на моем ноутбуке он всё проверил за 25 минут.

Безопасность релизов

1. Время от времени несколько разработчиков независимо друг от друга запускают системы воспроизводимой сборки Gitian, чтобы убедиться в том, что на выходе получаются идентичные исполняемые файлы. Если кому-то удаётся создать сборку, не совпадающую со сборками других разработчиков, это признак того, что в ней замечен невоспроизводимый компонент — тогда релиз откладывается. В таком случае разработчики отслеживают причину расхождений, исправляют её и затем собирают другого кандидата на релиз. Как только детерминированная сборка успешно завершается, разработчики подписывают результат, тем самым гарантируя, что получившиеся исполняемые файлы и использованные для их сборки инструменты чисты, и что они собраны из одного и того же источника. Этот метод позволяет обезопасить процесс сборки и распространения исполняемых файлов. Любой пользователь, имеющий соответствующие навыки, может запустить свою собственную систему сборки; инструкции здесь.
2. Как только сборки Gitian успешно завершаются и подписываются сборщиками, один из дежурных Bitcoin Core подписывает своим PGP-ключом сообщение, содержащее sha256-хэш каждой сборки. Если вы хотите запустить предварительно собранные исполняемые файлы, после загрузки вы можете посмотреть их хэш, а затем проверить, находится ли этот хэш в подписанном дежурными сообщении. Инструкции для этого можно найти здесь.
3. Код всех вышеперечисленных действий открыт и доступен каждому — любой, владеющий достаточными навыками и желанием, может его проверить лично.
4. После прохождения всех вышеперечисленных проверок качества и аутентичности код попадает в Bitcoin Core и в конечном итоге уходит в релиз, но никто не насаждает его нодам биткоина в принудительном порядке. Каждый оператор ноды биткоина сам принимает осознанное решение обновить установленный у себя код. Bitcoin Core не случайно не имеет функции автообновления, так как она потенциально может быть использована для навязывания пользователям кода, на который они не соглашались.

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

Масштаб тестирования кода

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

Проверить объём кода покрываемого тестами можно самостоятельно. Для этого нужно:

1. Склонировать репозиторий Bitcoin Core на гитхабе
2. Установить необходимые зависимости для сборки из исходного кода
3. Запустить эти команды
4. Просмотреть отчет здесь: ./total_coverage/index.html

Также, вы можете просмотреть отчёты о тестировании кода, которые регулярно публикует Марко Фальке.

Такое широкое покрытие кода тестами даёт нам уверенность в том, что код работает так, как задумано.

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

«Тест — это проверка программного обеспечения, но чем проверить сам тест? Программным обеспечением. Чтобы проверить тест, вы должны сломать программное обеспечение» — Грег Максвелл

Свободная конкуренция

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

На момент написания этой статьи на 96% доступных нод биткоина запущен Bitcoin Core той или иной версии. Но почему? Как может Bitcoin Core доминировать в сети, где каждый волен использовать любое другое программное обеспечение? В конце концов, RPC API-интерфейсы других программных реализаций совместимы с Bitcoin Core, или, по крайней мере, очень похожи на него.

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

Кто такие разработчики Core?

Людям, незнакомым с участием в разработке Bitcoin Core, со стороны может показаться, что Core — это некая однородная организация. Это совсем не так! Основные участники часто спорят друг с другом, и даже самые усердные из них написали немало кода, который так и не дошёл до релиза. Если вы прочитаете рекомендации и правила для участников, то заметите, что они довольно расплывчаты — процесс лучше всего охарактеризовать как «приблизительный консенсус».

Дежурные оценивают, соответствует ли патч общим принципам проекта; отвечает ли минимальным стандартам качества; и принимают во внимание общее мнение других участников.

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

• Сатоши Накамото: 1/3/09 — 2/23/11
• Гэвин Андресен: 2/23/11 — 4/7/14
• Владимир ван дер Лаан: 4/7/14 — настоящее время

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

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

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

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

Даже если без захвата власти какие-нибудь сомнительные изменения попали бы в код Bitcoin Core, нашлись бы разработчики, которые создали клон репозитория, удалили спорный момент из кода и сделали бы эту версию доступной для всех желающих. По сути, именно это и сделал Амори Сашэ, когда форкнул Bitcoin Core и удалил Segregated Witness из кода, чтобы создать Bitcoin ABC. Также бывают и случаи, когда Core отклоняет изменения, нужные некоторым людям: в таком случае разработчики могут форкнуть репозиторий и добавить эти изменения. Это случалось много раз, например:

• Майк Хирн форкнул Core и создал Bitcoin XT
• Эндрю Стоун форкнул Core и создал Bitcoin Unlimited
• Джеф Гарзик форкнул Core и создал BTC1

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

У некоторых людей есть мнение — и их трудно в нём переубедить — что пользователи Bitcoin Core не глядя следуют любым изменениям кода. Это может стать самоподкрепляющимся убеждением: раз уж пользователи не участвуют в процессе разработки, то они и не осознают своих возможностей, тем самым отдавая часть своей власти разработчикам. Однако, пользователи показали свою реальную власть во время движения UASF (User Activated Soft Fork — активируемый пользователями форк — прим. перев.) в 2017 году. Неизвестный разработчик под псевдонимом shaolinfry опубликовал BIP148 (Bitcoin Improvement Proposal — предложение по улучшению биткоина — прим. перев.), который заставил бы майнеров активировать функцию Segregated Witness примерно 1 августа. Однако, BIP148 оказался слишком спорным и не был принят в Bitcoin Core, поэтому shaolinfry форкнул Core и опубликовал свою версию под названием Bitcoin UASF. Эта программная реализация приобрела неожиданную популярность и, вероятно, создала достаточное давление, чтобы убедить майнеров принять BIP91 и тем самым активировать форк до истечения срока BIP148.

Лучшие участники Bitcoin Core на мой взгляд — это те, кто придерживаются принципа «экстремальной ответственности» (extreme ownership). Показательный пример: хотя Джон Ньюбери и не был автором кода, содержавшего в себе баг консенсуса, он тем не менее взял на себя ответственность за его попадание в релиз — так как не смог обнаружить его при проверке — и за то, что не смог найти этот баг позже, когда прописывал различные варианты тестирования:

Мы все — Сатоши.

Участие в Bitcoin Core

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

Core разработчик Эрик Ломброзо также написал статью о том, как происходят изменения в репозитории Core:

Алекс Б. написал отличную статью о философии разработки биткоина — советую прочитать это любому намеренному участвовать в проекте всерьёз:

Думаю, будет полезным привести конкретный пример: при написании этой статьи я столкнулся с трудностями при попытке запустить на моем компьютере скрипт verify-commits.py для проверки целостности истории слияний на гитхабе. Чтобы избавить будущих разработчиков от похожих проблем, я открыл пул-реквест, в котором предложил некоторые улучшения документации. Как можно увидеть из истории пул-реквеста, четыре разных разработчика высказали свои идеи о том, как можно улучшить мой запрос. Предложения были разными: от изменения вики-разметки до введения нового параметра, который бы можно было использовать в скрипте verify-commits.py. Я согласился со всеми предложениями, поэтому включил их в свой код и обновил пул-реквест. После этого разработчики, которые просматривали код, решили, что пул-реквест отвечает всем требованиям, и дежурный Марко Фальке поставил на нём тег, обозначающий что код будет включён в релиз 0.18. Через несколько дней, не встретив каких-либо возражений со стороны других разработчиков, дежурный Сэмюэль Добсон добавил код в Core.

Кто контролирует биткоин?

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

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

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

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

Никто не контролирует биткоин.

Никто не контролирует разработку биткоина.