LaconicNetwork/cosmos-sdk
9
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

docs: update ADR-064 (#15771)

Browse Source
This commit is contained in:
Aleksandr Bezobchuk 2023-04-11 09:45:43 -04:00 committed by GitHub
parent 7ab0dfc494
commit 882b4ef1dc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
docs/architecture/adr-064-abci-2.0.md
View File

@ -4,10 +4,11 @@
* 2023-01-17: Initial Draft (@alexanderbez)
* 2023-04-06: Add upgrading section (@alexanderbez)
* 2023-04-10: Simplify vote extension state persistence (@alexanderbez)
## Status
PROPOSED
ACCEPTED
## Abstract
@ -277,22 +278,14 @@ decision based on the vote extensions.
#### Vote Extension Persistence
In order to make any data derived from vote extensions persistent, we propose to
allow application developers to "merge" the `processProposalState` into the
`finalizeState`, such that when processing transactions during `FinalizeBlock`,
the base state includes any state changes from processing votes extensions
(see [`FinalizeBlock`](#finalizeblock-1) below).
However, we DO NOT want to pollute `finalizeState` with any state changes from
verifying transactions during `ProcessProposal`, so we will introduce a new API,
`ResetProcessProposalState`, that will allow applications to essentially reset
the `ProcessProposal` state, effectively allowing any state transitions after to
be committed.
What this means is that any explicit state changes in a `ProcessProposal` handler
using the injected `processProposalState.Context` will be written to state! An
application must be careful to execute `ResetProcessProposalState` where and when
appropriate.
In certain contexts, it may be useful or necessary for applications to persist
data derived from vote extensions. In order to facilitate this use case, we
propose to allow application developers to manually retrieve the `finalizeState`
context (see [`FinalizeBlock`](#finalizeblock-1) below). Using this context,
state can be directly written to `finalizeState`, which will be used during
`FinalizeBlock` and eventually committed to the application state. Note, since
`ProcessProposal` can timeout and thus require another round of consensus, we
will reset `finalizeState` in the beginning of `ProcessProposal`.
A `ProcessProposal` handler could look like the following:
@ -306,17 +299,10 @@ func (h MyHandler) ProcessProposalHandler() sdk.ProcessProposalHandler {
}
}
// Reset the ProposalProposal state, which, up to this point, has accumulated
// possible state transitions from transaction verification and processing.
// Any subsequent state transitions after this will be merged into the
// FinalizeState before processing Begin/EndBlock and transactions.
//
// NOTE: Applications must call this to ensure no state transactions up to now
// are committed!
h.app.ResetProcessProposalState()
fCtx := h.app.GetFinalizeState()
// Any state changes that occur on the provided ctx WILL be written to state!
h.myKeeper.SetVoteExtResult(ctx, ...)
// Any state changes that occur on the provided fCtx WILL be written to state!
h.myKeeper.SetVoteExtResult(fCtx, ...)
return abci.ResponseProcessProposal{Status: abci.ResponseProcessProposal_ACCEPT}
}