Dear Bankless Nation,
I just got back from DevConnect in Amsterdam.
DevConnect was organized by the Ethereum Foundation, with the goal of getting all the Ethereum developers in one spot, so they can all sync on progress.
The amount of progress that was made in the last week was insane. Not just from the ETH core devs and client teams, but for the surrounding ecosystem participants too. The L2 teams synced at an L2 summit, DeFi projects gave out bounties at the Hackathon. Web2 to Web3 bootcamps onboarded new devs across things like StarkNet, zkRollups, IPFS, light client tech, and so much more.
I’ve been to a lot of conferences in the last 18 months, and this one was unlike any other. People were here to build.
I was chatting with an Ethereum developer, Alex Stokes, and he said “we’ve achieved months worth of All-Core-Dev calls all in this one week of time”.
Shit got done at DevConnect 💪👷♂️🛠
So much was learned during this magical week, and I want to share it all with you.
Here are my 5 takeaways from DevConnect 👇
1. The MEV problem is critical
The highlight of DevConnect was MEV.day (Friday).
All of the greatest minds in the same came together to discuss: What the hell are we going to do with this massive MEV problem that’s insidiously growing?
Justin Drake—the cryptography maximalist—gave a talk about how all MEV problems are solved with cryptography.
Vitalik gave a talk on block Proposer-Builder Separation (PBS), Danksharding, and MEV in ETH 2. It was pretty complicated; most went over my head so I still need to take some time to digest it. Here are the slides for those interested.
Even Hasu gave a presentation, beamed in from an external location (although rumor is he was physically present).
MEV on ETH2: MEV-boost, PBS, Danksharding... How do the pieces fit together?
Phil Daian, the man who discovered the existence of MEV in the first place, gave an updated talk titled “MEV... wat do next?” on the current state of MEV.
According to Phil… the situation is pretty dire.
I’ve taken 5 slides from his talk, and added a summary to each one:
Once they’re uploaded, talks will be available here.
2. Ethereum devs are not playing around
DevConnect is exactly what the name implies: all the devs getting in one place and connecting.
There were two things that had complete consensus by everyone I talked to at DevConnect.
- Amsterdam is an amazing city.
- Everyone got a ton of work done.
It was pretty surreal to see Danny Ryan, Justin Drake, Vitalik, Dankrad, Preston Van Loon, and so many other core devs, client devs, and researchers all packed into one room, looking at a whiteboard or monitor.
I lost track of the number of times I heard about a successful ‘shadowfork’ (where devs forked the Ethereum main chain, to do a “practice Merge”).
‘The Merge’ is what mainstream knows is on the horizon for Ethereum, but there’s also so much development occurring with other aspects Ethereum too, as shown in Trent’s tweet above.
Ethereum development is tackling many problems in parallel, making on-site workshops an incredibly valuable time to cross-pollinate the development efforts of all the tracks.
3. L2 wars are going to be spicy 🌶 🔥🌶
While the ETH devs were focused on the Merge and Beyond 🔜™️, the L2 teams were at Layer Two Amsterdam.
Dankrad Feist opened up the day with a talk that outlined the 6 big checkboxes that L2s all need to work on. Every major L2 team was present, and it was immensely useful to have Dankrad illustrate what’s left to do for the L2 ecosystem before we can claim a job well done.
Here’s Dankrads “Big Five” checklist for L2s:
- Parallelize execution (1 cpu core → many cpu cores = faster Rollups!)
- Support light clients (no data centers for Rollup nodes! Laptops pls!)
- Make scalable escape hatches (User empowerment & soverignty!)
- Business Development (Need to onboard business use cases!)
- Figure out governance (Tokens?? but how??)
You can see Dankrad’s slides here (but you’ll likely need to watch the talk too, video not yet uploaded).
Next came Bartek from L2beat.com, who presented his “Risk Framework”, an effort of putting definitions and standards on the variables that L2s differentiate on.
All talks will be available here, once they’re uploaded.
The conclusions from these first two context-setting talks:
- L2s teams have their work cut out for them
- These are non-trivial problems, but we have known paths forward. All that’s left is execution.
This is all setting the stage for the coming L2 wars. As L2s all progress on this front, there will be jostling and positioning to prove who is furthest on this checklist.
During Bartek’s talk, he was discussing the various risks and gaps left in the current state of L2s. Each ‘unfinished’ aspect of L2s leaves a gap in user safety, and these ‘gaps’ are not 1:1 equivalent across rollups; each different rollup design has its own unique risks, even if they largely fit under the same categories.
For example, Bartek brought up Arbitrum’s 12-hour sequencer downtime last September, which conveniently occurred during Solana’s 17-hour downtime, and allowed us to compare the differences between the properties of L1 and L2 downtimes.
Throughout Crypto Twitter and the Ethereum community, it was echoed that “With L2s, if the sequencer goes down, you can still make L2 transactions with the L1!”.
L2s are like escalators: when they break, they just turn into stairs. You can still use them.
While Bartek was discussing this, he said “People thought you could still make a transaction on Arbitrum… but that was wrong: you actually couldn’t, citing the not-yet-finished state of the L2 ecosystem.
I was sitting in front of members of the Arbitrum team, and could hear murmers of displeasure and disagreement from this statement from Bartek. Eventually, someone loudly said “That’s not true!” from the audience. Discussing with other L2 teams, they said “actually it was true”, which is going straight to the point of what Bartek was talking about:
We don’t have risk frameworks or standards for discussing the variances in L2 rollup design, which is why we have disagreements about what’s true versus what’s not.
Bartek is clearly passionate about this, and looking at the risk page of L2beat.com, you can see all the various risk vectors of L2s, and the various levels of assurances that L2s give (or don’t!) about failure scenarios.
The tl;dr: everyone knows #L2-22 is on the horizon, and L2 teams are going to be jostling for mindshare and market share… because everyone agrees:
It’s time for L2s to shine.
4️⃣ EVM equivalence is *required*
EVM equivalence wasn’t in the center of attention at DevConnect… but it should have been.
The MEV teams focused on MEV. The Ethereum developers focused on Ethereum. The L2 teams focused on L2s.
Meanwhile, I focused on this concept called ‘EVM equivalence’, and now it’s living rent-free in my head.
Ethereum’s network effects stopped growing when gas sustained 300+ gwei during DeFi summer. This is the moment when Ethereum became a whale chain, and new users were pushed to other chains.
Some went to L2s like Polygon, and later Arbitrum when it came online in September. Many went to EVM-compatible L1s like Avalanche or Fantom. Others went to new chains with completely new non-EVM standards like Solana or Terra.
Other than those that stayed on the Ethereum L1, everyone went to chains that were not EVM equivalent.
Sure, Polygon and Arbitrum are EVM-compatible Ethereum L2s, adding to Ethereum's network effects, and sharing in Ethereum’s security.
But EVM compatibility is still a divergence from the network effects of the EVM, fracturing the network effects that put Ethereum on the global map.
If we want to pick up where we left off in DeFi summer 2020, we need EVM equivalency.
Only with an ecosystem of EVM equivalent ORUs can we continue growing the network effects of the EVM. Mere EVM compatibility isn’t going to cut it.
Thankfully, Optimism has had this since last October, and Arbitrum has begun to follow suit with Nitro.
My opinion is: EVM compatibility is dead; either go full EVM equivalent like Optimism or Arbitrum or just build a completely fresh execution environment that doesn’t have the technical baggage of the EVM.
This is a new concept for me but I’m going down the rabbit hole.
More on this on Wednesday in the newsletter.
5️⃣ There's not enough talent
Everyone is hiring, and the pool of talent that everyone is hiring from is not growing fast enough.
Basically, every team and company present at DevConnect would like to 2x the size of their developer team, but there simply isn’t enough talent to go around.
If you have the skills required to work for L2 teams or be a protocol dev, or generally just work in open source software, then you likely already work for one of these companies and are being paid very well.
And it’s not like there’s this other pool of Web2 talent that these teams can pull from.
The talent required to actually be helpful on the frontier of research and development is extremely specific, and this talent has likely already been in the space for a long time.
We need talented engineers from Web2 to drop what they’re doing, lock themselves in their basements for months, go down the crypto-network rabbit hole, and then reemerge as viable talent for Web3 companies.
I asked Bartek to illustrate what talent he needs for L2Beat.com; here’s what he said:
What are people waiting for??
And then, we need this new talent to not be corrupted by the mountains of capital that are accruing to those who participate in unethical and network-destabilizing MEV extraction.
The Final Takeaway
This week in Amsterdam is a testament to Ethereum’s slime-mold nature. Ethereum development is relentless developing on all fronts, all at once.
When there’s this much brainpower going into something, it’s unstoppable.
Unlike reports I’ve heard about other conferences, (that they’re a pile of money searching for a soul"), the environment at DevConnect was passionate builders tackling the hardest problems in crypto; problems that other ecosystems aren’t even bothering to consider, yet are foundational to the longevity of this industry.
DevConnect was saturated with the latter.
Not a moonboi in sight.
Let’s get busy.
- David