Free Press

The Future of Blockchain Series

Kampen om en skalbar lösning är blockkedjans månrace. Bitcoin behandlar 4,6 transaktioner per sekund. Visa gör i genomsnitt cirka 1 700 transaktioner per sekund (baserat på en beräkning som härrör från det officiella påståendet om över 150 miljoner transaktioner per dag). Potentialen för antagande finns där, men flaskhalsar för närvarande av skalbarhet.

En studie som publicerades av Tata Communications 2018 visade att 44 % av organisationerna i deras undersökning inför blockchain, men anspelar också på de universella problem som uppstår vid införande av ny teknik. Från en arkitektonisk nivå framstår det olösta problemet med skalbarhet som en flaskhals för blockkedjeanvändning och praktiska tillämpningar.

Som Deloitte Insights uttrycker det, ”blockkedjebaserade system är jämförelsevis långsamma. Blockkedjans tröga transaktionshastighet är ett stort bekymmer för företag som är beroende av högpresterande äldre transaktionsbehandlingssystem”. Världen fick en försmak av skalbarhetsproblemen 2017 och 2018: svåra överföringsfördröjningar och höga avgifter på Bitcoin-nätverket och den ökända Cryptokitties-appen som överbelastade Ethereum-blockkedjenätverket (ett nätverk som tusentals decentraliserade tillämpningar förlitar sig på).

För att skala en blockkedja räcker det inte med att öka blockstorleken eller minska blocktiden genom att minska hashkomplexiteten. Med båda metoderna når skalbarheten ett tak innan den kan nå de transaktioner som krävs för att konkurrera med företag som Visa, som ”hanterar i genomsnitt 150 miljoner transaktioner varje dag” eller cirka 1 736 transaktioner per sekund (TPS).

I jämförelse är Bitcoins transaktionshastigheter enormt mycket lägre. För närvarande är blockstorleken fastställd till 1 MB (1 048 576 bytes – även om den storleken genom SegWit kan skalas upp till teoretiska 4 MB) och den genomsnittliga transaktionsstorleken är 380,04 bytes (om man antar att varje transaktion är från en plånbok till x andra plånböcker – så en batch-transaktion skulle räknas som en transaktion. Jag kommer att prata mer om batch-transaktioner senare och varför jag märkte det på detta sätt) och verkar vara på uppgång. därför är den genomsnittliga mängden transaktioner som kan rymmas i ett av Bitcoins block, för närvarande, beräknad som:

Den nuvarande Bitcoin-blocksgenereringstiden är 10 minuter; dvs, var tionde minut skapas ett nytt block. På tio minuter (600 sekunder) kan Bitcoin i genomsnitt genomföra cirka 2 759,12 transaktioner enligt tidigare antaganden. Med andra ord kan Bitcoin-blockkedjan för närvarande endast garantera 4,6 transaktioner per sekund.

Öka blockstorleken eller minska blockgenereringstiden löser inte problemet: En titt på Non-SegWit TPS

Problemet med skalbarhet kommer förpackat med blockkedjans värdeerbjudanden; därför kan man inte helt enkelt öka skalbarheten genom att ändra parametrar i blockkedjan.

Bitcoin-communityt kan justera två variabler för att försöka öka TPS. Den ena variabeln är blockstorleken (B), som för närvarande är hårt kodad till 1 MB. Helst bör B ökas för att öka TPS. Den andra variabeln är blockgenereringstiden (TB), som justeras genom att ändra hashingpusslets komplexitet. Helst bör TB minskas för att öka TPS.

Scenarier 1 & 2

För att växa från 4,4 till Visas 1 736, skulle Bitcoin behöva skala sin TPS med 377,5x. Med andra ord skulle B behöva ökas från 1 MB till 377,5 MB (tabell 1, S1) eller TB skulle behöva minskas från tio minuter till 1,6 sekunder (tabell 1, S2). Ett tredje scenario skulle vara att justera båda. Inget av de tre scenarierna kan uppnås på blockkedjan på grund av en tredje, okontrollerad faktor: den relätid (TR) som behövs för att sända ett nytt block till varje nod i Bitcoin-nätverket.

För närvarande uppskattas det finnas 10 198 noder i Bitcoin-nätverket. Att sända en 1 MB (1 048 576 bytes) genom peer-to-peer-nätverket tar en viss tid. Karlsruhe Institute of Technology mäter Bitcoins blockspridningstid och den genomsnittliga blockspridningstiden som rapporterades den 17 januari 2019 var 13 989,42 millisekunder eller cirka 14 sekunder för att sprida sig till 99 % av nätverket. TB kan inte sjunka under 99 % av TR (TR99)=14 eftersom ett nytt block i så fall skulle genereras innan ett gammalt block tas emot av de flesta blocken i nätverket. Ju närmare TB kommer TR99, desto fler problem uppstår med gafflar, föräldralösa block och omorganiseringar av kedjan och (i extrema fall) säkerhetssårbarheter som attacker med dubbla utgifter.

Scenario 3

