Ethereum – ERC-Standard

1. ERC20-Standard

Es handelt sich um einen auf Ethereum veröffentlichten Standard-Token. Jeder kann seinen eigenen ERC20-Token ausgeben, solange dieser dem ERC20-Standard auf Ethereum entspricht, d. h. die angegebenen Funktionen und Ereignisse implementiert.

// 函数
function name() public view returns (string)
function symbol() public view returns (string)
function decimals() public view returns (uint8)
function totalSupply() public view returns (uint256)
function balanceOf(address _owner) public view returns (uint256 balance)
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)
//事件
event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _owner, address indexed _spender, uint256 _value)

Wenn die oben genannten Funktionen und Ereignisse implementiert sind, können die entsprechenden Token auf Ethereum ausgegeben werden. Derzeit gibt es viele ERC20-Token auf Ethereum.

Der ERC721-Standard ist ein nicht fungibler Token, und der entsprechende von NFT veröffentlichte Standard ähnelt ERC20.

2. Probleme mit ERC20

Allerdings weist die ERC20-Annotation selbst viele Einschränkungen auf. Es ist sehr schwierig, zusätzliche Funktionen basierend auf dem ERC20-Token ==-Standard hinzuzufügen, und oft kann dies nicht innerhalb einer Transaktion abgeschlossen werden.
Die Hauptprobleme sind:

Wenn eine Token-Übertragung eingeht, kann der ERC20-Standard nicht im Vertrag festhalten, wer den Token gesendet hat.
Der ERC20-Standard verfügt über keinen Übertragungsbenachrichtigungsmechanismus
Bei der Übertragung von ERC20-Tokens können keine zusätzlichen Informationen mitgeführt werden.

Zu diesem Zeitpunkt löste das Aufkommen des ERC777-Standards dieses Problem besser.

3. ERC1820 – Universeller Registrierungsvertrag

ERC1820 ist mit ERC165 kompatibel. Der ERC165-Standard selbst standardisiert die Identifizierung von Schnittstellen und die Erkennung, ob ein Vertrag eine bestimmte Standardschnittstelle implementiert.
Der ERC1820-Standard definiert, welche Funktionen Smart Contracts und normale Benutzerkonten in der Registry veröffentlichen können.
Jeder kann diese Registrierung abfragen, um zu fragen, welche Adresse eine bestimmte Schnittstelle implementiert, und der Smart Contract übernimmt die Implementierungslogik.
ERC1820 implementiert hauptsächlich zwei Schnittstellen:

setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer)
wird verwendet, um festzulegen, welcher Vertrag die Schnittstelle (_interfaceHash-Schnittstellenname von keccak256) der Adresse (_addr) (_implementer) implementiert.
getInterfaceImplementer(address _addr, bytes32 _interfaceHash) externe Ansicht gibt (address) zurück. Mit
dieser Funktion wird abgefragt, welcher Vertrag die Schnittstelle der Adresse (_addr) implementiert.

3.ERC777

Der Hauptvorteil:

ERC777 ist mit ERC20 kompatibel. Basierend auf ERC20 definiert es **send(dest, value, data)** zum Übertragen von Token. Zusätzliche Parameter werden zum Übertragen anderer Informationen verwendet. Die Sendefunktion erkennt, ob der Inhaber und der Empfänger identisch sind Die entsprechende Hook-Funktion ist implementiert. Wenn sie implementiert ist, wird die entsprechende Hook-Funktion aufgerufen.
Wenn ERC777 Send-to-Transfer verwendet, verwendet es die getInterfaceImplementer-Funktion von ERC1820 für die Inhaber- und Empfängeradressen, um abzufragen, ob ein entsprechender Implementierungsvertrag vorliegt.
Die Schnittstellen- und Funktionsnamen sind in der ERC777-Standardspezifikation vorgegeben. Liegt eine Implementierung vor, erfolgt der entsprechende Aufruf.
Sowohl Verträge als auch gewöhnliche Adressen können durch die Registrierung der Hook-Funktion tokensToSend steuern und deren Senden verweigern (die Ablehnung des Sendens wird durch Zurücksetzen in der Hook-Funktion tokensToSend erreicht).
Sowohl Verträge als auch normale Adressen können durch die Registrierung der Hook-Funktion tokensReceived steuern und deren Annahme verweigern (die Ablehnung erfolgt durch Zurücksetzen in der Hook-Funktion tokensReceived).
tokensReceived kann über die Hook-Funktion Token senden und den Vertrag benachrichtigen, Token in einer Transaktion zu akzeptieren, im Gegensatz zu ERC20, das über zwei Aufrufe (approve/transferFrom) abgeschlossen werden muss.

3-1 Schnittstellenbeschreibung und Implementierungskonventionen

ERC777-Verträge müssen die ERC777Token-Schnittstelle und die ERC20Token-Schnittstelle über ERC1820 registrieren.

3-2 Betreiber

ERC777 definiert eine neue Rolle des Betreibers. Ein Betreiber ist eine Adresse, die als mobiler Token fungiert. Jede Adresse bewegt ihre eigenen Token intuitiv und trennt die Konzepte von Inhaber und Betreiber.

3-3Token senden

ERC777 sendet Token mit den folgenden zwei Methoden:

send(address to, uint256 amount, bytes calldata data) external

function operatorSend(
    address from,
    address to,
    uint256 amount,
    bytes calldata data,
    bytes calldata operatorData
) external

OperatorSend kann die Informationen des Betreibers über den Parameter „OperatorData“ übertragen. Neben der Durchführung der Addition und Subtraktion des entsprechenden Kontostands und dem Auslösen von Ereignissen weist das Senden von Token auch zusätzliche Bestimmungen auf:

Wenn der Inhaber die Implementierungsschnittstelle ERC777TokensSender über ERC1820 registriert hat, muss der Token-Vertrag seine Hook-Funktion tokensToSend aufrufen.
Wenn der Empfänger die Implementierungsschnittstelle ERC777TokensRecipient über ERC1820 registriert hat, muss der Token-Vertrag seine Hook-Funktion tokensReceived aufrufen.
Wenn eine tokensToSend-Hook-Funktion vorhanden ist, muss diese aufgerufen werden, bevor der Kontostand geändert wird.
Wenn eine tokensReceived-Hook-Funktion vorhanden ist, muss diese aufgerufen werden, nachdem der Kontostand geändert wurde.

ERC777TokensSender

Für alle ERC777-Verträge kann eine Inhaberadresse nur eine ERC777TokenSender-Schnittstellenimplementierung registrieren. Die ERC777TokenSender-Implementierung wird von mehreren ERC777-Verträgen aufgerufen. Im Implementierungsvertrag der ERC777TokenSender-Schnittstelle ist msg.sender die ERC777-Vertragsadresse, nicht der Operator.

ERC777TokensRecipient

Wenn der Empfänger eine Vertragsadresse ist, muss die ERC777TokensRecipient-Schnittstelle registriert und implementiert werden (dies kann verhindern, dass der Token gesperrt wird). Wenn sie nicht implementiert ist, muss der ERC777-Token-Vertrag wieder in den Transaktionsstatus zurückkehren.

Schwachstellen, die durch einige Probleme mit den Standards ERC721 und ERC777 verursacht werden, werden später eingeführt.

Eine detaillierte Einführung zu ERC777-Tokens finden Sie im folgenden Dokument: Einführung in den ERC777-Standard.
Detaillierte Beschreibungen der oben genannten Standards ERC721, 20, 165, 777, 1820 und anderer Standards finden Sie in diesem Dokument: Ethereum EIP-Beschreibung