Pseudo-Introspection, or standard interface detection

[chriseth]

This EIP is being further developed as #881

---

For some "standard interfaces" like the token interface ( #20 ), it is sometimes useful to query whether a contract supports the interface and if yes, which version of the interface, in order to adapt the way in which the contract is interfaced with. Specifically for #20, a version identifier has already been proposed. This proposal wants to generalize the concept of interfaces and interface versions to interface identifiers:

Every "standard interface" should be assigned a unique identifier (the sha3 hash of its source representation would be suitable) as a bytes32 value. Interfaces that support pseudo-introspection should provide the following methods. Note that this is especially targeted at contracts that can also provide multiple non-conflicting interfaces. This is useful if e.g. a standard token contract also allows a "cheque" functionality, which would have its own interface ID, or if the token does not support allowances.

/// @returns true iff the interface is supported
function supportsInterface(bytes32 interfaceID) constant returns (bool);
/// @returns the (main) interface ID of this contract
function interfaceID() constant returns (bytes32);
/// @returns a bit mask of the supported interfaces.
function supportsInterfaces(bytes32[] interfaceIDs) constant returns (bytes32 r) {
  if (interfaceIDs.length > 256) throw;
  for (uint i = 0; i < interfaceIDs.length; i++)
    if (supportsInterface(interfaceIDs[i]))
      r |= bytes32(2**i);
}

Example implementation and usage:

contract GenericInterfaceContract {
    function interfaceID() constant returns (bytes32);
    function supportsInterface(bytes32 _interfaceID) constant returns (bool);
    function supportsInterfaces(bytes32[] interfaceIDs) constant returns (bytes32 r) {
      if (interfaceIDs.length > 256) throw;
      for (uint i = 0; i < interfaceIDs.length; i++)
        if (supportsInterface(interfaceIDs[i]))
          r |= bytes32(2**i);
    }
}
contract SimpleToken is GenericInterfaceContract {
    bytes32 public constant interfaceID = 0xf2a53462c853462ca86b71b97dd84af6a2f7689fc12ea917d9029117d32b9fde;
    event Transfer(address indexed _from, address indexed _to, uint256 _value);

    function totalSupply() constant returns (uint256 supply);
    function balanceOf(address _owner) constant returns (uint256 balance);
    function transfer(address _to, uint256 _value) returns (bool success);

    function supportsInterface(bytes32 _interfaceID) constant returns (bool) {
        return _interfaceID == interfaceID;
    }
}
contract Token is SimpleToken {
    bytes32 public constant interfaceID = 0xa2f7689fc12ea917d9029117d32b9fdef2a53462c853462ca86b71b97dd84af6;
    event Approval(address indexed _owner, address indexed _spender, uint256 _value);

    function transferFrom(address _from, address _to, uint256 _value) returns (bool success);
    function approve(address _spender, uint256 _value) returns (bool success);
    function allowance(address _owner, address _spender) constant returns (uint256 remaining);

    function supportsInterface(bytes32 _interfaceID) constant returns (bool) {
        return _interfaceID == interfaceID || super.supportsInterface(_interfaceID);
    }
}
contract C {
    function retrieveRemainingAllowance(GenericInterfaceContract c, address owner) returns (uint) {
        if (c.supportsInterface(Token.interfaceID)) {
            Token t = Token(c);
            return Token(c).allowance(owner, msg.sender);
        } else if (c.supportsInterface(SimpleToken.interfaceID)) {
            return 0;
        } else {
            throw;
        }
    }
}

Note:
Since the EVM does not provide any guarantees for the semantics of contracts, any such information returned by other contracts can only be used as a guideline.

Note2:
The convenient access to the interface ID via Token.interfaceID is not yet supported by solidity ( ethereum/solidity#1290 ).

Credits: This is the result of a discussion with @konradkonrad and @frozeman

[Arachnid]

This would be particularly useful for ENS resolvers, and would allow removing the has() method, which implements an equivalent (ENS-specific) operation.

supportsInterfaces seems like a lot of extra overhead for relatively little gain over just calling the contract multiple times, however, especially given the low number of interfaces one is likely to need to check.

[Arachnid]

A couple of other suggestions:

1. interfaceID assumes the existence of a 'primary' interface, and doesn't seem a-priori terribly useful. Unless there's compelling use cases for it, I'd suggest dropping it.
2. Making the interface ID the 32 bit XOR of all the function signatures the interface contains would make calculating it simpler, relying only on existing code to generate function hashes and simple arithmetic ops.

[Arachnid]

Discussing this with Chris in the Solidity channel, he pointed out that an interface is more than its ABI; it's possible for two interfaces with the same set of function signatures to have different expectations of how they operate (especially since function signatures don't include parameter names!). So, the interface ID should be a pseudorandom value with low probability of colliding with any other interface ID; it doesn't need to bear a strict relationship to the source (and arguably, shouldn't, so people don't make assumptions about it being usable as some kind of test).

I agree - so ignore my earlier suggestions about constructing the interface ID from the constituent functions.

Edit: On the other hand, Go does 'duck typed interfaces' and generally doesn't have a problem; although you can have two interfaces with the same ABI but different intents, the chances of both of them being relevant in a given scenario seem vanishingly small. For instance, it's easy to avoid a collision in interface definitions for ENS resolvers, and nobody's going to ask an ENS resolver if it implements, say , a token-related interface.

[chriseth]

After some more discussion, I think we did settle on just using the xor of the function identifiers that are part of the interface as a canonical identifier.

[VoR0220]

@chriseth @Arachnid I am of the belief that we should be either copying how Go does this or how Rust does this in regards to our interfaces. They should be their own type. Something looking like this:

contract C {
    interface I {
         foo(uint256) returns (uint256);
         bar(bool, string) returns (bool);
    }
}

contract A {
     struct MyStruct {
          function foo(uint256) returns (uint256);
          function bar(bool, string) returns (bool);
     }
     MyStruct _myStruct;
     D someContract;
     function a_call() {
          d.f(_myStruct); //passes in _myStruct as interface to D
     }
}

contract B {
  E _e; 
  D _d;

  function call_D() {
       _d.f(_e); //passes in E to D and thus will clear because functions align.
   }
} 

contract E {
    function foo (uint256) returns (uint256) {
       //some function
   }
   function bar (bool, string) returns (bool) {
     //some function
   }
} 
contract D is C {
     function f(_interface I) {
            switch type(_interface) { //switch on the types of objects passed into the interface (i think this should be mandatory to some extent)
                 case A:
                      uint a = _interface.foo(1);
                 case B: 
                       bool truth = _interface.bar(true, "something");
                 default: throw;
            }
     }
}

I'm not sure about xor-ing it...that may work, I'm just not sure I understand it yet, need to look. What I think we can do for the type assertion is to hash for these types based on their actual function opcodes that they are utilizing/generating on the stack portion. This will make it so that we can verify that only these contracts are calling externally and can make the interface quite a useful safety mechanism.

[Arachnid]

@VoR0220 I think what you're talking about is language design, and thus orthogonal to this EIP, which is mostly about how to implement the feature at the EVM level.

[VoR0220]

I believe you might be correct. Will reread this in the morning.

[VoR0220]

Okay. 2 Months later, I have reread it and with some help I think I understand the proposal better. Here's my question. How might we distinguish between different versions of a contract interface? Would that need to be included? Or would it be "Version independent"?

[jbaylina]

Here are the modifications that I would do in the standard:

1.- I would keep GenericInterface very simple with just one single method: supportsInterfaces(bytes32). I would not include the other two methods: supportsInterfaces and interfaceID.
2.- This interface should always return true when called with 0xf1753550 as a parameter. (This is the interface that implements supportsInterfaces(bytes32).
3.- This function should always return false when called with 0xff···ff parameter.

With this definition, You can test if a contract implements EIP165 or not by trying to call supportInterface for GenericInterface (Should always return true) and an Invalid interface (Should always return false). If an exception, out of gas or the results are not true/false, then this means that this contract does not implement EIP165

For saving gas, a single generic EIP165Cache contract can exist in the blockchain.

You can see an how this implementation would be here:

https://github.com/jbaylina/EIP165Cache/blob/master/contracts/EIP165Cache.sol