Dies ist vielleicht eher eine wirtschaftliche Frage als eine Bitcoin-Frage, aber ich frage mich, ob es praktikabel wäre, die Blockgröße für alle Zeiten auf 1 MB zu belassen und einfach eine Reihe von Regeln bestimmen zu lassen, welche Transaktionen in einen abgebauten Block aufgenommen werden , z.B:
Dies würde Menschen dazu anregen, sich mehr auf Off-Chain-Transaktionen (z. B. Gyft-Karten) oder Sidechains zu verlassen, viele Zahlungen in einer einzigen Transaktion zu sammeln und möglicherweise Transaktionen zu verzögern, wenn sie keine hohen Gebühren zahlen möchten. Und ein Vorteil wäre, dass die Blockchain nicht über eine Größe hinauswachsen würde, die auf die Festplatte eines einzelnen Benutzers passen würde. Dies würde Bitcoin dezentralisiert halten, ohne dass eine Hardfork erforderlich wäre.
Gibt es fatale Fehler in dieser Vorstellung?
Das Thema Blockgröße korreliert direkt mit der aktuellen Obergrenze von 7 Transaktionen pro Sekunde (TPS), die Bitcoin hat, die kürzlich vor dem US-Kongress ans Licht gebracht wurde. https://en.bitcoin.it/wiki/Scalability beschreibt die 7 TPS-Obergrenzen unter „Aktuelle Engpässe“. Ignorieren Sie Block-Framing-Datenfelder, das 7-TPS-Limit impliziert, dass ~4200 Transaktionen (10*60*7) mit jeweils ~238 Bytes groß sind und gut in die 1-MB-Block-Brown-Tasche passen. Eine sorgfältige Untersuchung der Spitze der Blockchain-Punkt-Informationen zeigt, dass die reale Welt etwas komplexer ist, und die Obergrenze von 7 TPS ist äußerst optimistisch, die meisten Transaktionen werden deutlich größer als 238 Bytes sein! Allein meine Mining-Auszahlungen sind ~4K groß.
Die Optimierung der Blockgröße ist ein sehr heißes/politisches Thema. Erinnern Sie sich an das Bitcoin Fork Blockchain-Problem vom 12. März 2013??? ( http://bitcoin.org/en/alert/2013-03-11-chain-fork ) Es ist zu früh für mich, die Vor- und Nachteile des Handelsraums zu sagen [systemtechnische Wahrheit bezüglich der Handelsraumanalyse der Alternative ( AoA) Ergebnisse für Abwärtskompatibilität, Skalierbarkeit, Sicherheit, nachhaltige Dezentralisierung ... Effektivitätsmessungen (MOE) und Leistungsmessungen (MOP)] dient der Erhöhung der aktuellen Blockgröße von 1 MB in der Blockchain.
Abgesehen von der staatlichen Politik wird letztendlich die Dynamik zwischen Stabilität von Entwicklerlösungen, Hardware-Engine-Lösungen, Minern und Pools die zukünftig unterstützte(n) Blockgröße(n) bestimmen.
Sehen:
Es lohnt sich, den dreiseitigen „Chicago Fed Letter“ vom Dezember 2013 mit dem Titel „Bitcoin: A Primer“ zu lesen, den die Federal Reserve über Bitcoin hat, siehe http://www.chicagofed.org/digital_assets/publications/chicago_fed_letter/2013 /cfldezember2013_317.pdf . Es ist Wahrheit in der Behauptung, dass „es im Durchschnitt etwa 30 Bitcoin-Transaktionen pro Minute gibt (Visa-Transaktionen durchschnittlich 200.000 pro Minute). Die durchschnittliche Bitcoin-Transaktionsgröße beträgt etwa 16, d $80)". Siehe https://blockchain.info/charts/n-transactions-per-blockfür die Wahrheit über Bitcoin-Transaktionsraten. Dies ist der Grund, warum die Blockgröße von Bitcoin so umstritten ist. Aus existenziellen Gründen muss die Bitcoin-Community äußerste Sorgfalt walten lassen, um eine Vorgehensweise auszuwählen. Es müssen Strategien entwickelt werden, um nicht zu schnell zu wachsen, und es müssen symbiotische Verbündete für Kryptowährungen etabliert werden, um die erwartete Nachfrage nach Kryptowährungstransaktionen auszugleichen, während eine optimale und optimale dezentrale Architektur identifiziert wird, die es Bitcoin ermöglicht, um mindestens drei Größenordnungen zu skalieren und sie gleichzeitig aufrechtzuerhalten dezentrale Eigenschaften. Blockgrößen zu groß zu machen, wird den Mining-Betrieb in den Händen von nur wenigen belassen, was uns wieder in das gleiche zentralisierte Banking-Paradigma zurückversetzt. Das ist die große Herausforderung! Einige große Entscheidungen müssen getroffen werden.
Blockchains werden niemals in der Basisschicht skalieren, aber Bitcoin kann [skalieren] und es wird eine Kombination aus Skalierung der zweiten und dritten Schicht sowie der Skalierung der Basisschicht sein. Wir werden die Blockgröße erneut erhöhen – haben wir bereits getan – wir werden es bei Bedarf erneut tun – nicht um bloße Transaktionen zu unterstützen, sondern um bei Bedarf mehr Second-Layer-Skalierung auf der Basisschicht zu unterstützen.
Ich denke, unter "Second-Layer-Technologie" würde Andreas einschließen:
Und es sei darauf hingewiesen, dass er zuvor gesagt hat, dass er keine aktuelle Implementierung von Bitcoin-Technologien befürworten würde, bei der die Gefahr besteht, dass sie erneut verbrannt werden.
Lassen Sie einfach eine Reihe von Regeln bestimmen, welche Transaktionen in einen abgebauten Block aufgenommen werden
Das Bitcoin-Protokoll hat keine Möglichkeit, solche Regeln durchzusetzen. Die Miner haben völlige Ermessensfreiheit darüber, welche Transaktionen sie in einen Block aufnehmen. Ihr erster Vorschlag (höhere Gebühr gibt höhere Priorität) wird natürlich passieren, wenn Bergleute gierig sind, aber es gibt keine Möglichkeit, sie dazu zu bringen, Blöcke auf einer anderen Grundlage auszuwählen, noch eine klare Möglichkeit, sie dazu anzuregen, ältere oder größere Transaktionen einzubeziehen.
Wenn solche Regeln verbindlich sein sollten, müsste es zumindest einen Hard Fork geben, um sie in das Protokoll aufzunehmen, und selbst dann ist überhaupt nicht klar, wie das neue Protokoll aussehen würde. Angenommen, ein Miner lässt eine Transaktion mit „hoher Priorität“ zugunsten einer Transaktion aus, der Ihre Regeln eine niedrigere Priorität einräumen. Wenn die Regel obligatorisch ist, sollte sein Block daher ungültig sein.
Aber denken Sie daran, dass es möglich sein muss, die Blockchain nachträglich zu validieren. Wenn jemand Monate später die Blockchain herunterlädt und verifiziert, wie kann er dann wissen, dass sich diese Transaktion mit hoher Priorität zu diesem Zeitpunkt im Mempool befand und dieser Block daher nicht akzeptabel ist? Dies scheint nicht praktikabel.
Bitcoin Core befolgte früher standardmäßig Prioritätsregeln, wobei etwas Blockplatz für Transaktionen mit hohen „zerstörten Bitcoin-Tagen“ (älter und größer) reserviert war, aber dies war streng freiwillig, und jeder Miner konnte den Code patchen oder andere Software verwenden, wenn er wollte etwas anders zu machen. Ihre Blöcke würden so oder so akzeptiert werden. Und tatsächlich, sobald das Transaktionsvolumen den Punkt erreichte, an dem es lukrativer war, Transaktionen mit höheren Gebühren gegenüber Transaktionen mit höherem BDD einzubeziehen, begannen die Miner, dies in kurzer Zeit zu tun, und schließlich gab Bitcoin Core auf und entfernte seine BDD-Regeln zugunsten eines rein gierigen Algorithmus.
Eine Erhöhung der 1MB-Grenze ist bereits in Arbeit. Es wird bald passieren. Wenn Benutzer auf diese Einschränkung stoßen, würde Bitcoin letztendlich schaden. Es würde keinen Sinn machen, Bitcoin in einem Bereich zu lähmen, um zu versuchen, es in einem anderen anzuregen. Ich denke, es gibt bessere Möglichkeiten, Bitcoin-Gyft-Karten anzuregen.
Ich glaube nicht, dass Blöcke für immer auf 1 MB begrenzt bleiben werden, und BIP141 ändert die Dinge geringfügig. Zum einen ist es wirtschaftlich nicht sinnvoll, dass Blöcke bei sinkender Blockbelohnung so klein bleiben, da dies bei steigender Nachfrage den Nutzwert von Bitcoin durch immer höhere Gebühren untergräbt. Dies spiegelt sich auch im Wert von BTC wider.
Ich glaube nicht, dass die Blockgröße unreguliert oder größer als nötig sein sollte.
Einfach ausgedrückt, wenn jeder Miner einen Block erstellt, der (current average valid network-wide mempool transaction count) x ( 1 / (144 x n days ) ) = number of transactions to be included in blockin n Tagen erfolgt, werden alle gültigen Transaktionen bestätigt und alle Gebühren eingezogen. Dies könnte zu einem weitaus höheren Betrag (und Barwert!) an Gebühren führen, als es die derzeitige Frustration der Benutzer durch das begrenzte Angebot und all seine Komplikationen letztendlich zulassen würde. Momentan wird dieser Nutzerfrust als Auktionsmodell für begrenzte Bandbreite bezeichnet.
Die erste zu lösende Schwierigkeit besteht darin, wie die aktuelle durchschnittlich gültige netzwerkweite Mempool-Transaktionszahl ermittelt werden kann, da der Mempool nicht im Konsens ist? Und wie viele sollten n Tage sein?
Siehe auch diese Antwort: https://bitcoin.stackexchange.com/a/69478/75001
Mursch