Die Smart-Contract-Funktionen von Ethereum sind auf etwa 16 lokale Variablen beschränkt. Wenn sie diese Zahl überschreiten, stack is too deepwird ein Fehler generiert.
Die Lösung besteht darin, die großen Funktionen in kleinere umzuwandeln. Zum Beispiel:
Contract A{
function B(p1,p2,p3...pn){
}
}
Kann entwickelt werden als:
Contract A{
function B1(p1,p2){
}
function B2(p3,p4){
}
...
}
Nehmen Sie nun an, dass einige Funktionen von den Ergebnissen anderer abhängig sind. Mit anderen Worten, die durch eine Funktion verursachte Zustandsänderung wirkt sich auf das Verhalten einer anderen aus.
Dieses Problem, an das ich denke, ist ein unvorhersehbarer Zustand, der in diesem Papier diskutiert wird , in dem es heißt:
Wenn ein Benutzer eine Transaktion an das Netzwerk sendet, um einen Vertrag aufzurufen, kann er im Allgemeinen nicht sicher sein, dass die Transaktion in demselben Zustand ausgeführt wird, in dem sich der Vertrag zum Zeitpunkt des Sendens dieser Transaktion befand.
Wie können wir sicherstellen, dass ein Benutzer, der eine Transaktion mit einer Funktion durchführen möchte, B1eine Transaktion mit einer Funktion durchführen möchte, B2ohne dass jemand anderes den Status ändert, der durch eine B1erneute Transaktion mit verursacht wurde?
Wenn einige der Variablen temporär sind und in ihren Funktionen enthalten sein können, können Sie möglicherweise B1()von innen aufrufen B2(), wodurch die Beschränkung der Stack-Tiefe umgangen wird, während die Ausführungsreihenfolge weiterhin garantiert wird.
Wenn Sie es in zwei Aufrufe aufteilen müssen und es wichtig ist, in welcher Reihenfolge sie aufgerufen werden, müssen Sie die Abhängigkeit möglicherweise selbst verwalten. Schreiben Sie beispielsweise eine Variable in B1()und checken Sie sie ein B2()und rufen Sie sie auf, revertwenn sie nicht geschrieben wurde.
blockchainenth
Edmund Edgar