Blockzeit und Blockgröße in der Zukunft

Bitcoin wurde ja um 2008-2009 entwickelt. Damals war ja das Internet noch relativ langsam und Speicher weitaus teurer. Heute (und erst recht in der Zukunft,hoffendlich:D) ist das Internet weitaus schneller (weniger Latenz und stabiler) und Speicher um einiges billiger.

Sollte man dann nicht in Zukunft erwägen die Blockgröße oder die Blockzeit ein wenig dahingehend anzupassen? Ich rede jetzt nicht von einer Verachtfachung auf 8MB wie Bitcoin Cash, sondern viel mehr von einem Netzwerk was sich langsam dem technologischen Gegebenheiten anpasst.

Wenn zum Beispiel der Speicher jetzt 5mal billiger ist als 2010, wäre es dann nicht in Zukunft sinnvoll die Blockgröße beispielweise auf 2MB zu verdoppeln? Wenn das Internet seit 2010 so viel schneller und stabiler geworden ist und die notes und miner jetzt viel besser miteinander kommunizieren können, wäre es nicht vlt sinnvoll in Zukunft die Blockzeit zu veringern?

Oder übersehe ich bei den Gedanken etwas?

1 „Gefällt mir“

Ich gehe auch davon aus, dass es irgendwann einmal Anpassungen geben wird.

Schließlich sind die 1 MB und 10 Minuten nicht gottgegeben. Und selbst wenn diese Werte ein Optimum darstellen sollten, das aus verschiedenen relevanten Parametern abgeleitet werden kann, müssten sich die Werte wie du sagst im Laufe der Zeit ändern.

Wenn z.B. irgendwann der günstigste erhältliche Datenspeicher schon 10x größer als die Blockchain ist, könnte man über ein Blockgrößenerhöhung nachdenken.
Das gleiche gilt für die Internetverbindung, die es selbst bei minimaler Geschwidigkeit ermöglichen sollte, dass sich ein neuer Block in maximal einigen Prozent der Blockzeit im gesamten Netzwerk verteilen kann.

Gleichzeitig haben solche Änderungen aber Auswirkungen auf viele andere Aspekte, die man berücksichtigen muss, z.B. die Fees. Am Ende muss sich alles in einem stabilen Gleichgewicht befinden. Es sollte z.B. keine Anreize dafür geben, die zu einer Verschlechterung der Blockchain Eigenschaften führen (Dezentralität, Sicherheit, Adoption etc.).

Die Änderung an sich sollte auch sicher durchführbar sein, es muss also einen breiten Konsens für so einen Hard Fork geben.

Mit Fokus auf Dezentralität und Stabilität bin ich aktuell der Meinung, dass die Werte ziemlich optimal gewählt sind. Die Blockchain ist so groß, dass eine entsprechende HDD/SDD gerade zu den günstigsten erhältlichen Speichern gehört.
Die Zeit für die Verbreitung eines neuen Blocks im Netzwerk liegt meines Wissens in der Größenordnung von 1…10 Sekunden, also ca. 1 % der Blockzeit.

Schöne Denkansätze dazu bietet der folgende Thread:

2 „Gefällt mir“

Sehr guter Thread, danke. Habe noch eine Frage.
Sagen wir in 6 Jahren sind wir an einem Punkt wo die Mehrheit des Netzwerk will, dass die Blockgröße angehoben wird. Wie läuft so ein „update“ ab? Wie lange dauert es bis es im Netzwerk übernommen wird? Wie läuft es ab?

Hier geht @Blocktrainer darauf ein:

Ich ging bisher davon aus, dass sich die Blockgröße nie ändern wird, weil das Bitcoin Netzwerk der TCP/IP Logik folgt. Die kleinen Datenpakete machen das Internet flexibler. Ohne IT’ler zu sein, hielt ich diese Flexibilität für das goldene Fundament des Bitcoin.

3 „Gefällt mir“

Eine Veränderung der Blocksize oder Blockzeit hat meiner Meinung nach nur den Vorteil, dass bei zu vollen Blöcken die Fee wieder günstiger werden. Es muss sich erst zeigen ob das überhaupt relevant ist. Dieses Problem ist noch sehr fern.

Ich sehe bei einem solchen Update folgendes Problem:

Vorherige Updates wie Taproot und Segwit haben das Protokoll so erweitert, dass Fullnodes mit einer älteren Version, welche die Updates nicht unterstützen, weiterhin funktionieren. Ein Update weiches die oben genannten Änderungen vornimmt, würde dafür sorgen dass ältere Fullnodes nicht mehr funktionieren. Vermutlich käme es dadurch zu einem Hard Fork.

Also zunächst mal, Bitcoin hatte 2017 eine Blockgrößenanpassung auf geschätzte 1.8 MB bei gewöhnlicher Verwendung, das sollte hier nicht unter den Tisch geschwiegen werden.

Anpassungen an gesunkene Hardwarekosten sind ein Fehler, den Bitcoin bisher souverän vermieden hat und hoffentlich auch in Zukunft nicht machen wird. Bitcoin passt die Blockgröße nicht an, wenn Speicher billiger wird, sondern wenn es absolut notwendig für den Weiterbestand und das weitere Wachstum des Netzwerks ist.

Das Endziel ist ein reines Gebührenmodell fürs Mining, also macht es keinen Sinn, ohne dringende Notwendigkeit durch Blockvergrößerungen die Konkurrenz am Gebührenmarkt zu verringern. Außerdem ist ein hard fork nichts, was man auf die leichte Schulter nimmt – was nachher das „echte“ Bitcoin ist, bestimmt im Wesentlichen eine wirtschaftliche Mehrheit, und wer will schon, dass das bei einem wachsenden Derivatemarkt am Schluss die CME entscheidet?

