mirror of https://github.com/tendermint/tendermint.git synced 2026-04-29 11:56:56 +00:00

Files

Sam Kleinman 61a81279bd abci: make tendermint example+test clients manage a mutex (#7978 )

This is the first step in removing the mutex from ABCI applications:
making our test applications hold mutexes, which this does, hopefully
with zero impact. If this lands well, then we can explore deleting the
other mutexes (in the ABCI server and the clients.) While this change
is not user impacting at all, removing the other mutexes *will* be. 

In persuit of this, I've changed the KV app somewhat, to put almost
all of the logic in the base application and make the persistent
application mostly be a wrapper on top of that with a different
storage layer.

2022-02-23 22:39:47 +00:00

helpers.go

libs: remove most of libs/rand (#6364 )

2021-04-23 16:00:35 +02:00

kvstore_test.go

abci: make tendermint example+test clients manage a mutex (#7978 )

2022-02-23 22:39:47 +00:00

kvstore.go

abci: make tendermint example+test clients manage a mutex (#7978 )

2022-02-23 22:39:47 +00:00

persistent_kvstore.go

abci: make tendermint example+test clients manage a mutex (#7978 )

2022-02-23 22:39:47 +00:00

README.md

abci: Vote Extension 1 (#6646 )

2022-02-02 11:51:13 +01:00

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 three 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.