bft blockchain consensus consistency cryptocurrency cryptography db distributed-systems go

History

Anton Kaliaev e13b4386ff abci: modify Client interface and socket client (#5673 ) `abci.Client`: - Sync and Async methods now accept a context for cancellation * grpc client uses context to cancel both Sync and Async requests * local client ignores context parameter * socket client uses context to cancel Sync requests and to drop Async requests before sending them if context was cancelled prior to that - Async methods return an error * socket client returns an error immediately if queue is full for Async requests * local client always returns nil error * grpc client returns an error if context was cancelled before we got response or the receiving queue had a space for response (do not confuse with the sending queue from the socket client) - specify clients semantics in [doc.go](https://raw.githubusercontent.com/tendermint/tendermint/27112fffa62276bc016d56741f686f0f77931748/abci/client/doc.go) `mempool.TxInfo` - add optional `Context` to `TxInfo`, which can be used to cancel `CheckTx` request Closes #5190		4 years ago
..
README.md	lint: add markdown linter (#5254)	4 years ago
helpers.go	test/e2e: fix secp failures (#5649)	4 years ago
kvstore.go	deps: bump tm-db to 0.6.0 (#5058)	5 years ago
kvstore_test.go	abci: modify Client interface and socket client (#5673)	4 years ago
persistent_kvstore.go	test/e2e: fix secp failures (#5649)	4 years ago

README.md

KVStore

There are two app's here: the KVStoreApplication and the PersistentKVStoreApplication.

KVStoreApplication

The KVStoreApplication is a simple merkle key-value store. Transactions of the form key=value are stored as key-value pairs in the tree. Transactions without an = sign set the value to the key. The app has no replay protection (other than what the mempool provides).

PersistentKVStoreApplication

The PersistentKVStoreApplication wraps the KVStoreApplication and provides two additional features:

persistence of state across app restarts (using Tendermint's ABCI-Handshake mechanism)
validator set changes

The state is persisted in leveldb along with the last block committed, and the Handshake allows any necessary blocks to be replayed. Validator set changes are effected using the following transaction format:

"val:pubkey1!power1,pubkey2!power2,pubkey3!power3"

where pubkeyN is a base64-encoded 32-byte ed25519 key and powerN is a new voting power for the validator with pubkeyN (possibly a new one). To remove a validator from the validator set, set power to 0. There is no sybil protection against new validators joining.