Add ERC7803Utils and ERC7803

[ernestognw]

Fixes #????

PR Checklist

• Tests
• Documentation
• Changeset entry (run npx changeset add)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 100db0f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Amxx]

I'm not a fan of the recurtion here, particularly because it require a _splice that is memory intensive. A simple for loop should work just fine

Suggested change

	return
	signingDomainSeparators.length == 0
	? MessageHashUtils.toTypedDataHash(verifyingDomainSeparator, structHash)
	: MessageHashUtils.toSigningDomainHash(
	signingDomainSeparators[0],
	// TODO: Make iterative?
	encodeForSigningDomains(
	_splice(signingDomainSeparators, 1, signingDomainSeparators.length),
	verifyingDomainSeparator,
	structHash
	)
	);
	bytes32 result = MessageHashUtils.toTypedDataHash(verifyingDomainSeparator, structHash);
	for (uint256 i = signingDomainSeparators.length; i > 0; --i) {
	result = MessageHashUtils.toSigningDomainHash(signingDomainSeparators[i-1], result);
	}
	return result;

[Amxx]

Suggested change

	if (methodBytes.length < 4) return (false, 0);
	// Check if it starts with "ERC-"
	if (!(methodBytes[0] == "E" && methodBytes[1] == "R" && methodBytes[2] == "C" && methodBytes[3] == "-")) {
	return (false, 0);
	}
	// Extract and validate the ERC number
	return Strings.tryParseUint(string(Bytes.slice(methodBytes, 4)));
	return (methodBytes.length > 4 && bytes4(methodBytes) == 0x4552432d)
	? Strings.tryParseUint(string(Bytes.slice(methodBytes, 4)))
	: (false, 0);

[Amxx]

When we know the string, and when the length is <=32, it is cheaper (but arguably less readable) to compare things directly

Suggested change

	return Strings.equal(methodId, "ECDSA");
	return bytes(methodId).length == 5 && bytes5(bytes(methodId)) == 0x4543445341;

[Amxx]

AFAIK, ERC-7803 doesn't document anything like this

[Amxx]

• isECDSA and isERC are not (currently) used. I'm not sure we really need them.
• the signature decoding is not standardized in the ERC document. We should probably ask the ERC to standardized that part. Note that the bytes32[] could be packed encoded.

One thing I'm concerned with is that passing the signingDomainSeparators through the signature is probably not the right way to proceed. We need some sort of verification that the domain separator of the actual contract was used. I would expect the implementation to not add anything in the signature (as opposed to ERC-7739).

On the "onchain" side, ERC-7803 would be an abstract signer layer that would "only" do something like:

abstract contract ERC7803 is AbstractSigner, EIP712 {
    using MessageHashUtils from bytes32;

    function isValidSignature(bytes32 hash, bytes calldata signature) public view virtual returns (bytes4 result) {
        return 
            _rawSignatureValidation(_domainSeparatorV4().toSigningDomainHash(hash), signature)
                ? bytes4(0x78030001)
                : bytes4(0xffffffff);
    }
}

_rawSignatureValidation would then either verify the signature directly (P256/ECDSA/...) or pass that to another SCA (through 127) that would eventually repeat the ERC-7803 hash processing, encapsulating it with the next signingDomainSeparators

[Amxx]

As discussed yesterday, closing this PR.