feat(forge): cheatcode eip712

[0xrusowsky]

Adds a new cheatcode to safely generate hashes following the EIP-712 spec.

implementation details

ref #4818

due to the lack of polymorphism, it is not possible for the cheatcode to accept a struct. Because of that, users must provide a string.

this impl allows users to either pass:

1. the type name, which will we will attempt to retrieve from the bindings generated by forge bind-json (recommended)
2. the full string representation of the type definition. In this case, we leverage alloy's eip712 support to generate the canonical representation of the type even if users pass malformed types (unsorted or with extra whitespaces).

context

usually developers manually set up constants on their smart contracts to easily access the EIP-712 type hashes:

library PermitHash {
    bytes32 public constant _PERMIT_DETAILS_TYPEHASH =
        keccak256("PermitDetails(address token,uint160 amount,uint48 expiration,uint48 nonce)");

    bytes32 public constant _PERMIT_SINGLE_TYPEHASH = keccak256(
        "PermitSingle(PermitDetails details,address spender,uint256 sigDeadline)PermitDetails(address token,uint160 amount,uint48 expiration,uint48 nonce)"
    );

    bytes32 public constant _PERMIT_BATCH_TYPEHASH = keccak256(
        "PermitBatch(PermitDetails[] details,address spender,uint256 sigDeadline)PermitDetails(address token,uint160 amount,uint48 expiration,uint48 nonce)"
    );
}

because of that, it is extremely important for these hashes to be canonical (properly computed following the EIP spec). However, as any manual approach this is error prone.

this new cheatcode aims to provide robustness to the codebases, and peace of mind for developers, giving them guarantees that no typos or sorting errors where made when manually generating the type definitions.

example usage

// represents a well-formatted EIP-712 type definition
string constant CANONICAL = "PermitBatch(PermitDetails[] details,address spender,uint256 sigDeadline)PermitDetails(address token,uint160 amount,uint48 expiration,uint48 nonce)";

// represents a mal-formatted EIP-712 type definition, emulating a human error
string constant MESSY = "PermitDetails(address token, uint160 amount, uint48 expiration, uint48 nonce) PermitBatch(PermitDetails[] details,address spender,uint256 sigDeadline)";

contract Eip712Test is DSTest {
    Vm constant vm = Vm(HEVM_ADDRESS);

    function testEip712HashType() public {
        bytes32 canonicalHash = keccak256(bytes(CANONICAL));

        // Can figure out the canonical type from a messy string representation of the type,
        // with an invalid order and extra whitespaces
        bytes32 fromTypeDef = vm.eip712HashType(MESSY);
        assertEq(fromTypeDef, canonicalHash);

        // Can figure out the canonical type from the previously generated bindings with `forge bind-json`
        bytes32 fromTypeName = vm.eip712HashType("PermitBatch");
        assertEq(fromTypeName, canonicalHash);

        // In practice, this means that devs only need to compare the hash with the cheatcode output
        assertEq(keccak256(bytes(MESSY)), vm.eip712HashType(MESSY));          // this check would fail
        assertEq(keccak256(bytes(MESSY)), vm.eip712HashType("PermitBatch"));  // this check would fail
    }
}

important note

when using vm.⁠eip712HashType:

• Passing a type string representation: validates EIP-712 formatting, canonicalizing messy inputs. However, it does NOT guarantee the string perfectly matches the smart contract's struct. For instance, a typo like ⁠amont instead of ⁠amount in the string will still produce a valid EIP-712 hash, but for the incorrect type, leading to runtime signature verification errors.
• Passing a type name: (RECOMMENDED METHOD) uses ⁠forge bind-json generated bindings, ensuring the hash corresponds to your actual compiled contract structs. This provides a guarantee of alignment, catching discrepancies that the string method would miss.

[grandizzy]

Please run cargo cheats twice to fix failing tests

[grandizzy]

looks good, left couple of comments / nits!
So if I get this right the DX would be:

• generate bindings with forge bind-json (by default goes to utils/JsonBindings.sol but could be configurable to different pathToJsonBindings path)
• use vm.eip712HashType(typeDefinition) or vm.eip712HashType(pathToJsonBindings, typeDefinition) to generate EIP-712 representation

[grandizzy]

sorry, just realized params should be calldata and not memory

[Philogy]

Getting the type string right is only half the battle, the other is also encoding/hashing. Would be nice if you had a json style chteatcode where you pass in the abi encoded bytes + the type name and you construct the EIP-712 bytes to be hashed to get the struct hash (including the typehash).

As an auditor/dev I see people messing up the hashing of sub-collections / arrays in EIP-712 all the time would be nice to have a good way to verify/compare this.