Hvordan SHA256 og gruvedrift beskytter Bitcoin-nettverket

Hvordan forsvares Bitcoin av energi? Og hva er en nonce? Disse spørsmålene og flere er besvart innen!

Hvordan gruvedrift fungerer er fascinerende. Når jeg forklarer det til folk, nyter jeg å se ansiktet deres i det øyeblikket de blir forvirret. Jeg skal forklare det her, men bare vit, jeg ser for meg alle ansiktene dine mens tankene dine 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 kult ut på fester, men også fordi det er grunnleggende for å forstå hvordan Bitcoin fungerer – spesielt gruvedrift, men også transaksjoner – under panseret.

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

Hash-funksjoner

La oss starte med et skjema som jeg skal forklare nedenfor...

Til venstre er inngangen, midten er funksjonen, og til høyre er utgangen. Inngangen kan være hvilken som helst data, så lenge den er digital. Det kan være av hvilken som helst størrelse, forutsatt at datamaskinen din kan håndtere det. Dataene sendes til SHA256-funksjonen. Funksjonen tar dataene og beregner et tilfeldig utseende tall, men med spesielle egenskaper (diskutert senere).

Den første Secure Hash Algorithm (SHA) var opprinnelig utviklet av NSA og det er mange forskjellige versjoner nå (Bitcoin bruker SHA256). Det er et sett med instruksjoner for 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 utgangen 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 256-sifret binært tall, uttrykkes verdien vanligvis i heksadesimalt format, 64 sifre.

Heksadesimal betyr at i stedet for 10 mulige symboler som vi er vant til med 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 desimal 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 i aksjon, kan jeg ta tallet 1 og kjøre det gjennom en online hash-kalkulator, og fikk denne utgangen (i heksadesimal):

Den øverste boksen er inngangen, den nederste boksen er den resulterende utgangen.

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

Det heksadesimale antallet utdata, hvis det konverteres til desimal, er (merk at det krever flere sifre for å skrive):

48,635,463,943,209,834,798,109,814,161,294,753,926,839,975,257,569,795,305,637,098,542,720,658,922,315

Og konvertert til binær er det:

11010111000011010110010011100111111111100110100111111001110000110011101011010111000000001001110111111110101101000111111010101110100011110101101101001001110101010100010001011110001110101001001110000000001111001010010110111011011011110000111010110110100101111010111001101011100110101110011010111001101011100110101110011010111001101011100111

Bare av interesse, her er den samme verdien i base 64.

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

Merk at den minste mulige verdien SHA256 kan returnere er null, men LENGDEN er fortsatt 256 biter. 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:

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

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

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

0000000000000000000000000000000000000000000000000000000000000000

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

• Inngangen kan ikke bestemmes fra utgangen
• Inngangen kan være hvilken som helst lengde
• Utgangen har alltid samme lengde
• Utgangen vil alltid bli gjengitt identisk hvis du gir samme input.
• Enhver endring av inngangen, uansett hvor liten, vil føre til en uforutsigbar og helt annerledes utgang
• Utgangen er tilsynelatende tilfeldig, men er faktisk deterministisk (som betyr at den er beregnet og reproduserbar)
• Utgangen kan ikke forutsies. Det 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-gruvedrift fungerer.

Men før du går videre anbefaler jeg deg å gå til en hash-kalkulator på nett og leke deg litt med den og teste selv hva jeg har sagt om hash-funksjoner. Jeg liker denne.

Gruvedrift

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

Gå til hash-kalkulatoren på nettet og skriv "Jeg lager 50 bitcoins og betaler meg selv dette beløpet."

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

La oss nå lage en regel som sier at for at denne betalingsmeldingen skal være gyldig, trenger vi hashen til å starte med en null. For å gjøre det, må vi endre inngangen på en eller annen måte. Men, som du har lært, er det ikke forutsigbart hva utgangen vil være for en gitt inngang. 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 allokert seksjon) kalt en "nonce" som vil inneholde en nonsensverdi.

Ordet "Nonce" er ment å være avledet fra "nummer bare brukt én gang", men jeg ser det ikke.

Legg merke til nedenfor hvordan bare å legge til "Nonce:" som en ekstra feltoverskrift endrer hash-utdata.

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

Det starter fortsatt ikke med en null. Jeg prøvde noen flere tegn til hashen startet med en null:

Der går vi. Nå, i henhold til de vilkårlige reglene jeg satte for denne late-versjonen av Bitcoin, er teksten i inndatavinduet en gyldig blokk med en enkelt transaksjon som betaler meg 50 bitcoin.

Merk at Bitcoin-blokker i hovedsak er sider i en hovedbok. Hver blokk er nummerert og lager nye bitcoin, sammen med en liste over transaksjonene mellom brukere. Denne rekorden er der bitcoin bor.

Nå 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 hva en ekte Bitcoin-blokk har.

Hash-en starter med en "f" ikke "0", så jeg må prøve noen verdier i nonce-feltet:

Denne gangen var jeg heldigere og fant en passende nonce etter bare fire forsøk. Husk at for den første blokken tok det 22 forsøk. Det er noe tilfeldighet her, men generelt er det ikke så vanskelig å finne en gyldig hash hvis alt vi prøver å få er ett 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 Bitcoins felt er slik, men det er flere detaljer som jeg ikke har lagt til. Dette 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 jeg trenger det for å forklare "vanskelighetsjusteringen" neste:

Over er blokk nummer tre. Den inkluderer forrige blokks hash og nå har jeg også begynt å inkludere tiden. Noce jeg fant vellykket fikk hashen til å starte med en null (jeg fortsatte bare å skrive en "1" til hash-målet ble nådd).

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

Å vinne en blokk

Gruveprosessen er konkurransedyktig. Den som produserer en gyldig blokk først, får betale seg selv en fast blokkbelønning. En gruvearbeider som produserer det samme blokknummeret litt senere, får ingenting - den blokken blir avvist. Å forklare hvorfor det vil føre til for mye avledning nå, så jeg skal forklare det i vedlegget.

Etter at blokk tre er funnet og kringkastet til alle (alle Bitcoin-nodene), slutter alle gruvearbeiderne å jobbe med det som ville vært deres versjon av blokk tre. De begynner å bygge på toppen av den vellykkede blokk tre (ved å trekke blokkhashen frem til en ny blokk) og begynner å jobbe med å finne en passende nonce for blokk fire. Vinneren publiserer resultatet og så begynner alle å jobbe med blokk fem osv.

Med hver blokk opprettes nye bitcoin og utgjør til sammen det totale tilbudet så langt. Hvis det er mange gruvearbeidere, bør vi statistisk sett forvente at blokker vil bli produsert raskere, og derfor vil bitcoin bli opprettet raskere. Problem, ikke sant?

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

NODER: Jeg nevner "gyldige" blokker. Hva så? Hvem sjekker? Bitcoin-nodene er. 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 avvise de som ikke er det. Hvor er reglene? I koden. En datamaskin som laster ned Bitcoin-koden er en node.

Vanskelighetsjusteringen

Gjennomsnittlig tid for å lage 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 hver blokkhash må starte med for å være gyldig.

Strengt sett 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, justeres hash-målet i henhold til forhåndsdefinerte regler som alle noder følger identisk (det er i koden deres).

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

Det kommer til å ta meg litt lengre tid å få to nuller, men vi ser 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 tok akkurat tiden opp til å demonstrere). 10-minutters målet er sannsynlighet; det er aldri kjent nøyaktig når neste blokk vil bli funnet.

Jeg rotet rundt på tastaturet i et minutt til to nuller dukket opp. Dette var eksponentielt vanskeligere enn å finne en enkelt null. Sjansen for å finne to nuller på rad er 1 av 16², eller en sjanse på 1 til 256.

Hvis flere mennesker skulle bli med i gruvedriften og konkurransen om nye bitcoin, vil det til slutt kreves tre nuller.

Jeg så nettopp opp den siste ekte Bitcoin-blokken, som inneholder hashen til forrige blokk. Hasjen var:

000000000000000000084d31772619ee08e21b232f755a506bc5d09f3f1a43a1

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

Antall forsøk per sekund er kjent som "hash rate". For øyeblikket er den estimerte verdens hash-raten i underkant av 200 millioner terahashes per sekund (én terahash er en billion hashes). 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 gruvearbeidere slutter seg til, vil hash-raten gå opp, blokker vil bli funnet raskere, og Bitcoins vanskelighetsgrad vil tilpasse seg til å kreve 20 nuller, noe som vil presse blokkproduksjonen tilbake til rundt 10 minutter.

Halveringen

Da Bitcoin først startet, ble det produsert 50 bitcoin med hver blokk. Reglene for Bitcoin blockchain spesifiserer at etter hver 210,000 10 blokker vil belønningen bli halvert. Dette øyeblikket er kjent som "halveringen", og skjer omtrent hvert fjerde år. Halveringen, kombinert med vanskelighetsjusteringen med å holde blokker med 2140-minutters intervaller, betyr at rundt år 0.00000001 vil blokkbelønningen være 1, eller 21 satoshi, den minste enheten til en bitcoin, og kan ikke halveres lenger. Gruvedrift vil ikke stoppe, men blokkbelønningen vil være null. Fra det øyeblikket vil ingen nye bitcoin bli opprettet fremover, og antallet bitcoin er matematisk kalkulerbart og nær nok til XNUMX millioner mynter. Slik er det totale tilbudet kjent - det er programmatisk satt.

Selv med blokkbelønningen på null, vil gruvearbeiderne fortsatt bli incentivert til å fortsette å jobbe for å tjene transaksjonsgebyrer.

Hvordan er blokkbelønningen halvert? Det er i koden som holdes av nodene. De vet å avvise enhver ny blokk etter 210,000 25 hvor en gruvearbeider betaler seg selv over 420,000 bitcoin. Og så å avvise eventuelle blokkeringer etter 12.5 XNUMX hvor en gruvearbeider betaler seg selv over XNUMX bitcoin, og så videre.

