Add eth_signIntendedValidatorData RPC

[YamenMerhi]

Summary

This proposal adds a new JSON-RPC method, eth_signIntendedValidatorData, which allows signing data with an intended validator address using [EIP-191] version [0x00] with this format:

0x19 <0x00> <intended validator address> <data to sign>

History

There has always been work to integrate signing methods in various applications, but the focus was on eth_sign as it was already in use, and everyone adopted it. Although [EIP-191] defines different versions serving different purposes, versions 0x00 and 0x45 (E) do not serve the same purpose.

In this issue, we can see that [EIP-191] was almost fully supported, but precedence led to only versions [0x45] and [0x01] being implemented, dropping version [0x00].

Due to this, several apps have deviated from version [0x00], although it makes more sense to use it than [0x45]. For example, in the issue mentioned above, the team deviated from [0x00] and chose [0x45], even though a smart contract account (Multisig) should handle verification and signing for one intended validator address.

This was the issue where support for [EIP-191] Full was being worked on: GitHub Issue

Motivation

Currently, signing messages relies heavily on [EIP-191] version [0x45] (eth_sign) and [EIP-712] (eth_signTypedDataV4). While [EIP-712] provides a more structured approach, it is often seen as complex. On the other hand, [EIP-191] version [0x45] is widely used but poses significant phishing risks due to the lack of data parsing.

EIP-191 defines three versions: [0x45], [0x01], and [0x00]. This proposal aims to fully support [EIP-191] by introducing the rpc call for [0x00] version, which enables signing data with an intended validator address. This new method will:

• Enable more dApps to use [EIP-191] version [0x00] without using raw signing methods which might be dangerous and restricted in few wallets.
• Enhance security by parsing data and displaying the intended validator address, reducing phishing risks.
• Provide a simpler alternative to [EIP-712], offering a balance between usability and security.
• Be particularly relevant for smart contract accounts, allowing signing with a specific intended validator address.

With the rise of smart contract accounts and the reliance on signatures to improve UX, the need for supporting [EIP-191] version [0x00] increases, especially given the prevalence of verifier smart contracts, such as Entry Points, Smart Contract Accounts, Key Managers, etc.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

eth_signIntendedValidatorData

MUST calculate an Ethereum signature using sign(keccak256("\x19\x00<signature validator address><data to sign>")).

This method adds a prefix to the message to prevent malicious dApps from signing arbitrary data (e.g., a transaction) and using the signature to impersonate the victim.

Parameters

1. DATA - 20-byte account address: The address signing the constructed message.
2. DATA - 20-byte account address: The intended validator address included in the message to sign.
3. DATA - Data string: The data to sign.

Returns

DATA - Signature.

Example

Request:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_signIntendedValidatorData","params":["0x6aFbBC5e6AFcB251371711a6551E60ead2779Dc0", "0x345B918b9E06fAa7B0e56bd71Ba418F31F47FED4", "0x59616d656e"], "id":1}'

{
  "jsonrpc": "2.0",
  "method": "eth_signIntendedValidatorData",
  "params": [
    "0x6aFbBC5e6AFcB251371711a6551E60ead2779Dc0",
    "0x345B918b9E06fAa7B0e56bd71Ba418F31F47FED4",
    "0x59616d656e"
  ],
  "id": 1
}

Result:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c"
}

Support

We see many members of the ETH ecosystem tired of the hacks that happen due to blind signing. Even if this standard is not perfect, it at least provides an idea of which verifier will verify the message. If you trust the verifier, then it's one extra step towards safety (not full safety as users can't know what bytes they are signing, but still).

In the Metamask forum, it received support and was praised by nick.eth, Lead developer of ENS & Ethereum Foundation alum.

• Nick's Tweet
• Metamask Forum - 15+ Votes

Links

• Closed EIP Specs PR.
• Discussion in Metamask Forum (+15 votes).

[lightclient]

Looking into this more, this may make more sense as a wallet API. This repo is really focused on the RPC provided by Ethereum clients and while some signing methods are supported due to legacy reasons, I don't know if it makes sense to add additional ones.

[YamenMerhi]

@lightclient I see, where is the best place to have this PR ?

[lightclient]

There isn't really a central spec for the wallet API like there is for the client API. I think an interface EIP like you started with would actually be best, but with wallet_ as the prefix instead of eth_. Sorry for diverting you originally.