Return parameter names with function signature

[danfinlay]

Opening for discussion, since I know there could a basic caveat; some functions with the same signature could name their parameters differently.

That said, if MetaMask had some way of knowing, for example, what the most popular names for those parameters were, or even just what the first registered one's parameters were named, we could experiment with the effectiveness of that strategy.

I suspect that for most cases, there would be no collisions. And in cases where there were, we could work around the issue in a variety of ways.

Related to MetaMask/metamask-extension#1142

[pipermerriam]

Hrm, it would be possible to take in parameter names but that adds a whole level of subjectivity to the data that is stored and opens up some attack avenues that I'm nervous about. Currently, someone could spam this database and fill it with a bunch of junk. That's not a big deal because that junk would still be valid function signatures. By introducing parameter names, then someone can spam a single signature with different parameter names and bloat the DB around that signature. It would also allow people to inject intentionally malicious parameter names which could then bleed through to the UI layers that use this database.

Thoughts? Any ideas on how to get the best of both worlds?

[danfinlay]

1. ************, just save the big ones like token standard etc to start.
2. ENS?
3. Some kind of more liquid ENS, where people can bond for some Param names, something game theory crypto economics. About to take off on a plane, will consider it more.

[tjayrush]

I've seen more than one example of ABI files with identical canonical function or event signatures with different parameter names. Especially for common things like vote, spend and so forth. I do see the need for some sort of automatic way to name variables for presenting user interfaces, but at least for common functionality, it seems people rename variables more than you might think.

[danfinlay]

I wonder how Etherscan goes about getting full source codes for contracts. While it's still subjective (someone could post a copy of the source code with differently named parameters), it seems like in general, whoever posts a source code first is making a demonstration of having early access to the source code, which is a pretty decent heuristic for naming parameters correctly.

Since long-term, "knowing what you're signing" is a critical ecosystem property, we should do whatever it takes to make this possible. Do I recall correctly there was talk of adding this sort of thing to the solidity compiler, so the data could be available on-chain? I think that would be ideal.

[tjayrush]

The deployer of a smart contract submits the solidity code to ethersan as far as I know. Etherscan then compiles and verifies only the byte code against the deployed byte code to determine if the contract should be 'verified. The byte code knows nothing about the solidity variable names, so two contracts with identical code with different variable names might produce the same byte code and both be verified.

I think I saw something about the ENS including ABI information for each contract, but I imagine this would be optional in the same way the 4byte registry (and etherscan code verification) is.

I have a very similar problem to you in the code I'm working on (QuickBlocks). Two ABIs can be identical with only the variable names different. I've seen it multiple times already for common things like wallets and DAOs which seem to come from common code bases but get slightly modified per deployment.

[pipermerriam]

@FlySwatter and @tjayrush

I think that ERC190 and EthPM offer good solutions to these problems but those are a bit further down the road when more tools have integrated with the spec and registry. An ERC190 package gives enough information about a contract that the function signature registry can be relegated to a fallback mechanism and that you can just lookup the ERC190 package for a contract and get all of the information you can possibly want about function signatures, variable names, etc.

In the meantime, I'm supportive of trying to figure out a solution to this but I've got limited resources and time to devote to this registry and keeping it simple is critical to keeping it functional unless someone steps up to maintain it.