Warum nicht „sechs Bestätigungen“ multiplizieren und Time-Between-Blocks und Reward durch denselben Faktor teilen?

Es scheint, dass die Wahl eines guten Faktors zur Erweiterung der Kapazität von Bitcoin eine gute Idee ist. Die Software würde einige ihrer berechneten Werte durch diesen Faktor dividieren, wie z. B. die Zielzeit zwischen Blöcken während der Schwierigkeitsberechnung, die Anzahl der Blöcke zwischen Schwierigkeitsanpassungen und die Subvention. Um die Sicherheit von „einer Stunde Hashing-Power“ zu erreichen, würde die Empfehlung für Bestätigungen mit diesem Faktor multipliziert. Es scheint, dass die Verwendung eines Faktors von zwei von Zeit zu Zeit (wann immer die Community es für wertvoll hält) angemessen wäre.

Nehmen wir an, wir wählen einen Faktor N. Dies ermöglicht es der Blockchain selbst, N-mal so schnell zu wachsen, den Minern N-mal die Transaktionsgebühren zu zahlen, die Anzahl der Belohnungen mit N zu multiplizieren (aber die Belohnung selbst durch N zu teilen) und den Durchschnitt zu teilen auf eine Bestätigung mit N warten und die Rate, mit der Transaktionen bestätigt werden, mit N multiplizieren. Dies verringert auch die Varianz der Mining-Einnahmen.

Dadurch kann Zeit (anstelle von Netzwerkbandbreite und Computerspeicher) verwendet werden, um die Tragfähigkeit des Bitcoin-Ökosystems zu erweitern. Sollte ein solcher Vorschlag in eine BIP geschrieben werden?

Die bisherigen Einwände gegen diese Idee wurden in den Kommentaren beantwortet. Wenn jemand der Meinung ist, dass es einen Einwand gibt, der ausreicht, um die Idee fallen zu lassen, posten Sie bitte eine Antwort. Wenn jemand einen BIP erstellen möchte, lassen Sie es mich bitte wissen, damit ich es nicht selbst tun muss. Es macht mir nichts aus, es selbst zu tun, aber ich werde wahrscheinlich langsam sein.

Ihr Vorschlag erhöht auch die Netzwerkbandbreite, da das Zeitintervall zwischen den Blöcken schrumpft und die für die Weitergabe von Blöcken erforderliche Kapazität zunimmt. Es gibt auch eine Latenz, die ins Spiel kommt. Wenn das Zeitintervall zwischen den Blöcken schrumpft, steigt der Anteil der Zeit, die durch die Latenzzeit beigetragen wird, und trägt zu einer höheren Wahrscheinlichkeit bei, dass ein geprägter Block verwaist. Bin gespannt, was die anderen denken.
Wenn also N = 2, haben wir alle 5 Minuten einen neuen 1-MB-Block statt 10, wobei sich jede Miner-Belohnung im Vergleich zum aktuellen Protokoll halbiert? Ist das nicht im Grunde dasselbe wie die Verdoppelung der Blockgröße (wenn auch auf verwickeltere Weise)?
Ein Nachteil ist, dass Sie alle Endbenutzer dazu bringen müssen, zu verstehen, dass sich der Benchmark für die Anzahl der Bestätigungen geändert hat, und dies jedes Mal erneut tun müssen, wenn sich N ändert. Unter dem aktuellen System können sich Endbenutzer eine magische Zahl wie 6 Bestätigungen merken, die sich nie ändern wird. Für solche Endbenutzer kann eine Erhöhung der Blockgröße transparent sein, selbst wenn es sich um einen Hard Fork handelt; Sie müssen ihre Software aktualisieren, aber sie müssen ihre Denkweise nicht ändern.
@renlord - ja, die Bandbreitenanforderung steigt mit der Kapazität. Verwaiste Blöcke gehen ebenfalls hoch, verursachen aber nur die Hälfte des Verlustes, den sie normalerweise verursachen.
@Sven-Williamson - ja, im Grunde dasselbe, verdoppelt jedoch nicht die Bandbreite für jeden Block oder die Mempool-Last, wenn die Blockgröße zunimmt.
@Nate-Elderidge - Die Sicherheit sollte immer "eine Stunde Hash-Power" gewesen sein, und es ist eine grundlegend vernünftige Änderung, sie darauf zu ändern.
@NateEldredge Sie könnten dies als "Bruchteile einer Bestätigung" implementieren. Anstatt also 7 Bestätigungen unter dem neuen System zu sehen, würden sie 3,5 sehen. Das Problem ist, dass Sie alle Brieftaschen benötigen, um dieses neue Nummerierungssystem zu übernehmen.

Antworten (1)

In Anbetracht des Ersetzens des 1-Blocks durch NBlöcke im gleichen Zeitrahmen N > 1sehe ich die folgenden Punkte:

Vorteile

  • Erwartete Zeit bis zur ersten Bestätigung wird reduziert
  • Die Mining-Einnahmen werden gleichmäßiger auf die Pools verteilt
  • Die Kapazität des Netzwerks wird erhöht
  • Geringerer Spitzenverkehr als Erhöhung der Blockgröße umN

Nachteile

  • Ein Hardfork ist erforderlich, um das Blockintervall anzupassen
  • Erhöhte Wahrscheinlichkeit von Kettengabeln und höhere Stale-Rate, da die Blockvalidierung einen größeren Teil des Blockintervalls beansprucht
  • Thin Clients müssen eine größere Menge an Headern speichern
  • Etwas größere Bandbreitennutzung als größere Blöcke

Dennoch kann es sein, dass 10 Minuten zu konservativ sind und ein kleineres Blockintervall einen Gesamtvorteil bieten würde. Zum Beispiel präsentierte Arthur Gervais bei Scaling Bitcoin Milan Simulationsergebnisse , die er dahingehend interpretierte, dass Bitcoin sicher 1-Minuten-Blöcke verwenden könnte.

CoinDesk behandelte das Thema in Eine niedrigere Blockzeit könnte Bitcoin-Skalierung helfen, aber wird es funktionieren? .

Wie würde die Geldmenge beeinflusst werden? Der Vorschlag war, die Blockzeit und die Belohnung durch denselben Divisor zu teilen, sodass die Geldmenge im Laufe der Zeit mit der gleichen Rate wie zuvor (wenn auch etwas gleichmäßiger) weiter wachsen würde.
@NateEldredge: Die Geldmenge wird sehr leicht reduziert, da Blocksubventionen früher einen Teil eines Satoshi pro Block verlieren würden, wenn die Halbierung die Genauigkeit auf Dezimalstellen verschiebt, aber nur volle Satoshis ausgezahlt werden können. – Ich habe jedoch nur den tatsächlichen Betrag berechnet, und selbst dafür sind N = 10es nur etwas weniger als 25 mBTC, also habe ich die Erwähnung aus meiner Antwort entfernt.
Warum nicht „sechs Bestätigungen“ multiplizieren und Time-Between-Blocks und Reward durch denselben Faktor teilen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v