Riesig: Bitcoin SV bildet 103-Megabyte-Block
Orange Cube, Lyon. Bild von Anthony via flickr.com. Lizenz: Creative Commons
Bitcoin SV ist weiter auf Rekordjagd. Nachdem die Miner schon kurz nach der Hard Fork im November mit einem Block mit einer Größe von 64 Megabyte eine neue Höchstmarke für dezentrale Blockchains gesetzt haben, legen sie nun nach.
Begonnen hat dieser Rekordversuch schon an Weihnachten. Der chinesische Mining-Pool Mempool hat am 26. Dezember einen Block mit einer Größe von 80 Megabyte erzeugt. Der toppte zwar den bisherigen Rekordblock von 64 Megabyte, den der Pool CoinGeek unmittelbar nach der Hardfork am 15. November gebildet hatte – aber er blieb unter den Erwartungen. Schließlich hatte Calvin Ayre von CoinGeek kurz vorher getweetet, dass er hoffe, noch im Jahr 2018 einen 128-Megabyte-Block zu sehen. Dieser würde die volle Kapazität von Bitcoin SV ausreizen.
We hope to mine a 128 MB block before the end of the year….spread this far and wide…#Bitcoin is back and open for business as #BSV:https://t.co/d1WdTJ8Fhf
— Calvin Ayre (@CalvinAyre) December 18, 2018
Dann kam Sylvester, und das Jahr ging ohne neuen Monsterblock zu Ende. Am dritten Januar hat Mempool dann weiter an den Megablöcken gearbeitet. Das Ziel war es, mehr als 100 Megabyte zu schaffen. Ein erster Versuch ging schief. Mempool bildete den Block zwar, und gab ihn an einige andere Knoten weiter – doch noch bevor er überall ankam, hatte Coingeek einen anderen, kleineren Block erzeugt, der sich schneller im Netzwerk ausbreitete. Mempools 100-Megabyte-Block wurde verwaist.
Waisenkinder und Bandbreite
Eigentlich ist es ganz einfach: Je größer der Block, desto länger dauert es, ihn an die anderen Miner zu übertragen, und desto größer wird die Gefahr, dass diese einen alternativen Block finden, bevor der eigentliche Block ankommt. Um große Blöcke zu minen, muss ein Miner gut vernetzt sein und die notwendige Bandbreite haben, damit er seinen Block schnell an die anderen Knoten im Netzwerk hochladen kann. Der Mechanismus der Verwaisten Blöcke (englisch: orphans) verhindert so auch, dass ein bösartiger Miner das Netzwerk dauerhaft mit Blöcken zukleistert, die zu groß sind, um verarbeitet zu werden.
Auch ein zweiter Anlauf von Mempool schlug fehl. Der Block wurde wieder verwaist. Der Pool rüstete seine Bandbreite auf und vernetzte sich besser mit den anderen wichtigen Knoten. Dann probierte er es erneut – und schaffte es. Block 563638 setzte sich durch und wurde zum Teil der Blockchain. Er ist 103 Megabyte schwer und enthält 460.400 Transaktionen.
Block 563.638 auf Blockchair.org
Zum Vergleich: Ein Bitcoin-Block ist nur 1-1,5 Megabyte groß, am Tag wächst die Blockchain um etwa 160 Megabyte und prozessiert gut 300.000 Transaktionen. Man könnte sagen, in den Block von MemPool passen etwa zwei Drittel eines Bitcoin-Tages. Für eine dezentrale Blockchain ist das ein absoluter Rekord. Man könnte meinen, dass sei für jeden Big Blocker ein Erfolg.
„Aber das ist ja gar nicht echt.“
Die Bitcoin-SV-Szene feiert Block 563638, natürlich. Sie handelt ihn als Beweis, dass Bitcoin SV die einzige Blockchain sei, die beweist, dass sie skalieren kann. Dagegen notiert die Bitcoin-Cash-Community (BCH) den Block mit Skepsis. Kein Wunder: Bitcoin Cash (BCH) hat sich bei der November Hardfork dafür entschieden, das Blocksize-Limit bei 32 Megabyte zu halten, anstatt es wie Bitcoin SV auf 128 Megabyte zu erhöhen.
Eine einmalige Spitzenbelastung, heißt es also, bedeute nicht viel. Viel wichtiger sei es, wie viel das Netzwerk im Durchschnitt aushält. Zudem sei der Block nicht echt gewesen, da er nicht aus Transaktionen im Pool der unbestätigten Transaktionen komme, sondern durch eigene Transaktionen von Mempool fabriziert worden sei. Daher sage er auch nichts darüber aus, ob solche Blöcke unter echten Bedingungen möglich sind.
Natürlich ist da etwas dran. Interessanter als ein Test der einmaligen Spitzenbelastung wäre es, eine Serie so großer Blöcke zu beobachten. Und es stimmt auch, dass Mempool den Block mit selbstgebastelten Transaktionen gefüllt hat. Der Admin des Pools hat daraus kein Geheimnis gemacht. Er erklärte, man wolle Flaschenhälse testen.
Und dies hat seinen Wert. Der Test zeigt, dass das Netzwerk in der Lage ist, eine Spitzenbelastung von Blöcken mit 103 Megabyte zu meistern. Auch konnte der Block recht zügig zu den anderen Minern und Knoten ausgeliefert werden: Der nächste Block wurde nur gut drei Minuten später gefunden, einige Nodes berichten, dass sie etwa 40 Sekunden gebraucht haben, um ihn zu empfangen. Das ist, an sich, ok. Das Netzwerk kommt mit diesem hohen Durchfluss klar.
Der Flaschenhals der Block-Propagierung ist offenbar nicht so eng, wie es manchmal dargestellt wird. Er ist nur einer von vielen anderen Faktoren – die Aufnahme von Transaktionen in den MemPool, die Dauer der initialen Synchronisierung von Nodes, der Festplattenverbrauch und so weiter – aber es ist interessant, auszuloten, wie weit es hier geht.
103 MB, aber leider nur 99 MiB 🙂
Danke fuer den Artikel. Etwas „richtiger“ wird die Meldung wenn man „grosse Miner“, bzw. „Miningpools“ schreibt. Denn kleine Miner werden sich diese Bandbreite nicht leisten koennen; nur die grossen Miner sind gut miteinander vernetzt wie der Artikel richtig beschreibt. Das fuehrt natuerlich zu mehr Zentralitaet, was nicht wuenschenswert ist. Satoshi hatte Mining Pools und ASICs einfach nicht vorhergesehen.
Korrekt, aber „kleine“ Miner gibt es bei Bitcoin leider seit Jahren nicht mehr, da sich das „Geschäft“ spätestens mit ASICs professionalisiert hat und wer sich solche spezialisierte Hardware leisten kann, sollte auch fähig sein, für eine gute Netzanbindung zu sorgen, zumal diese nicht mehr die Welt kostet. Deutschland ist da leider Entwicklungsland, aber in der Schweiz bekommt man selbst als Privatperson 1Gbit/s Full-Duplex Glasfaser (init7, vtx) für unter 100 Fränkli und in Glasfaser in den Bergen zu verlegen dürfte komplizierter sein als im relativ flachen Deutschland, in den meisten EU-Ländern bekommt man ein Vielfaches des Datenvolumens per LTE für weniger Geld als in Deutschland und wir haben immer noch etliche Funklöcher, obwohl man davon ausgehen könnte, dass die Netze solide finanziert sind.
Ich bin nicht der Ansicht, dass größere Blöcke zwingend zu mehr Zentralisierung führen als wir sie schon jetzt haben. Wenn das allerdings reibungslos funktionieren soll, brauchen wir mehr Professionalisierung der Pools (und das sind ja nur eine Handvoll), denn das oben genannte Beispiel zeugt eher von Unfähigkeit wie unten ausgeführt.
Das ist wahrscheinlich auch der Grund für die Orphans zuvor, denn mit Thin Blocks / Xthin / Compact Blocks sollte die Propagation eines Blocks mit Transaktionen aus dem Mempool trotz der Größe ziemlich fix gehen und die drei Anläufe von MemPool sind eigentlich der Gegenbeweis, dass so große Blöcke tatsächlich sinnvoll sind und wirkt ziemlich unprofessionell / schlecht vorbereitet. Wenn man das schon im Mainnet testen will, hätte man sich eine entsprechende Bandbreite zulegen sollen oder von mehreren Nodes entsprechend mehrere hundert Megabyte an (im Voraus signierten) Transaktionen im Netz propagieren müssen und dann tatsächlich daraus einen Block minen, allerdings wäre dies wahrscheinlich nicht MemPool mit ihren wenigen Prozent und die PR wäre nicht ihnen „zugute“ gekommen. Die vorherigen Orphans waren eventuell auch ein politisches Statement der anderen Miner / Pools, die diese künstlich aufgeblähten Blöcke mit unbekannten Transaktionen nicht aus dem Mempool schlichtweg abgelehnt haben (obwohl dafür eher zu wenig Zeit vorhanden war und wahrscheinlich die fehlende Propagation verantwortlich war). Interessant wäre noch zu erfahren, wie aufwendig nicht die Generierung sondern die Verifizierung eines solchen Blocks auf gängiger Hardware ist, denn bei Bitcoin skaliert diese afaik nicht linear. Habe leider keinen Bitcoin Fullnode, geschweige denn einen der Forks… Ein Miner muss einen Block und alle Transaktionen bzw. deren Signaturen einzeln verifizieren, bevor er darauf aufbauend versucht, den nächsten Block zu minen. Theoretisch reicht alleine der Block-Header, um einen neuen Block darauf aufbauend zu minen, allerdings basiert die Annahme dann auf Vertrauen, die andere Miner dem relativ unbedeutenden MemPool scheinbar nicht gegeben haben und da die Transaktionen zuvor nicht propagiert wurden und nicht im Voraus geprüft werden konnten, sind bereits Timings im Millisekundenbereich pro Transaktion bei knapp 500 Tausend durchaus ein Zeitfaktor. Womöglich war sogar die für Lesezugriffe ziemlich schlecht performende LevelDB, die Bitcoin und seine Forks für die Blockchain nutzen und die eigentlich für Schreibzugriffe optimiert wurde (was bei einer Blockchain oder den meisten Datenbankanwendungen eher die Ausnahme sind) statt für Leseoperationen. Monero nutzt dafür (mehr oder weniger exklusiv) eine Weiterentwicklung von LMDB, die zwar beim Platzbedarf etwas Overhead hat, aber Leseoptionen dafür deutlich schneller verarbeiten kann. Seit Monero vor ca. zwei Jahren zu LMDB gewechselt ist, ist der Entwickler Howard Chu, besser bekannt als hyc (symas) übrigens ein Core Entwickler bei Monero geworden und selbst sehr aktiv. Wohlgemerkt ohne Vergütung, ganz nach dem Open Source Gedanken.
Technisch sind große Blöcke für Mining-Pools durchaus machbar, seriöse Serverinfrastrukturen haben heutzutage mindestens 1Gbit/s, oft 3Gbit/s oder gar 10Gbit/s (gegen saftigen Aufpreis geht auch mehr). Selbst eine 1Gbit/s Leitung schafft in der Theorie 128MB Übertragung pro Sekunde und Kanal (full-duplex also up&down gleichzeitig). Wenn man seinen Mining Pool also nicht bei einem Tier4 oder 5 Wohnzimmerhoster unterbringt, kann man 100MB Blöcke selbst ohne Thin Blocks durchaus im Netzwerk propagieren. Die Optimierungen durch Thin Blocks bringen jedoch erheblichen Overhead, wenn die Transaktionen nicht im Mempool anderer Teilnehmer sind, denn diese werden dann einzeln abgefragt. Dann wäre eine Propagation des gesamten Blocks als eine große Datei viel sinnvoller.
Fazit: Die MemPool Betreiber haben sich scheinbar von der PR Abteilung leiten lassen und die technischen Aspekte mit Scheuklappen und Händen vor den Augen komplett ausgeblendet und damit eigentlich ihre eigene Unfähigkeit bewiesen (auch wenn der Block beim Dritten Anlauf durchgekommen ist), denn Orphans sollten eher eine ganz seltene Ausnahme bleiben. Ob das SV gut tut? Eher nicht, wenn es noch etwas gibt, was man beschädigen könnte. Die beiden gesplitteten Chains sind mit ihrer so abgeschlagenen Hashrate zu Bitcoin trotz gleichen Algorithmus ohnehin nicht sicher und potenzielle Orphaned Blocks werden die Alarmglocken bei Börsen und Merchants aufleuchten lassen und dann muss man eben auf 10 oder 20 Bestätigungen warten, bis eine Transaktion durch ist. Dass dies anders geht, zeigt z.B. wieder Mal Monero und 0-Confirmation Transaktionen sind eigentlich kein Thema, selbst einer der größten Dienstleister xmr.to akzeptiert diese bis zu einem Betrag von 0.1 BTC und schickt die Bitcoins sofort aus dem Hot-Wallet raus, alles darüber (bis 20 BTC) erfordert EINE Bestätigung im Netzwerk (bei einer Blocktime bei Monero von 2 Minuten). Wird übrigens von dem Gründer von Luckybit betrieben, der sich vor Jahren über die Miner Zensur auf der (Bitcoin) Blockchain geärgert hat: https://moneromonitor.com/episodes/2017-04-24-Episode-003.html
Ich habe mal eine Frage an Paul Janowitz. Es soll nicht vorwurfsvoll klingen oder wertend. Aber schaffst du es auch mal Beiträge zu schreiben ohne am Ende bei Monero zu landen? Eigentlich lese ich sehr gerne deine Kommentare. Aber Monero hier und Monero da nervt. Irgendwann.
Das „Problem“ ist, dass ich seit 2012 eher Bitcoin Maximalist war und mittlerweile nach den mir irgendwann unverständlichen Auseinandersetzungen um Blocksize irgendwann auf Monero gestoßen bin und dort immer noch keinen Nachteil gefunden habe, wie bei fast allen Coins mit denen ich mich befasst habe. Dafür musste ich mich sogar eingehend mit dem Code befassen, was bei den meisten Projekten nicht nötig ist, um sie bereits abzuschreiben. Bei vielen Kommentaren in der letzten Zeit habe ich mich mit Monero übrigens zurückgehalten, obwohl es fast bei jedem möglich ist, Parallelen oder eben andere Lösungsansätze im Vergleich zu Bitcoin zu ziehen.
Kurz und bündig: Hätte ich Monero nicht gefunden, würde ich mich wohl gar nicht mehr mit Bitcoin oder Kryptowährungen befassen. Ich sehe darin tatsächlich das (vorhanden oder in Entwicklung), was ich früher von Bitcoin erwartet habe. Für mich ist Bitcoin und Monero tatsächlich primär ein besseres Geldsystem und wenn wir das nicht erstmal tatsächlich hinbekommen, sind andere Anwendungen mit „Smart“-Contracts sehr abgehoben und in meinen Augen noch nicht sinnvoll.
Auch Monero hat seine Schwächen und aktuell gibt es z.B. eine kleine Krise rund um die I2P Router Implementierung „Kovri“, aber die Community geht mit solchen Dingen ziemlich offen um und irgendwie findet sich meistens eine Lösung. Das vermisse ich mittlerweile bei Bitcoin, da fast jede Diskussion toxisch endet. Interessant ist auch z.B. ein Statement des VideoLAN (VLC) Gründers, dessen Open Source Player für jedes Urgestein ein Inbegriff sein sollte und die erste tatsächliche Lösung geboten hat, um den Codec Wahnsinn in den Griff zu bekommen und bis heute seit mehr als 10 Jahren mein Player der Wahl geblieben ist… https://blog.l0cal.com/2017/12/14/update-on-crypto-currency-donations-at-videolan/
Hmm … ich verstehe deine Aussage, „MemPool ist unprofessionell, und Monero ist besser“, aber ich verstehe den Grund nicht. Weil sie mehrere Anläufe gebraucht haben, um den 103mb-Block auf die Kette zu bringen? Meiner Meinung nach ist die Bereitschaft, ein (überschaubares) Risiko einzugehen, lobenswert, und es ist ein Teil des Immunsystems einer Blockchain, dass es schwierig ist, große Blöcke zu bilden.
Die Vorbereitung halte ich für unprofessionell, nicht die Bildung eines großen Blocks an sich und das hätte man (wie ich ausgeführt habe) imho viel besser vorbereiten können, ohne zwei Orphaned zuvor zu generieren, denn man hat eher in meinen Augen nicht gravierende Limits aufgezeigt, aber für Außenstehende eben doch eine scheinbar nicht zu unterschätzende Limitierung aufgezeigt.
Analog dazu: Wenn ich einen Geschwindigkeitsrekord mit einem Fahrzeug vorbereiten will, werde ich mich wahrscheinlich um eine geeignete Location (Salzwüste oder ähnliches) kümmern, den Reifendruck und deren Beschaffenheit penibel kontrollieren und mich sogar zeitlich den Wetterverhältnissen anpassen (und gefühlt tausend andere Dinge). All dies hat MemPool scheinbar zumindest bei den ersten beiden Versuchen nicht gemacht und ich wage zu behaupten auch beim dritten nicht (da z.b. die Transaktionen nicht zuvor propagiert wurden) und dieser ist nur mit Glück durch einen nächsten Block bestätigt worden. Drei Anläufe für einen Erfolg ist eine Quote von 33% und für keine Blockchain in meinen Augen irgendwo in der Toleranz. Selbst ein Prozent Orphaned Blocks sind unter Umständen schon problematisch…
Dass Monero viele der Nachteile Bitcoins bereits gelöst hat, ist eine andere Geschichte und ich bin mir auch nicht sicher, ob das Netzwerk z.B. einen (oder mehrere) 100MB oder 20MB Block da 1/5 Blocktime problemlos verarbeiten würde. Allerdings ist die sehr moderate Steigerungsmöglichkeit der Blocksize für Miner von dem unteren Limit 300KB sehr beschränkt und damit ist die Orphan-Rate wahrscheinlich deutlich geringer, da Nodes nicht von 100KB in einem auf 100MB im nächsten Block skalieren müssen.
Ich wäre sogar für einen Stress-Test der dynamischen Blocksize im Mainnet, aber da bin ich leider noch isoliert, da ist die Bitcoin Cash Fraktion offener / bereiter. Man braucht dafür bei Monero auch mehr als nur einen Miner / Pool, der das beschließt und müsste das Netzwerk tatsächlich erstmal mit Unmengen an Transaktionen fluten. Könnte man eigentlich Mal organisieren, vor allem bei aktuellen Transaktionskosten von unter 1 Cent…
> Die Vorbereitung halte ich für unprofessionell, nicht die Bildung eines großen Blocks an sich und das hätte man (wie ich ausgeführt habe) imho viel besser vorbereiten können, ohne zwei Orphaned zuvor zu generieren, denn man hat eher in meinen Augen nicht gravierende Limits aufgezeigt, aber für Außenstehende eben doch eine scheinbar nicht zu unterschätzende Limitierung aufgezeigt.
Aber darum geht es doch. Tests, bei denen man schon zuvor weiß, was passiert, sind uninteressant. Die Erkenntnis war, dass Blöcke von 100 mb verwaisen, wenn der Miner nicht extrem gut vernetzt ist und eine mächtige Bandbreite hat.
In meinen Augen eben nicht, da mit Thin-Blöcken (oder wie die einzelnen Technologien, die das gleiche bezwecken und ich nicht sicher bin, welche bei SV oder selbst Bitcoin aktuell genutzt wird, Fluffy-Blocks sind es nicht) die Bandbreite bei der eigentlichen Block-Propagation eher zur Nebensache wird und sich auf die Zeit zwischen den Blöcken verteilt. Wenn man aber bei einer solchen aktivierten Optimierung aufbauend auf einem Mempool einen Block erstellt, dessen Transaktionen niemand anders kennt und das dann auch noch zu Hunderttausenden, mutiert die Optimierung leider zum Gegenteil. Generell gibt es bei einer „normalen“ Netzwerkauslastung keinen Grund, die Transaktionsdetails doppelt zu synchronisieren, bei der ursprünglichen Veröffentlichung im Mempool und dann nochmal im Block. In einem gesunden Netzwerk reicht je nach Technologie dazu eine ID oder ein Hash pro Transaktion, da sie eigentlich jeder im Mempool haben sollte und wenn nicht, fragt er diese eben per ID oder Hash nochmal ab. Wenn ein Miner wie MemPool jetzt aber einen Block generiert, dessen Hunderttausende Transaktionen niemandem außer ihm selber bekannt sind, vermute ich, dass die schiere Masse an Requests den Flaschenhals gebildet haben und nicht die Bandbreite an sich. Womöglich kann man diese Protokolle auch verbessern und bei z.B. über 10% tatsächlich den ganzen Block synchronisieren anstatt einzelner unbekannter Transaktionen, denn die Bandbreite für 100MB an sagen wir mal 100 (was imho schon viel ist) vernetzte Nodes zu verbreiten ist lediglich 10GB und relativ überschaubar. In Rechenzentren oder Upstream-Providern mit niedrigerem Tier wird zwar meist nach 95 Percentile der Netzauslastung abgerechnet, aber man kann im Schnitt von wenigen Euro pro TB Übertragung ausgehen.
Super Artikel und lesenswerter Kommentar @Paul
Der Block zeigt doch ganz gut, weshalb der Fork in BSV unnütz war:
Der 103 mb Block wird orphaned, da er nicht schnell genug durch das Netzwerk kommt. Man braucht da einfach neue Sachen wie Graphene oder Xthinner und kann den Code nicht ewig so lassen, wie es CSW möchte.
Die meisten Leute verstehen nicht, dass es gut ist, wenn (zu) große Blöcke verwaisen.
Genau deswegen wäre eine Art dynamische Blocksize wohl auch für Bitcoin und dessen Forks sinnvoll, denn Blockgrößenänderungen von 100KB zu 100MB sind scheinbar nicht stabil im Netzwerk. Wahrscheinlich schon, hätte man die Transaktionen zuvor propagiert, aber das ist nur (m)eine Annahme…
Bin mir nicht sicher. Dynamische Blocksizes sind ein fruchtbares Feld für Entwickler, um mit komplizierten Lösungen die Dinge komplizierter zu machen. Und sie machen Stresstests von Größen weit über dem Demand unmöglich.
Das ist eine berechtigte Befürchtung, aber man kann das tatsächlich sehr einfach implementieren, wie z.B. die erwiesen 1MB Blöcke als Basis und jeden Block darauf bei Bedarf um ein paar (sagen wir bis 10%) ansteigen lassen, da braucht man nicht Mal den Median oder Durchschnitt der letzten Blöcke, sondern einfach denjenigen, auf dem man aufbaut. Das ist viel simpler und weniger Anfällig für Störungen als z.B. Änderungen wie Segwit, Compact Blocks oder ähnliches.