-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
EPIC: ABCI++ #12272
Comments
Is the plan to switch to the newly introduced "same block execution" or keep using "next block execution"? Asking to learn - why would we prefer one over the other in the SDK? |
I think the idea here @p0mvn is to refactor/update the |
We will continue to use next-block execution because the sdk is built with the off by one approach of delayed execution (next-block execution), if we move to immediate execution (same-block execution) we would need to refactor quite a few things |
The ability to do same block execution would be nice, how bad would the refactor be @marbar3778 ? |
immediate execution would be a fairly hefty rewrite, I believe, as staking and other modules assume H+1. Optimistic execution, where we start execution in the process proposal phase is a lot lighter of a lift |
Yeah it's not trivial because as @marbar3778 pointed out there are various places in the SDK where we have this "off by 1" assumption, so it's not just a few changes to baseapp :-/ In any case, we're proposing the execute the entire block in |
Immediate execution seems like the "more correct" way to do things long term though? Should improve UX a lot since chain will feel "snappier" when using. Less important in a world of sub second block times, but still seems important? I know this would mess with the distributor for sure, but I presume also evidence crisis etc. would need a big refactor. |
Long term? Yes. It's not on our immediate roadmap though as ABCI++ integration is more important along with store improvements as that is the biggest pain point atm. People don't really mind the current execution model, granted it is annoying. |
Summary
Tendermint team has been working on a refactor of the abci layer to enable more use cases. This has been a requested feature by many users and will be a focus of the sdk team once a release of 0.36 is cut and SDK team has completed app wiring migration.
More Information can be found on the design here: https://github.com/tendermint/tendermint/tree/master/spec/abci%2B%2B
Phase 1
Phase 1 of baseapp++ will be focused on prepare proposal and process proposal.
Phase 2
Phase 2 of baseapp++ will commence once tendermint releases a version of abci with vote extensions and finalise block
BaseApp
simapp
store
(this includes possibly revamping streaming APIs) (@tac0turtle)runtime
server
types
client
BaseApp
ABCI methods to ensure errors are only returned where necessaryBaseApp
tests forFinalizeBlock
,ExtendVote
, andVerifyVoteExtension
Phase 3
Phase 3 is all about testing
Phase 4
For Admin Use
The text was updated successfully, but these errors were encountered: