Hvordan P2P-protokoller søker å løse Bitcoin Mining Sentralisering

Bitcoin-gruvebassenger er avhengige av sentralisering, men P2Pool og andre protokoller har forsøkt å redusere behovet for tillit til tredjeparter.

I en forrige artikkel, skrev jeg om naturen til desentralisering versus sentralisering i Bitcoin-gruvedrift og hvordan man konseptualiserer det i en for det meste kvalitativ forstand. Artikkelen brøt ned hele gruvestabelen, fra bassengkoordinering helt ned til energiproduksjon for å gi en følelse av forholdet mellom ulike lag i gruvestabelen og potensialet for å maksimere desentraliseringen, noe som gjorde poenget at jo lenger ned i stabelen du gå mot energiproduksjon, jo vanskeligere og mer kapitalkrevende blir det å bringe et meningsfullt nivå av desentralisering til det laget.

I denne artikkelen har jeg til hensikt å gå dypere inn på temaet gruvebassenger og gruvedriftskoordinering for å legge til rette for uavhengig eide gruveoperasjoner som samarbeider i et forsøk på å utvinne blokker som skal legges til blokkjeden.

Opprettelsen av gruvebassenger

Gruvedrift har kommet langt siden dagene da du bare kunne klikke på en knapp og pålitelig mine blokker helt alene på en bærbar CPU. Den gang var det faktisk en amatørhobbyist-innsats som ikke krevde noen reell kapitalinvestering eller ekspertise, men i dag er det et profesjonelt marked på flere milliarder dollar med massive kapitalinvesteringer som kreves i stor skala. Det er et helt annet ballspill.

En av de naturlige konsekvensene av denne endringen i gruveindustriens natur var etableringen av gruvebassenger veldig tidlig. Da gruvedriften faktisk forlot en bærbar datamaskin i hjørnet, var variansen og uforutsigbarheten av når du ville finne en blokk egentlig ikke så stor sak - til slutt ville du det, og strømkostnadene ved å holde en bærbar datamaskin i gang var egentlig ikke økonomisk. betydning.

Når ting skiftet til GPUer og ASICer, var det en materiell investeringskostnad på forhånd og en mye mer betydelig strømkostnad for å holde dem i drift. Den uforutsigbarheten når du ville finne en blokk ble et mye større problem for gruvearbeidere som forsøkte å tjene penger på kapitalinvesteringene sine og drive lønnsomt. Det er her gruvebassenger kommer inn i bildet.

De lar gruvearbeidere samarbeide om å finne en gyldig blokkhode som jobber på samme blokk sammen, og sender myntbasebelønningen til gruvepoolen, som deretter fordeler den proporsjonalt blant alle de deltakende gruvearbeiderne i forhold til hvor mye arbeid de har gjort for å hjelpe til med å finne blokken. Dette er bevist ved å levere "aksjer" til gruvebassenget; blokker som ikke oppfyller nettverksvanskelighetsmålet, men som er høye nok til å bevise at en gruvearbeider ikke lyver og faktisk kjører maskinvare og prøver å finne en gyldig blokk.

Sentralisering av gruvebasseng

Sentraliserte gruvebassenger har store implikasjoner for individuelle gruvearbeidere. De er et sentraliseringspunkt i prosessen med å velge (eller, enda viktigere, ekskludere) transaksjoner for inkludering i en blokk. Dette gir hver gruvebassengoperatør total kontroll over transaksjonene de velger å behandle på blokkjeden, uten mulighet for de faktiske eierne av gruvemaskinvaren til å uttale seg om dette bortsett fra ved å forlate bassenget hvis de er uenige i kriteriene som operatøren velger å stille inn.

De forvarer også individuelle gruvearbeideres bitcoin inntil disse gruvearbeiderne velger å trekke dem fra bassenget, og lar bassengoperatøren fungere som en depotmottaker og sentralt punkt som kan svindle gruvearbeidere som bruker bassenget, eller bli presset av regjeringer til å beslaglegge individuelle gruvearbeiders midler eller bruke KYC krav til dem.

Så, hvilke løsninger finnes for å løse dette problemet?

P2Pool: Det opprinnelige desentraliserte gruvebassenget

P2Basseng er den opprinnelige desentraliserte gruvebassengprotokollen. Det er en peer-to-peer-protokoll der gruvearbeidere koordinerer seg imellom for å dele opp gruvebelønningene mens de jobber sammen for å finne en gyldig blokk som oppfyller vanskelighetsmålet. Denne koordineringen oppnås ved å bruke det protokolldesignet refererer til som en "sharechain".

