-
Notifications
You must be signed in to change notification settings - Fork 348
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
Skip state independent checks in prepare proposal #3300
Comments
It's not clear to me what the benefits are from doing this. It seems like a small performance improvement that we should only pursue if we have data indicating that:
|
it seems a bit risky to me as well. It's true that we've ran check tx successfully on all of the txs, however it seems like it would be easy to let txs slip through the cracks. For example, aren't we skipping signature verification when we call ReCheckTx? if that's the case, is it possible that a transaction gets included that invaldates the nonce of a tx that makes it to Prepare? What happens if a validator isn't running ReCheckTx? we can quantify how long this is taking with further tracing and profiling, then re-evaluate. |
Yeah I agree that we should benchmark how long these operations take to get a better idea of the relative times. Maybe this is a good first step. We are benchmarking a lot of the network latencies as we're assuming that's were the biggest gains can be made, but it may also be a good idea to benchmark more of the computational work i.e. state execution, square construction, checkTx and the other abci calls as these do end up having significant impact on the total system (imagine waiting 3 seconds to process a block before you can continue to gossip it to peers that haven't seen the block yet). |
adding a plot here from a previous analysis for posterity, when the square size is increased, there are dramatic increases in the amount time required for nodes to process and prepare a proposal block. Worse yet, prepare and process proposal cannot overalp (without pipelining ofc) and are blocking, meaning that any increase in time verifying the data root is doubled. This plot shows square sizes that are 512x512 ODS (anything greater than 32MB) |
Cool plot! IMO we need to drill into Prepare/ProcessProposal to see if the ante handler is a bottleneck before we do this issue. |
Would be interested to see how much time the application is also handling |
Context
celestia-app/app/prepare_proposal.go
Lines 36 to 38 in 1d73e33
The text was updated successfully, but these errors were encountered: