Hvordan SHA256 og mining beskytter Bitcoin-nettverket

Beregnet lesetid: 14 minutter

Forfatter: Arman The Parman | Utgitt: 24/02/22 | Original: SHA256 and Bitcoin Mining Walkthrough

---

Hvordan mining fungerer er fascinerende. Når jeg forklarer det til folk, elsker jeg å se ansiktet deres i det øyeblikket de blir forvirret. Jeg skal forklare det her, men bare vit, jeg ser for meg alle ansiktene deres mens tankene deres blåser!

Jeg må begynne med hash-funksjoner. Uten hash-funksjoner ville ikke Bitcoin vært mulig. La meg først forklare hva de er, ikke bare slik at du kan høres kul ut på fester, men også fordi det er grunnleggende for å forstå hvordan Bitcoin fungerer, spesielt mining, men også transaksjoner under panseret.

Du trenger ikke å forstå hvordan Bitcoin fungerer for å bruke det, akkurat som hvordan du ikke trenger å forstå hvordan TCP/IP fungerer for å bruke internett. Men fortsett å les, for det er ganske interessant, og jeg skal gjøre det enkelt å forstå, jeg lover.

Hash-funksjoner

La oss starte med et bilde jeg vil forklare nedenfor…

Til venstre er INNDATA, midten er FUNKSJONEN, og til høyre er UTDATA. Inndata kan være en hvilken som helst data, så lenge den er digital. Den kan være av hvilken som helst størrelse, forutsatt at datamaskinen din kan håndtere det. Dataene sendes til SHA256-programmet. Programmet tar dataene og beregner et tall som ser tilfeldig ut, men med spesielle egenskaper (diskutert senere).

Den første SHA (Secure Hash Algorithm) ble opprinnelig utviklet av NSA og det er mange forskjellige versjoner nå (Bitcoin bruker SHA256). Det er et sett med instruksjoner om hvordan du blander sammen dataene på en veldig komplisert, men spesifisert måte. Instruksjonene er ikke en hemmelighet, og det er til og med mulig å gjøre det for hånd, men det er veldig kjedelig.

For SHA256 er utdataen et 256-bits tall (ikke en tilfeldighet).

Et 256-bits tall betyr et binært tall på 256 sifre. Binær betyr at verdien er representert med to symboler, enten 0 eller 1. Binære tall kan konverteres til et hvilket som helst annet format, for eksempel desimaltall, som er det vi er kjent med.

Selv om funksjonen returnerer et binært tall på 256 sifre, uttrykkes verdien vanligvis i heksadesimalt format, 64 sifre.

Heksadesimal betyr at i stedet for 10 mulige symboler som vi er vant til i desimal (0 til 9), har vi 16 symboler (de ti vi er vant til, 0-9, pluss bokstavene a, b, c, d, e, og f; som har verdiene 11 til 15). Som et eksempel, for å representere verdien av tallet 15 i heksadesimal, skriver vi bare «f», og det er den samme verdien. Det er mye informasjon tilgjengelig på nettet med et raskt Google-søk hvis du trenger mer utdypning.

For å demonstrere SHA256, kan jeg ta tallet 1 og kjøre det gjennom en online hash-kalkulator, og vi får da denne utdataen (i heksadesimal):

Inndatavinduet er det over, utdatavinduet er det under.

Merk at alle datamaskiner i verden vil produsere samme utdata, forutsatt at inndataen er den samme og SHA256-funksjonen brukes.

Den heksadesimale utdataen, hvis det konverteres til desimal, er (merk at det kreves flere sifre å skrive):

48635463943209834798109814161294753926839975257569795305637098542720658922315

Og konvertert til binær er det:

11010111000011010110010011100111111111100110100111111001110000110011101011010111000000001001110111111110101101000111111010101110100011110101101101001001110101010100010001011110001110101001001110000000001111001010010110111011011011110000111010110110100101111010111001101011100110101110011010111001101011100110101110011010111001101011100111

Bare ut av interesse, her er den samme verdien i base 64 (jeg skal la deg Google hva base 64 betyr):

1w1k5/5p+cM61wCd/rR+ro9bSdVEXjqTgDylu28OtpY= 

Merk at den minste mulige verdien SHA256 kan returnere er null, men LENGDEN er fortsatt 256 bits. Slik er null representert:

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Og størst mulig verdi er:

1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

I desimal er det:

115 792 089 237 316 195 423 570 985 008 687 907 853 269 984 665 640 564 039 457 584 007 913 129 639 935

I heksadesimal er det:

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Merk at det er nøyaktig 64 F-er.

Null i heksadesimal kan ganske enkelt skrives som én enkelt null, men for hash-utdata er det 64 av dem for å overholde kravet om at utdata skal ha fast størrelse:

0000000000000000000000000000000000000000000000000000000000000000

Her er et sammendrag av noen fakta om hash-funksjonen som er viktig å sette pris på:

• Inndata kan ikke bestemmes fra utdata
• Inndata kan være hvilken som helst lengde
• Utdata har alltid samme lengde
• Utdata vil alltid bli gjengitt identisk hvis du gir samme inndata.
• Enhver endring av inndata, uansett hvor liten, vil føre til en uforutsigbar og helt annerledes utdata
• Utdata er «tilsynelatende» tilfeldig, men er faktisk deterministisk (som betyr at den er beregnet)
• Utdata kan ikke forutsies. Den kan bare beregnes, og dette krever en målbar mengde arbeid fra en datamaskin (og timer med blyant og papir! Ikke gjør det.)

Nå som du forstår det grunnleggende konseptet for hva en hash er, kan du forstå forklaringen på hvordan Bitcoin-mining fungerer.

Men før du går videre, anbefaler jeg at du går til en online hash-kalkulator og leker litt med den og tester selv det jeg har sagt om Hash-funksjoner. Jeg liker denne.

Mining

Jeg vil starte med å demonstrere et consept-of-work, som er der «proof-of-work» i Bitcoin kommer fra.

Gå til den online hash-kalkulatoren og skriv «Jeg lager 50 bitcoins og betaler meg selv dette beløpet.»

Skriv det nøyaktig, skill mellom store og små bokstaver, inkludert punktum. Du bør få denne utdataen:

La oss nå lage en regel som sier at for at denne betalingsmeldingen skal være gyldig, trenger vi at hashen starter med en null. For å gjøre det, må vi endre inndata på en eller annen måte. Men som du har lært, er det ikke forutsigbart hva utdata vil være for en gitt inndata. Hvilken endring kan vi gjøre for å sikre en hash som starter med null?

Vi må legge til data ved å prøve og feile. Men vi ønsker heller ikke å endre betydningen av inndatameldingen. Så la oss lage et felt (en tildelt seksjon) kalt en «nonce» som vil inneholde en tulleverdi.

Ordet «Nonce» er ment å være avledet fra «nummer bare brukt én gang», men jeg ser ikke hvordan det gir mening.

Legg merke til hvordan det å legge til denne ekstra overskriften, «Nonce:», endrer hash-utdata.

Utdata starter fortsatt ikke med en «0», så la oss legge til noe tull (jeg la til en meningsløs «x»):

Den starter fortsatt ikke med en null. Jeg la til noen flere tegn til hashen startet med en null:

Der klarte vi det. Nå, i henhold til de vilkårlige reglene jeg har satt, er teksten i inndatavinduet en gyldig imaginær Bitcoin-blokk med én enkelt transaksjon som betaler meg selv 50 bitcoins.

Merk at Bitcoin-blokker rett og slett er «sider» i en hovedbok. Hver blokk er nummerert og lager nye bitcoins, sammen med transaksjoner mellom brukere. Dette er en logg, og der bitcoins bor.

La oss lage en ny regel. For neste blokk må hashen til forrige blokk inkluderes. Jeg vil legge til litt kompleksitet og legge til noen flere felt for å nærme meg sånn virkelige Bitcoin-blokker ser ut…

Hashen starter med en ‘c’ ikke ‘0’, så jeg må prøve noen verdier i nonce-feltet:

Denne gangen var jeg heldigere og fant en nonce etter bare 6 forskjellige forsøk. Den første blokken vi gikk igjennom fant jeg en etter 19 forsøk – det er noe tilfeldighet her, men generelt er det ikke så vanskelig å finne en gyldig hash hvis alt vi prøver å finne er én null. Det er 16 mulige verdier for det første hash-sifferet, så jeg har en sjanse på 1 til 16 for at enhver endring jeg gjør i inndatafeltet vil resultere i at det første hash-sifferet er «0».

Merk at Bitcoin sine felt ser slike ut, men det er flere detaljer jeg ikke har lagt til, denne delen er bare for å illustrere et poeng, ikke nødvendigvis for å detaljere nøyaktig hvordan en Bitcoin-blokk ser ut.

Jeg vil legge til et tidsfelt i neste blokk da det neste jeg skal forklare er «vanskelighetsjusteringen»:

Ovenfor er blokk nummer 3. Den inkluderer forrige blokk sin hash og nå har jeg også begynt å inkludere tiden. Nonce’n jeg skrev fikk hashen til å starte med en null (jeg fortsatte bare å skrive ‘1’ til hash-målet ble nådd).

Det er nok her til at jeg kan begynne å forklare noen interessante konsepter om Bitcoin-blokkjeden og mining.

Å vinne en blokk

Mining-prosessen er konkurransedyktig. Den som produserer en gyldig blokk først får betale seg selv innenfor den blokken, siden blokken nå er gyldig. En miner som produserer det samme blokknummeret litt senere (han som kommer på andreplass) får ingenting – den blokken blir avvist. Å forklare hvorfor det skjer blir en stor avledning nå, så jeg skal forklare det nederst i artikkelen.

Etter at blokk 3 er funnet og kringkastet til alle (alle Bitcoin-nodene), slutter alle minere å jobbe med blokk 3 og begynner å jobbe med blokk 4. Vinneren publiserer resultatet, og så begynner alle å jobbe med blokk 5 osv.

Med hver blokk opprettes nye bitcoins og utgjør til sammen den totale pengemengden så langt. Hvis det er mange minere, vil statistisk sett blokker bli produsert raskere, og bitcoins vil bli opprettet raskere. Det er et problem, ikke sant?

På jakt etter en begrenset mengde av bitcoins med en forutsigbar utstedelse over tid, tenkte Satoshi Nakamoto på dette problemet og introduserte en negativ tilbakemeldingssløyfe for å holde blokkproduksjonen på 10-minutters intervaller i gjennomsnitt. Hvordan? Se om du kan tenke deg en løsning. Ta en pause og gruble, og se om du kan komme på den samme geniale løsningen, og les videre når du gir opp.

NODER: Jeg nevner «gyldige» blokker. Hva så? Hvem sjekker? Bitcoin-nodene gjør. En Bitcoin-node beholder en kopi av blokkjeden så langt og følger et sett med regler for å sjekke at nye blokker er innenfor reglene, og avviser de som ikke er det. Hvor er reglene? I koden. En datamaskin som laster ned Bitcoin-koden er en node.

Vanskelighetsjustering:

Gjennomsnittlig tid for nye Bitcoin-blokker beregnes av hver node hver 2016-blokk (dette er grunnen til at tidsfeltet er nødvendig). Dette er en del av protokollen og reglene som nodene følger. En formel brukes for å justere antallet nuller som kreves for hver blokkhash

Strengt tatt er det ikke antallet nuller som justeres, men en målverdi hashen må være under, men å tenke på innledende nuller er enklere å forklare.

Hvis blokker produseres for raskt, blir hash-målet justert i henhold til forhåndsdefinerte regler som alle noder følger identisk (det står i koden deres).

For å holde det enkelt for mitt eksempel, la oss si at andre mennesker konkurrerer med meg, blokker opprettes for raskt, og nå trenger den fjerde blokken to nuller i stedet for én, ifølge en oppdiktet beregning.

Det kommer til å ta meg litt lengre tid å få to nuller, men la oss se for oss at det er mange andre som konkurrerer med meg, så den totale tiden det tar for noen å finne en blokk holdes til et mål.

Her er neste blokk:

Legg merke til tiden. Det har gått mer enn 10 minutter siden forrige blokk (jeg fant bare opp tiden for å demonstrere). 10-minutters målet er statistisk, det er aldri kjent nøyaktig når neste blokk vil bli funnet.

Jeg rotet rundt på tastaturet i 1. minutt til to nuller dukket opp. Dette var eksponentielt vanskeligere enn å finne én enkelt null. Sjansen for å finne to 0-er på rad er 1 i 16×16, eller 1 i 256 sjanse.

Hvis flere blir med og konkurrerer om nye bitcoins, vil det til slutt kreves 3 nuller.

Jeg fant nettopp den siste ekte Bitcoin-blokken, som inneholder hashen til forrige blokk. Hashen var:

0000000000000000000171c3948420295584b1da5fb10d8419c7d2b8b5eb1f0b

Det er 19 nuller! Det er en sjanse på 1 i 16¹⁹ for å finne en slik blokk med hvert forsøk. Bitcoin-minere gjør mange mange forsøk per sekund, og samtidig over hele verden.

Antall forsøk per sekund er kjent som «hash rate». Foreløpig er den estimerte hashrate’n i verden i underkant av 200 Tera-hash per sekund (200 billioner per sekund). Med så mange forsøk per sekund, blir en blokk med en hash som starter med 19 nuller funnet rundt hvert 10. minutt.

I fremtiden, ettersom flere minere blir med, vil hash-raten gå opp, blokker vil bli funnet raskere, og Bitcoin sin vanskelighetsgrad vil tilpasse seg til å kreve 20 nuller osv., noe som holder blokkproduksjonen rundt 10 minutter.

The halving:

Da bitcoin først startet, ble det produsert 50 bitcoins med hver blokk. Reglene for Bitcoin-blokkjeden spesifiserer at etter hver 210 000 blokker vil belønningen halveres. Dette øyeblikket er kjent som «the halving», og skjer omtrent hvert fjerde år. The halving, kombinert med vanskelighetsjusteringen for å holde blokker på 10-minutters intervaller, betyr at rundt år 2140 vil blokkbelønningen være 0,00000001 BTC, eller 1 Satoshi, den minste enheten til en bitcoin, og kan ikke halveres lenger. Mining vil ikke stoppe, men «blokkbelønningen» vil være null. Fra dette øyeblikket vil ingen nye bitcoins bli opprettet fremover, og antallet bitcoins er matematisk kalkulerbart og nær nok til 21 millioner mynter. Slik er den totale pengemengden kjent – ​​det er programmatisk innstilt.

Minerne vil imidlertid fortsatt bli belønnet, ikke fra «blokkbelønningen», men fra transaksjonsgebyrer – forklart i neste del.

Hvordan blir blokkbelønningen halvert? Det står i koden som holdes av nodene. De vet at de skal avvise enhver ny blokk etter blokk 210 000 hvor en miner betaler seg selv over 25 bitcoins.

Transaksjonsgebyrer:

Så langt har jeg bare vist imaginære blokker med én enkelt transaksjon, transaksjonen der mineren får utbetalt en belønning. Dette kalles «coinbase-transaksjonen».

Det er ikke oppkalt etter selskapet Conbase, jeg mener Coinbase. Selskapet oppkalte seg etter coinbase-transaksjonen, ikke omvendt, ikke bli forvirret.

I tillegg til coinbase-transaksjonen, er det transaksjoner av folk som betaler hverandre. Her er et eksempel jeg fant opp nå:

Jeg gadd ikke å finne en ekte hash denne gangen (det er faktisk den virkelige hashen rapportert i blokk 200 001). Nonce’n fant jeg bare opp for moro skyld, men legg merke til at en melding kan være innebygd der.

Satoshi inkluderte som kjent ordene «Chancellor on Brink of Second Bailout for Banks» i den første Bitcoin-blokken (The Genesis Block), på grunn av den dagens avisoverskrift.

Poenget her er at det er 132 transaksjoner inkludert (ikke alle er vist). Se på transaksjon #132 – 2,3 bitcoins fra en adresse betaler 2,1 bitcoins til en annen adresse også 0,1 bitcoins til en annen adresse igjen (jeg har brukt prikker for å forkorte lengden på adressen).

Så en kilde på 2,3 bitcoins betaler totalt 2,2 bitcoin (2,2+0,1=2,2). Mangler det 0,1 bitcoin? Nei, forskjellen gis til mineren, som jeg skal forklare.

Mineren har lov til å betale seg selv 25 bitcoins som blokkbelønning (fordi 210 000 blokker har passert så belønningen er halvert fra 50 til 25). Men hvis du ser nøye, er coinbase-transaksjonen 27.33880022. De ekstra 2,33880022 bitcoinene kommer fra de andre 132 transaksjoner i blokken – alle inndataene vil være litt større enn summen av utdataene. Så mineren får opprette disse «forlatte» bitcoinene som betaling til seg selv.

Blokkplass er begrenset. Da Bitcoin var nytt, kunne brukere sende transaksjoner uten en avgift, og minerne ville inkludere transaksjonen i blokken. Men nå er det flere brukere, og siden det er konkurransedyktig å få plass på neste blokk, inkluderer brukere en avgift i transaksjonen for å lokke minerne til å velge transaksjonen deres fremfor andres.

Så når blokkbelønningen går jevnt ned, halveres hvert 4. år og til slutt til null, får minere fortsatt betalt på denne måten.

Noen har antydet at belønningen til minere en dag ikke vil være nok og vil føre til at Bitcoin mislykkes. Denne bekymringen har blitt grundig avkreftet, og jeg vil ikke gjenta den her.

Kan en blokk skrives om?

Dette er ekstremt usannsynlig, og det er verdt å forstå hvorfor. Du vil da sette pris på hvorfor Bitcoin-transaksjoner er uforanderlige.

