ERC1407 :Namespacing ABI interface to allow function signature reuse in different context but same contract

[wighawag]

ip: ERC1407
title: Namespacing ABI interface
author: Ronan Sandford (wighawag)
discussions-to: #1407
status: Draft
type: Standards Track
category: ERC
created: 2018-13-09

Namespacing ABI interface

Abstract

Currently function and event ABI are entirely defined with their name and type signature.

It would be great to include an extra data to allow namespacing the interfaces.

Solidity and other smart contract languages could add the possibility to annotate function to use different namespace so a contract is not required to support only one namespace.

The default one could be the empty namespace '' for backward compatibility. Or alternatively every new contract would need to declare the default namespace for all functions (the default could be the contract name). Then annotations could be used to specify each function namespace if the one desired is different than the default.

Motivation

This would allow a contract to support multiple conflicting interfaces at the same time.

For example, let say you plan to use an ERC20 token but would like it to be part of the same contract as an ERC721. (this could allow you to avoid calling external contract to transfer balances for example). When the contract is used as an ERC20 "balanceOf" would return the balance of the ERC20 token represented by that contract and when used as an ERC721 it would return how many NFT you own. The namespacing would simply result in different ABI, so even though the function has the same signature, both can be used.

Currently this is not possible (and won't be for this particular case even after this EIP get implemented in smart contract languages since the ERC721 and ERC20 ABI has already been decided) but as more smart contract interface standards come into being, the likeliness of interface conflict will increase. The usefulness of combining two conflicting interfaces into one contract will probably rise too.

Potential Specification

Here is a potential way to achieve that in solidity.
Suggestion are more than welcome. The idea behind creating that issue to find a sensible specification for solving that problem elegantly.

use namsepace ERC721; // could be option since it match the contract's name

contract ERC721{
  function totalSupply() public view returns (uint256) { // use default namespace, that of the Contract Name
  ....
  }

  function balanceOf(address who) public view returns (uint256){

  }

contract ERC20 {
  function totalSupply() public view returns (uint256) { // use default namespace, that of the Contract Name
  ....
  }

  function balanceOf(address who) public view returns (uint256){

  }
  event Transfer(address indexed from, address indexed to, uint256 value);
}

contract Combination is ERC721, ERC20 {
    function test() {
     this.@ERC721.balanceOf(msg.sender);
     this.@ERC20.balanceOf(msg.sender); // could be a way to access namespaced function
  }
}

The ABI for each function could then be
sha3("<namespace><canonical function signature>")
instead of
sha3("<canonical function signature>)"

or maybe for allowing people to start using such scheme right now, we could do it this way
sha3("<namespace>__<canonical function signature>")

with that we can start namespacing our function waiting for proper language support (that would later make it easier to manage without typing and enforcing the use of namespace.

ERC20__totalSupply(..

[chriseth]

What is the difference to prefixing all functions in an interface definition by the name of the interface?

[wighawag]

Technically not much apart from forcing programming language to enforce such namespacing by default (assuming the default is the contract name or a forced namespace specification)

In term of programming experience. People like to have meaninful function name ununcombered with prefix. As such since as a programmer you might not be aware that someone will use the same function name, using a namespace allow you to provide a nice meaningful interface without fear of conflict.

Also it allow late standard to continue using simple function name.

[chriseth]

I'm not too sure that putting @namespace('ERC20') in front of each function definition is so much less typing than actually prefixing it before the function name. It should be as explicit as possible, because otherwise it would lead to confusion.

Perhaps we can get cheap proxies soon, then this issue would be not relevant anymore, would it?

[wighawag]

The idea is that you only need to put @namespace('ERC20') when that function belong to a different namespace that the one declared as default in the source file.

Using inheritance you call also group namespace. As such you might never need to use @namespace('ERC20') except if only one function needs it

To declare a namespace we could use a directive like

use namespace ERC20

or something like that.

I think the use of proxies is orthogonal to the proposal here.

The idea behind that proposal is to avoid conflict (especially the one that were not predicted by the original creator of the standards) by enforcing the use of namespace. This is why it is different than simply prepending a prefix to every function.

This is a common feature in many language so you can use a combination of libraries without them colliding.

[wighawag]

I updated the text to mention the use of inheritance and the idea of using _ or __ as separator so we can start using the standard before adoption by languages.

Note though, that as mentioned, the idea behind namespace is protect from conflict by enforcing it at the language level.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.