Allow account impersonation same as EDR

[BigTava]

Description

Our current account impersonation implementation relies on providing a known signer. This approach breaks down in scenarios where projects incorporate the nonce directly into their contract logic.

In these cases, even if the transaction from points to the impersonated account, the nonce must still come from that account. A simple workaround such as:

let payload = tx.dummy_signed_payload();
return self.send_raw_transaction(Bytes(payload)).await;

is not valid, since the resulting transaction fails signature validation.

To support impersonation correctly, we need to align with the EDR approach for fake signatures. Their method encodes the caller’s address directly into the signature (r and s) and uses a fixed recovery id. This produces deterministic, recognizable “fake signatures” that are still accepted by the runtime while maintaining nonce correctness.

Motivation

Implementing this behavior is the final step to enable full support for account impersonation in the dev-node. This will ensure 100% test coverage for LayerZero cc @TorstenStueber and allow developers to reliably simulate contract interactions involving arbitrary accounts.

[pgherveou]

CC @iulianbarbu that's what we discussed last friday right?

[iulianbarbu]

hey @pgherveou ! It is pretty much the same concern as for anvil-polkadot, yes. However, if it comes to solution, what https://github.com/NomicFoundation/edr/blob/c54a499bbf6a8d335449ecab5bf09af23841fcb0/crates/edr_signer/src/fakeable.rs#L71 does here looks fine except for the recovery id - which I think it is set to a valid recovery id per ethereum rules - at least based on a gpt prompt. My assessment is that for the impersonation logic to also allow for normal address recovery (for non-impersonated cases) we'd need to also embed in the signature some info to tell when the tx is impersonated, so that we can handle the signature accordingly. Embedding that info in some other place of the signature (throughout the 65 bytes) and not in the recovery id byte (the last byte) can actually result in a valid signature, so better to not overlap if we can (even if the chances are super small).

To enable the above I opened paritytech/polkadot-sdk#9786. Would something like this help for this issue as well? cc @BigTava

[BigTava]

Thanks @iulianbarbu. I see we have made lots of progress. Please let us know how to change our current account impersonation implementation when fixed. ccing @bee344 to follow up.

[iulianbarbu]

Thanks @iulianbarbu. I see we have made lots of progress. Please let us know how to change our current account impersonation implementation when fixed.

WIP, almost close to have something in final state. Will keep you posted.

does here looks fine except for the recovery id - which I think it is set to a valid recovery id per ethereum rules

Coming back at something I mentioned previously. We can not tweak the recovery id when considering legacy ETH transactions and that's because the chain id is determined based on the recovery id of the signature. Hence, we should use another way of detecting whether a signature is for an impersonation use case, and for my case I used signatures of following format: [0; 12] + recovered address + [0;33] (65 bytes in total). This should not conflict that easily with a valid signature coming from a pub/private key pair, and if it does there will be some errors for those who try out anvil-polkadot, but I assumed that to be super isolated in theory, almost non-problems in practice. I haven't fully clarified what's the probability of ending in the valid ethereum addresses range with such signatures, but I hope to do it soon. Even if it is an issue how we create fake signatures currently, we should be able to find stronger formats relatively easily (assuming we have a cryptographer at hand when we'll raise it as a problem).

[iulianbarbu]

PRs that made impersonation possible in anvil-polkadot: paritytech/foundry-polkadot#332, paritytech/polkadot-sdk#9878