EIP-4494: Extending ERC-2612-style permits to ERC-721 NFTs

[dievardump]

@wschwab

2) v,r,s vs full signatures

EIP2612 takes v, r, and s arguments, which are the three parts of a signature. The full signature is needed to verify the message, though. The author of 2612, Martin Lundfall, told me that his reasoning was that v, r, and s are all fixed length (uint8, bytes32, and bytes32), whereas the full signature would need to be a dynamically-sized array (if I understood him right, apologies if I missed something there), though if we kept v, r, and s as arguments (as in 2612), likely every function would need to concatenate them (using abi.encodePacked) in order to use ecrecover to verify.

About this, I would like to add:

since version 4.1, ECDSA from OpenZeppelin’s contracts repository implements EIP-2098 which allows signature of length 64.

We will not be able to support this easily with (r, s, v) as parameters since encodePacked(bytes32, bytes32, uint8) will always return a signature of 65 length.
This is why for the moment I went with the full bytes memory signature in the example of implementation, letting the library manage what EIP to follow according to the length of the bytes.