Jak oblicza się trudność?

Trudność Bitcoin zaczęła się od 1 (i nigdy nie może zejść poniżej tej wartości). Następnie dla każdego znalezionego bloku z 2016 roku porównywane są sygnatury czasowe bloków, aby dowiedzieć się, ile czasu zajęło znalezienie bloków z 2016 roku, nazwijmy to T. Chcemy, aby bloki 2016 zajęły 2 tygodnie, więc jeśli T jest różne, mnożymy trudności o (2 tygodnie / T) – w ten sposób, jeśli hashrate będzie kontynuowane tak, jak było, znalezienie bloków 2016 zajmie teraz 2 tygodnie.

Na przykład, jeśli zajęło to tylko 10 dni, oznacza, że trudność jest zbyt niska i tym samym zwiększy się o 40%.

Trudność może wzrosnąć lub spaść w zależności od tego, czy znalezienie bloków 2016 zajęło mniej, czy więcej niż 2 tygodnie. Ogólnie rzecz biorąc, trudność zmniejszy się po spadku hashratu sieci.

Jeśli współczynnik korekcji jest większy niż 4 (lub mniejszy niż 1/4), zamiast tego stosuje się 4 lub 1/4, aby zapobiec zmianie aby być zbyt gwałtownym.

W implementacji jest błąd, przez który obliczenia są oparte na czasie znalezienia ostatnich bloków z 2015 roku, a nie z 2016 roku. Naprawienie tego wymagałoby hard forka i dlatego jest na razie odroczone.

Można oszacować przybliżoną kolejną zmianę trudności, w oparciu o czas potrzebny na znalezienie ostatnich bloków. Nikt nie jest w stanie wiarygodnie sporządzać długoterminowych prognoz dotyczących przyszłych trudności, ale każdy może swobodnie spekulować na podstawie trendów kursowych, prawa Moorea i innych postępów w dziedzinie sprzętu.

Komentarze

• @StevenRoose: AFAIK, ale zostawię to do komentowania osobom, które są bardziej zaangażowane w podstawowy kod … Jest to wystarczające dla oddzielnego pytania SE.
• Dobra odpowiedź, ale jeden mały, ale ważny punkt jest omijany: w jaki sposób węzły w sieci zgadzają się co do trudności?
• @deadalnix: Trudność bloku jest deterministycznym obliczeniem opartym na danych poprzednich bloków. Wszystkie węzły niezależnie wykonują te same obliczenia i uzyskują ten sam wynik.
• @deadalnix: Znacznik czasu jest częścią bloku, co oznacza, że ktokolwiek znalazł blok, decyduje, co w nim umieścić . Sygnatura czasowa nie może być wcześniejsza niż mediana z ostatnich 11 bloków. Ponadto, jeśli węzeł otrzyma blok z datownikiem dłuższym niż 2 godziny w przyszłości, ponownie ject i nie propaguj.
• @tobi: O ok. Poprzednie komentarze dotyczyły błędu, a ” błędy ” wskazywały, że ' jest błąd, więc założyłem, że ' rozmawiamy o tym. Więc tak. Jeśli założymy, że około 2140 hashrate wyniesie około * 1B, co jest teraz, harmonogram będzie wyprzedzał o 96 tygodni, czyli prawie dwa lata. Ale jest jeszcze jeden efekt – opóźnienie spowodowane faktem, że na początku trudność wynosiła 1, mimo że hashrate nie było ' wystarczające, aby to uzasadnić.

Odpowiedź Meni jest dobra. Chcę tylko podać kilka praktycznych szczegółowych metod obliczania trudności, które mogą być pomocne w przyszłości liczba wyświetleń odpowiedzi na to pytanie.

Spójrzmy na nagłówek bloku Genesis Satoshi (część powiązanych informacji):

$ bitcoin-cli getblockhash 0 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f $ bitcoin-cli getblockheader 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f { ... "height": 0, ... "bits": "1d00ffff", "difficulty": 1, ... } 

Jak widać powyżej, blok Genesis ma poziom trudności „1” i bity „1d00ffff”. Bity bitcoin oznaczają „docelową” wartość skrótu, nowy wygenerowany blok musi spełniać warunek: podwójna wartość skrótu SHA-256 w nagłówku bloku musi być mniejsza niż ta Wartość „target”.

Wartość bitów „1d00ffff” w bloku genesis oznacza wartość „target”:

[0x00000000,0xffff,{0x00..0x00}] {0x00..0x00} at above has 26 bytes 0x00. 

Następnie, aby znaleźć nowy blok, musisz przeszukać 32-bitową wartość nNonce (a także nTimes i hashMerkleRoot także), aż wartość skrótu bloku będzie miała 4 bajty na początku zera.Nawiasem mówiąc, nNonce jest jednym z pól w strukturze nagłówka bloku:

 struct header_structure{ // BYTES NAME uint32_t nVersion; // 4 version uint8_t hashPrevBlock[32]; // 32 previous block header hash uint8_t hashMerkleRoot[32]; // 32 merkle root hash uint32_t nTime; // 4 time uint32_t nBits; // 4 target uint32_t nNonce; // 4 nonce }; 

Ponieważ algorytm SHA-256 (jak również dowolny kryptograficznie bezpieczny algorytm skrótu) generuje wynik, który będzie wyglądał jak jednolicie losowa sekwencja , a praktyczna metoda „prób i błędów” jest jedynym sposobem znalezienia nowego bloku spełniającego warunek. Prawdopodobieństwo znalezienia bloku z 4-bajtową wartością skrótu wiodącą od zera wynosi 1 / (2 ^ 32), co oznacza, że średnia liczba prób i błędów wynosi dokładnie 2 ^ 32 (czyli 4G).

Aby ułatwić ludziom zrozumienie tej „docelowej” wartości skrótu, definiujemy termin „trudność”, który oznacza średnią liczbę prób i błędów potrzebną do znalezienia bloku spełniającego warunek „docelowy”. I definiujemy jednostkę „trudności”: 1 „trudność” = hashe 4G

Następnie, do dziś wysokość łańcucha blokowego bitcoin osiąga 501509, spójrzmy na jego nagłówek:

$ bitcoin-cli getblockheader 0000000000000000006c5532f4fd9ee03e07f94df165c556b89c495e97680147 { ... "height": 501509, ... "bits": "18009645", "difficulty": 1873105475221.611, ... } 

Blok 501509 „s bits = 0x18009645, jest to kompaktowy format 256-bitowej liczby całkowitej, jego 256-bitowy format to:

[0x00000000,0x00000000,0x009645,{0x00..0x00}] {0x00..0x00} at above has 21 bytes 0x00. that is 0x009645 * (256 ^ 21） The genesis block"s target is ( 0x00ffff * 256 ^ 26 ）which is the difficulty unit "1.0". So, the difficulty = (0x00ffff * 256 ^ 26）/ (0x009645 * 256 ^ 21) = 65535/38469 * (256^5) = 1.703579505575918 * 2^40 = 1873105475221.611 

Jak dotąd masz wszystkie szczegóły dotyczące obliczania„ trudności ”. W niektórych przypadkach używamy również prostego formatu 1,7T aby określić poziom trudności, w powyższym przykładzie ：

 (1.703579505575918 * 2^40) = 1.703579505575918T 1T = 2^40 = 1024^4 

Komentarze

• 1d to 29 grudnia (nie 26). SHS to SHA
• dzięki @BorisIvanov, błąd literowy SHS został naprawiony. Ale 1d rzeczywiście oznacza 26 bajtów zerowego ogona zamiast 29, przeczytaj przykładowy szczegół pokazany powyżej.
• a tak. Znaczące

Chciałbym dać moje 2 centów, wyjaśniając związek między prawdopodobieństwem wydobycia bloku przy bieżącym celu t i odpowiadającą mu trudnością d w trakcie obliczania w rdzeniu bitcoin.

Więc kryptograficzne funkcje skrótu są wyidealizowane przez losową abstrakcję Oracle [ https://en.wikipedia.org/wiki/Random_oracle] . Możemy zatem modelować dane wyjściowe funkcji skrótu doubleSHA256 używanej w PoW jako zmienną jednorodną w przestrzeni {0,1}^256, tj. Tablice 256-bitowe . Zatem prawdopodobieństwo, że pojedynczy hash h będzie prawidłowym hashem, wynosi:

p = P(h < t) = t /( 2^{256} - 1 ) 

Z drugiej strony d jest obliczane w następujący sposób, tak jak @gary wyjaśniał wcześniej, tylko przekształcane na ułamki dziesiętne:

d = ( (2^{16} - 1) * 2^{8*26} ) / t = ( (2^{16} -1) * 2^{208} ) / t 

Implementacja jest w [ https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp] , wiersz 60, funkcja GetDifficulty. Właściwie, jeśli ktoś może wyjaśnić, jak dokładnie kod odwzorowuje powyższy wzór, byłoby to pomocne. Łącząc te dwie formuły, otrzymujemy:

d = ( (2^{16} -1) * 2^{208} ) / ( p * (2^{256} - 1) ) ~ 2^{-32} / p 

Analizując to ostatnie wyrażenie, trudność polega na stosunku między prawdopodobieństwem uzyskania skrótu niższego niż 2^{224} (czyli najmniejsza liczba dziesiętna, która ma reprezentację binarną przy użyciu 256 bitów zaczynających się od 32 bitów zerowych) i prawdopodobieństwo uzyskania prawidłowego skrótu na podstawie aktualnego celu t. Jest to bezpośrednia implikacja zdefiniowania w bloku genezy jako trudności 1 tej związanej z celem szesnastkowym 0x1d00ffff , wyrażone w tak zwanej 32-bitowej zwartej formie dla 256-bitowych liczb.

A Myślę, że fajne pytanie brzmi, dlaczego ta konkretna kompaktowa forma została wybrana do reprezentowania celu.

Komentarze

• Za głosem! Forma kompaktowa zapewnia 3 najbardziej znaczące bajty dla celu, na minimalnym poziomie trudności 3 najbardziej znaczące bajty to 00ffff.