Bitcoin Magazine: Otwarte oprogramowanie a source-available: czego porażka Coldcard ujawnia o bodźcach w oprogramowaniu Bitcoin

Kod zamknięty i otwarty od ponad dekady dzielą branżę Bitcoina oraz szerzej pojętego krypto. Zwolennicy Bitcoina od dawna argumentują, że infrastruktura finansowa świata powinna być budowana publicznie, ponieważ przejrzystość i możliwość audytu są nie do negocjacji, gdy w grę wchodzą prawdziwe pieniądze. Warstwa aplikacyjna i starsze warstwy finansów często się z tym nie zgadzają.

Niedawny atak na Coldcard, popularny sprzętowy portfel do samodzielnej kontroli, w którym użytkownicy stracili bitcoin o wartości ponad 100 milionów dolarów, czyli ponad 1,500 BTC, wywołał pytania o to, co właściwie oznacza „open source”. Sugerował też, że wiele osób, w tym także niektórzy poważni bitcoinowcy, słabo rozumie filozofię oprogramowania open source oraz warunki, w których ona zawodzi.

Zasady i terminologia

Język związany z open source bywa mylący. Free and Open Source Software (FOSS) oraz Free/Libre and Open Source Software (FLOSS) opisują oprogramowanie spełniające formalne definicje wolności użytkownika.

Free Software Foundation (FSF) definiuje wolne oprogramowanie poprzez cztery podstawowe wolności:

Wolność 0: Wolność uruchamiania programu, jak chcesz, w dowolnym celu.

Wolność 1: Wolność studiowania działania programu i zmieniania go tak, aby robił to, czego potrzebujesz. Dostęp do kodu źródłowego jest tu warunkiem koniecznym.

Wolność 2: Wolność redystrybucji kopii, aby móc pomagać innym.

Wolność 3: Wolność rozpowszechniania kopii zmodyfikowanych wersji innym. Dostęp do kodu źródłowego jest tu warunkiem koniecznym.

FSF podkreśla, że „free” oznacza wolność, a nie cenę, w znanym powiedzeniu używanym przez zwolenników FOSS: „„free” jak w „free speech”, a nie jak w „free beer””.

Definicja Open Source Initiative dodaje dziesięć praktycznych kryteriów. Obejmują one swobodną redystrybucję bez opłat licencyjnych, dostępność kodu źródłowego w preferowanej formie do modyfikacji, prawo do tworzenia i rozpowszechniania utworów zależnych oraz brak dyskryminacji wobec osób, grup lub dziedzin działalności — w tym użycia komercyjnego. Licencja musi spełniać wszystkie dziesięć kryteriów, aby kwalifikować się jako open source według standardu OSI.

„Source available” albo „source viewable” to coś innego. Kod może być publicznie czytelny, podczas gdy licencja nadal ogranicza prawo do jego sprzedaży. Firmware Coldcard jest na przykład wydawany na warunkach MIT wraz z Commons Clause. Klauzula ta konkretnie usuwa prawo do „Sell” oprogramowania — rozumianego jako udostępnianie go osobom trzecim za opłatą lub inne świadczenie w produkcie bądź usłudze, której wartość wynika w całości lub w istotnej części z samego oprogramowania. Innymi słowy, firmware Coldcard nie mógł być używany komercyjnie.

FAQ Commons Clause wprost wskazuje różnicę: „Is this ‘Open Source’? No.” Zauważa, że zastosowanie klauzuli oznacza, iż oprogramowanie spełnia wiele elementów definicji Open Source, ale nie wszystkie, i dlatego nie powinno być nazywane open source.

Te rozróżnienia mają znaczenie. Opublikowanie kodu źródłowego tworzy możliwość jego analizy. Nadanie pełnego zestawu praw określonych przez Free Software Definition lub Open Source Definition to właśnie to, co czyni oprogramowanie FOSS lub FLOSS. Jednak samo posiadanie takiej etykiety nie jest sednem sprawy. Krytycy twierdzą, że komercyjna swoboda w FOSS uruchamia bodźce dla osób trzecich do testowania i przeglądania kodu, których w innym wypadku mogłoby nie być.

Cztery wolności stanowią filozoficzne jądro open source, lecz w praktyce opierają się na założeniu ekonomicznym: że wystarczająco dużo zmotywowanych osób rzeczywiście przeanalizuje kod. Gdy to założenie zawodzi, system przypomina klasyczną tragedię wspólnego pastwiska, sytuację, w której wspólny zasób jest nadmiernie wykorzystywany lub zaniedbywany, ponieważ jednostki działają zgodnie z własnym krótkoterminowym interesem zamiast długoterminowego interesu grupy.

Każda osoba ma bodziec, by brać więcej albo wnosić mniej, niż jest to zrównoważone, a zasób w konsekwencji się degraduje. Do takiej sytuacji dochodzi, gdy istnieje brak zgodności między krótkoterminowym interesem własnym jednostki a długoterminowym interesem grupy. Czasem zgodność istnieje; czasem nie.

