Können wir einfach das Blockgaslimit erhöhen und die Blockzeit verkürzen, um TPS zu erhöhen? [Duplikat]

Gegebenes Transaktionsgaslimit (TGL), TPS = Blockgaslimit (BGL) / TGL / Blockzeit (BT). Aber wir erhöhen TPS nicht, indem wir einfach BGL erhöhen und BT verringern. Was genau ist der Nachteil? Größere BGL führt zu Mining-Zentralisierung und kürzere BT-Rate für größere Onkel?

Bearbeiten: "Was sind die Leistungsdynamiken von Ethereum?" spricht über Mining-Schwierigkeiten, nicht über Zentralisierung oder TPS.

Eine Erhöhung des Blockgaslimits führt zu einer längeren Verarbeitungszeit von Blöcken, außerdem benötigen große Blöcke mehr Zeit, um sich durch das Netzwerk zu verbreiten. Das Verringern der Blockzeiten führt zu mehr Blöcken, was zu mehr Verkehr im Netzwerk führt. Beides führt zu einer Zunahme von Onkelblöcken. Die Konsequenz ist, dass das Netzwerk einen Teil seiner Bemühungen verschwendet. Sie müssen sehr vorsichtig sein, wenn Sie Änderungen an diesen Parametern vornehmen, eine schlechte Konfiguration kann dazu führen, dass das Netzwerk anhält und viele wütende Leute werden.
Was vielen Menschen nicht bewusst ist, ist das Dilemma des Prüfers. Grundsätzlich, wenn Sie die Blockgröße bis zu einem Punkt erhöhen, an dem Mining-Knoten einen erheblichen Vorteil haben, wenn sie die Transaktionsvalidierung ignorieren und die gesamte CPU-/GPU-Leistung für PoW verwenden, da die Wahrscheinlichkeit ungültiger TXs ziemlich gering ist, würde dies einen echten Anreiz für Knoten setzen, die dies nicht tun um teure TXs zu validieren, bevor sie in einen Block aufgenommen werden. eprint.iacr.org/2015/702.pdf
Außerdem macht die Erhöhung von BGL ehrliche Miner anfällig für einen Angriff, bei dem der böswillige Miner A eine sehr teure Transaktion in seinen Block einbezieht, die er bereits zuvor verifiziert hat. Ja, sie müssen Gas dafür bezahlen, aber dieses Gas geht direkt als Mining-Belohnung an sie zurück, sodass sie sich einen Vorteil beim Mining verschaffen können, weil alle anderen damit beschäftigt sind, ihre teure Transaktion zu validieren, während sie PoW machen. Wenn Sie BGL niedrig halten, verringert sich der potenzielle Vorteil, den jemand durch einen solchen Angriff erhält

Antworten (1)

Die Maschinen, auf denen die Knoten ausgeführt werden, müssen in der Lage sein, Blöcke zu verifizieren.

Im Moment dauert es fast 15 Sekunden, um den Block für einige Maschinen zu validieren. Das Erhöhen des Blockgaslimits und das Verringern der Blockzeit führen dazu, dass einige Maschinen nicht mit der Spitze der Kette Schritt halten können

Das Synchronisieren eines Paritätsknotens gibt mir nur eine Geschwindigkeit von 30 bis 100 Transaktionen/s, dies hängt stark von der Hardware ab, auf der er läuft.

2018-02-26 14:25:47  Syncing #4950022 2622…f1f1     0 blk/s   25 tx/s   0 Mgas/s      0+  616 Qed  #4950640   100/100 peers   3 MiB chain 29 MiB db 83 MiB queue 123 MiB sync  RPC:  0 conn,  1 req/s, 2129 µs
2018-02-26 14:25:57  Syncing #4950024 5cb2…2fc6     0 blk/s   44 tx/s   1 Mgas/s      0+  612 Qed  #4950640   100/100 peers   3 MiB chain 32 MiB db 82 MiB queue 123 MiB sync  RPC:  0 conn,  2 req/s, 2470 µs
2018-02-26 14:26:08  Syncing #4950024 5cb2…2fc6     0 blk/s    0 tx/s   0 Mgas/s      0+  612 Qed  #4950640   100/100 peers   3 MiB chain 32 MiB db 82 MiB queue 123 MiB sync  RPC:  0 conn,  2 req/s, 2470 µs
2018-02-26 14:26:17  Syncing #4950026 83ce…8c21     0 blk/s   33 tx/s   1 Mgas/s      0+  612 Qed  #4950640   100/100 peers   3 MiB chain 35 MiB db 82 MiB queue 123 MiB sync  RPC:  0 conn,  2 req/s, 2409 µs
2018-02-26 14:26:27  Syncing #4950028 f1b5…2279     0 blk/s   43 tx/s   1 Mgas/s      0+  608 Qed  #4950640   100/100 peers   4 MiB chain 37 MiB db 81 MiB queue 123 MiB sync  RPC:  0 conn,  1 req/s, 2343 µs
2018-02-26 14:26:37  Syncing #4950031 68a4…7ede     0 blk/s   32 tx/s   2 Mgas/s      0+  608 Qed  #4950640   100/100 peers   4 MiB chain 39 MiB db 81 MiB queue 123 MiB sync  RPC:  0 conn,  1 req/s, 2089 µs

Eine Erhöhung des Blockgaslimits und eine Verringerung der durchschnittlichen Blockzeit würde bedeuten, dass einige Maschinen nicht mithalten können.

Das ist dasselbe wie die Blockzeit - sind Sie sicher, dass Sie 15 Sekunden für einen einzelnen Block meinen? Ich hatte den Eindruck, dass die Validierung im Bereich von 100 Millisekunden dauerte. Glücklich, falsch zu liegen.
Das Validieren des Blocks ist einfach, aber Sie müssen auch die Transaktionen und ihre Auswirkungen auf die Blockchain validieren. Um dies tun zu können, müssen Sie die Transaktionen ausführen und den Status ändern, Kontostände überprüfen und aktualisieren. Das dauert viel länger.
Das Lesen und Validieren des PoW aus dem Header ist einfach, ja, aber selbst das Anwenden des Status eines 8M-Gasblocks sollte auf einem anständigen Computer nur etwa 150 bis 200 ms dauern, oder? (8M Gas ist ~30kB.)
@RichardHorrocks, du könntest Recht haben. Tests dazu habe ich nicht gemacht. Es basierte darauf, wie schnell die Knoten mit der Spitze der Kette synchronisiert werden. Fühlen Sie sich frei, eine andere Antwort zu bearbeiten oder hinzuzufügen.
Okay, danke für die Bestätigung – lassen Sie mich über den gesamten Prozess nachdenken und eine Antwort zusammenstellen.
@RichardHorrocks Ich bin immer noch verwirrt. Hast du schon eine Chance, eine klarere Antwort zu geben?
@RichardHorrocks Ich habe weitere Informationen hinzugefügt, die meine Behauptung stützen
Hallo nochmal. Ich denke, wir betrachten zwei verschiedene Dinge: a) die Verarbeitung von Archivdaten von anderen Peer-Knoten beim ersten Booten eines Knotens, b) die Synchronisierung des zuletzt abgebauten Blocks, der derzeit im Netzwerk verbreitet wird. Das sind verschiedene Dinge. In a) synchronisieren wir den Inhalt der gesamten Zustandsdatenbank in LevelDB-Form. In b) übergeben wir einen einzelnen Block und wenden seine Zustandsübergänge auf die Datenbank an, die wir bereits auf der Festplatte haben. (Ich bin mir nicht sicher, wie ich diese in Bezug auf Bandbreite und Prozessornutzung vergleichen soll.)