Gruvearbeidere i P2Pool tar blokker som ikke oppfyller vanskelighetsmålet til nettverket, og miner effektivt sin egen blokkjede som består av alle kopiene av enkeltblokken som bassenget jobber med. Når de møter det mindre vanskelighetsgradsmålet der blokken ville bli omgjort til et basseng for å bevise at de gruver i en sentralisert modell, kringkaster de den blokken til resten av gruvearbeiderne. P2Pools "delingsvanskelighet" var målrettet slik at gruvearbeidere skulle finne en andel omtrent en gang hvert trettiende sekund.

Jeg er sikker på at leserne lurer på hvordan utbetalingen til individuelle gruvearbeidere fungerer. Myntbasetransaksjonen er strukturert slik at det opprettes en utgang for hver enkelt gruvearbeider i P2Pool, og deler opp midler direkte fra myntbasetransaksjonen. Gruvearbeidere i P2Pool verifiserer at alle utbetalingene til seg selv og alle som deltar i poolen er korrekte, og at hver gruvearbeider som har bidratt med en andel til aksjekjeden blir korrekt utbetalt for sitt arbeid i hver nye andel som legges til. Hvis en deltakende gruvearbeider ikke strukturerer utbetalingene til alle i sin siste andel riktig, slutter alle de andre gruvearbeiderne i P2Pool å inkludere dem i sine egne utbetalinger og "kaster ut" den gruvearbeideren fra bassenget for ikke å oppføre seg rettferdig.

Denne utformingen førte til noen skaleringsproblemer, og det er derfor den ikke er i bruk lenger. Etter hvert som deltakelsen i en P2Pool vokser, øker også det samlede vanskelighetsgradsmålet for aksjer i aksjekjeden, som målrettes omtrent en gang hvert trettiende sekund. Dette betyr at for mindre gruvearbeidere blir det vanskeligere å nå sharechain-vanskeligheten i løpet av en trettiandre periode. Dette betyr at for mindre gruvearbeidere øker variansen, eller uforutsigbarheten, i inntekten deres når den samlede hash-raten i en P2Pool øker. Dette fører også til et større antall foreldede blokker ettersom flere gruvearbeidere finner konkurrerende aksjer for aksjekjeden omtrent samtidig som flere gruvearbeidere blir med i P2Pool, noe som fører til "bortkastet arbeid" fra synspunktet til de enkelte gruvearbeiderne som bare får kompensert dersom deres andel er inkludert i aksjekjeden.

Det andre hovedproblemet med skalerbarhet er at utbetalingene går direkte til individuelle gruvearbeidere fra selve coinbase-transaksjonen. Gitt at hver gruvearbeider blir utbetalt i forhold til andelene de har utvunnet som er inkludert i aksjekjeden, krever hver gruvearbeider i P2Pool en ny utgang lagt til i myntbasetransaksjonen.

Dette har to konsekvenser. For det første: Gruvearbeidere får små UTXO-er av lav verdi i hver blokk P2Pool finner, noe som kommer med kostnadene ved å kondensere disse utdataene senere og/eller bære kostnadene for mye større transaksjoner når de går for å bruke myntene sine på grunn av mange individuelle UTXOer de slutter med, i stedet for en enkelt når de trekker seg etter en periode fra en konvensjonell pool. For det andre: Hver ny myntbase-utgang tar opp blokkplass som kan forbrukes av andres transaksjoner og tjener P2Pool mer i gebyrinntekter. Det er et dobbelt tap for gruvearbeidere som deltar i protokollen.

Disse to problemene bidro til at protokollen sakte døde ut og til slutt falt i en tilstand av ubruk. Etter alle indikasjoner fra mitt beste forsøk på å spore opp nøyaktige og nyere statistikker (mange gamle blokkutforskere som sporer gruvebassengandel har stengt ned i løpet av årene), virker det som om den siste blokken som ble utvunnet av P2Pool var på Februar 12, 2019.

P2Pool med betalingskanalutbetalinger

I 2017, en måned etter at SegWit-aktiveringen låste seg, gjorde Chris Belcher en forslag å forbedre skalerbarheten til P2Pool med bruk av enveis betalingskanaler og en gruppe knutepunkter som håndterer utbetalinger til gruvearbeiderne.

Hovedformålet med forslaget er å ta opp spørsmålet om at større myntbasetransaksjoner taper gruvearbeideres penger på to forskjellige måter. På et høyt nivå er ideen rett og slett å betale hele myntbasetransaksjonen ut til et knutepunkt med betalingskanaler åpne for de enkelte gruvearbeiderne, og garantere at muligheten til å kreve midlene fra myntbasetransaksjonen er atomisk knyttet til at gruvearbeiderne blir kompensert for deres andeler over betalingskanalene.

For å oppnå målet om atomitet mellom myntbasetransaksjonen og betalingskanaler for utbetalinger, må myntbasetransaksjonsutdataskriptet tilpasses. I Belchers forslag er det strukturert som et flergrenet manus med tre utgiftsbetingelser:

• En to-av-to multisig. Nøkkel én: navet (Hc). Nøkkel to: gruvearbeider som fant blokken (Mc).
• En enkelt nøkkel og en hashlock. Nøkkel: navet (H). Hashlock: en tilfeldig verdi generert av huben (X).
• En enkelt nøkkel og en tidslås. Nøkkel: gruvearbeideren som fant blokken (M). Timelock: en relativ CSV-tidslås på seks måneder.

En hvilken som helst av disse forbruksbetingelsene kan brukes til å låse opp myntbasetransaksjonsutgangen. La oss nå se på betalingskanalskriptet til gruvearbeiderne slik at vi kan se hvordan de to tingene samhandler:

• En to-av-to multisig. Nøkkel én: navet (Hc1). Nøkkel to: gruvearbeideren (Mc1).
• En to-av-to multisig og en hashlock. Nøkkel én: navet (Hu1). Nøkkel to: gruvearbeideren (Mu1). Hashlock: den tilfeldige verdien generert av huben som brukes i myntbasen (X).

La oss nå gå gjennom hvordan disse to tingene samhandler med hverandre.

Ettersom gruvearbeidere produserer aksjer for å legge til aksjekjeden, overvåker huben fremdriften. For hver andel oppdaterer huben tilstanden til kanalen med gruvearbeidere som leverer inn en andel for å betale dem proporsjonalt med mengden arbeid de gjør. Imidlertid gir de dem bare en signatur for den andre skriptbanen som krever at hashlock-forbildet skal brukes - dette garanterer at de som standard, uten at huben gir dem en signatur for den første banen, kan de ikke kreve disse midlene med mindre huben bruker myntbasen ut av seg selv ved å bruke skriptbanen med hashlock, som krever at de publiserer forhåndsbildet.

Nå vil til slutt en av gruvearbeiderne i P2Pool finne en gyldig blokk og publisere den til nettverket. På dette tidspunktet kan huben oppdatere alle betalingskanalene med gruvearbeiderne og gi signaturen til den første skriptbanen i kanalen, slik at hver gruvearbeider kan lukke kanalen sin og samle belønningene de har tjent når de vil uten å trenge hashlock forhåndsbilde.

På dette tidspunktet signerer gruvearbeideren som fant blokken den første skriptbanen i myntbasen, slik at navet kan kreve midlene fra myntbasen. Denne gruvearbeideren får en liten bonus fra gruvebelønningene for å motivere dem til å signere samarbeid. Men husk: hvis gruvearbeideren nekter å samarbeide, kan huben ganske enkelt bruke hashlock-banen selv og avsløre forhåndsbildet, slik at alle gruvearbeiderne kan samle sin rettmessige del av belønningen.

Dette har bare ulempen ved å tvinge alle kanalene til å stenge på kjeden, og må åpnes igjen for å fortsette gruvedriften. Det siste alternativet finnes i tilfelle knutepunktoperatøren velger å slutte å behandle utbetalinger, eller forsvinner. Etter seks måneder kan gruvearbeideren som fant blokken kreve pengene helt for seg selv hvis huben ikke har svart på samarbeid eller har brukt myntene med hashlock-banen.

Dette etterlater to spesifikke problemer når det gjelder trusselmodellen med Belchers foreslåtte forbedringer. Å bestemme hvilke transaksjoner som skal inkluderes i en blokk gir rom for variasjoner i hvor mye av den totale blokkbelønningen som er basert på hva individuelle gruvearbeidere velger å inkludere i blokkmalene de utvinner.

Når man introduserer betalingskanaler, skaper dette en margin for feil, dvs. at den faktiske belønningen for mined blokker ikke er lik det en gruvehub forplikter seg til i betalingskanalene til gruvearbeidere. I tilfelle de faktiske avgiftsestimatene er mindre enn hva blokkbelønningen var, kan huben ganske enkelt oppdatere betalingskanalene ved å bruke den samarbeidende forbruksbanen med det laveste beløpet, og så lenge de ikke krever myntbase-utgangen med hashlock-banen, gruvearbeiderne har ikke noe annet valg enn å godta den mindre utbetalingen som samsvarer med det gruvebelønningen faktisk var.

