Nyligen uppstod ett litet tjafs mellan Core- och Unlimited-fraktionerna i Bitcoin-gemenskapen, ett tjafs som kanske representerar femtionde gången samma tema diskuterades, men som ändå är intressant på grund av hur det lyfter fram en mycket subtil filosofisk punkt om hur blockkedjor arbete.
ViaBTC, en gruvpool som gynnar Unlimited, Tweeted "hashpower is law", en vanlig diskussionsfråga för Unlimited-sidan, som anser att gruvarbetare har och borde ha en mycket stor roll i styrningen av Bitcoin, det vanliga argumentet för detta är att gruvarbetare är den enda kategorin användare som har ett stort och illikvidt ekonomiskt incitament i Bitcoins framgång. Greg Maxwell (från Core-sidan) svarade att "Bitcoins säkerhet fungerar just för att hashkraft INTE är lag".
Kärnargumentet är att gruvarbetare bara har en begränsad roll i Bitcoin-systemet, för att säkra beställningen av transaktioner, och de bör INTE ha makten att bestämma något annat, inklusive blockstorleksgränser och andra blockvaliditetsregler. Dessa begränsningar upprätthålls av fullständiga noder som drivs av användare – om gruvarbetare börjar producera block enligt en uppsättning regler som skiljer sig från de regler som användarnas noder tillämpar, då kommer användarnas noder helt enkelt att avvisa blocken, oavsett om 10 % eller 60 % eller 99 % av hashkraften ligger bakom dem. På detta svarar Unlimited ofta med något i stil med "om 90 % av hashkraften ligger bakom en ny kedja som ökar blockeringsgränsen, och den gamla kedjan med 10 % hashpower nu är tio gånger långsammare i fem månader tills svårigheten återställs, skulle du verkligen inte uppdatera din klient för att acceptera den nya kedjan?”
Många människor ofta argumenterar mot användningen av offentliga blockkedjor för applikationer som involverar verkliga tillgångar eller något med motpartsrisk. Kritiken är antingen total och säger att det inte är någon mening med att implementera sådana användningsfall på offentliga blockkedjor, eller delvis, säger att även om det kan finnas fördelar med att lagra datum på en offentlig kedja, den företagslogik bör utföras utanför kedjan.
Argumentet som vanligtvis används är att det redan finns förtroendepunkter i sådana applikationer – det finns någon som äger de fysiska tillgångarna som backar upp de tillåtna tillgångarna i kedjan, och att någon alltid kan välja att fly med tillgångarna eller tvingas frysa dem av en regering eller bank, och att hantera de digitala representationerna av dessa tillgångar på en blockchain är som att betala för en förstärkt ståldörr till ens hus när fönstret är öppet. Istället bör sådana system använda privata kedjor, eller till och med traditionella serverbaserade lösningar, kanske lägga till bitar och bitar av kryptografi för att förbättra granskningsbarheten och därmed spara på ineffektiviteten och kostnaderna för att lägga allt på en blockchain.
Argumenten ovan är båda felaktiga i sina rena former, och de är felaktiga på ett liknande sätt. Medan det är teoretiskt möjligt för gruvarbetare att byta 99 % av sin hashpower till en kedja med nya regler (för att göra ett exempel där detta är okontroversiellt dåligt, anta att de ökar blockbelöningen), och till och med spawn-läger den gamla kedjan för att göra den permanent värdelös, och det är också teoretiskt möjligt för en centraliserad förvaltare av en tillgångsstödd valuta att sluta hedra en digital token, skapa en ny digital token med samma saldon som den gamla token utom med ett visst kontos saldo reduceras till noll, och börja hedra den nya token, i praktiken dessa saker är båda ganska svåra att göra.
I det första fallet måste användarna inse att något är fel med den befintliga kedjan, komma överens om att de ska gå till den nya kedjan som gruvarbetarna nu bryter på och ladda ner programvaran som accepterar de nya reglerna. I det andra fallet kommer alla klienter och applikationer som är beroende av den ursprungliga digitala token att gå sönder, användare kommer att behöva uppdatera sina klienter för att byta till den nya digitala token, och smarta kontrakt utan kapacitet att se till omvärlden och se att de behöver uppdatera kommer att gå sönder helt. Mitt i allt detta kan motståndare till bytet skapa en rädsla-osäkerhet-och-tvivel-kampanj för att försöka övertyga folk om att de kanske inte borde uppdatera sina kunder trots allt, eller uppdatera sin klient till några tredje uppsättning regler (t.ex. byte av arbetsbevis), och detta gör implementeringen av bytet ännu svårare.
Därför kan vi säga att i båda fallen, även om det teoretiskt finns centraliserade eller kvasi-centraliserade parter som skulle kunna tvinga fram en övergång från stat A till stat B, där stat B är otillfredsställande för användarna men att föredra framför de centraliserade parterna, kräver detta att göra det bryta igenom ett hårt koordinationsproblem. Samordningsproblem finns överallt i samhället och är ofta en dålig sak – medan det skulle vara bättre för de flesta människor om det engelska språket gjorde sig av med sitt mycket komplexa och oregelbundna stavningssystem och gjorde ett fonetiskt, eller om USA gick över till metriskt, eller om vi kunde omedelbart sänka alla priser och löner med tio procent vid en lågkonjunktur, i praktiken kräver detta att alla är överens om bytet samtidigt, och det är ofta väldigt svårt.
Med blockchain-applikationer gör vi dock något annat: vi använder koordinationsproblem till vår fördel, genom att använda den friktion som samordningsproblem skapar som ett bålverk mot missbruk av centraliserade aktörer. Vi kan bygga system som har egenskapen X, och vi kan garantera att de kommer att bevara egenskapen X i hög grad eftersom att ändra reglerna från X till inte-X skulle kräva att en hel massa människor går med på att uppdatera sin mjukvara samtidigt . Även om det finns en aktör som skulle kunna tvinga fram förändringen skulle det vara svårt att göra det. Det här är den typ av säkerhet som du får från klientsidans validering av blockchain-konsensusregler.
Observera att denna typ av säkerhet är beroende av decentralisering av användare specifikt. Även om det bara finns en gruvarbetare i världen, finns det fortfarande en skillnad mellan en kryptovaluta utvunnen av den gruvarbetaren och ett PayPal-liknande centraliserat system. I det senare fallet kan operatören välja att godtyckligt ändra reglerna, frysa folks pengar, erbjuda dålig service, dra upp sina avgifter eller göra en mängd andra saker, och samordningsproblemen är till operatörens fördel, eftersom sådana system har betydande nätverkseffekter och så många användare måste samtidigt gå med på att byta till ett bättre system. I det förra fallet innebär validering på klientsidan att många försök till ofog som gruvarbetaren kanske vill ägna sig åt avvisas som standard, och koordinationsproblemet fungerar nu till användarnas fördel.
Observera att argumenten ovan INTE, av sig själva, antyder att det är en dålig idé för gruvarbetare att vara huvudaktörerna som koordinerar och bestämmer blockstorleken (eller i Ethereums fall, gasgränsen). Det kan mycket väl vara så att i det specifika fallet med blockstorlek/gasgräns, "styrning av samordnade gruvarbetare med anpassade incitament" är det optimala tillvägagångssättet för att bestämma denna specifika policyparameter, kanske för att risken för att gruvarbetare missbrukar sin makt är lägre än risken att någon specifik vald hård gräns kommer att visa sig helt olämplig för marknadsförhållanden. decennium efter att gränsen satts. Det finns dock inget orimligt med att säga att regering-för-gruvarbetare är det bästa sättet att bestämma en policyparameter, och samtidigt säga att för andra parametrar (t.ex. blockbelöning) vi vill förlita oss på validering på klientsidan för att säkerställa att gruvarbetare är begränsade. Detta är kärnan i att konstruera decentraliserade institutioner: det handlar om att strategiskt använda koordinationsproblem för att säkerställa att systemen fortsätter att uppfylla vissa önskade egenskaper.
Argumenten ovan innebär inte heller att det alltid är optimalt att försöka lägga allt på en blockkedja även för tjänster som är förtroendekrävande. Det finns i allmänhet åtminstone några vinster att göra genom att köra mer affärslogik på en blockchain, men de är ofta mycket mindre än förlusterna för effektivitet eller integritet. Och detta ok; blockkedjan är inte det bästa verktyget för varje uppgift. Vad argumenten ovan do innebär dock är att om du bygger en blockchain-baserad applikation som innehåller många centraliserade komponenter av nödvändighet, så kan du göra betydande ytterligare vinster i förtroendeminimering genom att ge användarna ett sätt att komma åt din applikation genom en vanlig blockchain-klient ( i fallet med Ethereum kan detta vara Mist, Parity, Metamask eller Status), istället för att få dem att använda ett webbgränssnitt som du personligen kontrollerar.
Teoretiskt sett optimeras fördelarna med validering på användarsidan om bokstavligen varje användare kör en oberoende "ideal full nod" - en nod som accepterar alla block som följer protokollreglerna som alla gick med på när de skapade systemet, och avvisar alla block som gör det. inte. I praktiken innebär detta dock att man ber varje användare att bearbeta varje transaktion som drivs av alla i nätverket, vilket är helt klart ohållbart, särskilt med tanke på den snabba tillväxten av smartphoneanvändare i utvecklingsvärlden.
Det finns två vägar ut här. Den första är att vi kan inse det medan det är optimala ur synvinkeln av ovanstående argument att alla kör en full nod är det verkligen inte Obligatorisk. Förmodligen kommer alla större blockchain som körs med full kapacitet redan ha nått den punkt där det inte kommer att vara vettigt för "vanliga människor" att spendera en femtedel av sitt hårddiskutrymme för att köra en full nod, och så de återstående användarna är hobbyister och företag. Så länge det finns ett ganska stort antal av dem, och de kommer från olika bakgrunder, kommer samordningsproblemet att få dessa användare att samarbeta fortfarande vara mycket svårt.
För det andra kan vi lita på stark lätt klientteknologi.
Det finns två nivåer av "lätta klienter" som vanligtvis är möjliga i blockkedjesystem. Den första, svagare, typen av lätta klienter övertygar helt enkelt användaren, med en viss grad av ekonomisk säkerhet, att de finns i kedjan som stöds av majoriteten av nätverket. Detta kan göras mycket billigare än att verifiera hela kedjan, eftersom allt som klienter behöver göra är att i proof of work-scheman verifiera nonces eller i proof-insatsscheman verifiera signerade certifikat som säger "antingen är rothashen för staten vad jag säger det" är, eller så kan du publicera detta certifikat i huvudkedjan för att radera en stor summa av mina pengar”. När light-klienten har verifierat en root-hash kan de använda Merkle-träd för att verifiera vilken specifik data som helst som de kanske vill verifiera.
Titta, det är ett Merkle-träd!
Den andra nivån är en "nästan helt verifierande" ljusklient. Den här typen av klienter försöker inte bara följa den kedja som majoriteten följer; snarare försöker den också följa endast kedjor som följer alla regler. Detta görs genom en kombination av strategier; det enklaste att förklara är att en lätt klient kan arbeta tillsammans med specialiserade noder (kredit till Gavin Wood för att ha kommit på namnet "fiskare") vars syfte är att leta efter block som är ogiltiga och generera "bedrägeribevis", korta meddelanden som i huvudsak säga "Titta! Det här blocket har ett fel här borta!”. Light-klienter kan sedan verifiera den specifika delen av ett block och kontrollera om det faktiskt är ogiltigt.
Om ett block upptäcks vara ogiltigt, kasseras det; om en lätt klient inte hör några bedrägeribevis för ett givet block under några minuter, då antar den att blockeringen förmodligen är legitim. Det finns en lite mer komplexitet med i hanteringen av ärendet där problemet inte är data alltså illa, utan snarare data alltså saknas, men i allmänhet är det möjligt att komma ganska nära att fånga alla möjliga sätt som gruvarbetare eller validerare kan bryta mot reglerna i protokollet.
Observera att för att en lätt klient effektivt ska kunna validera en uppsättning applikationsregler måste dessa regler köras inom konsensus – det vill säga de måste vara antingen en del av protokollet eller en del av en mekanism som körs inuti protokollet ( som ett smart kontrakt). Detta är ett nyckelargument för att använda blockkedjan för både datalagring och exekvering av affärslogik, i motsats till bara datalagring.
Dessa lätta klienttekniker är ofullkomliga, eftersom de förlitar sig på antaganden om nätverksanslutning och antalet andra lätta klienter och fiskare som finns i nätverket. Men det är faktiskt inte avgörande för dem att arbeta 100 % av tiden för 100 % av validerarna. Snarare, allt vi vill är att skapa en situation där varje försök från en fientlig kartell av gruvarbetare/validerare att driva ogiltiga blockeringar utan användarens samtycke kommer att orsaka en stor mängd huvudvärk för många människor och i slutändan kräver att alla uppdaterar sin programvara om de vill fortsätta att synkronisera med den ogiltiga kedjan. Så länge detta är uppfyllt har vi uppnått målet om säkerhet genom samordningsfriktioner.
Källa: https://vitalik.eth.limo/general/2017/05/08/coordination_problems.html
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
- PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
- Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
- PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
- BlockOffsets. Modernisera miljökompensation ägande. Tillgång här.
- Källa: Platon Data Intelligence.
