Problem have been solved over here
Quoting nicksavers here
The thing is that if you did a fast-sync of
Geth >1.8.17 after the
block 4230605, it would have probably skipped the check on
that block and assume it's correct based on proof of work.... then
4238641. Similarly, if you start fast-sync now, you'll skip
fully verifying that block... etc. (explanation here)
The cause was apparently an implementation detail of
kept track of the refund inside each call, but defined it 'unsigned',
which made it impossible to become negative
The solution discussed as of this moment is to use the interpretation
of Geth. Parity has already solved the issue on their side with an
update (openethereum/openethereum#9746). Miners will start mining on
the Geth Constantinople chain on Ropsten to make sure it becomes the
canonical chain. The Parity update should be able to follow it. If
another conflict arises, it will be dealt with at that time.
Progress should be posted on notes, but it's a little bit behind on
the latest information.
Since the error had been solved. But if you are facing this issue please re-sync your node from the start.