Toelichting Bitonic over de Blocksize limiet

Voor diegenen die afgelopen 2 september niet bij Bitcoin Wednesday waren: Bitonic heeft daar een toelichting gegeven inzake ons standpunt in de Blocksize discussie.

Tevens zijn Jouke Hofman & Robert de Waard afgelopen weekend naar Montreal, Canada, geweest voor de workshop Scaling Bitcoin. Inhoudelijk zijn we dit allemaal op een rijtje aan het zetten. We zullen dit op de eerstvolgende Bitcoin Wednesday (7 oktober) nader toelichten. Alle ontwikkelingen, nu en uit het verleden, gaan we publiceren via onze website, fora en social media.

De Blocksize discussie: waar gaat de discussie precies over?

De kern van de discussie gaat over de stijging van het aantal transacties met Bitcoin en de oplossingen die er zijn om deze stijging mogelijk te maken. Deze discussie is niet nieuw en loopt al sinds 2009. Sinds 2010 is het aantal transacties blijven stijgen en is de discussie opnieuw opgelaaid vanwege het naderen van de limiet van 1 MB. Dit is vervelend, want hoeveel transacties doen we nou daadwerkelijk? Weinig. We doen dus relatief weinig transacties en we lopen al tegen limieten aan.

Waarom is er een limiet?

In de eerste plaats: waarom is die limiet er eigenlijk?
Het interessante hiervan is dat er in eerste instantie helemaal geen limiet was in Bitcoin. Satoshi heeft toen Bitcoin voor de eerste keer werd uitgebracht geen Blocksize limiet geïmplementeerd.

Dus waarom is deze limiet toegevoegd?

Dit is gebeurd voordat Bitcoin enige echte tractie kreeg (juli, 2010) omdat men bang was dat de Blockchain te groot zou worden om te hanteren voor gebruikers.

Bitcoin decentraal?

We praten er over dat Bitcoin decentraal is ‘by design’ - maar in de realiteit is dit niet zo. De hoeveelheid decentralisatie wordt niet afgedwongen door het protocol:

  • Elke 10 minuten een Block, wordt afgedwongen door het protocol;
  • Maximaal 21 miljoen bitcoins, wordt afgedwongen door het protocol;
  • Miners worden verhinderd om bitcoins te stelen in transacties, wordt afgedwongen door het protocol.

Decentralisatie van Bitcoin wordt niet afgedwongen door het protocol, maar door het aantal nodes in het P2P-netwerk.

Er is niks in de broncode die Bitcoin beschermt tegen het wegvallen van bitcoin-nodes uit het netwerk. Bitcoin zal dan gewoon draaien met één enkele node voor het afhandelen van transacties. Dus Bitcoin is alleen decentraal door de mensen die bereid zijn om deze bitcoin-nodes te draaien.

Het is dus belangrijk dat het runnen van een bitcoin-node niet te duur is.
Het probleem is dat het runnen van een node duurder wordt door een te grote Blockchain, waardoor de Blocksize limiet van 1 MB geïntroduceerd is.

Hoe op te schalen?

De meest voor de hand liggende keuze is om de Blocksize te vergroten.
Er zijn verschillende voorstellen, bijvoorbeeld naar 2 MB. Dat klinkt redelijk. Dat is ‘maar’ 1 MB meer, dat lijkt niet veel. Echter betekent dit dat het runnen van een node twee keer zo zwaar wordt. Dat is een behoorlijk verschil. Het voorstel van de Bitcoin-XT fork is 8 MB met een verdubbeling om de 2 jaar.

Het is zeer aannemelijk dat het voorstel van Bitcoin-XT daarom effect heeft op het aantal nodes. Onze verwachting is dat het een dusdanig negatief effect heeft op het aantal nodes dat we als Bitonic alvast hebben besloten dat we zo’n extreme wijziging niet zullen steunen.

Echter betekent dit niet dat we tegen elk voorstel voor het vergroten van de Blocksize zijn. We zijn ons bewust dat de capaciteiten van computers en internetverbindingen elke dag groeien. We denken daarom dat er ruimte is om de Blockchain te laten groeien, in relatie met de groei van deze capaciteiten. Veel van de voorstellen nemen dit mee.

Het probleem van veel van de voorstellen is dat deze pogen een voorspelling te doen hoe snel computer hardware en netwerkcapaciteiten gaan groeien in de komende jaren. Wij zijn ons er van bewust dat we de toekomst niet perfect kunnen voorspellen. Het lijkt ons daarom een beter idee dat Bitcoin-nodes hun capaciteiten kenbaar maken en de Blockchain laten groeien aan de hand daarvan, zoals is geïmplementeerd in BIP100.

