Хто контролює Bitcoin Core?

Переклад, оригінал дивіться тут: Who Controls Bitcoin Core?

Питання про те, хто контролює код в репозиторії Bitcoin Core на Гітхабі, продовжує виникати знову і знову. Цей аргумент часто підноситься як доказ наявності центральної точки контролю над протоколу біткоіну. Я переконаний, що саме питання є оманливим, оскільки має на увазі неминуче існування авторитарної влади – а ця модель непридатна для біткоіну. Читачу, звичайно, може бути неочевидно, чому це так, тому мета цієї статті – пояснити, як працює Bitcoin Core і, на більш високому рівні, як розвивається сам протокол біткоіну.

Історія Bitcoin Core

Bitcoin Core – це, скоріше, головне місце розробки біткоін протоколу, а не орган управління і контролю. Якщо воно з якоїсь причини припинить своє існування, виникне нове. Вибір конкретної платформи (в даний час – репозиторій на гітхабі) – це швидше питання зручності, а не визначення автентичності проекту. Насправді, ми вже не раз спостерігали, як розробка біткоіну переїжджала на інші платформи і навіть міняла імена.

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

Хоча в репозиторії на Гітхабі деякі розробники мають статус «чергових» (maintainer  -  статус з певними адміністративними правами в даному репозиторії -  прим. перекл.), що мають повноваження додавання коду в основну гілку – вони швидше займаються технічним обслуговуванням сховища, а не контролюють його. Якби кожна людина могла додавати код в основну гілку, це дуже швидко перетворилося б в хаос. Bitcoin Core дотримується принципів найменших привілеїв: будь-які повноваження, надані окремим особам, легко відкликаються, якщо ними зловживають.

Core відкрито публікує важливий список, що містить PGP-ключі, якими можна підписувати злиття коду (merge commits). 
Але мораль скоріше полягає в тому, що Гітхабу довіряти не можна! 
Навіть Bitcoin Core не знає всіх людей, які можуть змінити репозиторій – таких, напевно, ціла дюжина серед співробітників Гітхаба.

З точки зору безпеки, гітхабу довіряти не можна. Будь-який співробітник гітхаба може скористатися своїм службовим становищем і вставити код в репозиторій без відома чергових. Але малоймовірно, що такий зловмисник також зможе заволодіти PGP-ключем чергового розробника Bitcoin Core.

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

Ключі до царства

На момент написання статті довіреними відбитками PGP є :

71A3B16735405025D447E8F274810B012346C9A6 
133EAC179436F14A5CF1B794860FEB804E669320 
32EE5C4C3FA15CCADB46ABE529D4BCB6416F53EC 
B8B3F1C0E58C15DB6A81D30C3648A882F4316B9B 
CA03882CB1FC067B5D3ACFE4D300116E1C875A3D

Ці ключі належать наступним людям:

Чи означає це, що ми довіряємо цим п’ятьом людям? Не зовсім. Ключі не є доказом особистості – теоретично, вони можуть потрапити в руки інших людей. У чому ви дійсно можете переконатися, запустивши скрипт 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? Це учасники, які накопичили достатній соціальний капітал завдяки своєму внеску в проект протягом тривалого часу. Коли чергові помічають компетентного учасника, який продемонстрував свою надійність і мотивацію в певній галузі, вони можуть прийняти рішення дати його аккаунту розширені права на гітхабі. У свою чергу, головний черговий спостерігає за всіма аспектами проекту і відповідає за координацію релізів. Ця роль добровільно передавалася один одному наступними людьми:

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

Так само вчинили і з Джеффом Гарзіком , виключивши його зі сховищ на гітхабі – що засмутило його і багатьох інших – але до того моменту він не брав участі в проекті на протязі вже двох років . Залишити його аккаунту адміністративних привілеїв значило створити потенційну загрозу безпеці проекту і порушити принцип найменших привілеїв, на який посилається ван дер Лаан у своєму пості.

При погляді на Core з боку може здатися, що це закритий світ, створений технократами, в який вкрай складно потрапити новачкові. Але якщо ви поговорите з учасниками, то зрозумієте, що це не так. Хоча за всі ці роки лише дюжина людей мала доступ до зміни коду, сотні розробників внесли свою лепту в проект – і я в їх числі. Хоч я і не вважаю себе розробником Bitcoin Core – технічно я ним є. Ніхто не може перешкодити вам внести свій внесок!

У 2011 році, коли я був старшокласником, який не розумів що таке покажчик (pointer), співтовариство розробників @bitcoincoreorg (особливо такі люди, як Грег Максвелл, 
@pwuille і т. д.) допомагали мені привести мої гімняні патчі в гідний вигляд, і цим створили прекрасні умови для навчання.
У 2016 році@TheBlueMatt організував навчальний табір в @ChaincodeLabs . 
Я читав всі матеріали про біткоін, які траплялися мені в руки, але не наважувався відкривати свої пул-реквести. Метт, Алекс і Сухас щедро ділилися своїми знаннями, навчаючи нас основам роботи біткоін, і тому, як брати участь в розробці.
Коли я почав вносити свій скромний внесок в @bitcoincoreorg , я був в захваті від того, що @MarcoFalke @pwuille @orionwl @LukeDashjr і @jfnewbery брали участь в обговоренні моїх пул-реквестов. Такий доброзичливий проект!

