6

1820 keeps the record with

mapping(address => mapping(bytes32 => address)) internal interfaces

Which address is the actual contract which one is the interface?

I assumed the first address is the contract address and the second is the interface, so someone can query if my contract implements this interface and where is the interface at?

But in the erc1820 registery function setInterfaceImplementer

 require(
   ERC1820ImplementerInterface(_implementer).canImplementInterfaceForAddress(_interfaceHash, addr) == ERC1820_ACCEPT_MAGIC,"Does not implement the interface");

under my assumption this is querying the interface for records, that doesnt seems correct?

2 Answers 2

6

I assumed the first address is the contract address and the second is the interface, so someone can query if my contract implements this interface and where is the interface at?

That's correct.

The snippet of code you shared is where the ERC1820 registry asks the implementation if it can indeed implement a given interface for a given address. It's like this:

  • Rick: "ERC1820 registry, I'd like to make Smarx the 'question answerer' for Rick."
  • ERC1820 registry: "Hey Smarx, can you act as a question answerer for Rick?"
  • Smarx: "Yes."
  • ERC1820 registry: "Okay, then interfaces[Rick][question answerer] = Smarx"

Later on someone can query the registry:

  • Anybody: "For Rick, who is the question answerer?"
  • ERC1820 registry: "Smarx"

I hope that helps.

4
  • thanks for the answer. however this means the registery is asking the interface if a contract uses it, that doesnt seem right tho. The interface should just be standard standing alone, doesnt keep records of all the contracts using it. The registery should ask the contract if it supports an interface tho? Jun 14, 2019 at 13:33
  • The contact implementing the interface can just always reply "yes" if you want. But no, I don't think the typical scenario is a single contract handling an interface for everyone. Often the implementer only handles that interface for a single contract. (E.g. ERC777TokensReveiver)
    – user19510
    Jun 14, 2019 at 16:14
  • I thought the way it works is -- my contract can implement a standard interface e.g. ERC20 thats already deployed on chain. Then my contract can register with ERC1820 say this contract implements the standard ERC20 interface at this address. is this not correct? Jun 20, 2019 at 0:34
  • 1
    What do you mean by "that's already deployed on chain"?
    – user19510
    Jun 20, 2019 at 0:43
2

The perhaps confusingly-named interfaces mapping, mapping(address => mapping(bytes32 => address)):

  • maps account address (whether for EOA or contract) to another mapping
  • the second mapping is from (essentially) interface names to addresses of contracts implementing the interfaces

So for example, you could have a deployed contract that is able to send and receive ERC777 tokens. Its address would map to this mapping:

{
  ERC777TokensRecipient: <recipient address>
  ERC777TokensSender: <sender address>
}

(These interface names are specified in EIP 777.)

This way anyone using the send function on an ERC777 token with your deployed contract address in "from" or "to" would invoke the lookup in this mapping appropriately.

What goes into <recipient address> or <sender address>? It's simplest to use your deployed contract address, but you can also specify other contract addresses. These other contracts must implement the ERC1820ImplementerInterface as specified in EIP 1820.

So there is no "querying the interface". Rather, each account registers with the registry. You query the register which responds back with a mapping of interface names to implementation addresses. Token standards, such as ERC-777, will lookup pre-defined interface names for implementations of their hooks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.