We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
CProvider currently uses the CometBFT RPC to query CosmosSDK application state (attest/portal/valsync modules).
CometBFT however implements a sequential concurrency model. So queries and block processing compete for time resources. See cosmos/cosmos-sdk#10859.
Queries are therefore slower, and high query load can negatively affect block building latency. See #1865 .
Local simnet testing showed that gRPC is 2x~3x faster than CometBFT.
The text was updated successfully, but these errors were encountered:
b928597
refactor(halo): revert to using comet cprovider (#2228)
c0ef025
Revert to only using cometBFT cprovider since gRPC based cprovider is causing data races in CI. issue: #2002
corverroos
Successfully merging a pull request may close this issue.
Problem to Solve
CProvider currently uses the CometBFT RPC to query CosmosSDK application state (attest/portal/valsync modules).
CometBFT however implements a sequential concurrency model. So queries and block processing compete for time resources. See cosmos/cosmos-sdk#10859.
Queries are therefore slower, and high query load can negatively affect block building latency. See #1865 .
Local simnet testing showed that gRPC is 2x~3x faster than CometBFT.
Proposed Solution
The text was updated successfully, but these errors were encountered: