Problem (WIP #1313): light client doesn't verify the fetched staking state

[yihuang]

Solution:

• Support query merkle inclusion proof
• Also support query historical staking state
• Query json encoded staking from abci_query directly Problem: Some abci_query returns binary format which is hard to parse #1464

This feature(query historical staked state) is also needed to make the reward integration tests more stable.
Added a new abci_query path "staking" which is like "account", but it returns JSON directly, also support the new features (historical query, proof), the next step will be update the "staking_state" API in client-rpc and client-cli to use the new one.

[codecov]

Codecov Report

Merging #1466 into master will increase coverage by 0.06%.
The diff coverage is 76.74%.

@@            Coverage Diff             @@
##           master    #1466      +/-   ##
==========================================
+ Coverage   64.45%   64.51%   +0.06%     
==========================================
  Files         160      160              
  Lines       21632    21673      +41     
==========================================
+ Hits        13942    13983      +41     
  Misses       7690     7690              

Impacted Files	Coverage Δ
chain-storage/src/lib.rs	53.39% <0.00%> (-1.61%)	⬇️
chain-storage/src/api.rs	86.59% <50.00%> (-3.29%)	⬇️
chain-abci/src/app/query.rs	64.00% <81.25%> (+2.05%)	⬆️
chain-abci/src/app/app_init.rs	77.87% <100.00%> (+0.29%)	⬆️
chain-abci/tests/abci_app.rs	94.82% <100.00%> (+0.08%)	⬆️
chain-core/src/state/account.rs	85.89% <0.00%> (+0.42%)	⬆️
chain-core/src/state/account/address.rs	88.63% <0.00%> (+20.45%)	⬆️

[tomtau]

is the new column really required / does this need a breaking change? this is only for querying and if one provides the tx-query flag, it should be storing historical app states and each app state contains the staking version?

[yihuang]

is the new column really required / does this need a breaking change? this is only for querying and if one provides the tx-query flag, it should be storing historical app states and each app state contains the staking version?

The current historical app states only stores ChainState, staking_version is not in that, so an alternative solution is to put staking_version into the ChainState, or store historical ChainNodeState, I'm not sure.

[tomtau]

is the new column really required / does this need a breaking change? this is only for querying and if one provides the tx-query flag, it should be storing historical app states and each app state contains the staking version?

The current historical app states only stores ChainState, staking_version is not in that, so an alternative solution is to put staking_version into the ChainState, or store historical ChainNodeState, I'm not sure.

all the options are breaking -- a new column is probably the simplest.
I guess it's not possible to retroactively create this column, so the easiest migration will be to sync from scratch?

[yihuang]

all the options are breaking -- a new column is probably the simplest.
I guess it's not possible to retroactively create this column, so the easiest migration will be to sync from scratch?

Yes, the information was not there.

[tomtau]

I guess the column is the simplest breaking change -- just one thing is whether this could function without historical states?
Also I wouldn't mark this as "fix #1313", as client wasn't updated to verify fetched staking states in this PR?

[yihuang]

I guess the column is the simplest breaking change -- just one thing is whether this could function without historical states?

#1466 (comment)

Also I wouldn't mark this as "fix #1313", as client wasn't updated to verify fetched staking states in this PR?

Yes, I'll remove the "fix".

[tomtau]

bors r+

[bors]

Build succeeded:

• continuous-integration/travis-ci/push
• drone-hw/push