Bytes Speicher als Funktionsparameter erhöhen die Gaskosten

Ich habe einen SmartContract, der mit Pragma Solidity ^0.4.0 kompiliert wurde; Version und eine Funktion erhält einen Byte-Parameter, der eine lange Zeichenfolge enthält. In dieser Version müssen die Parameter nicht als "Speicher" eingestellt werden.

Ich habe einen neuen Vertrag mit Version Pragma Solidity >=0.4.25 <0.6.0 erstellt; und ich bin nicht in der Lage zu erstellen, es sei denn, ich markiere die Byte-Parameter als Speicher.

bytes memory dBlock

Diese haben die Gaskosten für die Transaktion um das 3-fache erhöht. Ich habe mit einer bytes32-Variablen getestet, dass die Benzinkosten fast nichts sind.

In diesem speziellen Fall erhalte ich jedoch oft eine lange Zeichenfolge, die viel länger als 32 Zeichen ist. Wie kann ich eine lange Zeichenfolge an einen Smart Contract übergeben und gleichzeitig etwas Gas bei der Transaktion sparen?

Antworten (1)

Wenn Sie Ihre Funktion auf extern einstellen (falls sie nur über txs oder andere externe Smart Contracts aufgerufen wird), kann in bestimmten Szenarien etwas Gas gespart werden.

function myExternalFunction(bytes calldata mydata) external {
    // do some stuff
}

Bytes kostet mehr als Bytes32, weil die Längeninformation selbst in einem Speicherplatz von 32 Bytes gespeichert wird. Daher ist es in jedem Fall besser, bytes32 zu verwenden, wenn Sie sicherstellen können, dass Sie nie mehr als 32 Bytes übertragen müssen. Noch eine Anmerkung, in früheren Solidity-Versionen war das Schlüsselwort "memory" implizit enthalten (wenn es als Funktionsparameter verwendet wurde). Also im Grunde, als Sie schrieben, function myfunc(bytes xyz)war es gleichfunction myfunc(bytes memory xyz)

Vielen Dank für Ihren Kommentar, ich werde die Sichtbarkeit auf extern ändern, es wird nie intern aufgerufen, so dass es viel Benzin spart.
Gern geschehen. Noch ein Tipp: Sie können Optimierer verwenden, um die Gusskosten weiter zu senken. In diesem speziellen Szenario ist jedoch nicht mehr viel Platz für Optimierungen. Der Solc-Compiler hat einen integrierten Optimierer und Sie können weiterhin externe Optimierer verwenden, die den Code erkennen und optimal optimieren können. Probieren Sie es doch einmal selbst aus und prüfen Sie, wie viel Sprit durch zusätzliche Optimierungen zumindest eingespart werden könnte (leider sagt es nur wie viel, nicht wo und wie): EVMuncher
Nochmals vielen Dank, ich denke auch daran, Textdaten zu komprimieren, bevor sie an Smartcontract gesendet werden. Reduzieren Sie auch ein wenig Gas