Eines der Hauptargumente dafür, die Blockgröße in Bitcoin nicht zu erhöhen, ist die Tatsache, dass eine größere Blockgröße eine langsamere Ausbreitung bedeutet.
Der platzintensivste Abschnitt des Bitcoin-Blocks sind die Daten der Transaktionen. Unter der Annahme, dass ein großer Teil der Knoten Vollknoten sind, gibt es eine große Redundanz in den Blockdaten.
Wenn ein Miner einen Block erfolgreich abgebaut hat, muss er ihn an die anderen Knoten im Netzwerk senden. Viele dieser Knoten besitzen bereits die meisten Transaktionsdaten, die im Block enthalten sind.
Vielleicht ist es besser, statt der Daten selbst einen Hash jeder Transaktion zu senden. Falls der empfangende Knoten diese Daten nicht hat, kann er sie vom sendenden Knoten anfordern.
Dies kann die Größe eines Blocks um das 5- bis 10-fache komprimieren (abhängig von der Größe des Hashs) und eine deutlich größere Blockgröße ermöglichen.
Meine Sorge wäre, dass in dem Fall, in dem der Empfänger nicht über alle Transaktionen verfügt, die zusätzlichen Anforderungen, um sie zu erhalten, am Ende mehr Zeit in Anspruch nehmen würden, als sie überhaupt erst zu senden. Bergleute sind auf der ganzen Welt verstreut, können aber wahrscheinlich für schnelle Verbindungen bezahlen, daher würde ich erwarten, dass Verbindungen zwischen ihnen eine hohe Latenz und eine hohe Bandbreite aufweisen. In einem solchen Fall ist es besser, präventiv eine größere Datenmenge zu senden (schnell wegen hoher Bandbreite), als einen Anfrage-/Antwort-Roundtrip zu riskieren (langsam wegen hoher Latenz).
Außerdem schließen Miner ziemlich oft Transaktionen ein, die sie selbst erstellt haben oder die ihnen privat gesendet wurden oder die auf andere Weise nicht im Peer-to-Peer-Netzwerk übertragen wurden. Betrachten Sie Auszahlungen aus Mining-Pools, nicht standardmäßige Transaktionen, Transaktionen mit niedrigen Gebühren, denen der Miner zugestimmt hat, sie zu „beschleunigen“, usw. Ich denke also, dass dieses zusätzliche Anforderungsprotokoll häufiger benötigt wird als nicht.
Dies könnte eine sinnvolle Optimierung für Full Nodes sein, die keine Miner sind und daher den Block nicht dringend erhalten müssen. Sie könnten auf diese Weise etwas Bandbreite sparen. Aber auf der anderen Seite, da sie den Block nicht dringend erhalten müssen, kümmern wir uns nicht so sehr um sie, und es ist schwer, eine größere p2p-Protokolländerung nur dafür zu rechtfertigen.
Ich bin mir nicht sicher, warum dies zuvor nicht vollständiger beantwortet wurde.
Bitcoin hat seit einigen Jahren nicht mehr den vollständigen Block als primäre Ausbreitungsmethode gesendet, siehe BIP 152 . Was gesendet wird, ist der Blockheader, 6 Bytes pro Transaktion und die Coinbase-Transaktion. Optional können zusätzliche Transaktionen gesendet werden, von denen der Sender vorhergesagt hat, dass der Empfänger sie nicht kennen wird.
Der sehr kurze Hash ist möglich, da der Hash von jedem sendenden Knoten unterschiedlich gesalzen wird. Dies macht es einem Angreifer unmöglich, absichtlich Kollisionen zu erzeugen, und alle zufällig auftretenden Kollisionen werden bei der Netzwerkausbreitung „umgeleitet“, da Blöcke einfach schneller auf Links fließen, auf denen keine Kollision stattgefunden hat.
Da diese Nachricht so klein ist, ist BIP152 in der Lage, häufig einen Roundtrip zu eliminieren, indem kein INV durchgeführt wird. Die Tatsache, dass manchmal ein zusätzlicher Roundtrip erforderlich ist, um fehlende Transaktionen auszufüllen, lässt nur die gleiche Anzahl von Roundtrips wie das ursprüngliche Protokoll übrig.
Es gibt auch Glasfaser , die die Übertragung bedingungslos auf 0,5 Roundtrips reduziert, jedoch auf Kosten einer beträchtlichen Bandbreitenverschwendung. Für schnelle Verbindungen ist dies das schnellste, was zu tun ist.
Für die Belange der Netzwerksicherheit und -stabilität ist es nicht nur eine Frage, wie langsam die Ausbreitung im Durchschnitt ist, sondern wie langsam sie von einem Miner im ersten Fall gemacht werden kann. BIP152 leistet im Durchschnitt gute Arbeit, verbessert aber im schlimmsten Fall nicht wirklich. Auch die Datenmenge in einem Block steuert auch die Datenmenge außerhalb von Blöcken, höchstens können kompakte Blöcke die Gesamtbandbreite eines Knotens nur auf reduzieren die Hälfte über dem ursprünglichen Schema.
Das Design von BIP152 wurde als Kompromiss zwischen vielen Faktoren ausgewählt – Latenz, Bandbreite, Rechenlast, Implementierungskomplexität. Glasfaser stellt einen anderen Kompromiss dar (bevorzugt die absolut niedrigste Verzögerung anstelle von weniger Bandbreite). Wir wissen, wie man Blöcke typischerweise auf etwa 500 Byte reduziert, mit erheblich mehr Implementierungskomplexität und Berechnung, aber es scheint nicht so, als gäbe es im Vergleich zur Wichtigkeit, andere Bereiche des Protokolls zu verbessern, viel Grund dazu. Dies gilt in doppelter Hinsicht, da diese Verbesserungen im schlimmsten Fall nicht helfen. Ich glaube, dass FIBER bereits sehr nahe an der bestmöglichen Worst-Case-Performance liegt.