Ich studiere den Quellcode des beliebten Ethereum SmartContract und es gibt etwas, das ich im ERC20-Standard nicht verstehe.
Nehmen wir dieses Beispiel:
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol
Hier ist ein Teil des Solidity-Quellcodes dieses Smartcontracts:
mapping (address => uint256) private _balances;
uint256 private _totalSupply;
Wie Sie sehen können, wird der Gesamtvorrat in einer separaten Variablen gespeichert. Dieses Gesamtangebot ist die Summe aller Salden.
Was ich über Solidity-Optimierung gelernt habe, ist, dass wir der Speicherung Vorrang vor der Berechnung geben sollten.
Wenn ich einen ERC20-Vertrag schreiben müsste, würde ich eine Ansichtsfunktion schreiben, die _balances summiert, um die Gesamtversorgung bereitzustellen. Warum ? Eine Ansichtsfunktion kann Salden für kostenloses Gas summieren, da sie nichts auf die Blockchain schreibt. Wenn wir eine _totalSupply-Variable haben, müssen wir sie jedes Mal aktualisieren, wenn sich der Saldo ändert. Es wird also etwas Benzin kosten, diese Variable zu schreiben.
Meine Frage ist: Warum setzt jeder eine _totalSupply-Variable auf ERC20-Verträge und nicht auf eine Ansichtsfunktion, die Salden summiert?
Danke
Wenn wir eine _totalSupply-Variable haben, müssen wir sie jedes Mal aktualisieren, wenn sich der Saldo ändert. Es wird also etwas Benzin kosten, diese Variable zu schreiben.
Das ist nicht richtig. Wenn Bob zum Beispiel x Tokens an Alice überträgt, werden ihre Salden aktualisiert, aber nicht der Gesamtvorrat. Das gleiche Prinzip gilt für Fiatgeld, eine Bank- oder Bargeldüberweisung hat keinen Einfluss auf das Gesamtangebot. _totalSupplywird jedoch jeweils aktualisiert mintund burndas sind jeweils die Erstellung und Vernichtung von Tokens. Der ERC20-Standard spezifiziert diese Funktionen nicht, da der Bereitstellungsmechanismus für jeden Token sehr spezifisch ist. Ihre Implementierung ist daher kostenlos.
Warum setzt jeder eine _totalSupply-Variable auf ERC20-Verträge und nicht auf eine Ansichtsfunktion, die Salden summiert?
Wie implementiert man diese sumFunktion? Dazu müssten Sie jede Adresse mit Token verfolgen, was keine optimale Lösung ist. Der _totalSupplyAnsatz ist viel einfacher, da das Gesamtangebot durch die Verwendung der Methoden mintund verfolgt wird burn.
Das ist nicht richtig. Wir können die Mapping-Variable nicht iterieren. Daher können wir die Summe von _balances nicht berechnen.
Bob5421
mild
_balancesist dies nicht möglich. Sie können bei einem Mapping keine Schleife erstellen, da es sich um ein Schlüssel/Wert-System mit einer unendlichen Menge an Schlüsseln handelt. Zum Beispiel existiert eine Adresse, die keine Token enthält, im Mapping und gibt Null als Wert zurück.mild
transferFunktion einige Logik hinzufügen.mild