forked from near/nearcore
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Implement limits on the size of transactions in ChunkStateWitness (ne…
…ar#11406) Fixes: near#11103 This PR adds 3 new limitations to control total size of transactions included in ChunkStateWitness 1) Reduce `max_transaction_size` from 4MiB to 1.5MiB. Transactions larger than 1.5MiB will be rejected. 2) Limit size of transactions included in the last two chunks to 2MiB. `ChunkStateWitness` contains transactions from both the current and the previous chunk, so we have to limit the sum of transactions from both of those chunks. 3) Limit size of storage proof generated during transaction validation to 500kiB (soft limit). In total that limits the size transaction related fields to 2.5MiB. About 1): Having 4MiB transactions is troublesome, because it means that we have to allow at least 4MiB of transactions to be included in `ChunkStateWitness`. Having so much space taken up by the transactions could cause problems with witness size. See near#11379 for more information. About 2): `ChunkStateWitness` contains both transactions from the previous chunk (`transactions`) and the new chunk (`new_transactions`). This is annoying because it halves the space that we can reserve for transactions. To make sure that the size stays reasonable we limit the sum of both those fields to 2MiB. On current mainnet traffic the sum of these fields stays under 400kiB, so 2MiB should be more than enough. This limit has to be slightly higher than the limit for a single transaction, so we can't make it 1MiB, it has to be at least 1.5MiB. About 3): On mainnet traffic the size of transactions storage proof is under 500kiB on most chunks, so adding this limit shouldn't affect the throughput. I assume that every transactions generates a limited amount of storage proof during validation, so we can have a soft limit for the total size of storage proof. Implementing a hard limit would be difficult because it's hard to predict how much storage proof will be generated by validating a transaction. Transactions are validated by running `prepare_transactions` on the validator, so there's no need for separate validation code.
- Loading branch information
1 parent
722a56b
commit 8d3edac
Showing
78 changed files
with
1,105 additions
and
287 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.