Закритий проти відкритого вихідного коду — суперечка, що розділяє біткоїн- і ширшу криптоіндустрію вже понад десять років. Прихильники біткоїна давно доводять, що фінансова інфраструктура світу має будуватися публічно. Прозорість і перевірюваність, кажуть вони, не підлягають обговоренню, коли на кону реальні гроші. Однак прикладний і легасі-шари фінансів часто з цим не згодні.

Проте нещодавній злам Coldcard — популярного апаратного гаманця для самостійного зберігання, де користувачі втратили біткоїнів більш ніж на $100 млн (понад 1500 BTC), — поставив під сумнів те, що «Open Source» насправді означає. Він показав, що, ймовірно, більшість людей, навіть багато переконаних біткоїнерів, погано розбираються у філософії розробки Open Source і в тому, коли вона дає збій.

Принципи та термінологія

Мова навколо Open Source може бути непростою. Free and Open Source Software (FOSS) і Free/Libre and Open Source Software (FLOSS) позначають ПЗ, що відповідає формальним визначенням свободи користувача.

Фонд вільного ПЗ (FSF) визначає вільне ПЗ через чотири суттєві свободи:

• Свобода 0: свобода запускати програму як завгодно, для будь-якої мети.
• Свобода 1: свобода вивчати, як працює програма, і змінювати її, щоб вона виконувала ваші обчислення як вам потрібно (доступ до вихідного коду — передумова для цього).
• Свобода 2: свобода поширювати копії, щоб ви могли допомагати іншим.
• Свобода 3: свобода поширювати іншим копії ваших змінених версій (доступ до вихідного коду — передумова для цього).

FSF підкреслює, що «free» стосується свободи, а не ціни, у відомій цитаті, що часто звучить від прихильників FOSS: «"free" як у "free speech" (свобода слова), а не як у "free beer" (безкоштовне пиво)».

Визначення Open Source від Open Source Initiative додає десять практичних критеріїв. До них належать вільне поширення без роялті, доступність вихідного коду в бажаній для модифікації формі, право створювати й поширювати похідні роботи та відсутність дискримінації осіб, груп чи сфер діяльності — включно з комерційним використанням. Ліцензія має відповідати всім десяти критеріям, щоб кваліфікуватися як Open Source за стандартом OSI.

«Source available» або «source viewable» — це інше. Код може бути публічно читабельним, тоді як ліцензія обмежує право його продавати. Прошивка Coldcard, наприклад, випущена під умовами MIT плюс Commons Clause. Це застереження спеціально прибирає право «продавати» ПЗ — визначене як надання його третім сторонам за плату чи іншу винагороду в продукті або послузі, цінність яких цілком або значною мірою походить із самого цього ПЗ. Іншими словами, прошивку Coldcard не можна було використовувати комерційно.

Власний FAQ Commons Clause прямо заявляє про цю різницю: «Це "Open Source"? Ні». У ньому зазначається, що застосування застереження означає, що ПЗ відповідає багатьом елементам Визначення Open Source, але не всім, і тому його не слід називати Open Source.

Ці відмінності важливі. Публікація вихідного коду створює можливість інспекції. Саме надання повного набору прав, визначених Визначенням вільного ПЗ або Визначенням Open Source, робить ПЗ FOSS або FLOSS. Але володіння «знаком схвалення», можливістю розмахувати прапором FOSS чи FLOSS, — не суть. Комерційна свобода у FOSS розкриває сторонні стимули тестувати й перевіряти код, яких інакше могло б не бути, доводять критики.

Чотири свободи утворюють філософське ядро Open Source. На практиці вони спираються на економічне припущення: що досить мотивованих людей справді вивчать код. Коли це припущення не виконується, система породжує класичну «трагедію спільнот» — ситуацію, коли спільний ресурс надмірно використовується або занедбується, бо окремі користувачі діють у власних короткострокових інтересах, а не в довгострокових інтересах групи.

У кожного є стимул брати більше (або вкладати менше), ніж стійко, і ресурс у результаті деградує. Це відбувається, коли є розузгодження між короткостроковим інтересом індивіда й довгостроковим інтересом групи. Іноді узгодженість є; іноді ні.

Один біткоїн-розробник висловив проблему прямо: «Використання моків і заглушок Open Source-коду в тестах безвідповідальне й короткозоре. Open Source-код вважається безпечним, бо будь-хто може його перевірити. Якщо ви не готові зробити мінімум — протестувати функції, від яких реально залежите, — то ви поводитеся як п'явка».

У результаті Open Source сам по собі не створює безпеку. Він створює можливість верифікації. Чи відбудеться ця верифікація — залежить від стимулів, навичок і уваги. Вважається, що історичний FOSS з часом «загартовується», у міру того як уразливості виявляються, розкриваються й патчаться, створюючи міцні підвалини, на яких будують інші. Ядро Linux — чудовий приклад такого загартованого FOSS; воно живить переважну більшість серверів світу, хмарну інфраструктуру, пристрої Android і вбудовані системи, що робить його одним із найширше розгорнутих ПЗ в історії.

Open Source на прикладі Bitcoin Core

Bitcoin Core, еталонна реалізація біткоїна, — ще один показовий великомасштабний приклад чистого Open Source, що працює «в дикій природі». ПЗ, що стоїть за більшою частиною пов'язаної з біткоїном інфраструктури, випущене під ліцензією MIT. Його процес розробки за задумом широко публічний.

Будь-хто може відкрити pull request. Ревю коду — основний фільтр і рекомендована точка входу для нових контриб'юторів. Ревьюери використовують формальну лексику: Concept ACK (визнання й згода з метою), Approach ACK (згода з метою й методом), ACK з конкретним хешем коміту (протестовано й схвалено до злиття) або NACK (незгода, що має супроводжуватися технічним обґрунтуванням).

