Note: Denne side er alvorligt forældet og stort set uvedligeholdt; på grund af tidligere hændelser med redigeringskrig har den ikke været genstand for meget peer review.
En Bitcoin fuld node kunne modificeres til at skalere til meget højere transaktionshastigheder end dem, der ses i dag, forudsat at den pågældende node kører på en high end servere i stedet for et skrivebord. Bitcoin blev designet til at understøtte letvægts klienter, der kun behandler små dele af blok kæden (se forenklet betaling verifikation nedenfor for flere detaljer om dette).
Bemærk venligst, at denne side eksisterer for at give beregninger om skalerbarhed af en Bitcoin fuld knude og transaktioner på blok kæden uden hensyn til netværkssikkerhed og decentralisering. Det er ikke hensigten at diskutere skalerbarheden af alternative protokoller eller forsøge at opsummere filosofiske debatter. Opret alternative sider, hvis du ønsker at gøre det.
Note to Readers
Når techies hører om, hvordan Bitcoin fungerer, stopper de ofte ved ordet “flooding” og siger “Oh-my-god! that can’t scale!”. Formålet med denne artikel er at tage et ekstremt eksempel, den maksimale transaktionshastighed af Visa, og vise, at Bitcoin teknisk set kunne nå den slags sats uden nogen form for tvivlsom argumentation, ændringer i kernen design, eller ikke-eksisterende overlays. Som sådan er det blot et ekstremt eksempel- ikke en plan for, hvordan Bitcoin vil vokse for at imødekomme bredere behov (som et decentraliseret system er det bitcoin bruger offentligheden, der vil beslutte, hvordan Bitcoin vokser) – det er bare et argument, der viser, at Bitcoin kerne design kan skalere meget bedre end en intelligent person kunne gætte på første.
Dan kritiserer med rette den analyse, der præsenteres her- påpeger, at operere på denne skala ville betydeligt reducere den decentrale karakter af Bitcoin: Hvis du skal have mange terabytes af diskplads til at køre en “fuld validering” node så færre mennesker vil gøre det, og alle, der ikke gør det vil have til at stole på dem, der gør at være ærlig. Dan synes (ud fra sine slides) at være gået for vidt med dette argument: han synes at antyde, at dette betyder, at bitcoins vil blive kontrolleret af den slags centralbanker, som er almindelige i dag. Hans analyse fejler af to grunde (og den anden er skyld i, at denne side er lidt misvisende):
Først, selv på den astronomiske skala, der præsenteres her, ligger den nødvendige kapacitet godt inden for (velhavende) privatpersoners rækkevidde, og det ville den helt sikkert også være på et fremtidigt tidspunkt, hvor den slags kapacitet var påkrævet. Et system, der sætter privatpersoner, eller i det mindste små grupper af privatpersoner, på lige fod med centralbanker, kan næppe kaldes et centraliseret system, selvom det ville være mindre decentraliseret end den bitcoin vi har i dag. Systemet kunne heller ikke komme til denne form for skala uden bitcoin-brugere, der kollektivt bliver enige om at øge den maksimale blokstørrelse, så det er ikke et resultat, der kan ske uden bitcoin-brugernes samtykke.
For det andet, og vigtigst af alt, handler den formodede skalering, der er beskrevet her, om, at Bitcoin erstatter visa. Dette er en dårlig sammenligning, fordi Bitcoin alene ikke er en perfekt erstatning for visa af grunde helt uden forbindelse med skalering: Bitcoin tilbyder ikke øjeblikkelige transaktioner, kredit eller forskellige mekanismer til bekæmpelse af svig (som nogle mennesker ønsker, selv om ikke alle ønsker det), for eksempel. Bitcoin er en mere komplet erstatning for checks, bankoverførsler, postanvisninger, guldmønter, cd’er, opsparingskonti osv. og hvis det bliver bredt vedtaget, erstatter det sandsynligvis de anvendelser af kreditkort, som ville være bedre tjent med disse andre ting, hvis de fungerede bedre online.
Bitcoin-brugere gloser nogle gange for hurtigt over dette faktum, fordi folk er for hurtige til at kalde det en fejl, men det er uretfærdigt. Intet system er ideelt for al brug, og Bitcoin har et bredere spektrum af kvaliteter end de fleste monetære instrumenter. Hvis Bitcoin samfund er ikke villig til at påpege nogle ting ville bedre blive gjort af andre systemer, så bliver det nemt at gøre stråmandsargumenter: Hvis vi indrømmer, at Bitcoin kunne bruges som et gulv voks og ørken topping, nogen vil altid påpege, at det ikke er den bedste gulv voks eller bedste ørken topping.
Det er trivielt at bygge betalingsbehandling og kredit systemer _på toppen_ af Bitcoin, både klassiske dem (som Visa selv!) såvel som “decentraliserede” dem som Lightning. Disse systemer kunne håndtere større transaktionsmængder med lavere omkostninger, og afregne ofte til den bitcoin, der bakker dem op. Disse kunne bruge andre teknikker med andre kompromiser end bitcoin, men stadig være bakket op og denomineret af bitcoin så stadig nyde sin mangel på central kontrol. Vi ser begyndelsen af dette i dag med Bitcoin udveksling og tegnebog tjenester tillader øjeblikkelige betalinger mellem medlemmer.
Disse tjenester ville få fordel af den stabile inflation resistente Bitcoin valuta, brugere ville få fordelene ved øjeblikkelige transaktioner, kredit, og anti-bedrageri, Bitcoin generelt ville nyde forbedret skalering fra offloaded transaktionsvolumen uden at kompromittere sin decentrale natur. I en verden, hvor bitcoin var meget udbredt betalingsbehandlingssystemer ville sandsynligvis have lavere priser, fordi de ville være nødt til at konkurrere med rå-bitcoin transaktioner, de kunne også være råd lavere pris, fordi hyppige bitcoin afregning (og nul tillid bitcoin escrow transaktioner) ville reducere deres risiko. Dette er dobbelt sandt, fordi Bitcoin kunne tænkes at skalere til at erstatte dem helt, selv om det ikke ville være den bedste idé på grund af den resulterende reduktion i decentralisering.
Skalering mål
VISA håndterer i gennemsnit omkring 2,000 transaktioner per sekund (tps), så kald det en daglig peak rate på 4,000 tps. Den har en spidskapacitet på ca. 56 000 transaktioner pr. sekund, men de bruger faktisk aldrig mere end ca. en tredjedel af dette, selv i spidsbelastede shoppingperioder.
PayPal håndterede derimod omkring 10 millioner transaktioner om dagen for et gennemsnit på 115 tps i slutningen af 2014.
Lad os tage 4.000 tps som startmål. Det er klart, hvis vi ønsker Bitcoin til at skalere til alle økonomiske transaktioner på verdensplan, herunder kontanter, ville det være meget højere end det, måske mere i omegnen af et par hundrede tusinde tps. Og behovet for at kunne modstå DoS-angreb (som VISA ikke har at gøre med) indebærer, at vi ville ønske at skalere langt ud over de standard peak rates. Alligevel, vælge et mål lad os gøre nogle grundlæggende beregninger, selv om det er lidt arbitrært.
I dag er Bitcoin-netværket begrænset til en vedvarende hastighed på 7 tps på grund af Bitcoin-protokollen, der begrænser blokstørrelser til 1 MB.
CPU
Protokollen har to dele. Noder sender “inv”-meddelelser til andre noder, der fortæller dem, at de har en ny transaktion. Hvis den modtagende knude ikke har denne transaktion, anmoder den om den med en getdata.
Den store omkostning er de krypto- og block chain-opslag, der er involveret i at verificere transaktionen. Verificering af en transaktion betyder nogle hashing- og nogle ECDSA-signaturverificeringer. RIPEMD-160 kører med 106 megabyte/sek (kald det 100 for enkelhedens skyld), og SHA256 er omtrent det samme. Så hashing 1 megabyte skulle tage omkring 10 millisekunder og hashing 1 kilobyte ville tage 0,01 millisekunder – hurtigt nok til, at vi kan ignorere det.
Bitcoin er i øjeblikket i stand til (med et par enkle optimeringer, der er prototyper, men ikke fusioneret endnu) at udføre omkring 8000 signaturverificeringer pr. sekund på en quad core Intel Core i7-2670QM 2,2Ghz-processor med fire kerner. Det gennemsnitlige antal input pr. transaktion er ca. 2, så vi skal halvere hastigheden. Det betyder, at 4000 tps er let opnåeligt CPU-mæssigt med en enkelt temmelig mainstream CPU.
Som vi kan se, betyder dette, så længe Bitcoin noder får lov til at max ud mindst 4 kerner af de maskiner, de kører på, vil vi ikke løbe tør for CPU-kapacitet til signaturkontrol, medmindre Bitcoin håndterer 100 gange så meget trafik som PayPal. I slutningen af 2015 håndterer netværket 1,5 transaktioner/sekund, så selv hvis vi antager en enorm vækst i popularitet, vil vi ikke nå dette niveau i lang tid.
Naturligvis gør Bitcoin andre ting end signaturkontrol, mest indlysende er at administrere databasen. Vi bruger LevelDB, som gør hovedparten af de tunge løft på en separat tråd, og er i stand til meget høje læse / skrive belastninger. Samlet set er Bitcoin’s CPU-forbrug domineret af ECDSA.
Netværk
Lad os antage en gennemsnitlig hastighed på 2000tps, så bare VISA. Transaktioner varierer i størrelse fra omkring 0,2 kilobyte til over 1 kilobyte, men det er i gennemsnit en halv kilobyte i dag.
Det betyder, at du skal holde trit med omkring 8 megabit/sekund af transaktionsdata (2000tps * 512 bytes) / 1024 bytes i en kilobyte / 1024 kilobyte i en megabyte = 0,97 megabyte pr. sekund * 8 = 7,8 megabit/sekund.
Denne slags båndbredde er allerede almindelig for selv private forbindelser i dag, og er helt sikkert i den lave ende af hvad colocation-udbydere vil forvente at give dig.
Når blokke er løst, vil den nuværende protokol sende transaktionerne igen, selv om en peer allerede har set den på udsendelsestidspunktet. At rette dette til at gøre blokke bare liste over hashes ville løse problemet og gøre den båndbredde, der er nødvendig for blokudsendelse, ubetydelig. Så selv om denne optimering ikke er fuldt implementeret i dag, tager vi ikke hensyn til blokoverførselsbåndbredden her.
Lagring
Ved meget høje transaktionshastigheder kan hver blok være over en halv gigabyte stor.
Det er ikke nødvendigt for de fleste fuldt validerende knudepunkter at lagre hele kæden. I Satoshis papir beskriver han “pruning”, en måde at slette unødvendige data om transaktioner, der er fuldt ud brugt. Dette reducerer mængden af data, der er nødvendig for en fuldt validerende knude, til kun at være størrelsen af den aktuelle ubrugte outputstørrelse plus nogle yderligere data, der er nødvendige for at håndtere re-orgs. Pr. oktober 2012 (blok 203258) har der været 7 979 231 transaktioner, men størrelsen af det ubrugte output-sæt er mindre end 100MiB, hvilket er lille nok til let at passe i RAM for selv ret gamle computere.
Kun et lille antal arkiveringsnoder har brug for at gemme den fulde kæde, der går tilbage til genesis-blokken. Disse noder kan bruges til at bootstrap nye fuldt validerende noder fra bunden, men er ellers unødvendige.
Den primære begrænsende faktor i Bitcoin’s ydeevne er disk søgninger, når den ubrugte transaktion output sæt holder op med at passe i hukommelsen. Når harddiske er udfaset til fordel for SSD’er, er det meget muligt, at adgangen til UTXO-sættet aldrig bliver en alvorlig flaskehals.
Optimeringer
Beskrivelsen ovenfor gælder for den nuværende software med kun mindre optimeringer antaget (den type, der kan og er blevet gjort af en mand på et par uger).
Der er imidlertid potentiale for endnu større optimeringer i fremtiden, der kan foretages på bekostning af en vis ekstra kompleksitet.
CPU
Der findes algoritmer til at fremskynde batchverifikation over elliptiske kurvesignaturer. Det er muligt at kontrollere deres signaturer samtidig for en 2x hastighedsstigning. Dette er en noget mere kompleks implementering.
Simplificeret betalingsverifikation
Det er muligt at bygge en Bitcoin-implementering, der ikke verificerer alt, men i stedet er afhængig af enten at forbinde til en betroet knude, eller sætter sin lid til høj sværhedsgrad som en proxy for bevis for gyldighed. bitcoinj er en implementering af denne tilstand.
I Simplified Payment Verification (SPV) mode, opkaldt efter den sektion af Satoshis papir, der beskriver det, klienter forbinder til en vilkårlig fuld knude og downloader kun block headers. De verificerer, at kædehovederne forbinder hinanden korrekt, og at sværhedsgraden er høj nok. Derefter anmoder de om transaktioner, der matcher bestemte mønstre, fra den eksterne knude (dvs. betalinger til dine adresser), som leverer kopier af disse transaktioner sammen med en Merkle-forgrening, der forbinder dem med den blok, hvori de optrådte. Dette udnytter Merkle-træstrukturen til at muliggøre bevis for inklusion uden at have brug for det fulde indhold af blokken.
Som en yderligere optimering kan blokoverskrifter, der er begravet tilstrækkeligt dybt, smides væk efter nogen tid (f.eks. behøver man reelt kun at gemme så lavt som 2016-overskrifter).
Den sværhedsgrad, der kræves for at opnå tillid til, at den fjerne knude ikke fodrer dig med fiktive transaktioner, afhænger af din trusselsmodel. Hvis du opretter forbindelse til en knude, der er kendt for at være pålidelig, er sværhedsgraden ligegyldig. Hvis du ønsker at vælge en tilfældig knude, bør omkostningerne for en angriber til at udvinde en bloksekvens, der indeholder en falsk transaktion, være højere end den værdi, der kan opnås ved at snyde dig. Ved at ændre hvor dybt begravet blokken skal være, kan man afveje bekræftelsestiden mod omkostningerne ved et angreb.
Programmer, der implementerer denne tilgang, kan have fast lager-/netværksoverhead i nultilfælde uden brug, og ressourceforbrug proportionalt med modtagne/afsendte transaktioner.
Se også: Thin Client Security.
Relateret arbejde
Der er et par forslag til optimering af Bitcoin’s skalerbarhed. Nogle af disse kræver en alt-kæde / hard fork.
- Ultimate blockchain compression – ideen om, at blockchain kan komprimeres for at opnå “trust-free lite nodes”
- The Finite Blockchain paper, der beskriver opdeling af blockchain i tre datastrukturer, der hver især er bedre egnet til deres formål. De tre datastrukturer er en finite blockchain (beholder N blokke i fortiden), et “account tree”, som beholder kontosaldoen for hver adresse med en saldo, der ikke er nul, og en “proof chain”, som er en (stadigt voksende) slanket version af blockchainen.
- Lightning Network, en alternativ protokol til transaktionsafregning, hvor noder opretter mikrobetalingskanaler mellem hinanden og afregner lejlighedsvis på blockchainen. Almindelige brugere interagerer primært eller udelukkende med betalingskanaler og bruger kun blockchainen til store overførsler og kold opbevaring.
