Haga que msg.sender permanezca constante en contratos anidados de solidez

Tengo tres contratos diferentes. Uno es un contrato simple (ContractA), el segundo es mi contrato de token y el tercero es el contrato de token ERC20 que se hereda en mi contrato de token. Entonces, cuando hago una solicitud desde mi interfaz (reactjs) a mi ContractA, envía esa solicitud a mi contrato de Token, que envía la solicitud al contrato de token ERC20 para transferir el token a una dirección.

El problema al que me enfrento es que al llamar a las funciones, la dirección del usuario se cambia al contrato que llama al otro contrato. ¿Cómo puedo hacer que el contrato sea constante durante toda la ejecución? Lo que significa que la dirección del contrato debe ser el usuario que originó la solicitud desde la interfaz.

Nota: No puedo cambiar mi implementación en mi contrato de token porque ya está implementado.

MiContrato.sol

function sellTokens(address _from) public {
        require(myToken.balanceOf(_from) >= 1);
        myToken.transfer(_deployerAddress, 1);
}

Aquí está mi función sellTokens que transferirá un token al propietario del token. Esto se llama desde el archivo myContract .

La función de transferencia se implementa en la implementación del token ERC20 de OpenZepplin. Ahora, cuando llamo a la función de transferencia, obtiene el mensaje msg.sender como el contrato, que es myContract. Y a cambio, me da un error porque la cantidad excede el saldo ya que myContract no tiene tokens. myToken es aquel en el que se hereda el token ERC20.

Respuestas (2)

No estoy totalmente seguro de entender su pregunta, y lo que puede y no puede cambiar, y cuál es la diferencia entre snaToken y myToken. Está comprobando el saldo de snaToken pero luego envía myToken. ¿Qué está sucediendo exactamente allí?

Pero de todos modos, ¿conoces el mecanismo de asignación? (funciones .approve y .transferFrom) Puede usarlo para hacer esto:

  1. El usuario llamará para aprobar MyContract. Significado: su interfaz le pedirá al usuario que firme una transacción de "aprobación" para el token que desea transferir. Entonces, si, por ejemplo, desea que el usuario envíe sus myTokens, primero debe llamar y firmar: myToken.approve (myContract, transferAmount). Esto da permiso para que el contrato de myContract envíe tokens transferAmount desde msg.sender a quien elija myContract.
  2. Luego, el usuario llamará a MyContract sellTokens, pero ahora sellTokens no llamará a .transfer, pero llamará a transferFrom: myToken.transferForm(msg.sender, destinationAddress, transferAmount). Esto transferirá los myTokens del usuario a la dirección de destino.

Espero que esto ayude, pero como dije, no estoy seguro de cuál es la relación entre myToken y snaToken y por qué está comprobando el saldo de uno y enviando el otro.

Muchas gracias por la ayuda, tu método funcionó de maravilla. Además, hubo un error: snaToken es lo mismo que myToken. Simplemente olvidé cambiar el nombre de snaToken a myToken, lo he corregido.

debe usar tx.originen lugar de msg.sender, si hay múltiples invocaciones de funciones en múltiples contratos, tx.origin siempre se referirá a la cuenta que inició la transacción, independientemente de la pila de contratos invocados. Sin embargo, msg.sender se referirá al que llamó al contrato, podría ser una dirección de contrato inteligente.

Gracias por la sugerencia. ¿Puede volver a revisar la pregunta y decirme si ahora tiene sentido? He agregado algunos detalles más para aclarar más. Habría usado tx.origin si tuviera el código myToken conmigo o hubiera hecho otra implementación. Dado que el código myToken está implementado y no puedo cambiarlo, tengo que buscar diferentes implantaciones en las que msg.sender permanezca constante durante la ejecución.
Lo siento, no lo entendí bien, en ese caso, debe usar el mecanismo approve+ transferFromde erc20 en lugar de la función de transferencia. Las funciones de transferencia solo se pueden llamar directamente.
Haga que msg.sender permanezca constante en contratos anidados de solidez
RespuestasAquíPolítica de privacidad1y, 0v