[Anvil] Impersonation

[alindima]

Configured via CLI or impersonation RPCs: anvil_impersonateAccount, anvil_stopImpersonatingAccount, anvil_autoImpersonateAccount, eth_sendUnsignedTransaction.

We need to handle this in two places: during txpool validation (with the validate_transaction runtime API) and during runtime execution of the transaction. Txpool ends up calling a runtime API (validate_transaction) and into the Checkable trait implementation of the UncheckedExtrinsic. The Checkable implementation of UnsignedExtrinsic ends up calling a hostcall to verify the signature, in sp_io::crypto: https://github.com/paritytech/polkadot-sdk/blob/e117602f60bf3a0debe6843c94278275e3912a40/substrate/primitives/io/src/lib.rs#L885

We need to add a magic signature, which ends up bypassing the signature checks.
There are two options:

• We can impl a new Checkable type. This would mean modifying the runtime. Not ideal because long term we want to have this work with arbitrary runtimes (even forked)
• We could override the hostcall that performs the signature checks. Not sure how easy this is, but would enable us to not modify the runtime.

[alindima]

See an example of a similar override here: https://github.com/polytope-labs/sc-simnode/blob/6b871bc7bc30d83d526631f925d43efee82dbec6/simnode/src/overrides.rs#L27

And then using it like so: ExtendedHostFunctions<sp_io::SubstrateHostFunctions, SignatureVerificationOverride>

[iulianbarbu]

There is a roadblock here. We'd need to override the secp256k1_ecdsa_recover host function, which returns the sender's public key in the runtime code based on the tx signature and the tx body hash, but the actual public address used in the context of validation/execution is the hash of the public key. The fetching of the public key and its hashing is handled by a function of pallet-revive::evm::api::signature::TransactionSigned, which is not overridable: https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/revive/src/evm/api/signature.rs#L135. We'd need to make this function overridable so that we get an implementation of impersonation where attached tx signatures are the actual senders public address, that will be forwarded by the custom function in the runtime's context.

Not sure to what interface makes sense to move this function so that we override it. Maybe someone from pallet-revive team has an idea, or even a better route.

LE:

We'd need to make this function overridable so that we get an implementation of impersonation where attached tx signatures are the actual senders public address, that will be forwarded by the custom function in the runtime's context.

Forwarding should happen though only for impersonated addresses. We have another problem here where even if we override the function, we still need to access some static context where we can find that a certain sender address should be impersonated, otherwise we will not be able to tell between cases like impersonate certain addresses, impersonate all, or no impersonation.

[iulianbarbu]

Forwarding should happen though only for impersonated addresses. We have another problem here where even if we override the function, we still need to access some static context where we can find that a certain sender address should be impersonated, otherwise we will not be able to tell between cases like impersonate certain addresses, impersonate all, or no impersonation.

I think there is a way to avoid exposing context to the recover_eth_address, if it can be made overridable. ETH signatures have 65bytes, where last byte is a recovery id that can take 4 values (0,1,2,3). When impersonating, we can tell whether we're impersonating by enconding the information in the recovery id. E.g. we'll not use the default 0,1,2,3 as it is done for valid signatures, but use something > 3 to encode the following infos:

1. 4 means we impersonate a certain public address, which is set in the first 20 bytes of the signature.
2. 5 means we impersonate all. Similar to 4, we'd need to put the public address of the sender in the signature and return it from the function we must make overridable. Overall it doesn't differ much from previous case, so we can simply choose to use same 4 for both. Where the difference is in the sendTransaction logic, where if impersonate all is set, we don't look in an allow list of addresses to fake the signature, but fake for every address.
3. 0/1/2/3 is regular valid sig case.
4. something totally different means faulty behavior

[iulianbarbu]

Opened paritytech/polkadot-sdk#9785 with a proposed solution for enabling overriding the code which we want to override.

[iulianbarbu]

Summary: this issue is close to being done, final reviews waiting on #332 .