Problem: don't support debug query result (backport: #328)

[yihuang]

Solution:

• update cosmos-sdk dependency, the feature is backported to cosmos-sdk 0.44.x

👮🏻👮🏻👮🏻 !!!! REFERENCE THE PROBLEM YOUR ARE SOLVING IN THE PR TITLE AND DESCRIBE YOUR SOLUTION HERE !!!! DO NOT FORGET !!!! 👮🏻👮🏻👮🏻

PR Checklist:

• Have you read the CONTRIBUTING.md?
• Does your PR follow the C4 patch requirements?
• Have you rebased your work on top of the latest master?
• Have you checked your code compiles? (make)
• Have you included tests for any non-trivial functionality?
• Have you checked your code passes the unit tests? (make test)
• Have you checked your code formatting is correct? (go fmt)
• Have you checked your basic code style is fine? (golangci-lint run)
• If you added any dependencies, have you checked they do not contain any known vulnerabilities? (go list -json -m all | nancy sleuth)
• If your changes affect the client infrastructure, have you run the integration test?
• If your changes affect public APIs, does your PR follow the C4 evolution of public contracts?
• If your code changes public APIs, have you incremented the crate version numbers and documented your changes in the CHANGELOG.md?
• If you are contributing for the first time, please read the agreement in CONTRIBUTING.md now and add a comment to this pull request stating that your PR is in accordance with the Developer's Certificate of Origin.

Thank you for your code, it's appreciated! :)

[thomas-nguy]

why is this PR pointed to release/v0.6.x?

[yihuang]

why is this PR pointed to release/v0.6.x?

it's a backport, the feature is backported to cosmos-sdk 0.44.x, for easier debugging.

[thomas-nguy]

cosmos/cosmos-sdk@v0.44.3...v0.44.6

[yihuang]

actually, it's: cosmos/cosmos-sdk@v0.44.3...8a26cd1

[thomas-nguy]

looks fine after a quick check of the changelog of cosmos sdk

Just to confirm, events are not store in consensus hash right?
cosmos/cosmos-sdk#10631

[yihuang]

Just to confirm, events are not store in consensus hash right? cosmos/cosmos-sdk#10631

I think it is stored in consensus hash, so it looks like breaking, maybe better to cherry-pick to a custom fork then.

[tomtau]

I think events used to be in the consensus in TM 0.33 or something like that, but it was later removed (it's up to ABCI apps to do it themselves now)

[yihuang]

I think events used to be in the consensus in TM 0.33 or something like that, but it was later removed (it's up to ABCI apps to do it themselves now)

that's great, @mofhusseini has run a node with this version, haven't seen app hash mismatch issue yet.

[tomtau]

Just for reference: events were perhaps hashed into block headers pre-0.33, not hashed in 0.33, but considered to be hashed again for 0.34, but it was decided not to hash them: tendermint/tendermint#5134 (comment) :D
I believe it's still the case and even 0.35 remains like this, but I didn't follow the development in detail -- @JayT106 can double-check it.

[JayT106]

@tomtau is correct, the current block header doesn't have the event hash in v0.34 and later release.

Only LastResultsHash has been stored in the header to represent the hash of the transactions' results