A bug that chain-split ethereum’s Ropsten testnet has been identified and fixed within hours.

As it was guessed, it had something to do with a new Ethereum Improvement Proposal (EIP) that adds efficiency gains to gas calculations with only Parity seemingly affected.

“The bug has been fixed. It affects parity and aleth, which we had the same bug,” Wei Tang, a Rust developer at Parity told Trustnodes, with aleth being a C++ eth client.

“I fixed the sstore refund saturating_sub bug and confirmed that it indeed computed the same state root as geth.” Tang publicly said around midnight London time before adding:

“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.”

Martin Holst Swende, an eth developer, tested the fix, with it showing that Geth and Parity, ethereum’s two main clients, can now be in synch. Alexey Akhunov, an independent researcher and software dev, said:

“I suppose Parity just uses a different way of accounting the refunds. Instead of having global counter + changes in the journal, it has substates with their own counters, which could be applied or not applied (if reverted) during the finalisation.

I remember that geth had 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.”

In other words, they take a different approach to calculating gas, which is fine as long as they both reach the same “number.” That didn’t happen with a Trump tweet inserted into eth’s testnet, which split the chain as Parity and Geth charged different gas amounts.

“It is related to gas refund for SSTORE gas reduction. Our code failed to account for the case that a substate refund can go negative,” Tang says. Asked how serious was the bug, Tang says:

“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. That’s why we want to do extensive testing and code reviewing — either using Ropsten testnet or via hand-written testcases — before it touches mainnet.”

With the bug now identified and fixed, Parity needs to release a new client of sorts, following which a new testnet block will be set, so starting the testing process again.

Does that mean this can still be in time for November? “No comment,” says Tang who must have been far too busy patching Parity.

Our out of nowhere guess would be that this probably can still make it for November if no other issues are found. That’s because with this bug so quickly identified and fixed, the delay might be just a few days.

Devs, however, are preparing for Devcon4, so that might be a bit of a “distraction.” Then there’s Christmas – an even bigger distraction. Then there’s Bitcoin’s birthday on January the 3rd which may be around the time they launch the issuance reduction eth upgrade if they can’t make it for November.

Afterwards, the big Ethereum 2.0 upgrade starts unfolding, beginning with the Proof of Stake Beacon Chain which may reduce issuance even further. Then in 2020 we have the shards, followed by the completion of the first stage of Ethereum 2.0.

Once this is done they’ll shard the shards. In addition, the EVM just copied by Tron will be discarded for eWASM.

With it all creating a new modern, scalable, environmentally friendly, one CPU (32eth) one vote, public blockchain with smart contracts, dapps and all the rest.

Delays however should be expected as much of this is fairly complex. But it looks like they now at least know where they are going and how to get there. So as long as they keep working at it, as long as they keep making progress, we’ll wait.

Copyrights Trustnodes.com