2

Given transaction gas limit (TGL), TPS = block gas limit (BGL) / TGL / block time (BT). But we don't increase TPS by simply raising BGL and decreasing BT. What's the downside exactly? Bigger BGL leads to mining centralization and shorter BT larger uncle rate?

Edit: "What are Ethereum performance dynamics?" talks about mining difficulty, not centralization or TPS.

sinoTrinity
  • 377
  • 2
  • 8
  • Increasing block gas limit will cause longer time for processing blocks, also large blocks take more time to propagate through the network. Lowering block times will cause more blocks, which causes more traffic in the network. This both will cause the increase of uncle blocks. The consecuence is the network will waste part of their effort. You have to be really careful when making changes in those parameters, a bad configuration can cause the network to halt and lots of angry people. – Ismael Feb 20 '18 at 03:16
  • 1
    Something many people are not aware of is the verifier's dilemma. Basically If you increase block size to a point where mining nodes have a significant advantage if they ignored transaction validation and use all cpu/gpu power for PoW, given that the chances of invalid txs are quite low this would set a real incentive for nodes not to validate expensive txs before including in a block. https://eprint.iacr.org/2015/702.pdf – Theo Port Feb 26 '18 at 20:04
  • 1
    Also, increasing BGL makes honest miners vulnerable to an attack where malicious miner A includes a very expensive transaction in their block, which they have already verified beforehand. Yes, they have to pay gas for it, but that gas goes straight back to them as mining reward, so they can gain an advantage in mining because everyone else is busy validating their expensive transaction while they're doing PoW. Keeping BGL low reduces the potential advantage someone gains through such an attack – Theo Port Feb 26 '18 at 20:05

1 Answers1

-1

The machines running the nodes need to be able to verify blocks.

At the moment it takes almost 15 seconds to validate the block for some machines. Increasing the block gas limit and decreasing block time will make some machines unable to keep up with the tip of the chain

Synchronizing a parity node only gives me a speed of 30 to 100 transactions/s this is very dependent on the hardware it's running on.

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

Increasing the block gas limit and decreasing the average block time would mean that some machines will not be able to keep up.

Daniel Luca CleanUnicorn
  • 2,760
  • 15
  • 27
  • 1
    That's the same as the block time - are you sure you mean 15 seconds for a single block? I was under the impression that validation took in the region of 100s of milliseconds. Happy to be wrong though. – Richard Horrocks Feb 13 '18 at 19:05
  • Validating the block is easy, but you also need to validate the transactions and what they do on the blockchain. To be able to do that you need to run the transactions and change the state, check and update account balances. That takes much longer. – Daniel Luca CleanUnicorn Feb 13 '18 at 19:12
  • Reading and validating the PoW from the header is easy, yes, but even applying the state of an 8M gas block should only take in the region of 150-200ms on a decent machine, right? (8M gas is ~30kB.) – Richard Horrocks Feb 13 '18 at 19:22
  • @RichardHorrocks you might be right. I did not do tests about this. It was based on how quickly the nodes get synched to the tip of the chain. Feel free to edit or add another answer. – Daniel Luca CleanUnicorn Feb 13 '18 at 19:33
  • 1
    Okay, thanks for confirming - let me think about the complete process and put an answer together. – Richard Horrocks Feb 13 '18 at 21:08
  • @RichardHorrocks I'm still confused. Have you got a chance to put up a clearer answer yet? – sinoTrinity Feb 17 '18 at 08:09
  • @RichardHorrocks i've added more information that supports my claim – Daniel Luca CleanUnicorn Feb 26 '18 at 12:34
  • Hi again. I think we're looking at two different things: a) processing archive data from other peer nodes when first booting a node, b) syncing the most recently mined block that's currently being propagated around the network. These are different things. In a) we're syncing the contents of the entire state database in LevelDB form. In b) we're passing around a single block and apply its state transitions to the database we already have on disk. (I'm not actually sure how to go about comparing these with regards to bandwidth and processor use.) – Richard Horrocks Feb 27 '18 at 17:10