Größe des Vertragscodes (und wie kann man das umgehen?)

Ich schreibe einige ziemlich umfangreiche Solidity-Smart-Contracts und glaube, dass ich die EIP170-24k-Bytecode-Größenbeschränkung erreiche. hab ich schon

(a) meinen Code in Bibliotheken faktorisiert

(b) heute meinen Vertrag in zwei Teile aufgeteilt.

Nichts scheint zu helfen, unter die Grenze zu kommen. Verdammt, die Aufteilung in zwei Verträge -erhöhte- -stark- den Code eines der beiden resultierenden Verträge -- viel größer als der ursprüngliche All-in-One-Vertrag.

Gibt es Tools, mit denen Sie herausfinden können, woher das Code-Bloat kommt? Andere Methoden zum Aufteilen, um die Größe zu reduzieren?

Höchstwahrscheinlich von den neuen Aussagen. Sie sind oft der Störenfried, weil sie den Code des zu instanziierenden Vertrages enthalten.
Oh wow. Wo hast du das gelernt (oder war es durch Experimentieren)? Du hast absolut recht – und vielleicht bringt mich das aus der Klemme! Ich danke dir sehr! Haben Sie irgendwo Dokumente zur Semantik gefunden, wie Solidity kompiliert wird? Ich meine, auf einer detaillierten Ebene, die für diese Art von Debugging geeignet ist?
Experimentieren, Dokumentieren, Recherchieren hier und im Internet allgemein. In der Schule wird es nicht gelehrt. :-) Ich habe hinzugefügt und antworte mit einem Beispiel für das Fabrikmuster.

Antworten (2)

Höchstwahrscheinlich kommt das Aufblähen des Bytecodes von den neuen Anweisungen in Ihrem Code. Sie sind oft der Störenfried, weil sie den Code des zu instanziierenden Vertrages enthalten. Sie können Vertragsfabriken erstellen, die Sie im Vorfeld bereitstellen können. Auf diese Weise können Sie die Bytecode-Größe Ihres Hauptvertrags reduzieren.

Z.B

contract X {}

contract XFactory {
    function createX() returns (X) {
        return new X();
    }
}

contract Main {
    XFactory xFactory;
    ...
    Main(XFactory _xFactory) {
        xFactory = _xFactory;
    }
    ...
    function someMethod() {
        X x = xFactory.create();
    }
    ...
}
Ach seufz. Dein Muster funktioniert bei mir nicht. Ich benötige zwei Verträge, A und B, die beide über eine dauerhafte Datenspeicherung verfügen, wobei B einen Zeiger auf A hat. Im Gegensatz zu Ihrem Beispiel muss Main also eine dauerhafte Kopie von X haben. Wenn ich weitergeben werde einen Zeiger auf XFactory, ich könnte genauso gut einen Zeiger auf X übergeben. Ah, gut.

Es ist möglich, die Beschränkung der maximalen Vertragsgröße zu umgehen, indem der Transparent Contract Standard implementiert wird: https://github.com/ethereum/EIPs/issues/1538