Ich habe einen Vertrag fooContract, der eine fooLib-Bibliothek verwendet und fooLib.foo (LibStruct-Speicherparameter) aufruft.
Die Transaktionskosten zum Erstellen von fooContract scheinen vom Code in der Funktion fooLib.foo() abzuhängen, obwohl die Parameter unverändert sind.
Dh. Mit dem Solidity-Browser fooContract erstellen Kosten 3.185.059. Wenn ich den Code in fooLib.foo() auskommentiere, sinken die Erstellungskosten von fooContract auf 2.816.000 .
Soweit ich verstanden habe, sind Libs eine Möglichkeit, die Funktionalität für Verträge zu verschieben, die zu groß für das Blockgaslimit sind.
Übersehe ich hier einen Punkt?
Ich vermute, dass Sie eine Bibliothek nicht so verwenden, wie sie beabsichtigt ist, um die Gaskosten in Ihrem Vertrag zu erzielen. Ich nehme an, was Sie tun, ist so etwas wie:
library fooLib {
// foo code
}
contract fooContract is fooLib {
// foo code
}
In diesem Fall müssen Sie beim Erstellen fooContract
die Kompilierungskosten für bezahlen fooLib
. Was Sie tun möchten, ist, fooLib selbst bereitzustellen, festzulegen, wie mit der Bibliothek über eine interagiert werden interface
soll, und die Bibliotheksadresse anzugeben, mit der während der Kompilierung von solc mit dem Compiler verknüpft werden soll fooContract
. fooLib
Auf diese Weise würden Sie die Kompilierungskosten beim Bereitstellen vermeiden fooContract
und stattdessen nur die Transaktionsgebühren bezahlen, wenn Sie die Bibliothek verwenden.
Der folgende Stackexchange-Beitrag enthält eine solide detaillierte Beschreibung dieses Prozesses:
Ein sehr guter Aragon-Artikel dazu:
Die internen Funktionen in Bibliotheken werden zur Kompilierzeit in den aufrufenden Vertrag gezogen und JUMP
anstelle einer DELEGATECALL
. Aus Solidity-Dokumentation: http://solidity.readthedocs.io/en/v0.4.21/contracts.html#libraries
VincentLg
szerte
VincentLg