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

Adds mainnet archival rpc and fixes ref-finance example #57

Merged
merged 6 commits into from
Jan 24, 2022

Conversation

ChaoticTempest
Copy link
Member

This will fix the issue with #49. This was because ref-finance contract on mainnet on updated and so did some deposit requirements get upped. With this PR, to remedy the issue, mainnet archival rpc was added so we can grab the contract from a specific block height instead of the latest block height

workspaces/src/rpc/patch.rs Outdated Show resolved Hide resolved
workspaces/src/rpc/patch.rs Outdated Show resolved Hide resolved

// type taken from near_primitives::hash::CryptoHash.
/// CryptoHash is type for storing the hash of a specific block.
pub struct CryptoHash(pub [u8; 32]);
Copy link
Contributor

Choose a reason for hiding this comment

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

why use newtype for this over just an alias of [u8; 32] for simplicity?

Copy link
Member Author

Choose a reason for hiding this comment

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

I just took whatever was in near_primitives. It's a newtype there, so stuck with that. I don't know if changing it to an alias of [u8; 32] would make it harder to transition later when near_primitives is 1.0

Copy link
Contributor

Choose a reason for hiding this comment

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

why would it be hard to transition? Just wrapping the bytes passed in with CryptoHash internally? Am I missing something with what you mean here?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm just thinking whether or not if we end up just exposing near_primitives::hash::CryptoHash later and its still just a newtype which would make it a breaking change to transition over to. But maybe not a huge concern if we force everyone to just rely on our CryptoHash from workspaces

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah, the primitives type prob shouldn't be tied to our API. I'm not sure if I'm misunderstanding what you're saying here though. Why would we ever need to expose the primitives type to be a part of our API?

Copy link
Member Author

Choose a reason for hiding this comment

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

I was just thinking of this case, because there was a conversation we had about potentially exposing the near_primitives/near_account_id types once they released 1.0. But regardless of that, I think the newtype here would be better suited since it might be harder for users to create CryptoHashes if it was just an alias of [u8; 32]. The FromStr impl should allow us to create it easily

@ChaoticTempest
Copy link
Member Author

I'll just merge this one in since this one has a fix for the other PRs stalling. If there's anymore concerns, we can just address them in a later ticket/PR

@ChaoticTempest ChaoticTempest merged commit 668a9af into main Jan 24, 2022
@ChaoticTempest ChaoticTempest deleted the feat/mainnet-archival branch January 24, 2022 18:27
@frol frol mentioned this pull request Oct 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants