EIP ? - CallWithSigner as a potential fix for the msg.sender problem

I have a couple of issues with the proposal, and I’m inclined for an approach of having an additional sponsor signer of the transaction. I’ll explain here.

  1. minor: The multi-queue adds a SSTORE gas cost to the call. This cost would vary between 5000 (updating the nonce of a queue that does exists to 20000 for creating a new queue). A sponsor-signature added to the transaction also needs to update its nonce, but the lookup of the account node has already been done, so the cost is actually lower.

  2. Main: Signatures used in CallWithSigner get embedded in transaction arguments, and are not segregated. Therefore they cannot be later batched, or pruned, which is something Ethereum could do in the future using SNARKs. If Ethereum implemented SNARK proofs of batched signatures, the senders must still be stored, because they are included in the signatures via public-key-recovery, so the space savings would be about 40% for simple transactions, yet it’s an important saving. I think signatures should always be segregated to increase the chances that future improvements in SNARKs allow compression of signatures via a single proof.

  3. Implementation: You’re not committing to the amount of gas to pass the callee with the signature.
    Sign(keccak256(targetContract, callData, value, replayProtection, chainid))
    Therefore a front-running attack can be to execute the call the minimum gas (2300) and prevent any other execution future execution. The call should also commit to a minimum amount of gas to pass (or the the exact amount). In RSK the call should also commit to the minimum stack depth.

Regards!