Hur P2P-protokoll försöker lösa Bitcoin Mining Centralization

Bitcoin gruvpooler är beroende av centralisering, men P2Pool och andra protokoll har försökt minska behovet av förtroende för tredje part.

I en tidigare artikel, skrev jag om karaktären av decentralisering kontra centralisering i Bitcoin-gruvdrift och hur man konceptualiserar det i en mestadels kvalitativ mening. Artikeln bröt ner hela gruvstacken, från poolkoordination hela vägen ner till energiproduktion för att ge en känsla av förhållandet mellan olika lager i gruvstacken och potentialen att maximera decentraliseringen, vilket gjorde poängen att ju längre ner i stacken du gå mot energiproduktion, desto svårare och mer kapitalintensivt blir det att få en meningsfull nivå av decentralisering till det lagret.

I den här artikeln tänker jag gå djupare in på ämnet gruvpooler och samordning av gruvarbetare för att underlätta oberoende ägda gruvdrifter som samarbetar i ett försök att bryta block som ska läggas till blockkedjan.

Skapandet av gruvpooler

Gruvdrift har kommit långt sedan de dagar då du helt enkelt kunde klicka på en knapp och på ett tillförlitligt sätt bryta block helt själv på en bärbar CPU. Då var det i själva verket en amatörhobbysträvan som inte krävde några riktiga kapitalinvesteringar eller expertis, men nuförtiden är det en professionell marknad med flera miljarder dollar med massiva kapitalinvesteringar som krävs i stor skala. Det är ett helt annat bollspel.

En av de naturliga konsekvenserna av denna förändring i gruvindustrins natur var skapandet av gruvpooler mycket tidigt. När gruvdrift faktiskt lämnade en bärbar dator igång i hörnet, var variationen och oförutsägbarheten när du skulle hitta ett block inte riktigt så stor sak - till slut skulle du göra det och energikostnaden för att hålla en bärbar dator igång var inte riktigt ekonomisk. betydelse.

När saker och ting väl gick över till GPU:er och ASIC:er, fanns det en materialinvesteringskostnad i förväg och en mycket mer betydande elkostnad för att hålla dem i drift. Den oförutsägbarheten när du skulle hitta ett block blev en mycket större fråga för gruvarbetare som försökte få avkastning på sina kapitalinvesteringar och driva lönsamhet. Det är här gruvpooler kommer in i bilden.

De tillåter gruvarbetare att samarbeta för att hitta ett giltigt blockhuvud som arbetar på samma block tillsammans, och skickar myntbasbelöningen till gruvpoolen, som sedan fördelar den proportionellt mellan alla deltagande gruvarbetare i förhållande till hur mycket arbete de har gjort för att hjälpa till att hitta kvarteret. Detta bevisas genom att lämna in "andelar" till gruvpoolen; block som inte uppfyller nätverkets svårighetsmål men är tillräckligt höga för att bevisa att en gruvarbetare inte ljuger och faktiskt kör hårdvara och försöker hitta ett giltigt block.

Centralisering av gruvpoolen

Centraliserade gruvpooler har stora konsekvenser för enskilda gruvarbetare. De är en centraliseringspunkt i processen att välja (eller, ännu viktigare, utesluta) transaktioner för inkludering i ett block. Detta ger varje gruvpoolsoperatör total kontroll över de transaktioner som de väljer att bearbeta i blockkedjan, utan möjlighet för de faktiska ägarna av gruvhårdvaran att utöva något att säga till om utom genom att lämna poolen om de inte håller med om kriterierna som operatören väljer att ställa in.

De förvarar också enskilda gruvarbetares bitcoin tills dessa gruvarbetare väljer att ta ut dem från poolen, vilket lämnar pooloperatören att agera som förvaringsinstitut och central punkt som kan lura gruvarbetare som använder poolen, eller pressas av regeringar att lägga beslag på enskilda gruvarbetares medel eller tillämpa KYC krav på dem.

Så, vilka lösningar finns för att lösa detta problem?

P2Pool: Den ursprungliga decentraliserade gruvpoolen

P2Pool är det ursprungliga decentraliserade gruvpoolsprotokollet. Det är ett peer-to-peer-protokoll där gruvarbetare samordnar sinsemellan för att dela upp gruvbelöningarna när de arbetar tillsammans för att hitta ett giltigt block som uppfyller svårighetsmålet. Denna samordning åstadkoms med hjälp av vad protokolldesignen refererar till som en "sharechain".

Gruvarbetare i P2Pool tar block som inte uppfyller svårighetsmålet för nätverket och bryter effektivt sin egen blockkedja som består av alla kopior av det enda blocket som poolen arbetar med. När de möter det mindre svårighetsmålet där blocket skulle förvandlas till en pool för att bevisa att de bryter i en centraliserad modell, sänder de det blocket till resten av gruvarbetarna. P2Pools "andelssvårighet" var inriktad på att gruvarbetare skulle hitta en andel ungefär en gång var trettionde sekund.

Jag är säker på att läsare undrar hur utbetalningen till enskilda gruvarbetare fungerar. Myntbastransaktionen är strukturerad så att en utdata skapas för varje enskild gruvarbetare i P2Pool, som delar upp medel direkt från myntbastransaktionen. Gruvarbetare i P2Pool verifierar att alla utbetalningar till sig själva och alla som deltar i poolen är korrekta, och att varje gruvarbetare som har bidragit med en andel till aktiekedjan får korrekt utbetalning för sitt arbete i varje ny aktie som läggs till. Om någon deltagande gruvarbetare inte strukturerar utbetalningarna korrekt till alla i sin senaste andel, slutar alla andra gruvarbetare i P2Pool att inkludera dem i sina egna utbetalningar och "avhyser" den gruvarbetaren från poolen för att han inte uppträdde rättvist.

Denna design ledde till några skalningsproblem varför den inte används längre. I takt med att deltagandet i en P2Pool ökar, ökar också det sammanlagda svårighetsmålet för aktier i aktiekedjan, som riktar in sig på ungefär en gång var trettionde sekund. Detta innebär att det för mindre gruvarbetare blir svårare att nå sharechain-svårigheten inom en trettioanvänd period. Detta innebär att för mindre gruvarbetare ökar variansen, eller oförutsägbarheten, i deras inkomst när den sammanlagda hashhastigheten i en P2Pool ökar. Detta leder också till ett större antal inaktuella block eftersom fler gruvarbetare hittar konkurrerande aktier för aktiekedjan ungefär samtidigt som fler gruvarbetare ansluter sig till P2Pool, vilket leder till "bortkastat arbete" från de enskilda gruvarbetarnas synvinkel som bara får kompenseras om deras andel ingår i aktiekedjan.

Det andra huvudproblemet med skalbarhet är att utbetalningarna går direkt till enskilda gruvarbetare från själva myntbastransaktionen. Med tanke på att varje gruvarbetare betalas ut i proportion till de aktier de har brutit som ingår i aktiekedjan, kräver varje gruvarbetare i P2Pool en ny utdata som läggs till i myntbastransaktionen.

Detta har två konsekvenser. För det första: Gruvarbetare får små UTXO:er av lågt värde i varje block som P2Pool hittar, vilket kommer med kostnaden för att kondensera dessa utdata senare och/eller bära kostnaden för mycket större transaktioner när de går för att spendera sina mynt på grund av många individuella UTXO de slutar med, istället för en enda när de drar sig efter en period från en konventionell pool. För det andra: Varje ny myntbasutdata tar upp blockutrymme som kan konsumeras av andra människors transaktioner och tjänar P2Pool mer i avgiftsintäkter. Det är en dubbel förlust för gruvarbetare som deltar i protokollet.

Dessa två frågor bidrog till att protokollet långsamt dog ut och så småningom hamnade i ett tillstånd av obruk. Enligt alla indikationer från min bästa ansträngning att spåra korrekt och färsk statistik (många gamla blockutforskare som spårar gruvpoolandelar har stängts av under åren), verkar det som om det sista blocket som P2Pool bröt var på Februari 12, 2019.

P2Pool med betalningskanalutbetalningar

2017, en månad efter att SegWit-aktiveringen låste sig, gjorde Chris Belcher en förslag att förbättra skalbarheten för P2Pool med användning av enkelriktade betalningskanaler och en grupp hubbar som hanterar utbetalningar till gruvarbetarna.

Huvudsyftet med förslaget är att ta itu med frågan om att större myntbastransaktioner förlorar gruvarbetares pengar på två olika sätt. På en hög nivå är tanken helt enkelt att betala ut hela myntbastransaktionen till ett nav med betalningskanaler öppna för de enskilda gruvarbetarna, och garantera att möjligheten att kräva pengarna från myntbastransaktionen är atomiskt kopplad till att gruvarbetarna kompenseras för sina andelar över betalningskanalerna.

För att uppnå målet om atomicitet mellan myntbastransaktionen och betalningskanaler för utbetalningar måste myntbastransaktionsutmatningsskriptet anpassas. I Belchers förslag är det strukturerat som ett manus med flera grenar med tre utgiftsvillkor:

• En två-av-två multisig. Nyckel ett: navet (Hc). Nyckel två: gruvarbetare som hittade blocket (Mc).
• En enkel nyckel och ett hashlock. Nyckel: navet (H). Hashlock: ett slumpmässigt värde som genereras av navet (X).
• En enkel nyckel och ett tidslås. Nyckel: gruvarbetaren som hittade blocket (M). Timelock: ett CSV-relativt tidslås på sex månader.

Vilket som helst av dessa utgiftsvillkor kan användas för att låsa upp myntbastransaktionsutdata. Låt oss nu titta på betalningskanalskriptet till gruvarbetarna så att vi kan se hur de två sakerna interagerar:

• En två-av-två multisig. Nyckel ett: navet (Hc1). Nyckel två: gruvarbetaren (Mc1).
• En två-av-två multisig och ett hashlock. Nyckel ett: navet (Hu1). Nyckel två: gruvarbetaren (Mu1). Hashlock: det slumpmässiga värdet som genereras av navet som används i myntbasen (X).

Låt oss nu gå igenom hur dessa två saker interagerar med varandra.

Eftersom gruvarbetare producerar aktier för att lägga till aktiekedjan, övervakar navet framstegen. För varje aktie uppdaterar hubben kanalens tillstånd med gruvarbetare som lämnar in en andel för att betala dem proportionellt mot mängden arbete de gör. Men de ger dem bara en signatur för den andra skriptsökvägen som kräver att hashlock-förbilden ska spenderas - detta garanterar att de som standard, utan att navet ger dem en signatur för den första sökvägen, inte kan göra anspråk på dessa pengar om inte navet spenderar myntbasen utdata själv med hjälp av skriptsökvägen med hashlocket, vilket kräver att de publicerar förbilden.

Nu kommer så småningom en av gruvarbetarna i P2Pool att hitta ett giltigt block och publicera det till nätverket. Vid denna tidpunkt kan navet uppdatera alla betalningskanaler med gruvarbetarna och ge signaturen till den första skriptsökvägen i kanalen, vilket gör att varje gruvarbetare kan stänga sin kanal och samla in belöningarna de har tjänat när de vill utan att behöva hashlocket förbild.

Vid denna tidpunkt undertecknar gruvarbetaren som hittade blocket den första skriptvägen i myntbasen, vilket tillåter navet att göra anspråk på pengarna från myntbasen. Den gruvarbetaren får en liten bonus från gruvbelöningarna för att uppmuntra dem att skriva på i samarbete. Men kom ihåg: om gruvarbetaren vägrar att samarbeta, kan navet helt enkelt spendera själv genom att använda hashlock-banan och avslöja förbilden, vilket gör att alla gruvarbetare kan samla sin beskärda del av belöningen.

Detta har bara baksidan av att tvinga alla kanaler att stänga på kedjan, måste öppnas igen för att fortsätta bryta. Det sista alternativet finns om navoperatören väljer att sluta behandla utbetalningar, eller försvinner. Efter sex månader kan gruvarbetaren som hittade blocket göra anspråk på pengarna helt för sig själva om navet inte har svarat för att samarbeta eller har spenderat mynten med hashlock-banan.

Detta lämnar två specifika frågor i termer av hotmodell med Belchers föreslagna förbättringar. Att bestämma vilka transaktioner som ska inkluderas i ett block lämnar utrymme för varians i hur mycket av den totala blockbelöningen som baseras på vad enskilda gruvarbetare väljer att inkludera i de blockmallar som de bryter.

När man introducerar betalningskanaler skapar detta en marginal för fel, dvs. den faktiska belöningen för minerade block är inte lika med vad en gruvnav förbinder sig till i betalningskanalerna till gruvarbetare. I fallet att de faktiska avgiftsuppskattningarna är mindre än vad blockbelöningen var, kan navet helt enkelt uppdatera betalningskanalerna med hjälp av den kooperativa utgiftsvägen med det lägsta beloppet, och så länge de inte gör anspråk på myntbasutdata med hashlock-vägen, gruvarbetarna har inget annat val än att acceptera den lägre utbetalningen som matchar vad gruvbelöningen faktiskt var.

