From 882b4ef1dcd98db72bc044586cb3e52f45db2dbf Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Tue, 11 Apr 2023 09:45:43 -0400 Subject: [PATCH] docs: update ADR-064 (#15771) --- docs/architecture/adr-064-abci-2.0.md | 40 +++++++++------------------ 1 file changed, 13 insertions(+), 27 deletions(-) diff --git a/docs/architecture/adr-064-abci-2.0.md b/docs/architecture/adr-064-abci-2.0.md index fc3062830f..9a47180509 100644 --- a/docs/architecture/adr-064-abci-2.0.md +++ b/docs/architecture/adr-064-abci-2.0.md @@ -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} }