Free Press

The Future of Blockchain Series

Kampen om en skalerbar løsning er blockchain’s måneløb. Bitcoin behandler 4,6 transaktioner i sekundet. Visa foretager i gennemsnit omkring 1.700 transaktioner pr. sekund (baseret på en beregning, der er afledt af den officielle påstand om over 150 millioner transaktioner pr. dag). Potentialet for vedtagelse er der, men er i øjeblikket flaskehalset af skalerbarhed.

En undersøgelse offentliggjort af Tata Communications i 2018 viste, at 44 % af organisationerne i deres undersøgelse er i gang med at indføre blockchain, men hentyder også til de universelle problemer, der opstår ved implementering af nye teknologier. Fra et arkitektonisk niveau fremstår det uløste problem med skalerbarhed som en flaskehals for blockchain-adoption og praktiske anvendelser.

Som Deloitte Insights udtrykker det, “er blockchain-baserede systemer forholdsvis langsomme. Blockchain’s langsomme transaktionshastighed er et stort problem for virksomheder, der er afhængige af højtydende legacy transaktionsbehandlingssystemer med høj ydeevne.” Verden fik en smagsprøve på skaleringsproblemerne i 2017 og 2018: alvorlige overførselsforsinkelser og høje gebyrer på Bitcoin-netværket og den berygtede Cryptokitties-app, der overbelastede Ethereum-blokkædenetværket (et netværk, som tusindvis af decentrale applikationer er afhængige af).

For at skalere en blockchain er det ikke nok at øge blokstørrelsen eller reducere bloktiden ved at reducere hashkompleksiteten. Med begge metoder når evnen til at skalere et loft, før den kan nå de transaktioner, der er nødvendige for at konkurrere med virksomheder som Visa, som “håndterer i gennemsnit 150 millioner transaktioner hver dag” eller omkring 1.736 transaktioner pr. sekund (TPS).

Til sammenligning er Bitcoin-transaktionshastighederne enormt meget lavere. I øjeblikket er blokstørrelsen sat 1 MB (1.048.576 bytes – selv om gennem SegWit, kan denne størrelse skalere til op til en teoretisk 4 MB) og den gennemsnitlige transaktionsstørrelse er 380.04 bytes (under forudsætning af, at hver transaktion er fra en tegnebog til x andre tegnebøger – så en batch-transaktion ville tælle som én transaktion. Jeg vil tale mere om batch-transaktioner senere, og hvorfor jeg mærkede det på denne måde) og synes at være stigende. derfor er den gennemsnitlige mængde transaktioner, der kan passe ind i en af Bitcoins blokke, i øjeblikket, beregnet som:

Den nuværende Bitcoin blokgenerering tid er 10 minutter; dvs, hvert tiende minut bliver der udvundet en ny blok. På ti minutter (600 sekunder) kan Bitcoin i gennemsnit foretage omkring 2.759,12 transaktioner baseret på tidligere antagelser. Med andre ord, Bitcoin blockchain kan i øjeblikket kun garantere 4,6 transaktioner pr. sekund.

Increasing Block Size or Decreasing Block Generation Time Won’t Solve the Problem: A Look at Non-SegWit TPS

Problemet med skalerbarhed kommer pakket med blockchain værdi forslag; derfor kan man ikke blot øge skalerbarhed ved at ændre parametre i blockchain.

The Bitcoin samfund kan justere to variabler for at forsøge at øge TPS. Den ene variabel er blokstørrelsen (B), som i øjeblikket er hårdt kodet til 1 MB. Ideelt set bør B øges for at øge TPS. Den anden variabel er blokgenerationstiden (TB), som justeres ved at ændre kompleksiteten af hashing-puslespillet. Ideelt set bør TB reduceres for at øge TPS.

Scenarier 1 & 2

For at vokse fra 4,4 til Visa’s 1.736, ville Bitcoin skulle skalere sin TPS med 377,5x. Med andre ord skal B øges fra 1 MB til 377,5 MB (tabel 1, S1), eller TB skal reduceres fra ti minutter til 1,6 sekunder (tabel 1, S2). Et tredje scenarie ville være at justere begge dele. Ingen af de tre scenarier er opnåelige på blockchainen på grund af en tredje, ukontrolleret faktor: den relætid (TR), der er nødvendig for at udsende en ny blok til hver enkelt knude på Bitcoin-netværket.

I øjeblikket anslås der at være 10.198 knuder i Bitcoin-netværket. Det tager noget tid at sende en 1 MB (1.048.576 bytes) gennem peer-to-peer-netværket. Karlsruhe Institute of Technology måler Bitcoins blokudbredelsestid, og den gennemsnitlige blokudbredelsestid, der blev rapporteret den 17. januar 2019, var 13.989,42 millisekunder eller ca. 14 sekunder for at udbrede sig til 99 % af netværket. TB kan ikke falde til under 99% af TR (TR99)=14, for hvis den gør det, ville en ny blok blive genereret, før en gammel blok ville blive modtaget af de fleste af blokkene i netværket. Jo tættere TB kommer på TR99, jo flere problemer opstår der med forks, forældreløse blokke og omorganiseringer af kæden og (i ekstreme tilfælde) sikkerhedssårbarheder som f.eks. dobbeltudgiftsangreb.

Scenarie 3

Selv om TB = TR99 = 14, med en blokstørrelse på 1 MB, ville Bitcoin-blockchainen kun kunne øge sin hastighed til 188 TPS (tabel 1, S3). Selv om denne skala repræsenterer en 188x stigning i TPS, er det ikke i nærheden af de 1.736 TPS, som Visa gennemfører dagligt; desuden lægger det lag på de førnævnte risici. Den anden variabel, B, kan justeres, men ikke uden at påvirke TR, hvilket ville påvirke TR99 og dermed den nedre grænse for TB.

Scenarie 4

For eksempel ville den tid, det tager hver enkelt knude på netværket at hente en ny blok, TR, også stige ved at fordoble størrelsen af B (fra 1 MB til 2 MB) – med ca. 2x; ved 2 MB ville TR99 = 28s, så TB’s nedre grænse ville også være 28s. Ved at øge B med en hvilken som helst faktor og efterfølgende øge TR med den samme faktor ville netto-TPS forblive den samme – i dette tilfælde omkring 188 TPS (tabel 1, S4). En løsning til at reducere virkningen af B fra TR er at øge båndbredden mellem alle knudepunkterne i Bitcoin-netværket. Desværre, fordi det er et P2P-netværk, falder dette ansvar på skødet af hver enkelt peer i netværket.

The Emergence of SegWit

I 2017 trådte Segregated Witness (SegWit) i kraft på tværs af alle Bitcoin-noder. Bemærk – Jeg vil ikke gå ind i alle detaljerne i SegWit, men hvis du ønsker at lære om dens historie og dens rolle i fremkomsten af Bitcoin Cash hard fork, tage et kig på denne artikel:

Det gør, hvad navnet lyder som det gør – adskillelse af vidnet del af hver transaktion fra de faktiske transaktionsdata. Det skete som en blød gaffel, så det blev indført uden nogen større virkninger på det eksisterende blockchain-netværk og kode. På grund af den måde, hvorpå vidnetransaktionen ville blive vægtet, kunne de nye SegWit-aktiverede Bitcoin-blokke teoretisk set øges til op til 4 MB uden at ændre Bitcoin-blokstørrelsen.

Jeg siger teoretisk set, fordi der er yderligere faktorer, der bidrager til den endelige størrelse af SegWit-blokken. Faktisk, hvis du tjekker en Bitcoin blockchain explorer, vil du se, at (i hvert fald på det tidspunkt, hvor denne artikel blev offentliggjort) den gennemsnitlige blokstørrelse stadig er under 1 MB.

Men det betyder ikke, at blokke ikke kan gå over 1 MB. I begyndelsen af 2018 var vi vidne til en af de største (sandsynligvis stadig den største) blokstørrelser, der blev genereret, og som kom til at veje omkring 2,1 MB. SegWits soft fork har bidraget til at forbedre blokstørrelsen uden ændringer i kernekoden, men det forbedrer stadig ikke TPS på en skalerbar måde.

Når vi undersøgte de foregående fire scenarier under en proof-of-work-konsensus, så vi, at en simpel forøgelse af blokstørrelsen eller en reduktion af minedriftskompleksiteten kun kunne føre os så langt. Selv en kombination af dette ville være begrænset på grund af transaktionsforplantningstiden. Hvis man forsøger at udvinde nye blokke hurtigere, end gamle blokke kan spredes, vil det føre til nogle ret store sikkerhedsproblemer. SegWit har hjulpet med at afhjælpe nogle af TPS-problemerne i mellemtiden, men der er stadig behov for en mere skalerbar løsning for at opnå Visa-lignende TPS.

Det ser ud til at flytte enhver brik på plads for at øge TPS flytter en anden brik ud af plads et andet sted i blockchain-puslespillet; uanset, der er projekter og startups arbejder for at opnå de TPS svar, der er nødvendige for at skubbe blockchain adoption i et skalerbart stadium.

Eksisterende og fremtidige tilgange til at løse skalerbarhed

Når man leder efter det potentielle svar på skalerbarhedsproblemet, opstår der flere andre spørgsmål. For eksempel, hvis svaret kun gælder for en bestemt blockchain, så er det afhængig af den antagelse, at den pågældende blockchain vil være den, der har brug for denne skalerbarhed i fremtiden; ellers er indsatsen unødvendig eller malplaceret. En anden overvejelse er at forstå, hvad der kan være en afvejning. Lige nu kommer alle tilgængelige løsninger med begrænsninger.

Batchbetalinger i én transaktion

Pros: Reducerer størrelsen af en transaktion record ved at sætte flere transaktioner i én, hvilket giver mulighed for flere transaktioner samlet set pr blok, hvilket kan øge TPS til en vis grad.

Cons: Kan ikke batch flere tegnebogens transaktioner sammen; risici privatlivets fred

Batch betalinger har været en funktion af Bitcoin (og derfor, Bitcoin gafler herunder Digibyte, Dogecoin, Bitcoin Cash, etc.) gennem RPC sendmany. Exchanges gør allerede dette, og du kan se det, når du forsøger at slå dit transaktions-id op på en blockchain explorer. Hvad du kan ende med at se, er en tegnebog, der sender ud til flere forskellige tegnebøger. I så fald er det en batch-transaktion.

Fordelen ved dette er, at det at lægge det i én transaktion betyder, at 1) du kun skal betale ét transaktionsgebyr, og 2) at du ikke behøver at skrive en fuld transaktion, der som jeg beskrev tidligere er ca. 380 bytes, for hver transaktion. Faktisk er det sådan, at ud af de 380 bytes, som transaktionen kan være, kan kun 34 bytes heraf være transaktionsoplysninger.