Kuinka vaikeus lasketaan?

Bitcoin-vaikeudet alkoivat 1: stä (eivätkä koskaan voi mennä alle sen). Sitten jokaisen löydetyn vuoden 2016 lohkon kohdalla lohkojen aikaleimoja verrataan selvittämään kuinka paljon aikaa kului vuoden 2016 lohkojen löytämiseen, kutsumme sitä nimellä T. Haluamme, että vuoden 2016 lohkot vievät 2 viikkoa, joten jos T on erilainen, kerrotaan vaikeus (2 viikkoa / T) – tällä tavalla, jos hashrate jatkuu ennallaan, vuoden 2016 lohkojen löytäminen vie nyt 2 viikkoa.

Esimerkiksi, jos se kesti vain 10 päivää, se tarkoittaa, että vaikeus on liian pieni ja kasvaa siten 40%.

Vaikeus voi kasvaa tai pienentyä riippuen siitä, kestikö vuoden 2016 lohkojen löytäminen vähemmän tai enemmän kuin 2 viikkoa. Yleensä vaikeus vähenee, kun verkon hasrate laskee.

Jos korjauskerroin on suurempi kuin 4 (tai alle 1/4), sen sijaan käytetään 4 tai 1/4 muutoksen estämiseksi. olla liian äkillinen.

Toteutuksessa on vika, jonka vuoksi laskenta perustuu viimeisten vuoden 2015 lohkojen löytämisajankohtaan eikä vuoteen 2016. Sen korjaaminen vaatii kovaa haarukkaa ja on siten toistaiseksi lykätty.

On mahdollista antaa karkea arvio seuraavasta vaikeusmuutoksesta viimeisten lohkojen löytämisajan perusteella. Kukaan ei voi ennustaa tulevaisuuden vaikeuksia pitkällä aikavälillä luotettavasti, mutta kuka tahansa voi vapaasti spekuloida valuuttakurssitrendien, Mooren lain ja muiden laitteistokehitysten perusteella.

Kommentit

• @StevenRoose: AFAIK se on, mutta jätän sen, että kommentoivat ihmiset, jotka ovat enemmän tekemisissä ydinkoodin kanssa … Tämä riittää erilliseen SE-kysymykseen.
• Hyvä vastaus, mutta vältetään yksi pieni, mutta isoin piste: kuinka verkon solmut sopivat vaikeuksista?
• @deadalnix: Lohkon vaikeus on tietoihin perustuva deterministinen laskelma. Kaikki solmut tekevät itsenäisesti saman laskelman ja saavat saman tuloksen.
• @deadalnix: Aikaleima on osa lohkoa, mikä tarkoittaa, että kuka löysi lohkon, päättää mitä siihen laittaa. Aikaleiman on oltava aikaisintaan 11 edellisen lohkon mediaani. Jos solmu vastaanottaa lohkon, jonka aikaleima on yli 2 tuntia tulevaisuudessa, se heitä se äläkä levitä sitä.
• @tobi: Voi ok. Aiemmat kommentit koskivat virhettä, ja ” -virheet ” vihjasivat, että se ’ virheen, joten oletin, että ’ puhumme siitä. Niin kyllä. Jos oletamme, että noin 2140: n kohdalla hashrate on noin * 1B nykyistä, aikataulu on edessä 96 viikkoa tai melkein kaksi vuotta. Mutta on vielä yksi vaikutus – viive, joka johtuu siitä, että vaikeus oli alussa yksi, vaikka hashrate ei ollut riittävä perustelemaan sitä.

Menin vastaus on hyvä. Haluan vain antaa käytännön yksityiskohtaisen menetelmän vaikeuslaskennasta, ehkä hyödyllinen tulevaisuudessa tämän kysymyksen vastausten näkemykset.

Katsotaanpa Satoshin geneesi-lohkon otsikko (osa aiheeseen liittyvää tietoa):

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

Kuten yllä voimme nähdä, geneesi-lohkolla on ”1” vaikeus ja ”1d00ffff” bittiä. bittibitit tarkoittavat ”kohde” hash-arvoa, uuden generoidun lohkon on täytettävä ehto: lohkon otsikon kaksinkertaisen SHA-256-hash-arvon on oltava pienempi kuin tämä ”kohde” -arvo.

