Skip to content
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.

ABCI logic "sanity checks" #49

Open
tomtau opened this issue Apr 30, 2019 · 1 comment
Open

ABCI logic "sanity checks" #49

tomtau opened this issue Apr 30, 2019 · 1 comment

Comments

@tomtau
Copy link
Contributor

tomtau commented Apr 30, 2019

There are a few protocol assumptions that are currently unchecked / trusted, e.g. the block execution state machine:

BeginBlock -> [DeliverTx]* -> EndBlock -> Commit -> BeginBlock -> ...

This could be encoded in session types: https://github.com/Munksgaard/session-types

tomtau added a commit to crypto-com/thaler that referenced this issue May 6, 2019
Solution: added a basic definition for rewards pool state representation + refactor around BlockHeight opaque type
* extended InitConfig to contain the dedicated ERC20 addresses that will form the rewards pool at genesis
* fixed chain-core dependencies
* changed dev-utils to allow a more flexible config generation
* extracted out app_hash computation into chain-core's `computer_app_hash` and extended InitChain handling to persist rewards pool state
* added a basic modified calculation mechanism from https://github.com/input-output-hk/rust-cardano
* removed error-prone deref in coin
* removed ABCI  app sanity checks, as they should be done in the ABCI library (added a link to the issue tendermint/rust-abci#49 )
* removed .iter() calls where possible
@tomtau
Copy link
Contributor Author

tomtau commented Oct 31, 2019

One extra sanity check could be in Info: https://tendermint.com/docs/spec/abci/abci.html#messages -- the info request contains the Tendermint versioning information; this could be checked against some constant in the ABCI server implementation (currently, we maintain this file: https://github.com/tendermint/rust-abci/blob/develop/version.txt but afaik it's not used in runtime)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant