Кто контролирует Биткоин? (основы основ)

[Dmitrii Storm]

Эта статья написана 15 декабря 2018 года одним из разработчиков Bitcoin Core,

бывшим инженером BitGo и ведущим экспертом в сфере безопасности криптовалютных кошельков Джеймсоном Лоппом.

 

Оригинал статьи здесь

 

За шесть лет статья не потеряла своей актуальности, изменились лишь несущественные детали.

Крайне рекомендую для ознакомления каждому, кто хочет познать Биткоин.

 

Спойлер

Джеймсон Лопп

 

Чтение статьи займёт 14 минут вашего бесценного времени вашей единственной жизни. Но оно того стоит.

 

---------------------------------------- перевод--------------------------------------------------------------

Кто контролирует Bitcoin Core?
Объяснение того, как работает разработка  кода Bitcoin.

 

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

 

Этот довод часто преподносится как свидетельство наличия «центральной точки контроля» над протоколом Биткоина. 

 

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

Поэтому цель этой статьи — объяснить, как работает Bitcoin Core и как развивается сам протокол Биткоина.

 

История Bitcoin Core

 

Bitcoin Core — это центр разработки протокола Bitcoin, а не точка управления и контроля. 

Если бы он прекратил свое существование по какой-либо причине, то возникла бы новая центральная точка — техническая коммуникационная платформа, на которой он основан (в настоящее время репозиторий GitHub), — это вопрос удобства, а не определения/целостности проекта. 

Фактически, мы уже видели, как центральная точка разработки Bitcoin меняла платформы и даже названия!

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

 

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

 

Хотя на уровне организации есть несколько учетных записей GitHub «maintainer» (дежурных), которые имеют возможность добавлять код в главную ветку Биткоина, это скорее функция технического персонала, чем позиция власти и контроля.

 

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

 

 

GitHub нельзя доверять. Любое количество сотрудников GitHub может использовать свои административные привилегии для внедрения кода в репозиторий Биткоина без согласия «maintainers» (дежурных). Но маловероятно, что злоумышленник из GitHub также сможет завладеть ключом PGP «maintainer» (дежурных) Bitcoin Core.

 

Вместо того, чтобы основывать целостность кода на учетных записях GitHub, Bitcoin Core имеет систему непрерывной интеграции, которая выполняет проверки доверенных ключей PGP, которые должны подписывать каждое изменение кода Биткоина. Хотя эти ключи привязаны к известным идентификаторам (людям), все равно опасно предполагать, что так будет всегда — ключ может быть украден/отнят, и мы не узнаем об этом, если только владелец исходного ключа не уведомит других «maintainers» (дежурных). 

 

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

 

Ключи к королевству

 

На момент написания статьи это доверенные отпечатки PGP «maintainers» (дежурных):

• 71A3B16735405025D447E8F274810B012346C9A6
• 133EAC179436F14A5CF1B794860FEB804E669320
• 32EE5C4C3FA15CCADB46ABE529D4BCB6416F53EC
• B8B3F1C0E58C15DB6A81D30C3648A882F4316B9B
• CA03882CB1FC067B5D3ACFE4D300116E1C875A3D

 

Эти ключи зарегистрированы на:

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

 

Означает ли это, что мы доверяем этим пяти людям? Нет! 

Ключи не являются доказательством личности — эти ключи потенциально могут попасть в руки других людей. 

 

Какие гарантии вы действительно получаете, если запускаете скрипт Python verify-commits?

• python3 contrib/verify-commits/verify-commits.py
• Использование данных verify-commits из bitcoin/contrib/verify-commits
• Все Tree-SHA512 совпали до 309bf16257b2395ce502017be627186b749ee749
• Существует допустимый путь от «HEAD» до 82bcf405f6db1d55b684a1f63a4aabad376cdad7, где подписаны все коммиты!

 

Скрипт verify-commits — это проверка целостности, которую любой разработчик может запустить на своей машине. При запуске он проверяет подпись PGP на каждом коммите слияния с момента коммита 82bcf405… в декабре 2015 г. — более 3400 слияний на момент написания статьи. 

 

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

Тем не менее, «maintainer» (дежурный) может стать мошенником или его ключи могут быть украдены, так что опасность атаки на код Биткоина сохраняется всегда.

Кто такие «maintainers» (дежурныe) и как они получили эту роль? Мы рассмотрим это немного позже.

 

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

 

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

 

Безопасность запросов на объединение кода (Pull Requests Security)

Спойлер

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

 

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

 

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

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

 

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

 

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

 

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

 

Вы можете самостоятельно проверить код Биткоина тестами:

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

 

Кроме того, вы можете просмотреть отчет о тестах, который размещает Марко Фальке

 

Такой высокий уровень тестирования кода означает высокий уровень уверенности в том, что код функционирует так, как задумано.

 

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

 

 

Конкуренция свободного рынка

 

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

 

 

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

 

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

 

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

 

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

 

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

 

• «Maintainers» (дежурныe) примут во внимание, соответствует ли исправление общим принципам проекта, отвечает ли оно минимальным стандартам для включения, а также оценят общее согласие участников.

 

Кто такие «Maintainers» (дежурныe) Bitcoin Core? Это участники, накопившие достаточный социальный капитал благодаря своему вкладу в проект на протяжении длительного времени. Когда дежурные замечают компетентного участника, продемонстрировавшего свою надежность и мотивацию в определенной области, они могут принять решение дать его аккаунту расширенные права на гитхабе Bitcoin Core. 

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

 

• Когда я начал вносить свой скромный вклад в @bitcoincoreorg, я был в восторге от того, что @MarcoFalke @pwuille @orionwl @LukeDashjr и @jfnewbery принимали участие в обсуждении моих пул-реквестов. Такой дружелюбный проект!
• — Jeff Rade (@jeffrade) November 19, 2018

 

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

 

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

 

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

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

 

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

 

 

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

 

Однако, пользователи показали свою реальную власть во время движения UASF (User Activated Soft Fork — активируемый пользователями форк) в 2017 году. 

 

Спойлер

BIP или Bitcoin Improvement Proposal — предложение по улучшению Биткоина

Неизвестный разработчик под псевдонимом shaolinfry опубликовал BIP148, который заставил бы майнеров активировать функцию Segregated Witness примерно 1 августа.

 

Однако, BIP148 оказался слишком спорным и не был принят в Bitcoin Core, поэтому shaolinfry сам форкнул BitcoinCore и опубликовал свою версию под названием 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 (BIP), даже это всего лишь рекомендуемая и самая распространённая практика, и никто не обязан ей следовать. 

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

 

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

 

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

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

 

Спойлер

 

Часть перевода этой статьи на русский взята отсюда: https://21ideas.org/kto-kontroliruet-bitkoin-kor/

Edited 15 Jun 2025, 07:55 by Dmitrii Storm
исправил пару опечаток

[b1tkl1m]

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

Автору огромная благодарность!!!!!