core/types: updates for EIP-7702 API functions #30933
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The signing key should be passed first, because it is usually in a variable,
while the authorization will often be a literal.
Compare
a, err := types.SignAuthorization(types.SetCodeAuthorization{
ChainID: getChainID(),
Nonce: getNonce(),
}, key)
with
a, err := types.SignAuthorization(key, types.SetCodeAuthorization{
ChainID: getChainID(),
Nonce: getNonce(),
})
fjl
requested review from
s1na,
lightclient,
holiman and
rjl493456442
as code owners
|
Btw, just to mention that we still need to support SetCodeTx in txpool |
fjl
added a commit
to fjl/go-ethereum
that referenced
this pull request
Dec 18, 2024
As a follow-up to ethereum#30933, I propose to also use the SetCode prefix in our internal APIs for the authorization list.
fjl
added a commit
that referenced
this pull request
Dec 19, 2024
As a follow-up to #30933, I propose to also use the SetCode prefix in our internal APIs for the authorization list.
GrapeBaBa
pushed a commit
to optimism-java/shisui
that referenced
this pull request
Dec 23, 2024
Here I am proposing two small changes to the exported API for EIP-7702: (1) `Authorization` has a very generic name, but it is in fact only used for one niche use case: authorizing code in a `SetCodeTx`. So I propose calling it `SetCodeAuthorization` instead. The signing function is renamed to `SignSetCode` instead of `SignAuth`. (2) The signing function for authorizations should take key as the first parameter, and the authorization second. The key will almost always be in a variable, while the authorization can be given as a literal.
GrapeBaBa
pushed a commit
to optimism-java/shisui
that referenced
this pull request
Dec 23, 2024
…30935) As a follow-up to ethereum#30933, I propose to also use the SetCode prefix in our internal APIs for the authorization list.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here I am proposing two small changes to the exported API for EIP-7702:
(1)
Authorizationhas a very generic name, but it is in fact only used for one niche use case: authorizing code in aSetCodeTx. So I propose calling itSetCodeAuthorizationinstead. The signing function is renamed toSignSetCodeinstead ofSignAuth.(2) The signing function for authorizations should take key as the first parameter, and the authorization second. The key will almost always be in a variable, while the authorization can be given as a literal. Compare these two invocations:
with
I feel like the second one is easier to read.