d2afb91e99
* add proto, add boilerplates * add canonical * fix tests * add vote signing test * Update internal/consensus/msgs_test.go * modify state execution in progress * add extension signing * add extension signing * VoteExtension -> ExtendVote * modify state execution in progress * add extension signing * verify in progress * modify CommitSig * fix test * apply review * update data structures * Apply suggestions from code review * Add comments * fix test * VoteExtensionSigned => VoteExtensionToSigned * Apply suggestions from code review Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com> * *Signed -> *ToSign * add Vote to RequestExtendVote * add example VoteExtension * apply reviews * fix vote * Apply suggestions from code review Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com> Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com> * fix typo, modify proto * add abcipp_kvstore.go * add extension test * fix test * fix test * fix test * fit lint * uncomment test * refactor test in progress * gofmt * apply review * fix lint Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com> Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com>
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.