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
mattsse
left a comment
mattsse
left a comment
There was a problem hiding this comment.
still a bit unclear what this exactly validates
could you please add some additional docs
| #[derive(Debug, clap::Parser)] | ||
| pub struct ValidateAuthArgs { | ||
| /// Transaction hash. | ||
| tx_hash: B256, | ||
|
|
||
| #[command(flatten)] | ||
| rpc: RpcOpts, | ||
| } |
There was a problem hiding this comment.
this needs some docs, what this actually does
| // Extract authorization list from EIP-7702 transaction | ||
| let auth_list = match &*tx.inner.inner { | ||
| AnyTxEnvelope::Ethereum(TxEnvelope::Eip7702(signed_tx)) => { | ||
| signed_tx.tx().authorization_list.clone() | ||
| } | ||
| _ => { | ||
| eyre::bail!("transaction is not an EIP-7702 transaction"); | ||
| } | ||
| }; |
There was a problem hiding this comment.
I believe we can use the trait Transaction's function for this
| // Build a map of address -> running nonce from txs in this block up to and including | ||
| // our tx | ||
| let mut running_nonces: HashMap<Address, u64> = HashMap::new(); |
There was a problem hiding this comment.
i assume this is because naively getting the nonce at the block before this assumes there is only 1 transaction from the sender account in the current block, so we need to account for the fact that the account might send 1 or more txs before their eip7702 authorization which would bump the nonce.
3 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