Bitcoin Core rozważa rezygnację z obsługi szyfrowanego routingu, ponieważ słaba kondycja węzłów naraża użytkowników na ataki eklipsowe

Współpracownicy Bitcoin Core zastanawiają się, czy rzadko używany transport sieciowy oferuje cenną ochronę, czy stał się zbyt kosztownym obciążeniem do utrzymania.

W otwartej dyskusji na temat wsparcia CJDNS, członek Bitcoin Core Andrew Chow powiedział, że jedna baza danych seederów zawierała 25 adresów CJDNS, osiągnęła 22 i sklasyfikowała tylko siedem jako dobre. Autor problemu, Martin Zumsande, zgłosił, że widział tylko trzech lub czterech partnerów, mimo że Bitcoin Core dostarcza 11 stałych nasion CJDNS.

Te liczby skłoniły do poparcia deprecjacji i zasugerowania, aby Bitcoin Core ostrzegł użytkowników w wersji 32.x przed planowanym usunięciem w 33.x. Jednak ta sekwencja wersji została postawiona jako pytanie. Na niedzielę, 23 sierpnia, problem pozostał otwarty w kamieniu milowym 32.0, a jego sekcja rozwoju była pusta w zakresie gałęzi implementacyjnej lub pull requestu.

Bitcoin Core implementuje CJDNS jako opcjonalny transport peer-to-peer i obsługę adresów, poza systemem konsensusu Bitcoin. Problem #36041 pyta, czy Bitcoin Core powinien zachować obsługę adresów CJDNS jako zapas, gdy cienka pula partnerów może również sprawić, że węzły tylko CJDNS będą łatwiejsze do otoczenia.

Siedem dobrych węzłów Bitcoin Core uchwyciło jeden zrzut seederów

Liczby seederów opisują bazę danych jednego crawlera w jednym momencie. Globalna populacja CJDNS może być większa, ponieważ liczba ta obejmuje tylko bazę danych tego crawlera.

Seeder stosuje "dobry" jako surowszy filtr techniczny niż osiągalność. W implementacji Chow'a DNSSeedrs, węzeł musi przejść kontrole dotyczące swojego portu, reklamowanej usługi sieciowej, wersji protokołu, wysokości łańcucha i niezawodności. Testy niezawodności wykorzystują kilka okien czasowych i wymagają minimalnych liczby prób. To wyjaśnia, jak seeder mógł osiągnąć 22 adresy, klasyfikując tylko siedem jako dobre.

Tylko siedem z 22 osiągniętych adresów przeszło filtry dobrego węzła, pozostawiając płytką pulę użyteczną. Węzeł Zumsande'a znalazł tylko trzech lub czterech partnerów i zaproponował niskie liczby w trzech cyfrach jako przybliżony poziom, który mógłby uzasadnić dalsze wsparcie. Niski próg w trzech cyfrach był tylko Zumsande'a, dając konserwatorom liczbę do dyskusji zamiast tylko ogólnej skargi na niskie użycie.

Aritmetyka liczby partnerów sama w sobie pozostawia koszt eklipsy nieznany. Bitcoin Core normalnie utrzymuje osiem pełnych połączeń wychodzących i dwa połączenia tylko do przesyłania bloków, z okazjonalnym czujnikiem lub dodatkowym połączeniem tylko do przesyłania bloków. Współpracownik zasugerował, aby jakikolwiek próg CJDNS opierał się na koszcie wypełnienia tych regularnych slotów i eklipsy węzła tylko CJDNS.

Atak eklipsowy izoluje węzeł, monopolizując partnerów, którzy kształtują jego widok sieci. W transporcie z małym znanym zestawem adresów, atakujący ma bardziej skoncentrowany cel. Obecna dokumentacja CJDNS w Bitcoin Core już zniechęca do działania tylko CJDNS, ponieważ węzeł może nie wypełnić swoich slotów wychodzących, wielokrotnie próbując kilka adresów, które zna, i stając się bardziej podatnym na ataki Sybila.

Sukces eklipsy zależy od więcej niż dziesięciu regularnych slotów wychodzących. Publiczna dyskusja pozostawia pełny koszt ataku nieokreślony. Dostępność adresów, wybór adresów, bramy niezawodności crawlerów i okazjonalne dodatkowe połączenia wychodzące wpływają na praktyczną ekspozycję. Mierzona pula wspiera obawy o koncentrację dla węzłów tylko CJDNS, podczas gdy koszt wykorzystania tej obawy pozostaje nieokreślony.

