Ethereum Merger Testnet Error Fixed – Trustnodes

There was a problem with endians, those being “the order or sequence of bytes of a word of digital data in computer memory.”

“Prysm beacon node used incorrect endianness to marshal/unmarshal the base_fee_per_gas field in execution_payload object,” says Prysmatic Labs, the devs behind the most used eth2 client, Prysm. They add:

“Today, the execution layer uses big endianness, and the consensus layer uses little endianness.

Since Prysm incorrectly unmarshals execution_payload back to original form, the execution layer client correctly rejected the deformed payload when calling engine_newpayloadv1 endpoint by returning INVALID_BLOCK_HASH.”

In other words, the testnet did exactly what it was meant to do: test performance in a live network emulation now the product is out of the ‘lab.’

The error here so being due to the lab using a fixed unit, while the live network has some differences as Prysm says:

“This issue did not show up in the previous devnets [because] the base fee was 7 which is equal regardless of the endianness. It also did not show up in the unit tests because 7 was used as the input value.”

So a non error, error, but obviously necessary to catch with this showing more that development has reached the stage where they fine tuning every single thing to get ready for the big upgrade.

What makes this more interesting however is that it’s Prysm involved and still the testnet kept on working.

That’s because “the missing blocks account for ~15-20% of the total blocks.” You need around 33% for the network to halt.

On the current live Beacon chain however, Prysm is estimated to have 66% of the nodes. Something that, if anything goes wrong, would not only halt the network but might also cause it to require days for reboot.

So are we to expect node runners to take that 33% threshold share for any one client more seriously once eth is full Proof of Stake? Or is it more that in testnet, it is devs mainly playing and obviously they’re very aware of the necessity for client diversity?

That’s to be seen, but Prysm’s dominance began during the Beacon chain testnet in 2020 and then continued on to the livenet as well.

It not having such dominance in this new testnet, may well thus indicate they won’t have it on the new livenet either.

So far the Beacon chain is a dummy chain where no transfers are happening. So devs and node runners maybe didn’t think client diversity so important.

Once ethereum upgrade to full Proof of Stake however, these node clients will be running everything, the MakerDAO cascadingly sensitive CPDs, deposits to Coinbase, NFTs, and even Land on Decentraland.

The stakes therefore reach the point of total. And so we have an indication that devs are, faced with that situation, taking the node threshold very seriously.

Something that may be the real unbugging here, if it continues to remain the same on livenet too.