Nie usunięto żadnego kodu i nie podjęto ostatecznej decyzji, ale trwale niskie wskaźniki adopcji skłoniły współtwórców Bitcoin Core do ponownego przeanalizowania praktycznych kompromisów — bezpieczeństwa i inżynieryjnych — związanych z utrzymywaniem starszych sieci nakładkowych w głównym kliencie Bitcoina; debata koncentruje się teraz na tym, czy szyfrowana sieć routingu CJDNS nadal uzasadnia swoje miejsce w implementacji referencyjnej.

Siedem „dobrych” węzłów wywołuje szerszy audyt infrastruktury

Techniczna dyskusja rozpoczęła się w otwartym issue na GitHubie, gdzie deweloperzy zakwestionowali, czy Bitcoin Core powinien nadal wspierać szyfrowaną warstwę routingu, w której notuje się niemal brak udokumentowanego rzeczywistego ruchu. Głównym celem dodawania alternatywnych warstw transportu sieciowego do Bitcoina jest redundancja: zapobieganie każdemu pojedynczemu punktowi awarii lub cenzury na poziomie sieci. Trasy zapasowe funkcjonują jednak tylko wtedy, gdy w sieci bazowej uczestniczy aktywna siatka peerów.

Podczas zautomatyzowanych testów konfiguracji węzła działającego wyłącznie przez CJDNS deweloper Core Marco Falke zgłosił, że jego instancja nie była w stanie nawiązać w danym momencie połączeń z więcej niż trzema lub czterema różnymi peerami. W ramach pogłębienia tej obserwacji inny współtwórca odpytał uznaną bazę danych seederów sieci — usługi bootstrapowe przekazujące świeżo uruchomionym węzłom ich pierwsze adresy peerów — zawierającą 25 znanych adresów CJDNS. Z 25 przetestowanych adresów 22 odpowiedziało na podstawowe handshaki, ale tylko siedem spełniło kryteria techniczne wymagane, by uznać je za niezawodnych, „dobrych” peerów do aktywnego propagowania bloków i transakcji.

Pojedyncze zapytanie do seederów nie stanowi absolutnego spisu wszystkich działających węzłów w całym ekosystemie CJDNS; prywatne, nieogłaszane węzły i niezaindeksowani peerowie mogą nadal istnieć poza publicznymi listami seederów. Mimo to te liczby uwypuklają poważną praktyczną rzeczywistość: sieć nakładkowa z mniej niż dwunastoma dostępnymi celami routingu nie zapewnia redundancji operacyjnej wymaganej od odpornego węzła produkcyjnego. Dla skali: długo działające publiczne crawle zliczyły osiągalne węzły Bitcoina ogłaszane w sieci Tor w liczbie kilku tysięcy, wobec 25 adresów zgromadzonych przez seeder CJDNS.

Zrozumienie CJDNS: szyfrowany routing IPv6 kontra reguły konsensusu

CJDNS to szyfrowana sieć nakładkowa mesh oparta na IPv6, wykorzystująca kryptografię klucza publicznego do przydzielania adresów i rozproszonego routingu. Poza Bitcoinem protokół jest najlepiej znany jako warstwa routingu Hyperborii — prowadzonej przez wolontariuszy społecznościowej sieci mesh. Bitcoin Core dodał natywną obsługę CJDNS w wersji 23.0 w 2022 roku, umożliwiając operatorom węzłów kierowanie ruchu peerów przez CJDNS obok IPv4, IPv6, Tora i I2P.

Zgodnie z dokumentacją Bitcoin Core CJDNS szyfruje ruch end-to-end i może utrudniać analizę oraz filtrowanie ruchu. Nie jest jednak siecią anonimizującą w takim sensie jak Tor: pośrednie routery CJDNS wciąż mogą widzieć kryptograficzne adresy źródłowe i docelowe pakietów, które przekazują.

Propozycja dotyczy wyłącznie sposobu, w jaki Bitcoin Core znajduje peerów i łączy się z nimi. Usunięcie obsługi CJDNS nie zmieniłoby walidacji bloków, wydobycia, reguł skryptów ani formatów transakcji; węzły nadal egzekwowałyby te same reguły konsensusu Bitcoina.

Mechanika bezpieczeństwa ataku eclipse

W bezpieczeństwie węzłów Bitcoina transport sieciowy i selekcja peerów są bezpośrednio powiązane z integralnością danych. Szyfrowanie ukrywa zawartość pakietów przed stronami trzecimi, ale nie chroni węzła przed dostarczaniem mu fałszywych lub opóźnionych informacji, jeśli pula jego peerów jest zbyt ograniczona. Wąska pula peerów podkopuje bezpieczeństwo, wyraźnie ułatwiając złośliwym podmiotom izolowanie węzłów działających wyłącznie przez CJDNS i manipulowanie nimi.

Głównym zagrożeniem dla odizolowanych węzłów jest atak eclipse. W ataku eclipse przeciwnik przejmuje kontrolę nad wszystkimi połączeniami peerów nawiązanymi przez węzeł docelowy. Otaczając całkowicie węzeł docelowy, atakujący skutecznie oddziela go od legalnej, globalnej sieci Bitcoina. Z tej pozycji napastnik może manipulować obrazem blockchainu widzianym przez ofiarę, opóźniając ogłaszanie bloków, cenzurując określone przychodzące transakcje lub próbując ataków podwójnego wydatku wobec transakcji niepotwierdzonych.