Maar wat als blijkt dat de capaciteit van Bitcoin-nodes niet snel genoeg kan groeien?

Hoe kunnen we dan wereldwijde adoptie bereiken? Moeten we dan decentralisatie opgeven?

In ieder geval is Bitonic tegen een lineaire groei van de Blocksize limiet.

De Blocksize kan twee keer zo groot worden, alleen betekent dit dat je twee keer zoveel capaciteit nodig hebt voor alleen twee keer zoveel transacties. Twee keer nauwelijks transacties is nog steeds weinig transacties. Wanneer men denkt dat het vergroten van de Blocksize limiet de enige oplossing is om Bitcoin op te schalen...Dan is de enige oplossing het decentrale karakter van Bitcoin opgeven hier het gevolg van.

Wij als Bitonic zijn hier op tegen. Heel veel transacties doen op een centrale manier is absoluut niet waarom Bitcoin is gestart. Gelukkig zijn er nog andere oplossingen.

Bitcoin-transacties staan ook contractuele-transacties toe die oplossingen mogelijk maken als Payment Channels (streamium), Side chains, Lighting Network, Amiko Pay, enzovoort. Een paar maanden geleden deed Corné Plooy van Amiko Pay een berekening (op Bitcoin Wednesday): een Block Size van 20 MB zou voldoende kunnen zijn om iedereen op de wereld Bitcoin-transacties te laten doen.

Bij Bitonic monitoren we actief de progressie van dit soort oplossingen.
We zijn er van overtuigd dat wanneer de 1 MB Blocksize wordt benaderd deze oplossingen bruikbaar worden.

Dus wat is de oplossing volgens ons?

Op dit moment hebben we nog geen idee. Bitcoin is een netwerk van miljarden dollars dat werkt omdat de incentives kloppen. Verandering van deze incentives zou kunnen betekenen dat het hele netwerk afbrokkelt. Alle incentives binnen Bitcoin zijn al complex, dus het is erg lastig om daar aan te rommelen. We hebben het nog niet eens gehad over de fee structuur. Wat gebeurd er als de Block Reward wordt gehalveerd? De volgende halvering is al volgend jaar.

Al met al is het een complex onderwerp en daardoor is het maken van beslissingen erg lastig. Het lijkt daardoor alsof mensen vastlopen in het maken van een beslissing, maar dat is niet het geval. Iedere dag komen er nieuwe oplossingen en dit maakt het maken van een goede beslissing een enorme uitdaging.

Onze interpretatie van de Stress-testen

We hebben de stress-testen geanalyseerd en gevisualiseerd in onderstaande figuren. Figuren 2,3,4 illustreren wat de invloed van het stress-testen is geweest op de verwerkingssnelheid van onze transacties. Onze conclusie is dat deze testen hebben laten zien dat het geen impact heeft gehad op onze transacties. Wanneer er voldoende fee wordt meegestuurd is er geen afwijking te zien in de snelheid waarin transacties worden verwerkt. We sturen uiteraard altijd voldoende fee mee. Figuur 2 en 4 hebben geen significante afwijking ten opzichte van figuur 3.

Figuur 1 is een weergave van de stress-test van 7,8,9 juli 2015. Deze test laat zien wat het effect is van een toename van transacties op de Blocksize. De Mempool bevat de ontvangen tranacties van een node die nog onbevestigd zijn. Alle full-nodes en miners houden dit bij.

mempool

Figuur 2,3 & 4 laten zien hoe snel de transacties die wij verstuurden werden opgenomen in een Block. Block 0 betekent dat ze in het eerstvolgende Block werden opgenomen. We hebben de transacties van 8 juli tot en met 15 september opgesplitst in verschillende periodes om te laten zien wat het verschil is tussen een normale periode en de periodes waarin de stress-testen plaatsvonden.

mempool

mempool

mempool

Eerdere berichten

Nieuwsoverzicht

Toestemming Live Chat

De Live Chat is een dienst van MessageBird B.V. die (o.a.) onderworpen is aan de AVG (Algemene Verordening Gegevensbescherming) en stelt dat zij uw gegevens niet gebruiken voor commercieel gewin. Om de Live Chat te laden, vragen we u toestemming te geven voor de verwerking van de gegevens die u via de Live Chat met ons deelt. Door dit venster te sluiten zonder toestemming te geven, wordt de chat niet geladen en worden er geen gegevens gedeeld.
Voor verdere informatie verwijzen wij graag naar de Privacyverklaring van MessageBird.