FIP-8: Verifications for Contract Wallets

[varunsrin]

Title: Verifications for Contract Wallets
Type: Implementation FIP
Authors: @horsefacts, @sanjay, @eulerlagrange.eth

Abstract

A proposal to extend verifications to support smart contract signatures.

Problem

Verifications require producing a claim with an Ethereum EOA address and providing an ECDSA signature in the VerificationAddEthAddressBody. This doesn't work for smart contract addresses, where the signing address is not the same as the address being verified.

We should extend the protocol specification to support ERC-1271 verifications so that smart contract wallets can be verified correctly.

Specification

Extend VerificationAddEthAddressBody to add two additional fields, verification_type and chain_id:

message VerificationAddEthAddressBody {
  bytes address = 1;            // Ethereum address being verified
  bytes eth_signature = 2;      // Signature produced by the user's Ethereum address
  bytes block_hash = 3;         // Hash of the latest Ethereum block when the signature was produced
  uint32 verification_type = 4; // 0 = EOA, 1 = contract
  uint32 chain_id = 5;          // 0 for EOA verifications, 1 or 10 for contract verifications
}

Type EOA:

• Format:
  • verification_type must be 0.
  • chain_id must be 0.
• Verification: No change to verification.
• Revocation: No change to revocation.

Type Contract:

• Format:
  • verification_type must be 1.
  • chain_id must be 1 or 10.
  • The EIP-712 signature must include chainId in the domain separator. (This is not required for EOA signatures)
  • eth_signature must be ≤ 256 bytes.
• Verification: Hubs must make an eth_call to an EIP-6492 universal validator contract, providing the EIP-712 typedData hash of the VerificationClaim as the bytes32 _hash parameter. EIP-6492 defines a wrapper format for verifying contract signatures from undeployed counterfactual contracts compatible with ERC-1271. Tools like Viem already use the 6492 format for smart contract signature verification.
• Revocation: Hubs must run a daily job to re-verify all contract verifications and remove invalidated verifications. Users of smart contract wallets should remove verifications sooner by publishing a VerificationRemove message according to their own security policy.

As an example of future extensibility, we might further extend verifications to use an onchain registry like delegate.xyz. The following is just an example and will not be implemented as part of this FIP.

Type 'DelegateV2':

• Format:
  • verification_type must be 2.
  • chain_id must be 1 or 10.
  • eth_signature must be a signature from the custody address accepting the delegation.
• Verification: Make an eth_call to the delegate.xyz contract on chainId to retrieve active delegations.
• Revocation: Hubs must subscribe to DelegateAll revocation events.

Rationale

Design goals:

• Distinguishing EOA signatures from contract signatures
  • ✅ Add a field to the verification message: Requires change to protobuf definitions.
  • Add a leading byte to the existing signature field: Overloads a field that should be well typed, creates a legacy signature format.
  • Check at runtime if an address is a contract: Unnecessary RPC usage and performance impact to hubs. Need chain ID anyways.
• Handling revocability
  • Add expiration to verifications: Bad UX for users without much extra security. Users can remove verifications anyways.
  • ✅ Periodically re-verify contract verifications
    • On every access: Unnecessary performance impact to hubs.
    • ✅ On a regular schedule: This already happens once per day, can eventually be extracted into a separate background job.
  • Do nothing, only revoke explicit removals: Prevents cleanup.
• Preventing malicious contract signatures from DoSing Hubs
  • ✅ Include a configurable RPC timeout.
  • Do nothing: hubs inherit timeout policy of their RPC provider. This is set for hosted providers like Alchemy/Infura, but not necessarily for self hosted nodes.

Why is there a limit on the length of contract signatures?
Unlike offchain ECDSA signatures, which are 65 bytes long, ERC-1271 and 6492 don't enforce a maximum length on smart contract signatures. This means a malicious contract signer could grief or DoS hubs, by forcing them to store very long signatures. 256 bytes should be sufficient for most contract wallet and smart contract use cases, and we can increase max length in the future if necessary.

Why are smart contract verifications only available on OP and Ethereum mainnet?