Przy standardowym routingu IPv4, IPv6 lub Tor Bitcoin Core łagodzi ataki eclipse, nawiązując wiele niezależnych połączeń w obrębie zróżnicowanych netgroup i zakresów sieciowych; domyślnie oprogramowanie utrzymuje jednocześnie osiem otwartych wychodzących połączeń full-relay. Gdy węzeł działa wyłącznie w sieci dysponującej tylko siedmioma niezawodnymi peerami — mniej niż wynosi liczba domyślnych gniazd wychodzących — łączna pula dostępnych połączeń jest daleko zbyt mała: atakujący potrzebuje bardzo niewielkich zasobów, by zmonopolizować wszystkie połączenia przychodzące i wychodzące węzła działającego tylko przez CJDNS, przemieniając zamierzony mechanizm bezpieczeństwa w poważny pojedynczy punkt awarii.

Złożoność kodu i argumenty za wycofaniem

Oprócz niskich wskaźników adopcji i obaw bezpieczeństwa deweloperzy opowiadający się za usunięciem podkreślają ciągnące się obciążenie utrzymaniowe, jakie kod CJDNS nakłada na całe repozytorium oprogramowania Bitcoin Core.

W przeciwieństwie do standardowych modułów obsługi protokołów integracja CJDNS nie jest całkowicie odizolowana od standardowej logiki połączeń IPv6. Ponieważ CJDNS wykorzystuje specjalnie sformatowane adresy IPv6, baza kodu wymaga dedykowanej logiki obsługi, specjalnych argumentów uruchomieniowych, takich jak -cjdnsreachable, oraz wyspecjalizowanych obejść dla przypadków brzegowych. Z czasem deweloperzy zauważyli, że te niestandardowe ścieżki logiczne wprowadzają ryzyko błędów i komplikują rutynowe refaktoryzacje stosu sieciowego. Warstwa transportu jest przy tym rozwijana: szyfrowany transport v2 zgodny z BIP 324 trafił jako opcja w wersji 26.0 i został domyślnie włączony w wersji 27.0 — nowy kod połączeń pojawia się w czasie, gdy starsze ścieżki, takie jak CJDNS, są ponownie oceniane.

Kilku współtwórców Core złożyło „Concept ACK” wobec wycofania protokołu. W terminologii rozwoju otwartoźródłowego Bitcoin Core „Concept ACK” oznacza, że współtwórca zgadza się z ogólnym celem propozycji; nie stanowi to ostatecznego głosu, scalenia kodu ani natychmiastowego zobowiązania do usunięcia funkcji.

Argumenty za długoterminowymi rezerwami awaryjnymi

Po drugiej stronie sporu deweloperzy wzywający do ostrożności argumentują, że użyteczność węzła nie powinna być oceniana wyłącznie na podstawie bieżących metryk ruchu. Współtwórca Jon Atack zwrócił uwagę, że automatyczne wykrywanie peerów CJDNS zintegrowano z Core dopiero na początku 2025 roku. Przed tą aktualizacją operatorzy węzłów musieli ręcznie konfigurować adresy peerów — proces stwarzający istotną barierę wejścia w porównaniu z dostępnymi dla Tora lub I2P konfiguracjami jednym kliknięciem.

Zwolennicy argumentują, że niskie liczby użycia CJDNS wynikają z braku świadomości użytkowników i ograniczonej integracji w popularnych, gotowych dystrybucjach oprogramowania węzłów, a nie z braku wartości samego protokołu. Gdyby główne publiczne sieci anonimizujące, takie jak Tor lub I2P, spotkało scentralizowane blokowanie, awarie infrastruktury lub filtrowanie na poziomie państwa, alternatywne protokoły mesh, takie jak CJDNS, mogłyby zapewnić kluczowy awaryjny kanał zapasowy do utrzymywania połączeń z peerami.

Atack zgłosił się także na ochotnika do osobistego utrzymywania kodu integracji CJDNS, odpowiadając tym samym na obawy dotyczące obciążenia deweloperów. Współtwórcy Core muszą teraz zdecydować, czy zachować alternatywną trasę transportu na wypadek awaryjnych sytuacji brzegowych, czy usprawnić bazę kodu, usuwając logikę sieciową o niskim wykorzystaniu.

Co potencjalne usunięcie oznacza dla operatorów węzłów

Gdyby Bitcoin Core ostatecznie usunął natywną integrację CJDNS w przyszłym wydaniu, oprogramowanie po prostu przestałoby zarządzać połączeniami peerów CJDNS wewnątrz warstwy aplikacji. Zmiana nie przeszkodziłaby operatorom w uruchamianiu CJDNS zewnętrznie na poziomie systemu operacyjnego ani nie zmieniłaby sposobu, w jaki cała sieć Bitcoina przetwarza transakcje.

Usunięcia w Bitcoin Core podążają zazwyczaj powolnym, udokumentowanym torem — wycofanie sygnalizowane jest w notatkach wydaniowych, a kod usuwany dopiero w późniejszym głównym wydaniu, zgodnie z mniej więcej półrocznym rytmem wydań projektu — dlatego sygnały wartych obserwacji to wątek na GitHubie, ewentualny formalny pull request dotyczący wycofania oraz to, czy automatyczne wykrywanie peerów dodane w 2025 roku poprawi liczby adopcji, zanim opiekunowie podejmą decyzję.

Dla zdecydowanej większości operatorów węzłów, którzy polegają na standardowych połączeniach IPv4, IPv6, Tor lub I2P, usunięcie CJDNS przeszłoby całkowicie niezauważone. Trwająca dyskusja odzwierciedla rygorystyczną filozofię inżynieryjną Bitcoin Core: każda linia kodu musi uzasadniać swoje istnienie sprawdzonym bezpieczeństwem i aktywną użytecznością.

Ten artykuł ma wyłącznie charakter informacyjny i nie stanowi porady inwestycyjnej.

Źródło: Coindoo