Adding Signature Verification and Public Key Retrieval to Hedera EVM

[mshakeg]

Abstract

This proposal suggests extending the Hedera EVM to support signature verification and public key retrieval within smart contracts. This would be achieved by introducing a new precompiled contract that implements the signature verification algorithm for the ED25519 key system and a method to retrieve the public key associated with a given accountId.

Motivation

The Hedera EVM implementation lacks the ability to easily verify ED25519 signatures within smart contracts and retrieve the public key of an accountId, limiting the type of applications that can be built on top of it. This proposal aims to overcome these limitations, enabling a new class of applications on Hedera.

Rationale

Adding a ED25519 signature verification mechanism and public key retrieval function, akin to Ethereum's EIP-665, would enable contracts to verify off-chain actions, enforce cryptographic commitments, implement meta-transaction patterns, and much more. This function could be realized as a new precompiled contract in the Hedera EVM, similar to Ethereum's approach. The ability to retrieve the public key for a given accountId is also essential in cases where a single ED25519 public key can be associated with multiple accountIds.

User Stories

As a dApp developer, I want to create a token contract with a permit function(such as an EIP-2612 token i.e. ERC20 Permit) that allows token owners to approve spenders via signed messages, reducing the need for multiple transactions.

This would also enable all other applications that make use of ecrecover to now also verify ED25519 signatures(albeit with few modifications).

Specification

1. Add a new precompiled contract that implements the ED25519 signature verification algorithm. This contract should take a message, the public key of the signer, and a signature as input, and return a boolean indicating whether the signature is valid, as per EIP-665.
2. Add a method to retrieve the public key associated with a given accountId. This function should return the ED25519 public key registered with the given accountId on the Hedera network.

interface IEdVerifier {

  function edverify(bytes32 message, bytes64 signature, bytes32 publicKey) external view returns (bool valid);
  
  function getPublicKey(address accountId) external view returns (bytes32 publicKey);
}

Extended ERC20 Permit Example

uint256 constant MAX_ENTITY_ID = 1e12; // assumes this value is the max realistic entity id on Hedera and that all EVM addresses are above this value

// typical ERC20 permit implementation with ECDSA signature
function permit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s) external {
    require(uint160(owner) > MAX_ENTITY_ID, "Require EVM Address");
    require(deadline >= block.timestamp, "ERC20Permit: expired deadline");

    bytes32 structHash = keccak256(
        abi.encode(
            PERMIT_TYPEHASH,
            owner,
            spender,
            value,
            nonces[owner]++,
            deadline
        )
    );

    bytes32 hash = keccak256(
        abi.encodePacked(
            "\x19\x01",
            DOMAIN_SEPARATOR,
            structHash
        )
    );

    address signer = ecrecover(hash, v, r, s);
    require(signer != address(0) && signer == owner, "ERC20Permit: invalid signature");

    _approve(owner, spender, value);
}

// permit with ED25519 signature
function permit(address owner, address spender, uint256 value, uint256 deadline, bytes64 signature, bytes32 publicKey) external {
    require(uint160(owner) <= MAX_ENTITY_ID, "Require Account ID");
    require(deadline >= block.timestamp, "ERC20Permit: expired deadline");

    // Build the message that was signed
    bytes32 message = keccak256(abi.encodePacked(
        owner,
        spender,
        value,
        nonce[owner]++,
        deadline
    ));

    // Verify the signature
    require(edverify(message, signature, publicKey), "ERC20Permit: invalid signature");
    // verify the owner accountId is registered with the publicKey
    require(getPublicKey(owner) == publicKey, "owner publicKey mismatch");

    // If the signature is valid, approve the spender
    _approve(owner, spender, value);
}

Backwards Compatibility

This proposal should not introduce any backwards compatibility issues. Existing contracts will continue to operate as they do now, and the new functionality will be available for new contracts or updated versions of existing ones.

Security Implications

The introduction of signature verification and public key retrieval must be handled carefully. The implementation of the ED25519 signature verification algorithm must be secure, and contracts using it must be careful to correctly handle the public key and accountId.

References

EIP-665: Add precompiled contract for Ed25519 signature verification - https://eips.ethereum.org/EIPS/eip-665
EIP-712: Ethereum typed structured data hashing and signing - https://eips.ethereum.org/EIPS/eip-712
EIP-2612: permit – 712-signed approvals - https://eips.ethereum.org/EIPS/eip-2612

[mshakeg]

Hey @Nana-EC I finally got around to drafting this HIP idea. It's a relatively simple improvement that could provide significant benefits for developers. I'd greatly appreciate your feedback when you have a moment.

[Nana-EC]

Hey @mshakeg
Thanks for this.

The inspiration makes sense.
Will review in depth.

In the mean time can you check out HIP 632 as I think there's partial overlap as it refers to the signature verification aspect and might require an update to your suggestion or potentially feedback on that existing HIP.

[mshakeg]

@Nana-EC thanks for pointing me to HIP-632. I just went over it and it seems to overlap with what's proposed here. It's probably a cleaner solution as devs only deal with the account Id/Address and not directly with the publicKey. Btw has development on this HIP been halted? There doesn't seem to be any activity on the related hashgraph/hedera-services/issues since January.

[Nana-EC]

Great, glad to hear 632 captures your goals.
What about the public key query here, is that something you are still suggesting of does 632 make it unnecessary?

Development for 632 has not yet been schedule unfortunately

[mshakeg]

@Nana-EC for my specific use case (implementing ERC20 with Permit, and likely any other use case relying on ecrecover), the isAuthorizedRaw(address, messageHash, signatureBlob) function as outlined in HIP-632 would work fine. That said, it's possible other use cases could benefit from direct access to the public key. Thus, it might be worthwhile to consider incorporating this feature into HIP-632.

Development for 632 has not yet been schedule unfortunately

On the matter of scheduling development for HIP-632, given the significant benefits to developers and the (seemingly) low engineering effort required, would there be scope to reconsider its prioritization in the development pipeline?