Hvordan P2P-protokoller søger at løse Bitcoin Mining Centralization

Bitcoin-minepuljer er afhængige af centralisering, men P2Pool og andre protokoller har forsøgt at reducere behovet for tillid til tredjeparter.

I en forrige artikel, skrev jeg om karakteren af ​​decentralisering versus centralisering i Bitcoin-minedrift, og hvordan man konceptualiserer det i en overvejende kvalitativ forstand. Artiklen nedbrød hele minestablen, fra poolkoordinering helt ned til energiproduktion for at give en fornemmelse af forholdet mellem forskellige lag af minestablen og potentialet for at maksimere decentraliseringen, hvilket gjorde pointen, at jo længere nede i stakken du gå mod energiproduktion, jo sværere og mere kapitalintensivt bliver det at bringe et meningsfuldt niveau af decentralisering til dette lag.

I denne artikel har jeg til hensigt at gå dybere ind i emnet minepuljer og minearbejderkoordinering for at lette uafhængigt ejede minedrift, der samarbejder i et forsøg på at udvinde blokke, der skal føjes til blockchain.

Oprettelse af minepuljer

Minedrift er kommet langt siden de dage, hvor du blot kunne klikke på en knap og pålideligt mine blokke helt alene på en bærbar CPU. Dengang var det faktisk en amatør-hobbyist-bestræbelse, der ikke krævede nogen reel kapitalinvestering eller ekspertise, men i dag er det et professionelt marked på flere milliarder dollar med massive kapitalinvesteringer, der kræves i stor skala. Det er et helt andet boldspil.

En af de naturlige konsekvenser af dette skift i mineindustriens natur var oprettelsen af ​​minepuljer meget tidligt. Da minedrift reelt efterlod en bærbar computer kørende i hjørnet, var variansen og uforudsigeligheden af, hvornår du ville finde en blok, egentlig ikke så stor en sag - til sidst ville du, og strømomkostningerne ved at holde en bærbar computer kørende var ikke rigtig økonomisk betydning.

Da tingene først skiftede til GPU'er og ASIC'er, var der en materielle investeringsomkostninger på forhånd og en meget større el-omkostning for at holde dem i drift. Den uforudsigelighed i, hvornår du ville finde en blok, blev et meget større problem for minearbejdere, der forsøgte at tjene penge på deres kapitalinvesteringer og drive rentabelt. Det er her minebassiner kommer ind i billedet.

De giver minearbejdere mulighed for at samarbejde om at finde en gyldig blokhoved, der arbejder på den samme blok sammen, og sender møntbasebelønningen til minepuljen, som derefter fordeler den proportionalt mellem alle de deltagende minearbejdere i forhold til, hvor meget arbejde de har gjort for at hjælpe med at finde blokken. Dette bevises ved at indlevere "aktier" til minepuljen; blokke, der ikke opfylder netværkets sværhedsgradsmål, men er høje nok til at bevise, at en minearbejder ikke lyver og faktisk kører hardware og forsøger at finde en gyldig blok.

Centralisering af minepuljen

Centraliserede minepuljer har store konsekvenser for individuelle minearbejdere. De er et centraliseringspunkt i processen med at udvælge (eller, endnu vigtigere, udelukke) transaktioner til inklusion i en blok. Dette giver hver minepuljeoperatør total kontrol over de transaktioner, de vælger at behandle på blockchain, uden mulighed for de faktiske ejere af minedriftshardwaren til at udtale sig om dette, undtagen ved at forlade puljen, hvis de er uenige i de kriterier, som operatøren vælger at indstille.

De opbevarer også individuelle minearbejderes bitcoin, indtil disse minearbejdere vælger at trække dem tilbage fra puljen, hvilket efterlader pooloperatøren, der fungerer som en depot og centralt punkt, der kunne bedrage minearbejdere ved at bruge puljen eller blive presset af regeringer til at beslaglægge individuelle minearbejderes midler eller anvende KYC krav til dem.

Så hvilke løsninger findes der til at løse dette problem?

P2Pool: Den oprindelige decentraliserede minepulje

P2Pool er den originale decentraliserede minepuljeprotokol. Det er en peer-to-peer-protokol, hvor minearbejdere koordinerer indbyrdes for at opdele minedriftens belønninger, mens de arbejder sammen for at finde en gyldig blok, der opfylder vanskelighedsmålet. Denne koordinering udføres ved hjælp af det, som protokoldesignet refererer til som en "sharechain".

Minearbejdere i P2Pool tager blokke, der ikke opfylder vanskelighedsmålet for netværket, og miner effektivt deres egen blockchain sammensat af alle kopierne af den enkelte blok, som puljen arbejder på. Når de møder det mindre sværhedsgradsmål, hvor blokken ville blive forvandlet til en pulje for at bevise, at de miner i en centraliseret model, udsender de den blok til resten af ​​minearbejderne. P2Pools "dele-sværhedsgrad" var rettet mod, at minearbejdere ville finde en andel cirka hver XNUMX. sekund.

Jeg er sikker på, at læsere undrer sig over, hvordan udbetalingen til individuelle minearbejdere fungerer. Møntbase-transaktionen er struktureret således, at der skabes et output for hver enkelt minearbejder i P2Pool, der opdeler midler direkte fra coinbase-transaktionen. Minearbejdere i P2Pool bekræfter, at alle udbetalinger til dem selv og alle, der deltager i puljen, er korrekte, og at hver minearbejder, der har bidraget med en andel til sharechain, bliver korrekt udbetalt for deres arbejde i hver ny tilføjet aktie. Hvis en deltagende minearbejder ikke strukturerer udbetalingerne korrekt til alle i deres seneste andel, så stopper alle de andre minearbejdere i P2Pool med at inkludere dem i deres egne udbetalinger og "smider" den minearbejder ud af puljen for ikke at opføre sig retfærdigt.

Dette design førte til et par skaleringsproblemer, hvorfor det ikke er i brug længere. Efterhånden som deltagelsen i en P2Pool vokser, vokser det samlede sværhedsgradsmål for aktier i aktiekæden, som er målrettet cirka en gang hvert 2. sekund. Dette betyder, at det for mindre minearbejdere bliver sværere at nå sharechain-problemet inden for en hvilken som helst andenogtredive periode. Dette betyder, at for mindre minearbejdere stiger variansen eller uforudsigeligheden i deres indkomst, efterhånden som den samlede hashrate i en P2Pool stiger. Dette fører også til et større antal uaktuelle blokke, da flere minearbejdere finder konkurrerende aktier til aktiekæden på nogenlunde samme tid, som flere minearbejdere tilslutter sig PXNUMXPool, hvilket fører til "spildt arbejde" set fra de enkelte minearbejderes synspunkt, som kun får kompenseres, hvis deres andel indgår i aktiekæden.

Det andet hovedproblem med skalerbarhed er, at udbetalingerne går direkte til individuelle minearbejdere fra selve coinbase-transaktionen. Da hver minearbejder udbetales i forhold til de aktier, de har udvundet, som er inkluderet i aktiekæden, kræver hver minearbejder i P2Pool et nyt output tilføjet i møntbasetransaktionen.

Dette har to konsekvenser. For det første: Minearbejdere får små UTXO'er af lav værdi i hver blok, som P2Pool finder, hvilket kommer med omkostningerne ved at kondensere disse output senere og/eller bære omkostningerne ved meget større transaktioner, når de går for at bruge deres mønter på grund af talrige individuelle UTXO'er, de slutter med, i stedet for en enkelt, når de trækker sig efter en periode fra en konventionel pulje. For det andet: Hver ny møntbase-output optager blokplads, der kunne forbruges af andres transaktioner og tjener P2Pool mere i gebyrindtægter. Det er et dobbelt tab for minearbejdere, der deltager i protokollen.

Disse to problemer bidrog til, at protokollen langsomt døde ud og til sidst faldt i en tilstand af ubrug. Efter alle indikationer fra mit bedste forsøg på at spore nøjagtige og nyere statistikker (mange gamle blokudforskere, der sporer minepuljeandele, er lukket ned i årenes løb), ser det ud til, at den sidste blok udvundet af P2Pool var på Februar 12, 2019.

P2Pool med betalingskanaludbetalinger

I 2017, en måned efter SegWit-aktivering låste sig ind, lavede Chris Belcher en forslag at forbedre skalerbarheden af ​​P2Pool med brug af envejsbetalingskanaler og en gruppe af hubs, der håndterer udbetalinger til minearbejderne.

Hovedformålet med forslaget er at løse problemet med de større møntbasetransaktioner, der taber minearbejderes penge på to forskellige måder. På et højt niveau er tanken ganske enkelt at betale hele møntbasetransaktionen ud til en hub med betalingskanaler åbne for de enkelte minearbejdere og garantere, at muligheden for at kræve midlerne fra møntbasetransaktionen er atommæssigt forbundet med, at minearbejderne bliver kompenseret for. deres andele over betalingskanalerne.

For at nå målet om atomicitet mellem møntbasetransaktionen og betalingskanaler for udbetalinger, skal møntbasetransaktionsoutputscriptet tilpasses. I Belchers forslag er det struktureret som et multi-branch script med tre forbrugsbetingelser:

• En to-af-to multisig. Nøgle et: navet (Hc). Nøgle to: minearbejder, der fandt blokken (Mc).
• En enkelt nøgle og en hashlock. Nøgle: navet (H). Hashlock: en tilfældig værdi genereret af navet (X).
• En enkelt nøgle og en tidslås. Nøgle: minearbejderen, der fandt blokken (M). Timelock: en relativ CSV-tidslås på seks måneder.

Enhver af disse forbrugsbetingelser kan bruges til at låse op for møntbasetransaktionsoutput. Lad os nu se på betalingskanalscriptet til minearbejderne, så vi kan se, hvordan de to ting interagerer:

• En to-af-to multisig. Nøgle et: navet (Hc1). Nøgle to: minearbejderen (Mc1).
• En to-af-to multisig og en hashlock. Nøgle et: navet (Hu1). Nøgle to: minearbejderen (Mu1). Hashlock: den tilfældige værdi, der genereres af den hub, der bruges i møntbasen (X).

Lad os nu gå igennem, hvordan disse to ting interagerer med hinanden.

Da minearbejdere producerer aktier for at tilføje til sharechain, overvåger hub'en fremskridtene. For hver andel opdaterer hub'en kanalens tilstand med minearbejdere, der afleverer en andel for at betale dem proportionalt med den mængde arbejde, de udfører. Men de giver dem kun en signatur for den anden scriptsti, der kræver hashlock-forbilledet at bruge - dette garanterer, at de som standard, uden at hubben giver dem en signatur for den første sti, kan de ikke gøre krav på disse midler, medmindre hubben bruger møntbasen output af sig selv ved hjælp af scriptstien med hashlocket, hvilket kræver, at de udgiver præbilledet.

Nu vil en af ​​minearbejderne i P2Pool til sidst finde en gyldig blok og udgive den til netværket. På dette tidspunkt kan hub'en opdatere alle betalingskanalerne med minearbejderne og give signaturen til den første scriptsti i kanalen, hvilket gør det muligt for hver minearbejder at lukke deres kanal og indsamle de belønninger, de har optjent, når de vil uden at have brug for hashlock forbillede.

På dette tidspunkt underskriver minearbejderen, der fandt blokken, den første scriptsti i møntbasen, hvilket gør det muligt for navet at kræve midlerne fra møntbasen. Denne minearbejder får en lille bonus fra minedriftsbelønningerne for at tilskynde dem til at underskrive i samarbejde. Men husk: Hvis minearbejderen nægter at samarbejde, kan hub'en blot bruge hashlock-stien og afsløre preimaget, så alle minearbejdere kan samle deres rimelige del af belønningen.

Dette har blot ulempen ved at tvinge alle kanalerne til at lukke på kæden, og de skal genåbnes for at fortsætte minedriften. Den sidste mulighed findes i tilfælde af, at hub-operatøren vælger at stoppe med at behandle udbetalinger eller forsvinder. Efter seks måneder kan minearbejderen, der fandt blokken, gøre krav på pengene helt for sig selv, hvis hub'en ikke har reageret på at samarbejde eller har brugt mønterne med hashlock-stien.

Dette efterlader to specifikke problemer med hensyn til trusselsmodellen med Belchers foreslåede forbedringer. Beslutningen om, hvilke transaktioner der skal inkluderes i en blok, giver plads til varians i, hvor meget af den samlede blokbelønning, der er baseret på, hvad individuelle minearbejdere vælger at inkludere i de blokskabeloner, de miner.

Når man introducerer betalingskanaler, skaber dette en fejlmargin, dvs. den faktiske mined block-belønning svarer ikke til, hvad en minehub forpligter sig til i betalingskanalerne til minearbejdere. I tilfælde af, at de faktiske gebyrestimater er mindre end, hvad blokbelønningen var, kan hub'en blot opdatere betalingskanalerne ved hjælp af samarbejdsudgiftsstien med det laveste beløb, og så længe de ikke gør krav på coinbase-outputtet med hashlock-stien, minearbejderne har intet andet valg end at acceptere den mindre udbetaling, der svarer til, hvad minedriftsbelønningen faktisk var.

I tilfælde af, at minedriftsbelønningen var lidt højere end estimatet, er det stadig i hub'ens bedste interesse at opdatere kanalerne til minearbejderne for at afspejle dette, da minearbejdere, som hub'en behandler uærligt, simpelthen kan forlade når som helst. Det eneste randtilfælde, hvor det kunne give mening for navet at defekte og beholde den ekstra belønning, ville være, hvis nogen betalte et unormalt stort minearbejdergebyr, men bortset fra den situation, er det i navets og minearbejdernes interesse at tilpasse sig enhver uoverensstemmelse mellem belønningsestimatet og den faktiske blokbelønning.

Det andet problem er det faktum, at hub'en er et centralt punkt, der kan DDoS'd og tvinges til at forhindre P2Pool i at fungere. Belchers forslag involverer at bruge flere hubs og sende hver møntbasetransaktion fra forskellige blokke til forskellige hubs. Dette kræver dog, at minearbejdere har åbnet kanaler fra alle hubs, de bruger, hvilket efter Belchers estimat af en hub, der har brug for 50 gange blokbelønningen (ca. 650 BTC) for at skaffe likviditet til minearbejdere, bliver utrolig kapitalineffektiv.

Braidpool: Another Iteration

Indtast Braidpool (advarsel: linket er en direkte PDF-download fra GitHub). Braidpool er et forslag fra Bob McElrath og Kulpreet Singh, der bygger på Belchers forslag ved hjælp af betalingskanaler. Der er indført to store ændringer, der forbedrer udestående spørgsmål tilbage med Belchers forslag.

Den første er en ændring i, hvordan hubs og minearbejdere kommunikerer med hinanden. De foreslår, at minearbejdere knytter en Tor v3-adresse til hver af de aktier, de sender til puljen. På denne måde kan hub'en fungere uden at udsætte et netværksendepunkt, der er modtageligt for DoS-angreb.

Hub-operatøren kan derefter oprette forbindelse til minearbejdere for at åbne og opdatere kanaler med dem, hvilket mindsker behovet for, at minearbejdere skal bruge flere hubs for at undgå et enkelt angrebspunkt. Dette gør det muligt for en Braidpool at operere med en enkelt hub, hvilket gør hele systemet mere robust og kapitaleffektivt.

Den anden ændring er brugen af ​​en rettet acyklisk graf (DAG) i stedet for en sharechain. Problemet med aktiekæden var, at med det tredive sekunders deletidsmål, steg sværhedsgraden for aktier, efterhånden som puljen voksede i størrelse, hvilket gjorde det vanskeligere for mindre minearbejdere. Brug af en DAG som Ethereum, hvor det ikke er et nulsumsspil, hvor en enkelt aktie kommer ind i sharechain og andre bliver forældreløse, giver minearbejdere mulighed for dynamisk at indstille en sværhedsgrad for aktier, der kan justeres baseret på den hashrate, de har, og hvordan ofte kan de finde aktier med det.

DAG-strukturen inkluderer alle, der har deltaget i den mellem faktiske fundne Bitcoin-blokke, og fordeler belønningerne proportionalt mellem alle baseret på det arbejde, de har leveret til DAG. Dette løser skaleringsproblemet med varians for individuelle minearbejdere, efterhånden som puljerne vokser sig større.

Bortset fra disse to ændringer, er resten af ​​strukturen ligesom Belchers forslag, møntbasen og kanal-scripts er de samme.

Afsluttende tanker

Nogle læsere undrer sig måske over, hvorfor Betterhash ikke blev berørt i denne artikel. Mens decentraliserer udvælgelsen af ​​transaktioner til inklusion i en blok, decentraliserer det ikke fuldt ud alle funktionerne i puljen - vigtigst af alt, den opbevaringsmæssige karakter af puljer, der håndterer midler. Dette efterlader minearbejdere åbne for tvang gennem afslag på at udbetale midler, hvis minearbejderen vælger transaktioner, som puljen ikke godkender. Derfor vil jeg ikke betragte det som en decentraliseret minepulje, selv om den marginalt forbedrer situationen i et fjendtligt, men ikke helt modstridende miljø.

Denne artikel har været centreret omkring P2Pool og foreslået iterationer for at forbedre dens skaleringsbegrænsninger. Af hensyn til ikke at skrive en hel bog, har jeg ikke berørt andre eksisterende eller potentielle designs. Så snart jeg er i stand til at komme til det, planlægger jeg at skrive et opfølgningsstykke, der går ind på andre mekanismer til at decentralisere minepuljer.

Dette er et gæsteindlæg af Shinobi. Udtalte meninger er helt deres egne og afspejler ikke nødvendigvis dem fra BTC Inc Bitcoin Magazine.

• Coinsmart. Europas bedste Bitcoin og Crypto Exchange.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. FRI ADGANG.
• CryptoHawk. Altcoin radar. Gratis prøveversion.
• Kilde: https://bitcoinmagazine.com/technical/p2pool-bitcoin-mining-decentralization