Jeden z deweloperów Bitcoina ujął problem bez ogródek: „Using mocks and stubs of Open Source code in tests is irresponsible and shortsighted. Open Source code is considered safe because anyone can verify it. If you aren’t willing to do the bare minimum of testing the features you actually depend on, then you are behaving like a leech.”

W rezultacie open source samo w sobie nie tworzy bezpieczeństwa. Tworzy możliwość weryfikacji. To, czy ta weryfikacja nastąpi, zależy od bodźców, umiejętności i uwagi. Historyczny FOSS z czasem zwykle twardnieje, gdy luki są odkrywane, ujawniane i łatane, tworząc solidne fundamenty dla innych. Jądro Linux jest świetnym przykładem takiego dojrzałego FOSS; zasila zdecydowaną większość serwerów na świecie, infrastrukturę chmurową, urządzenia z Androidem i systemy wbudowane, co czyni je jednym z najpowszechniej wdrożonych elementów oprogramowania w historii.

Open source na przykładzie Bitcoin Core

Bitcoin Core, referencyjna implementacja Bitcoina, jest kolejnym dużym, dalekowzrocznym przykładem działania czystego open source w praktyce. Oprogramowanie, które działa za większością infrastruktury związanej z Bitcoinem, jest wydawane na licencji MIT. Jego proces rozwoju jest z założenia publiczny.

Każdy może otworzyć pull request. Code review jest podstawowym filtrem i zalecanym punktem wejścia dla nowych współtwórców. Recenzenci używają formalnego słownictwa: Concept ACK, czyli potwierdzenie i zgoda co do celu; Approach ACK, czyli zgoda co do celu i metody; ACK z konkretnym hashem commita, czyli przetestowane i zatwierdzone do scalenia; albo NACK, czyli sprzeciw, któremu powinna towarzyszyć argumentacja techniczna.

Opiekunowie projektu oceniają konsensus wśród współtwórców i techniczne zalety zmiany przed jej scaleniem. Zmiany krytyczne dla konsensusu mają jeszcze wyższy próg i zwykle wymagają Bitcoin Improvement Proposal oraz szerokich, wieloletnich dyskusji na liście mailingowej bitcoin-dev i na IRC.

Nie istnieje uprzywilejowana kasta „deweloperów Bitcoin Core”. Zaufanie zdobywa się przez wykazywaną przez czas kompetencję. Opiekunowie istnieją z praktycznych powodów — do audytu i scalania kodu, zarządzania wydaniami oraz podstawowej moderacji — ale wytwarzana praca to czysty kod open source, który każdy może przejrzeć, zbudować, rozwidlić albo uruchomić. Deweloperów, których commity trafiają do Bitcoin Core, określa się szeroko jako Bitcoin Core Contributors.

Calle, wieloletni deweloper Bitcoina w modelu open source, podsumował niedawno sytuację: „People who think that core is some sort of intransparent institution operating in the shadows are either too lazy or too dumb to go have a look for themselves. Literally everything they do is public, anyone can chime in, and the result of their work is pure Open Source code.”

Finansowanie tej pracy pochodzi w dużej mierze ze struktur non-profit i grantowych, takich jak Brink, OpenSats, Spiral i inne, a nie z tradycyjnego firmowego roadmapu produktowego. Dyskusje techniczne i debaty toczą się publicznie na liście bitcoin-dev oraz na kanale IRC #bitcoin-core-dev w Libera Chat, gdzie propozycje są analizowane przed i w trakcie procesu pull requestów. Zgłoszenia i pull requesty na GitHubie często zawierają historię komentarzy sięgającą dekady. Efektem jest kultura rozwoju zoptymalizowana pod kątem poprawności i audytowalności, a nie szybkości czy komercyjnego tempa dostarczania funkcji.

Ekonomia open source

Większość użytkowników oprogramowania open source lub source-available nigdy nie czyta samodzielnie kodu. Polegają na założeniu, że ktoś inny go analizuje. W przypadku Coldcard krytyczna wada entropii pozostawała w publicznie dostępnym firmware przez około pięć lat, zanim została wykorzystana i w ten sposób odkryta.

Błąd trafił do bazy kodu podczas dużego przepisywania w 2021 roku, które usunęło także pozostały kod pochodzący z GPL z Trezor, pierwszego portfela sprzętowego i obecnie drugiego co do wielkości w branży self-custody. Biblioteka będąca centrum problemu z entropią, która zastąpiła trezor-crypto, nazywa się libngu i była poddana minimalnej zewnętrznej kontroli, mając tylko 7 gwiazdek i mniej niż 20 forków po ponad 5 latach użycia produkcyjnego. Dla porównania biblioteka trezor-crypto ma 512 gwiazdek i 212 forków, a bardziej nowoczesne trezor-firmware ma 793 forki i 1.8k gwiazdek. Sama dostępność źródeł nie doprowadziła do tego rodzaju przeglądu, który miał znaczenie, ponieważ inne dobrze finansowane firmy komercyjne miały być od niego odcięte — przynajmniej tak twierdziliby krytycy.

