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

Image for post
Image for post

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 can write to storage[node] and storage[node + 0x40] to set the resolver and TTL, respectively. …


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.

Image for post
Image for post

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 so it is no longer a one-to-one copy of the specification. This means beginning to “swiftify” the code and unpacking logic into multiple classes rather than one monolithic file. …


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.

Image for post
Image for post
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.

Reimplementation

After having implemented the spec, we realized that some of our handling of changes to the spec was a little broken and the code had diverged from it. Therefore, we decided to re-implement the spec from scratch. …


Ethereum 2.0 in Swift & BeaconChain.swift updates

Image for post
Image for post

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:

BeaconChain.Swift

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, so the code does not yet follow best design practices. Danny Ryan, one of the researchers working on Ethereum 2.0, …


Allowing for cheaper data submission when validation is expensive

Image for post
Image for post

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 of the “Counterfactual: Generalized State Channels on Ethereum” blog post. …


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

Image for post
Image for post

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 to the fact that cost is one of the first steps of deterring squatters, it is a simple method to disincentivize a user from registering every possible domain on day one. …


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.

Image for post
Image for post

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.

Today, the .luxe TLD was enabled on ENS on the Ethereum Mainnet, with the deployment of a new registrar smart contract. This is the first step in launching the TLD publicly; it provides the infrastructure necessary for supportinng DNS registrars such as Alibaba and Encirca to ENS-enable their customers’ domains. …


The flaws of shareholder voting and blockchain governance

Image for post
Image for post

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 decisions and advancing blockchain norms. …


Image for post
Image for post

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 and the ethereum ecosystem using ENS. The basic idea is that today to register a domain, or use any other dapp, the users must already be blockchain “experts”, they must have a wallet and some ether, which implies that they have gone through an exchange’s KYC process; this is not a user friendly experience and needs to be solved with a flow where a “no-coiner” can get a name, a wallet and tokens to start using dapps. Beltran’s beliefs were that ENS has the perfect position to be this entry point, and could offer a valuable place for new users to go and get introduced to various different dapps as part of alliance of companies who contribute to onboard users to the blockchain, sharing among them the web3 version of the “customer acquisition cost”. …

About

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