Основна проблема: Поза двійковим кодом, перевірка довіри

Коли більшість людей завантажують 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 request) переглядається. Але шлях від людсько читабельного коду до виконуваного бінарного програмного забезпечення включає компілятори, сторонні бібліотеки та операційні системи, які самі можуть бути векторами зламу, задніх дверей або помилок.

«Довірені третії особи — це вразливі місця безпеки» — Нік 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]