ENS hackathon winners interview (2nd place)
Hi, Congratulations on winning the 2nd place. Can you introduce your team members?
Richard(@ricmoo): Heya!
I started off in the blockchain space back with Bitcoin, which had quite a following in Toronto, where I met Decentral and wrote their Bitcoin wallet, Jaxx. My biggest interest in blockchain was censorship-resistance and decentralizing authorities though, so of the various projects, Namecoin piqued my interest the most. Once Ethereum came along, the possibilities with it seemed far more broad and exciting, so that’s where my focus shifted. Then during DevCon2, Nick Johnson presented his ENS and, well, to quote Liz Lemon, “I want to go to there”.
These days I have two main projects I spend my time on: ethers.js, which is a complete and compact library for all your Ethereum needs and Firefly, the $5 DIY Air-Gapped hardware wallet.
Yuet(@yuetloo): I was introduced to the blockchain space by Richard. We started going to Ethereum meetups and hackathons together. We were also fortunate enough to win a few of the hackathon projects that we did together, one of them was the firefly hardware wallet. Hackathons are a lot of fun and are the best way to meet people who are passionate about the blockchain technology and who want to make great products with the technology.
Both of you were in the “1st Solidity Gas Golfing Contest” programming contest leaderboard which is very impressive (in fact we invited both of you because we recognised your ENS names through the contest). Tell us more about the experience.
Richard: The Solidity Gas Golfing Contest was a lot of fun, and I learned a lot about about some odd choices the compiler makes (or more likely, odd choices that the optimizer makes it look like the compiler is making). I find Solidity has a lot of parallels with hardware development, which makes it very satisfying to conquer problems. Memory and storage is expensive and slow, every instruction cycle counts and in the real world once you deploy hardware or Solidity, it is very hard to change/upgrade. At the end of the day though, for all the tweaking that went into the Solidity and re-ordering statements, the most important thing was to choose a smart (but not too smart) algorithms.
Yuet: It’s a really good learning experience for me to discover the importance of a good algorithm in Solidity performance improvement. I was re-visiting a lot of the well-known algorithms and apply them in the solidity contract and was able to achieve significant performance improvement.
Can you explain to us more about your project “Firefly Offline Trustless ENS Name Transfers and Attested Templates w/ ENS” ? How did you come up with the idea? What does it do? Why did you think it was a great way to integrate with ENS? What was the biggest challenge?
Richard:So, this is actually something we have had planned since the beginning, but have not had the time to work on, so this Hackathon seemed like the perfect opportunity. We have had a crowdfunding campaign for Firefly for over a year, where anyone can register a sub-domain under the “firefly.eth” ENS name, and if you look at the contract, sub-names must be 20 characters or less, which is suspiciously the exact length that fits on the Firefly screen.
We want to move the Firefly to be a hardware wallet that makes use of an on-chain multi-sig (by default). We have a lot of layers (which we work hard to abstract from the customer), but some highlights are:
- a) the multi-sig is available to receive funds immediately
- b) the multi-sig is not actually deployed until funds are received (so empty accounts never waste on-chain space)
- c) the customer does not require gas to deploy their multi-sig
- d) there are many levels of account recovery available
- e) we can do some very cool things with plug-ins, such as this hackathon project
The way sending to an ENS address is done today, for example, in MyCrypto, is once you type in “ricmoo.firefly.eth” it queries their servers, calling ENS to lookup the current address of “ricmoo.firefly.eth”. This is then shown up in the UI, under “ricmoo.firefly.eth”. If you use a hardware wallet with MyCrypto, this address is also shown there, to which the user then accepts the transaction and the ether is sent. The problem is what if the MyCrypto servers were compromised, or if you agreed to allow insecure certificates from the Starbucks Wi-Fi? Then the call you thought your were making to ENS, may return an attackers address instead. The address shown in MyCrypto is already wrong, which means the address on the hardware wallet is wrong. Despite everything agreeing, the ether is sent to the wrong address, through no fault of the customer.
By moving the lookup step to an on-chain multi-sig plug-in, the ENS name can be looked up, trustlessly against ENS at the time the transaction is mined on the network. This provides two main advantages:
- a) The Firefly shows a far more user-friendly “send 1 ether to ricmoo.firefly.eth?” (rather than some complicated address)
- b) once the user agrees to the transaction, it is certain that the ether goes to the intended recipient.
In terms of challenges, there are always a few hiccups when you have so many moving parts. We needed to modify the iOS Wallet App to support the on-chain FireflyVault multi-sig Wallet plug-ins, update the Firefly firmware to understand the transaction type and show the value and ENS name on the display (which we decided to include a shiny new, legible font) and then actually get the FireflyVault to process the signed plug-in messages. Nothing specifically stands out, it was a classic weekend of a healthy level of hackathon stress.
This hackathon’s focus on health was nice though; we never felt that bead of sweat running down our forehead, moments before the deadline and moments after breaking some key feature while attempting to add a superfluous one.
Richard, Your other project ethers.js natively supports ENS as a first class citizen. Tell us more about the project and its ENS feature. Are there anything you found difficult about integrating ENS? Do you have any suggestions to make ENS better?
Richard:The ethers.js library is a full Ethereum library that is meant to be complete, but also small. It currently weighs in at 85kb over-the-wire and includes everything you need to create a full wallet, or a dapp or build an Ethereum framework. It is meant as a complete replacement for Web3, EthereumJS, BIP39, et al.
I consider ENS one of the most valuable technologies available on Ethereum, so I wanted to make sure it was as easy to use as possible. In ethers.js, anywhere you can specify an address, you can also specify an ENS name, for example if querying a provider for an account’s balance (e.g. provider.getBalance("ricmoo.firefly.eth")), or calling a contract function (e.g. any ERC-20 contract can use: contract.transfer("ricmoo.firefly.eth", amount) .
To be honest, ENS integration was incredibly easy. The ENS Registry contract and resolver contracts are very elegant in their simplicity, which made adding support fairly trivial. Since all the operations on the network are asynchronous, it was easy to just inject an ENS name lookup earlier in the functions.
What is next for your project?
Richard: The quality of this feature and code is very much that of a short hackathon. There were a lot of short-cuts taken and assumption made, that can be made during a quick demo, but need to be more robust for actual use. We plan to add a much more optimized, and more general plug-in system to the FireflyVault multi-sig wallet and add a plug-in type for ENS names in the Firefly firmware, so any token can also be trustlessly transferred (e.g. “Transfer CryptoKitty: #1,337 to ricmoo.firefly.eth”), or ENS names themselves can be managed, (e.g. “Finalize Auction: foobar.eth” or “set address: foobar.eth to 0x123456…CDEF”).
We are also working on a plasma chain (ish) solution to do some very bizarre and interesting things by exploiting (borderline abusing) human psychology. I’ll just leave that sentence as a teaser of things to come. Mwa ha ha. :)
Anything I didn’t ask but you want to tell to the readers?
Richard:Usually when I consult for a company, after their elevator pitch of their product, my first question is almost always “but why blockchain?”. Most of the time, we eventually agree that maybe blockchain doesn’t make sense, but that they still plan/want to use it. This usually inspires the question, “Well then… What *does* need blockchain?”. My response is basically “ENS and CryptoKitties.”
ENS is a game changer. I often say this jokingly, but that whole truth-and-jest thing has merit: “If ENS was the only thing to come out of Ethereum in the end, I would consider Ethereum to have been a wild success.”
Just try disabling your DNS server, and see how much fun the internet is. :)