I tilfelle gruvebelønningen var litt høyere enn estimatet, er det fortsatt i hubens beste interesse å oppdatere kanalene til gruvearbeiderne for å reflektere dette, ettersom gruvearbeidere som navet behandler uærlig, ganske enkelt kan forlate når som helst. Det eneste fordelaktige tilfellet der det kan være fornuftig for navet å defekte og beholde den ekstra belønningen, ville være hvis noen betalte et unormalt høyt gruvearbeidsgebyr, men bortsett fra den situasjonen, er det i navets og gruvearbeidernes interesse å tilpasse seg eventuelle uoverensstemmelser mellom belønningsestimatet og den faktiske blokkbelønningen.

Det andre problemet er det faktum at huben er et sentralt punkt som kan DDoS'd og tvunget til å forhindre P2Pool fra å fungere. Belchers forslag innebærer å bruke flere hubs, og sende hver myntbasetransaksjon fra forskjellige blokker til forskjellige hubs. Dette krever imidlertid at gruvearbeidere har åpnet kanaler fra alle knutepunktene de bruker, som etter Belchers estimat på et knutepunkt som trenger 50 ganger blokkbelønningen (ca. 650 BTC) for å gi likviditet til gruvearbeiderne, blir utrolig kapitalineffektivt.

Braidpool: Another Iteration

Enter Braidpool (advarsel: lenken er en direkte PDF-nedlasting fra GitHub). Braidpool er et forslag fra Bob McElrath og Kulpreet Singh som bygger på Belchers forslag ved å bruke betalingskanaler. Det er to store endringer introdusert som forbedrer utestående problemer igjen med Belchers forslag.

Den første er en endring i hvordan knutepunktene og gruvearbeiderne kommuniserer med hverandre. De foreslår at gruvearbeidere knytter en Tor v3-adresse til hver av aksjene de sender til bassenget. På denne måten kan huben fungere uten å avsløre noe nettverksendepunkt som er mottakelig for DoS-angrep.

Huboperatøren kan deretter koble seg til gruvearbeidere for å åpne og oppdatere kanaler med dem, noe som reduserer behovet for gruvearbeidere å bruke flere knutepunkter for å unngå et enkelt angrepspunkt. Dette gjør at en Braidpool kan operere med en enkelt hub, noe som gjør hele systemet mer robust og kapitaleffektivt.

Den andre endringen er bruken av en rettet asyklisk graf (DAG) i stedet for en aksjekjede. Problemet med aksjekjeden var at med det trettisekunders andelstidsmålet økte vanskelighetene som kreves for aksjer etter hvert som bassenget vokste i størrelse, noe som gjorde det vanskeligere for mindre gruvearbeidere. Ved å bruke en DAG som Ethereum, hvor det ikke er et nullsumspill av en enkelt aksje som kommer inn i sharechain og andre blir foreldreløse, lar gruvearbeidere dynamisk sette en vanskelighetsgrad for aksjer som kan justeres basert på hash-raten de har og hvordan ofte kan de finne aksjer med den.

DAG-strukturen inkluderer alle som har deltatt i den mellom faktisk funnet Bitcoin-blokker, og fordeler belønningen proporsjonalt mellom alle basert på arbeidet de har gitt til DAG. Dette løser skaleringsproblemet med varians for individuelle gruvearbeidere etter hvert som bassengene vokser seg større.

Bortsett fra disse to endringene, er resten av strukturen akkurat som Belchers forslag, myntbasen og kanalskriptene er de samme.

Final Thoughts

Noen lesere lurer kanskje på hvorfor Betterhash ikke ble berørt i denne artikkelen. Mens desentraliserer utvalget av transaksjoner for inkludering i en blokk, desentraliserer det ikke alle funksjonene til bassenget fullt ut - viktigst av alt, den depotmessige karakteren til bassenger som håndterer midler. Dette etterlater gruvearbeidere åpne for tvang gjennom avslag på å betale ut midler hvis gruvearbeideren velger transaksjoner som bassenget ikke godkjenner. Derfor ville jeg ikke betraktet det som et desentralisert gruvebasseng, selv om det forbedrer situasjonen marginalt i et fiendtlig, men ikke fullt ut motstridende miljø.

Denne artikkelen har vært sentrert rundt P2Pool og foreslått iterasjoner for å forbedre skaleringsbegrensningene. For å ikke skrive en hel bok har jeg ikke berørt andre eksisterende eller potensielle design. Så snart jeg er i stand til å komme til det, planlegger jeg å skrive et oppfølgingsstykke som går inn på andre mekanismer for å desentralisere gruvebassenger.

Dette er et gjesteinnlegg av Shinobi. 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/p2pool-bitcoin-mining-decentralization