There a few random technical topics which I have coherent enough thoughts on to make them public. It's a short list, but here it is. If you're looking for my personal [blog], it's over here.
What the hell is an enshrined bridge?
in 2016, a reentrancy attack drained a smart contract of 3.6 million Ether (now worth $billions) and caused a hard-fork of the Ethereum network. In this case, the ordering of three lines of code was the the root of the vulnerability. Because the attack was so substantial, and because it used quite an interesting exploit, most Solidity developers are familiar with this attack and use the common Checks-Effects-Pattern (CEI) to prevent against it. But I’ve also encountered (both myself and from others) quite a bit of confusion on exactly how following this pattern prevents against attacks. So I wanted to write about it, and in a way that non-Solidity devs can also understand.
TLDR: Dealing with Solidity arithmetic is non-trivial. I built a tiny JavaScript library to help with this.
Last week, MIMO launched the KUMA protocol, an Ethereum-based protocol that brings interest-bearing tokens backed by real-world bonds. It was the first DeFi protocols that I’ve played a small role in developing from start to finish. Witnessing all stages - from initial ideas and specs, implementation, security audits, and integrations, has all been awesome experience as a blockchain engineer. As this marks a milestone, I’d like to reflect on what I’ve learned in the past 1.5 years of Solidity development, comparing my initial experiences with Solidity with where I am now as a slightly-more-experienced blockchain-engineer. Also, it might be fun to remind myself how utterly incompetent I was not too long ago.