Kann ERC20-Token-Transfers eine Gebühr in Ether hinzugefügt werden

Neu bei Solidity...

Ist es möglich, eine Gebühr für die Übertragung eines ERC20-Tokens in Ether zu erheben? Die Gebühr würde 0,000001 Ether pro Überweisung betragen. Jedes Mal, wenn der ERC20-Token an einen anderen Benutzer gesendet wird, wird die Gebühr in Ether an einen Vertrag gesendet. Quellenbeispiel für die Überweisung der Gebühr in Ether wäre am hilfreichsten.

(Hinweis: Diese Frage bezieht sich nicht auf Gasgebühren. Dies bezieht sich auf eine zusätzliche Gebühr in Ether für die Übertragung eines ERC20-Tokens.)

ERC20 ist ein Standard, nichts hindert Sie daran, seine Funktionen zu überladen.

Antworten (2)

Die Spezifikationen des ERC-20-Standards können Sie hier einsehen .

Für die relevanten Funktionen transferund transferFromgibt es keine Erwähnung von Veränderbarkeitsbeschränkungen (oder für irgendeine andere Funktion).

Wenn Sie diese Funktionen payableerstellen und verlangen, dass der Wert 0,000001 ETH beträgt, würde dies wahrscheinlich nicht gegen den ERC-20-Standard verstoßen (wie in diesem Dokument dargelegt).

Kann eine kostenpflichtige Funktion eine nicht kostenpflichtige Funktion implementieren?
Was meinst du mit umsetzen? Eine kostenpflichtige Funktion kann eine nicht kostenpflichtige Funktion aufrufen. Es gibt keine Erwähnung im Standard von Beschränkungen gegen die Zahlbarkeit, und vermutlich hätten sie, wenn es beschränkt wäre, den expliziten Modifizierer für nicht zahlbar verwendet.
Das EIP20 ist eine Schnittstelle, die Funktionen hat, die die Schnittstellenimplementierung implementieren muss. transferist eine dieser Funktionen, daher muss der Durchführungsvertrag eine transferFunktion mit derselben Signatur haben. Wenn eine payableFunktion die Funktion in der Schnittstelle implementieren kann, ist meine Antwort falsch. Aber ich konnte nicht viele Informationen darüber finden :(
Eigentlich ist dies ein guter Punkt, wenn der zahlbare Modifikator zu einer Funktion hinzugefügt wird, wird die Signatur anders sein? Ich vermute, es wird, was wahrscheinlich bedeutet, dass Sie Recht haben.
Nein, das Hinzufügen payableändert den Funktionshash nicht. Der Funktions-Hash ist einfach der Hash von transfer(address,uint256)(oder bytes4(keccak256("transfer(address,uint256)")), was 0xa9059cbb) ist, es werden keine Rückgabewerte, Modifikatoren oder Veränderlichkeit für den Funktions-Hash berücksichtigt.
Ich habe das gerade in Remix versucht und gibt type error:contract A { function doit() public; } Vertrag B ist A { Funktion doit() zahlbar öffentlich { } }
Dies hat jedoch nichts mit dem ER20-Standard zu tun, dies ist nur ein Fehler, der verursacht wird, weil Sie von einem anderen Vertrag erben und dann mit einer Funktion mit unterschiedlicher Veränderlichkeit überschreiben. Der ERC20-Standard ist jedoch kein Vertrag, sondern eine Reihe von Spezifikationen, die Ihr eigener Vertrag erfüllen muss (siehe Link in meiner Antwort). Möglicherweise finden Sie Beispiele für Verträge, die dem ERC20-Standard entsprechen, aber sie sind nicht der Standard selbst. Dieser Fehler hängt also nicht mit dem ERC20-Problem zusammen.

Gemäß dem ERC20-Standard ( https://theethereum.wiki/w/index.php/ERC20_Token_Standard ) lautet die Antwort nein.

Aber nichts hindert Sie daran, die Funktionalität zu erweitern. Das Erweitern bedeutet einfach, dass es zusätzlich zur regulären ERC20-Funktionalität über zusätzliche Funktionen verfügt - Benutzer müssen über die zusätzliche Funktionalität Bescheid wissen, um sie verwenden zu können.

Hier ist eine ziemlich standardmäßige Implementierung eines ERC20-Tokens: https://github.com/ConsenSys/Tokens/blob/master/contracts/eip20/EIP20.sol Wenn wir uns die transferFunktion ansehen, können wir zum Beispiel eine ähnliche Funktion wie diese hinzufügen :

function transferWithFee(address _to, uint256 _value) public payable returns (bool success) {
        require(balances[msg.sender] >= _value);
        // require some amount of ether to be included in the transaction.
        require(msg.value >= 123);
        balances[msg.sender] -= _value;
        balances[_to] += _value;
        Transfer(msg.sender, _to, _value);
        return true;
    }

Alle Ether, die an die Funktion gesendet werden, bleiben im Vertrag. Außerdem möchten Sie wahrscheinlich etwas Böses mit der ursprünglichen transferFunktion machen, damit die Leute nicht nur diese, sondern diese neue Funktion verwenden: Sie können sie zum Beispiel einfach wie folgt implementieren:

function transfer(address _to, uint256 _value) public returns (bool success) {
        return false;
    }