A deeper dive into CVE-2020–5232 and how we handled it.

As you probably know by now, the ENS registry was recently migrated from the old LLL contract to a newer Solidity contract. The reason was a bug we have not yet made public found by the one and only samczsun. This post will give more details of how the ENS team handled the situation.

On November 8th, the night before Nick Johnson’s wedding, we were forwarded an email from Martin Holst Swende that was submitted to the Ethereum bug bounty program.

This writeup references the ENS registry: https://github.com/ensdomains/ens/blob/master/contracts/ENS.lll

The owner of a node is located in storage[node + 0x20], but…

And how to fix it…

Constantinople was delayed, and it was delayed due to a pretty obvious flaw. Although the flaw was obvious, the decision to delay the upgrade was made last minute because the bug itself was found last minute. Had the flawed EIP been actively looked at by a broader community earlier, the flaw would’ve probably been abundantly clear (yes, there is some hindsight bias to consider here).

Finding and reporting flaws in an EIP draft has little to no incentive — not just limited to economic incentives, but also social ones. …

BeaconChain, BLS & Libp2p

Since our updates roughly one month ago we’ve continued active development on our ETH 2.0 implementation. We’ve made significant progress implementing both the BeaconChain as well as active development of various technology surrounding it.

Contributions to the BeaconChain spec

We were again able to contribute to the BeaconChain spec by simplifying the is_power_of_two function.

The code not only reduces the complexity of the previous implementation but is also more efficient, as was discovered in trinity.

BeaconChain Updates

Our BeaconChain went through various updates over the past month, not only did we implement the spec version 0.4.0, but we also started working on cleaning up the code base…

BeaconChain re-implementation & Beginnings of BLS

Since announcing yeeth, we have been actively working on many of our code bases to continue development of ETH 2.0 in Swift. Over the past 2 weeks, we made significant progress on multiple fronts:

Contributions to the BeaconChain Spec

Our updates over the past two weeks included contributions to the BeaconChain specification itself along with multiple minor fixes, including spelling mistakes and naming issues. Additioanly we defined a new helper function.

Pull Request #567

One of our contributions moved some duplicated code into a helper function to calculate the total balance of a set of validators.


After having implemented the spec, we realized that some of our handling…

Ethereum 2.0 in Swift & BeaconChain.swift updates

Last week, I decided to start implementing an Ethereum 2.0 beacon chain for fun. This quickly transitioned into making plans for building a fully fledged Ethereum 2.0 client in swift.

Yeeth: Yeezy Ethereum, pronounced: how Mike Tyson says “yes”

Soon after deciding on working on this implementation, Eric Tu joined me in building it. We’ve made some good progress since the beginning. Here are our updates:


The first thing we are working on is the beacon chain implementation itself. Since beginning, we made significant progress and the specification has been fully implemented. The implementation is currently one-to-one to the specification…

Allowing for cheaper data submission when validation is expensive

At Devcon4, Richard Moore, Nick Johnson and I got into a conversation about counterfactuality and what that means in the context of smart contracts that are trying to find efficient schemes for validating data on-chain. We realized that there is another model for smart contracts that is not really counterfactual. Counterfactual smart contracts are contracts where things could be happening on-chain but do not. They allow any participant in a transaction to make something happen on-chain, meaning participants can act as though a transaction happened on-chain without it happening on-chain. For a more in-depth description, check out the terminology section…

Our reasons behind why we think the Harberger tax model is not ideal for the rent of domains on ENS.

The current method to obtain ENS domains involves an auction that many users have discovered to be a confusing process. In order to improve the overall UX a new system needs to be put in place to obtain domains and rent them for a desired amount of time. It was always part of the roadmap to move away from the current model, but finding something which works and is considered to be fair by users can be rather tricky.

In a domain name system it is important that there is a cost associated with obtaining a name. This is due…

Recently, Nick announced an integration with the .luxe TLD — the first time an internet-wide top-level domain will natively support ENS. This permits anyone with a .luxe domain to use their domain both in DNS and ENS simultaneously, simply by entering their wallet address in their registrar’s control panel.

ENS is excited to see this development, as it integrates ENS and Ethereum closer with legacy Internet technologies such as DNS. Improvements like this are crucial in improving the usability of Ethereum and applications built on top of it, by doing away with t1he need to enter long, opaque addresses.


The flaws of shareholder voting and blockchain governance

This post mainly addresses blockchain governance. It was written mainly with blockchains in mind rather than blockchain based protocols. However, points made can be applied to both.

On-chain governance discussions often seem to be based on corporate board decision-making. This is a paradoxical issue, given the values behind decentralization. If shareholder voting works for companies then token holder voting must somehow work for all blockchains. This analogy is also used to support the view that token holder voting is not plutocratic. Making this connection allows supporters to suggest token holder voting is both a way of the stakeholders making informed…

On the 10th of August 2018, the ENS team hosted a unconference style workshop to discuss important topics around ENS and its future. In this post we try and highlight some of the key takeaways from every session.

The unconference topics were suggested by participants using session cards, then 3 topics were chosen by public votes. At the end of the event we had a lightning talk session where everybody could demonstrate what they are working on in the ENS space.

ENS as an entry point into blockchain

The first discussion was lead by Beltran, it revolved around creating an entry point into blockchain…

Dean Eigenmann

Working on one too many projects.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store