2

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?

1

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.

  • 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? – Panda Power Jun 14 '19 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 '19 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? – Panda Power Jun 20 '19 at 0:34
  • What do you mean by "that's already deployed on chain"? – user19510 Jun 20 '19 at 0:43
0

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, privacy policy and cookie policy

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