”1d00ffff” -bittien arvo geneesilohkossa tarkoittaa ”kohde” -arvoa:

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

Sitten, löytää uusi lohko, sinun on haettava 32 bittiä nNonce-arvo (ja nTimes ja hashMerkleRoot myös), kunnes lohkon hash-arvolla on 4 tavua nolla johto.Muuten, nNonce on yksi lohkojen otsikkorakenteen kentistä:

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

Koska SHA-256-algoritmi (samoin kuin mikä tahansa kryptografisesti suojattu hash-algoritmi) tuottaa tuloksen, joka näyttää yhtenäisen satunnaisena sekvenssinä , käytännön ”kokeilu ja virhe” -menetelmä on ainoa tapa löytää uusi lohko täyttämään ehto. Todennäköisyys löytää lohko, jossa on 4 tavua nolla johtava hajautusarvo, on 1 / (2 ^ 32), mikä tarkoittaa, että keskimääräiset ”kokeiluvirheen” luvut ovat tarkalleen 2 ^ 32 (ts. 4G).

Jotta ihmisellä olisi helppo ymmärtää tämä ”kohde” -hajautusarvo, määritellään termi ”vaikeus”, mikä tarkoittaa keskimääräisiä ”kokeilu ja virhe” -numeroita lohkon löytämiseksi ”kohde” -olosuhteen täyttämiseksi. Ja määrittelemme ”vaikeus” -yksikön: 1 ”vaikeus” = 4G-hajautus

Sitten tähän päivään asti bitcoin-lohkoketjun korkeus on 501509, katsotaanpa sen otsikko:

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

Lohko 501509 ”bittiä = 0x18009645, se on kompakti 256 bitin kokoinen muoto, sen 256 bitin muoto on:

[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 

Sinulla on toistaiseksi kaikki yksityiskohdat kuinka” vaikeus ”lasketaan. Joissakin tapauksissa käytämme myös yksinkertaista muotoa 1.7T sanomaan vaikeus, yllä olevassa esimerkissä ：

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

Kommentit

• 1d on joulukuussa 29 (ei 26). SHS on SHA
• kiitos @BorisIvanov, kirjoitusvirhe SHS on korjattu. Mutta 1d tarkoittaa todellakin 26 tavua nollapistettä 29 sijasta, lue yllä oleva esimerkkitiedot.
• ah joo. Merkitys

Haluan antaa 2 senttiä tässä selittämällä suhde lohkon louhinnan todennäköisyyden mukaan, kun nykyinen kohde t on annettu, ja vastaavan vaikeuden d laskennan välillä bitcoin-ytimessä.

Joten salauksen hash-toiminnot idealisoidaan satunnaisella oraakkelin abstraktiolla [ https://en.wikipedia.org/wiki/Random_oracle] . Siksi voimme mallintaa PoW: ssä käytetyn doubleSHA256 hash-funktion lähdön yhtenäisenä muuttujana avaruudessa {0,1}^256, eli 256 bitin matriiseissa . Siten todennäköisyys, että yksittäinen hash h on kelvollinen hash, on:

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

Toisaalta d lasketaan seuraavasti, aivan kuten @gary selitti aiemmin muunnettuna desimaaleiksi:

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

Toteutus on [ https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp] , rivi 60, toiminto GetDifficulty. Itse asiassa, jos joku osaa selittää, kuinka koodi täsmää yllä olevaan kaavaan, se olisi hyödyllistä. Yhdistämällä nämä kaksi kaavaa saadaan:

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

Tätä viimeistä lauseketta analysoitaessa vaikeus on (joka on pienin desimaaliluku, jolla on binaarinen esitys käyttäen 256 bittiä alkaen 32 nollabitistä) ja todennäköisyys saada kelvollinen hash nykyisen kohteen perusteella t. Tämä on suora merkitys määritettäessä geneesi-lohkossa vaikeus 1 heksadesimaalikohteeseen 0x1d00ffff , ilmaistuna mielestäni 256-bittisten numeroiden 32-bittisenä pienikokoisena muotona.

A mukava kysymys on mielestäni miksi tämä erityinen kompakti muoto valittiin edustamaan kohdetta.

Kommentit

• Myönnetty! Pienikokoinen muoto tarjoaa kohteelle 3 merkittävintä tavua, pienimmässä vaikeudessa 3 merkittävintä tavua ovat 00ffff.