You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An application can set this handler in `app.go` via the `baseapp.SetExtendVoteHandler`
@@ -38,7 +38,7 @@ other validators when validating their pre-commits. For a given vote extension,
38
38
this process MUST be deterministic. The Cosmos SDK defines [`sdk.VerifyVoteExtensionHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.1/types/abci.go#L29-L31):
39
39
40
40
```go
41
-
type VerifyVoteExtensionHandler func(Context, *abci.VerifyVoteExtensionRequest) (*abci.VerifyVoteExtensionResponse, error)
41
+
type VerifyVoteExtensionHandler func(Context, *abci.RequestVerifyVoteExtension) (*abci.ResponseVerifyVoteExtension, error)
42
42
```
43
43
44
44
An application can set this handler in `app.go` via the `baseapp.SetVerifyVoteExtensionHandler`
@@ -78,7 +78,7 @@ will be available to the application during the subsequent `FinalizeBlock` call.
78
78
An example of how a pre-FinalizeBlock hook could look like is shown below:
Copy file name to clipboardExpand all lines: docs/build/architecture/adr-038-state-listening.md
+20-20Lines changed: 20 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@
7
7
* 10/14/2022:
8
8
* Add `ListenCommit`, flatten the state writes in a block to a single batch.
9
9
* Remove listeners from cache stores, should only listen to `rootmulti.Store`.
10
-
* Remove `HaltAppOnDeliveryError()`, the errors are propagated by default, the implementations should return nil if they don't want to propagate errors.
10
+
* Remove `HaltAppOnDeliveryError()`, the errors are propagated by default, the implementations should return nil if don't want to propogate errors.
11
11
* 26/05/2023: Update with ABCI 2.0
12
12
13
13
## Status
@@ -20,7 +20,7 @@ This ADR defines a set of changes to enable listening to state changes of indivi
20
20
21
21
## Context
22
22
23
-
Currently, KVStore data can be remotely accessed through [Queries](https://docs.cosmos.network/main/build/building-modules/messages-and-queries#queries)
23
+
Currently, KVStore data can be remotely accessed through [Queries](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules/messages-and-queries.md#queries)
24
24
which proceed either through Tendermint and the ABCI, or through the gRPC server.
25
25
In addition to these request/response queries, it would be beneficial to have a means of listening to state changes as they occur in real time.
26
26
@@ -40,7 +40,7 @@ type MemoryListener struct {
40
40
stateCache []StoreKVPair
41
41
}
42
42
43
-
// NewMemoryListener creates a listener that accumulates the state writes in memory.
43
+
// NewMemoryListener creates a listener that accumulate the state writes in memory.
44
44
funcNewMemoryListener() *MemoryListener {
45
45
return &MemoryListener{}
46
46
}
@@ -114,7 +114,7 @@ func (s *Store) Delete(key []byte) {
114
114
115
115
### MultiStore interface updates
116
116
117
-
We will update the `CommitMultiStore` interface to allow us to wrap a `MemoryListener` to a specific `KVStore`.
117
+
We will update the `CommitMultiStore` interface to allow us to wrap a `Memorylistener` to a specific `KVStore`.
118
118
Note that the `MemoryListener` will be attached internally by the concrete `rootmulti` implementation.
119
119
120
120
```go
@@ -224,9 +224,9 @@ so that the service can group the state changes with the ABCI requests.
224
224
// ABCIListener is the interface that we're exposing as a streaming service.
225
225
typeABCIListenerinterface {
226
226
// ListenFinalizeBlock updates the streaming service with the latest FinalizeBlock messages
227
-
ListenFinalizeBlock(ctx context.Context, req abci.FinalizeBlockRequest, res abci.FinalizeBlockResponse) error
228
-
// ListenCommit updates the streaming service with the latest Commit messages and state changes
229
-
ListenCommit(ctx context.Context, res abci.CommitResponse, changeSet []*StoreKVPair) error
227
+
ListenFinalizeBlock(ctx context.Context, req abci.RequestFinalizeBlock, res abci.ResponseFinalizeBlock) error
228
+
// ListenCommit updates the steaming service with the latest Commit messages and state changes
229
+
ListenCommit(ctx context.Context, res abci.ResponseCommit, changeSet []*StoreKVPair) error
230
230
}
231
231
```
232
232
@@ -267,16 +267,16 @@ We will modify the `FinalizeBlock` and `Commit` methods to pass ABCI requests an
267
267
to any streaming service hooks registered with the `BaseApp`.
We propose a `RegisterStreamingPlugin` function for the App to register `NewStreamingPlugin`s with the App's BaseApp.
531
531
Streaming plugins can be of `Any` type; therefore, the function takes in an interface vs a concrete type.
532
-
For example, we could have plugins of `ABCIListener`, `WasmListener` or `IBCListener`. Note that `RegisterStreamingPlugin` function
532
+
For example, we could have plugins of `ABCIListener`, `WasmListener` or `IBCListener`. Note that `RegisterStreamingPluing` function
533
533
is helper function and not a requirement. Plugin registration can easily be moved from the App to the BaseApp directly.
534
534
535
535
```go
@@ -720,5 +720,5 @@ These changes will provide a means of subscribing to KVStore state changes in re
720
720
721
721
### Neutral
722
722
723
-
* Introduces additional—but optional—complexity to configuring and running a cosmos application
723
+
* Introduces additional- but optional- complexity to configuring and running a cosmos application
724
724
* If an application developer opts to use these features to expose data, they need to be aware of the ramifications/risks of that data exposure as it pertains to the specifics of their application
Copy file name to clipboardExpand all lines: docs/build/architecture/adr-040-storage-and-smt-state-commitments.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -92,16 +92,16 @@ A new database snapshot will be created in every `EndBlocker` and identified by
92
92
NOTE: `Commit` must be called exactly once per block. Otherwise we risk going out of sync for the version number and block height.
93
93
NOTE: For the Cosmos SDK storage, we may consider splitting that interface into `Committer` and `PruningCommitter` - only the multiroot should implement `PruningCommitter` (cache and prefix store don't need pruning).
94
94
95
-
Number of historical versions for `abci.QueryRequest` and state sync snapshots is part of a node configuration, not a chain configuration (configuration implied by the blockchain consensus). A configuration should allow to specify number of past blocks and number of past blocks modulo some number (eg: 100 past blocks and one snapshot every 100 blocks for past 2000 blocks). Archival nodes can keep all past versions.
95
+
Number of historical versions for `abci.RequestQuery` and state sync snapshots is part of a node configuration, not a chain configuration (configuration implied by the blockchain consensus). A configuration should allow to specify number of past blocks and number of past blocks modulo some number (eg: 100 past blocks and one snapshot every 100 blocks for past 2000 blocks). Archival nodes can keep all past versions.
96
96
97
97
Pruning old snapshots is effectively done by a database. Whenever we update a record in `SC`, SMT won't update nodes - instead it creates new nodes on the update path, without removing the old one. Since we are snapshotting each block, we need to change that mechanism to immediately remove orphaned nodes from the database. This is a safe operation - snapshots will keep track of the records and make it available when accessing past versions.
98
98
99
99
To manage the active snapshots we will either use a DB _max number of snapshots_ option (if available), or we will remove DB snapshots in the `EndBlocker`. The latter option can be done efficiently by identifying snapshots with block height and calling a store function to remove past versions.
100
100
101
101
#### Accessing old state versions
102
102
103
-
One of the functional requirements is to access old state. This is done through `abci.QueryRequest` structure. The version is specified by a block height (so we query for an object by a key `K` at block height `H`). The number of old versions supported for `abci.QueryRequest` is configurable. Accessing an old state is done by using available snapshots.
104
-
`abci.QueryRequest` doesn't need old state of `SC` unless the `prove=true` parameter is set. The SMT merkle proof must be included in the `abci.QueryResponse` only if both `SC` and `SS` have a snapshot for requested version.
103
+
One of the functional requirements is to access old state. This is done through `abci.RequestQuery` structure. The version is specified by a block height (so we query for an object by a key `K` at block height `H`). The number of old versions supported for `abci.RequestQuery` is configurable. Accessing an old state is done by using available snapshots.
104
+
`abci.RequestQuery` doesn't need old state of `SC` unless the `prove=true` parameter is set. The SMT merkle proof must be included in the `abci.ResponseQuery` only if both `SC` and `SS` have a snapshot for requested version.
105
105
106
106
Moreover, Cosmos SDK could provide a way to directly access a historical state. However, a state machine shouldn't do that - since the number of snapshots is configurable, it would lead to nondeterministic execution.
0 commit comments