Well, the real-world contract would probably have a lot of other checks to prevent this from happening.
First, the meta-transaction signer may sign on msg.sender
as well, so it cannot run random code first. Also, if the ‘relays’ who are calling some execute(..)
function on a ‘relayer’ contract have no reason to be smart contracts themselves the ‘relayer’ contract could check that it is called directly(something like tx.origin == msg.sender
or tx.gasLimit == msg.gasLimit
). Next, the ‘relayer’ contract could only allow calls from registered relay addresses. This also would allow a relay network to blacklist or penalize relays in one way or another.
Worst case, it can also check the signature on msg.gasLimit
instead. This is only required if there is a need for ‘relays’ to actually be smart contracts for some reason. There is a caveat to this, of course, because CALL
does not guarantee the gas limit to be enforced, the ‘relays’ smart contracts would have to do that.
Anyway, these considerations I believe will be quite different for each application. My point here is that the opcode is not gameable by itself. Code using it may be gameable if not implemented correctly, but hey, this is true for 0x01 ADD
as well! 