Ich habe einen Vertrag, bei dem viel multipliziert und addiert wird. Etwas wie:
for (uint index = 0; index < 10; index++) {
let numAdders = adders[index];
if (numAdders > 0) {
added = numAdders * index;
tokens[senders] = tokens[sender] + added;
}
}
A) Ich sehe, dass die Opcode-Kosten 3 für das Addieren und 5 für das Multiplizieren sind ... also sieht es so aus, als würde mir dafür nie das Benzin ausgehen, oder?
B) Wenn die 10 im obigen Code dynamisch wäre, könnte ich den Vertrag durch den Index iterieren lassen, bis das Gaslimit erreicht ist (oder ein Gaslimit-Schwellenwert, der vom Aufrufer der als Parameter übergebenen Funktion festgelegt wurde) und dann alle Zustandsänderungen festschreiben bis zu diesem Punkt + eine Zustandsvariable speichern, um zu wissen, wo mit dem nächsten Funktionsaufruf fortgefahren werden soll?
Nicht wirklich, aber Sie können den Gasverbrauch steuern und entsprechend reagieren.
Ihre großen Kosten werden SSTORE und in geringerem Maße SREAD sein. Während die Berechnungen etwas trivial zu lesen sind, ist der Zustand nicht trivial, und das Festlegen des Zustands ist ziemlich teuer.
Wenn ich mich nicht irre, msg.gaswird der Vertrag Einblick in das verbleibende Gas geben. Wichtig ist, dass der Vertrag genügend Gas übrig haben muss, um alle Abwicklungsschritte durchzuführen, damit alles abgeschlossen ist, bevor das verfügbare Gas erschöpft ist.
Im Allgemeinen sind unbegrenzte Schleifen ein Antimuster. Anstatt zur Unterstützung eines interaktiven Prozesses unerwünschte Komplexität in den Vertrag einzuführen, sollten Sie erwägen, die Funktion so zu gestalten, dass sie jeweils nur eine Iteration verarbeitet, sodass Sie in jeder Größenordnung konsistente Gaskosten haben. Ein Client würde sich um die Interaktion kümmern und mehrere Transaktionen senden.
Es gibt eine Implikation, dass Sie den Vertrag bei jedem Schritt in einem gültigen Zustand belassen müssten. Das ist etwas gewöhnungsbedürftig.
Ich hoffe es hilft.