La función de llamada geth de un contrato diferente no funciona, ganache y remix funcionan

Estoy tratando de llamar a una función de contrato desde otro contrato, usando web3.js.

Al usar ganacheo remixtodo funciona bien: web3.jsdevuelve los eventos disparados y el gas usado (33938 en este ejemplo) y los campos relevantes en los contratos están siendo cambiados.

Sin embargo, cuando estoy usando gethtodo lo anterior funciona, pero solo mientras no llame a la función de otro contrato.
Al hacerlo no se devuelven los eventos, no se modifican los campos y el gas devuelto es 90000 o el gas que estoy enviando en las sendopciones web3 (ej.c1.methods.transferToC2(1).send({from: <my account address>, gas: 2000000});

Estos no son exactamente los contratos, pero para una comprensión general del problema, la estructura de los contratos relevantes es algo así como:

Contract c1 () {
    event Event(uint256 someNumber);
    address private c2Address = 0x208bcebf6cfa80fe2862fcdacdeb6ad9d3533017;
    address private someAddress = 0x5e7105a34ed27f0b72285f2f951394f3da3ea5eb;
    function transferToC2(uint256 someNumber) public  {
        Event(someNumber);
        IERC20(c2Address).foo(someAddress, someNumber);
    }
}

Contract c2 is ERC20 () { 

}

interface IERC20 {
    function foo(address someAddress, uint256 someNumber) public returns (bool);
}

contract ERC20 is IERC20 {
    mapping (address => uint256) internal someMapping;
    function foo(address someAddress, uint256 someNumber) public  {
        someMapping[someAddress] = someNumber;
        return true;
    }
}

Estoy implementando los contratos truffle migrate --network <network> --resety el resultado es algo así como:

Deploying c1...
... 0x703293ce078c3c50e6da8725c6e9a4b91ae904c2943929c8e4189069dccc3de8
c1: 0xed8b7d949b961b1135199e08a9180f5328234426
Deploying c2...
... 0x1b54c170d4fccc13724ee9000078ff437b49883438413e5bf8da68d9343ca6d8
c2: 0x208bcebf6cfa80fe2862fcdacdeb6ad9d3533017

Dentro del nodo geth parece que el saldo de la dirección de mi cuenta siempre está creciendo, supongo que como resultado de la minería.

Es imposible responder con precisión si no nos proporciona la fuente del contrato. Comprobaría si la dirección del segundo contrato es correcta, si el contrato A llama al contrato B dentro de B msg.sender will be contract A not the original sender. If B is an ERC20 token and A want to transfer tokens from the user it has to call transferFrom` (el usuario tiene que approvecontratar previamente a A para hacerlo).
@ismael es por eso que di un ejemplo similar a mis contratos. No estoy interesado en este momento en transferir los tokens, sino en entender qué es lo que no funciona cuando se llama a la función de un contrato diferente. En lo que a mí respecta, todos los nombres no habrían estado relacionados con las transferencias. He editado mi respuesta para que se entienda mejor.
Probé tus contratos de ejemplo y funcionan correctamente tanto en remix como en geth. Verificaría que la dirección del segundo contrato sea correcta, el segundo contrato tiene una verificación adicional que podría fallar. ¿Qué versión de solidity estás usando? ¿Están habilitados los códigos de operación byzantinum en la red que está probando?
@Ismael Gracias por la dirección a byzantium, ahora funciona al agregar el byzantiumBlockal genesis.jsonarchivo

Respuestas (1)

Siguiendo la dirección de Ismael, agregué a genesis.jsonla byzantiumBlockdefinición, por ejemplo:

"config": {
    "chainId": 6035,
    "homesteadBlock": 0,
    "byzantiumBlock": 0 //added this
},

Y el problema paró.