Add Tendermint max block size param to genesis config file #843
Conversation
sug0
force-pushed
the
tiago/ethbridge/max-block-size-genesis-param
branch
from
414b6e9 to
a937e00
Compare
sug0
force-pushed
the
tiago/ethbridge/max-block-size-genesis-param
branch
from
a937e00 to
d1301b5
Compare
|
@james-chf can't target |
|
so, actually, it looks like we do not configure evidence params right now, and they seem to be using 1 MiB of space at most, by default. that should be plenty of space, so I'm not going to touch that config. |
Wouldn't it just be setting a max cap of 100 MiB rather than having blocks always be 100 MiB in size? (I would have thought applying this PR to |
…size-genesis-param
yeah, it'd just set a max block size of 100 MiB, but I'm not sure if it's a good idea to include this PR in |
| @@ -111,6 +115,16 @@ impl Parameters { | |||
| pos_inflation_amount, | |||
| } = self; | |||
|
|
|||
| // write max proposal bytes parameter | |||
There was a problem hiding this comment.
We should add validation somewhere that the input isn't insane. Here perhaps?
There was a problem hiding this comment.
Or maybe it' crazy to validate genesis input. But we will need some mechanism for validation if it is changed by governance. Tomas mentioned something about guarding it with VPs. Maybe a separate pr.
There was a problem hiding this comment.
we're grabbing this parameter from the toml config, whose deserialization already has some logic that checks if it is in the range [1 B, 90 MiB]
There was a problem hiding this comment.
I'm not sure if that's enough?
There was a problem hiding this comment.
Ah, I missed that. So good enough for now. For governance, I'm not so sure as it doesn't require a hard fork but just a change in storage. So we might need this VP idea. But that can be a separate PR.
There was a problem hiding this comment.
btw I think I misinterpreted the Tendermint specs. https://github.com/tendermint/tendermint/blob/v0.34.x/spec/abci/apps.md#blockparamsmaxbytes
I think the hard cap for a block might be 100 mb - 1 b, instead of 100 mb, since they're using an open interval
| // TODO: improve this code; use some kind of prefix | ||
| // tree to efficiently match `key` | ||
| is_epoch_duration_storage_key(key) | ||
| || is_max_expected_time_per_block_key(key) | ||
| || is_tx_whitelist_key(key) | ||
| || is_vp_whitelist_key(key) | ||
| || is_implicit_vp_key(key) | ||
| || is_epochs_per_year_key(key) | ||
| || is_pos_gain_p_key(key) | ||
| || is_pos_gain_d_key(key) | ||
| || is_staked_ratio_key(key) | ||
| || is_pos_inflation_amount_key(key) | ||
| || is_max_proposal_bytes_key(key) |
There was a problem hiding this comment.
oic the efficiency issue now. It would be good I guess if all protocol parameters were under some subtree e.g. /parameters/protocol/... or something, then we could easily recognize them
There was a problem hiding this comment.
I was playing around with trie codegen over the weekend for this specific use-case, but I still need to improve the generated code. https://gist.github.com/sug0/1bc632eb19ebdeb2d596c1617fba4138
There was a problem hiding this comment.
btw, we do have the same internal address as a prefix in each of these keys
We allow validators to configure the max transaction batch size at genesis (up to 90 MiB worth of tx data). Tendermint is configured with a hard-coded value of 100 MiB per serialized block; this is fine, because we enforce tx data size on an application basis, with the block space allocator abstraction.
NOTES: https://hackmd.io/DJVZdogGSuKjw3fjVKv7ag?view
TODO: Add maximum gas cap on blocks