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

accounts/abi/bind: allow to specify signer on transactOpts #21356

Merged
merged 8 commits into from
Dec 8, 2020

Conversation

MariusVanDerWijden
Copy link
Member

@MariusVanDerWijden MariusVanDerWijden commented Jul 22, 2020

This commit enables users to specify which signer they want to use while creating their transactOpts.
Previously all contract interactions used the homestead signer. Now a user can specify whether they
want to sign with homestead or EIP155 and specify the chainID which adds another layer of security.

closes #16484

This PR changes the interface of New{}Transactor, so it is a breaking change for everyone who uses the bind package to create their signer.

@karalabe
Copy link
Member

Wondering if we should use a chainid instead of a signer as a new parameter? The auth package is mostly a convenience thing so you don't need to construct your transactor manually and so you don't need to care about the details. It seems sane to me to explicitly enforce EIP155 in a convenience method and let the user do the manual dance if they want he unsecure version. It's also easier to tell the users to pass the chainid, than to "construct an EIP155 signer".

What are your thoughts? I'm open to alternatives, just looking at it from an API perspective.

Also this PR would break all existing code relying on abigen generated contracts :P

@MariusVanDerWijden
Copy link
Member Author

Yeah I think that might be a better interface, we don't really want to encourage homestead signers anymore, right?
I'll change it to use ChainID and eip155 signers.
About breaking all existing contracts: Yeah but I think the change might be so useful that it outweighs the inconveniences.
Only problem I can see is that Dapp developers have to introduce a global variable to identify the network, default it to 1 and set it to 1337 in testing. Oh btw It is not really documented that all simulated backends run chains with chainID 1337 in the source code, shall I add some docu there?

@karalabe
Copy link
Member

The more docs the better :)

Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

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

Makes sense to me, but I'm not really well versed in that whole abi/bind thingy, I've never used it and am not the best person to give a thumbs-up :)

Copy link
Member

@gballet gballet left a comment

Choose a reason for hiding this comment

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

In order not to break contracts right off the bat, It should be possible to keep the legacy system and display a deprecation warning when the function is used, and offer the new API with a slightly different name. Leave it like that for a few releases and then remove it.

@MariusVanDerWijden
Copy link
Member Author

Hmm I restored the old functions now, I'm not a huge fan, but at least I'll get a purely red pr in some months

Copy link
Member

@gballet gballet left a comment

Choose a reason for hiding this comment

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

LGTM

accounts/abi/bind/auth.go Outdated Show resolved Hide resolved
accounts/abi/bind/auth.go Outdated Show resolved Hide resolved
@MariusVanDerWijden
Copy link
Member Author

cc @fjl

…thereum#21545)

This allows users to estimate gas on top of arbitrary blocks as well as pending and latest.
Tracing on pending is useful for most users as it takes into account the current txpool while
tracing on latest might be useful for users that have little to know knowledge of the current
transactions in the network.

If blockNrOrHash is not specified, estimateGas defaults to pending
This commit enables users to specify which signer they want to use while creating their transactOpts.
Previously all contract interactions used the homestead signer. Now a user can specify whether they
want to sign with homestead or EIP155 and specify the chainID which adds another layer of security.
@MariusVanDerWijden
Copy link
Member Author

cc @fjl

@MariusVanDerWijden MariusVanDerWijden deleted the eip155signer branch November 30, 2021 15:24
gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Jun 20, 2024
gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Jan 7, 2025
gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Jan 9, 2025
gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Jan 10, 2025
gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Jan 10, 2025
gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Jan 10, 2025
gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Jan 10, 2025
gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Jan 14, 2025
gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Jan 16, 2025
gzliudan added a commit to gzliudan/XDPoSChain that referenced this pull request Jan 17, 2025
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.

Abi.bind should use EIP155Signer (not HomesteadSigner) for new transactions.
7 participants