feat(cast): validate-auth #12634
feat(cast): validate-auth #12634
Conversation
0xferrous
requested review from
DaniPopes,
grandizzy,
mattsse,
onbjerg and
zerosnacks
as code owners
0xferrous
force-pushed
the
push-mylruvmswxuw
branch
from
4b83973 to
8beb5dd
Compare
0xferrous
force-pushed
the
push-mylruvmswxuw
branch
from
8beb5dd to
8ad961b
Compare
mattsse
left a comment
mattsse
left a comment
There was a problem hiding this comment.
There is no way to determine the validity of the authorizations just looking at the RPC responses with cast tx
this isn't quite accurate because: we display: recoveredAuthority if the auth is valid
authorizationList [
{recoveredAuthority: 0x6d88AED96570f99f17803AAadCB7d52a903A8000, signedAuthority: {"chainId":"0x1","address":"0xa845c74344fc9405b1fcf712f04668979573c1bf","nonce":"0x0","yParity":"0x0","r":"0x65f49a34f31703fec5612c7022ad9ad3411524f3265f926ff3ad9710ee3c0495","s":"0x254672cc95922e76b069ee1458155cb74d1b179ba1d26239ffb4b220816982e2"}}
]
| #[command(visible_aliases = &["decode-auth"])] | ||
| RecoverAuthority { auth: String }, | ||
|
|
||
| /// Validate EIP-7702 authorizations in a transaction and print validity status. |
There was a problem hiding this comment.
what is being validated here?
just the auth itself?
because for this we only need to fetch the tx itself and perform recovery on this, then this can be simplified
this info is also already included in cast tx (only displays the recovered auth if valid)
so I'm not actually sure how exactly this new command is different
There was a problem hiding this comment.
I don't think the recoveredAuthority in itself tells you whether the authorization was valid because, the signature can be valid, but the nonce may be outdated or too ahead(there is only one acceptable nonce), the chain id can be invalid, etc. Essentially, my intention was to determine which authorizations got "executed", and which got rejected, and this is my attempt at displaying that information.
I think it shows the decoded data and recovered authority from the signature, but it doesn't show the the validity. I had to refer to etherscan for instance when I couldn't figure out why my eoa was not getting delegated
There is no way to determine the validity of the authorizations just looking at the RPC responses with `cast tx` or `cast receipt`. So, we need to build a new command that manually validates the authorizations with the logic laid out in EIP-7702.
0xferrous
force-pushed
the
push-mylruvmswxuw
branch
from
8ad961b to
e735b88
Compare
2 participants
Motivation
There is no way to determine the validity of the authorizations just looking at the RPC responses with
cast txorcast receipt.Solution
So, we need to build a new command that manually validates the authorizations with the logic laid out in EIP-7702.
PR Checklist