About signature verification by smart contract wallets (1271, 1654, 2126)

1

The need for smart contract wallet to be able to recognise signature as been identified a long time ago. Verification of EOA’s signature using ecrecover is now very common, as is allows protocole to partially move offchain, reduce gas cost, and increase scalability.

Smart contract based wallet, like Argent and Gnosis can very rarely interact with such systems.

Many proposal, with various names, have been drafted. The ERC1271/1654 family proposed a isValidSignature function, with various arguments, that would allow a smart contract to recognise signature made by its owners. THe most common variants are

isValidSignature(bytes data, bytes signature) returns (bytes4)
isValidSignature(bytes32 hash, bytes signature) returns (bytes4)

With various assumption about how the hash or data should be processed

There function are expected to return their own selector has a “magic value”.
The second option is less generic, but IMO is a better fit considering the bytes32 format correspond to ecrecover's supported format, and is standardised through ERC191 and ERC712

These 2 ERCs have been in draft for way to long!

More recently, @pedrouid proposed ERC2126, which (while I did not agree with the overall design) had the benefit to try and have things moving again. Unforunatelly, the corresponding PR was close due to inactivity so the ERC never made it EIP repo.

Argent implements (bytes32, bytes), Gnosis implements a version of (bytes,bytes) where the data is expected to signed using an ERC712 structure. I do believe that it is high time we move a proposal to final call, as having the various proposal stuck in “draft” prevents adoption.

I’d love to have the community opinion on that subject. Particularly that of ERC1271 & 1654 authors, and that of Wallet developpers.

@pedrouid @PhABC @frangio @shrugs @abandeali1 @izqui @catageek @pazams

4 Likes
2

Happy to make a PR to set ERC-1271 to final call again, with the isValidSignature(bytes32 hash, bytes signature) returns (bytes4) version. Need to look back as to why the last attempt never made it through.

3 Likes
3

the whole debate bytes32 vs bytes was an unfortunate event IMO to the specification of ERC-1271

there was a period of time that all smart contract wallets used bytes yet they all verified data differently

hence why bytes32 is the preferred interface since it guarantees that ecrecover behaves equally on all smart contracts

the second advantage was that using bytes 32 consolidate the differences of ERC-1654

therefore both standards now share the same validation and ERC-1654 is an extension of ERC-1271

given these developments I saw no benefit of pursuing ERC-2126 since the mine issue was solvable by using bytes32 for ERC-1271

2 Likes
4

Having one question about 1271 - it states:

The specific return value is expected to be returned instead of a boolean in order to have stricter and simpler verification of a signature.

This is the reference implementation:

  /**
   * @notice Verifies that the signer is the owner of the signing contract.
   */
  function isValidSignature(
    bytes32 _hash,
    bytes calldata _signature
  ) external override view returns (bytes4) {
    // Validate signatures
    if (recoverSigner(_hash, _signature) == owner) {
      return 0x1626ba7e;
    } else {
      return 0xffffffff;
    }
  }

really having trouble understanding how this is simpler/stricter than

  /**
   * @notice Verifies that the signer is the owner of the signing contract.
   */
  function isValidSignature(
    bytes32 _hash,
    bytes calldata _signature
  ) external override view returns (boolean) {
    // Validate signatures
    if (recoverSigner(_hash, _signature) == owner) {
      return true;
    } else {
      return false;
    }
  }

really hope someone can enlighten me here.

Also think we need something like ERC2126 - otherwise IMHO 1271 is building on sand. Wondering what other approach @Amxx had in mind when stating:

More recently, @pedrouid proposed ERC2126, which (while I did not agree with the overall design) had the benefit to try and have things moving again.

5

digging into 1271 more another question arose (sorry to use this thread - but it is the last one about 1271 here and there is no discussions-to header in the EIP)
How should it work with multisigs where there is not only one owner? Here we would kinda need a list of signatures right? How would this work with the current 1271 design?