Within hours of a bug that split Ethereum’s testnet being found, the problem was fixed and as was predicted, the glitch was related with the new Ethereum Improvement Proposal (EIP) which adds efficiency gains to calculations with only Parity to apparently be affected.
A Rust developer called, Wei Tang said:
“The bug has been fixed. It affects parity and aleth, which we had the same bug,” with aleth being a C++ eth client. He continued to say, “I fixed the SSTORE refund saturating sub bug and confirmed that it indeed computed the same state root as geth. I guess when Afri wakes up, we’ll try to get a patch release really soon which should fix the current consensus issue on Ropsten.”
An Ethereum developer called Martin Holst Swende tested the fix with it showing that the two main clients of Ethereum, Geth and Parity, can now be in sync. An independent research and software dev, Alexey Akhunov spoke on the matter and said:
“I suppose Parity just uses a different way of accounting the refunds. Instead of having global counter + changes in the journal, it has substrates with their own counters, which could be applied or not applied (if reverted) during the finalisation. I remember that geth had a similar approach before Shanghai DoS and then changed it to the journal. But I suppose Parity is much more sparing with allocations, so it can afford that.”
According to TRUSTNODES, this essentially means they take an alternate approach to calculating gas which is all well and good if they reach the same result.
“It is related to a gas refund for SSTORE gas reduction. Our code failed to account for the case that a substate refund can go negative. “The general idea to hard fork Ropsten is so that we can have real-world data to test the Constantinople hard fork so that bugs like this can be spotted. We had some expectations that Ropsten might be down for a few days (but we didn’t expect it to be a Saturday!). Of course, any consensus bugs on mainnet would be really serious.”
Since the bug has now been found and fixed, Parity needs to release a new client of sorts, after a new testnet block will be set and thus beginning the testing process once more.
What are your thoughts? Let us know what you think down below in the comments!