EPIC: Hard capped blocksize #1592
Assignees
Labels
consensus breaking
modifies block validity rules in a way that will break consensus unless all nodes update their rules
Comments
evan-forbes
added
the
consensus breaking
evan-forbes
added a commit
that referenced
this issue
May 17, 2023
…ze (#1761) ## Overview The base implementation for all ADR021 #1759 options part of #1592 blocked by #1754 ## Checklist - [x] New and updated code has appropriate documentation - [x] New and updated code has new and/or updated testing - [x] Required CI checks are passing - [x] Visual proof for any user facing features like CLI or documentation updates - [ ] Linked issues closed with keywords
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We want the ability to configure the square size via token voting, but with hard cap that requires a hardfork to change. In previous discussions, we've decided to simply use the consensus param of max block size to limit the max block size. However, the hardcoded limit is still the max square size (currently 128 as of writing), which gets hit at ~6-7MB.
We should still make the block size limited by the consensus param, and we don't want to go above a 128x128 square size (ods). This will likely involve setting the default block size consensus param to the maximum value that can fit in a 128x128 square.
related to #1569 in that we are wanting to hardcode a max parameter.
blocked by #1214 because that removes the estimation logic, which would probably be used to limit the square size
The text was updated successfully, but these errors were encountered: