Ich habe einen Vertrag, den wir A anrufen werden, der die Übertragungsfunktion eines ERC20-Vertrags verwendet, den wir B über eine Schnittstelle anrufen. Allerdings funktioniert die Transferfunktion nicht wie erwartet, da beim Aufruf von Benutzer -> A -> B der msg.sender nun die Vertragsadresse von A und nicht mehr die Adresse des Benutzers ist.
Ich kann mir zwei unmittelbare Möglichkeiten vorstellen, dies zu lösen.
Beide Lösungen ändern jedoch den ERC20-Token-Standardvertrag, von dem ich nicht sicher bin, ob dies eine gute Praxis ist.
Ich kann sehen, dass dies ein häufiges Problem sein könnte, auf das Entwickler stoßen. Soll ich eine der oben genannten Lösungen implementieren, obwohl sie den Standardvertrag ändert? Wenn nicht, wie soll ich es dann lösen?
Der richtige Weg, dies zu tun, ist mit dem approveand transferFrom-Workflow. Der EOA würde approveden Vertrag zum Übertragen der Tokens und dann die Funktion für den Vertrag aufrufen, die tranferFromstattdessen verwenden würdetransfer
Dies scheint, als ob die Verwendung von delegatecall()über ein Proxy-Muster das ist, wonach Sie suchen.
Mit Delegiertenruf geben Sie den ursprünglichen Absender an den nächsten Vertrag weiter . Dies kann Sie jedoch Sicherheitsrisiken für den Anrufvertrag aussetzen. dh in Ihrem Szenario Vertrag B, da Sie den Speicher von Vertrag A für Vertrag B freigeben.
Es gibt andere Beiträge, die erklären, wie man solche verwendet, zB den Unterschied zwischen CALL, CALLCODE und DELEGATECALL
Wie funktioniert die Methode "delegatecall", um die Methode eines anderen Vertrags aufzurufen?
Toller Blog: https://blog.gnosis.pm/solidity-delegateproxy-contracts-e09957d0f201
HerrGelb
msg.senderkorrekt ist, aber die Saldenaktualisierungen werden nicht im Speicher gespeichert, der dem Token-Vertrag zugeordnet ist.Jonathan Scialpi
HerrGelb
approve/transferFromMuster. Es werden auch mehrere Standardentwürfe für das Hinzufügen eines Rückrufs zur Information eines Vertrags über das Senden von Token in Vorbereitung sein. ERC223, ERC677, ERC827