I fallet att gruvbelöningen var något högre än uppskattningen är det fortfarande i hubbens bästa intresse att uppdatera kanalerna till gruvarbetarna för att återspegla detta, eftersom gruvarbetare som navet behandlar oärligt helt enkelt kan lämna när som helst. Det enda kantfallet där det kan vara vettigt för navet att defekta och behålla den extra belöningen skulle vara om någon betalade en onormalt hög gruvarbetaravgift, men bortsett från den situationen ligger det i navets och gruvarbetarnas intresse att anpassa sig till eventuella skillnader mellan belöningsuppskattningen och den faktiska blockbelöningen.

Den andra frågan är det faktum att navet är en central punkt som kan DDoS'd och tvingas förhindra att P2Pool fungerar. Belchers förslag innebär att man använder flera hubbar och skickar varje myntbastransaktion från olika block till olika hubbar. Detta kräver dock att gruvarbetare har kanaler öppna från alla hubbar de använder, vilket, enligt Belchers uppskattning av ett nav som behöver 50 gånger blockbelöningen (cirka 650 BTC) för att tillhandahålla likviditet till gruvarbetare, blir otroligt kapitalineffektivt.

Braidpool: Another Iteration

ange Braidpool (varning: länken är en direkt nedladdning av PDF från GitHub). Braidpool är ett förslag från Bob McElrath och Kulpreet Singh som bygger på Belchers förslag med hjälp av betalningskanaler. Det har införts två stora förändringar som förbättrar utestående frågor kvar med Belchers förslag.

Den första är en förändring i hur nav och gruvarbetare kommunicerar med varandra. De föreslår att gruvarbetare ska bifoga en Tor v3-adress till var och en av de aktier de sänder till poolen. På så sätt kan hubben fungera utan att exponera någon nätverksändpunkt som är känslig för DoS-attacker.

Navoperatören kan sedan ansluta till gruvarbetare för att öppna och uppdatera kanaler med dem, vilket minskar behovet för gruvarbetare att använda flera hubbar för att undvika en enda attack. Detta gör att en Braidpool kan arbeta med ett enda nav, vilket gör hela systemet mer robust och kapitaleffektivt.

Den andra förändringen är användningen av en riktad acyklisk graf (DAG) istället för en aktiekedja. Problemet med aktiekedjan var att med det trettio sekunders andelstidsmålet ökade svårigheten som krävdes för aktier när poolen växte i storlek, vilket gjorde det svårare för mindre gruvarbetare. Att använda en DAG som Ethereum, där det inte är ett nollsummespel av en enskild aktie som kommer in i aktiekedjan och andra som blir föräldralösa, tillåter gruvarbetare att dynamiskt ställa in en svårighetsgrad för aktier som kan justeras baserat på hashhastigheten de har och hur ofta kan de hitta aktier med den.

DAG-strukturen inkluderar alla som har deltagit i den mellan faktiska hittade Bitcoin-block, och fördelar belöningarna proportionellt mellan alla baserat på det arbete som de har tillhandahållit DAG. Detta löser skalningsproblemet med varians för enskilda gruvarbetare när poolerna växer sig större.

Bortsett från dessa två förändringar, är resten av strukturen precis som Belchers förslag, myntbasen och kanalskripten är desamma.

Avslutande tankar

Vissa läsare kanske undrar varför Betterhash inte berördes i den här artikeln. Samtidigt som urvalet av transaktioner för inkludering i ett block decentraliseras, decentraliseras inte alla funktionerna i poolen helt – viktigast av allt, förvaringskaraktären hos pooler som hanterar medel. Detta lämnar gruvarbetare öppna för tvång genom vägran att betala ut pengar om gruvarbetaren väljer transaktioner som poolen inte godkänner. Därför skulle jag inte betrakta det som en decentraliserad gruvpool, även om den marginellt förbättrar situationen i en fientlig men inte helt kontradiktorisk miljö.

Den här artikeln har varit centrerad kring P2Pool och föreslagit iterationer för att förbättra dess skalningsbegränsningar. För att inte skriva en hel bok har jag inte berört andra befintliga eller potentiella mönster. Så snart jag kan komma till det, planerar jag att skriva en uppföljning som går in på andra mekanismer för att decentralisera gruvpooler.

Detta är ett gästinlägg av Shinobi. Åsikter som uttrycks är helt deras egna och återspeglar inte nödvändigtvis BTC Incs eller Bitcoin Magazine.

• Myntsmart. Europas bästa bitcoin- och kryptobörs.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. FRI TILLGÅNG.
• CryptoHawk. Altcoin radar. Gratis provperiod.
• Källa: https://bitcoinmagazine.com/technical/p2pool-bitcoin-mining-decentralization