Private contract accessing public variables on public contract aborts execution

[rsarres]

Consider the following scenario:
ContractA is PUBLIC
ContractB is PRIVATE

contract ContractA {
mapping (bytes32 => bool) public contractAmapping;
}


contract ContractB {
mapping (bytes32 => bool) public contractBmapping;

function test(bytes32 _mappingID)  {
        ContractA contractAobject = ContractA(contractAaddress);
=>    contractBmapping[_mappingID] = contractAobject.contractAmapping(_mappingID); 
       (code continues....)
}
}

I have the following issue: When I remove the line with an arrow where contractB reads contractA´s mapping, everything works and the (code continues...) executes . If the line with an arrow is present, (code continues...) never executes.
AFAIK, my private contract is not making a state change in the public contract, it is only reading a variable on a read only VM, like this:
S -> (A) -> [B]
I tried to encapsulate the mapping with a getter function and got the same behavior.

[tylobban]

Hi @rsarres, what is the rest of the code actually doing? If it's updating state in ContractB then that may be the problem. Would also like to see what happens if you make the function a constant.

[rsarres]

Thanks @tylobban. Yes, it updates the state of the private ContractB. I may have misunderstood the Quorum Design doc as it states that S -> (A) -> [B -> C] transaction is allowed. Doesn´t it mean that the read-only VM state is only applied to the public contracts B and C and the private contract (A) can have its state changed?
Finally, I need to update ContractB state based on the information read from ContractA, so in my understanding I cannot use a constant function.

[tylobban]

@rsarres hi! Can you please confirm which version of solidity you are using for your contracts? It looks like this issue is caused by changes that were made in the 0.4.0 release of Solidity and incompatibility with the geth version that Quorum is currently on. Please can you try compile your contracts with 0.3.6 and let us know if that works? We will soon be working on upgrading geth to a later version.

[rsarres]

Hi @tylobban . Sorry about the delayed response, I was away from office last week. I am working on the vagrant VM of the 7nodes example. The geth version output is:

Geth
Version: 1.5.0-unstable
Git Commit: 6d0bd810484f4c56f7c9aebc229e1bdc56832ced
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.3
OS: linux
GOPATH=
GOROOT=/usr/local/go

The solc --version output is:

solc, the solidity compiler commandline interface
Version: 0.4.8+commit.60cc1668.Linux.g++

I will try to compile the contracts with 0.3.6 version and post the results.
Thanks.

[rsarres]

Hi @tylobban .
Compiling both contracts on 0.3.6 solved the problem.
Thanks very much for your help.

[mattcrooks]

Hi, just wondering if this issue is fixable and if it is on the road map. We are experiencing the same issue and the workaround (compile in 0.3.6) is working for us but we'd like to take advantage of some of the improvements post 0.4.10.

Many thanks, Matt.

[jpmsam]

@mattcrooks @rsarres this should have been fixed with Quorum v2. I'll confirm before closing the issue but let us know if you are still experiencing it too.

[rsarres]

@mattcrooks @jpmsam Hi. I have just tested the contracts compiled in 0.4.21 and 0.4.10 and the behavior is the same: Everything runs fine when following the 5nodesRTGS readme instructions until the sendValue call, the first call of a function that performs a contract-to-contract interaction. Debugging this call, I saw that it ends with a REVERT in 0.4.21 and with a "Missing opcode 0xfe" in 0.4.10. I am using Quorum V.2.0.0.

[rsarres]

@mattcrooks As an example, I have just committed two new deploy scripts using precompiled contracts in Solidity 0.4.21 and 0.4.10 to the 5nodesRTGS git. If you follow 5nodesRTGS readme using one of these contract versions instead of the 0.3.6 script, you will see that the issue persists: function sendValue aborts execution.

[mattcrooks]

@rsarres @jpmsam Thanks for this, I will test this week and report back.

[fixanoid]

This has been resolved