Tengo un contrato que llamaremos A que usa la función de transferencia de un contrato ERC20 que llamaremos B a través de una interfaz. Sin embargo, la función de transferencia no funcionará como se esperaba porque en la llamada del usuario -> A -> B, el remitente del mensaje ahora es la dirección del contrato de A y ya no la dirección del usuario.
Puedo pensar en dos formas inmediatas de resolver esto.
Sin embargo, ambas soluciones modifican el contrato estándar del token ERC20, lo que no estoy seguro de si es una buena práctica.
Puedo ver cómo esto podría ser un problema común con el que se encuentran los desarrolladores. ¿Debo implementar una de las soluciones anteriores aunque cambie el contrato estándar? Si no es así, ¿cómo debo resolverlo?
La forma adecuada de hacerlo es con el flujo de trabajo approvey transferFrom. El EOA haría approveel contrato para transferir los tokens y luego llamaría a la función en el contrato que usaría tranferFromen lugar detransfer
Parece que el uso de a delegatecall()través de un patrón de proxy es lo que está buscando.
Con la llamada de delegado, pasa el remitente original al siguiente contrato . Sin embargo, esto puede exponerlo a riesgos de seguridad para el contrato de llamadas. es decir, en su escenario contrato B, ya que está exponiendo el almacenamiento del contrato A al contrato B.
Hay otras publicaciones que explican cómo usar tales, por ejemplo, Diferencia entre CALL, CALLCODE y DELEGATECALL
¿Cómo funciona el método de llamada delegado para llamar al método de otro contrato?
Gran blog: https://blog.gnosis.pm/solidity-delegateproxy-contracts-e09957d0f201
señor amarillo
msg.senderes correcto, pero las actualizaciones de saldos no se guardarán en el almacenamiento asociado con el contrato de token.Jonathan Scialpi
señor amarillo
approve/transferFrompatrón. También están surgiendo varios borradores de estándares para agregar una devolución de llamada para informar un contrato de tokens que se envían. ERC223, ERC677, ERC827