Warum brauchen wir "stateMutability" im ABI des Vertrags, wenn wir bereits "constant" und "payable" haben? [Duplikat]

stateMutability: eine Zeichenfolge mit einem der folgenden Werte: pure (festgelegt, um den Blockchain-Status nicht zu lesen), view (festgelegt, um den Blockchain-Status nicht zu ändern), nicht zahlbar und zahlbar (wie oben zahlbar).

Konstante: wahr, wenn die Funktion so angegeben ist, dass sie den Blockchain-Status niemals ändert; zahlbar: wahr, wenn die Funktion Ether akzeptiert, standardmäßig falsch.

Innerhalb des ursprünglichen Designs konnten einige Anwendungsfälle nicht ausgedrückt werden. Zum Beispiel hat eine reine Funktion kein Äquivalent.

Antworten (1)

constantwurde zugunsten von pureund verworfen view- siehe hier

purewird für Funktionen verwendet, bei denen der Status nicht einmal gelesen wird (z. B. Funktionen vom Typ safeMath), während viewer für Funktionen verwendet wird, die den Status nicht ändern, sondern daraus lesen.

bzgl. des ABI constantwurde aus Gründen der Abwärtskompatibilität beibehalten:

Bemerkungen:

JSON ABI hat ein neues Feld statemutability, das mit einem String-Wert wie oben eingeführt wurde

JSON ABI bleibt für eine Weile konstant/kostenpflichtig für die Abwärtskompatibilität

Quelle: Kommentar von Axic vom 15.08.2017 hier

Ich denke, das OP interessiert sich nicht für den Unterschied zwischen rein / Ansicht / Konstanten usw. Er fragt, warum der stateMutabilityBegriff abi enthält, da Ansicht / Konstante bereits in der Funktionssignatur definiert sind.
Die Antwort ist klar. constantund payablewurde aus Gründen der Abwärtskompatibilität beibehalten. Danke schön!