-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Import all SMT files into cosmos-sdk without any build errors #232
Conversation
b8cf96f
to
27ccc2f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the bulk changes here are from https://github.com/vulcanize/cosmos-sdk/releases/tag/v0.46.0-smt-0.0.5-alpha?
Can we instead cherry-pick changes and then resolve merge conflicts? Even if github does not give any real guarantees about the commits being the same it will help reviewing the PR a bit IMO.
Would you prefer cherry picking the commits from Vulkanize and then layering commits on top of that to resolve changes needed for v0.46 -> v0.45? |
68ab1f1
to
9aa377e
Compare
e37f7c9
to
a292da8
Compare
553781e
to
e0baa95
Compare
Looks like there's a race condition in a test sometimes but unable to reproduce locally. Will move on to #111 and build on top of this for now. Please feel free to suggest any possible ways to resolve this. Things tried: adding a sync.Mutex lock/unlock around write and GetKVStore in |
Please correct me if I am wrong but wouldn't that mean looking at manav/backport_smt...vulcanize:cosmos-sdk:release-v0.46.0-smt-0.0.5-alpha and cherry-picking commits? It seems like there are 1k+ commits there which might not be worth the effort |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you rebase manav/backport_smt
against the latest default branch? As-is, this PR is useless since it's based on a stale Cosmos SDK release.
e648aa4
to
cb35c3a
Compare
traceContext types.TraceContext | ||
traceWriter io.Writer | ||
traceContext types.TraceContext | ||
traceContextMutex sync.RWMutex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should the mutex be a pointer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should that affect functionality in this case? I tried searching how mutexes are used in the cosmos-sdk currently and it seems like there are plenty of places where they are not pointers:
https://github.com/cosmos/cosmos-sdk/blob/2646b474c7beb0c93d4fafd395ef345f41afc251/snapshots/store.go#L30
https://github.com/cosmos/cosmos-sdk/blob/2646b474c7beb0c93d4fafd395ef345f41afc251/types/config.go#L21
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just rebased on top of 0.45.5 instead, and that seems to have fixed the issue. Thanks Evan! Appreciate your help :)
cb35c3a
to
207b382
Compare
Rebased to 0.45.5 which is what ethermint uses |
What is the status of this PR? Ethermint now uses 0.46 |
good from my side, waiting on review |
I don't really follow. I thought this backports code from 0.46 to an older version of the SDK? Why would that still be necessary when you'd be now using 0.46 directly? Are you sure this is good to go as is @Manav-Aggarwal? |
Also, related to this:
You should compare the diff of their work from where they forked off and not against your branch in our fork. If you look at As a general note: I would not take the changes of others and commit them under a different account if avoidable (you lose the git history by that and it attributes code to the wrong account). There might be scenarios where this is unavoidable maybe. But git would allow different strategies here at least: merging one branch into another, or the aforementioned cherry-picking. another option is interactive rebase (with picking the relevant changes). |
Since cosmos-sdk v0.46 supports tendermint v0.34 now, this PR is not needed. We'll be closing this PR and prioritizing #245 directly in cosmos-sdk 0.46 |
Description
Closes: #231
For Cevmos' Block Fraud Proofs we need to have a SMT based store. We want to try and backport the one from v0.46.x.
Follow up would be in ##111
Please use manav/backport_smt-add_files...vulcanize:cosmos-sdk:release-v0.46.0-smt-0.0.5-alpha for comparing this to the vulcanize implementation if useful for review
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change