Hogyan számítják ki a nehézséget?

A Bitcoin nehézség 1-nél kezdődött (és ennél soha nem mehet alá). Ezután minden megtalált 2016-os blokkhoz összehasonlítjuk a blokkok időbélyegeit, hogy megtudjuk, mennyi idő kellett a 2016-os blokkok megtalálásához, hívjuk T-nek. Azt akarjuk, hogy a 2016-os blokkok 2 hétig tartsanak, tehát ha T eltér, akkor szorozzuk a nehézség (2 hét / T) – így ha a hashrate folytatódik, ahogy volt, akkor most 2 hétre lesz szükség a 2016-os blokkok megtalálásához.

Például, ha csak 10 napig tartott, azt jelenti, hogy a nehézség túl alacsony, ezért 40% -kal megnő.

A nehézség növekedhet vagy csökkenhet attól függően, hogy kevesebb vagy több mint 2 hét kellett-e a 2016-os blokkok megtalálásához. Általában a nehézség a hálózati hasráta csökkenése után csökken.

Ha a korrekciós tényező nagyobb, mint 4 (vagy kevesebb, mint 1/4), akkor 4 vagy 1/4 értéket használunk a változás megakadályozására túl hirtelen.

Van egy hiba a megvalósításban, amely miatt a számítás a 2016-os helyett az utolsó 2015-ös blokkok megtalálásának idején alapul. Ennek kijavításához kemény villára lenne szükség, és így egyelőre elhalasztva.

Körülbelül becsülhető a következő nehézségváltozás, a legutóbbi blokkok megtalálásának ideje alapján. Senki sem tud megbízhatóan előrejelezni a jövőbeli nehézségeket, de bárki szabadon spekulálhat az árfolyam-trendek, Moore törvényei és egyéb hardveres fejlemények alapján.

Megjegyzések

• @StevenRoose: AFAIK ez, de meghagyom azoknak az embereknek a kommentelését, akik jobban foglalkoznak az alapkóddal … Ez egy különálló SE kérdéshez megfelelő.
• Jó válasz, de egy kicsi, de nagybetűs pont elkerülve van: hogyan állapodnak meg a hálózat csomópontjai abban, hogy mi a nehézség?
• @deadalnix: A blokk nehézsége egy determinisztikus számítás az adatok alapján. Minden csomópont egymástól függetlenül ugyanazt a számítást hajtja végre, és ugyanazt az eredményt kapja.
• @deadalnix: Az időbélyeg a blokk része, ami azt jelenti, hogy aki megtalálta a blokkot, eldönti, hogy mit tegyen bele. . Az időbélyeg nem lehet korábbi, mint az elmúlt 11 blokk mediánja. Ha egy csomópont a jövőben 2 óránál hosszabb időbélyeggel rendelkező blokkot kap, akkor újra tedd szét és ne terjessd.
• @tobi: Na jó. A korábbi megjegyzések a hibáról szóltak, és ” hibák ” arra utaltak, hogy ‘ hiba, ezért feltételeztem, hogy ‘ erről beszélünk. Szóval igen. Ha azt feltételezzük, hogy 2140 körül a hashrate * 1B körül lesz, mint most, az ütemterv 96 héttel, vagyis majdnem két évvel előbbre kerül. De van még egy hatás – késés, amelyet az okoz, hogy az elején a nehézség 1 volt, annak ellenére, hogy a hashrat nem volt elég ‘ t megalapozni.

Meni válasza jó. Csak néhány gyakorlati részletmetikát szeretnék adni a nehézségszámításról, ami talán hasznos lehet a jövőben ennek a kérdésnek a nézetei a válasz.

Vessünk egy pillantást Satoshi genezis blokkfejlécére (a kapcsolódó információk része):

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

Mint fent láthatjuk, a genezis blokk “1” nehézséggel és “1d00ffff” bitekkel rendelkezik. A bitcoin bitek a “cél” kivonatértéket jelentik, az új generált blokknak meg kell felelnie egy feltételnek: a blokkfejléc dupla SHA-256 kivonatértékének ennél kisebbnek kell lennie “target” érték.

Az “1d00ffff” bit érték a genezis blokkban a “target” értéket jelenti:

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

Ezután a új blokk kereséséhez meg kell keresnie azt a 32 bit nNonce értéket (és az nTimes és a hashMerkleRoot is), amíg a blokk hash értéke 4 bájt nulla vezet.Egyébként az nNonce a blokkfejléc-szerkezet egyik mezője:

 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 }; 

Mivel az SHA-256 algoritmus (csakúgy, mint bármely kriptográfiailag biztonságos hash algoritmus) olyan kimenetet produkál, amely egységesen véletlenszerű sorrendként jelenik meg , a gyakorlati “próba és hiba” módszer az egyetlen módja annak, hogy új feltételeket találjon a feltételnek. Annak a valószínűsége, hogy egy 4 bájtos nulla vezető hash értékkel rendelkező blokkot talál, 1 / (2 ^ 32), vagyis az átlagos “próba és hiba” szám pontosan 2 ^ 32 (azaz 4G).

Ahhoz, hogy az ember könnyen megérthesse ezt a “cél” kivonatértéket, meghatározzuk a “nehézség” kifejezést, ami az átlagos “próba és hiba” számokat jelenti, hogy megtalálja a “cél” feltételnek megfelelő blokkot. És meghatározzuk a “nehézség” mértékegységét: 1 “nehézség” = 4G hash

Akkor a mai napig a bitcoin blokklánc magassága eléri az 501509-et, vessünk egy pillantást a fejlécére:

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

Az 501509 blokk bitje = 0x18009645, kompakt formátuma 256 bites egész szám, 256 bites formátuma:

[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 

Eddig minden részlet megvan a” nehézség “kiszámításához. Bizonyos esetekben az 1.7T egyszerű formátumot is használjuk. a nehézség megadásához, a fenti példában ：

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

Megjegyzések

• 1d értéke 29 decemberben (nem 26). Az SHS SHA
• köszönöm @BorisIvanov, a hibát SHS kijavították. De A 1d valóban 26 bájt nulla farokot jelent 29 helyett, kérjük, olvassa el a fenti példát.
• ah igen. Jelentőség

Szeretném megadni a 2 cent itt, az aktuális célpont t adott blokk bányászatának valószínűsége és a számításhoz tartozó megfelelő d közötti kapcsolat magyarázatával. a bitcoin magjában.

Tehát a kriptográfiai hash függvényeket a véletlenszerű orákulum absztrakció idealizálja [ https://en.wikipedia.org/wiki/Random_oracle] . Modellezhetjük tehát a PoW-ban használt doubleSHA256 hash függvény kimenetét, mint egységes változót a {0,1}^256 térben, azaz 256 bites tömbökben. . Így annak valószínűsége, hogy egyetlen kivonat h érvényes hash:

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

Másrészt d kiszámítása a következőképpen történik, ahogy a @gary korábban kifejtette, csak tizedessé alakítva:

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

A megvalósítás a [ https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp] , 60. sor, funkció GetDifficulty. Valójában, ha valaki meg tudja magyarázni, hogy a kód pontosan hogyan viszonyul a fenti képlethez, az hasznos lehet. E két képlet ötvözésével kapjuk meg:

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

Ez utóbbi kifejezés elemzésével a nehézség a (amely a legalacsonyabb decimális szám, amelynek bináris reprezentációja 256 bitet használ, 32 nulla bittel kezdődik), és egy érvényes hash megszerzésének valószínűsége az aktuális cél alapján t. Ez közvetlen következménye annak, ha a genezis blokkban meghatározzuk a 1-es nehézséget a hexadecimális célhoz társított 0x1d00ffff , amelyet úgy gondolok, hogy 256 bites számok 32 bites kompakt formájának hívják.

A kedves kérdés, szerintem miért ezt a sajátos kompakt formát választották a cél képviseletére.

Megjegyzések

• Szavazat! A kompakt forma 3 legjelentősebb bájtot biztosít a cél számára, a min nehézségben a 3 legjelentősebb bájt a 00ffff.