Jeg forklarte tidligere at hashen til forrige blokk er inkludert i nåværende blokk. Det betyr at enhver redigering av transaksjoner i en gammel blokk endrer hashen til blokken. Men den hashen er registrert i neste blokk, så neste blokk må oppdateres. Men hvis du endrer hashen som er registrert i neste blokk, må den hashen også endres.

Merk at hver gang en hash endres, mister du alle disse nydelige nullene og vil bare sitte igjen med en tilfeldig hash – og må gjøre alt arbeidet på nytt for å få tilbake nullene. Hvis du gjør det for blokken du prøvde å redigere, må du gjøre om arbeidet for neste blokk, og den neste, helt til den siste blokken. Du kan ikke bare stoppe ved den gamle blokken, fordi reglene for Bitcoin er slik at den lengste kjeden av blokker er den ekte Bitcoin-blokkjeden. Hvis du går tilbake og redigerer en blokk for 10 blokker siden, har du ikke lenger den lengste kjeden. Du må legge til 10 blokker til og så litt mer, for mens du lagde de 10 blokkene, ble den ekte kjeden litt lengre. Du må kjøre kappløp for å forbigå den ekte kjeden. Hvis vellykket, blir den nye versjonen den ekte versjonen.

Å gjenta hele verdens kollektive hashing-innsats fra den redigerte blokken til den siste blokken er barrieren for å redigere Bitcoin. Energien ble brukt på å lage disse hashene med alle de usannsynlige nullene, og det energiforbruket må gjentas for å redigere Bitcoin. Dette er grunnen til at energien som brukes til å utvinne Bitcoin ikke er «bortkastet»; den er der for å forsvare Bitcoin fra redigeringer; å gjøre hovedboken uforanderlig uten å måtte stole på en sentral myndighet.

Hva skjer hvis 2 minere finner en blokk samtidig?

Dette skjer faktisk her og der, og det ordner seg alltid som følger:

Hver node vil motta en av de nye nesten samtidige blokkene først og vil akseptere den, og avvise den som kommer senere. Dette resulterer i en splittelse av nettverket, men det er midlertidig.

For å illustrere, la oss kalle en av blokkene blå og den andre rød (de har ingen farge, bare tål meg)

Minerne jobber deretter med neste blokk, men det vil være en splittelse om hvilken blokk de forlenger kjeden fra.

La oss si at den vinnende mineren fant en blokk ved hjelp av den blå kjeden. De vil sende den nye blokken til alle nodene og den lengste kjeden vil være synlig. Nodene som hadde akseptert den røde kjeden, vil da glemme den, og ta i bruk den blå kjeden.

Alle minerne som jobbet med den røde kjeden vil stoppe, og vil nå jobbe med den lengre kjeden som er den blå kjeden. Den røde kjeden døde.

Notater

Hvorfor en andreplass for minere er ugyldig

Anta at blokk 700 000 nettopp ble utvunnet av MINER-A. 30 sekunder senere opprettet MINER-B også en annen versjon av blokk 700 000. Når MINER-B kringkaster dette alternativet, kommer hver node til å avvise det fordi de allerede har sett og akseptert blokken til MINER-A. Dessuten, i løpet av de 30 sekundene, la oss si at MINER-C fant blokk 700 001. Gitt at MINER-B sin konkurrerende blokk nummer 700 000 ikke utvider den nåværende kjeden (som er opp til 700 001), blir den også avvist av den grunn.

Enda mer interessant er at hvis MINER-B hadde jobbet på blokk 700 001 i stedet for å konkurrere på versjon på 700 000, så ville mineren hatt like stor sjanse til å utvinne en gyldig blokk som en ugyldig blokk på 700 000. Så snart en miner ser en ny blokk, bør de sette innsatsen på neste blokk.

Hvis imidlertid MINER-B fant blokk 700 000 1 sekund etter at MINER-A gjorde det, er det mulig at noen noder ser MINER-A sin blokk først, og noen ser MINER-B sin blokk først, avhengig av geografiske steder og internetthastigheter. I så fall er det en midlertidig fork, og noen minere vil jobbe med å utvide den ene versjonen, og noen minere vil jobbe med å utvide den andre. Som forklart tidligere ved å bruke beskrivelsene «blå kjede» og «rød kjede», vil til slutt en av versjonene strekke seg lengre enn den andre og bli den gyldige versjonen.

Dette er et gjesteinnlegg skrevet av Arman The Parman. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis meningene til Bitcoinplassen.