Kintsugi Fuzzer Issue

Previously we have covered everything related to Kintsugi Testnet. In this article we will see the 1st Major Issue or Bug in Kintsugi Testnet after its launch in December.

Table of Contents
1. Core Idea
2. How did this happen?
3. What was expected?
4. What actually happened?
5. Conclusion
6. FAQs

If you prefer watching a video

Core Idea

So Basic Idea here is that Kintsugi Testnet has run into a chain split causing the POS blockchain to run in several parallel versions of the truth.

How did this happen?

So Marius van der Wijden created a Fuzzer which produces a valid block and then changes its blockhash to the parent hash to make it invalid.

Marius van der Wijden is one of the developers involved in running tests on Kintsugi and is currently Ethereum Core Developer working with the Geth client team.

Fuzzer is an an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. This is helpful in finding anomalies and exceptional outputs.

What was expected?

So, It was expected that nodes should reject such a changed block.

What actually happened?

Since the parent hash pointed to a valid block. Some implementations did not actually execute and verify the block but looked it up in a cache instead. Since the previous block was valid and in the cache, they assumed the new block to be valid as well. Geth clients {Execution Layer} rejected the block, while the other half, the Nethermind and Besu clients {Consensus Layer}, accepted it, causing the chain to split.

Conclusion

The result was that half the network rejected the block, while the other half accepted it, causing the chain to split since we now had two different views of the correct state. Now different forks of the Kintsugi testnet exist and every node thinks that they are on a correct fork.