Błąd vardiff w kopaniu Bitcoina może pozostawić ograniczone koparki palące prąd przy niezliczonej pracy
Najważniejsze informacje
- •Bitcoin Optech zwrócił uwagę na tryb awarii zmiennej trudności 18 września, przybliżając szerszej publiczności analizę opublikowaną w lipcu przez inżyniera kopskiego Erica Price'a.
- •Kontroler przeliczający trudność share'ów tylko przy nadejściu share'a może utrzymywać nieaktualny, trudniejszy przydział po nagłym spowolnieniu koparki, pozostawiając maszynę liczącą, podczas gdy zaakceptowane share'y stają się rzadkie.
- •Błąd dotyczy trudności share'ów przydzielanej przez pulę, a nie trudności sieci Bitcoina, a dostępne źródła nie zmierzyły, jak często występuje i czy spowodował istotne straty w rzeczywistości.
- •Implementacja referencyjna Stratum V2 unika trwałego zamrożenia dzięki przeliczaniu według timera i obniżaniu trudności podczas niedoboru share'ów, a ckpool wskazano jako wdrożony przykład zależny od share'ów.
- •Operatorzy mogą przetestować swoje kontrolery za pomocą otwartoźródłowego shape-proxy od MARA Foundation, który symuluje pozorne spadki hashrate'u przy użyciu profili step, ramp i stall.

Niektóre kontrolery kopania Bitcoina zarządzające zmienną trudnością mogą nadal przesyłać pracę skalibrowaną do poprzedniej prędkości maszyny, zanim koparka ograniczy swój hashrate. Koparka może dalej liczyć i pobierać energię elektryczną, podczas gdy jej zaakceptowane share'y stają się wyjątkowo rzadkie.
Bitcoin Optech, branżowe źródło do wymiany wiedzy technicznej między firmami z ekosystemu Bitcoina, 18 września zwrócił uwagę na ten tryb awarii, przybliżając szerszej publiczności analizę opublikowaną w lipcu przez inżyniera kopskiego Erica Price'a. Odkrycie dotyczy trudności share'ów przydzielanej przez pulę, a nie trudności sieci Bitcoina, i opisuje testowalną słabość kontrolera, a nie dowód na szeroko zakrojone straty kopaczy.
Jak vardiff się blokuje
Pule kopania przydzielają każdemu połączeniu trudność share'ów łatwiejszą niż trudność bloku Bitcoina; wyższa przydzielona trudność odpowiada trudniejszemu celowi share'ów. Przesyłane share'y pozwalają puli szacować hashrate kopacza i rozliczać wniesioną prac, podczas gdy kontroler zmiennej trudności (vardiff) dostosowuje przydział, aby share'y napływały w użytecznym tempie.
Analiza Price'a opisuje pułapkę, która otwiera się po nagłym spowolnieniu koparki. Jeśli kontroler przelicza trudność tylko wtedy, gdy nadejdzie share, stary, trudniejszy przydział sprawia, że kolejny share jest mniej prawdopodobny. Bez świeżego share'a wyzwalającego aktualizację kontroler może utrzymywać złą trudność, co utrzymuje strumień share'ów w stanie rozrzedzenia.
Dlaczego ograniczenie mocy czyni błąd realistycznym
Nagłe ograniczenie mocy jest realistyczne operacyjnie: farmy kopania dławią maszyny, aby pobierać mniej prądu, zwykle gdy sieć energetyczna jest pod obciążeniem — to dokładnie taki spadek hashrate'u, na który reaguje ten błąd. Podczas zimowej burzy w USA w styczniu 2026 r. CryptoSlate poinformowało o gwałtownym spadku hashrate'u sieci, gdy kopacze ograniczyli zużycie energii, choć to wydarzenie nie zostało powiązane ze stratą związaną z vardiff.
Wysoka trudność share'ów nie usuwa automatycznie oczekiwanego uznania kopacza w dłuższym okresie. Pule mogą nadać rzadkiemu dowodowi o wysokiej trudności większą wagę rozliczeniową, jak wyjaśnia dokumentacja puli Braiins. Pay-per-share płaci stałą stawkę za każdy zaakceptowany share, niezależnie od tego, czy pula znajdzie blok, a proporcjonalny system dzieli każde okno nagrody między share'y przesłane w jego trakcie. Ryzyko pojawia się w zrealizowanym oknie: jeśli nie nadejdzie żaden zaakceptowany share, kopacz w modelu pay-per-share nie otrzymuje zapłaty za ten interwał, a jeśli nadejdzie kilka, pozostają wypłacalne. W systemie proporcjonalnym brakujące share'y mogą zwiększyć udział innych uczestników w oknie nagrody.
Stratum V2 ogranicza problem, wskazano ckpool
Stratum V2 jest następcą oryginalnego protokołu Stratum, którego pule używają do rozdzielania pracy i zbierania share'ów od kopaczy. Obecna implementacja referencyna Stratum V2 unika trwałego zamrożenia dzięki przeliczaniu według timera i obniżaniu trudności podczas niedoboru share'ów, choć analiza wskazuje, że odzyskiwanie może być nadal powolne na długo żyjących kanałach. To działanie timera należy do implementacji referencyjnej, a nie do każdego wdrożenia dozwolonego przez protokół Stratum V2. Analiza i Optech wskazują ckpool jako wdrożony przykład zależny od share'ów. Jak często występuje to zachowanie i czy spowodowało istotne straty w rzeczywistości, nie zostało zmierzone przez dostępne źródła.
Jak operatorzy mogą to przetestować
Operatorzy mogą teraz bezpośrednio przetestować to zachowanie. Otwartoźródłowy shape-proxy od MARA Foundation potwierdza share'y lokalnie, przekazując kontrolowany ich ułamek w górę, a profile step, ramp i stall mogą sprawić, że pula zobaczy pozorny spadek bez zmiany fizycznej wydajności koparki. Spadająca przydzielona trudność pokazuje, że testowany kontroler ma ścieżkę odzyskiwania; cel, który pozostaje zablokowany, jest dowodem powolnego lub brakującego odzyskiwania w tym profilu i oknie obserwacji, choć częstotliwość timera, wiek kanału i losowy napływ share'ów mogą wpływać na wynik. Dopóki nie istnieją szersze pomiary, takie testy prowadzone przez operatorów są główną drogą od analizy do dowodów o rozpowszechnieniu.
Źródło: CryptoNewsNet