Мейнтейнери зважують консенсус серед контриб'юторів і технічні переваги зміни перед злиттям. Зміни, критичні для консенсусу, стикаються з ще вищою планкою й зазвичай вимагають Bitcoin Improvement Proposal і широких багаторічних обговорень у розсилці bitcoin-dev і в IRC.

Немає привілейованої касти «розробників Bitcoin Core». Довіра заробляється через продемонстровану компетентність з часом. Мейнтейнери існують із практичних причин — аудит і злиття коду, управління релізами й базова модерація, — але вироблювана робота є чистим Open Source-кодом, який будь-хто може інспектувати, зібрати, форкнути або запустити. Розробників, чиї «коміти» вливаються в Bitcoin Core, широко називають контриб'юторами Bitcoin Core.

Calle, давній Open Source-розробник біткоїна, нещодавно резюмував реальність: «Люди, які думають, що Core — якась непрозора установа, що діє в тіні, або надто ліниві, або надто дурні, щоб піти й подивитися самим. Буквально все, що вони роблять, публічно, будь-хто може вставити слово, а результат їхньої роботи — чистий Open Source-код».

Фінансування цієї роботи приходить в основному через некомерційні та грантові структури на кшталт Brink, OpenSats, Spiral та інших, а не через традиційну продуктову дорожню карту компанії. Технічне обговорення й суперечки проходять публічно в розсилці bitcoin-dev і в IRC-каналі #bitcoin-core-dev на Libera Chat, де пропозиції розбираються до й у ході процесу pull request. Тикети й pull request на GitHub часто несуть історії коментарів, що тягнуться на десятиліття. Результат — культура розробки, оптимізована під коректність і перевірюваність, а не під швидкість або комерційну швидкість випуску фіч.

Економіка Open Source

Більшість користувачів Open Source або source-available ПЗ ніколи не читають код самі. Вони покладаються на припущення, що його вивчають інші. У випадку Coldcard критичний вада ентропії залишався в публічно доступній прошивці приблизно п'ять років, перш ніж був проексплуатований і таким чином виявлений.

Баг потрапив у кодову базу під час великого переписування 2021 року, яке також прибрало залишковий GPL-похідний код від Trezor — першого апаратного гаманця, а тепер другого за величиною в індустрії самостійного зберігання. Бібліотека в центрі збою ентропії, що замінила trezor-crypto, називається libngu й мала мінімальну зовнішню увагу — лише 7 «зірок» і менше 20 форків за понад 5 років використання в продакшені. Порівняйте це з 512 «зірками» бібліотеки trezor-crypto поряд із 212 форками або 793 форками й 1,8 тис. «зірок» сучаснішої trezor-firmware. Сама лише доступність вихідного коду не породила того ревю, яке мало значення, бо іншим комерційним, добре фінансованим компаніям було обмежено її використання — або так, принаймні, доводили б критики.

Ставки в біткоїні вищі, ніж у більшості програмних областей. Критичну ваду можна напряму конвертувати в ліквідні кошти на відкритому ринку. Хоча перша половина вкрадених у Coldcard коштів усе ще тримається на жменьці адрес і хакера колись можуть спіймати, наслідувачі, що пішли за ним, були обережнішими, і деякі вкрали більше біткоїнів і успішно їх відмили, за даними Galaxy Research. Стійкість біткоїна до цензури та його незмінна переказовність створюють і потужний стимул для атакувальників, і «дарвінівський» фільтр; у довгостроку схильні виживати лише ті проєкти, які безперервно приваблюють компетентне ревю, і ті користувачі й компанії, які вживають серйозних запобіжних заходів.

Вибір ліцензії формує ці стимули, на думку прихильників FOSS, що роками критикували ліцензійні рішення Coinkite. Чисті Open Source-ліцензії максимізують пул потенційних ревьюерів і форків. Обмежені «source available» ліцензії можуть знизити комерційне «безквитництво», але також звужують коло людей, у яких є і юридичне право, і економічний мотив вкладати глибоку увагу. На жаль, тягар ревю коду за обмежувальної ліцензії повертається до самої компанії, ставлячи її в певному сенсі ближче до закритого коду, ніж до відкритого.

Як ШІ змінює розробку відкритого й закритого коду

Штучний інтелект тепер теж змінює баланс між FOSS і закритим кодом.

Після інциденту з Coldcard волонтерська ініціатива, відома як Bitcoin Red Team — під керівництвом розробників, включно з Calle й Робом Гамільтоном з AnchorWatch, і за підтримки OpenSats, — використала передові ШІ-моделі для сканування сотень Open Source-репозиторіїв біткоїна. За один інтенсивний період команда подала тисячі знахідок, включно з десятками, класифікованими як критичні або високої серйозності, по сотнях проєктів. Відповідальні розкриття були зроблені мейнтейнерам до ширшої публікації. Вправа показала, що систематичне ревю за допомогою ШІ може виявляти проблеми в масштабі й зі швидкістю, раніше непрактичними для суто людських команд.

На цьому фронті варто відзначити, що Red Team знайшла китайські моделі з відкритими вагами куди надійнішими, ніж закриті американські моделі, які, навіть із кібер-дозволами й першокласним доступом, відмовлялися відповідати на запити Red Team, — тренд, про який американські розробники шкодують.

Водночас потік згенерованого ШІ коду створив новий тиск типу «відмова в обслуговуванні» на мейнтейнерів FOSS. Перевірка ШІ-виводу часто займає більше часу, ніж його генерація. Деякі Open Source-проєкти за межами біткоїна обмежили трекери задач або ввели суворі правила проти ШІ-контрибуцій просто заради того, щоб залишатися працездатними.

Джерело: Bitcoin Magazine