Схоже, людям вкрай складно зрозуміти, що розробка біткоін не залежить від структури сховища Bitcoin Core на гітхабі. Хоча Bitcoin Core і має деяку структуру (для координації використовуються централізовані канали зв’язку), сам проект не контролюється будь-ким з учасників – навіть тими, хто має особливі привілеї в репозиторії гітхаба. Хоча технічно чергові можуть захопити репозиторій, піддати цензурі незгодних розробників і, можливо, навіть зберегти за собою назву «Bitcoin Core» – це буде лише означати, що розробка проекту переїде з Bitcoin Core в інше місце. Якщо розробники перестануть погоджуватися з діями чергових, то вони просто скопіюють код і перенесуть свою роботу в інший репозиторій, в якому попередні чергові Bitcoin Core не матимуть адміністративних привілеїв.

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

Форкнути код – дуже просто. Змістити центр фокусу розробки біткоіну – складно: ви повинні переконати учасників, що їм буде краще брати участь в іншому проекті.

Я не присягаю на вірність нікому, жодній команді розробників. 
Моя мета – запускати той код, що, як я вважаю, найкращим чином захистить мій фінансовий суверенітет.

У деяких людей є думка – і їх важко в ній переконати – що користувачі 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 ). Показовий приклад: хоча Джон Ньюбері і не був автором коду, який тримав в собі баг консенсусу, він тим не менше взяв на себе відповідальність за його потрапляння в реліз – тому що не зміг виявити його при перевірці – і за те, що не зміг знайти цей баг пізніше, коли прописував різні варіанти тестування:


Я несу відповідальність за баг CVE-2018-17144. 
[@Orionwl: Погано, що був доданий код з багами. 
Так, ми облажались, але це «ми» – дуже широке поняття. 
Все співтовариство винне в тому, що недостатньо уважно перевіряла запропоновані зміни. 
Розробникам потрібно бути уважнішими! 
Ця відповідальність лежить на всіх вас.]

Ми всі – Сатоши.


Візуалізація розробки Bitcoin Core

Участь в Bitcoin Core

Може здатися, що почати свій шлях в Core – це щось лякаюче складне, але в мережі є чимало ресурсів, покликаних допомогти розробникам-початківцям. Рекомендації та правила для учасників можна знайти тут, хоча, можливо, краще навіть почати з ненав’язливого вступу за авторством Джиммі Сонга : https://bitcointechtalk.com/a-gentle-introduction-to-bitcoin-core-development-fdc95eaee6b8

Core розробник Ерік Ломброзо також написав статтю про те, як відбуваються зміни в репозиторії Core: https://bitcointechtalk.com/a-gentle-introduction-to-bitcoin-core-development-fdc95eaee6b8

Алекс Б. написав відмінну статтю про філософію розробки біткоіни – раджу прочитати це будь-кому навмисному брати участь в проекті всерйоз: https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd

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

Хто контролює біткоіни ?

Як я неодноразово повторював протягом багатьох років, повністю зрозуміти біткоін як систему практично неможливо. Визначення протоколу біткоіну подібно визначенню мови. Мови розвиваються органічно: слова з часом самі знаходять своє значення, а не беруть його з словників. Так само як словники описують мову, а не визначають її, так і програмні реалізації біткоіну описують мову біткоіну за допомогою коду. Ніхто не зобов’язаний погоджуватися з визначенням даного слова в словнику, так само як і не зобов’язаний погоджуватися з кодом в даній програмній реалізації біткоіну, запускаючи його.

Мовами не керує демократія, і точно так само вона не керує біткоіном. Незважаючи на це, постійно можна чути, як люди посилаються на майнерів, нод, розробників або користувачів, які можуть «голосувати» за щось – але насправді механізму, який би змусив меншість прийняти зміни, за які проголосувала більшість, не існує . Біткоін – це анархія: без правителів, але не без правил. Правила визначаються і застосовуються окремими учасниками мережі.

Хоча зміни в сам протокол біткоіну зазвичай вносяться через так звані Bitcoin Improvement Proposal , навіть це всього лише рекомендована і найпоширеніша практика, і ніхто не зобов’язаний її дотримуватися. Це просто більш формалізований спосіб розгляду запропонованих учасниками змін: спочатку вони піддаються експертній оцінці, а потім повинні отримати загальне схвалення.

Як би важко не було це пояснити або зрозуміти, тут і полягає важливий аспект «антихрупкості» біткоіну: якби існувала єдина точка контролю – вона ж і була б головним вразливим місцем, на яке могли б натиснути структури, яким біткоіни загрожує. В кінцевому рахунку, кожен оператор Ноди сам собі начальник в тому сенсі, що він особисто стежить за тим, щоб ніхто в мережі не порушував правил, які він вважає вірними. Ця модель безпеки  - основа управління біткоіном, яка будується за принципом «знизу – вгору».

Ніхто не контролює біткоіни.

Ніхто не контролює розробку біткоіну.

You May Also Like

About the Author: jejalic

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *