- The Future of Blockchain Series
- Ja, blockchain heeft een schaalbaarheidsprobleem. Hier is wat het is, en hier is wat mensen doen om het op te lossen.
- Het vergroten van de blokgrootte of het verkleinen van de blokgeneratietijd lost het probleem niet op: een blik op Non-SegWit TPS
- De opkomst van SegWit
- Bestaande en toekomstige benaderingen om schaalbaarheid op te lossen
- Batch betalingen in één transactie
The Future of Blockchain Series
Ja, blockchain heeft een schaalbaarheidsprobleem. Hier is wat het is, en hier is wat mensen doen om het op te lossen.
De strijd om een schaalbare oplossing is de maanrace van de blockchain. Bitcoin verwerkt 4,6 transacties per seconde. Visa doet gemiddeld zo’n 1.700 transacties per seconde (gebaseerd op een berekening die is afgeleid van de officiële claim van meer dan 150 miljoen transacties per dag). Het potentieel voor adoptie is er, maar wordt momenteel geblokkeerd door schaalbaarheid.
Uit een onderzoek dat Tata Communications in 2018 publiceerde, blijkt dat 44% van de organisaties in haar onderzoek blockchain adopteert, maar zinspeelt ook op de universele problemen die zich voordoen bij het inzetten van nieuwe technologieën. Vanaf een architecturaal niveau komt het onopgeloste probleem van schaalbaarheid naar voren als een knelpunt voor de adoptie van blockchain en praktische toepassingen.
Zoals Deloitte Insights het formuleert, “blockchain-gebaseerde systemen zijn relatief traag. De trage transactiesnelheid van blockchain is een grote zorg voor ondernemingen die afhankelijk zijn van krachtige legacy transactieverwerkingssystemen.” De wereld kreeg een voorproefje van de schaalbaarheidsproblemen in 2017 en 2018: ernstige overdrachtsvertragingen en hoge kosten op het Bitcoin-netwerk, en de beruchte Cryptokitties-app die het Ethereum-blockchainnetwerk verstopte (een netwerk waar duizenden gedecentraliseerde applicaties op vertrouwen).
Om een blockchain te schalen, is het vergroten van de blokgrootte of het verminderen van de bloktijd door het verminderen van de hash-complexiteit niet voldoende. Met beide methoden bereikt het vermogen om te schalen een plafond voordat het de transacties kan bereiken die nodig zijn om te concurreren met bedrijven als Visa, dat “gemiddeld 150 miljoen transacties per dag verwerkt” of ongeveer 1.736 transacties per seconde (TPS).
In vergelijking daarmee zijn de transactiesnelheden van Bitcoin enorm veel lager. Momenteel is de blokgrootte 1MB (1.048.576 bytes – hoewel door SegWit, die grootte kan worden opgeschaald tot een theoretische 4MB) en de gemiddelde transactiegrootte is 380,04 bytes (ervan uitgaande dat elke transactie van één portemonnee naar x andere wallets gaat – dus een batchtransactie zou tellen als één transactie. Ik zal later meer vertellen over batchtransacties en waarom ik het zo gelabeld heb) en lijkt te stijgen.Daarom wordt het gemiddelde aantal transacties dat in één van de Bitcoin-blokken past, momenteel berekend als:
De huidige generatietijd van Bitcoin-blokken is 10 minuten; d.w.z., elke tien minuten wordt een nieuw blok gemijnd. In tien minuten (600 seconden) kan Bitcoin gemiddeld ongeveer 2.759,12 transacties uitvoeren, uitgaande van eerdere aannames. Met andere woorden, de Bitcoin-blockchain kan momenteel slechts 4,6 transacties per seconde garanderen.
Het vergroten van de blokgrootte of het verkleinen van de blokgeneratietijd lost het probleem niet op: een blik op Non-SegWit TPS
Het probleem van schaalbaarheid komt verpakt met blockchain-waardeproposities; daarom kan men de schaalbaarheid niet eenvoudig vergroten door parameters in de blockchain te veranderen.
De Bitcoin-gemeenschap kan twee variabelen aanpassen om te proberen de TPS te vergroten. De ene variabele is de blokgrootte (B), die momenteel hard gecodeerd is op 1MB. Idealiter zou B vergroot moeten worden om de TPS te vergroten. De andere variabele is de blokgeneratietijd (TB), die wordt aangepast door de complexiteit van de hashingpuzzel te wijzigen. Idealiter moet TB worden verminderd om de TPS te verhogen.
Scenario’s 1 & 2
Om van 4,4 naar Visa’s 1.736 te groeien, zou Bitcoin zijn TPS met 377,5x moeten opschalen. Met andere woorden, B zou moeten worden verhoogd van 1MB tot 377,5MB (tabel 1, S1) of TB zou moeten worden verlaagd van tien minuten tot 1,6 seconden (tabel 1, S2). Een derde scenario zou zijn beide aan te passen. Elk van de drie scenario’s is onhaalbaar op de blockchain vanwege een derde, oncontroleerbare factor: de relaistijd (TR) die nodig is om een nieuw blok naar elke node op het Bitcoin-netwerk te zenden.
Momenteel zijn er naar schatting 10.198 nodes in het Bitcoin-netwerk. Het verzenden van een 1MB (1.048.576 bytes) door het peer-to-peer netwerk neemt enige tijd in beslag. Het Karlsruhe Institute of Technology meet de blokpropagatietijd van Bitcoin, en de gemiddelde blokpropagatietijd gerapporteerd op 17 januari 2019 was 13.989,42 milliseconden of ongeveer 14 seconden om door te propageren naar 99% van het netwerk. TB kan niet onder 99% van TR (TR99)=14 komen, want als dat wel het geval is, dan zou een nieuw blok worden gegenereerd voordat een oud blok door de meeste blokken in het netwerk zou zijn ontvangen. Hoe dichter TB bij TR99 komt, hoe meer problemen er ontstaan met forks, orphan blocks en chain re-organizations, en (in extreme gevallen) beveiligingskwetsbaarheden zoals double-spend attacks.
Scenario 3
Zelfs als TB = TR99 = 14, met een blokgrootte van 1MB, zou de Bitcoin-blockchain zijn snelheid slechts kunnen opvoeren tot 188 TPS (tabel 1, S3). Hoewel die schaal een toename van 188 TPS vertegenwoordigt, komt hij niet in de buurt van de 1 736 TPS die Visa dagelijks uitvoert; bovendien legt hij een laag op de eerder genoemde risico’s. De andere variabele, B, kan worden aangepast, maar niet zonder dat dit gevolgen heeft voor TR, hetgeen gevolgen zou hebben voor TR99 en derhalve voor de ondergrens van TB.
Scenario 4
Voorbeeld: door de grootte van B te verdubbelen (van 1 MB naar 2 MB), zou de tijd die elk knooppunt op het netwerk nodig heeft om een nieuw blok te downloaden, TR, ook toenemen – met ongeveer 2x; bij 2 MB zou TR99 dus 28s bedragen, zodat de ondergrens van TB ook 28s zou bedragen. Door B met een willekeurige factor te verhogen, en vervolgens TR met dezelfde factor te verhogen, zou de netto TPS gelijk blijven – in dit geval ongeveer 188 TPS (tabel 1, S4). Een oplossing om de invloed van B op TR te verminderen is de bandbreedte tussen alle knooppunten in het Bitcoin-netwerk te vergroten. Helaas, omdat het een P2P-netwerk is, valt die verantwoordelijkheid in de schoot van elke peer in het netwerk.
De opkomst van SegWit
In 2017 ging Segregated Witness (SegWit) van kracht over alle Bitcoin-knooppunten. Opmerking – Ik zal niet ingaan op alle details van SegWit, maar als u meer wilt weten over de geschiedenis ervan en de rol ervan in de opkomst van de Bitcoin Cash-hard fork, bekijk dan dit artikel:
Het doet wat de naam klinkt alsof het doet – het scheiden van het getuige-gedeelte van elke transactie van de eigenlijke transactiegegevens. Het gebeurde als een soft fork, dus het werd ingesteld zonder grote effecten op het bestaande blockchain netwerk en code. Vanwege de manier waarop de getuigentransactie zou worden gewogen, zouden de nieuwe SegWit-enabled Bitcoin-blokken theoretisch kunnen worden verhoogd tot maximaal 4 MB zonder de grootte van het Bitcoin-blok te veranderen.
Ik zeg theoretisch omdat er extra factoren zijn die bijdragen aan de uiteindelijke grootte van het SegWit-blok. In feite, als je een Bitcoin blockchain verkenner bekijkt, zul je zien dat (in ieder geval op het moment dat dit artikel werd gepubliceerd) de gemiddelde blokgrootte nog steeds onder de 1MB ligt.
Maar dat wil niet zeggen dat blokken niet verder kunnen gaan dan 1MB. Begin 2018 waren we getuige van een van de grootste (waarschijnlijk nog steeds de grootste) blokgroottes die werden gegenereerd, met een gewicht van ongeveer 2,1 MB. De soft fork van SegWit heeft geholpen de blokgrootte te verbeteren zonder wijzigingen in de kerncode, maar het verbetert nog steeds niet de TPS op een schaalbare manier.
Toen we de vorige vier scenario’s onder een proof-of-work-consensus onderzochten, zagen we dat het simpelweg vergroten van de blokgrootte of het verminderen van de mijnbouwcomplexiteit ons maar tot op zekere hoogte zou kunnen brengen. Zelfs een combinatie hiervan zou beperkt zijn vanwege de transactietijd. Proberen om nieuwe blokken sneller te delven dan oude blokken zich kunnen voortplanten zal leiden tot een aantal behoorlijk grote veiligheidsproblemen. SegWit heeft geholpen een aantal van de TPS-problemen in de tussentijd te verlichten, maar een meer schaalbare oplossing is nog steeds nodig om Visa-like TPS.
Het lijkt erop dat het verplaatsen van elk stuk op zijn plaats om TPS te verhogen, een ander stuk ergens anders in de blockchain-puzzel van zijn plaats haalt; hoe dan ook, er zijn projecten en startups die werken aan het bereiken van de TPS-antwoorden die nodig zijn om blockchain-adoptie in een schaalbaar stadium te duwen.
Bestaande en toekomstige benaderingen om schaalbaarheid op te lossen
Bij het zoeken naar het potentiële antwoord op het schaalbaarheidsprobleem, komen meerdere andere problemen naar voren. Bijvoorbeeld, als het antwoord alleen toepasbaar is voor één bepaalde blockchain, dan berust het op de aanname dat die bepaalde blockchain degene zal zijn die in de toekomst die schaalbaarheid nodig heeft; anders is de inspanning onnodig of misplaatst. Een andere overweging is te begrijpen wat de afweging kan zijn. Op dit moment komen alle beschikbare oplossingen met beperkingen.
Batch betalingen in één transactie
Pros: Vermindert de grootte van een transactierecord door meerdere transacties in één te stoppen, waardoor meer transacties in totaal per blok mogelijk zijn, wat de TPS tot op zekere hoogte kan verhogen.
Cons: Kan niet de transacties van meerdere portemonnees samen batchen; riskeert privacy
Batchbetalingen is een kenmerk geweest van Bitcoin (en dus ook van de vertakkingen van Bitcoin, waaronder Digibyte, Dogecoin, Bitcoin Cash, enzovoort) via de RPC sendmany. Uitwisselingen doen dit al, en je kunt het zien als je je transactie ID probeert op te zoeken in een blockchain verkenner. Wat je uiteindelijk zou kunnen zien is één portemonnee die naar meerdere verschillende portemonnees stuurt. In dat geval is het een batchtransactie.
Het voordeel hiervan is dat het in één transactie stoppen betekent dat 1) je maar één transactiekosten hoeft te betalen, en 2) je niet een volledige transactie hoeft te schrijven die, zoals ik eerder beschreef, ongeveer 380 bytes is, voor elke transactie. In feite, van de 380 bytes die de transactie kan zijn, zouden slechts 34 bytes daarvan de transactie-informatie kunnen zijn.