Since hubs need to perform a call to verify smart contract signatures, they need access to an RPC provider for the network where the smart contract is deployed: one provider per chain. Hubs already support RPC connections to OP mainnet and Ethereum mainnet.

We expect that OP and Ethereum mainnet verifications will be sufficient for most use cases in the near future and don’t want to require hubs to support additional networks right now. We may revisit this decision: nothing in this design precludes adding additional networks.

Release

Include the proposed changes after protocol release 2023.10.04.

[varunsrin]

Verifications require producing a claim with an Ethereum address and providing a signature from the same address in the VerificationAddEthAddressBody. This doesn't work for 1271 addresses, where the signing address is not the same as the address being verified.

We should extend the specification to support EIP-1271 verifications so that smart contract wallets can be verified correctly.

[varunsrin]

cc @horsefacts

[Hmac512]

There are system design implications on supporting signatures that aren’t intrinsically verifiable (eg ECDSA recover).

For a 1271 sig you will have to make an eth_call via infura/alchemy.

Do you want to add a flag for if a signature is EOA or 1271, or are you cool with verifying every such signature with eth_call?

Implications:

1. Someone can setup a contract wallet with a verify signature method that takes a long time. This could be a way to interfere with hubs.

2. 1271 are revocable. A 1271 signature could be valid at block N, but invalid at N+1

3. EOA wallets are non-transferable and Contract wallets are transferable. For the latter it might make sense for the verification to expire (also makes me think a flag for EOA makes sense).

[varunsrin]

All good points:

• I like the idea of setting a flag or type somewhere to minimize network calls.
• What's the worst case complexity you can create with a valid isValidSignature method in solidity?

[Hmac512]

What's the worst case complexity you can create with a valid isValidSignature method in solidity?

In the spec of isValidSignature the signature is bytes of arbitrary length. You can add an extra byte that’s used to determine how long it should take to verify. You can even set it up so that it could take forever without much overhead.

BUT:

Now that I think about it, Infura/Alchemy have this exact same problem. You can ddos their service with eth_calls that take really long.

Alchemy says they enforce a timeout for eth_call at the node level (assuming Infura is the same). So that timeout is de facto the max time it could take in a hub to verify a 1271 signature.

Probably want to document this node-level timeout assumption in case people run their own OP nodes.

[horsefacts]

Zain from OP Labs suggested using a SIWE message as the claim in a Twitter conversation.

Pros:

• Can just use the siwe package, which supports 1271 out of the box.
• We intend to use SIWE as the address ownership claim for "Sign in with Farcaster," so maybe it makes sense to use here, too.

Cons:

• We have existing verifications using the 712 format that we'd still need to support.
• The actual verification workflow is not that complicated, so using the SIWE library might not buy us much in terms of simplifying implementation.
• We might need to store more data to construct the claim.

[horsefacts]

Update here: in implementing this we decided to stick with our existing 712 structured claim format. Constructing a SIWE claim requires more data, like a nonce associated with the claim. This is useful in the SIWE login context, but not in the context of our claims, which are protected from replay on hubs by the message timestamp. We want to store the minimum amount of information necessary to construct claims on hubs.

[horsefacts]

(Still planning to use SIWE claims for Sign in With Farcaster)

[vrypan]

FIP-5:

If users really want a very customized recovery setup, they would be better off using a smart contract wallet as their custody address instead.

Does this mean that until this FIP is finalised, setting a smart contract custody address is not possible?

[horsefacts]

No, it's possible to use a smart contract wallet as a custody address today, although logging in from that wallet is not supported in all clients. This just has to do with verifications, i.e. associating other addresses with your FID besides the custody address.

[horsefacts]

A PR implementing this in hubs is ready to go here: farcasterxyz/hub-monorepo#1449

One small update from the implementation: we are using the EIP-6492 standard for contract signature verification. This is a signature wrapper standard that is backwards compatible with EIP-1271 signatures and forwards compatible with verifying signatures from counterfactual smart wallets. Clients like Viem already use this for contract signature verification.

The consequence is that valid contract signatures will include both EIP-1271 signatures from smart contract wallets and signatures in the EIP-6492 wrapper format.