Notera: Den här sidan är kraftigt föråldrad och underhålls i stort sett inte; på grund av tidigare incidenter av redigeringskrig har den inte varit föremål för någon större granskning.
En Bitcoin-nod kan modifieras så att den kan skalas upp till mycket högre transaktionshastigheter än vad som är fallet i dag, förutsatt att noden körs på avancerade servrar i stället för skrivbordsservrar. Bitcoin utformades för att stödja lättviktsklienter som endast bearbetar små delar av blockkedjan (se förenklad betalningsverifiering nedan för mer information om detta).
Bemärk att den här sidan existerar för att ge beräkningar om skalbarheten hos en Bitcoin full node och transaktioner på blockkedjan utan hänsyn till nätverkssäkerhet och decentralisering. Den är inte avsedd att diskutera skalbarheten hos alternativa protokoll eller försöka sammanfatta filosofiska debatter. Skapa alternativa sidor om du vill göra det.
Note to Readers
När teknikerna hör om hur Bitcoin fungerar stannar de ofta vid ordet ”flooding” och säger ”Oh-my-god! that can’t scale!”. Syftet med den här artikeln är att ta ett extremt exempel, den högsta transaktionshastigheten hos Visa, och visa att bitcoin tekniskt sett skulle kunna nå den typen av hastighet utan någon form av ifrågasättande resonemang, förändringar i kärndesignen eller obefintliga overlays. Som sådant är det bara ett extremt exempel – inte en plan för hur bitcoin kommer att växa för att tillgodose bredare behov (som ett decentraliserat system är det den bitcoinanvändande allmänheten som kommer att bestämma hur bitcoin växer) – det är bara ett argument som visar att bitcoins kärndesign kan skalas upp mycket bättre än vad en intelligent person skulle kunna gissa sig till att börja med.
Dan kritiserar med rätta den analys som presenteras här- och påpekar att drift i denna skala skulle avsevärt minska bitcoins decentraliserade karaktär: Om man måste ha många terabyte diskutrymme för att driva en ”full validering”-nod så kommer färre människor att göra det, och alla som inte gör det måste lita på att de som gör det är ärliga. Dan tycks (enligt hans presentationer) ha gått för långt med det argumentet: han verkar antyda att detta innebär att bitcoins kommer att kontrolleras av den typ av centralbanker som är vanliga i dag. Hans analys misslyckas av två skäl (och det andra beror på att den här sidan är lite missvisande):
För det första, även i den astronomiska skala som presenteras här ligger den erforderliga kapaciteten väl inom räckhåll för (rika) privatpersoner, och skulle säkerligen vara det vid någon framtida tidpunkt när den typen av kapacitet krävdes. Ett system som sätter privatpersoner, eller åtminstone små grupper av privatpersoner, på samma nivå som centralbanker kan knappast kallas centraliserat, även om det skulle vara mindre decentraliserat än den bitcoin vi har idag. Systemet skulle inte heller kunna nå den här typen av skala utan att bitcoinanvändarna gemensamt skulle komma överens om att öka den maximala blockstorleken, så det är inte ett resultat som kan ske utan bitcoinanvändarnas samtycke.
För det andra, och viktigast av allt, handlar den antagna skalning som beskrivs här om att bitcoin ersätter visum. Detta är en dålig jämförelse eftersom bitcoin ensam inte är en perfekt ersättning för visum av skäl som är helt orelaterade till skalning: Bitcoin erbjuder t.ex. inte omedelbara transaktioner, kredit eller olika bedrägeribekämpningsmekanismer (som vissa människor vill ha, även om inte alla vill det). Bitcoin är en mer komplett ersättning för checkar, banköverföringar, postanvisningar, guldmynt, cd-skivor, sparkonton osv. och om det antas i stor utsträckning ersätter det förmodligen användningen av kreditkort som skulle vara bättre betjänade av dessa andra saker om de fungerade bättre på nätet.
Bitcoin-användare bortser ibland från detta faktum för snabbt eftersom folk är för snabba med att kalla det för en brist, men detta är orättvist. Inget system är idealiskt för all användning och Bitcoin har ett bredare spektrum av egenskaper än de flesta monetära instrument. Om Bitcoin-communityt inte är villigt att påpeka att vissa saker skulle göras bättre av andra system så blir det lätt att göra halmgubbsargument: Om vi medger att bitcoin kan användas som golvvax och ökenbeläggning kommer någon alltid att påpeka att det inte är det bästa golvvaxet eller den bästa ökenbeläggningen.
Det är trivialt att bygga betalningshantering och kreditsystem _ovanpå_ bitcoin, både klassiska system (som Visa självt!) och ”decentraliserade” system som Lightning. Dessa system skulle kunna hantera större transaktionsvolymer med lägre kostnader och göra avräkningar ofta till den bitcoin som backar upp dem. Dessa skulle kunna använda andra tekniker med andra kompromisser än bitcoin, men ändå backas upp och denomineras av bitcoin så att de fortfarande åtnjuter dess brist på central kontroll. Vi ser början på detta i dag med tjänster för utbyte av bitcoin och plånböcker som möjliggör omedelbara betalningar mellan medlemmar.
Dessa tjänster skulle dra nytta av den stabila inflationsresistenta bitcoin-valutan, användarna skulle dra nytta av omedelbara transaktioner, krediter och bedrägeribekämpning, och bitcoin som helhet skulle få en förbättrad skalning genom att avlasta transaktionsvolymerna utan att kompromissa med dess decentraliserade natur. I en värld där bitcoin används i stor utsträckning skulle betalningsförmedlingssystemen förmodligen ha lägre priser eftersom de skulle behöva konkurrera med transaktioner med råa bitcoin, men de skulle också ha råd med lägre priser eftersom frekventa bitcoinavräkningar (och nollförtroende- och escrow-transaktioner med bitcoin) skulle minska deras risk. Detta är dubbelt sant eftersom bitcoin kan tänkas skala för att ersätta dem helt och hållet, även om det inte skulle vara den bästa idén på grund av den resulterande minskningen av decentralisering.
Skaleringsmål
VISA hanterar i genomsnitt cirka 2 000 transaktioner per sekund (tps), så kalla det en daglig topphastighet på 4 000 tps. Den har en toppkapacitet på cirka 56 000 transaktioner per sekund, men de använder i själva verket aldrig mer än ungefär en tredjedel av denna kapacitet, inte ens under topphandelsperioder.
PayPal hanterade däremot cirka 10 miljoner transaktioner per dag för i genomsnitt 115 tps i slutet av 2014.
Låt oss ta 4 000 tps som utgångsmål. Om vi vill att Bitcoin ska skalas till alla ekonomiska transaktioner världen över, inklusive kontanter, skulle det naturligtvis vara mycket högre än så, kanske mer i storleksordningen några hundra tusen tps. Och behovet av att kunna motstå DoS-attacker (vilket VISA inte behöver hantera) innebär att vi skulle vilja skala långt bortom de vanliga topphastigheterna. Genom att välja ett mål kan vi ändå göra några grundläggande beräkningar även om det är lite godtyckligt.
I dag är Bitcoin-nätverket begränsat till en uthållig hastighet på 7 tps på grund av att Bitcoin-protokollet begränsar blockstorlekarna till 1 MB.
CPU
Protokollet består av två delar. Noder skickar ”inv”-meddelanden till andra noder för att berätta att de har en ny transaktion. Om den mottagande noden inte har den transaktionen begär den den med ett getdata.
Den stora kostnaden är de krypto- och blockkedjeuppslag som krävs för att verifiera transaktionen. Att verifiera en transaktion innebär en del hashing och en del ECDSA-signaturverifieringar. RIPEMD-160 körs med 106 megabyte/sek (kalla det 100 för enkelhetens skull) och SHA256 är ungefär lika lång. Så hashning av 1 megabyte bör ta cirka 10 millisekunder och hashning av 1 kilobyte skulle ta 0,01 millisekunder – tillräckligt snabbt för att vi ska kunna ignorera det.
Bitcoin kan för närvarande (med ett par enkla optimeringar som är prototyper men inte sammanfogade ännu) utföra cirka 8 000 signaturverifieringar per sekund på en fyrkärnig Intel Core i7-2670QM 2,2Ghz-processor. Det genomsnittliga antalet ingångar per transaktion är cirka 2, så vi måste halvera hastigheten. Detta innebär att 4000 tps är lätt att uppnå CPU-mässigt med en enda ganska vanlig CPU.
Som vi kan se innebär detta att så länge Bitcoin-noder tillåts utnyttja maximalt minst 4 kärnor i de maskiner de körs på, kommer vi inte att få slut på CPU-kapacitet för signaturkontroller såvida Bitcoin inte hanterar 100 gånger så mycket trafik som PayPal. I slutet av 2015 hanterade nätverket 1,5 transaktioner/sekund, så även om vi antar att populariteten ökar enormt kommer vi inte att nå den nivån på länge.
Naturligtvis gör Bitcoin andra saker än signaturkontroll, mest uppenbart hanteringen av databasen. Vi använder LevelDB som gör huvuddelen av det tunga arbetet på en separat tråd och klarar mycket hög läs- och skrivbelastning. Totalt sett domineras Bitcoins CPU-användning av ECDSA.
Nätverk
Låt oss anta en genomsnittlig hastighet på 2000tps, alltså bara VISA. Transaktioner varierar i storlek från cirka 0,2 kilobyte till över 1 kilobyte, men det är i genomsnitt en halv kilobyte idag.
Det innebär att du måste hålla jämna steg med cirka 8 megabit/sekund av transaktionsdata (2000tps * 512 bytes) / 1024 bytes i en kilobyte / 1024 kilobyte i en megabyte = 0,97 megabyte per sekund * 8 = 7,8 megabit/sekund.
Den här typen av bandbredd är redan vanlig för till och med bostadsanslutningar idag, och ligger säkert i den nedre delen av vad colocationleverantörer kan förvänta sig att ge dig.
När blocken löses kommer det nuvarande protokollet att skicka transaktionerna på nytt, även om en kamrat redan har sett dem vid sändningstillfället. Om detta åtgärdas så att blocken bara blir listor över hashes skulle problemet lösas och den bandbredd som behövs för blockutsändning skulle bli försumbar. Så även om denna optimering inte är fullt genomförd idag, tar vi inte hänsyn till blocköverföringsbandbredden här.
Lagring
Vid mycket höga transaktionshastigheter kan varje block vara över en halv gigabyte stort.
Det är inte nödvändigt för de flesta fullt validerande noder att lagra hela kedjan. I Satoshis dokument beskriver han ”pruning”, ett sätt att radera onödiga uppgifter om transaktioner som är fullt genomförda. Detta minskar den mängd data som behövs för en fullt validerande nod till att endast vara lika stor som den aktuella storleken på den oförbrukade utgången, plus en del ytterligare data som behövs för att hantera re-orgs. Från och med oktober 2012 (block 203258) har det skett 7 979 231 transaktioner, men storleken på den oförbrukade utdatamängden är mindre än 100 MB, vilket är tillräckligt litet för att lätt rymmas i RAM-minnet även för ganska gamla datorer.
Endast ett litet antal arkivnoder behöver lagra hela kedjan som går tillbaka till det ursprungliga blocket. Dessa noder kan användas för att starta upp nya helt validerande noder från grunden, men är annars onödiga.
Den primära begränsande faktorn för Bitcoins prestanda är disksökningar när den oförbrukade transaktionsutmatningsuppsättningen slutar att rymmas i minnet. När hårddiskar fasas ut till förmån för SSD-diskar är det fullt möjligt att tillgången till UTXO-uppsättningen aldrig blir en allvarlig flaskhals.
Optimeringar
Beskrivningen ovan gäller den nuvarande programvaran med endast mindre optimeringar förutsatt (av den typ som kan och har kunnat göras av en man på några veckor).
Det finns dock potential för ännu större optimeringar i framtiden, till priset av viss ytterligare komplexitet.
CPU
Algoritmer finns för att påskynda batchverifiering över elliptiska kurvsignaturer. Det är möjligt att kontrollera deras signaturer samtidigt för en 2x snabbare hastighet. Detta är en något mer komplex implementering.
Simplifierad betalningsverifiering
Det är möjligt att bygga en Bitcoin-implementering som inte verifierar allt, utan i stället förlitar sig på att antingen ansluta till en betrodd nod, eller sätter sin tilltro till hög svårighetsgrad som en ställföreträdare för bevis på giltighet. bitcoinj är en implementering av detta läge.
I SPV-läget (Simplified Payment Verification), som är uppkallat efter det avsnitt i Satoshis papper som beskriver det, ansluter klienterna till en godtycklig fullständig nod och laddar ner endast blockhuvudena. De verifierar att kedjehuvudena ansluter till varandra på rätt sätt och att svårighetsgraden är tillräckligt hög. De begär sedan transaktioner som matchar vissa mönster från den avlägsna noden (dvs. betalningar till dina adresser), som tillhandahåller kopior av dessa transaktioner tillsammans med en Merkle-gren som kopplar dem till det block där de dök upp. Detta utnyttjar Merkle-trädstrukturen för att möjliggöra bevis på inkludering utan att behöva hela blockets innehåll.
Som en ytterligare optimering kan blockrubriker som ligger tillräckligt djupt begravda slängas efter en tid (t.ex. behöver man egentligen bara lagra så lågt som 2016 års rubriker).
Den svårighetsgrad som krävs för att få förtroende för att den fjärrstyrda noden inte matar dig med påhittade transaktioner beror på din hotmodell. Om du ansluter till en nod som är känd för att vara tillförlitlig spelar svårigheten ingen roll. Om du vill välja en slumpmässig nod bör kostnaden för en angripare att bryta en blocksekvens som innehåller en falsk transaktion vara högre än det värde som kan erhållas genom att lura dig. Genom att ändra hur djupt nedgrävt blocket måste vara kan man jämföra bekräftelsetiden med kostnaden för en attack.
Program som implementerar detta tillvägagångssätt kan ha en fast lagrings-/nätverksöverkostnad i nollfallet utan användning, och en resursanvändning som är proportionell mot mottagna/skickade transaktioner.
Se även: Thin Client Security.
Relaterat arbete
Det finns några förslag för att optimera Bitcoins skalbarhet. Vissa av dessa kräver en alt-chain/hard fork.
- Ultimate blockchain compression – idén om att blockkedjan kan komprimeras för att uppnå ”trust-free lite nodes”
- The Finite Blockchain paper som beskriver att blockkedjan delas upp i tre datastrukturer, var och en bättre lämpad för sitt ändamål. De tre datastrukturerna är en ändlig blockkedja (behåll N block i det förflutna), ett ”kontoträd” som behåller kontosaldot för varje adress med ett saldo som inte är noll, och en ”beviskedja” som är en (ständigt växande) bantad version av blockkedjan.
- Lightning Network, ett alternativt protokoll för transaktionsavräkning där noder upprättar mikrobetalningskanaler mellan varandra och avräknar på blockkedjan då och då. Vanliga användare interagerar främst eller enbart med betalkanaler och använder blockkedjan endast för stora överföringar och kallförvaring.