transaksjons~~POS=TRUNC

Så langt har jeg bare vist imaginære blokker med en enkelt transaksjon - transaksjonen der gruvearbeideren 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 tenkt eksempel:

Jeg gadd ikke finne en ekte hash denne gangen (det er faktisk den virkelige hasjen som er rapportert i blokk 200,001 XNUMX). Jeg har bare gjort opp for moro skyld, men merk at en melding kan være innebygd der.

Satoshis inkluderte som kjent ordene "Chancellor on Brink of Second Bailout for Banks" i den første Bitcoin-blokken (The Genesis Block), etter dagens avisoverskrift.

Poenget her er at det er 132 transaksjoner inkludert (ikke alle vist). Se på transaksjon #132 – 2.3 bitcoin fra en adresse betaler 2.1 bitcoin til en annen adresse og også til en andre adresse beløpet 0.1 bitcoin (jeg har brukt prikker for å forkorte lengden på adressen).

Så en kilde til 2.3 bitcoin betaler totalt 2.2 bitcoin (2.2 + 0.1 = 2.2). Mangler det 0.1 bitcoin? Nei, forskjellen hevdes av gruvearbeideren, som jeg skal forklare.

Gruvearbeideren har lov til å betale seg selv 25 bitcoin som blokkbelønning (fordi 210,000 50 blokker har passert så belønningen er halvert fra 25 til 27.33880022). Men hvis du ser, er myntbasetransaksjonen 2.33880022. De ekstra 132 bitcoin kommer fra de andre XNUMX transaksjonene i blokken – alle inngangene vil være litt større enn summen av utdataene. Så gruvearbeideren kan kreve denne "forlatte" bitcoinen som betaling til seg selv. Disse anses som transaksjonsgebyrer betalt til gruvearbeideren.

Blokkeplassen er begrenset. Da Bitcoin var ny, kunne brukere sende transaksjoner uten gebyr, og gruvearbeiderne ville inkludere transaksjonen i blokken. Men nå er det flere brukere, og siden det er konkurransedyktig å komme på neste blokk, inkluderer brukere et gebyr i transaksjonen for å lokke gruvearbeideren til å velge transaksjonen sin fremfor andres.

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

Noen har antydet at belønningen til gruvearbeidere 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 (uforanderlige).

Jeg forklarte tidligere at hashen til forrige blokk er inkludert i gjeldende blokk. Det betyr at enhver redigering av transaksjoner i en gammel blokk endrer hashen til den redigerte blokken. Men den hashen blir registrert i neste blokk, så det betyr at den neste blokken også må oppdateres. Men hvis du endrer hashen som er registrert i den neste blokken, må hashen endres, og så videre.

Merk at hver gang en hash endres, mister du alle disse nydelige nullene og vil bare sitte igjen med en tilfeldig utseende hash - og må gjøre alt arbeidet på nytt for å få nullene tilbake. 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 virkelige Bitcoin-rekorden. 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 laget de 10 blokkene, ble nok den virkelige kjeden litt lengre. Du må rase for å forbigå den virkelige kjeden. Hvis vellykket, blir den nye versjonen den virkelige 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, for å gjøre hovedboken uforanderlig uten å måtte stole på en sentral autoritet.

Hva skjer hvis to gruvearbeidere finner en blokk samtidig?

Dette skjer faktisk nå og da, 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 ankommer bare noen øyeblikk 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).

Gruvearbeidere 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 gruvearbeideren 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 slippe den og ta i bruk den blå kjeden.

Alle gruvearbeidere 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 lenken er død.

Vedlegg

Hvorfor en Runner Up Miner's Block er ugyldig

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

Enda mer interessant er det at hvis MINER-B hadde jobbet med blokk 700,001 i stedet for en konkurrerende versjon på 700,000, ville de hatt like stor sjanse til å utvinne en gyldig blokk 700,001 som de ville måtte finne en alternativ blokk 700,000. Så snart en gruvearbeider ser en ny blokk, bør de sette innsatsen på neste blokk.

Hvis imidlertid Miner-B fant blokk 700,000 XNUMX ett sekund etter at MINER-A gjorde det, er det mulig at noen noder ser MINER-A sin blokk først mens andre ser MINER-B sin blokk først, avhengig av geografiske steder og internetthastigheter. I så fall er det en midlertidig gaffel, og noen gruvearbeidere vil jobbe med å utvide den ene versjonen mens andre gruvearbeidere vil jobbe med å forlenge den andre. Som forklart tidligere ved å bruke beskrivelsene "blå kjede" og "rød kjede", vil til slutt en av versjonene strekke seg lenger før den andre og bli den gyldige versjonen enstemmig.

Dette er et gjesteinnlegg av Arman The Parman. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis meningene til BTC Inc Bitcoin Magazine.

• Myntsmart. Europas beste Bitcoin og Crypto Exchange.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. FRI TILGANG.
• CryptoHawk. Altcoin Radar. Gratis prøveperiode.
• Kilde: https://bitcoinmagazine.com/technical/how-mining-protects-the-bitcoin-network