W praktyce oznacza to, że wybory licencyjne są czymś więcej niż prawną ciekawostką: wpływają na to, kto może uczestniczyć w przeglądzie, kto ma motywację, by go przeprowadzać, oraz jak szybko błędy mogą zostać zauważone w oprogramowaniu chroniącym realne środki. Stawka w Bitcoinie jest wyższa niż w większości innych dziedzin oprogramowania. Krytyczną lukę można bezpośrednio zamienić na płynne środki na otwartym rynku. Choć pierwsza połowa skradzionych środków z Coldcard nadal znajduje się pod kontrolą w kilku adresach i haker może kiedyś zostać złapany, kolejni naśladowcy byli ostrożniejsi, a niektórzy ukradli więcej bitcoinów i skutecznie je wyprali, według Galaxy Research. Odporność Bitcoina na cenzurę i nieodwracalność transakcji tworzą zarówno silny bodziec dla atakujących, jak i darwinowski filtr: długoterminowo zwykle przetrwają tylko projekty, które stale przyciągają kompetentny przegląd, oraz użytkownicy i firmy podejmujące poważne środki ostrożności.

Według zwolenników FOSS, którzy od lat krytykowali decyzje licencyjne Coinkite, wybory dotyczące licencji kształtują te bodźce. Czyste licencje open source maksymalizują pulę potencjalnych recenzentów i forków. Ograniczone licencje „source available” mogą zmniejszać komercyjne pasożytnictwo, ale mogą też zawężać krąg osób, które mają zarówno prawo prawne, jak i ekonomiczną motywację do głębokiego zaangażowania. W tym sensie ciężar przeglądu kodu wraca do firmy działającej w ramach restrykcyjnej licencji, zbliżając ją w pewnym stopniu bardziej do kodu zamkniętego niż otwartego.

Jak AI zmienia rozwój open i closed source

Sztuczna inteligencja zmienia obecnie także równowagę między FOSS a closed source.

Po incydencie Coldcard ochotnicza inicjatywa znana jako Bitcoin Red Team — prowadzona przez deweloperów, w tym Calle i Roba Hamiltona z AnchorWatch, oraz wspierana przez OpenSats — użyła zaawansowanych modeli AI do skanowania setek otwartych repozytoriów Bitcoina. W jednym intensywnym okresie zespół zgłosił tysiące znalezisk, w tym dziesiątki sklasyfikowanych jako krytyczne lub wysokiego ryzyka, w setkach projektów. Zanim doszło do szerszej publikacji, opiekunowie otrzymali odpowiedzialne ujawnienia. Ćwiczenie pokazało, że systematyczny przegląd wspomagany przez AI może wykrywać problemy w skali i z prędkością wcześniej niepraktyczną dla zespołów wyłącznie ludzkich.

W tym obszarze Red Team uznał chińskie modele open-weight za znacznie bardziej niezawodne niż zamknięte amerykańskie modele, które — nawet przy uprawnieniach cybernetycznych i najwyższym poziomie dostępu — odmawiały odpowiedzi na pytania Red Teamu, co amerykańscy deweloperzy przyjęli z rozczarowaniem.

Jednocześnie zalew kodu generowanego przez AI stworzył nową presję typu denial-of-service na opiekunów projektów FOSS. Przeglądanie wyników AI często trwa dłużej niż ich wygenerowanie. Niektóre projekty open source poza Bitcoinem ograniczyły trackery zgłoszeń lub wprowadziły surowe zasady przeciwko wkładowi AI, po prostu po to, by zachować funkcjonalność.

Po stronie closed source tradycyjna przewaga bezpieczeństwa przez niejawność słabnie. Nowoczesne modele AI potrafią czytać kod, deobfuskować go, testować endpointy i rozumować o nim z dużą prędkością. Praktyczna różnica między open a closed source sprowadza się dziś głównie do kodu backendowego, który nigdy nie jest publicznie udostępniany online. W efekcie kod zamknięty opiera się przede wszystkim na jakości profesjonalnych audytów, szybkości wdrażania poprawek oraz strukturze bodźców, która utrzymuje kompetentne osoby z dostępem w stałej gotowości do przeglądu.

Bitcoin i szerzej branża krypto wywierają niezwykłą presję na wolne i otwarte oprogramowanie. Połączenie realnej wartości pieniężnej zagrożonej atakiem, ekonomii o charakterze antagonistycznym oraz analizy na skalę AI zmusza modele tworzenia oprogramowania do ewolucji. Powrót do analogowych systemów sprzed ery cyfrowej nie jest realną opcją dla infrastruktury podtrzymującej nowoczesne społeczeństwo. Prawdopodobnie przetrwają jedynie najbardziej audytowane projekty, odporne na presję hackerów wspieranych przez AI i ciężar finansów cyfrowych jako domyślnego standardu.

Ten artykuł, „Open Source vs. Source-Available: What the Coldcard Failure Teaches About Bitcoin Software Incentives”, po raz pierwszy ukazał się w Bitcoin Magazine i został napisany przez Juana Galta.