-
Notifications
You must be signed in to change notification settings - Fork 992
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Tendermint max block size param to genesis config file #843
Add Tendermint max block size param to genesis config file #843
Conversation
414b6e9
to
a937e00
Compare
a937e00
to
d1301b5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm though I think we should mark out Tendermint consensus params in their own config struct (either in this PR, or some later one). This PR should be targeting main
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add validation somewhere that the input isn't insane. Here perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if that's enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, we do have the same internal address as a prefix in each of these keys
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
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