[Bug] Lack of selector checking in sol macro

[cre-mer]

Component

sol! macro

What version of Alloy are you on?

=0.7.6

Operating System

macOS (Apple Silicon)

Describe the bug

The sol macro in alloy is designed to generate type-safe Rust bindings for Ethereum smart contracts based on their ABI. However, the current implementation of the sol macro does not check for function selector collisions. This can result in the generation of bindings that contain multiple functions sharing the same function selector.

This vulnerability could be exploited by a malicious actor who provides an ABI containing colliding function selectors to an unsuspecting developer. The developer, unaware of the actual contract's ABI, might implement the bindings and call these functions, not realizing that both function calls are resolving to the same function selector. This could lead to unintended behavior in the application.

A simplified example of this issue can be seen when using a human-readable ABI format. The following functions, transfer(address,uint256) and func_2093253501(bytes), both share the same selector hash 0xa9059cbb (as seen on 4byte.directory):

sol! {
    error func_2093253501(bytes);
    error transfer(address,uint256);
    
    function func_2093253501(bytes);
    function transfer(address,uint256);
}

Moreover, the sol macro allows declaring errors that resolve to the selector hashes 0x00000000 and 0xffffffff. These selectors are reserved for future usage in Solidity, as mentioned in the docs. For example, the following code is not permitted by the Solidity compiler, because BlazingIt4490597615 () has the selector hash 0x00000000 as seen on 4byte.directory.

sol! {
    error BlazingIt4490597615();
}

Expected Behavior

During compilation, an error should be raised pointing out occurrences of function selector collisions, as well as usage of illegal selector hashes.

Actual Behavior

No warnings or errors are produced. The code compiles successfully without alerting the developer to the selector collision.