Redundancja zależy od sposobu użycia CJDNS

CJDNS oferuje inną propozycję, gdy jest jedną z kilku ścieżek. Dokumentacja Bitcoin Core przedstawia go jako opcjonalną opcję obok IPv4, IPv6, Tor i I2P, pozwalając węzłowi zachować inną trasę dostępną, jeśli jedna sieć ma problemy.

Ta opcja stała się łatwiejsza w użyciu. CJDNS 22.1 wprowadził automatyczne połączenia DNS-seeded 8 stycznia 2025 roku, co uczyniło ręczne dodawanie partnerów opcjonalnym. Bitcoin Core następnie połączył zaktualizowaną dokumentację konfiguracji 30 marca 2026 roku, zastępując przestarzałe instrukcje ręcznego łączenia nowym przepływem.

Te zmiany zmniejszyły tarcia w konfiguracji. Jakikolwiek wpływ na populację partnerów CJDNS w Bitcoin pozostaje niezmierzony. Bitcoin Core połączył inną zmianę dokumentacji 18 sierpnia 2026 roku, wyraźnie zniechęcając do użycia tylko CJDNS, ponieważ pula adresów pozostawała zbyt mała, aby niezawodnie wypełnić sloty wychodzące.

Operatorzy tylko CJDNS i mieszanych sieci stają więc przed różnymi stawkami. Operator tylko CJDNS staje w obliczu ryzyka cienkiej puli, o którym dokumentacja teraz ostrzega. Operator mieszanej sieci używa CJDNS dla opcjonalnej różnorodności tras i może zachować inne automatyczne ścieżki, nawet gdy CJDNS ma mało partnerów.

Przyszła deprecjacja usunęłaby ustawienia transportu, pozostawiając zasady ważności bloków bez zmian. Bitcoin Core dodał pełne wsparcie CJDNS w wersji 23.0 jako funkcję sieci P2P. Debata ogranicza się do obsługi adresów i opcji połączeń; zasady konsensusu i ważności bloków Bitcoin znajdują się poza jej zakresem.

Bezpośrednio dotkniętymi operatorami byliby ci, którzy używają -cjdnsreachable, co mówi Bitcoin Core, aby traktować odpowiedni zakres IPv6 jako CJDNS, lub -onlynet=cjdns, co ogranicza automatyczne połączenia wychodzące do tego transportu. Ta sama opcja może obecnie być łączona z innymi sieciami, podczas gdy połączenia przychodzące i ręcznie dodane pozostają dostępne pod -onlynet, zgodnie z dokumentacją.

Problem #36041 pozostaje otwarty, z ostrzeżeniem i sekwencją usunięcia zapisanymi tylko jako propozycja. Pokazuje to mały obserwowany zestaw partnerów, wiele wyrazów poparcia dla deprecjacji i jedną proponowaną sekwencję wydania. Pokazuje również, dlaczego liczba użycia sama w sobie jest niekompletnym testem: pojemność zapasowa jest najcenniejsza przed awarią głównej trasy, ale zapasowa sieć, która nie wypełnia połączeń, może oferować mniejszą odporność, niż sugeruje jej obecność w kodzie.

Bitcoin Core nadal wspiera CJDNS. Połączone ostrzeżenie lub pull request usunięcia zmieni status debaty. Siedem dobrych węzłów czyni wymianę transportu mierzalną i pozostawia wybór usunięcia otwartym.

Niniejsza treść ma charakter wyłącznie informacyjny i nie stanowi porady finansowej, inwestycyjnej, prawnej ani podatkowej. Wszelkie wydarzenia, nagrody, promocje online lub powiązane informacje, o których tu mowa, nie powinny być traktowane jako rekomendacja, zachęta ani zaproszenie do kupna, sprzedaży, wymiany lub innego rodzaju obrotu aktywami kryptograficznymi. Aktywa kryptograficzne charakteryzują się dużą zmiennością i mogą prowadzić do strat. Dostępność usług, produktów i powiązanych wydarzeń WEEX może się różnić w zależności od regionu. Użytkownik jest odpowiedzialny za upewnienie się, że jego udział jest zgodny z obowiązującymi lokalnymi przepisami i regulacjami.