User Tools

Site Tools


Sidebar

Welcome to DIDO WIKI

dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_1820

EIP 1820: Pseudo-introspection Registry Contract

Return to Ethereum ERCs

Note: The following is an excerpt from the official Ethereum site. It is provided here as a convenience and is not authoritative. Refer to the original document as the authoritative reference.
Table 1: Data sheet for Pseudo-introspection Registry Contract
Title Pseudo-introspection Registry Contract
Author Jordi Baylina, Jacques Dafflon
Status Final
Created 2019-03-04
Description http://eips.ethereum.org/EIPS/eip-1820
Specification http://eips.ethereum.org/EIPS/eip-1820#Specification
Category ERC
Requires 165 , 214
Replaces ERC 820

Simple Summary

This standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation.
This standard keeps backward compatibility with ERC165.

Abstract

This standard defines a registry where smart contracts and regular accounts can publish which functionality they implement—either directly or through a proxy contract.
Anyone can query this registry to ask if a specific address implements a given interface and which smart contract handles its implementation.
This registry MAY be deployed on any chain and shares the same address on all chains.
Interfaces with zeroes (0) as the last 28 bytes are considered ERC165 interfaces, and this registry SHALL forward the call to the contract to see if it implements the interface.
This contract also acts as an ERC165 cache to reduce gas consumption.

Motivation

There have been different approaches to define pseudo-introspection in Ethereum. The first is ERC165 which has the limitation that it cannot be used by regular accounts. The second attempt is ERC672 which uses reverse Ethereum Name Service (ENS)1). Using reverse ENS has two issues. First, it is unnecessarily complicated, and second, ENS is still a centralized contract controlled by a multisig. This multisig theoretically would be able to modify the system.
This standard is much simpler than ERC672, and it is fully decentralized.
This standard also provides a unique address for all chains. Thus solving the problem of resolving the correct registry address for different chains.
1)
Ethereum Name Service, https://ens.domains/
dido/public/ra/xapend/xapend.b_stds/defact/ethereum/eip/erc_1820.txt · Last modified: 2022/02/03 20:15 by 62.92.37.226
Translations of this page: