Kernentwickler diskutieren konkrete Vorschläge zum Blocksize-Thema
cube - 03 von Racchio via flickr.com. Lizenz: Creative Commons
Weiter 1 MB? Oder 2? Oder doch gleich 8? Die Bitcoin-Kernentwickler diskutieren, wie man die Blocksize erhöhen kann. Mittlerweile gibt es vier konkrete Vorschläge, die zur Debatte stehen. Für die Szene sind die meisten von ihnen enttäuschend. Sie möchte am liebsten sofort sehr große Blöcke sehen, damit Bitcoin so viele Transaktionen wie möglich stemmen kann. Allerdings ist die Debatte nicht ganz so einfach …
So gut wie jeder kennt das Problem: Der Vertrieb will, dass die Produktion das Unmögliche wahrmacht, und mehr produziert, als die Fabrik hergibt. Der Bauherr möchte ein Haus, das günstig, riesig, wärmegedämmt ist und allen statischen Prinzipien widerspricht. Und so weiter. In jedem Projekt gibt es diejenigen, die verlangen und fordern, und es gibt diejenigen, die konstruieren und bauen. Meist widersprechen sich diese beiden Gruppen. Die einen wollen das maximal wünschbare, die anderen klären das Mögliche. Die einen greifen nach den Sternen, die anderen zum Maßband.
Bei der Entwicklung von Bitcoin-Core, der Kernsoftware des Bitcoins, ist es nicht anders. Die Community möchte, dass die Größe der Blöcke erhöht wird, damit der Bitcoin mehr Transaktionen stemmen kann. Eine Beschränkung auf 1 MB je Block – was 3-5 Transaktionen je Sekunde entspricht – ist nun mal zuwenig für ein Zahlungsmittel mit dem Anspruch, global zu funktionieren, Nanopayment zu ermöglichen und nebenbei als verteilte Datenbank den Wertpapierhandel und das Notarwesen zu revolutionieren. Daher sind sich an sich alle einig: Bitcoin muss lernen, besser zu skalieren.
Blöcke und ihre Größe
Blöcke sind die fundamentale Einheit der Blockchain genannten Technologie hinter dem Bitcoin. Die Miner fügen etwa alle zehn Minuten einen neuen Block mit aktuellen Transaktionen an die Blockchain an. Diesen neuen Block verteilen sie dann im Netzwerk, wodurch alle Teilnehmer dieselbe Blockchain mit denselben Blöcken haben. Eine Transaktion gilt erst als bestätigt, wenn sie in einen neuen Block aufgenommen und dieser an die Blockchain hinzugefügt ist. Ursprünglich war die Größe von Blöcken unlimitiert. Nachdem aber ein theoretischer Angriff gefunden wurde, haben die Entwickler die Größe von Blöcken auf 1 Megabyte beschränkt. Umgerechnet bedeutet dies, dass die Blockchain nicht mehr als 3-5 Transaktionen je Sekunde aufnehmen kann. Dieses Limit ist bis heute gültig. Lange Zeit war es kein Problem, doch die stark steigende Anzahl täglicher Transaktionen bringt das Bitcoin-Netzwerk immer öfter an sein Limit, weshalb der Ruf nach größeren Blöcken zunehmend laut wird.
Die Kernentwickler beschäftigen sich natürlich schon länger mit dem sogenannten Scalability-Problem. Während sie Bitcoin Core ständig weiterentwickeln (brillant mit der Version 0.11!), diskutieren sie verschiedene Lösungsansätze. Allerdings gehen die Ansichten, wie man Bitcoin skalierbar macht und wie groß künftig die Blöcke sein sollen, megaweit auseinander.
Während Kernentwickler Gavin Andresen konsequent und öffentlich für größere Blöcke plädiert, bleibt der Rest eher skeptisch mit einem unterschiedlichen Grad an Kompromissbereitschaft. Nun diskutieren die Kernentwickler in der Bitcoin-Mailing-List vier Vorschläge (Bitcoin Improvement Proposals, kurz: BIP) für eine Hard-Fork:
BIP100: Schlägt eine Hard Fork am 11. Januar 2016 vor, nachdem 90 Prozent der Miner zuvor zugestimmt haben. Die Blocksize soll zu diesem Zeitpunkt weiterhin 1 MB betragen, aber nach Übereinstimmung der Miner alle 3 Monate eine Erhöhung um den Faktor 0,5 bis 2 ermöglichen.
BIP101: Eine Hardfork soll frühestens am 11. Januar 2016 geschehen, nachdem 75 Prozent der Miner sie unterstützen. Die Größe der Blöcke soll sofort auf 8 MB springen, sich dann alle zwei Jahre verdoppeln, bis sie schließlich am 11. Januar 2036 8192 MB groß ist.
BIP102: Am 11. November 2015 soll eine Hardfork einsetzen, die die Größe der Blöcke auf 2 MB erhöht. Weitere Erhöhungen sind nicht vorgesehen.
BIP103: Schlägt eine HardFork am 1. Januar 2017 vor. Die Blocksize bleibt zunächst ebenso groß, steigt aber alle 97 Tage um 4,4 Prozent und wird 2063 die finale Größe von 2048 MB erreichen. Eine Steigerung von 17,7 Prozent im Jahr entspreche etwa dem Wachstum der Bandbreite.
Wer entscheidet, welcher Vorschlag umgesetzt wird?
Bitcoin ist Open Source, ja, was zunächst bedeutet, dass jeder den Code einsehen und nach Lust und Laune kopieren darf. Einen Push (= Write) Zugang zum Code auf GitHub hat allerdings nur eine sehr beschränkte Anzahl von Personen. Dies sind Wladimir J. van der Laan, Gavin Andresen, Jeff Garzik, Gregory Maxwell und Pieter Wuille. Nur diese Personen können den Bitcoin-Code verändern. Allerdings bekommen sie natürlich Hilfe von zahlreichen freiwilligen Entwicklern, die neue Versionen im Testnet testen und Vorschläge ausarbeiten.
Was allerdings jeder machen kann, ist, den Code zu forken und eine eigene Version aufzubauen. So hat Mike Hearn etwa Bitcoin XT von der Originalsoftware geforkt. Hearn hat bereits angekündigt, mit XT Gavin Andresens Vorschlag für 8 MB große Blöcke zu implementieren. Allerdings ist XT zum einen ein um Mike Hearn zentralisiertes Programm und es hat zum anderen viel zu wenig Anhänger, um Bitcoin Core als Standardsoftware abzulösen.
Ohne einen Konsens der fünf Kernentwickler wird es vermutlich keine gültige Erhöhung der Blocksize geben. Daher hängt nun alles davon ab, wie diese fünf Personen sich entscheiden. Gavin Andresen, Jeff Garzik und Peter Wuille haben bereits ihren Vorschlag eingereicht. Von Gregory Maxwell ist aufgrund vorheriger Äußerungen nicht zu erwarten, dass er eine Erhöhung der Blockgröße unterstützt, während Wladimir van der Laan als leitender Entwickler sich bislang mit konkreten Äußerungen weitgehend zurückhält.
Was spricht gegen eine Erhöhung der Blockgröße?
Während es sehr naheliegend ist, warum man größere Blöcke braucht – um mehr Transaktionen zu verteilen – sind die Argumente gegen eine Erhöhung der Blockgröße komplizierter und technologischer. Die Kernentwickler sehen ihre Aufgabe nicht darin, ökonomische Wünsche der Community zu erfüllen, sondern die Sicherheit des Systems zu gewährleisten. Und für dieses stellt nicht nur eine Hard Fork an sich ein großes Risiko dar, sondern auch die unkontrollierte Erhöhung der Blockgröße. Es gibt folgende technische Risikofaktoren:
- Der Bedarf an Festplattenspeicher führt zur weiteren Zentralisierung von Knoten. Man benötigt schon jetzt mehr als 30 Gigabyte Festplattenspeicher, um Bitcoin Core zu betreiben. Wenn man die Blockgröße auf beispielsweise 8 MB erhöht, kann sich diese Zahl sehr schnell vervielfachen. Ein DdoS-Transaktionen durch Spam-Attacken kann alle zehn Minuten 8 MB sinnlose Daten auf jede Festplatte übertragen, die die Blockchain speichert. Für institutionelle Anbieter und Rechenzentren ist dies kein Problem, für den einzelnen Benutzer jedoch schon.
- Der Bedarf an Bandbreite führt ebenfalls zu weiterer Zentralisierung. Jeder Knoten propagiert eingehende Transaktionen und Blöcke im Netzwerk. Bereits jetzt benötigt Bitcoin Core eine gewisse Menge an Bandbreite. Wenn nun die Blöcke größer werden, werden nicht nur mehr Transaktionen durch die Knoten laufen, sondern auch größere Blöcke, welche mehr Bandbreite benötigen, um verteilt zu werden. Zu große Blöcke könnten es für Menschen in strukturschwachen Gebieten (zum Beispiel im nicht-metropolen Großraum Nürnberg :)) unmöglich machen, einen Node zu betreiben. Es gibt verschiedene Hochrechnungen, wie hoch die benötigte Bandbreite sein wird und wie hoch die verfügbare Bandbreite in Zukunft ausfallen wird. Diese Hochrechnungen sind allerdings nicht eben valide und daher immer selbst ein Risikofaktor. Während Gavin Andresen sehr optimistisch rechnet, um die Blöcke möglichst groß zu kriegen, rechnet Pieter Wuille sehr konservativ, um das System keinen Risiken auszusetzen.
- Die Verzögerung der Propagierung von Transaktionen: Je größer die Blöcke sind, desto länger brauchen sie, um im Netzwerk propagiert zu werden. Auch hier fallen Hochrechnungen nicht eindeutig aus, aber es könnte sein, dass zum Beispiel 8 MB große Blöcke die Dauer so erheblich verlängern, dass Miner Gefahr laufen, mehr verwaiste Blöcke zu erzeugen, da sie „auf der falschen / alten Blockchain“ minen. Dies könnte die schwächeren Miner vom Markt verdrängen und die bereits bestehende ungünstige Zentralisierung des Minings weiter verschärfen oder gar den Angriff des „egoistischen Minings“ einfacher machen.
Für die Kernentwickler geht es vor allem darum, das System sicher und dezentral zu halten. Daher wollen sie konservative, vorsichtige Forks, mit der Option, im Falle des Erfolges später noch nachzujustieren, anstatt das System einen Risiko auszusetzen, um ein Problem auszumerzen, dass es so noch gar nicht gibt. Bei derzeit gut 100.000 Transaktionen am Tag ist eine zarte Erhöhung der Blocksize zwar angebracht, aber eine Verachtfachung ist noch nicht im Ansatz notwendig. „Wenn Bitcoin sehr groß skalieren muss, um erfolgreich zu sein, dann ist es bereits gescheitert“, wie es Pieter Wuille sagte. Wie einige andere Kernentwickler setzt er darauf, dass Bitcoin an sich sicher bleibt, während man die „totale Skalierbarkeit“ durch weitere Dienstleister wie Changetip oder Coinbase sowie Protokoll-Überschichten wie Lightning oder Sidechains erreicht. Der Bitcoin würde damit weniger zum digitalen Bargeld als zum Settlement-Netzwerk für darüber geschaltete Protokolle und Unternehmen.
Jemand andreres antwortete, man habe es noch nicht mal versucht, Bitcoin zu skalieren. Für viele Nutzer überdies soll Bitcoin bleiben wie er ist, anstatt zum Settlement-Netzwerk zu werden. Denn zentrale Zahlungsdienstleister gibt es schon genug.
Anders gesagt: die Diskussion wird uns wohl noch eine ganze Weile begleiten. Denn die Frage nach der Blockgröße ist nicht rein technologisch, sondern idealistisch. Es geht darum, was der Bitcoin sein soll.
Ich bin für Bip100 oder 103
ne Abstimmung hier wäre mal nicht verkehrt 😉
mfg
Danke für den Artikel, hat auch meinen Horizont wieder erweitert.
Da die notwendige Grösse der Blöcke für die Zukunft nicht vorhersehbar ist, wird es mir bei allen vorliegenden Vorschlägen etwas mulmig. Ausser BIP102 welcher das Problem etwas in die Zukunft schiebt. Liese sich die Blockgrösse nicht dynamisch erhöhen, angepasst an die jeweils gegenwärtigen Anforderungen?
Zum Beispiel:
Wenn die Durchschnittliche Grösse der Blöcke über einen definierten Zeitraum von z.B. 3 Monaten grösser als 0,8 MB ist, soll die Blockgrösse auf 2 MB steigen. Wenn die Durchschnittliche Grösse der Blöcke über diesen Zeitraum grösser als 1,8 MB ist, soll die Blockgrösse auf 3 MB steigen etc etc. So würde das Limit stetig den Anforderungen entsprechend hochgesetzt und es bräuchte sehr lang anhaltende Spam-Attacken um die Blockgrösse sinnlos in die Höhe zu treiben sowie die benötigte Bandbreite unnötig zu erhöhen.
So würde man dem Settlement-Netzwerk keinen Vorschub leisten, es aber auch nicht an seiner Entwicklung hindern. Ich denke es hat alles irgendwie seinen Platz.
Was sagt eigentlich Satoshi Nakamoto dazu?
http://www.industrytap.com/wp-content/uploads/2014/03/Satoshi-Nakamoto-AP-e1394636850521.jpg
Kann den nicht mal einer fragen? Der hat das bis jetzt ganz gut gemacht…
Satoshi hat es meist selbstregulierend gelöst… z.B. Difficulty, oder Mining Reward
Vorschlag BIP101 ergibt meiner Meinung nach den meisten Sinn bzw. ist am zukunftsträchtigsten, weil es …
1. nicht so kompliziert wie andere Vorschläge ist
2. weil es sich an den Moorschen Gesetzmäßigkeiten orientiert
3. weil es nur ein mal eine Zustimmung von 75% benötigt
Vorschlag BIP102 kann man quasi in die Tonne treten, ist sozusagen gar keine Lösung.
BIP100 wird bereits an den 90% scheitern, worauf der Ideengeber sicherlich auch baut bzw. spekuliert. D.h. er macht einen durchaus plausiblen Vorschlag, baut dann aber mit den 90% eine unüberwindbare Hürde ein.
90% ergibt auch gar keinen Sinn, denn in einer Demokratie müssen auch keine 90% zustimmen. Selbst 75% halte ich schon für ambitioniert.
Einzig BIP103 wäre durchaus eine Überlegung wert, wenn da nicht wieder so eine unüberwindbare Hürde wäre. So würde die Bandbreite frühestens im April 2017 angehoben und dann auch nur in vernachlässigbarer Höhe.
D.h. wir würden weitere fast 2 Jahre mit dem 1MB leben müssen.
Wenn man sich die Anzahl der Transaktionen anschaut, welche allein in den letzten 12 Monaten von 75.000 auf 120.000 gestiegen war, so werden wir bereits in einem Jahr permanent auf das Maximum bei 200.000 laufen. D.h. im Klartext, dass wir etwa 1 Jahr permanent am Limit laufen und eine zunehmende Zahl von Transaktionen gar nicht mehr ausgeführt werden wird. Die Gebühren werden dann logischerweise deutlich steigen und eine Vielzahl von Applikationen nicht mehr rentabel und würden vermutlich auf Altcoins ausweichen und abwandern.
Nachdem ich das Papier zu BIP 100 nun doch noch gelesen habe (meine Englischkenntnisse sind beschränkt), sehe ich erst was für ein Sprengkraft die Blocksize-Debatte überhaupt hat. Falls wir in Bitcoin eine globale dezentrale Währung sehen welche unabhängig vom Treiben der Banken und Zentralbanken einen sicheren Hafen für das Geld von Menschen weltweit sein soll und gleichzeitig das Problem von Menschen ohne Bankkonto lösen kann, frage ich mich was um Himmels Willen hat die Nasdaq auf der Bitcoin-Blockchain verloren? Mit Millionen täglicher Transaktionen würde sie die Blockchain vollmüllen zu einem Zweck welcher der Idee von Bitcoin diamentral widerspricht! Verhindern kann man dies mit Blöcken die für solchen „Spam“ zu klein aber trotzdem gross genug für „normale Transaktionen“ sind. Eine langsam wachsende Blockgrösse sehe ich mittlerweile als den einzig richtigen Weg. Ich kann nur jedem empfehlen das Papier von Jeff Garzik (BIP 100) zu lesen. Die Zusammenhänge zwischen Blockgrösse und „was ist Bitcoin?“ sind wirklich spannend.
Das Problem ist, dass viele Leute, wie u.a. auch ein Jeff Garzik gar nicht verstehen, welch Tragweite die Bitcoin-Blockchain automatisch mit sich bringt.
Man geht immer noch mit der Maßgabe heran, mit Bitcoin ein alternatives Bezahlungssystem zu haben. Bitcoin aber ist viel mehr als das und das Bezahlsystem ist nur ein Teil des Bitcoin aber eben nicht der einzige Teil.
Da das System offen ist, kann man die Verwendung nur bedingt limitieren, z.B. indem man eine Mindestgebühr einführen würde.
Ich selbst wäre durchaus dafür, eine solche Gebühr einzuführen um den SPAM teuer zu machen.
Wiederum sollte die Gebühr nicht zu hoch liegen, weil man ja gerade wegen niedriger Gebühren eine Alternative zum Bankentransfer hat, weil vor allem Micropayment, Minispenden, Abo in Centhöhe eine der Stärken des Bitcoin darstellt.
Daher bin ich der Meinung, dass Gavin die Tragweite bislang am besten erkennt und auch die besten Vorschläge bringt.
Damit Bitcoin als Zahlungsmittel existieren kann reicht die Blockgröße völlig.
Ist durch dificulty/mining-Reward und Transaction fee eigentlich selbstregulierend.
Micropayment anbieter sind meiner Meinung nach sogar was gutes, da sie den Nutzerkreis vergrößern. Ich sehe da erstmal keinen Handlungsbedarf. Zumal Sicherheit das höchste Gut bei Bitcoin ist.
Nein, die Blockgröße reicht eben nicht und wird bereits in etwa einem Jahr permanent am Limit laufen, sofern wir (nur) von einem stetigen Wachstum ausgehen.
Würde Beispielsweise der Bitcoin erneut in einen Hype münden, so wäre das Limit binnen kürzester Zeit erreicht.
Die Konsequenz daraus wären sich auftürmende Warteschlangen und eskalierenden Wartezeiten.
Danke für diese schön zusammengestellte Zusammenfassung. Schwanke zwischen 100 & 103.
Das Voting unter den Minern läuft nun
https://www.blocktrail.com/BTC/pools?resolution=24h
Es scheint sich der Vorschlag BIP100 allmälig herauszukristallisieren.
Was mir bis vor Kurzem etwas unklar war ist der Mechanismus, welcher dahinter steht um eine Anpassung der Blockgröße mit Faktor 0,5 bis 2 zu erreichen.
U.a. ist da von 90% Zustimmung die Rede. Da ging ich bislang davon aus, dass alle Miner entsprechend einer bestimmten Veränderung zustimmen müssen. Dies erschien mir stets unrealistisch.
Doch wie ich nun verstanden habe geht man dabei wiefolgt vor.
Beispiel:
10% stimmen für die Beibehaltung der Blockgröße
20% stimmen für 1,5MB
70% stimmen für 2MB
So werden 90% bei 1,5MB erreicht. Man zählt sozusagen von oben nach unten.
Wie ich weiter erfahren habe, soll ab 1.Sept. der BIP100 im Testnet anlaufen.
So wie es aussieht läuft es auf die Umsetzung des BIP100 hinaus.
BIP101 sowie BitcoinXT dürfte damit vermutlich vorerst nicht realisierbar sein bzw. werden. Ich kann mir nicht vorstellen, dass Gavin bei einer mehrheitlichen Zustimmung für BIP100 einen eigenen Weg weitergehen wird. Vielmehr gehe ich davon aus, dass er dem BIP100 wird folgen.
Eines kann man aber definitiv feststellen, dass mit der Androhung der Aufspaltung in BitcoinXT die Sache erst so richtig ins Rollen gekommen ist und sich die Beteiligten, d.h. Miner sowie Entwickler intensivst mit der Thematik auseinandersetzen MUSSTEN.
U.a. gab es neben den Vorschlägen der Entwickler auch den Vorschlag seitens diverser Miner, die Blockgröße auf 8MB zu erhöhen und später ggf. durch weitere Forks manuell erneut zu erhöhen.
Aber wie sich die letzten Tage zeigt, hat man sich zum BIP100 verständigen können.
Die 50% mehrheitlicher Zustimmung zum BIP100 erscheint daher nur noch eine Frage von wenigen Wochen.
Es ist schon sehr spannend diese vergleichsweise demokratischen Prozesse mitzuverfolgen mit all den Turbulenzen und Spannungen. Es ist aber auch spannend zu sehen, wie open-source diese Prozesse förmlich erzwingt und eben kein Kernentwicklerteam unantastbar ist.
Ich habe einen eigenen Vorschlag:
Man passt die maximale Blockgröße anhand der Auslastung zyklisch an, wie es jetzt schon mit der Schwierigkeit geschieht. Man könnte z.B. all 2016 Blöcke zeitgleich mit der Anpassung der Schwierigkeit ermitteln, welche Blockgröße nun für die nächsten 2016 Blöcke gilt.
Man könnte diese mathematisch aus den letzten 2016 Blöcken ermitteln (z.B. 120 % der durchschnittlichen letzten BlockGröße). So können auch die Miner zumindest bei hohen Auslastungen durch temporär viele Transaktionen von dann höheren Fees profitieren, aber das Netzwerk bleibt stabil und es besteht eine gute Chance das alle Transaktionen nach und nach doch abgearbeitet werden können.
Ich find die Teilung in Bitcoin Cash und BTC eigentlich recht schlau gelöst jetzt. vll. wäre der Weg in der Zukunft einfach immer ein neuer Branch anstatt diese ewigen Diskussionen. Am Ende setzt sich das durch was sicherer / schneller ist.