Även om TB = TR99 = 14, med en blockstorlek på 1 MB, skulle Bitcoins blockkedja bara kunna öka sin hastighet till 188 TPS (tabell 1, S3). Även om denna skala representerar en 188x ökning av TPS är den inte i närheten av de 1 736 TPS som Visa genomför dagligen; dessutom lägger den på de ovan nämnda riskerna. Den andra variabeln, B, kan justeras, men inte utan att påverka TR, vilket skulle påverka TR99 och därmed TB:s nedre gräns.

Scenario 4

Till exempel, genom att fördubbla storleken på B (från 1 MB till 2 MB) skulle den tid som det tar för varje nod i nätverket att ladda ner ett nytt block, TR, också öka – med ungefär 2 gånger; vid 2 MB skulle alltså TR99 = 28s, så TB:s nedre gräns skulle också vara 28s. Genom att öka B med en valfri faktor och därefter öka TR med samma faktor skulle netto-TPS förbli detsamma – i detta fall omkring 188 TPS (tabell 1, S4). En lösning för att minska effekten av B från TR är att öka bandbredden mellan alla noder i Bitcoin-nätverket. Eftersom det är ett P2P-nätverk faller det ansvaret tyvärr på varje peer i nätverket.

SegWits uppkomst

Under 2017 trädde Segregated Witness (SegWit) i kraft i alla Bitcoin-noder. Obs – jag kommer inte att gå in på alla detaljer om SegWit, men om du vill lära dig om dess historia och dess roll i uppkomsten av Bitcoin Cash hard fork, ta en titt på den här artikeln:

Det gör det som namnet låter som det gör – segregerar vittnesdelen av varje transaktion från de faktiska transaktionsuppgifterna. Det inträffade som en soft fork, så det instiftades utan några större effekter på det befintliga blockchain-nätverket och koden. På grund av det sätt som vittnestransaktionen skulle viktas skulle de nya SegWit-aktiverade bitcoinblocken teoretiskt sett kunna ökas till upp till 4 MB utan att ändra bitcoinblockets storlek.

Jag säger teoretiskt sett eftersom det finns ytterligare faktorer som bidrar till den slutliga storleken på SegWit-blocket. Faktum är att om du kollar en utforskare av Bitcoin-blockkedjan kommer du att se att (åtminstone när den här artikeln publicerades) den genomsnittliga blockstorleken fortfarande är under 1 MB.

Men det betyder inte att block inte kan överstiga 1 MB. I början av 2018 bevittnade vi en av de största (förmodligen fortfarande största) blockstorlekarna som genererades, med en vikt på omkring 2,1 MB. SegWits mjuka gaffel har bidragit till att förbättra blockstorleken utan ändringar i kärnkoden, men den förbättrar fortfarande inte TPS på ett skalbart sätt.

När vi undersökte de fyra föregående scenarierna under en proof-of-work-konsensus såg vi att en enkel ökning av blockstorleken eller en minskning av gruvkomplexiteten bara kunde ta oss så långt. Även en kombination av detta skulle vara begränsad på grund av transaktionsförmedlingstiden. Att försöka bryta nya block snabbare än vad gamla block kan spridas leder till ganska stora säkerhetsproblem. SegWit har bidragit till att lindra en del av TPS-problemen under tiden, men det behövs fortfarande en mer skalbar lösning för att uppnå Visa-liknande TPS.

Det verkar som att om man flyttar någon bit på plats för att öka TPS så flyttas en annan bit på plats någon annanstans i blockkedjepusslet; oavsett detta finns det projekt och nystartade företag som arbetar för att uppnå de TPS-svar som behövs för att driva blockkedjeanvändningen in i ett skalbart stadium.

Existerande och framtida tillvägagångssätt för att lösa skalbarhet

När man letar efter det potentiella svaret på skalbarhetsproblemet uppstår flera andra frågor. Om svaret till exempel bara är tillämpligt för en viss blockkedja bygger det på antagandet att just den blockkedjan kommer att vara den som behöver den skalbarheten i framtiden, annars är ansträngningen onödig eller malplacerad. Ett annat övervägande är att förstå vad avvägningen kan vara. Just nu har alla tillgängliga lösningar begränsningar.

Batchbetalningar till en transaktion

Pros: Det kan inte sammanföra flera plånbokstransaktioner, vilket kan öka TPS i viss utsträckning.

Nackdelar: Kan inte sammanföra flera plånbokstransaktioner; riskerar integritet

Batchbetalningar har varit en funktion i Bitcoin (och därmed i Bitcoins gafflar, inklusive Digibyte, Dogecoin, Bitcoin Cash, etc.) genom RPC-sändningen. Exchanges gör redan detta, och du kan se det när du försöker slå upp ditt transaktions-ID på en blockchain explorer. Vad du kan komma att se är att en plånbok skickar ut till flera olika plånböcker. I det fallet är det en batch-transaktion.

Fördelen med detta är att om du lägger det i en transaktion innebär det att 1) du bara behöver betala en transaktionsavgift, och 2) du behöver inte skriva en hel transaktion som är, som jag beskrev tidigare, ungefär 380 bytes, för varje transaktion. Faktum är att av de 380 byte som transaktionen kan vara, kan endast 34 byte av dessa vara transaktionsinformation.