Skip to content
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: Eth wallet contract implementation #10850

Merged
merged 14 commits into from
Apr 8, 2024

Conversation

birchmd
Copy link
Contributor

@birchmd birchmd commented Mar 21, 2024

This PR adds the eth wallet contract implementation which will be automatically deployed with eth implicit accounts. This is as per the design outlined in near/NEPs#518 .

It is intentional that the wallet contract implementation is isolated as its own crate and not contained in the broader nearcore workspace. This allows it to be reviewed, tested and audited independently from the rest of the Near code. The crate includes integration tests written using near-workspaces. However, the nearcore integration test related to the wallet contract has also been updated to check that the contract is automatically deployed when creating an eth address and that it works as expected.

This will not be the last PR in this project because I am only adding the logic for the implementation. It still remains to setup the reproducible build pipeline and update the tests which check the contract hashes. Additionally, there are still a few details which need to be finalized: (1) the Ethereum chain ID that will be associated with Near and (2) the Near account ID that will have the eth address registrar contract deployed. The eth address registrar contract stores a reverse lookup of Ethereum-like address to Near account IDs. It is necessary for the wallet contract to detect faulty relayers.

However this (relatively large) PR can be reviewed and merged, and the points above will be addressed in much more manageable follow-up PRs.

@birchmd birchmd added C-enhancement Category: An issue proposing an enhancement or a PR with one. T-core Team: issues relevant to the core team T-Aurora Team: issues relevant to the Aurora team rust Pull requests that update Rust code labels Mar 21, 2024
@birchmd birchmd requested a review from a team as a code owner March 21, 2024 13:26
@@ -121,6 +121,8 @@ arbitrary = { version = "1.2.3", features = ["derive"] }
arc-swap = "1.5"
assert_matches = "1.5.0"
async-trait = "0.1.58"
aurora-engine-transactions = { git = "https://github.com/aurora-is-near/aurora-engine.git", tag = "3.6.1" }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason these are a git dependency?

We should avoid git dependencies where possible. The fact that this is referencing a tag suggests to me that these should be on crates.io.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aurora doesn't have a regular process for releasing crates to crates.io. So for now a git dep is required to use the crate. But this is easy to update in the future if Aurora does start releasing crates.

Copy link
Collaborator

@nagisa nagisa Mar 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should really be a not "if Aurora starts", but rather "integrating with the rest of the ecosystem ought to be a very strong incentive for Aurora to start releasing crates."

We can't really audit git tags, they are not reproducible and might just make the build process slower every time as cargo can't cache git repositories globally.

Does it block this PR? Probably not. But waiting for Aurora to realize these problems on their own before an action is taken is also not great.

Copy link

codecov bot commented Mar 21, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.39%. Comparing base (b2c82f9) to head (37175d3).
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #10850      +/-   ##
==========================================
+ Coverage   71.37%   71.39%   +0.02%     
==========================================
  Files         760      760              
  Lines      152772   152772              
  Branches   152772   152772              
==========================================
+ Hits       109039   109075      +36     
+ Misses      39207    39172      -35     
+ Partials     4526     4525       -1     
Flag Coverage Δ
backward-compatibility 0.24% <ø> (ø)
db-migration 0.24% <ø> (ø)
genesis-check 1.43% <ø> (ø)
integration-tests 37.08% <ø> (+0.11%) ⬆️
linux 69.84% <ø> (+<0.01%) ⬆️
linux-nightly 70.86% <ø> (+0.02%) ⬆️
macos 54.41% <ø> (+<0.01%) ⬆️
pytests 1.65% <ø> (ø)
sanity-checks 1.44% <ø> (ø)
unittests 67.02% <ø> (+<0.01%) ⬆️
upgradability 0.29% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@staffik
Copy link
Contributor

staffik commented Mar 25, 2024

I started reviewing this but it might take a while. I plan to send feedback tomorrow.

Copy link
Collaborator

@nagisa nagisa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q for Adam: do we need to have the contract checked-in? Why aren't we building it on demand and e.g. verifying its reproducibility through “other” means?

For wallet tests lets see if we can (re-)use the infrastructure in near-test-contracts. At least that way all the relevant stuff stays in the same spot. Ideally these contracts would get built on the fly like test-contract-rs is, but its not a too big of a deal if doing so is really difficult.


I don't feel qualified to review the contract itself, and I don't think I have the capacity at the moment to become able. It looks like Adam is already on the hook for that anyhow, but please definitely talk with N1 EMs to prioritize it accordingly if that's not the case.

@@ -805,6 +897,16 @@ dependencies = [
"hashbrown 0.11.2",
]

[[package]]
name = "borsh"
version = "0.10.3"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please investigate upgrading this dependency.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been done on the Aurora side. But it hasn't been released as a tag yet on GitHub. This will be resolved when we next upgrade the Aurora dependency.

@@ -6526,6 +7068,19 @@ version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ae1a47186c03a32177042e55dbc5fd5aee900b8e0069a8d70fba96a9375cd012"

[[package]]
name = "sha2"
version = "0.9.9"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmph. I know we don't do a best job of keeping nearcore's dependencies up-to-date ourselves, but this was one merge button away…

@bowenwang1996
Copy link
Collaborator

@staffik any updates on the review?

Copy link
Contributor

@staffik staffik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work, looks impressive!
Apologies for delay, we are absorbed in statelessnet issues.
I did not check test code yet and will look into the issue of checking-in the contract.
I am not qualified to review the contract too, but I heard there will be a proper audit later.

@birchmd
Copy link
Contributor Author

birchmd commented Apr 3, 2024

Thanks for the review @staffik ! I think I have addressed all your comments now.

the issue of checking-in the contract

I started working on this here. I was planning on pushing the commit in another PR after this one is merged.

@staffik
Copy link
Contributor

staffik commented Apr 3, 2024

Thanks for the review @staffik ! I think I have addressed all your comments now.

the issue of checking-in the contract

I started working on this here. I was planning on pushing the commit in another PR after this one is merged.

There are 3 comments left and I will quickly look at test-related code now.

@staffik
Copy link
Contributor

staffik commented Apr 3, 2024

Thanks for the review @staffik ! I think I have addressed all your comments now.

the issue of checking-in the contract

I started working on this here. I was planning on pushing the commit in another PR after this one is merged.

There are 3 comments left and I will quickly look at test-related code now.

Sorry, I underestimated, will finish tomorrow morning.
We will need an approval from near code owner to be able to merge.

Copy link
Contributor

@staffik staffik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Second part of review.

Copy link
Contributor

@staffik staffik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, amazing work!

Copy link
Collaborator

@akhi3030 akhi3030 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approving to unblock.

@birchmd birchmd enabled auto-merge April 8, 2024 13:55
@birchmd birchmd added this pull request to the merge queue Apr 8, 2024
Merged via the queue into near:master with commit ce68b7c Apr 8, 2024
29 checks passed
@birchmd birchmd deleted the eth-wallet-contract branch April 8, 2024 14:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. rust Pull requests that update Rust code T-Aurora Team: issues relevant to the Aurora team T-core Team: issues relevant to the core team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants