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

Accept 0x addresses from CLI (and optionally RPC) #403

Closed
adlrocha opened this issue Aug 8, 2023 · 3 comments
Closed

Accept 0x addresses from CLI (and optionally RPC) #403

adlrocha opened this issue Aug 8, 2023 · 3 comments
Labels
bug Something isn't working s:ipc

Comments

@adlrocha
Copy link
Contributor

adlrocha commented Aug 8, 2023

Issue type

Bug

Have you reproduced the bug with the latest dev version?

Yes

Version

v0.5.0

Custom code

Yes

OS platform and distribution

No response

Describe the issue

Right now, it is really confusing to determine when one should use 0x and t4 addresses from the agent. The reason for this is that we use Address throughout all of the IPC agent except when we interact with the ETH RPC. This implies the use of fvm_shared::Address as the underlying type. However, the address used to interact with the subnet, and all the Ethereum tooling, expects a 0x. This leads to many users using their 0x instead of f4 address as arguments. Even our config expects a 0x address for the default accounts in fevm instead of the underlying f4.

A potential implementation could be through a top-level Address wrapper type that can be converted into both f4 and 0x as described in #407.

Repro steps

N/A

Relevant log output

No response

@adlrocha adlrocha added the bug Something isn't working label Aug 8, 2023
@jsoares
Copy link
Contributor

jsoares commented Aug 9, 2023

Also important to take into account (currently) split key stores and the potential need to search for an appropriate key using the converted format.

@adlrocha
Copy link
Contributor Author

adlrocha commented Aug 9, 2023

@mturilin, this is the issue that I mentioned yesterday that may fit perfectly our first PDR.

@adlrocha
Copy link
Contributor Author

Fixed in #344

@jsoares jsoares transferred this issue from consensus-shipyard/ipc-libs Dec 19, 2023
@jsoares jsoares added the s:ipc label Dec 19, 2023
@jsoares jsoares closed this as not planned Won't fix, can't repro, duplicate, stale Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working s:ipc
Projects
No open projects
Status: Done
Development

No branches or pull requests

2 participants