Authenticating sequencer via ecrecover #302
Description
Is your feature request related to a problem? Please describe.
At present, the optimism contracts rely on msg.sender to authenticate the caller. It would be nice if the sequencer can be authenticated via ecrecover as this will allow any signing key to send the sequencer's transaction on their behalf. This is useful if the sequencer relies on a third party relay service (like ITX) or just to provide the option to send the transaction via a different signing key due to some unforeseen reason (e.g. bug that prevents sequencer key sending the transaction / bumping the fee).
Describe the solution you'd like
I have provided an exploratory PR here #301 to work out the best way to implement it. I have modified:
ReplayProtection.sol
- A contract to standardise how the replay protection is handled. At present, it is a simple incrementing nonce. It has the lowest gas costs since it re-uses the same storage slot.
For OVM_CanonicalTransactionChain.sol and OVM_StateCommitmentChain.sol I have tried to add in two extra parameters, uint nonce and bytes signature, that then checks if the signature is pre-filled.
OVM_CanonicalTransactionChain.sol
- enqueue().
- appendQueueBatch().
- appendSequencerBatch() - I couldn't get it to work yet with this function. Some parameters are read-in via assembly.
OVM_StateCommitmentChain.sol
- appendStateBatch().
- deleteStateBatch().
Describe alternatives you've considered
I am not sure if there is any alternative. Wallet contract's won't work due to the .call() gas expansion. I do wonder if the above functions really need to authenticate the caller? Mostly around the transaction chain, since that will prevent honest users from sending withdrawal transactions?
Also, is there any other contracts that requires the sequencer interaction? I couldn't find any.
Additional context
I am mostly trying to work out how we could separate msg.sender and ecrecover in the contracts. To make it easier to authenticate the sequencer.