Dazu habe ich zwei Fragen:

Also würdest du nicht sagen, dass Blockgröße und -zeit nach einer Abwägung verschiedener Faktoren beurteilt werden? Zum Beispiel u. a. auch wie einfach und günstig man eine Full Node betreiben kann.

Und wie modelliert man die Miningeinnahmen sinnvoll, u.a. abhängig von Blockgröße pro Zeit? Für mich ist z.B. nicht offensichtlich wie sich die Einnahmen ändern würden, wenn man in der Zukunft die Blockgröße beispielsweise mal verdoppelt.

Ich nehme dabei natürlich an, dass es ab einem gewissen Zeitpunkt in der Zukunft soviel Nachfrage gibt, dass man auch ein Vielfaches der Blöcke füllen könnte.
Bei einer Blockvergrößerung stünden dann günstigere Transaktionen einer größeren Menge von Transaktionen gegenüber.

Bringt es für das Netzwerk nicht mehr wenn eine Node, resp. der Speicher irgendwann so günstig ist, dass auf jedem Gerät (Handy oder PC) eine Node laufen kann? Irgendwann geht der Grenznutzen einer Node wahrscheinlich gegen Null, aber bis dahin überwiegt dies in meinen Augen.

Ich bin kein Informatiker, kann mir jedoch vorstellen, dass wir eher die Zahlungen bündeln werden um die Transaktionskosten für die einzelne Transaktion zu reduzieren. Ich glaube mal gehört zu haben, dass dies in einer Form kommt. Wie weit dies ausgebaut werden kann, weiss ich jedoch nicht.

Doch, ich finde, eine Änderung der Blockgröße ist eine Entscheidung, in die, falls sie mal getroffen werden sollte, viele Faktoren einfließen müssen bzw. werden (allen voran das, was ich vage „dringende Notwendigkeit“ genannt hab). Ich sage hier eigentlich nur, dass unter diesen Faktoren der Faktor Hardwarekosten ein limitierender sein muss („machen wir mal lieber keine 1GB-Blöcke, weil Speicher dafür zu teuer ist“) und nicht ein motivierender („Speicherkosten haben sich halbiert, wieso verdoppeln wir also nicht einfach mal die Blöckgröße?“). Es macht aber auch einen Riesenunterschied, ob man einfach nur abstrakt beurteilt, dass eine andere Blockgröße im Moment eigentlich für alle besser wäre, oder ob man dafür ernsthaft einen hard fork vorschlägt.

Deine zweite Frage ist hier ganz gut beantwortet: https://core.ac.uk/download/pdf/288644038.pdf. Ein Ergebnis ist etwa, dass Miner dann am meisten von größeren Blöcken profitieren, wenn die Transaktionen im Mempool alle ca. gleich hohe Gebühren bieten, und am wenigsten, wenn die Gebühren im Mempool stark polarisiert sind.

2 „Gefällt mir“

Ok, sehr interessant und schlüssig, wie halt immer! :+1:

Mein Aussage von oben ist dann mindestens schlecht formuliert. Weiter fallende Preise für Speicher wären zwar notwendig, aber nicht hinreichend für eine Blocksize Erhöhung.

Danke für deine Antwort und den Link! Toll, dass es so ein Journal gibt. Das sehe ich zum ersten Mal.

Also mir würde jetzt nicht einfallen welche positiven Effekte so eine Erhöhung haben soll. Bei einer Verdopplung der Blockgröße hat man dann halt ~14 tps anstatt 7 tps, was aber immer noch um mindestens den Faktor Zehntausend zu klein ist um den Mainlayer als Zahlungs/ Transaktionslayer zu nutzen.
Außerdem musst du bedenken, nur weil bei uns der Speicher gerade günstig ist muss das nicht Weltweit der Fall sein. Genau so kann es passieren das wir bei der Herstellung unerwartet einen Engpass haben wie jetzt bei der Chipherstellung der sich möglicherweise über Jahre hinzieht.

1 „Gefällt mir“

Bestes Saylor Interview, unteranderem zur Erhöhung der Blocksize.

Robert Breedlove ist mir etwas creepy aber ich werd mir das morgen mal ansehen, danke für’s teilen!

1 „Gefällt mir“

Ich hoffe es ist das Richtige, bin mir zu 90% sicher :stuck_out_tongue:

Ist das Richtige! Blockzeit ab Minute 25.

Mal eine anderer Ansatz: Wäre durch die programmierung (Efizienz des codes und/oder komprimierung) es möglich mehr Daten in den Block zu speichern? Damit könnte man ja am Ende auch Gebühren sparen oder sehe ich das falsch?

Meinst du, dass die Blocke weiterhin gleich groß sind, aber die Daten darin “kleiner“?

Genau so habe ich das darstellen wollen. Man sieht ja überall eine optimierung von programmcodes. Jetzt müsste man nur schauen inwieweit sich das auf die Hardwareleistung überträgt (Anstieg der Prozessauslastung). Es kann auch sein das durch die optimierung sogar leistung eingespart wird aber es kann sich auch gegenteilig verändern. Die Frage ist dann wie hoch die leistungsaufnahme ist.

Segwit hat es ja bereits ermöglicht das mehr Transaktionen in einen Block passen, respektive mehr Daten pro Block verarbeitet werden. Ich meine in einem Stream vernommen zu haben, dass im optimalen Fall bis zu 4MB durch ‚Optimierung\Anhänge‘ in einen Block passen. Technisch weiss ich jedoch nicht wie.