# Development update 6

This is my sixth developoment update for the Ethereum CDAP programme.

## Task

Two weeks ago, the [Quilt team](https://github.com/quilt/), [Peter](https://github.com/ultratwo) and I finished implementing the Frontier version of the yellow paper. However, there were several `state` tests that needed to be passed. I set out with the goal of passing all the state tests.

## Challenges

There were several consensus bugs that I discovered along the way and I have fixed them in seperate pull requests.

## Code

The work for passing all state tests was split across multiple pull requests:

- My implementation of `SELFDESTRUCT` had a bug where I would destruct an incorrect address. While passing some more tests for `SELFDESTRUCT`, I figured out that our total gas consumed calculation was incorrect. The pull request for this can be found [here](https://github.com/ethereum/execution-specs/pull/332/).
- While trying to pass tests that made recursive `message-calls` using the `CALL` opcode, I encountered a problem with python's default recursion limit. I had to bump it up in order to get the tests passing. The PR for this can be found [here](https://github.com/ethereum/execution-specs/pull/334).
- Uncommented some tests that were previously commented out because the `RETURN` opcode wasn't implemented then. There were no bugs found here. The PR for this can be found [here](https://github.com/ethereum/execution-specs/pull/337).
- A discussion held in [discord](https://discord.com/channels/595666850260713488/856943705209569291/885164284903063596) made me realise that there was a bug in the refund logic for the `SELFDESTRUCT` opcode. The fix can be found [here](https://github.com/ethereum/execution-specs/pull/338).
- While try to pass some more tests, I realised that the gas consumed calculations for exceptional halting of the evm were incorrect. I have fixed it [here](https://github.com/ethereum/execution-specs/pull/339).
- Some logging tests helped me discover a bug in opcodes `CREATE`, `CALL` and `CALLCODE`. The child computation/execution frames created by these opcodes were not appending logs to their parent computation/frame. The fix can be found [here](https://github.com/ethereum/execution-specs/pull/340).
- Our gas calculations had a bug where a 256 bit integer variable would overflow. I had to implement some safe 256 bit arithmetic to handle such problems. The fix can be found [here](https://github.com/ethereum/execution-specs/pull/342).
- I further discovered that exceptional halting wouldn't set the empty substate during bytecode execution. All thanks to the tests for helping me discover this problem. Here's the [pull request](https://github.com/ethereum/execution-specs/pull/343).
- Also, address collision wasn't handled earlier. I have implemented it in this [pull request](https://github.com/ethereum/execution-specs/pull/345).
- The `BALANCE` opcode was returning incorrect values for the sender of the transaction. This was because we would charge the transaction fee at the end of the transaction execution. However, as per the yellow paper we have to charge the transaction fee before the transaction is executed. The fix can be found [here](https://github.com/ethereum/execution-specs/pull/346).
- I disocvered another consensus bug in the implementation of the `CREATE` opcode. Apparently, we forgot to consume all the gas left if there is an address collision error. I have fixed it [here](https://github.com/ethereum/execution-specs/pull/348).
- The Frontier version of the yellow paper has an incorrect value for the minimum gas limit for a block. Here's the [pull request](https://github.com/ethereum/execution-specs/pull/349/files) for it.

### Accomplishment

After all those bug fixes, I can finally say that all the `state` tests are now green.

## What's Next?

Now that the Frontier version is fully complete, we can start working on a new hard fork i.e `Homestead`. I have also been thinking about contributing to the new programming language [FE](https://github.com/ethereum/fe) that's being developed by the EF. Let's see how that goes. Until next time...