Blockgröße abhängig von der Transaktionsanzahl

Darum geht es in der aktuellen Blockgrößendebatte und das schon seit über einem Jahr. Ich werde versuchen, das alles hier nicht zu wiederholen.

Deine Zahlen scheinen ungefähr richtig zu sein. Ob 600-MB-Blöcke in Ihrer Seitenkette möglich sind, hängt davon ab, wie Ihre Seitenkette funktionieren würde. Wenn Sie die Proof-of-Work-Sicherheit loswerden und es sich um Hardware in Rechenzentrumsqualität und Bandbreite zwischen den Parteien handelt, die einander bis zu einem gewissen Grad vertrauen, gibt es kein Problem. Es wäre wahrscheinlich auch in diesem Fall sinnvoll, die Blockzeit zu verringern, z. B. 60 MB alle 1 Minute. Tatsächlich würden Blöcke wahrscheinlich überhaupt keinen Sinn mehr machen, warum nicht einfach eine nur anhängende Datenbank mit einzelnen Transaktionen mit einigen Prüfsummen zur Sicherheit?

Sidechains können einige Eigenschaften tauschen, um andere Eigenschaften zu erhalten, was durchaus Sinn machen könnte. Im obigen Beispiel tauschen Sie dezentralisiert vertrauenswürdig gegen hohe Effizienz, aber vertrauenswürdig (Benutzer müssen Ihnen und einigen anderen beteiligten Parteien und der/den Regierung(en) vertrauen, und... ).

Bitcoin selbst hat als primäre Eigenschaft, dass es dezentralisiert ist. Unzensierbar, niedrige Eintrittsbarriere für Bergleute und für vollständige Knoten, Peer2Peer und all diese guten Dinge sind sehr eng mit dieser primären Eigenschaft verbunden und verflochten. 600 MB pro Block würden das alles komplett zerstören.

Das soll nicht heißen, dass es nicht viele viel coolere Tricks gibt, die Bitcoin im Ärmel hat. SegWit wird derzeit eingeführt und wird Blöcke für bestimmte Knoten kleiner und besser beschneidbar machen, während die effektive Blockgröße auf etwa 1,75 MB erhöht wird. Außerdem eröffnen sich Wege zu vielen weiteren coolen Effizienzverbesserungen, wie z. B. die deutliche Verkleinerung von Multi-Sig-Transaktionen.

Ein noch größerer Schritt wird mit bidirektionalen Zahlungskanälen und damit aufgebauten Netzwerken gemacht. Lightning Network ist der bekannteste Name in diesem Bereich. Die Idee ist, Hunderttausende (oder mehr Bestellungen) kleiner Transaktionen über Wochen oder Monate zwischenzuspeichern, ohne eine einzige in einen Block zu stecken. Nur ganz am Anfang beim Öffnen eines solchen Kanals und am Ende beim Schließen des Kanals landet eine Transaktion tatsächlich in einem Block. Die Organisation dieser Kanäle in einem Peer2Peer-Netzwerk ermöglicht es jedem, Geld über mehrere Hops zu senden und weiterzuleiten, sodass jeder jeden anderen bezahlen kann, ohne einem einzigen Knoten vertrauen zu müssen, und sogar echte sofortige und vertrauenswürdige Zahlungen erhält (kein Warten auf Blockbestätigungen erforderlich).

Beim Skalieren dreht man selten einfach an einem Regler, nur um ein vorhandenes Ding zu vergrößern. Clevere Lösungen haben eine viel größere Wirkung und bieten gleichzeitig bessere Kompromisse.

Entschuldigen Sie, dass ich Ihre genaue Frage, alle Auswirkungen der Umstellung auf eine große Blockgröße aufzulisten, nicht beantwortet habe. Sie sind zahlreich und jeder kann zu seinem eigenen endlosen Fahrradabwurf und Handwink-Diskussionen führen. Das Wichtigste ist, dass ein einmal abgebauter Block so schnell wie möglich auf der ganzen Welt verbreitet werden muss, da sonst das Risiko besteht, dass ein anderer Miner einen anderen Block findet, in dem einer dieser Blöcke „verwaist“ (verschwendet) wird. Mehr verwaiste Blöcke führen zu einem zentralisierteren Mining, da größere Miner eine größere Chance haben, ein solches Waisenrennen zu gewinnen. "ASAP" bei einem 10-Minuten-Intervall liegt daher in der Größenordnung von Sekunden. Das bedeutet jetzt nicht, dass die gesamten 600 MB innerhalb weniger Sekunden auf alle Knoten auf der ganzen Welt übertragen werden müssten, aber es ist immer noch eine ziemliche Herausforderung.

Derzeit gelten 2 MB als maximale sichere Blockgröße, die SegWit ziemlich genau abdeckt. Nach weiteren Ausbau- und Effizienzsteigerungen ist in ein bis zwei Jahren voraussichtlich eine weitere Verdopplung möglich.

Ist die obige Schätzung korrekt, oder übersehe ich etwas?

Ihre Schätzungen scheinen (mehr oder weniger) in Ordnung zu sein.

Wenn es richtig ist, welche Auswirkungen hat der Wechsel von einer Blockgröße von 1 MiB auf 586 MiB?

Die beiden wichtigsten, die ich sehe, sind:

• große Blöcke machen den Betrieb vollständiger Knoten schwieriger/teuer (dh erfordern bessere Spezifikationen und bessere Upload-/Download-Geschwindigkeiten); daher schlecht für die Dezentralisierung, da nicht viele Leute in der Lage sein werden, einen vollständigen Knoten zu betreiben
• die Blöcke brauchen länger, um sich durch das Netzwerk zu verbreiten, wodurch die Wahrscheinlichkeit von verwaisten Blöcken und doppelten Ausgaben steigt.

Eine ausführlichere Liste finden Sie hier .

Beachten Sie, dass diese Bedenken/Nachteile für eine erhöhte Blockgröße für eine Erhöhung um 4, 8 oder 32 MB geäußert wurden ... eine Erhöhung um 586 MB wäre viel zu übertrieben. Und wenn Sie die Parameter ähnlich wie bei Bitcoin halten, hätten Sie die gleichen Probleme in der Seitenkette.