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
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
crates/cast/src/cmd/validate_auth.rs
Outdated
| // 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
crates/cast/src/cmd/validate_auth.rs
Outdated
| // 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.
There was a problem hiding this comment.
yes, although i have realized my implementation is still incomplete, because all the valid authorizations before the current tx in the given block can also have an authorization that can affect the running nonce of current recovered authority, which means i have to validate authorizations for all txs before current tx to get the real running nonce and accurate validation.
0xferrous
force-pushed
the
push-mylruvmswxuw
branch
from
e735b88 to
92133e1
Compare
0xferrous
force-pushed
the
push-mylruvmswxuw
branch
from
92133e1 to
05474f8
Compare
| /// Validates all the authorizations in an EIP-7702 transaction. It does so by validating the | ||
| /// nonce and chain id for each of the recovered authority from the given authorizations. | ||
| /// | ||
| /// For nonce validation, it builds a "running nonce" map by processing all transactions | ||
| /// before the target transaction in the same block: | ||
| /// - For each transaction sender, tracks their next expected nonce (tx.nonce + 1) | ||
| /// - For each valid authorization in previous transactions, also increments that authority's | ||
| /// running nonce (since valid authorizations execute and increment the authority's nonce) | ||
| /// - If an authority is not in the running nonce map, fetches their nonce at block - 1 | ||
| /// | ||
| /// Then, for each authorization in the target transaction: | ||
| /// - Validates nonce against the running nonce | ||
| /// - If the authorization is valid (both chain and nonce), increments the running nonce for | ||
| /// that authority (for subsequent authorizations in the same transaction) | ||
| /// | ||
| /// For chain id validation, it checks if it is zero or the same chainid as the current chain. |
0xferrous
force-pushed
the
push-mylruvmswxuw
branch
from
05474f8 to
113f249
Compare
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
113f249 to
d654a9b
Compare
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