It honestly just made me happy, and made me want to have that conversation with everyone on the planet. But that obviously doesn’t scale. So the next best thing is to write a post about what we talked about.

I’ve known for a long time that if Ethereum succeeds, it will make a real difference in the world. But it’s taken me a while to put into words exactly why.

I think it’s because the problems Ethereum tries to solve are hard to see. They’re baked into systems we’ve grown used to, so we don’t always notice how broken things are.

In a recent CNBC article about Ethereum’s 10-year birthday, Vitalik described the mission as making Ethereum “a really valuable part of global infrastructure that helps make the internet and the economy a more free and open place.”

That might sound like a nice tagline, but isn’t the internet already free and open?

At first glance, maybe. But if you look closer at how we got here, you’ll see something different. The internet started as an open, messy, beautiful space. Then slowly, it became siloed. The rules stopped being written to give you freedom and started being written to keep you locked in and extract from you.

The early internet showed what’s possible when no one controls the system. It was a rare window where open protocols won, governments funded the infrastructure, and corporate gatekeepers hadn’t yet taken over.

What do I mean when I say “open protocols won”?

I like Timber Schroff’s definition from Summer of Protocols: protocols “enable repeatable behaviors at scale without central authority.”

That might sound abstract, but it’s what made the early internet magical.

When you send an email or visit a website, you’re using protocols like HTTP or SMTP, systems anyone can build on without asking permission. No company owns them. No platform decides what message you can send or what page you can view. That’s the power of open protocols.

Gmail is a good example. It’s built on SMTP, an open protocol, which means you can leave at any time, take your email and messages with you, and everything will still work. Because Gmail has to compete with other email clients, it can’t lock you in, and as a result, it’s free, works well, and doesn’t show ads in most places. The open protocol keeps them honest.

For a while, it worked. Anyone could launch a website, share a video, or publish a blog. It was chaotic, creative, and deeply human.

Yes, you can still do those things today. But back then, it wasn’t filtered through an algorithm. You didn’t need a platform’s blessing, or worry that your reach would be throttled, your content demonetized, or your account banned without recourse. What you posted showed up in RSS feeds, blog sites, forums. Discovery was messy, but it was real.

In 2006, Time named "You" the Person of the Year, because for the first time, regular people were in control of the content, the platforms, and the culture.

That moment did not last, but it gave us a glimpse of what an open internet could be.

Ethereum didn’t get the same head start the internet did. The early internet was funded by governments, supported by universities, and eventually adopted by industry. Ethereum had none of that. It grew under pressure. It had to fight to survive, not just in the market but in the face of legal uncertainty and regulators who didn’t even understand what it was.

Despite being fully open source, with live calls anyone can join and a protocol anyone in the world can verify from home, Ethereum was met with skepticism and resistance.

Imagine if everything Apple built was open source and every strategic decision was made in public. That level of transparency is almost unthinkable. And yet that’s how Ethereum operates.

It starts with fixing finance.

What the internet did to information, Ethereum will do for finance.

Before the internet, your access to knowledge depended almost entirely on where you were born. If you didn’t live near a good library, weren’t in a strong school district, or didn’t have a shot at a top university, you were at a massive disadvantage.

The internet changed that. Borders started to matter less. Anyone with a connection could learn, explore, and teach themselves almost anything.

Finance is still waiting for that kind of update.

Traditional finance is closed, outdated, and tilted against the average user. Markets are only open during banker hours. Core infrastructure runs on code written decades ago. The rules are opaque, which allows insiders to exploit the system while regular people are left in the dark.

Entire regions are excluded.

https://www.unescwa.org/news/escwa-warns-nearly-65-adults-arab-region-still-unbanked-amid-sdg-push

Entire groups are systematically overcharged, steered into worse products, or excluded altogether.

People’s savings are trapped in systems they don’t understand or trust, while their wealth is quietly inflated away.

The result is a world where opportunity is unevenly distributed and trust in institutions keeps eroding. Ethereum gives us the chance to rebuild financial infrastructure from scratch and make it accessible, transparent, and fair.

Borders are imaginary lines, yet they determine so much of your life.

The internet made knowledge free and open.

Ethereum is doing the same for value.

Everyone should be free to learn, earn, and build no matter where they’re born.

That alone would be massive. Making the financial system neutral, accessible, and global is not some small improvement. It would shift power, unlock opportunity, and improve the lives of millions.

But that is only the beginning.

We are going through a digital version of the industrial revolution.

The original industrial revolution brought undeniable progress, but also caused harm we didn’t fully understand at the time, child labor, dangerous working conditions, environmental damage. It took decades to respond and adapt. Eventually, we introduced cleaner energy, labor protections, and safer factories.

The internet brought global access to information, but it also created systems that exploit attention. Social apps are designed to keep us on them as long as possible. They don’t aim to make us angry, they just show us whatever keeps us engaged the longest. It turns out that outrage, anxiety, and conflict are especially effective at doing that.

The result is rising depression, shrinking attention spans, and collapsing intimacy. These aren’t random outcomes. They’re the byproduct of systems optimized for engagement, not well-being.

We finally have the foundations for an open social ecosystem. Protocols like Farcaster are creating a world where identity is portable, where anyone can build a client, and where platforms compete to serve users instead of extract from them.

The network effects of Twitter are massive. Replacing it will not happen overnight. But open systems have one key advantage: they force apps to compete on user experience, not control.

There’s no central company that can shut down a better product just because it becomes too popular. Take Reddit, for example. Apollo was a third-party app that many people preferred over the official one. It had a cleaner design, better features, and a more thoughtful user experience. But Reddit made it impossible to operate by raising API prices, effectively killing it.

If Reddit were a protocol instead of a platform, Apollo could have kept growing. That’s what open systems make possible. When users are free to choose, and developers are free to build, the best experiences rise to the top.

And it is not just Twitter or Reddit.

It is Facebook and Instagram deciding who sees what and shaping our social lives through engagement algorithms.
It is YouTube controlling discovery and demonetizing creators without warning.
It is TikTok optimizing for addiction instead of well-being.
It is LinkedIn gatekeeping professional identity and reach.
It is Spotify owning the relationship between artists and their fans.
It is Amazon and Apple taking a cut of every purchase and locking developers into closed ecosystems.
It is Tinder putting your dating life behind a paywall and optimizing for swipes, not connection.
It is every platform that locks you in, extracts from you, and makes you play by their rules.

It’s time to replace those systems with something more open, fair, and humane.

That list isn't meant to be complete. It's meant to show what reimagining the internet to be more free and open can unlock.

This change might take a decade or longer, but it’s a fight worth fighting for.

And it doesn’t mean everything needs to be built entirely on Ethereum. Most apps in the future will likely use Ethereum for a small part, such as transferring value (money, financial assets, digital items, etc.) or verifying identity, while relying on other tools to complete the stack.

Zero knowledge for privacy. Decentralized storage for permanence. Peer-to-peer protocols for messaging. Ethereum is just one part of a growing toolkit for building open, user-owned systems.

So let’s go back to the conversation that inspired this post.

The story I just told is beautiful, but none of this will happen on its own.

We need developers. We need storytellers.
We need educators, designers, organizers, researchers, philosophers.
We need people who care.

One of the best things about this space is that you don’t need permission. You can just start doing things.

You're not too late. Ethereum needs people like you, believers.

If you ever feel lost or unsure how you fit in, message me. I’d love to talk.

Ethereum is at a turning point. Scaling is happening, and we have real challenges to solve. But instead of accelerating progress, our biggest communication platform is holding us back. We are designing mechanisms for Ethereum from first principles, so why are we still relying on a social media model built to amplify outrage? The algorithm does not show us reality. It manufactures conflict, rewards division, and wastes our energy on distractions. It doesn't have to be this way. We know how to build better systems. The time to build is now.

Before we talk about building something better, let’s take a step back and look at the problem. Social media platforms are engineered to maximize engagement, and an unfortunate quirk about human nature is that outrage drives engagement. I polled my friends in group chats, and the vote was unanimous. All 17 agreed that social media is bad for mental health. No debate, just “common knowledge”. 

This isn’t a coincidence. Platforms are designed this way. Social media companies do not care about your well-being. They care about engagement, because engagement prints money. Even the people who built these platforms know how harmful they are. Mark Zuckerberg and Peter Thiel both limit their kids’ screen time because they understand exactly how addictive these systems are.

It was not always like this. Early social media was simple. You followed people, and posts appeared in reverse chronological order. No engagement farming. No algorithm. But once these platforms scaled and needed a business model, everything changed. The more time users spent on the platform, the more money they made. Keeping you engaged was not just a feature, it was the entire product. This is where the algorithmic feed came in. 

When Elon Musk open-sourced Twitter’s algorithm, it confirmed what many had suspected. The feed is designed to predict what will keep you on the platform the longest. And the thing that holds people’s attention more than anything else is outrage. Once you understand this, everything makes sense. Outrage gets engagement. Engagement gets reach. Reach gets influence. The fastest way to grow a following is to be as inflammatory as possible.

On Crypto Twitter, the loudest voices dominate, not because they have the best ideas, but because outrage gets engagement. The easiest way to be heard is to attack someone, not contribute meaningful ideas. Instead of focusing on real problems, the conversation is shaped by whatever generates the most conflict.

This actively harms Ethereum. Instead of accelerating progress, it slows us down. Time and energy that should go toward solving critical problems is wasted on performative debates and engagement-driven infighting. Instead of meaningful discussions, we get engagement wars. Instead of collaboration, we get tribalism.

Look at what almost everyone in Ethereum agrees on. We need to fix L2 interoperability UX. We need to scale blobs for L2s. These are not controversial points, they are shared priorities across app developers, rollup teams, core devs, and users. But instead of conversations focused on how to solve these problems, social media amplifies dunking on the latest controversy of the day.

I made a poll on Farcaster asking if people think the Ethereum community is divided, and 60% said yes. That number is already high, but if I ran the same poll on Twitter, I am sure it would be much worse. But when you strip away the engagement farming and look at actual discussions, most people in Ethereum agree on key issues. The fights that dominate Twitter are not representative of reality. They are just what the algorithm chooses to show us.

And it is not just social status. Outrage farming is financially rewarded. The easiest way to raise your profile is to grow your Twitter following by being an asshole. That leads to podcast appearances, better deal flow, and a payday at a new job. Kaito has taken it even further, explicitly rewarding engagement with yaps that will almost certainly become tokens. The entire system has evolved to reward the worst possible behavior. The downstream effects are everywhere. 

This is not just Ethereum, it is happening across every major online community. When a network reaches a certain scale and has different perspectives clashing, the algorithm does not just show you what is happening. 

But what if it didn’t have to be this way? What if we built platforms that prioritized consensus instead of conflict?

This is not just a hypothetical. At Devcon, Audrey Tang gave a keynote and in it she talked about Polis, an open-source platform that Taiwan has successfully used to enable constructive public discussions. Unlike traditional social media, Polis does not have a reply button. Instead of users competing to deliver the most viral dunk or escalate arguments, Polis allows people to vote agree or disagree on statements. There is no incentive to start a fight because there is no mechanism to reward one. Replies do not scale, they create endless threads of back-and-forth arguing that go nowhere.

A real-world example of Polis in action came during a heated debate about whether speakers from a Chinese company should be allowed to present at a JavaScript conference in Taiwan. The discussion escalated into a 200-comment flame war, with two major groups emerging. One side argued that inviting the speakers did not imply endorsement of their country’s politics, while the other saw their inclusion as problematic. To shift the conversation away from endless back-and-forth arguing, someone introduced Polis. Instead of continuing the debate through replies, participants could only vote agree, disagree, or pass on statements. 

Polis quickly revealed two distinct groups forming. As shown in the images, the group on the left largely supported inviting the speakers, believing that technology sharing should not be conflated with political endorsement. The group on the right, however, disagreed, seeing the invitation as potentially legitimizing the company’s ties to the Chinese government. The first image captures one of the more divisive statements: “Invite speakers for technology sharing does not mean recognition of enterprise culture or products,” which received strong agreement from Group 2 while the opposing group largely rejected it.

Amid the division, one comment gained broad support from both sides: “I think JSDC organizers have the freedom to organize the agenda.” 

This consensus did not erase the disagreement, but it provided a shared foundation of mutual respect. Instead of fueling more conflict, Polis surfaced a point of alignment that allowed for a more constructive discussion. For those interested in the full story of how Taiwan used Polis for public deliberation, Colin Megill wrote a detailed blog post about it here.

You have probably already seen a version of Polis in action already. Twitter’s Community Notes is powered by a system inspired by Polis. Instead of relying on simple upvotes or majority rule, it uses machine learning to find patterns in voting data and highlight statements supported by people who normally hold opposing viewpoints. This ensures that the notes shown are not just popular but actually bridge different perspectives. I am not going to go deep into the math here, but Vitalik wrote about it in his blog post What do I think about Community Notes.

We already see glimpses of how different incentives can shape discourse. Take ETH Holders, a Twitter account where anyone with at least 2 ETH can post anonymously using ZK proofs. Side note, I think it is an extremely cool real-world application of ZK. What is most striking about the account is the tone of the posts. The majority of them are positive about Ethereum. In a world where the Twitter algorithm only rewards negativity, people have to be anonymous just to express positive sentiment about the ecosystem. That is the kind of distortion we are dealing with.

The question is not whether better models exist. They do. Polis is open-source, live in production, and already proving that social media does not have to be built on conflict.

We know the problem. We know the solution. The only thing left is to build. 

In an ideal world, we could just build a better Twitter client. That would let us keep the network effects without being trapped by an algorithm designed to manipulate us. But Elon made that impossible by locking down Twitter’s APIs. So where do we build instead? There is already a protocol with an open API, Ethereum-native users, and the freedom to experiment. It starts with an F… yup, you guessed it, friend.tech. 

The solution is not as simple as using Farcaster. Warpcast does not solve the algorithm problem. Its ranking system is closed source, and it is likely no better than Twitter’s at surfacing meaningful discussions. But the beauty of decentralized social media is that we are not locked into one client. We can build our own.

This new client would function as an Ethereum-focused Farcaster client, pulling in posts from the Ethereum channel across all clients, including Warpcast. However, instead of displaying posts in a traditional feed with replies and retweets, every discussion would be structured into voteable statements. Users could post directly to the Ethereum channel within this client, but rather than engaging in back-and-forth debates, they would only be able to vote agree, disagree, or pass on each statement. Polis would then analyze the voting patterns to surface consensus, filtering out noise and highlighting areas of alignment and disagreement across different groups.

To ensure meaningful discussions, the client would automatically pull in key debates from Ethereum Magicians and ETH Research, transforming long technical threads into clear, structured statements that the community could vote on. Governance proposals, EIPs, and protocol updates would also be included, allowing the broader Ethereum ecosystem to signal their views without being drowned out by engagement-driven controversy. Instead of amplifying the loudest voices, this client would provide a way to see what Ethereum researchers, developers, and users actually think about important topics.

This would be the foundation. No viral dunking. No incentivized fighting. Just a way to see what the Ethereum community really thinks.

I don’t think Crypto Twitter is going to disappear anytime soon, but a platform like this could serve as a necessary check on it. Right now, when Twitter is blowing up about something, there is no way to tell if it is a real issue or just another outrage cycle fueled by the algorithm. Imagine being able to open a different platform and immediately see what people across the ecosystem consider an actual priority, from app developers to ETH whales to core developers to investors. This would provide a real sense of what matters instead of letting Twitter dictate the narrative.

A common pushback when anything Farcaster-related is brought up is that Farcaster is bad for Ethereum. Some argue that it is an echo chamber with a small audience or that it fragments the Ethereum community. But the real problem is not Farcaster, it is Twitter. As I have laid out in this post, Twitter’s algorithm is designed to manufacture division, reward performative engagement, and slow Ethereum’s progress. Leaving Twitter is not about moving to an echo chamber. It is about leaving an engagement-maximizing system that incentivizes dunking over surfacing real priorities.

If a strong, widely-held disagreement exists on a topic, Polis will surface it clearly. If people from different backgrounds all reject an idea, that becomes obvious without the noise of engagement farming. This is a better way to capture the real sentiment of the Ethereum community. It does not eliminate criticism. It makes it measurable.

To illustrate how Polis makes sentiment measurable, consider the ongoing debate about raising the Ethereum gas limit. Key positions could be distilled into voteable statements such as: 

• Ethereum should gradually raise the gas limit as hardware improves.

• Increasing the gas limit too soon risks harming decentralization by making it harder to run a full node. 

• Raising the gas limit should only happen after extensive benchmarking on network health and validator costs.

Instead of scrolling through endless Twitter arguments, the Ethereum community would have a clear, structured way to signal their views. If 80% of validators, 65% of researchers, and 75% of ETH holders aligned on one statement, that would provide a measurable signal of consensus. Conversely, if a statement was overwhelmingly rejected across all groups, it would reveal a lack of broad support, without requiring anyone to sift through toxic engagement-driven debates.

One of the biggest distortions in Crypto Twitter is the illusion that the loudest voices represent the majority opinion. In reality, these voices are just the ones most incentivized to engage. The minority that thrives on outrage and performative dunking dominates the discourse, while the silent majority, who are more thoughtful, pragmatic, or simply uninterested in engagement farming, stays quiet. This creates a feedback loop where the loudest, most aggressive voices claim to speak for the entire community, even when they do not.

We can see a parallel in how online discussions typically unfold. In a Polis experiment analyzing online alcohol sales in Taiwan, 447 people participated by voting on statements, yet only 32 of them actually commented. That means the people who spoke up represented less than ten percent of the participants. The rest just voted. If participation had only been measured by who was commenting, it would have given a completely skewed picture of what the broader public actually thought. Instead, because Polis allowed silent participants to register their views, the government could see a more accurate reflection of public opinion.

This is why Ethereum needs a different model for discourse. A system where engagement is not dictated by how well someone can farm outrage, but instead by how well their ideas resonate with the broader community. A platform that rewards clarity over conflict. A place where people who do not want to waste their time arguing can still contribute by voting and shaping the conversation in a meaningful way.

To make this even more transparent, we could include a public dashboard showing real-time participation statistics. This would allow anyone to see how many people are voting versus commenting, helping filter out distortions and ensuring that the broader community’s views are accurately represented.

Ethereum has always been where ideas become reality. We saw it with prediction markets, quadratic funding, and decentralized social media itself. Now we have the chance to build something even bigger. A platform that aligns Ethereum’s builders, researchers, and users on what actually matters. A system that accelerates progress instead of fueling division. This is not a thought experiment. It is something we can build right now. If we get this right, Ethereum will not only be the most decentralized and secure network but also the most productive ecosystem in crypto.

If you are a software developer and want to help bring this to life, reach out. If you are not a developer but want to contribute in other ways, let’s make this happen together.

TEEs provide secure, hardware-based computing by isolating code and data while allowing external verification of integrity. They evolved from earlier trust models that relied on operating systems and virtual machines for isolation. TEEs come in different forms: iPhone’s Secure Enclave handles cryptographic tasks, Intel SGX enables secure enclaves for applications handling sensitive data, and Intel TDX extends this model to protect entire virtual machines. While they provide stronger security guarantees than trusting a centralized operator, especially in cloud environments, they are closed-source and require trust in the manufacturer. This typically creates a 1-of-1 trust model, where a hardware compromise can break security, though the degree of trust required depends on the implementation. TEEs are also vulnerable to side-channel attacks, physical tampering, and supply chain risks, making careful evaluation essential for each use case.

TEEs are not a perfect solution, but in the right cases, their benefits outweigh the risks, especially when failures default to the existing system. The push for secure hardware extends beyond crypto, with OpenAI advocating for improved TEEs and Apple developing a hardware-based private cloud. Just as Ethereum works to reduce trust assumptions, Flashbots is doing the same for TEEs. They have published research on why this approach is worth exploring and how to build trustless supply chains. If you are a hardware security expert, reach out to Flashbots to contribute.

MEV exists as a consequence of network design, where those who provide the service of adding new blocks, initially miners, were in a position to influence transaction order for profit. Left unchecked, this would lead to centralization, with validators that are dominant at extracting MEV gaining outsized influence. To prevent this, Flashbots set out to democratize MEV extraction.A key driver of MEV is that validators operating in low-latency environments can observe pending transactions and reorder them and/or add new transactions for profit. One way to limit MEV extraction is by making transaction details private. This requires a privacy tool, but zk-SNARKs and other cryptographic techniques, while promising, are too slow, inflexible for real-time block building, or not production-ready. With software solutions falling short, Flashbots turned to TEEs.

Flashbots first used Intel’s SGX to build blocks in March 2023 and later expanded to both build and search in Intel’s TDX. TEEs bring privacy benefits by allowing orderflow to be selectively private. For example, a transaction can reveal that a user wants to swap USDC for ETH without disclosing their identity or trade size. This prevents sandwiching while still allowing backrunning arbitrage. TEEs enable verifiable block construction on private transactions, ensuring efficient block building without compromising user privacy.

PBS prevented validator centralization, but today, just two builders produce 92% of Ethereum blocks, reducing censorship resistance and liveness. To fix this, Flashbots launched BuilderNet in November 2024, with Beaverbuild, Flashbots, and Nethermind as the first participants. BuilderNet allows multiple operators to share orderflow and build blocks collectively, shifting MEV away from exclusive deals and making block building more open and decentralized.

Beaverbuild’s participation is particularly notable since they are currently the largest builder and have spent years sourcing exclusive orderflow deals. Their decision to join BuilderNet signals a shift away from private MEV agreements toward a more transparent and competitive market. While it may seem surprising that a dominant builder would give up its edge, the economics of exclusive orderflow are less lucrative than they appear. Providers often negotiate high refund percentages, keeping 90-95% of the MEV value, leaving builders with thin margins. Additionally, Beaverbuild’s team originally started as searchers, and running a builder was primarily a way to maximize their own orderflow. With BuilderNet’s transparent refund system, they no longer need to vertically integrate to extract value, allowing them to return to their strengths as searchers. Beyond financial incentives, they also see this as the right move for Ethereum’s long-term health, preferring to contribute to a positive-sum ecosystem rather than competing over exclusive orderflow deals.

However, as of today, Beaverbuild is still operating its centralized setup in parallel with BuilderNet, with all of its orderflow currently going to the former. This isn’t a departure from the plan but a staged transition.

I asked Shea Ketsdever from Flashbots about this, and she said they are working closely with Beaverbuild to benchmark performance and run tests to ensure a smooth transition, with expectations for orderflow to shift over to BuilderNet in Q1 2025. Something to keep an eye on.

TEEs make this possible by ensuring MEV is redistributed transparently and allowing untrusted builders to collaborate without any one party gaining an advantage. Each operator runs an open-source builder inside a TEE, encrypting and fairly processing all orderflow. Unlike today’s fragmented system, BuilderNet ensures no builder has privileged access, making it trustless and verifiable.

This shifts MEV capture from private agreements to an open system where wallets, apps, and searchers receive fair refunds. Even searchers who typically keep orderflow private are incentivized to use BuilderNet for transparent payouts. Currently, a single operator submits the final block, similar to MEV-Boost relays, but future upgrades will allow multiple operators to collaborate on block construction, making MEV extraction more decentralized and equitable.

For more on BuilderNet, Robert has discussed it on the Uncommon Core and Infinite Jungle podcasts.

Flashbots is also using TEEs in Rollup-Boost, a sidecar system for L2 sequencers that enables faster confirmations, verifiable ordering, and more programmability. TEEs prevent sequencers from manipulating transactions while allowing private mempools and trustless execution. Since Rollup-Boost is a sidecar, rollups can retain their existing frameworks like the OP Stack or ZK Stack while adding new features. This solves a key issue in the rollup-centric roadmap, where most L2s have simply forked Geth and followed L1 upgrades instead of driving real innovation. Rollup-Boost enables experimentation without requiring rollups to maintain a separate client.

Uniswap’s upcoming L2, Unichain, will be the first to use Rollup-Boost, launching with Flashblocks and Verifiable Priority Ordering. Flashblocks enables 250ms confirmation times, native revert protection, and increased gas throughput, while Verifiable Priority Ordering allows applications to internalize their MEV. The sidecar processes transactions using extensions before returning finalized blocks to the sequencer for posting on Ethereum L1. Future extensions include Encrypted Mempool, TEE Validity Proofs, and TEE Coprocessing.

For more on Rollup-Boost, Robert has also discussed it on Uncommon Core and a different episode of Infinite Jungle.

TEEs are being integrated into L2 bridge proof systems to complement ZK proofs, which, while offering strong security, are complex and prone to bugs. Relying on a single prover increases the risk of catastrophic failure if an issue arises. To mitigate this, teams are exploring adding TEE-based proofs as an additional verification layer, reducing the likelihood of invalid states being finalized.

TEE and ZK proofs operate independently, ensuring redundancy. If one system encounters a bug or security flaw, the other can provide a fallback, preventing invalid state transitions from being finalized. In such cases, the security council can intervene before the issue escalates.

Scroll, in collaboration with Automata, has developed an open-source SGX-based TEE prover, already used to validate testnet blocks. Scroll’s next steps include integrating the dual-proof system, implementing dispute resolution mechanisms, and forming a TEE prover committee. As part of this process, Scroll is exploring ways to further decentralize TEE attestation, similar to Ethereum’s Distributed Validator Technology, ensuring no single hardware manufacturer becomes a central point of trust.

Taiko uses a tiered proof system. Initially, TEEs provide fast validation by running a lightweight execution client that verifies state transitions and signs results with ECDSA for onchain validation. During a cooldown period, ZK proofs can challenge TEE proofs. To ensure correctness, provers must stake a bond, which is forfeited if their proof is invalid. While a centralized fallback exists for security in the early stages, Taiko plans to phase it out and transition fully to ZK-based verification.

TEE proofs enable this multi-proof system by providing an additional security layer while zkEVMs are still maturing. They offer a fast, cost-effective way to validate state transitions without fully relying on ZK proofs, ensuring that even if a ZK prover fails, the system maintains security and liveness.

TEEs are rapidly becoming a key part of Ethereum’s infrastructure, addressing security, privacy, and decentralization challenges across MEV, rollups, and bridges. As these systems mature, they could redefine Ethereum’s trust model while bridging the gap until cryptographic solutions fully scale.

Special thanks to Quintus for feedback and review

- Eric Hughes, A Cypherpunk’s Manifesto

A couple of weeks ago, I started looking into cypherpunk stories using Ethereum. When I first heard the word “cypherpunk,” I thought of it as an adjective describing actions that use privacy to bypass government surveillance. For instance, one story that came to mind was from a couple of years ago when Vitalik said he used Tornado Cash (before it was added to the OFAC list) to donate to Ukraine after the Russian invasion in 2022 but didn’t want the Russian government to see the details of his donation.

I went to YouTube looking for more cypherpunk stories, and the algorithm gods blessed me with a talk "I read every single 1990s Cypherpunk email. Here's what you should know. | Devcon SEA" from Devcon by Porter. I’d been meaning to watch it but had forgotten about it until now. After watching, I realized I really didn’t know much about the cypherpunks. I had only a vague sense that they were deeply respected in the Ethereum community and had pushed for privacy through an email list, that was about it.

Porter’s talk sparked my curiosity, and since then, I’ve been learning about the cypherpunks. I watched the documentary Cypherpunks Write Code, listened to the podcast The Cypherpunks - How Hackers Prevented the Ministry of Truth, and read the two most famous emails: The Crypto Anarchist Manifesto and A Cypherpunk’s Manifesto. Neither is long, and I highly recommend reading both.

Let me just say, holy shit. The cypherpunks left an incredible mark on society; they were fearless, visionary, and undeniably badass. The cypherpunks were a group of nerds driven by one simple motivation: they wanted the world to be freer. They weren’t building tools to get rich or for recognition—they were building because they believed freedom and privacy were fundamental rights. And they were willing to go to jail to defend those rights.

What made them truly badass was their unwavering confidence in what they were creating. They knew that what they were building was legal, ethical, and objectively good for the world. They trusted that if it ever came to a court battle, the law would side with them—and history proved them right. Cypherpunk Phil Zimmerman created encryption software, PGP, and it spread internationally, and the U.S. government accused him of illegally exporting “weapons,” this is privacy code, do you hear how crazy that sounds. Confident in their cause, cypherpunks rallied behind him, printing PGP’s code as books to prove it was protected speech under the First Amendment. The government eventually dropped the case, and courts later ruled that code is indeed free speech.

But beyond my personal admiration, it’s important to understand who they were and their impact on the world. Without them, there’s no Bitcoin; without Bitcoin, there’s no Ethereum. Therefore without the cypherpunks, I’d probably be writing about AI right now. But since you’re reading this, it’s clear you’re interested in Ethereum—so strap in for a bit of a history lesson.

The cypherpunk movement traces its roots back to the late 1970s, when the NSA tried to block MIT's public key cryptography research. They did everything they could to keep it out of the public’s hands, labeling it a "modern weapon" and threatening to personally go after anyone who spread it. But this didn’t stop 20-year-old cypherpunk Mark Miller from secretly copying the paper and distributing it nationwide. Aware of the risks, he told friends, "If I disappear, share this." In 1978, the U.S. government backed down, and encryption went public. The first battle for encryption had been won, but the larger war for privacy and freedom was just beginning.

Fast forward to 1991, when software developer Phil Zimmerman released PGP (Pretty Good Privacy), the first relatively user-friendly secret messaging system with strong encryption on the internet. His software spread overseas, and the U.S. government argued that Zimmerman’s actions were equivalent to exporting weapons, making it illegal without approval. They launched an investigation against him.

Zimmerman’s PGP incident was a wake-up call for the broader community of freedom advocates, inspiring a more organized response—enter the Cypherpunk mailing list. It became a hub for discussions on cryptography, privacy, digital cash, and the future of decentralized systems. At its peak, the list had only about 2,000 subscribers—an insanely small number considering the impact they had.

While their discussions on the mailing list were technical, they were always tied to a larger vision. The cypherpunks foresaw two potential futures for humanity: one with 1984-style tyrannical, top-down control and another where it enabled freedom. After witnessing repeated attempts by the U.S. government to suppress cryptography, they realized they had to act. They knew they needed to build and deploy tools that couldn’t be shut down. Without these efforts, governments could wield technology that authoritarian regimes like the Nazis or Soviets could have only dreamed of. As Eric Hughes put it, “Since we can't get privacy unless we all do, we're going to write it.”

“With the internet and personal computing we can build networks with many interconnecting nodes that would be basically unstoppable.”

- Timothy C. May

The cypherpunks embraced a technology-driven view of historical change. They believed that meaningful progress doesn’t come from lobbying or electing the right people—it comes from technological innovation and adoption. If you want the future to unfold a certain way, you have to build it yourself.

“Our code is free for all to use, worldwide. We don't much care if you don't approve of the software we write. We know that software can't be destroyed and that a widely dispersed system can't be shut down.”

- Eric Hughes, A Cypherpunk’s Manifesto

The cypherpunks were a group of hackers, cryptographers, scientists, mathematicians, philosophers, and activists united by a shared vision: creating a future that maximized human freedom.

They recognized that the internet could break down borders, removing barriers for people worldwide. Just as the fall of the Berlin Wall allowed people in East Germany to immediately gain freedoms like speech, press, travel, and the ability to keep the value they create, the internet offered similar possibilities on a global scale. The cypherpunks envisioned two major freedoms the internet could enable: the first was the freedom to have private communication, and the second, which I’ll discuss later.

Most of the emails on the cypherpunk mailing list were highly technical, focused on building cryptographic tools. Here are some of the key innovations they contributed to:

• 1993 – Mixmaster Remailers: Anonymous email systems enabling untraceable communication.

• 1995 – Tor (The Onion Router): Anonymous internet browsing, inspired by cypherpunk principles (later completed by others).

• 1995 – Cryptographic File System (CFS): An early prototype for encrypted file storage.

• 1997 – Hashcash: A proof-of-work system initially designed to combat email spam, later adapted for Bitcoin mining.

While much of what the cypherpunks built didn’t achieve mainstream adoption (with Bitcoin being the big exception) their ethos sparked a broader movement for privacy-focused technology. Tools like VPNs, used by over 1.5 billion people globally in 2023 to secure internet connections and bypass censorship, and the Signal protocol, which powers WhatsApp’s end-to-end encryption for its more than 2.7 billion monthly active users, reflect the cypherpunk vision of empowering individuals to protect their data. Even Apple’s privacy features, such as App Tracking Transparency and on-device data processing, are used by hundreds of millions of iPhone users daily. These technologies have become indispensable, enabling private communication, secure browsing, and greater control over personal information on a massive scale.

The cypherpunks knew their innovations weren’t just disrupting technology, they were challenging the power structures that depended on centralized control. This duality meant their work wasn’t confined to coding; they also fought legal and social battles to defend their vision of freedom. The cypherpunk community was divided on whether their cryptographic tools would lead to greater individual freedom, free trade, and the spread of democracy or to the complete dissolution of governments. But regardless of the outcome, they were united in their mission to create tools that empowered freedom, put them in people’s hands, and let the future unfold from there. Governments, recognizing the disruptive potential of these technologies, often resorted to fear-mongering, invoking the actions of bad actors to justify their control.

As Timothy C. May put it:

"Child pornographers, terrorists, money launderers—take your pick. These are the people who will be invoked as the bringers of death and destruction. And well, it’s true. But all technologies have had bad effects. Telephones allow extortion, death threats, bomb threats, kidnapping cases. Uncontrolled publishing of books could allow satanic books to appear."

May’s words captured the cypherpunk perspective: while bad actors could exploit any technology, the tools themselves were neutral. The same systems governments feared could also protect individual freedom and privacy. Yet, governments often weaponized these edge cases to sway public opinion against encryption and privacy tools.

Despite this opposition, the cypherpunks persevered. They risked jail time to ensure their work remained accessible. Discussions on the mailing list also went into the legality of their efforts and even debated whether they should send a letter to the White House to explain their intentions. Time and again, they stood firm against central governments, defending their vision of a freer, more private future. Notable legal and social battles include:

• 1990s - Crypherpunks Support Zimmerman: The cypherpunks rallied to defend Zimmerman by highlighting the parallels between encryption software and protected forms of speech. They printed the PGP source code, bound it into books, and distributed it to European bookstores. The government realized it would lose a court battle to suppress a university-published book and dropped the investigation in 1996.

• 1993 – Electronic Frontier Foundation (EFF): John Gilmore co-founded the EFF to advocate for digital privacy and free speech, supporting many of the early encryption battles.

• 1995 – "Government Secrecy and Technology" Lawsuit: The cypherpunks backed Bernstein v. United States, where Daniel Bernstein sued for the right to publish encryption software as free speech. This landmark case established code as a form of protected speech under the First Amendment. People even got tattoos of encryption algorithms as a tongue-in-cheek protest, asking, “Can I travel to another country now?”

• 1997 – "Crypto Wars" Advocacy: The cypherpunks played a critical role in opposing the U.S. government’s Clipper Chip initiative, which aimed to mandate encryption backdoors.

Let’s revisit the second freedom the cypherpunks were working to unlock.

“We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.”

- Eric Hughes, A Cypherpunk's Manifesto

Notice the mention of electronic money? The cypherpunks aimed to enable the freedom to send value across borders, increasing economic freedom globally. Their holy grail was to achieve this privately, constructing a borderless world where individual activities and assets were resistant to government control and confiscation.

“Tim [May], me, and many others considered electronic cash to be the holy grail because it completed the picture. A private and decentralized monetary system was, many argued, a key component in constructing a new borderless world.”

- Adam Back

Despite many failed attempts and the cypherpunk mailing list cooling down, the movement was reborn in 2008 when a pseudonymous creator unveiled none other than Bitcoin. While Bitcoin marked the culmination of the cypherpunks' dream of digital “cash,” the principles they championed didn’t stop there. Many of their ideas: scalable peer-to-peer electronic cash ;), pseudonymity, advanced cryptography, privacy, and maximizing more freedoms like access to financial services—have found new life in the Ethereum ecosystem.

“The technology for this revolution--and it surely will be both a social and economic revolution--has existed in theory for the past decade. The methods are based upon public-key encryption, zero-knowledge interactive proof systems, and various software protocols for interaction, authentication, and verification.”

- Timothy C. May, The Crypto Anarchist Manifesto

It’s incredible to think that they were discussing zero-knowledge proofs back in the 1990s. I think they’d be proud to see them not only brought to life but actively shaping the Ethereum ecosystem today.

Understanding who the cypherpunks were has deepened my appreciation for their impact. Their work laid the foundation for so much of what we see in Ethereum today, making me wonder—what would they be building if they were here now? That’s a question for another time, but I’d love to hear your thoughts on how their ethos lives on in Ethereum today. For now, I’m simply grateful that this group of nerds fought for what they believed in. I hope to carry their flame forward.

“Our dream was to enable the future of human freedom, and we had this bizarre confidence about how the future would unfold and, to use Alan Kay’s famous phrase, to have a huge hand in inventing it.”

- Mark Miller

The purpose of this post is to provide an update on the progress in addressing how to scale the network’s data availability processing capacity while enabling solo staking validators to continue to self-build and distribute blocks as the network scales. 

This post will cover the current state with Proto-Danksharding, introduce PeerDAS, discuss the importance and challenges of solo stakers, review recent distributed block building proposals and their trade-offs, and outline next steps in the design process.

Proto-Danksharding introduced a new resource to the Ethereum protocol called "blobs." These blobs are raw data that every node temporarily stores for around 18 days. Each blob is 125 KB, and they are priced independently from other EVM transactions. Due to their temporary nature and separate pricing market, L2s saw a dramatic reduction in data posting costs, with average transaction fees dropping from around $0.50 to roughly $0.006 per transaction, representing an >80x reduction.

Currently, the protocol aims to include three blobs per block, with a maximum of six. However, the protocol has an ambitious goal: scaling the data layer to accommodate up to 256 blobs per block. To reach this target, the data layer will need to be sharded, meaning not every node will need to download all of the data.

The plan, called Peer Data Availability Sampling (PeerDAS), for scaling Ethereum’s data layer involves gradually increasing the number of blobs per block. In this plan, nodes subscribe to smaller portions of each blob, called subnets, allowing them to verify data availability collectively by the end of each slot.

I’m going to provide an oversimplified explanation of how this process works. For more technical details, please refer to either this post, From 4844 to Danksharding: A Path to Scaling Ethereum DA, or watch this presentation, PeerDAS in Pectra and Beyond, both by Francesco D'Amato.

When a node is selected to propose a block (including the attached blobs), it will first need to extend each blob using erasure coding, doubling the size of each blob. The advantage of this extension is that the original blob can now be reconstructed as long as 50% of the data is available. This means nodes only need to confirm that at least half of the blob is available to be sure the entire blob is available.

Next, the blobs are stacked on top of each other (just picorally), in order to form columns that represent individual subnets. Each subnet (i.e., column) is significantly smaller than a full blob, which makes them lighter for nodes to handle. 

In the current PeerDAS specification, full nodes will need to subscribe to at least 8 out of a total of 128 subnets. Staking nodes are required to participate in at least 8 subnets, or if higher, 1 per validator. Nodes with at least 128 validators (>= 4096 ETH) are considered "supernodes" and must download all subnets, meaning they are not sampling but instead fully downloading the data.

PeerDAS offers significant scalability improvements over proto-danksharding, with an 8x increase in consensus layer bandwidth. The expected blob count under PeerDAS is 24-48 blobs per block, which amounts to approximately 6 MB of data. Nodes subscribing to subnets only handle 1/16 of the total data, which includes the extended part, or about 1/8 of the original data. This progress puts us roughly 5x away from the original scalability goal - exciting progress!

After a proposer extends the blobs, will also create cryptographic proofs (KZG) that prove each blob was extended correctly, then it distributes the subnets and proofs across the network, initiating the data propagation process. If the proposer is using MEV-Boost, the builder will handle this process (extension, proof generation, and initial distribution) on their behalf.

After the distribution phase, PeerDAS enters two subsequent phases: the sampling phase and the reconstruction phase. During the sampling phase, nodes either receive data or don't, and they record their response ("yes" or "no") as part of the protocol (this is a massive oversimplification). The final reconstruction phase is used when nodes disagree on whether the data was available. In this phase, nodes attempt to reconstruct the data to reach consensus on its availability.

The specifics of these two phases are beyond the scope of this post, as our focus here is primarily on the distribution stage of the data because that is where low resourced self buildings face the most challenges.

It is crucial that low resource staking nodes that choose to not use MEV-Boost, around 10% of the network, are still able to fulfill their duties during the distribution phase (extend the blobs, generate the proofs, distribute the subnets). This is essential for maintaining the censorship resistance of the network. Ethereum's unique ability to support solo staking and allow solo stakers to act as self-builders, contributes significantly to the decentralized nature of the network. This level of censorship resistance is unimaginable for other networks that lack solo staking, and it's something we cannot afford to compromise on.

However, there are multiple challenges that low resource self-builders face in participating effectively in the PeerDAS process. First, the proof generation process demands more computational power than many self-builders currently have available. Second, the task of distributing all the column subnets in a timely manner is heavily constrained by upload bandwidth.

The solution is distributed block building, which focuses on easing the workload for self-builders by spreading intensive tasks across multiple participants. This collaborative approach enables self-builders to continue leading the distribution phase without significantly compromising decentralization, thereby preserving Ethereum's resilience against censorship.

Francesco D’Amato’s Idea of how it might work

Francesco D'Amato (in this presentation) suggested a potential method for enabling distributed block building, which involves leveraging the capabilities of higher-resourced nodes in the network.

The idea starts with the proposer sending the beacon block and ensuring it propagates through the network. While the proposer can optionally start propagating the blobs, without extending them and therefore also generating proofs.

Eventually, the beacon block will reach a “super node(s)". Since these nodes are highly resourced, the protocol can leverage them. When the super node receives the beacon block and no blobs attached or only subnets from the original data set (none from the extended data), it can step in to handle the more resource-intensive tasks: extending the blobs, generating the proofs, and then acting as new propagation sources, ensuring that all subnets are received across the network.

Francesco noted that while it should be possible to build and distribute blocks locally, it is important to recognize that economically, it's not a significant issue if a proposer chooses not to include the maximum number of blobs that a node running MEV-Boost could handle. Given that each validator only proposes approximately 2.5 blocks per year and earns around $5 per blob, the marginal yield from including all available blobs is relatively small compared to the rewards from proposing the beacon block itself. Validators who already choose not to use MEV-Boost are leaving some yield on the table, and including fewer blobs could simply be an extension of this trade-off.

Distributed Block Building Call #0

The first, and only, Distributed Block Building call was held on September 18th. In this call, Dankrad proposed a new solution to address the self-building and distribution challenges for solo stakers, and invited feedback from other Ethereum core developers and researchers. His approach differed from Francesco's earlier proposal by suggesting the creation of a new gossip subtopic where any node could participate. In it nodes could take blobs from the mempool, extend them and create the proof, and then gossip the extended data along with the proofs. This would lead to a new extension and proof mempool for all nodes. Allowing self builders to take advantage of it and simply use this mempool when it’s their turn to propose saving them the computational task of extending and creating the proofs for each blob.

Compared to Francesco's approach, Dankrad's proposal enables all nodes, not just supernodes, to participate in the creation and distribution of extensions and proofs for self builders. It also reduces duplicate work, as nodes can see the existing extension and proof in the gossip network and avoid repeating the same computation. This approach would allow builders with sufficient bandwidth, but lacking the hardware for computation, to fully participate in the process. However, it also introduces some challenges, such as handling proofs separately by the CL rather than the EL. This dependency makes the two layers more intertwined, as the CL must rely on updates from the EL to confirm proof verification, which could result in delays and inefficiencies. Additionally, every node on the network would hear about every extension and proof, even if they are only subscribed to a subset of them, potentially adding unnecessary overhead.

Several people, including Potuz and Ansgar, suggested an alternative approach to achieve the same goal. This approach involves attaching the extension and proof to the transaction itself, either by integrating it directly into the transaction format or the preferred method of keeping the transaction format the same but including the extension and proof to the transaction in the gossip layer. In this model, a blob transaction is sent as usual, but when it reaches a node that can do the computation (which it would immediately if it’s sent via Infura or Alchemy), that node would perform the necessary computation and attach the extension and proof.

This approach keeps the transaction signing interface unchanged, but alters the gossip layer. It simplifies the inclusion of proofs but tightly couples the proof format between the EL and CL, as the cryptographic components would now be embedded within the EL.

Participants agreed to explore both options (proofs in gossip new network vs. proofs in transactions) in more detail. A temperature check indicated a slight preference for Option 2 (proofs in transactions), but no definitive decision was made. Researchers will develop more detailed proposals to assess the feasibility of each approach. Concerns about latency, resource requirements, and possible DDOS vectors were also raised, emphasizing the need for further analysis to determine the computational burden of proof verification.

Towards the end, I touched on a common critique: Sure, but they don’t feel like Ethereum. While rollups may technically be part of Ethereum, users often feel like they’re navigating entirely different chains. This fragmentation hurts the user experience. I pointed out that the Ethereum community is fully aware of this issue and actively working on solutions, including standards to abstract away these differences.

Soon, the United Chains of Ethereum will become a reality, where the wallet handles all the chain abstraction. For users, it will feel like interacting with one seamless chain, even if bridging or other background processes are happening behind the scenes. Wallets will automatically handle the necessary logic, such as identifying which L2 a transaction is interacting with, so users won’t have to worry about manually switching networks or dealing with complex steps like bridging assets between chains. Whether a transaction is happening on Arbitrum, Optimism, Base, ZKsync, or any other rollup, it will feel like a unified experience.

In this post, I’ll dive into how this vision is turning into reality, and how it’s a massive, coordinated effort across the entire Ethereum ecosystem. I’ll walk through how the Ethereum community, along with researchers, rollup teams, wallet developers, and organizations like the Ethereum Foundation, are working together to address this user experience challenge. From identifying the problem to creating standards, forming working groups, and holding open discussions, you’ll see the unique way Ethereum solves its problems: openly, collaboratively, and with a commitment to long-term decentralization.

The first step is acknowledging the problem: from a user’s perspective, it needs to feel like using one unified chain, not a patchwork of different networks. To achieve this, we need standards that abstract away the chains behind the scenes, so users don’t have to manage them. The next step is getting the right people into a room to discuss potential solutions. Rollup projects have a strong incentive to solve this because it enhances the user experience, which will drive more developers to build in the Ethereum ecosystem. However, there’s often an issue of trust, coordination requires transparency and buy-in from multiple parties.

This isn’t just about rollups. Wallet teams play a crucial role in facilitating this chain abstraction, ensuring that users don’t even need to think about the network they’re interacting with. Here’s where the Ethereum Foundation steps in to provide the coordination necessary to move things forward. The EF includes some of the most connected and brightest minds in the ecosystem (and no, I’m not referring to myself here, think people like Vitalik, Justin Drake, Dankrad Feist, etc.).

Vitalik has been vocal about solutions like ERC-3770, a standard for chain-specific addresses, since mid-June. By the end of July, it was time to take serious action. Justin Drake created a chain-specific address working group, bringing together Vitalik, wallet teams, rollup teams, and more. 

From there, the conversation took off, people kept adding others to the discussion, and the chat rarely went silent as the group worked to find a solution.

There are even multiple proposals from different researchers across the Ethereum ecosystem. For example, Ethereum researcher Sam Wilson has put forward detailed thoughts on the topic in his proposal. Meanwhile, Marco Stronati from Matter Labs and Jeff Lau from ENS have also contributed to the discussion with their proposal, highlighting the diversity of efforts to solve this complex challenge.

The Ethereum Foundation didn’t stop at facilitating discussions. As progress was made, Ethereum researcher Josh Rudolf (if you’re not following Josh yet, I highly recommend it, he also facilitates the Stateless Ethereum calls and posts excellent summaries on X. Stateless Ethereum is an exciting topic that will significantly boost both decentralization and scalability on L1, and it’s something I’m personally very excited about) suggested holding a breakout Zoom session, and on August 10th, the first one took place. You can find the recording here. Josh also took notes, which you can check out here.

It’s easy to take this process for granted, but Ethereum’s problem solving approach is unlike any other industry. Everything happens in the open, with no secrets, and anyone in the world can join the effort. Companies like Apple would never allow this, competitors might steal their ideas. But Ethereum thrives on openness and collaboration. One of my favorite examples is Danny Ryan, one of the key architects of the Merge. Before joining Ethereum, he was, at the time, just a freelance web developer who got nerd sniped by the open discussion about the Merge and ended up becoming a pivotal figure in making it happen.

After the first breakout session, things ramped up. A second call happened (recording here) with more on the way, and all the notes are available here. The specifics of the standards being worked on aren’t the focus of this post, if you’re interested, check the links above. The problem is still being solved, but significant progress is being made, and if you want to contribute, feel free to message me, and I’ll add you to the Telegram group.

Solving problems in the Ethereum ecosystem is a complex, collaborative effort that spans multiple organizations, teams, and individuals. What sets Ethereum apart is its open, transparent process, working in public to tackle big challenges like improving user experience on rollups. Very soon, Ethereum will feel like a united ecosystem, with wallets abstracting the complexity of multiple chains. When there’s a will, the community finds a way. Ethereum’s brightest minds are coordinating across various fronts to ensure this vision becomes a reality.

Creating the United Chains of Ethereum isn't the only problem currently being worked on in the open. There are numerous ongoing breakout sessions where Ethereum's most innovative minds are tackling important topics. For example, you can follow or contribute to the breakout rooms for Distributed Block Building, EOA/AA, ePBS, PeerDAS, Verkle/Stateless, Sequencing and Preconfirmations, and EOF. Check out the full playlists here.

Let’s build a system of global digital property rights together and in the open, defying societal norms of closed, proprietary work. Ethereum is keeping the cypherpunk vision alive, ensuring transparency and decentralization remain core to its ethos.

Eventually, these efforts will converge, enabling Ethereum to implement a comprehensive solution: a scalable Layer 1 and a network of blockchains that also benefit from Ethereum’s security. Just as the entire internet doesn’t run on one server, the entire internet of value won’t run on a single blockchain. In the end game, we’ll have a diverse ecosystem of blockchains, all enjoying the security of Ethereum’s L1.

L2s are an integral part of this strategy, and they are Ethereum when they use Ethereum for DA, are derived from Ethereum L1, meaning they build their chain and validate their state transitions based on data from Ethereum’s L1 blockchain, and when their critical verification processes, like fraud proofs and SNARK/STARK verifications, play out on Ethereum L1. However, that doesn’t mean they’ll always be tied to Ethereum. While it’s theoretically possible for L2s to switch DA providers or move critical functions to another chain, doing so would be incredibly complex, disruptive, and unlikely, especially as these rollups become more deeply integrated with Ethereum over time. For now, L2s that rely on Ethereum for DA, derive their state from Ethereum L1, and use Ethereum for these critical verification processes are very much a part of Ethereum.

In order to understand why I believe the rollup-centric roadmap was a no-brainer decision and why L2s are Ethereum, we need to explore the historical context that led to this decision and examine how closely tied L2s are to Ethereum. That’s what I’ll be covering in the rest of this post.

Ethereum’s Vision and the Challenge of Scaling

When Ethereum launched, it had the ambitious goal of creating public good infrastructure where anyone could run a computer in their home, verifying every transfer of digital value on the planet cheaply. The Ethereum Community refuses to give up on the principle that everyone should be able to verify every transfer. This is the cypherpunk nature of Ethereum. If people can’t run a node and verify their transactions, trusting someone else instead, it’s a failure. In this regard, Ethereum and Bitcoin share a common goal.

This approach works on a small scale, but scaling it has always been a challenge. Bitcoin essentially gave up on this by becoming a store of value, which I don’t say to criticize—it still adds immense value to the world. But Ethereum believes that scaling while maintaining decentralization is possible and has been working toward that goal. From day one, Ethereum has aimed to be a decentralized platform accessible to the world, and unlike a store of value, achieving this ambitious goal requires effective scaling.

The Dual Challenge: Execution and DA

In 2015, Ethereum realized that scaling the system required solving two distinct problems: scaling the ability to execute transactions (going from state N to state N+1) and scaling the ability for computers to download any specific transaction and know with certainty that no transactions are missing (DA). Each is a different challenge. At that time, Ethereum was handling around 15 transactions per second (TPS), while Visa was processing an average of 1,700 TPS, with the capability to handle up to 24,000 TPS. To surpass Visa in performance, Ethereum needed to solve both challenges.

In its early years, Ethereum explored scaling execution through a method known as sharding, which involved creating multiple copies of the EVM that would communicate with each other. However, this approach ultimately led to a dead end. Ethereum recognized that the true solution to scaling execution lies in advanced cryptography, which initially seemed a distant goal. Yet, what once appeared far-fetched is gradually becoming a reality. Cryptographic proofs like SNARKs and STARKs, which enable the verification of computations with certainty, are at the core of this breakthrough. Although early implementations were slow and prone to bugs, the potential of these technologies is enormous. If these proofs can be generated quickly and reliably, they would solve the execution scaling problem. However, their readiness for Mainnet deployment remains uncertain, as they must be 100% secure, a milestone that has yet to be fully achieved.

Ethereum has significantly impacted research in this area. In its early years, Ethereum sparked renewed interest in making these proofs faster and more reliable. But while progress has been made, at this point it is still years, maybe decades, away from being ready. Let’s put a pin in this story and shift focus to scaling DA.

By 2017, efforts to scale DA were gaining significant momentum. The challenge was to handle large blocks of data—larger than any single node could practically download—while still allowing even small, resource-limited computers to know all the transactions are available to be downloaded and nothing is missing. DA is crucial because if any part of the data is missing, it could compromise the system entirely. For instance, if a transaction that prints 1000 ETH is missing, the state transition might be incorrect, leading to catastrophic outcomes. 

Even if the network can't process an invalid state transition because they include a cryptographic proof, it's still essential that all transactions are available so that nodes maintaining the state can update their records accurately. This also ensures that nodes have access to any specific transactions they might need, such as for tracking their own state data. Every node downloads the entire block of data, which typically ranges from around 20 KB to 80 KB depending on network activity. However, as block sizes increase, this becomes impractical for many nodes, especially those with limited resources.

To address this, researchers focused on how to ensure that even if a node only downloads a small portion of the data, it can still verify the block’s integrity and ensure that nothing is missing. The solution that emerged is known as data availability sampling (DAS). DAS allows nodes to verify large datasets by only sampling a small portion of the data. If the sample passes verification, it’s statistically highly likely that the entire dataset is intact. However, if any part of the data is missing, nodes that sample that specific part can raise an alarm, signaling to the rest of the network that something is wrong.

This approach is not only efficient but also extremely scalable. Individually, it’s not resource-intensive for nodes since they only need to download a small portion of the data. However, when many nodes participate in sampling, they can collectively cover a vast amount of data, allowing the block size to grow in proportion to the number of nodes. This means that as the network scales with more nodes, the block size can increase accordingly, while the network can still statistically ensure that all the data is available and intact, further enhancing the system’s capacity. Major breakthroughs in this area were made in 2017, culminating in the publication of a pivotal paper in 2018, which detailed the mechanics of DAS (see the paper here). 

To grasp the concept, Vitalik offers a helpful analogy: Imagine you're an orange farmer with 5,000 oranges. Instead of checking each one, you randomly pick 25. If all 25 are ripe, it’s likely the whole batch is ripe. Now, imagine you use a special pesticide (in reality this is polynomial jedi magic) that ensures the entire harvest is ripe if at least 50% are ripe. After picking 25 random oranges and finding them all ripe, you can start to build confidence that a large portion of the harvest is ripe. If your goal is to ensure at least 50% are ripe, the more random oranges you find that are ripe, the higher your confidence grows, eventually reaching near certainty (99.99%) that at least half of the harvest is ripe. This is similar to how DAS will work in Ethereum.

Looking forward, Ethereum's endgame solution to the DA side of the scaling problem involves DAS within a framework known as Danksharding. While Ethereum blocks previously reached up to 80KG, this solution could allow blocks to grow up to 32MB. Thanks to DAS and some polynomial jedi magic that’s beyond the scope of this post—nodes will be able to verify with 99.99% certainty that no transaction data is missing. This is over a 400x improvement.

Why A Rollup-Centric Roadmap?

Fast forward to 2019: scaling DA was progressing faster than scaling execution. Ethereum recognized that by prioritizing the scaling of DA on its Mainnet, it could provide immediate benefits to the ecosystem. L2s solutions could start leveraging this improved DA to achieve scalability now, while still ensuring that no invalid state transitions could occur. This strategic move allowed Ethereum to maintain its core principles of decentralization and security while enabling L2s to offload execution tasks. At the same time, the emergence of a robust L2 ecosystem provided a unique opportunity to accelerate progress in scaling execution. By creating a thriving L2 environment, Ethereum opened the door for these projects to attract significant investment and resources. 

L2 projects like ZKsync, Polygon, StarkNet, ZKsync, Optimism, and Arbitrum were able to raise substantial amounts of capital—$458M, $451M, $261M, $178M, and $124M, respectively. This influx of funding allowed these projects to push the boundaries of cryptographic proof technologies like SNARKs and STARKs, as well as other aspects of execution scaling. With access to millions of dollars in funding, these L2 projects could build dedicated teams of top-tier cryptographers and engineers, focusing on making SNARK and STARK technology faster, more reliable, and more scalable, while also advancing execution scaling in other innovative ways. This level of concentrated effort and financial backing was something that the Ethereum Foundation and academic researchers, despite their early contributions, could not have matched on their own.

The rapid development driven by these L2 companies resulted in significant breakthroughs. Proof generation times decreased, bugs were ironed out, and the overall reliability of cryptographic proofs improved dramatically. What might have taken decades under the slower pace of academic research was being achieved in a fraction of the time. The competitive and well-funded L2 ecosystem created an environment where innovation thrived, directly contributing to the acceleration of execution scaling.

By scaling DA on the mainnet, Ethereum not only supports current L2s but also speeds up the development of execution scaling. Eventually, these zkEVM rollups will develop a robust zkEVM (using SNARKs) that can be integrated into Ethereum, enabling true in protocol execution shards and realizing Ethereum’s full scalability potential, when combined with the final version of DAS (Danksharding). For more on the end state of Ethereum execution scaling, Justin Drake’s comment on a reddit AMA provides a great overview: link. In the meantime, L2s serve as out of protocol execution shards.

You can think about the rollup-centric roadmap as a form of decentralizing the R&D needed to scale Ethereum. Initially, the Ethereum Foundation and academic researchers, both with limited resources, were the primary drivers of scaling efforts. However, by embracing the rollup-centric roadmap, Ethereum effectively roped in private companies that could raise millions from venture capitalists to accelerate progress. This influx of funding and talent has led to faster advancements in scaling technologies like SNARKs, STARKs, and execution environments.

The end state, after execution scaling is fully integrated into Ethereum, will be a system that not only scales but also supports out of protocol chains that can tap into Ethereum’s security. This will be crucial as Ethereum scales to onboard the entire world. Even with a fully scaled Ethereum, the demand will likely outstrip supply, so having additional chains that leverage Ethereum’s security is a win in all directions.

Was the Rollup-Centric Roadmap a Mistake? 

To recap, if we consider whether the rollup-centric roadmap was a mistake, let's review the decisions the Ethereum ecosystem could have made:

1. Abandon Scaling L1: Scaling L1 is hard enough that it might not be worth the effort. Ethereum could have become a store of value, similar to Bitcoin, and focused only on a few applications. 

2. Focus Solely on L1 Upgrades: The ecosystem could have focused only on introducing upgrades to both the DA and execution on L1 together, without involving L2 solutions. It’s unclear how long it would have taken to solve execution scaling problems.

3. Leverage DA Scaling Progress: Recognizing that DA scaling was progressing faster, Ethereum could allow L2s to take advantage of it. This approach would enable companies to start leveraging L2 solutions, raise millions to accelerate execution scaling, and experiment with different execution environments to cater to various developer needs. This strategy would speed up the eventual end game of a fully scaled Ethereum and allow other chains to access Ethereum’s security in the midterm.

The Ethereum community went with option 3, which, even in hindsight, seems like the smart choice to me. By decentralizing scaling R&D and enabling a thriving L2 ecosystem, Ethereum has positioned itself to achieve its scalability goals faster and more effectively, while also opening up new opportunities for innovation and security.

But What Does This Mean for the Identity of L2s?

However, as we shift back to the question of whether L2s are truly Ethereum, it’s important to recognize that while switching DA layers is theoretically possible, in practice, it’s a monumental task. The decentralized governance structures of major rollups mean that any decision to switch DA providers would need to undergo rigorous community scrutiny, requiring multiple rounds of voting and discussions. Even if a decision were to pass, users would have ample time to exit the rollup if they disagreed with the move. This process is not only time-consuming but also potentially disruptive, making it unlikely that an established rollup would easily switch from Ethereum. The level of coordination, community consensus, and technical adjustments required to switch DA layers underscores the deep ties between these L2s and Ethereum.

Additionally, L2s are deeply intertwined with Ethereum because they are derived directly from Ethereum L1. The L2 chain is constructed using data from Ethereum L1, including L1 block attributes, deposits, sequencer batches, and system configuration updates. You can see this in the OP Stack Specs. 

Moreover, the bridge contracts on Ethereum L1, which facilitate deposits, withdrawals, and proof verifications, are critical to the functioning of these rollups. The massive amounts of value locked in these bridges—billions of dollars in ETH and other ERC20 tokens—highlight the dependence of L2s on Ethereum. For example, Arbitrum’s bridge holds about ~2m ETH (~$6bn), Base’s bridge holds ~550k ETH (~$1.4bn), and OP Mainnet’s bridge holds ~510k ETH (~$1.3bn). And these figures only account for ETH balances, the bridge also secure other ERC20 tokens worth billions more. These bridges serve as the ultimate safety net, allowing users to exit the rollup back to L1 if necessary. 

For zkRollups, Ethereum L1 is also where the SNARK/STARK verifiers reside, which are responsible for verifying the correctness of state transitions. Similarly, for optimistic rollups, L1 is where the fraud proof game plays out, ensuring that any disputes about state transitions are resolved securely. It’s crucial that these smart contracts are free of bugs and remain safe because any failure could result in an invalid state transition, undermining the entire rollup. As these contracts become more battle-tested and prove their security over time, the likelihood of moving away from Ethereum decreases. The longer these rollups operate on Ethereum, the more entrenched they become, making a switch increasingly unlikely.

While it’s theoretically possible for rollups to switch their DA layers or even move their proof verifiers to another chain, such a shift would be incredibly complex and messy, akin to a major hardfork. The longer these rollups operate on Ethereum, the more entrenched they become, making a switch increasingly unlikely.

Josh Stark frames it well, he’s been tweeting stats with this format for months: “Ethereum is ____ (insert metric) L1 plus ______ (insert metric) on all L2s under its security.” As long as these execution environments use Ethereum, they are Ethereum. But it’s true—theoretically nothing is stopping them from leaving in the future.

Sure, but They Don’t Feel Like Ethereum

A reasonable counterpoint to my argument that rollups are Ethereum is that, while technically true for the reasons I laid out, it doesn’t matter if they don’t feel like Ethereum to the user. From the user’s perspective, it can often feel like navigating 30 different chains, which is a real pain in terms of user experience. I agree with this, but it’s important to recognize that the entire Ethereum community is aware of this issue and is actively working on a solution.

There are two standards in development that will allow users to make transactions without needing to worry about which chain they’re on, as long as it’s within the Ethereum ecosystem. The wallet will handle everything behind the scenes, making the experience seamless and truly feel like Ethereum. 

For example, once these standards are adopted and built into apps and wallets, the experience will be seamless. Let’s say you visit an application built on Zora and want to collect a photograph for 0.001 ETH, but you’ve never used Zora before, and all your ETH is on Base. You just click mint, and it works as if your ETH is already on Zora. In the background, the wallet is handling the bridging of the 0.001 ETH to Zora, but you won’t even notice it happening.

Vitalik has been advocating for the adoption of these standards for months, and there’s an active Telegram group with 76 wallet developers, researchers, and application developers who are working on finalizing and implementing these standards.

Before long, using an L2 will feel like using Ethereum itself, with the complexities hidden in the background.

Conclusion

2015: "Ethereum is a scam ICO that will never ship."

2016: "Ethereum is dead after the DAO hack, there's no coming back."

2017: "Ethereum is only used for scam ICOs."

2018: "Ethereum will never scale, EOS, Cardano, or Polkadot will overtake it."

2020: "Proof of Stake will never work or ship."

2021: "Ethereum has abandoned its users despite supporting them in the past."

2024: "Ethereum is a security, it will never get an ETF."

Today: "The rollup-centric roadmap was a mistake. L2s aren't Ethereum, and the UX is a real pain."

That's the FUD timeline, but I don’t subscribe to a world of FUD. Instead, let’s look at the reality of Ethereum’s scaling journey:

2015: Ethereum Mainnet launched with a transaction throughput of approximately 12-15 TPS, setting an ambitious goal to scale beyond Visa's capability of 24,000 TPS.

2015: Ethereum community realized that scaling required solving two distinct problems: DA and execution.

2017/2018: Efforts to solve the execution problem through sharding hit a dead end. The community identified advanced cryptographic solutions like SNARKs and STARKs as the future of scaling execution, although they were considered decades away from readiness. Meanwhile, DA research thrived, leading to the publication of the DAS paper.

2019: It became clear that DA could be scaled independently of execution. This realization allowed rollups to begin leveraging Ethereum's security while solving the execution problem.

2020: Ethereum researchers recognized that they could decentralize Ethereum’s scaling R&D by allowing L2s to form corporations, raise millions from venture capital, and focus on solving the execution problem and advancing cryptography. Researchers continued working on scaling DA.

2020-2022: L2 projects like ZKsync, Polygon, StarkNet, Optimism, and Arbitrum raised substantial amounts of capital—$458M, $451M, $261M, $178M, and $124M, respectively.

2021: 

• The "end game" solution to the DA problem was proposed: Danksharding. 

• Optimism launched as the first rollup on Ethereum.

2022: The Proto-Danksharding plan was introduced as an intermediate step toward Danksharding. From the perspective of rollups, this would mark their final interface with Ethereum, with the introduction of blob data space.

2023: 

• The first zkEVM rollup, ZKsync, launched, followed by other zkEVM rollups like Polygon zkEVM, Scroll, and Linea. Just a few years earlier, zkEVMs were considered a distant possibility. 

• Base was announced, bringing the publicly traded giant Coinbase into the arena of helping to scale Ethereum execution.

2024: 

• The Ethereum network, comprising Ethereum L1 and L2s, reached 138 TPS before Proto-Danksharding went live. After its implementation, the network hit an all-time high of 360 TPS.

• Despite the thriving rollup ecosystem, users experienced the network as navigating individual chains rather than one cohesive Ethereum. In response, the community began actively working on and implementing standards to abstract away the different chains, aiming to create a seamless, unified Ethereum experience.

• Execution scaling also made significant strides, with Base, announcing its goal to reach 1 Ggas/s, a 400x increase from current levels.

• New L2 projects, such as MegaETH and Reddio, raised significant funds and set ambitious targets to push the limits of execution scaling, aiming for 100k+ TPS through innovative approaches like advanced node specialization and optimizing parallel execution.

• Meanwhile, zkEVM rollups continued to mature, with developers focusing on refining and finalizing their smart contract designs, bringing them closer to a fully optimized and secure state.

2025: PeerDAS is expected to go live, bringing DAS to Mainnet, further advancing Ethereum’s DA scaling.

It once looked like Ethereum would never scale. The prevailing thought was that the only way to scale these systems would require data centers to verify transactions. The cypherpunk vision, where anyone in the world can cheaply verify the internet of value and know their digital property will never be taken from them, seemed dead. But I’ve just laid out where Ethereum currently stands and how it got here. Do you think this vision is dead? I think you know where I stand.

Thank you to YB, Paul Dowman, Shazow, Samuel, and the Farcaster community for their comments on earlier drafts.

At a high level, one of Ethereum's key goals is to make running a node that verifies blocks as lightweight as possible. When Ethereum switches its state database structure from a Merkle Patricia Tree to Verkle trees, it will enable a new type of node called a stateless client. These nodes are almost as lightweight as current light clients that only receive headers and can verify state proofs, but they also verify transactions in real-time and therefore are fully protected against invalid state transitions.

Currently, the number of nodes that protect the network against corruption (invalid state transitions) is in the thousands, but with the introduction of stateless clients, this number could potentially increase to millions. Additionally, Verkle trees enhance the efficiency of transaction verification, allowing for a safe increase in the gas limit by 3-10x.

In this post, I'll briefly touch on what Merkle and Verkle trees are, but the focus isn't on cryptography. Instead, it's for those interested in the bigger picture of what these data structures enable: stateless clients. You'll understand what they are, how they work, why they matter, how they fit into Ethereum's roadmap, and why Vitalik is so excited about them.

TLDR

What is a stateless client and how does it work?

Ethereum's state, the database of accounts, balances, and smart contract data, grows alongside the blockchain itself. Each node currently needs 2TB of storage (SSD) to store this state (and history 1.2TB), which is currently 245.5GB and growing. Stateless clients verify transactions without storing the state. They rely on execution witnesses included with each block, containing pre-state data and a cryptographic proof that this pre-state is part of the parent state root. For example, if Alice sends Bob 1 ETH, the witness confirms Alice and Bob's starting balance is part of the parent state root. You then execute the block to ensure that Alice has sufficient funds and verify Bob's updated balance. Ethereum's current state is stored in a Merkle Patricia Tree, which can generate state proofs. However, these proofs become excessively large as the state grows, making them impractical for efficient transmission and verification. Verkle trees are a new way to store Ethereum's state, enabling compact proofs that remain small even as the state grows. These compact proofs make stateless clients a practical reality.

What are some of the traits of stateless clients?

1. Near-Instantaneous Node Setup: New nodes can join the network and start validating immediately, receiving only the latest block and its state proof. This eliminates the process of downloading and verifying the entire blockchain history, which can take over a day.

2. Low-Powered Nodes: Stateless nodes eliminate the need for extensive storage and, when combined with eliminating the need to store history, will allow nodes to run on lower-power devices. They could run locally in your browser or possibly on very low-power devices like smartwatches and phones.

   1. Cheaper Nodes: This reduction in storage requirements also makes verifying nodes much cheaper. Currently, a 2TB SSD, which is necessary to store the full state on a traditional node, costs around $100. 

   2. Wallet Integration: Wallets will be able to integrate these stateless clients into their products. Every time a user opens their wallet, it would locally spin up a new stateless client. This could increase the number of Ethereum nodes to the millions.

3. Verifying Light Clients: Currently, users trust centralized RPCs like Infura or Alchemy when interacting with or viewing the blockchain. Light clients today can already allow for trustless access to state information, and we need to push wallets to integrate them. However, stateless clients take this a step further by also protecting against invalid state transactions by verifying all the transactions in a block.

What do stateless clients unlock?

1. Unstoppable Decentralization: By potentially increasing the number of lightweight, full-verifying nodes to millions, stateless clients make Ethereum virtually uncorruptable.

2. Scalable Layer 1: As the blockchain's state grows, each node needs more storage space, leading to slower block verification due to increased database lookups and updates. This creates a compounding issue: more transactions mean faster state growth, further increasing verification time. This state growth is the primary obstacle to Ethereum's scalability. Stateless clients eliminate the need for extensive state storage and simplify database interactions, allowing it to happen almost entirely in RAM, ensuring block verification is not slowed by state growth. This could allow Ethereum to increase its gas limit by 3-10x without sacrificing verification speed.

3. Scalable Layer 2s: The way Ethereum plans to achieve throughput of 100k transactions or more for L2s is via a method called data availability sampling. How this works is beyond the scope of this post (maybe I’ll cover it soon ) but the key takeaway is the more Ethereum nodes there are, the more nodes that are sampling blob data, and the more nodes that are sampling blob data, the more blobs the Ethereum network can include per block. If there are enough sampling nodes, this will lead to data costs being virtually zero for L2s. Remember how stateless clients could lead to millions of nodes…

What does this set the stage for?

1. Fully SNARKed Ethereum: The ultimate goal is to move from receiving state proofs and verifying individual transactions to receiving a single SNARK proof that verifies the entire state transition is correct. This approach would essentially make Ethereum behave as a zkRollup, where a single proof can verify the block execution correctness, which includes a vast number of transactions, allowing Ethereum to scale 10-100x or more. In this world, compute is no longer a bottleneck for scaling Ethereum and running a node on the lowest power devices would be a given.

2. State Expiry: Users currently pay a one-time cost to store data on the blockchain, but nodes must store this data indefinitely. Stateless clients will allow anyone to verify the blockchain in real time with virtually no storage requirements. However, they are not the only nodes in the network. There will still be block builders and nodes that choose not to go stateless and prefer to keep the state. These nodes will require more and more storage as the state grows, leading to centralization risks. Adding Verkle trees for the state database sets the stage for state expiry. State expiry means that, except for nodes that choose to store everything (like archive nodes), all other nodes would remove state that has not been recently accessed (e.g., in the last year) and require Verkle state proofs to revive expired state. This would reduce the state that everyone needs to store to a flat ~20-50GB.

Wen?

The current roadmap suggests that Verkle trees (or a potential alternative) are more likely to be included in the Osaka-F star hardfork, tentatively scheduled for early 2026.

That’s the high-level takeaway. If you want to stop reading here, you'll have a good understanding. However, if you want to dive deeper, the rest of the post will cover in detail some of the topics touched on above.

Light Weight Nodes, Instantaneous Set Up, and Unprecedented Decentralization

Ethereum's long-term vision has always been to create an unstoppable blockchain, resistant to manipulation by any central group or entity. This vision hinges on the ability of millions, if not someday billions, of users around the world to run nodes and independently verify the network.

Currently, running a node that verifies the chain in real-time is possible on standard consumer hardware for a few hundred dollars, and over ten thousand people are doing just that. This empowers them to directly validate transactions and rules, safeguarding their assets and preventing unauthorized changes to the network. As Vitalik explains in "The Limits to Blockchain Scalability," "The elites of your blockchain community, including pools, block explorers and hosted nodes, are probably quite well-coordinated; quite likely they're all in the same telegram channels and wechat groups. If they really want to organize a sudden change to the protocol rules to further their own interests, then they probably can." Jordan McKinney, in "Scaling Ethereum 101," echoes this sentiment, emphasizing that wider node participation by users makes it significantly harder for malicious actors, even those who are well-coordinated, to collude and hijack the chain. 

In summary, the more nodes around the world running the chain, the more difficult it becomes for any central group to violate the rules of the blockchain and steal value from users.

Stateless nodes drastically lower the barrier to run a node. They will be so lightweight they could run in your browser or POSSIBLY on your phone. It would also be nearly instantaneous to spin up a stateless node. You’d receive the previous state root and the current proposed block along with the Verkle proof witness and immediately start validating the chain. Gone will be the days where it would take at least a day to sync to the tip of the chain.

Geth developer Marius van der Wijden expects that once Verkle trees make stateless nodes possible and wallets incorporate them into their products, Ethereum may grow from 10,000 nodes to millions of stateless nodes. "Everyone can run these nodes," he said. "They need a little bit of storage, they don’t need much memory, they need a little bit of bandwidth, but it could be that you can run these on your phone." Ethereum researcher Dankrad Feist also thinks running them on your phone might be possible. However, some Ethereum researchers don't think running it on a phone is practical quite yet.

Already today, the architecture exists for trustless interactions with Ethereum using light clients. Light clients allow users to verify state information by requesting proofs from RPCs, meaning they can trust the data they receive without storing the entire blockchain state. Wallets could embed light clients, like Helios, into their products, enabling users to verify parts of the state by asking an RPC for a witness proof to confirm accuracy. This approach allows users to interact with the blockchain trustlessly, ensuring the data they receive is accurate without having to rely on centralized services.

However, stateless clients take this one step further. Light clients currently trust that the block headers they receive are correct because they come from the sync committee. While this is a step in the right direction, it's not perfect. Stateless clients will be able to verify all transactions in a block, ensuring the headers are correct with certainty. This level of verification guards against invalid state transitions. By building stateless clients into wallets, users can protect themselves and the network from invalid state transactions, making Ethereum virtually impossible to collude against and attack.

While we work towards the full implementation of stateless clients, it's crucial to push for the integration of light clients into wallets today. This step will enhance trust and security in the short term. Once stateless clients are integrated, they will provide an even higher level of security by verifying every transaction, not just relying on headers.

A valid criticism is that people don't care about decentralization. However, Ethereum developers must remember its importance and prioritize it. By integrating stateless nodes into wallets, users can benefit from enhanced security and decentralization without added complexity or inconvenience. Another example of this is the potential integration of stateless nodes into development frameworks. This would allow app developers to enjoy a trustless RPC relationship without needing additional work. It's on us to resist the natural incentives and prioritize decentralization, even when it's the harder path.

The user experience remains the same, but it will be more trustless. This is how you build a protocol that can last for decades.

How to Safely Scale Layer 1

Historically, networks, like Ethereum, which have low hardware requirements are met with soaring fees when demand increases. We’ve seen this many times throughout Ethereum’s history. This has created a formidable challenge: how to scale the network to accommodate growing demand while not just preserving accessibility for everyday users but even making it easier to run a node.

To understand how stateless nodes fits into Ethereum's scaling puzzle, let's break down what happens within its 12-second block time. You can visualize this process in the screenshot from Jordan McKinney's "Scaling Ethereum 101" video below. 

In the first 4 seconds, a new block is proposed and propagated across the network. Nodes receive this block sometime within those first 4 seconds and spend about 300-600 milliseconds processing its transactions and verifying the block's accuracy. The remaining 8 seconds are dedicated to validators confirming the block's validity through a voting process. At first glance, the short block processing time compared to the 8 second voting time that follows it might suggest an easy solution: pack more transactions into each block and make the processing time a little longer. However, this is not so simple. While the 8 second voting process itself is relatively quick, it doesn't tell the whole story.

Although nodes can quickly agree on the tip of a chain (within that 8 second window), the remaining "dead time" is crucial. If new blocks were constantly being added at the same rate nodes process them, nodes that have fallen out of sync or are joining the network for the first time would never be able to catch up. 

Blockchain's State Growth Problem and the Need for Innovation

The growth of Ethereum's state also presents a major hurdle to scaling. Ethereum’s state is the database that stores contract bytecode, contract storage, account balances, and account nonces and is constantly getting bigger. 

https://learnweb3.io

LearnWeb3 - Become a next gen developer!

LearnWeb3 is a free platform to take you from zero to hero in Web3. Join 110k+ developers in our mission to make learning permissionless and collaborative.

As of Mar 4th of this year it took up 274GB of storage and is growing by 2.5GB every month. This expansion directly impacts how quickly blocks can be processed. As the state grows, it takes longer to find and update the necessary information, slowing down the entire verification process. This means that over time, block verification naturally becomes slower. Therefore, the more transactions Ethereum handles, the faster the state grows, creating a snowball effect that further increases verification time.

Binance Smart Chain highlights the dangers of scaling solely by increasing the transaction capacity (raising the gas limit and speeding up the blocktime). This led to an explosion in state size, making it virtually impossible for new nodes to join the network or for nodes that fell out of sync to catch up, as the time required to verify new blocks continuously increased, even with powerful hardware and a limited number of validators. This illustrates the critical need to address state growth directly as part of any effective scaling solution. (If you're curious to learn more about this issue, the Uncommon Core podcast episode with Hasu and Jon Charbonneau offers a detailed discussion around the 32min mark.)

When you combine the state database with the history of the chain (all the blocks and transactions needed to sync a node from the very beginning), which currently sits at a 1.2TB and grows by roughly 19.3GB each month, you're looking at a lot of storage. In total, you need 2TB of storage to run a full node today. So, if you want to run a node on a budget-friendly device like a NanoPC T6, Radxa Rock 5B, or Orange Pi 5 Plus, you'll need to spend at a minimum $170-$220 for the computer itself, plus another $100 for at least 2TB of storage. 

However, this is just the starting point. If the state and history continue to grow at the same rate, we'll hit the critical threshold of 1.8TB in just 2 to 3 years. This means that, sooner rather than later, you'd need to upgrade your storage to a pricier 4TB option, potentially costing around $300. And as the state and history keep expanding, you'd need to keep upgrading, eventually reaching a point where you'd need 8TB of storage, which can cost over $1,000! If this trend continues unchecked, running a node could eventually require a full-blown data center.

Ethereum's Current State Management (and Its Limitations)

Ethereum's current state is stored in a data structure called a Merkle Patricia Tree. This tree-like structure organizes all the account balances, contract code, and storage data. Each leaf represents an account's state. These leaf hashes are then combined in pairs and hashed, forming higher-level branches. This process continues, creating a cascade of hashes until a single root hash emerges, representing the entire state. 

This structure offers several benefits. First, it ensures data integrity: any change to even a single account's state will result in a different root hash, making tampering immediately evident. Second, it enables efficient verification: instead of downloading the entire state, you can prove a specific piece of data's validity by presenting a Merkle Proof. 

A Merkle proof is a set of hashes that can verify a specific piece of data belongs to a larger dataset. It leverages the tree structure, where data is hashed and combined hierarchically into a single root hash. The proof includes the data's hash and a path of sibling hashes that allows recalculation of the root hash, confirming the data's inclusion. In Ethereum, a Merkle proof allows you to verify specific information about an account or smart contract without downloading the entire blockchain's state.

https://inevitableeth.com

Merkle Tree

Applying a hash function takes data (of arbitrary contents and size) and reduces it to a unique, compact string. Every input produces a unique output, even if two inputs are nearly identical. A Merkle Tree uses hashing to build a data structure that allows for quick, efficient, verifiable proof that a transaction was included in a much larger data set.

When a new block arrives, it has a list of proposed transactions and a new state root. Nodes, each maintaining a copy of the current state in a Merkle tree, verify each transaction. They ensure senders have sufficient funds, execute smart contract logic, and update their local state tree accordingly. After processing all transactions, the node recalculates the state root by hashing the updated tree. This recalculated root is then compared to the one provided in the block header. A match confirms the block's validity, proving that the validator who proposed the block executed the transactions correctly and didn't attempt any fraudulent activity. 

This process works well, but it needs to scale up. The current bottleneck is when the node needs to access and update the state. This requires reading and writing data to the hard drive, which has a limited input/output operations per second capacity. As the state grows, the number of required input/output operations increases, slowing down the entire verification process. 

This creates a compounding issue – the more transactions Ethereum handles, the faster the state grows, further increasing verification time. 

Even the fastest NVMe SSDs have a maximum capacity, which translates into a theoretical limit on the number of transactions Ethereum can process per second. Eventually, the growing state will exceed even the fastest drive's capacity, acting as a "brick wall" that limits Ethereum's transaction throughput. 

In addition to their large hard drives, nodes also have a faster type of memory called RAM for storing temporary data. Think of RAM like a super fast scratchpad for the computer to jot down notes while it's working. Accessing and updating information in RAM is lightning fast compared to the hard drive. The catch is that RAM is much smaller, while most Ethereum nodes today have 2TB of storage space, their RAM is usually only 32GB or 64GB.

The Key to Unlocking Ethereum's Speed and Scalability

Verkle trees are a game-changer because they allow nodes to verify blocks primarily using this fast RAM, barely touching the slower hard drive. Now, you might be thinking, "Hold on, don't nodes need the entire Ethereum state stored on their hard drive to verify transactions?" With Verkle trees, the answer is surprisingly no. They make it possible for nodes to operate without storing the state, a concept known as "statelessness."

Stateless clients represent a future for Ethereum where nodes no longer need to store the blockchain's entire state. Instead, they rely on compact proofs (Merkle or Verkle, more on this later), delivered alongside each block as a "witness." These witnesses essentially vouch for the accuracy of the specific data needed to verify the block's transactions. This streamlined approach allows nodes to do their job using primarily their fast RAM, with minimal storage requirements.

For example, if Alice sends Bob some ETH, the witness would include proof of Alice's and Bob's account balances. A stateless client can independently validate this transaction by checking these proofs and simulating the transaction to ensure it matches the new state root in the block header. This process is estimated to be 3-10 times faster than the current method of verifying blocks, which requires retrieving and updating state data from a node's hard drive. This speedup opens the possibility of increasing the gas limit by a factor of 3 to 10, leading to a corresponding increase in the blockchain's throughput.

However, for stateless Ethereum to truly work, the current Merkle tree structure needs to be replaced with Verkle trees. Merkle proofs are simply too big when dealing with Ethereum's massive (and growing) state. 

Unlike Merkle trees, which use multiple branches and hashes to represent each piece of data, Verkle trees use a more compact structure based on vector commitments. You can picture it like a wider, shorter tree, meaning there are fewer levels to traverse when creating a proof, and the proof size stays consistent even as the state grows. This results in dramatically smaller proofs, making the "stateless" client vision a practical reality. 

Verkle trees achieve their magic through some seriously impressive cryptography. While the inner workings might seem like Jedi magic to most of us (myself included!), the key takeaway is that Verkle trees enable drastically smaller proofs compared to Merkle trees. While Merkle proofs for a block can easily exceed 10MB, and in the worst case, reach up to a whopping 400MB, Verkle proofs are mere kilobytes in size! A fun fact about Verkle Trees is that John Kuszmaul designed them in 2018 while still in high school.

While stateless nodes are theoretically possible with Merkle proofs, they're impractical in reality. For stateless operation to work efficiently, the witness size must be very small, on the order of kilobytes, aka the size of Verkle proofs. Merkle proofs can exceed the capacity of RAM and make it difficult to transmit them across the network quickly enough for validators to process within the 12 second block time.

Ethereum's Modular Future

If regular nodes aren't storing the state, who is? With PBS, the responsibility of building blocks is offloaded to specialized entities called builders. These builders run powerful machines designed to handle the heavy lifting of generating Verkle proofs and maintaining a full copy of the Ethereum state. This division of labor allows builders to focus solely on constructing blocks, including creating the Verkle proof witnesses. Meanwhile, validators can specialize on efficiently verifying the validity of these blocks using the compact Verkle proofs provided by the builders. This modular approach will rely on other entities like archive nodes, RPC services, and block explorers to play a role in holding and serving the state to users, always accompanied by a cryptographic proof to ensure the correctness of the information provided.

Potential Alternatives to Verkle Trees

While Verkle trees are a promising solution, Ethereum is not strictly bound to them. The ultimate goal is to develop the most efficient stateless clients by keeping the database simple, SNARK-friendly, and capable of creating small state proofs and the community is exploring other alternatives solutions including:

• Binary trees: Potentially wrapped in a STARK to reduce proof sizes. 

• SHA256-based approaches: Known for safety but slower to prove. 

• Lattice-based hash functions: Arithmetically simple and prover-friendly, offering compact proofs.

Ethereum remains open to adopting the best available cryptographic structure to achieve efficient stateless clients and true scalability. For more specific details of each potential alternative check out this tweet from Vitalik.

Timeline and Transition

However, it's important to note that this future isn't imminent. While Verkle trees are a significant development, their integration into Ethereum mainnet will be a gradual process. They are not going to be included in the upcoming Prague-Electra hardfork, which is likely to be activated in early to mid 2025. Instead, the current roadmap suggests that Verkle trees (or a potential alternative) are more likely to be included in the Osaka-F star hardfork, tentatively scheduled for early 2026. This timeline, however, is subject to change as development progresses and the community aligns on priorities. There's still a lot of testing that needs to be done to ensure a smooth and secure transition. Switching to a new data structure like Verkle trees carries inherent risks, and the Ethereum community is committed to ensuring this change is implemented safely and responsibly. For more on the technical details of the transition see this document or this presentation.

Welcome to the endgame, wen stateless.

At its core, restaking helps developers build secure infrastructure projects (like oracles, bridges, or DA solutions) by tapping into the massive amount of value already secured within the Ethereum network. It allows developers to design their own proof of stake systems inside smart contracts. These smart contracts determine how much cryptocurrency participants must stake, the rewards for running the project correctly, and the penalties for misbehavior. 

Think of restaking services as a miniature version of Ethereum with the slashing conditions enforced by a smart contract. Just like Ethereum needs to update its ledger and stay secure, so do projects built on it. This is achieved through PoS: participants lock up cryptocurrency as a guarantee of good behavior. This limits the number of participants who can update the project and provides strong security. Those misbehaving risk losing their stake (slashing), while those who help the project run smoothly earn rewards. The total amount of cryptocurrency staked determines the project's economic security, making it costly for anyone to attack.

Restaking applies the same security principles as PoS blockchains to other kinds of projects. Developers set requirements within smart contracts, such as how much cryptocurrency must be staked, the rewards for good behavior, and penalties for acting maliciously. This allows them to tap into the existing security of Ethereum, which includes both staked ETH and the ability to opt into these projects while still validating Ethereum. Without restaking, developers would need to bootstrap their own economic security, a slow process. This usually involves launching their own tokens, attracting users to buy and stake them, and gradually building up a substantial value locked to deter attacks. It's a challenging path, especially when dealing with a new and potentially volatile token. Some projects, like Chainlink, rely on the reputation of their node operators to ensure security. While this can be effective to a degree, it ultimately relies on trust rather than verifiable economic incentives.

Restaking changes the game entirely. It lets developers leverage the value secured on Ethereum right from the start. This means tapping into not only the ~$100bn of staked ETH securing the Ethereum network itself, but also ERC20 assets within the Ethereum ecosystem, worth hundreds of billions more. This is a seismic shift. Projects that previously could only dream of achieving robust security levels can now access it practically overnight. It's like going from building a small neighborhood watch to having the entire national guard at your disposal.

Consider the example of oracle networks. Before restaking, Chainlink had a dominant position due to its established reputation and network of node operators. However, restaking enables the creation of oracle networks where nodes have both their reputation and significant capital on the line. This poses a real threat to incumbents like Chainlink, as new projects can quickly achieve greater levels of security, disrupting the existing landscape and fostering greater competition. An application's security is only as secure as its weakest link. In many cases that link is its price oracle. This drastically increases the economic security of the oracle, and as a result, the security of the entire app.

If a developer wants to build restaking services they need to code the node software to run these services as well as design the PoS consensus and encode it into an Ethereum smart contract. Users can then decide via the economic incentives if they want to run that particular service. If they decide they do they simply send coins, or "restake" their Beacon Chain ETH, to the restaking staking smart contract and run the node of the service.

Restaking could also run more like delegated PoS (this is how EigenLayer works) where there's a separation between stakers (who provide tokens to lock up) and operators (who run the technical side of things). On the system's UI you'll see a list of professional node operators, how much is currently delegated to them, and their fees. You simply click on an operator, choose how much to delegate, and they run the software on your behalf.

Users evaluate restaking services, considering the economic incentives (potential rewards vs. slashing risks) and the technical requirements (node software, hardware) to decide if they want to run them. If interested, they can either directly "restake" their Beacon Chain ETH or stake their ERC20s into the service's smart contract and run the node themselves, or delegate their stake to a professional operator, depending on the restaking platform's design.

This restaking ecosystem functions much like a marketplace, mirroring how node operators choose which blockchains to support. Just as operators evaluate different blockchains based on factors like the staking token's potential, rewards, slashing risks, and node requirements, they now have the same choices with restaking services. The key difference is that restaking happens entirely through smart contracts on Ethereum and can be managed through a single user interface. Also, depending on the design of the restaking service, you might not even need to buy their native token. Instead, you can often use ETH or other ERC20 tokens directly.

To "restake" your Beacon Chain ETH, you need to set this up when you initially become a validator. Instead of using a standard withdrawal address, you create a specialized restaking contract and link it to your validator. This allows you to allocate portions of your staked ETH to other restaking services. When you decide to withdraw your ETH from being a validator on the Beacon Chain, the restaking smart contract will assess your performance. If you've acted honestly, you'll receive additional rewards. However, if you've engaged in malicious behavior, you could face slashing penalties.

Is it Risky?

You might be wondering how you can use the same 32 ETH that's securing Ethereum to secure other things. Isn't that spreading yourself too thin or even worse, recreating the financial instruments that caused the 2008 financial crisis, where the same underlying assets were repackaged and resold multiple times, amplifying risk? The key difference is that restaking doesn't involve creating new financial products or hiding risk. Your ETH remains on the Beacon Chain, securing the Ethereum network. By opting into restaking, you simply take on additional responsibilities, such as running nodes for oracles or data availability solutions. You're not removing your ETH from its core duty, you're extending its usefulness. While there might be some overlap between Ethereum validators and restaking operators, restaking itself doesn't add to your Ethereum validator tasks.

To clarify with an example: Imagine there’s $100bn worth of staked Ethereum securing the Ethereum protocol. Now, let’s say half of those running Ethereum nodes have additional capacity and choose to opt into running other services like zkTLS verifiers, oracles, zk-coprocessors, DA layers, etc. They would only opt in if they have the computing capacity, otherwise, it would be economically irrational, as they could be slashed on both Ethereum and the new services if their hardware fails. As a result, the same $100bn in staked ETH is now not only securing Ethereum but also providing economic security for these additional services. This maximizes the efficiency of the staked ETH, allowing it to secure multiple layers of the ecosystem simultaneously.

The risks of restaking are primarily managed through slashing. If you don't meet the requirements of the restaking service you're supporting, you could lose some of your staked ETH. In a worst-case scenario, if slashing reduces your ETH below the validator threshold, you'll be removed as a validator. Think of it like this: you're already working hard to secure Ethereum. Restaking lets you make your ETH even more productive, earning extra rewards while contributing to other vital services. It's a way to increase your impact, but it comes with the responsibility to maintain high performance across all your roles.

Restaking isn't without risks. A major concern is the potential for a mass slashing event on the restaking layer. If many validators get slashed simultaneously, they could be ejected from the Beacon Chain, significantly reducing Ethereum's overall security and potentially creating pressure for a social layer fork to resolve the issue. Additionally, there's a risk of collusion among restaking operators. We'll discuss how EigenLayer and the community are actively working to mitigate these risks later.

State of Restaking

EigenLayer, the first live restaking platform on Ethereum, launched deposits on December 19th, 2023. While native ETH restaking (ETH also used for Ethereum validation) was uncapped, Liquid Staking Token deposits initially had limits to ensure system stability. These limits have been gradually lifted and removed entirely as of April 16th, 2024. Despite these early limits, demand remains high, and the system is cautiously scaling. Current TVL is ~$15bn.

Before exploring EigenLayer further, let's define a few key terms: 

• Operators: Entities that handle the technical aspects of Actively Validated Services (AVSs), which are infrastructure projects built on EigenLayer. 

• Delegators (or Restakers): Individuals who choose to stake their cryptocurrency (ETH or LSTs) to support specific AVSs. In doing so, they can potentially earn rewards or have their coins be slashed depending on if the operator is malicious.

EigenLayer launched on mainnet on April 9th, 2024, with EigenDA (an AVS developed by Eigen Labs) as the first AVS. At launch, payments to operators and slashing are not live. They planned to be implemented later this year once the protocol is more mature. Once slashing is live, if a service is run incorrectly, anyone can submit proof, and the smart contract will slash the staked currency. Therefore the slashing condition needs to be objective. EigenLayer is experimenting using it's EIGEN token for subjective slashing conditions but that's beyond the scope of this post. A veto committee, composed of stakers, operators, and AVS developers, will serve as a safeguard during the early stages of slashing. They will be able to reverse slashing decisions from non-malicious errors. This helps reduce risk for stakers and operators while AVSs are being refined.

Some Current Eligible AVSs to Receive Stake

• EigenDA: A data availability solution for Ethereum rollups and other applications. 

• Brevis coChain: Allows smart contracts to access onchain historical data and customizable trustless computations, enabling data-driven DeFi, zkBridges, and more.

• AltLayer MACH: Provides fast finality for rollups on Optimism and Arbitrum, improving transaction confirmation times.

• Xterio Mach: Supports Web3 game development, offering player-driven experiences built on decentralized infrastructure.

• eoracle: A oracle network, enabling offchain data feeds for smart contracts. 

• Lagrange State Committees: Introduces ZK light clients to optimistic rollups, improving their security and efficiency.

Risks

Restaking introduces several potential risks to the Ethereum ecosystem, including:

• Compromised Neutrality: Adding responsibilities to Ethereum validators could jeopardize Ethereum's core principle as a neutral base layer. Pressure to intervene in external service failures might lead to social layer forks, undermining trust in Ethereum.

• "Too Big to Fail" Dynamics: Reliance on forks to resolve issues could favor large projects, as they have more leverage to influence such decisions. This risks centralizing the ecosystem and harming innovation.

• Increased Staking Pool Centralization: EigenLayer's rewards structure may further incentivize staking pools, potentially leading to a few pools controlling significant portions of staked ETH. This weakens decentralization.

• Complex Risk for Delegators: Assessing the risks of AVSs and operators is difficult for delegators. This could lead to uninformed decisions, increasing the potential for both centralization and slashing events.

• Collusion Potential: Coordinated attacks by colluding operators could target several AVSs simultaneously and undermine the system's security model.

EigenLayer and the Ethereum community are mitigating these risks by:

• Prioritizing Contained AVSs: Supporting AVSs designed to minimize the impact on the broader Ethereum ecosystem.

• User-Friendly Risk Tools: Developing tools and education to help delegators properly assess risks.

• Collusion Monitoring: Monitoring restaking patterns to identify collusion attempts.

• Veto Committee: Temporary safety against unintended slashing in early-stage AVSs.

Liquid Restaking Protocols

Instead of delegating directly through EigenLayer's UI, users can opt to use LRT (Liquid Restaking Token) protocols. These protocols simplify restaking. You deposit your ETH or supported LSTs into an LRT protocol. The protocol pools these deposits and, upon reaching increments of 32 ETH, uses them to spin up new validators. These validators then participate in both Ethereum validation and opt into restaking on EigenLayer. As these validators earn rewards from both traditional staking (Beacon Chain ETH and LSTs) and securing AVSs, the value of your LRT (representing your stake in the pool) increases. LRTs can also often be used within DeFi protocols while your underlying stake continues to earn rewards. EigenLayer currently has a 7 day withdrawal window to ensure accurate rewards and/or slashing calculations. LRT protocols may offer immediate withdrawal options, assuming there's sufficient liquidity available within the protocol's pool. It's also typically much cheaper (gas wise) to deposit your tokens into an LRT protocol rather than directly through EigenLayer.

There's currently $10.6bn of value locked in Liquid Restaking protocols, with different protocols choosing to support different AVSs on top of their Ethereum validation duties. Some LRT protocols are even building their own AVSs. One LST provider predicts an additional 0.5% yield from running AVSs on top of traditional staking rewards, “would be nice”. For more on the specifics of each LRT protocol, I'd recommend this Bankless episode.

The Ethereum public mempool, the traditional gateway for all transactions, is facing a decline in usage. The reason is the rise of MEV, where sophisticated actors can profit from transactions while they're pending. In response, the community have devised innovative ways to mitigate the negative effects of MEV. One strategy involves redesigning applications to delay sending transactions to the public mempool until potential MEV is minimized. This is achieved through offchain transaction optimization, and currently, 22% of swaps use these redesigned applications. Additionally, users are increasingly opting for private transactions, completely bypassing the public mempool. They do this to either avoid MEV entirely or get its value returned to them. Currently, about 10% of transactions use this method. I believe both trends will intensify. The future likely lies in MEV-optimized applications seamlessly integrated with private transactions, maximizing user benefit. Ultimately, the public mempool may become a niche tool primarily used for transactions requiring the highest level of censorship resistance, even if it means suffering the negative consequences of MEV.

Don't worry if that introduction seemed confusing, I'll break everything down and explain it in a clear way 🫡

In this post I’ll explain:

• How the Ethereum transaction process originally worked.

• Why MEV led to the creation of new transaction pathways.

• How new applications are designed to minimize MEV.

• Methods for bypassing the public mempool via private transactions (private RPCs, OFAs).

• The role of L2s and future Ethereum upgrades.

• Why the public mempool will only have a niche role for censorship resistance.

Let's start by giving an overview of how the transaction supply chain originally worked and briefly go over what MEV is and how it changed everything. Originally there was only one way for a transaction to land onchain, your wallet would format your transaction, and you'd sign and broadcast it to an Ethereum node (either your own or a service like Infura or Alchemy). These nodes would gossip the transaction to their connected peers, creating a network wide pool of pending transactions called the public mempool. You can view the current live public mempool here. In PoW, miners would then fill blocks with the highest gas-paying transactions and compete to find the "golden nonce" to propose the block. However, the public mempool's transparency creates an issue. While your transaction awaits confirmation, it's visible to everyone, including sophisticated actors who can exploit this visibility for profit, leaving the sender of the transaction worse off. This is called MEV, and because of it the transaction landscape had to be changed.

In PoS, the validator that’s randomly selected to propose a block has a temporary monopoly over the transactions that go into a block and can extract higher yields than just issuance and gas fees. This is done by strategically reordering, including, or excluding transactions to benefit themselves. This poses a serious risk: if one actor becomes exceptionally good at MEV extraction, they could attract a disproportionate amount of validator stake. They could create a staking pool, offering higher yields to stakers and thereby attracting more stake. This would lead to significant centralization within the validator set and undermine Ethereum's core principle of trustlessness.

To combat this, the transaction supply chain was redesigned with proposer-builder separation (PBS). While the exact workings of PBS aren't crucial for this post, it's important to understand that any validator can now also run a piece of software created by Flashbots called MEV-Boost, giving them access to sophisticated entities called builders who create blocks and bid to have their blocks included onchain by the randomly selected validator. There’s also an entity in the supply chain called searchers that specialize in finding profitable MEV opportunities and bid to have their bundles included in the builders' blocks. However, PBS doesn't address the ways builders can exploit the public mempool to extract MEV from users. In fact, it further entrenches MEV in the ecosystem, since running MEV-Boost is economically rational for validators, more users are likely to feel the consequences of MEV. If you do want a deeper understanding of PBS, you can refer to my post: Ethereum Proposer Builder Separation: Past, Present, and Future.

The public mempool remains a prime target for searchers. These sophisticated actors analyze pending transactions and can insert their own transactions to profit at the expense of users –  think sandwich attacks, DEX/CEX arbitrage, or exploiting offchain knowledge about NFTs. With around 90% of validators running MEV-Boost it's clear that MEV remains a major issue for users. But this doesn't mean users and developers have been passive. Far from it, they've been actively developing strategies to counter MEV's negative effects.

The playbook for users to avoid the negative effects of MEV is simple: avoid the public mempool. There are two main approaches to accomplish this, which can also be used together for maximum benefit. The first is to use “MEV-optimized” applications where you express and sign your intent offchain (e.g., the trade you want to make). This intent is analyzed and only submitted to the public mempool (potentially as multiple optimized trades) when it minimizes MEV risk. The second strategy is to send your transaction directly to a builder, bypassing the public mempool entirely. This limits searchers' ability to exploit your transaction. The MEV-optimized applications I previously introduced could also submit their transactions directly to builders for even greater MEV protection. Let's break these down further.

All transactions included in L1 blocks via the public mempool are vulnerable to MEV. Ethereum's 12 second block times create a window for exploitation, but some applications are particularly prone to MEV extraction. AMMs, particularly those designed like Uniswap V2, are major sources of MEV. In fact, 98.85% of extracted MEV has come from just three AMMs: Uniswap V2 (63.4%), Balancer V1 (19.39%), and Uniswap V3 (16.06%). Their design allows searchers to profit from slippage. In simplified terms, slippage is the difference between your desired swap price and the actual executed price. When you submit a swap transaction to the public mempool, searchers can manipulate the order to ensure you receive the worst possible price within your specified limit, profiting from this price difference. However, there are app designs that mitigate this issue by using offchain intents to optimize transactions before they hit the public mempool.

These swapping applications that limit MEV are known as DEX aggregators. While their specific designs vary (like 1inch, Matcha, or the upcoming UniswapX), the overall principle is the same: you express your trading intent offchain and it’s analyzed and executed onchain in a way that minimizes slippage and MEV risk. There are two common approaches. The first is smart routing, where you submit your intent (e.g., swap 1 ETH for 3,500 USDC) to a server. It analyzes liquidity across multiple AMMs and devises an optimal trade route, potentially splitting your order across exchanges for the best price. The goal is to minimize potential slippage, making MEV extraction unprofitable for searchers. The second approach is offchain order matching, used by systems like CoW Swap. Here decentralized "solvers" match buyers and sellers offchain, and then execute these matched orders onchain in batches to save gas costs. Think a decentralized order book. Both methods introduce some degree of trust in the offchain components, as they could theoretically fail to execute your order or go offline. Despite this tradeoff, DEX aggregators are gaining popularity, currently representing 22% of total DEX volume. This share is likely to grow as users become more aware of the price benefits compared to swapping directly on a single AMM, where they often pay higher costs due to additional fees (like the Uniswap frontend fee), slippage, and hidden MEV costs. We can expect further innovation in MEV-optimized app design, building on the foundation laid by these early examples.

Now let's break down the second way users can avoid the public mempool: private transactions. These transactions capitalize on the fact that builders now create 90% of Ethereum blocks. Instead of broadcasting your transaction to the public mempool, you send it directly to a builder or group of builders. There are two main approaches within private transactions: private RPCs and OFAs (Order Flow Auctions).

An example of a private RPC is Flashbots Protect. Unlike broadcasting transactions to the public mempool, Protect submits them directly to selected builders, shielding them from the view of frontrunning searchers. Builders may share limited transaction details with certain searchers to facilitate inclusion, but this information is insufficient for frontrunning and restricts them to backrunning strategies only. Since its inception, Protect has protected over 13 million transactions and has processed nearly $30 billion in DEX trading volume.

Flashbots Protect further benefits users with MEV-Share, an integrated Order Flow Auction (OFA, I’ll explain OFAs in more detail in the next paragraph). MEV-Share auctions backrunning opportunities among searchers, returning a significant portion of the MEV extracted from your transaction. The trade-off is that limiting the number of builders or the amount of back run MEV you tolerate can potentially slow down your transaction's inclusion onchain. MEV-Share has refunded over over 360 ETH across 10.5k transactions. 

OFAs build upon the concept of a private RPC and add an auction component. The defining characteristic of OFAs is that they aim to refund most of the MEV extracted from your transaction back to you. Users submit their orders (transactions or intents) to an auctioneer, where MEV searchers compete to execute them. While searchers can still use MEV strategies, competition within the auction drives them to bid aggressively, allowing the bulk of the MEV proceeds to flow back to you. With MEV-Boost, most of the value extracted from MEV flowed to validators, but OFAs shift this dynamic to benefit the users who generate the value. This realignment is generally considered a more fair outcome. For example, consider a large swap on Uniswap where you want to trade 100 ETH for 350,000 USDC. If submitted directly, MEV bots could manipulate the order to cause significant slippage, potentially resulting in you receiving only 320,000 USDC. However, in an OFA, searchers will compete to execute this trade, bidding up the amount of slippage they're willing to return to you. This competition could result in bids where searchers offer to return, say, $29,000 back to you (minus fees taken by the auctioneer). As a result, you might end up receiving 349,000 USDC (320,000 from the swap and 29,000 as an MEV refund), dramatically reducing the negative impact of MEV. OFAs are a relatively new concept and are still under development. While originally pioneered in 2021 by the now-closed project Rook, they are currently offered in various forms by projects like UMA's Oval and Flashbots' MEV-Share. Continued innovation will likely bring greater refinement to OFA models and potentially address challenges like centralization or potential trust assumptions.

Currently, around 10% of transactions are sent privately, bypassing the public mempool. You can see this trend on mempool.pics. I believe this number will continue to grow. With the financial incentives of MEV refunds or avoidance, why would users choose to expose their transactions on the public mempool? It's a matter of increasing awareness and improving the designs of OFAs and private RPCs. In the long term, I envision MEV-optimized apps like DEX aggregators integrating with private RPCs and/or OFAs to further benefit users. While they aim to minimize MEV, it can't be fully eliminated, so returning the remaining MEV to users (via OFAs) is a logical next step.

So, is the public mempool dead? Not entirely. There's more to consider, especially with Ethereum's rollup-centric roadmap. How do L2s and future upgrades factor into this equation?

When you submit a transaction on an L2, it's typically forwarded from an RPC service like Alchemy or Infura to the L2's centralized sequencer. If your transaction has sufficient gas, the sequencer will bundle it with others and submit the batch to L1 to update the L2's state. Depending on the design of the rollup it's mempool can be public (queried through the RPC service) or private (visible only to the sequencer itself). However, regardless of the mempool's visibility, the sequencer has full control over transaction ordering, creating the potential for MEV extraction. However, to date, L2 sequencers have generally honored their commitments to avoid this practice. But even if the sequencer chooses not to extract MEV on L2 itself, if their mempool is public, searchers may still be able to leverage information from the mempool to extract MEV on L1. While this centralized sequencer model reduces MEV on the L2, it also creates a significant risk of censorship.

Centralized sequencers can censor transactions. This was demonstrated during a recent hack on an application built on the Blast blockchain on March 27th. The hacker stole $63M, but Blast's sequencer blocked the hacker's transactions, preventing them from cashing out and moving the tokens off the rollup. Left with no other option, the hacker surrendered their private key to the Blast team. The Blast team then used this private key to submit and process a transaction (on behalf of the hacker) that recovered the stolen funds. While this example highlights how censorship can work in the protocol's favor, it also underscores the risks of centralization. It weakens the system's credible neutrality. Long-term, a reliance on centralized sequencers poses significant risks, especially on the regulatory side.

While the future is uncertain, many L2s will likely move towards decentralizing the sequencer role. This decentralization, even if not achieving the same level of permissionlessness as Ethereum validation, remains crucial for credible neutrality. However, it also reintroduces MEV risks. How MEV will evolve in this new landscape is unclear, but we can build off of the lessons we've learned on L1. The development and use of apps that minimize MEV leakage will undoubtedly continue to rise. As a user, preference will always lean towards systems that offer protection from excessive MEV extraction. L2s understand this, and I anticipate they will design systems that limit public mempool use and incorporate MEV redistribution or auction mechanisms similar to those on L1. Additionally, the “private transaction space” is continuing to innovate, with solutions like Flashbots SUAVE potentially playing a significant role in shaping the future of L2 MEV mitigation and harnessing.

It's important to remember that all of this is speculation. Another way rollups could potentially decentralize the sequencer is to have a permissioned sequencer set controlled by the rollup's DAO. DAOs could have the power to kick sequencers off the set if they're caught extracting MEV or censoring transactions. The future of decentralizing the sequencer remains an open question, and different rollups will likely approach this problem in different ways. If this problem interests you, I'd recommend checking out StarkNet's community forums where they're tackling this problem in the open and accepting community input.

There's a specific type of rollup with a unique design that deserves its own analysis: Based Rollups. Many in the Ethereum community, including Justin Drake, see them as the maximally credible neutral solution for L2s, potentially addressing the sequencer centralization challenge I was just describing. These rollups leverage Ethereum's existing transaction supply chain for sequencing and proposing L2 blocks. L1 block builders take on the role of what current L2 sequencers do, ordering L2 transactions and submitting blocks (along with proofs, if applicable) to update the rollup's state on the L1 smart contract.  The exact implementation of the transaction supply chain, including the presence of a public or private mempool, varies across Based Rollup construction. Taiko, the first Based Rollup, will launch with a public mempool similar to Ethereum's. This simplifies the launch process, but reintroduces MEV risks. When you send a transaction on Taiko, it goes to a Taiko node for verification and then is broadcasted to other Taiko nodes, creating a public mempool that L1 builders can query. Long-term, I believe Based Rollups will evolve away from public mempools to further mitigate MEV. They might adopt private RPC approaches, implement OFAs, or utilize systems like Flashbots SUAVE, which offers a form of encrypted mempool that significantly differs from the fully transparent public model.

If you stopped reading here you might think the public mempool is as good as dead due to MEV risks. Well, the public mempool's role will actually evolve, serving a specific, less frequent, but vital purpose: maximizing censorship resistance. For the absolute highest guarantee of transaction inclusion using the public mempool is the best option. Transactions sent via private RPCs bypass the public mempool entirely, meaning validators who don't run MEV-Boost and outsource block building will never see them. While this is currently a minority (around 10% of validators), these validators do not censor at all and simply include the transactions that pay the highest gas price in a block. 

Currently, a majority of relays (entities that pass blocks and bids from builders to validators) engage in censorship, refusing to forward blocks containing transactions from OFAC sanctioned addresses. If you want to send a transaction from one of those addresses and use a private RPC to avoid the public mempool, validators who don't run MEV-Boost won't see it. In this scenario, you'll rely on a non-censoring relay winning the proposed block, potentially leading to a longer wait time. While a non-censoring relay will likely include your transaction eventually, submitting it to the public mempool would generally lead to faster inclusion as it's visible to validators who don’t run MEV-Boost in addition to all the builders. Additionally, there's the risk of relays that currently don’t censor also adopting censorship. Ultimately, the public mempool remains the strongest tool for maximizing censorship resistance. If you're sending a transaction from an address that faces potential censorship, accepting the negative effects of MEV might be a necessary trade-off to ensure timely inclusion, or in the worst case, inclusion at all.

Ethereum's future upgrades might significantly impact public mempool usage. One exciting proposal gaining traction is inclusion lists, this upgrade might be included in the upcoming Pectra hard fork. This aims to strengthen censorship resistance by giving MEV-Boost running validators more control over transaction selection. Essentially, blocks would include a new "inclusion list" specifying transactions that must be included in the next block. If the next block doesn't contain all the transactions in the inclusion list then the block is invalid. This enforces a certain level of compliance among validators. The transactions on these lists would come from the public mempool, potentially solidifying its role as a censorship resistance tool.

It's important to note that Ethereum client implementations could offer customizable options for censorship. Certain clients may allow users to configure filtering mechanisms to prevent certain transactions from being included in inclusion lists. Despite this potential for optional client-level censorship, the very existence of inclusion lists forces builders to respect them. Validators defying inclusion lists risk having their blocks rejected, leading to missed rewards. This economic incentive, along with the likely large presence of non-censoring clients, helps mitigate censorship, uphold resistance principles, and strengthen the public mempool's role as a place for transactions needing maximum censorship resistance.

Another potential change to Ethereum's transaction flow is the Execution Tickets upgrade. This upgrade offers various benefits like smoother validator rewards, improved trustlessness for liquid staking protocols, L1 preconfirmations for Based Rollups, an easy to implement MEV burn, and more. However, our main concern is how it affects the public mempool. Execution Tickets change the system by removing validators ability to build blocks locally. It introduces an inprotocol lottery system that does two things: it sells "tickets" granting holders a chance to propose the transaction list for a block, and it randomly selects winning tickets. Holders of winning tickets can propose a block and their ticket is consumed. This change eliminates the previous advantage of the public mempool where a non-MEV-Boost validator could locally build and propose blocks in a credibly neutral way. However, Execution Tickets will still work with inclusion lists. Validators will still publish their inclusion lists, and the following execution ticket winner must include those transactions or their block is invalid. Therefore, the public mempool retains its value as a censorship resistance tool. If a transaction is in the public mempool it’s likely to be included in an inclusion list, guaranteeing its inclusion in a future valid block.

Regardless of the future of Ethereum, whether users are on L1 or L2, which upgrades are included, or continued reliance on existing infrastructure, one trend is certain: MEV-optimized applications and private transactions will continue to rise. Users will increasingly seek out DEX aggregators, and private RPCs / OFAs, either individually or combined, to minimize MEV's impact. These advancements and further innovations will empower users and come close to eradicating the negative consequences of MEV for the vast majority.

However, the public mempool won't disappear entirely. It will evolve from a universal gateway to a niche tool, crucial for a specific use case: guaranteed censorship resistance. A small portion of users, prioritizing the fastest possible onchain inclusion for their “transaction facing potential censorship” over MEV minimization, will continue to leverage the public mempool. Here, transactions are visible to everyone. This transparency comes at a cost in the form of potential MEV extraction, but it prioritizes the core principle of censorship resistance.

Unless you've been living under a rock (who knows, maybe even Patrick is excited about it), you've probably heard about account abstraction and ERC-4337, or at least noticed the excitement surrounding it. With ERC-4337, Vitalik's original vision for accounts can finally be realized. He initially aimed to build a system with native account abstraction, but after 1.5 years of initial development, he was forced to ship Ethereum without it due to community pressure. Now, with ERC-4337 live, we can fully appreciate the benefits of having our accounts as smart contracts, a significant shift from what they've been since Ethereum's inception.

For the remainder of this piece, I'll refer to smart contract accounts simply as smart accounts. These smart accounts allow you to program your desired verification rules as well as execution calls. This functionality means you can sign transactions with biometric methods like Face ID, encode multiple contract calls in a single action (such as approve and swap), enable social recovery methods, and facilitate pull payments like authorizing Netflix to withdraw 10 USDC a month. You can also set specific rules for your keys, such as allowing someone to trade a certain amount of tokens on your behalf without the ability to move NFTs or USDC, among other functionalities.

However, to truly grasp the workings and implications of account abstraction, it's essential first to understand how Ethereum accounts and transactions functioned before the rise of ERC-4337. And that's where our journey begins.

Ethereum Initially

In Ethereum, an account represents a participant with a unique address, capable of holding ETH. There are two types of accounts:

• Externally Owned Account (EOA): Controlled by individuals or entities who possess the corresponding private key. EOAs are capable of initiating transactions directly, such as transferring ETH, interacting with smart contracts, or deploying new contracts.

• Contract Account: Automated agents, known as smart contracts, that are deployed on the Ethereum network. They are governed by their embedded code and do not possess private keys. Unlike EOAs, Contract Accounts cannot initiate transactions on their own. They require an external trigger, a transaction initiated by an EOA or another contract, to perform actions defined in their code.

EOA Overview

Transactions must originate from an EOA and they are directly controlled through its private key. Possession of this key allows an individual (or entity) to sign transactions, effectively authorizing actions such as transferring ETH or interacting with smart contracts. This signature is the digital proof that the transaction has been authorized by the holder of the private key associated with the account address from which the transaction is sent. In these transactions, the corresponding public address, which is derived from the private key, is used as the from field in the transaction object. When an Ethereum full node receives a transaction from its peer, it needs to validate the transaction's signature. They are able to take the transaction and its signature and output the address that signed that transaction. If the outputted address does not match the from address, the transaction is immediately rejected, effectively blocking unauthorized transactions on the network. The from address is also the public address that serves as the account's visible identifier on the blockchain, enabling other participants to send funds to it. Anyone can create a transaction with the from address being any address. For instance, I could create a transaction where the from address is Vitalik's address. However, if you can't sign the transaction using the corresponding private key, the transaction will immediately be rejected. Therefore, ownership of an EOA's private key means complete control over the account and its funds. 

“Creating” An EOA

Creating an EOA on the Ethereum network is a bit of a misnomer. Rather than creating a new account in the traditional sense, generating a new EOA is more about gaining access to a specific address within Ethereum's vast, pre-existing address space. This process is straightforward and free of charge. Your Ethereum node can easily set up a new account upon request. The first step is generating a private key, a unique, random, 256-bit number. The chances of duplicating a private key are virtually nonexistent, equal to finding a specific atom within the observable universe. Here’s the enormity of that number for perspective: 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936. Even with the entire global population generating a billion keys every second, the probability of a repeat within our universe's lifespan is minuscule.

Using cryptographic algorithms, a public key is derived from the private key. Ethereum, like Bitcoin, uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256k1 curve. The process is a one way street: producing a public key from a private one is easy and cheap, whereas the reverse is nearly impossible with today's technology (aka until quantum computing arrives). The public key is a 512-bit figure, formed by two 256-bit coordinates on the elliptic curve. This deterministic process ensures the same private key always results in the same public key. The Ethereum account address is then created using the Keccak-256 hashing algorithm, which processes the public key to produce a 256-bit hash. The unique Ethereum address is formed from the last 160 bits (20 bytes) of this hash. In Ethereum's design, all possible addresses theoretically exist within its vast address space. It's possible to send ETH to an address for which no private key has yet been generated. Remarkably, if a private key for that address is later created, the individual who generated it would gain access to the sent assets.

For those interested in a deeper dive of the cryptography involved, Elliptic Curve Cryptography Overview and The Discrete Logarithm Problem videos provide an excellent breakdown of how the cryptography works and why it remains secure.

Contract Account Overview

Contract accounts, commonly known as smart contracts, differ significantly from EOAs. While EOAs are controlled by individuals through private keys, contract accounts are governed by predetermined code and lack private keys. Contract accounts are created and deployed on Ethereum through a transaction initiated by an EOA. The deployed code, written in a programming language such as Solidity, is then compiled and executed by the EVM.

Every time a contract account receives a transaction, either from an EOA or another contract, its code is executed by the EVM. These accounts maintain an internal state, a record of data like balances and ownership details, which can be altered according to the rules set in the contract's code. For instance, a DeFi application or a token contract like ERC-20 are examples of contract accounts, each with its unique set of rules and functionalities.

The embedded code in contract accounts often includes validation rules that define the conditions for successful transactions or function executions. If a transaction or function call does not meet these predefined rules, the contract will automatically revert the transaction. For example, a smart contract might have a rule that only allows the contract owner to withdraw funds. If someone else tries to invoke the withdrawal function, the contract will check against its ownership condition, fail the validation, and the transaction will revert, ensuring the assets remain secure.

Creating a Contract Account

Creating (deploying) a contract account from an EOA costs a gas fee, reflecting the computational resources required to update the Ethereum network with the new contract's code and state. There are two different ways to create a contract account. The first, and standard method, is by using the CREATE opcode. It's executed in Solidity using the syntax new ContractName(). The contract's address generated through this method is determined by two factors: the creator's address and their transaction count, also known as nonce. However, the exact address of the contract remains unknown until the transaction is confirmed, due to the nonce changing with each transaction the creator makes.

The process for determining the contract address using the CREATE opcode can be illustrated through the following pseudo-code:

rlpEncoded = RLP(senderAddress, nonce); 
hash = keccak256(rlpEncoded); 
contractAddress = '0x' + last20Bytes(hash);

* RLP stands for Recursive Length Prefix, a serialization method used in Ethereum.

The other method is using the CREATE2 opcode to allow for more predictable contract address generation. This method can be executed in Solidity using new ContractName{salt: salt}(), where salt is a parameter defined by the user. The contract address in this case is derived from a combination of the sender's address, the salt, and the contract's initialization code.

The pseudo-code for the CREATE2 opcode looks something like this:

hash = keccak256(0xff ++ senderAddress ++ salt ++ keccak256(init_code)); 
contractAddress = '0x' + last20Bytes(hash);

* init_code refers to the smart contract's bytecode.

Accounts in the EVM

In the EVM, every account is associated with four fields:

• Nonce: For EOAs, this counts the number of transactions sent. For contract accounts, it represents the number of contracts created. The nonce prevents replay attacks by ensuring each transaction is unique.

• Balance: The amount of Ether in the account, measured in wei. There are 1e+18 wei in one ETH, with wei being the smallest denomination of Ether.

Fields Specific to Contract Accounts:

• CodeHash: The immutable hash of the EVM code that defines a contract account's functions and behavior. In EOAs, this is a hash of an empty string, reflecting the absence of executable code.

• StorageRoot: Known as the storage hash, it's derived from the root node of a Merkle Patricia trie, a data structure for mapping keys to values. This is used by contract accounts for data storage. EOAs, which do not store data in this manner, have a constant value representing an empty trie.

Transactions Overview

Transactions are actions that change the Ethereum's network state. All Ethereum nodes agree on this state and share transactions that change it. When a block with new transactions is confirmed, it updates the network's agreed upon state.

Ethereum Transaction Structure:

• From: The sender's Ethereum address (EOA).

• To (Recipient): The receiving address. ETH is transferred to EOAs, or it triggers actions in contract accounts.

• Value: Amount of ETH being transferred, in wei.

• Gas Limit: The highest gas amount the transaction can use.

• MaxPriorityFeePerGas: The extra fee given to miners or validators.

• MaxFeePerGas: The maximum fee per gas the sender is willing to pay, inclusive of the base fee and priority fee.

• Nonce: A sequential number tied to the sender's address, indicating the number of transactions sent.

• Input Data: Used for calling contract functions, sending info, or deploying contracts.

• Signature (v,r,s): Added after the transaction is signed, confirming its authenticity.

A sample transaction for sending 0.01 ETH from one address to another would look like this:

{ 
  "from": "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8", 
  "to": "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a", 
  "gasLimit": "21000", 
  "maxFeePerGas": "300", 
  "maxPriorityFeePerGas": "10", 
  "nonce": "0", 
  "value": "10000000000000000", 
  "inputData": "", 
  "v": "0x1b", 
  "r": "0xb31c...1f", 
  "s": "0xc1b9...4e" 
}

The signature components (v, r, s) confirm the sender authorized the transaction. Once the signed transaction is shared with the network and validated by nodes, it can be added to the blockchain. The next section will detail these validation checks.

Life Cycle of A Transaction

Simple ETH Transfer

The journey of a simple ETH transaction begins with the creation of a transaction object by your wallet software.

An example transaction object for sending 1 ETH could look like this:

{
  "from": "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
  "to": "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
  "gasLimit": "21000",
  "maxFeePerGas": "300",
  "maxPriorityFeePerGas": "10",
  "nonce": "0",
  "value": "1000000000000000000",
  "inputData": "", 
}

The next step is signing the transaction. To sign it you hash the transaction object and then sign this hash with the sender's private key using the Elliptic Curve Digital Signature Algorithm (ECDSA) on the secp256k1 curve. The resulting signature, comprising 'v', 'r', and 's' values, is appended to the transaction, forming the signed transaction. Once signed, the Ethereum wallet or interface prepares the transaction for broadcast on the Ethereum network. This typically involves serializing the transaction into a raw hexadecimal format and then sending it to an Ethereum full node, often through an Ethereum client like Geth or a service like Infura.

Ethereum nodes, upon receiving a transaction, perform a series of checks to verify its authenticity and viability. These checks include signature verification against the sender's address, matching the nonce with the sender's account nonce, ensuring the gas limit is appropriate, confirming the sender's balance can cover the transaction value and gas cost, verifying the gas price, and checking that the transaction format adheres to Ethereum's standards. If a transaction passes these checks, the node adds it to its local mempool, a holding area for transactions before they are included in a block. The node then propagates the transaction to other nodes in the network.

Finally, once a transaction is included in a validated block and the block is accepted by the network, the transaction achieves confirmation and finality. The Ethereum blockchain updates to reflect the state change resulting from the transaction, modifying the involved parties' ETH balances accordingly.

The key thing I want you to take away from this lifecycle is that executing an ETH transaction requires proving ownership of the sender's address through the private key. This proof is validated by nodes offchain via signature verification. Once validated and processed, the transaction alters the blockchain's state, updating the ETH balances of those involved.

Smart Contract Interactions

Interacting with a smart contract is different from basic ETH transfers in a number of ways. One key difference is the utilization of the inputData field within the transaction object. This field is used to encode both the function call and any necessary arguments required by the function being called. The first four bytes of this inputData field are dedicated to the function selector. This selector is the hash of the function's signature (for example, transfer(address,uint256)), and it determines which function within the contract will be called. Following the function selector, the arguments to the function are provided in an ABI-encoded format, each of these arguments is padded to 32 bytes.

Here’s an example of a transaction object calling a smart contract function:

{ 
  "from": "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8", 
  "to": "0xContractAddressHere", 
  "gasLimit": "HigherThan21000", 
  "maxFeePerGas": "AppropriateFee", 
  "maxPriorityFeePerGas": "AppropriateTip", 
  "nonce": "TransactionCount", 
  "value": "AmountOfETHToSend (can be 0)", 
  "inputData": "FunctionCallData",
  "v": "0x1b", 
  "r": "0xb31c...1f", 
  "s": "0xc1b9...4e" 
}

When a transaction is sent to a smart contract, Ethereum nodes validate the signature, ensuring ownership of the sender's address through the private key, and then they run the transaction through the EVM to execute it. The smart contract's code determines whether the transaction is valid. If any of the contract's conditions are not met, the EVM reverts all state updates made during the transaction's execution. However, the sender still incurs the gas costs associated with processing the transaction, reflecting the computational resources used up until the point of failure.

Smart Contract Example - Multi-Signature Wallet:

In this multi-signature wallet contract, the confirmTransaction function includes several checks:

• onlyOwner: Ensures only wallet owners can call the function.

• txExists: Verifies the existence of the transaction.

• notExecuted: Prevents double execution of a transaction.

• notConfirmed: Stops an owner from confirming the same transaction multiple times.

Successful completion of these checks leads to a state update in the contract, reflecting the confirmation. If the required number of confirmations is reached, the transaction executes. 

In summary, both simple ETH transfers and smart contract interactions require proof of ownership via the private key associated with the from address. Transactions on the Ethereum network are authenticated this way, it's a non-customizable process. However, smart contracts can be designed to include onchain verifications as determined by the contract's code.

Limitations with the Initial Account and Transaction System

The initial account and transaction system faced limitations. One being that this setup restricted transaction verification to using ECDSA on the secp256k1 curve, which only checks the transaction's from address against the signature. While it's possible to add verification rules into smart contracts, ideally, accounts themselves would have this same customizability. Another limitation was that a single transaction could only call one smart contract and execute just one of its functions, rather than allowing multiple actions to be encoded in one transaction. Furthermore, there was no built in system for an address to cover the gas fees for another user's transaction, either for free or in return for a different token.

To begin addressing these issues, Ethereum needed to transition toward a system where contract accounts can initiate transactions. Contract accounts in this system would need two important functions: one to verify that the person sending the transaction is indeed authorized to use the account, and another to execute the transaction's intended actions. This change primarily solves the programmable account problem, allowing for the integration of various verification rules within the accounts. As an example, just as the developer implemented predefined checks in the Multi-Signature contract discussed in the previous section, users can now encode similar rules for their own accounts. For instance, users could create contract accounts with rules to prevent transactions over a certain amount within a specific time frame. If such a transaction is attempted, network nodes would reject it. Contract accounts could also be set to perform specific actions after each transaction, like automatically donating to Gitcoin. Additionally, these accounts would enable native multi-signature features and social recovery options, improving security and user experience. However, even further modifications to the EVM would be needed to fully address the challenges of executing multiple actions in a single transaction and enabling one user to pay for another's transaction fees.

ERC-4337

How to Fix the System

There have been a number of EIPs that have been proposed to guide this process. Vitalik gave a detailed overview of the history and development of account abstraction in Ethereum, including the early ideas, various EIPs that were considered but not implemented, and where we stand today, in his presentation at ETH CC. For those interested in a deeper understanding of this journey, you can watch his presentation here.

This transition towards account abstraction is complex and requires thorough testing to ensure the network's stability. Considering Ethereum's crucial role in finance, art, and other sectors, any significant disruptions could have wide reaching impacts. The Ethereum Core Developers had been focusing on the successful implementation of the Merge, transitioning Ethereum to a proof of stake. Their current areas of focus includes scaling solutions like Proto-Danksharding and Danksharding, and other initiatives such as stateless clients and Verkle trees. The core devs are already operating at full capacity and face challenges in managing the additional workload required for implementing account abstraction.

With that in mind, the Ethereum community introduced ERC-4337, a standard that is already operational on the network. This standard enables the benefits of account abstraction immediately, without requiring modifications to the EVM. It does so by introducing a "user intent layer" that works upstream of the current transaction process. This layer, coupled with a new set of standards to follow and a new entry point smart contract (I'll explain this contract in detail later), brings the benefits of account abstraction to Ethereum without modifying the underlying protocol.

Layer 2 solutions are actively exploring account abstraction as well. For example, zkSync has already integrated account abstraction into their protocol. Ethereum's modular roadmap allows for Layer 2s to experiment with modifying the EVM without permission from the base layer. Additionally, other proposals suggest incorporating a different account abstraction architecture into various Layer 2 solutions. As these solutions mature and demonstrate their security and effectiveness, they present a model that could be adopted by Ethereum Mainnet in the future. Meanwhile, ERC-4337 serves as a crucial intermediary, providing the immediate benefits of account abstraction.

ERC-4337 Components

Although the EVM remains unchanged, ERC-4337 adds new elements to Ethereum, changing how transactions are created and handled. Let's break down these components:

• User Operations (UserOps): Similar to transactions, UserOps are objects that represent what a user wants to do. They're structured with fields like sender, nonce (for anti-replay and salt in first-time account creation), initCode (for deploying the smart account if it doesn't exist), callData (the execution data), gas limits for different phases, fees, paymaster data (for gas fee sponsorship), and the signature.

• Bundlers: They are nodes that collect, simulate, bundle, and submit UserOps onchain. Currently, UserOps are sent directly to bundlers, but future plans include gathering them from a specialized mempool. Bundlers simulate these operations to make sure they will be valid onchain, bundle, and send them as a single transaction to the EntryPoint Contract.

• EntryPoint Contract: This contract handles the bundled UserOps. It verifies each UserOp, ensuring the smart accounts involved meet the required conditions. Successful verification leads to the execution phase. The EntryPoint Contract also manages gas use and compensates bundlers, as they cover the initial gas costs from their accounts.

• Account Contracts (Smart Accounts): These are user owned smart contract wallets. Wallet developers must implement functions in these contracts for verification and processing transactions.

• Factory Contract: Used in setting up new wallets. It uses the initCode from a UserOp to create the wallet, using the CREATE2 opcode for predictable addresses.

• Paymaster Contracts: Optional contracts that can sponsor transaction fees for Account Contracts, allowing fees to be paid in ERC-20 tokens or for free rather than ETH.

• Aggregator Contract: Designed to lower Layer 2 costs by verifying multiple UserOps with a single BLS signature, thus reducing data size. No aggregator contracts are in production yet.

The EntryPoint contract is central to ERC-4337. There's a single, official version of this contract used across all EVM chains. If there needs to be any changes to it, a new contract has to be deployed. The current EntryPoint contract can be found at the address 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789. While the EntryPoint contract remains consistent, other contracts like smart accounts, Paymasters, and Factorys offer flexibility for customization. Developers can tailor these contracts to their specific requirements, provided they follow the guidelines of ERC-4337.

In the next part of the post, we'll explore the lifecycle of a UserOp under ERC-4337, from the initial setup of a new smart account to the detailed process of verifying and executing a UserOp. This walkthrough will cover multiple scenarios including one where gas costs are sponsored by a paymaster. We'll dive into the functions and interactions of key components in this system: the EntryPoint, Smart Account, Paymaster, and Factory.

I recommend pulling up the Ethereum Foundation's repository related to ERC-4337 as you read along. It's available here and features sample contracts like SimpleAccount.sol, EntryPoint.sol, DepositPaymaster.sol, TokenPaymaster.sol, and SimpleAccountFactory.sol. Reviewing these contracts while I walkthrough the examples will really help with your understand of the ERC-4337 framework's mechanisms and interactions.

The examples we're going to cover, utilize sample contracts provided by the Ethereum Foundation and Biconomy, to service as an example of specific instances of how ERC-4337 can be implemented. However, it's important to understand that both smart accounts and paymasters in ERC-4337 offer a high degree of customization. They are not limited to predefined structures or functionalities but can be tailored to meet diverse verification and execution requirements.
In these simple examples, the smart account will have just one owner, whose signing key is an EOA verified using ECDSA with the secp256k1 curve. There will also be no special modules (I'll explain what modules are later), it will solely execute the intended action in the UserOp and nothing more.

Deploying a Smart Account

In order to send a transaction from a smart account in ERC-4337 you actually have to have a smart account deployed. Your smart account wallet software will handle the setup details like potentially offering options like setting account owners and recovery agents. In our example, the smart account will only have one owner. To start the deployment process you'd interact with the wallet interface, where a UserOp is crafted, signed, and sent to a Bundler.

Before accepting a UserOp, bundlers verify its authenticity and viability. They use an RPC method called simulateValidation to simulate calling the EntryPoint contract. This validation ensures that the UserOp's signature is correct and that it can cover its fees. Invalid UserOps are dropped from the Bundler's mempool. Bundlers then aggregate multiple valid UserOps from its mempool and send them as a batch to the EntryPoint’s handleOps function, using their EOA. Since they are using their EOA, they have to pay the gas for this execution. They are later reimbursed for this gas cost, plus receive an additional fee, but it's important to note that they initially front the gas.

The initCode field of the UserOp is used for encoding deployment information of a new smart account. The first 20 bytes of initCode are the address of the Factory Contract this UserOp wants to use to deploy their smart account. If this field is not empty, the EntryPoint attempts to call out to this Factory Contract to begin the smart account deployment process. This contract's role is to deploy new Smart Accounts, using the CREATE2 opcode for predictable address generation. The Factory Contract stores the bytecode of the smart account as a state variable to assist in deployment. The Factory Contract using the CREATE2 opcode, inputs this bytecode, the owner's signer public address (in our case EOA), and an optional salt (which is the nonce in the UserOp) to deploy a new smart account. To ensure consistency, the wallet interface precomputes the new account's address and includes it in the UserOp's sender field. If the actual and precomputed addresses don't match, the UserOp is reverted. If the deployment was successful the EntryPoint will emit an AccountDeployed event.

Example UserOp for Smart Account Deployment:

{
  "sender": computedAddress, // Address of the new smart account, computed offline
  "nonce": 0, // For a new account, the nonce is an optional salt
  "callData": "", // Empty for deployment 
  "callGasLimit": 1000000, // Estimated gas limit for deployment 
  "verificationGasLimit": 50000, // Gas limit for verification process 
  "preVerificationGas": 21000, // Basic transaction gas cost 
  "maxFeePerGas": 1000000000000, // Current network gas price 
  "maxPriorityFeePerGas": 1e9, // 1 Gwei, example priority fee 
  "paymasterAndData": 0x0…, // Zero address if not using a paymaster 
  signature: "0xEOAOwnerSignature", // Signature from the account owner (offchain signing process) 
  "initCode": deploymentCode // Factory address and constructor arguments for the new account 
}

Bundlers use their EOAs to send UserOps to the EntryPoint and they need to be compensated for the gas used in that transaction and paid an additional fee for their services. This is paid by either the smart account or a sponsoring paymaster. Smart accounts or paymasters deposit ETH in the EntryPoint contract to cover these costs. If there's insufficient deposit ETH during execution, the EntryPoint withdraws the required amount from the respective contract (smart account or paymaster) and then compensates the Bundler. If at any stage, the contract lacks sufficient ETH to cover the fee, the UserOp is reverted.

The fee payment process for deploying a smart account works as follows:

• Direct ETH Transfer: By using the CREATE2 opcode's deterministic nature users can send ETH directly to this precomputed address before the actual smart account is deployed. Upon deployment, the smart account will already possess ETH, enabling the EntryPoint to withdraw the required amount from the smart account.

• Paymaster Sponsorship: The gas costs are funded by a paymaster. In this case, the paymaster's address and relevant information are specified in the paymasterAndData field. The paymaster contract has specific rules set up to determine whether it will sponsor gas for a particular smart account.

In our example, since there isn't a sponsoring paymaster involved, it would be necessary to precompute the address of the smart account beforehand and prefund it with some ETH. This prefunding is for covering the costs of the bundler's services. By doing so, when the smart account is deployed using CREATE2, it already has the necessary ETH balance. This allows the EntryPoint to directly use these funds to compensate the bundler for processing the transaction. From the user's perspective, the smart account wallet software will handles this technical process, often providing a straightforward option like a button to easily pre-fund their smart account.

Summary of Key Steps:

1. Prefunding the Smart Account: Before any actions, the smart account must be precomputed and pre-funded with ETH to cover the costs of the bundler's services.

2. Forming UserOps: UserOps are formed in the wallet interface to represent the intended actions for deploying the smart account, signed, and sent to Bundlers. 

3. Validation and Processing by Bundlers: Bundlers validate offchain the UserOps for authenticity and viability using an RPC method, and aggregate the valid UserOps. 

4. Sending UserOps to EntryPoint: The aggregated UserOps are sent to the EntryPoint contract’s handleOps function by the Bundlers using their EOAs. 

5. Deploying through Factory Contract: The initCode in UserOps directs the EntryPoint to use the Factory Contract, which use the CREATE2 opcode, to deploy new smart accounts. 

6. Precomputed Address Consistency Check: The EntryPoint checks the precomputed address in the UserOp against the actual deployed smart account address. A mismatch means the UserOp is reverted. 

7. Deployment Confirmation Event: The EntryPoint emits an AccountDeployed event upon successful deployment of the smart account. 

8. Gas Cost Management: Bundlers are reimbursed for their gas costs in processing and sending UserOps to the EntryPoint. This reimbursement is either from the smart account's funds or a paymaster's sponsorship. 

Verifying and Executing a UserOp From Smart Account

With a smart account deployed, let's explore the process of verifying and executing a UserOp from it. As an example, consider a scenario where you want to approve UniSwap to spend 0.01 WETH and then swap that 0.01 WETH for 20 DAI. From a user perspective, if you have 0.01 WETH in your smart account and sufficient ETH deposited in the EntryPoint to cover the gas fees, the process is straightforward. You simply click a button, sign the transaction with the EOA designated as the owner of your smart account in your wallet interface, and then wait for the UserOp to be processed. With just one click, you've both approved and swapped. You'll see your WETH gone and a new DAI balance in your smart account. There's a lot happening behind the scenes, so let's break it down.

Initially, the UserOp is formed by the application's frontend and the user's account abstraction wallet software. This object includes necessary details such as the smart account's address, nonce, calldata, gas limits, and the signature from the smart account's owner.

The UserOp might look like: 

{ 
  "sender": "0xSmartAccountAddress", 
  "nonce": 1, // Current nonce of the smart account 
  "callData": "0xEncodedToCallExecutebatchWithEncodedWETHAddressValueCallDataToCallApproveAndEncodedUniSwapAddressValueCallDataToCallSwap", // Encoded calldata to call the executeBatch function that will execute approve and swap operations 
  "callGasLimit": 500000,
  "verificationGasLimit": 50000,
  "preVerificationGas": 21000,
  "maxFeePerGas": 100000000000,
  "maxPriorityFeePerGas": 2000000000,
  "paymasterAndData": "0x0…", // No paymaster used (zero address) 
  "signature": "0xEOAOwnerSignature" // Signature from the EOA owner of the smart account 
}; 

From a high-level perspective, the callData is a bytes array that the smart account is set up to parse and decode. In our example it contains three items. The first item is to call the executeBatch function on the smart account. The next is to call the ERC20 contract, to approve UniSwap to spend 0.01 WETH. The last item is to execute a swap transaction on UniSwap, where 0.01 WETH is exchanged for DAI. The smart account, upon receiving this callData, first processes the approval transaction with the ERC20 token and then carries out the swap operation on UniSwap, ensuring that both actions are completed in the intended order within a single UserOp. We'll go through how this works in more detail later in this section.

Going back to our example, as before, the bundler uses an RPC method to call the simulateValidation function of the EntryPoint locally before sending the UserOp to the EntryPoint. This step again checks whether the signature on the UserOp is authentic and if the operation has the necessary funds to be executed. Upon passing the initial validation, along with other initial validation UserOps, the bundler sends the bundle to the handleOps function on the EntryPoint.

Verifying and executing a UserOp, begins with looping through the bundle of UserOps ensuring each UserOp has enough funds to cover its operation and passing its specific validation checks.

Initially, the system calculates the necessary prefund amount (an estimate of total amount the user needs to pay the bundler) for the UserOp. An internal function, _validateAccountPrepayment, then assesses whether the smart account associated with the UserOp has sufficient ETH deposited in the EntryPoint to cover the prefund amount. If the deposited ETH meets the required amount, the missingAccountFunds variable is set to zero. Otherwise, the function computes any shortfall and assigns this value to missingAccountFunds.

This step is followed by calling the validateUserOp function on the smart account. This function verifies that the call is made by the EntryPoint and validates the signature using the validateSignature method. In our case validateSignature checks if the signature (UserOp.Signature) originates from the EOA that owns the account. If the signature doesn't match, it returns SIG_VALIDATION_FAILED instead of causing a transaction failure.

The process also includes nonce verification to ensure transaction order and prevent replay attacks. If additional funds are needed to meet the prefund requirement, the function attempts to transfer the necessary ETH from the smart account to the EntryPoint. This step does not cause a revert in the case of insufficient funds in the smart account, as this is addressed subsequently in the EntryPoint.

After these validation checks, the EntryPoint rechecks if the smart account's deposit meets the prefund amount. If the deposit still falls short, despite the attempted top-up, the UserOp is reverted. This process ensures each UserOp is thoroughly vetted for both funding and authenticity before execution.

In the EntryPoint contract's handleOps function, each UserOp is individually processed. In typical smart contract scenarios, a revert would cause the entire transaction to fail and halt all subsequent actions. However, the handleOps function is designed differently for handling UserOps. Here, if a UserOp fails during the validation or execution phase, the contract captures this failure and proceeds to the next operation. This functionality is made possible through Solidity's try and catch blocks, allowing the system to isolate and manage individual failures without impacting other operations.

Once the UserOps have passed the validation phase, they move into the execution phase. This phase involves looping through the array of verified UserOps and calling the EntryPoint’s _executeUserOp function for each one. A critical function within this phase is innerHandleOp, which executes a low-level call to the Smart Account, using the callData provided in the UserOp. The callData dictates which functions to execute and their respective inputs. In our specific scenario, it is encoded to call our executeBatch function with the following inputs:

• dest: An array of addresses (the WETH and UniSwap addresses)

• value: an empty array

• func: an array that calls the approve function to permit UniSwap to spend 0.01 WETH, followed by the swap function to exchange 0.01 WETH for DAI.

The executeBatch function starts by ensuring that the call originates from the EntryPoint or the account owner. It then verifies the alignment of the lengths of the destination addresses (dest), values (value), and function calls and inputs (func). Then the function makes calls to the specified smart contracts. This function appears as follows:

function executeBatch(address[] calldata dest, uint256[] calldata value, bytes[] calldata func) external {
        _requireFromEntryPointOrOwner();
        require(dest.length == func.length && (value.length == 0 || value.length == func.length), "wrong array lengths");
        if (value.length == 0) {
            for (uint256 i = 0; i < dest.length; i++) {
                _call(dest[i], 0, func[i]);
            }
        } else {
            for (uint256 i = 0; i < dest.length; i++) {
                _call(dest[i], value[i], func[i]);
            }
        }
    }

In our example, the smart account executes two specific transactions:

1. Approving UniSwap to Spend 0.01 WETH on the DAI contract

2. Swapping 0.01 WETH for 20 DAI on the UniSwap contract

As the EntryPoint contract processes each of these UserOps, it keeps track of the gas consumed for each operation. This tracking includes all UserOps, whether they are executed successfully or end up reverting. The EntryPoint contract also keeps an up to date record of the deposit amounts for each involved smart account and any paymaster contracts. Once all UserOps in the batch are processed, the EntryPoint contract concludes the operation with the _compensate function. This function takes the total gas used for processing the entire batch of UserOps and transfers this amount from the EntryPoint to the Bundler.

Summary of Key Steps:

1. UserOp Formation: The application's frontend and the user's account abstraction wallet create the UserOp, including essential details like the smart account's address, nonce, calldata, gas limits, and owner's signature. 

2. Validation by Bundler: Using the RPC method simulateValidation, the bundler locally authenticates the signature and ensure the UserOp is funded. 

3. Bundler Sends to EntryPoint: After initial validation, the bundler sends the UserOp batch to the EntryPoint's handleOps function. 

4. Prefund Assessment: The EntryPoint calculates the necessary prefund for the UserOp and checks if the smart account has sufficient deposited ETH. 

5. Signature and Nonce Verification: The EntryPoint validates the signature and nonce of the UserOp, ensuring authenticity and preventing replay attacks. 

6. Funding Shortfall Check: If additional funds are needed, the EntryPoint attempts to transfer the required ETH from the smart account. 

7. UserOp Processing: Each UserOp is individually processed in the EntryPoint, isolating failures and allowing continuous operation through try and catch blocks. 

8. Execution Phase: The EntryPoint loops through verified UserOps, executing each one using the executeBatch function. 

9. Specific Transactions Execution: The smart account executes the intended transactions, like approving and swapping. 

10. Bundler Refunded : Bundlers are reimbursed for their gas costs in processing and sending UserOps to the EntryPoint from the smart account's deposit in the EntryPoint

Using a Paymaster To Pay For Gas

In this scenario, we explore how a paymaster can sponsor the gas fees required for minting an NFT. This allows users to mint NFTs without paying any gas fees. The process from the users standpoint is straightforward: users click a mint button, and the transaction is processed with the gas fees covered by the paymaster.

The journey begins with the user's account abstraction wallet and the application's frontend collaborating to create a UserOp. This UserOp contains essential information such as the smart account's address, the current nonce, and the encoded instructions for the NFT minting operation. Additionally, it includes a field, paymasterAndData, which carries details about the paymaster responsible for the gas fees.

An example UserOp for NFT minting might look like this:

{
  "sender": "0xSmartAccountAddress", 
  "nonce": 2,
  "callData": "0xEncodedToCallExecuteWithEncodedMintNFTContractAddressAndMintFunction", // Encoded calldata to call execute with the NFT address and minting operation
  "callGasLimit": 500000, 
  "verificationGasLimit": 50000,
  "preVerificationGas: 21000,
  "maxFeePerGas": 100000000000,
  "maxPriorityFeePerGas": 2000000000,
  "paymasterAndData": "0xPaymasterAddressEncodedValidUntilValidAfterSignature", // Paymaster info, including address, timestamps, and signature
  "signature": "0xEOAOwnerSignature"
};

The paymasterAndData contains the paymaster's address and additional data like valid timestamps and a signature. This signature, generated offchain by a service trusted by the paymaster, confirms the agreement to sponsor this operation. The valid timestamps in paymasterAndData indicate when the operation is permitted.

The UserOp is sent to a bundler, which verifies the operation's authenticity and the paymaster's commitment to cover the fees. After passing validation, the UserOp is bundled with others and sent to the EntryPoint's handleOps function.

It begins with the _validateAccountPrepayment function to determine if the user's ETH deposit in the EntryPoint or the use of a paymaster is sufficient for the required prepayment amount. Since a paymaster is utilized in this case, no additional transfer of ETH is needed from the user's account. The procedure then advances to the signature and nonce verification phase. This involves the use of the validateUserOp function on the smart account, which verifies the origin of the call from the EntryPoint, confirms the matching of the signature to the smart account’s owner, checks the nonce, and assesses if any extra ETH transfer is necessary. In this scenario, the presence of the paymaster eliminates the need for an additional transfer. 

Next, the handleOps function extracts the paymaster's address from the paymasterAndData field, which comprises the initial 20 bytes. If the paymaster is not set to the zero address, the _validatePaymasterPrepayment function is internally called. This function checks the sufficiency of the Paymaster's ETH deposit for the prepayment amount. If the paymaster's deposit is insufficient, the UserOp is immediately reverted.

After that, the EntryPoint calls the validatePaymasterUserOp function on the paymaster. This function's primary role is to validate the eligibility of a UserOperation for gas fee sponsorship by the paymaster. It begins by parsing the paymasterAndData field of the UserOp to extract validUntil and validAfter timestamps and a signature. A unique hash is created from the contents of the UserOp, including these timestamps. This hash is then used in Ethereum's standard message signing process, and ECDSA recovery is used to ensure that the provided signature matches the paymaster's owner. If the signatures do not match, indicating a lack of authorization by the paymaster, the function returns a SIG_VALIDATION_FAILED error, indicating that the operation cannot proceed under this paymaster's sponsorship. This function returns a context, an empty string in this scenario, which doesn't play a role currently but will in the next scenario, along with the paymaster's details.

Assuming the UserOp passes the paymaster's validation, the handleOps function proceeds to the execution stage. It follows similar steps to the previous example by calling into the smart account, which then interacts with the NFT contract to mint the NFT. The difference in this scenario is that the callData is now encoded to call the smart account's execute function rather than executeBatch, as there's only one operation to execute: the minting of the NFT.

Finally, the handleOps function concludes by compensating the bundler for the gas used in the process.

Summary of Key Steps:

1. UserOp Formation: The account abstraction wallet and application frontend collaborate to create a UserOp, containing the smart account's address, nonce, encoded NFT minting instructions, paymasterAndData details, etc. 

2. UserOp Verification by Bundler: The bundler locally verifies the authenticity and viability of the UserOp. 

3. Bundler Submission to EntryPoint: After local validation, the bundler sends the UserOp to the EntryPoint contract's handleOps function. 

4. Signature and Nonce Verification: The validateUserOp function on the smart account verifies that the signature matches the smart account's owner, and the nonce is unique.

5. Paymaster Verification: The EntryPoint extracts the paymaster's address from paymasterAndData and validates the paymaster's deposit is sufficient through the _validatePaymasterPrepayment function.

6. Paymaster UserOp Authorization: The EntryPoint calls the validatePaymasterUserOp function on the paymaster contract to confirm sponsorship eligibility for the UserOp.

7. Execution of NFT Minting: Assuming successful validation, the EntryPoint contract calls the smart account's execute function, which interacts with the NFT contract to mint the NFT. 

8. Compensation of Bundler: After successful execution, the EntryPoint concludes by compensating the bundler for the gas used in processing the transaction.

Paymaster Allowing Users To Pay With ERC-20s

In contrast to the previous examples where transactions were funded using ETH or covered for free by the paymaster, this scenario explores a paymaster setup that allows users to pay for gas with ERC-20 tokens.

Here's a high-level overview of how this differs from previous methods: 

1. ERC-20 Token Charge for Gas: Users pay for gas in ERC-20 tokens, calculated based on the ETH equivalent of the gas cost plus any markup by the paymaster.

2. ETH Deposit Maintenance by Paymaster: The paymaster maintains an ETH deposit in the EntryPoint contract to cover actual gas costs, despite accepting ERC-20 tokens from users.

3. Batched Transaction Process (Approve Paymaster): 

   1. Initially, users approve the paymaster to spend their ERC-20 tokens. This approval is necessary for the paymaster to subsequently transfer the tokens from the user's account. 

   2. Following the approval, the next transactions in the batch execute the user's intended onchain activities.

4. Token Amount Calculation, Balance Check, and Context Returned in _validatePaymasterUserOp: 

   1. Following signature verification, this function determines the required ERC-20 token amount to cover gas fees, considering necessary ETH prepayment and additional charges

   2. It checks if the user's account has enough of the ERC-20 token (fee token) to cover the calculated charge.

   3. Returns a Context with essential transaction details, including the required token amount.

5. Post-Operation (postOp) Processing on Paymaster including Fee Transfer: 

   1. The function begins by decoding the context. It extracts key data such as the user's account, the fee token, and pricing details. 

   2. Next, it calculates the effective exchange rate for converting the gas costs to fee tokens, which is done using either the data provided in the context or by fetching new data from an oracle aggregator. 

   3. Following this, the function calculates the charge amount. This involves converting the actual gas cost into the equivalent amount in fee tokens and then applying the price markup. 

   4. Finally, the function transfers the calculated charge from the user's account to the designated fee receiver.

It's important to note that the approach described above reflects Biconomy's specific implementation of a token paymaster. However, paymaster contracts can be tailored to a developer's requirements as long as they comply with ERC-4337 standards, offering various levels of customization in terms of how fees are calculated, processed, and collected.

Customization and Flexibility in ERC-4337

Smart Accounts

In ERC-4337, each smart account is required to include the validateUserOp function. Developers have the flexibility to implement various types of verification logic within this function, depending on their specific requirements. The validateUserOp function should either confirm successful verification by returning a '0' or to indicate a failure in the verification process by returning a specific error reason, such as SIG_VALIDATION_FAILED, to the EntryPoint.

Following the verification process, if a UserOp is successfully validated, the smart account is then responsible for executing the actions specified in the UserOp's callData. Additionally, developers can program the smart account to perform other actions during the execution phase.

Advanced Functionality in Smart Accounts

Smart accounts in ERC-4337 can incorporate a variety of advanced functionalities that extend beyond basic transaction validation and execution. These advanced functionalities, referred to as modules, can be easily integrated into smart accounts. I will cover these modules in detail in a later section, where I discuss an ERC that proposes a standardization for them.

One such module is the use of session keys, which allow users to temporarily delegate transaction signing authority for specific activities, like granting a game permission to sign on their behalf for a set period. Another intriguing module is the implementation of subscription models. Users can program their smart accounts to handle recurring payments, such as a monthly subscription fee to services like Netflix where Netflix can pull x amount of coins per month and no more. For financial management and security, smart accounts can also enforce spending limits. Users can set a cap on the amount of money or value of assets that can be transacted monthly, providing control over their financial activities. Asset protection is another vital module. Users can set rules in their smart accounts to safeguard valuable assets. Any transaction attempting to transfer these protected assets, like a Pudgy Penguin NFT, would be automatically reverted. Additionally, role based access control in smart accounts allows for the creation of specific roles with defined permissions for specific signing key holders. For example, a role can be established for trading on a particular UniSwap pair with restrictions on the percentage of profits the key holder can access.

You might be wondering, can't these features already be implemented with EOA meta-transactions or pre-approved batch signatures? The answer is yes, but there are distinct advantages to using smart account modules. These modules enable onchain verification of conditions and allow for the simultaneous use of multiple relayers. In contrast, other methods might require giving up control of your EOA private key or relying on a second party's countersignature, which introduces potential risks of censorship or denial-of-service issues.

Paymasters

Paymasters in ERC-4337 are required to have a validatePaymasterUserOp function, to authorize users to use the paymaster. Additionally, they may include a postOp function to manage tasks after the operation, such as transferring ERC-20 fee tokens from the user or refilling the EntryPoint contract with ETH.

The design of paymasters allows for customized fee sponsorship. Developers can create paymasters that cover transaction fees in exchange for ERC-20 tokens, offer free transactions under certain conditions, or implement tiered fee structures based on user behavior. This flexibility enables the development of various business models within the Ethereum ecosystem.

For instance, paymasters can offer transaction fee discounts for specific token holders, or create loyalty based fee coverage programs. They can also adapt to dynamic pricing models that respond to market conditions or user engagement, providing innovative ways to manage transaction fees.

Social Recovery and Multi-Signature Smart Accounts

Social recovery in smart accounts introduces a user friendly approach to account recovery, mitigating the risks associated with traditional methods like relying solely on a seed phrase. Users appoint trusted contacts such as friends, family members, or trusted institutions as recovery agents within their smart account. This setup eliminates the worry of losing access to assets due to lost or forgotten seed phrases.

The recovery process operates on a consensus model. For account recovery to be initiated, a majority or a predefined number of these appointed agents must agree and provide their signatures, effectively authorizing the recovery action. This approach ensures that recovery is not solely dependent on a single individual's decision.

Smart accounts offer the flexibility to set specific criteria or conditions for recovery activation. These could include time delays, location based triggers, or other predetermined conditions, adding a layer of control and customization to the recovery process.  Smart account wallets should offer users straightforward options to select their recovery agents and define the conditions for account recovery. 

Similar to Gnosis Safes but now, these multi-signature smart accounts are treated as first class citizens, eliminating the worry of them being a pain to work with. These accounts requires multiple signatures from a predefined group of addresses for a UserOp to be executed. It's particularly beneficial for organizations or joint accounts where consensus is needed for transactions or just to beef up your security. This collective authorization approach enhances security by distributing control, making unauthorized access more difficult.

Diverse Validation (Signing) Methods

Before the introduction of ERC-4337, verifying the authenticity of a transaction required signing an EOA using the ECDSA on the secp256k1 curve. Now, you have the flexibility to sign your transaction using any method you prefer, enhancing security, user experience, and aligning with various use cases. These validation methods can even be plugged in as modules to your smart account after it's already deployed. Some examples include:

Passkey-Based Systems with Secure Enclave Integration: Utilizing biometric features like Face ID or fingerprints, this method enables transactions to be signed through biometric authentication. By generating cryptographic signatures within a device's secure enclave, triggered by biometric authentication, this method significantly reduces the exposure of private keys. This ensures that the key material never leaves the secure hardware, providing a robust layer of security against external threats. A key distinction is that passkeys utilize ECDSA on the secp256r1 curve. In your smart account's validateUserOp function, a prewritten function can now be used to verify signatures made with this method. I will cover passkeys in detail in a later section about an EIP that proposes a new precompile aimed at reducing the gas cost for verifying the secp256r1 curve used by passkeys.

MPC (Multi-Party Computation): Enables multiple parties, each holding a portion of private data, to collaboratively compute a function without disclosing their individual inputs. In the context of account abstraction, MPC is used for the secure generation and management of signing keys. The private key in MPC is divided and distributed among various parties, and these shares are combined to create a complete signing key only when authorized. There are various MPC providers, differing in the number of nodes holding a key shard, cryptographic methods for key recreation, and authorization options for key recreation. Some providers allow users to authorize the recreation of their key for transaction signing through methods like email verification with a magic link or by signing in with an OAuth-enabled web2 provider such as Gmail, Facebook, or Twitter.

Quantum-Resistant Algorithms: With advancements in quantum computing, there is a growing need for quantum-resistant cryptographic algorithms. These algorithms are designed to be secure against the potential future threat of quantum computers, providing a more forward looking approach to transaction signing.

Aggregator Contract

When users transact on a Layer 2, they incur a gas fee. This fee is composed of two parts: the cost to execute the transaction itself and the cost to post transaction data back to Mainnet. The latter represents the bulk of the expenses, accounting for approximately 95% of the total fee charged to users. As Mainnet continues to upgrade, incorporating features like Proto-Danksharding, a solution for more efficient temporary data posting, and Danksharding, which enables nodes to verify complete data submission through probabilistic checks, we can expect these data posting costs to decrease. Nevertheless, the aim is to further reduce Layer 2 costs.

ERC-4337 introduces an approach to alleviate this by minimizing the amount of data Layer 2 networks need to post when using ERC-4337. It leverages an Aggregator Contract, which effectively handles verifying multiple UserOps. Traditionally, each UserOp would require its own signature, often around 65 bytes or more, contributing significantly to the data footprint and, consequently, the cost. However, the Aggregator Contract simplifies this process by removing the need to include a signature field in each UserOp. Instead, the aggregator contract collects a batch of transactions and validates them with a single, combined signature using BLS cryptography. This BLS signature is considerably shorter than the cumulative total of individual UserOp signatures. Since Layer 2 networks pay Mainnet to post this data, the aggregation of signatures into a single, concise BLS signature translates into substantial savings.

To utilize this feature, bundlers have an extra responsibility. They must collect the individual signatures from various user operations and merge them into a single BLS signature. Following this step, they can compile multiple sets of aggregated user operations, with each set bearing one BLS signature. However, instead of using the standard handleOps function on the EntryPoint contract, they must call a different function called handleAggregatedOps designed for this purpose.

The rest of the process largely mirrors the standard ERC-4337 process, with a notable difference during the verification stage. During this phase, instead of contacting each user's smart account one by one for validation, the system consults the aggregator contract specified in the UserOpsPerAggregator struct. The aggregator contract, then, verifies the batch of transactions collectively, which streamlines the operation.

The Future

EIP-7212: Implementing WebAuthn Standards in Ethereum

WebAuthn, developed by the FIDO Alliance and the World Wide Web Consortium (W3C), is a web standard for secure, passwordless authentication. It enables users to log in to websites with biometrics, mobile devices, or FIDO security keys, enhancing security and simplifying the login process. During registration, a user's device generates a public-private key pair, similar to creating an Ethereum EOA, with the public key sent to the website's server and the private key retained securely on the device. For login, the website requests authentication, and the device signs a challenge with the private key, proving identity without a password.

Passkeys are a user authentication method based on the WebAuthn standard. One place to store them when using an Apple device is using iCloud Keychain. When a user signs in via iCloud, it becomes possible to recover their Passkeys. However, while iCloud Keychain is secure, it doesn't offer hardware-level security. The private key is briefly copied in plain text into the system memory, creating a potential attack surface. If an app is compromised, there's a risk to the key. Alternatively, Passkeys can be secured using the iPhone's Secure Enclave, an isolated microchip within Apple's chips designed for secure data and operations. The private key is securely generated and stored in the Secure Enclave, ensuring it never leaves the hardware. This means that using biometrics to access a Passkey stored in the Secure Enclave offers maximum safety, though it trades off ease of recovery.

You might be thinking, "This sounds great, we can use the Secure Enclave to hold our Passkeys, authenticate them with Face ID, and then sign transactions using a passkey, which are verified by an account abstraction wallet." However, it's not that simple. When I mentioned, "During registration, a user's device generates a public-private key pair, similar to creating an Ethereum EOA," I used the word 'similar' intentionally. It's a comparable process but not exactly the same. You might not recall, but earlier in this post, I mentioned that Ethereum, like Bitcoin, uses the ECDSA with the secp256k1 elliptic curve to generate its public-private key pairs. In contrast, the WebAuthn standard employs a different elliptic curve, known as secp256r1, for generating its public-private key pairs.

A problem arises because verifying signatures on the secp256k1 curve is one of the nine precompiled contracts in the EVM, but this isn't the case for the secp256r1 curve. A precompiled contract is a special type of contract, integrated directly into the EVM, instead of being user written and deployed. These contracts offer cheaper gas costing functions for specific operations than if the same functionalities were executed through smart contracts. Among these is the ecrecover function. It processes the signature and the message to return the signer's address. However, ecrecover is compatible only with the secp256k1 curve and not the secp256r1, which is used in passkeys. Being a precompiled contract, the cost of using ecrecover is relatively low, at about 3k gas.

EIP-7212 proposes making the verification of signatures on the secp256r1 curve as efficient as on the secp256k1 curve by incorporating it into a precompiled contract. Initially, the Clave team, who co-authored the EIP, found that using Solidity for verifying keys on the secp256r1 curve cost around 400k gas. Optimizations later reduced this to roughly 70k gas. However, it's important to note that each public key requires its unique set of pre-computed data, tailored to its mathematical properties, to optimize signature verification. Thus, the pre-computation and deployment are specific to each key. To verify signatures from a different public key, new pre-computation and a new contract deployment are necessary, which is notably gas intensive, costing about 3.2 million gas. For a deeper understanding of the need for pre-compilation and redeployment, I recommend listening to the Web3 Galaxy Brain episode featuring the Daimo Team, the other half of the EIP-7212 authors, available here. Alternative methods for verifying signatures on the secp256r1 curve exist, including SNARK-based approaches and various Solidity implementations. Nonetheless, the overarching issue remains the same: verifying signatures on the secp256r1 curve within the EVM is highly gas consuming, and EIP-7212 aims to make it as cost effective as verifying signatures on the secp256k1 curve.

The EIP seems like an obvious choice to include in the protocol, and guest after guest on Web3 Galaxy Brain seem to agree. If we're aiming for a web2-like user experience, making signature verification for biometric keys as affordable as for EOAs is essential. However, Vitalik has expressed caution about adding new precompiled contracts. In his blog post titled “Should Ethereum be okay with enshrining more things in the protocol?”. He pointed out that previous precompiles, like RIPEMD and BLAKE, haven't been used as much as expected, suggesting we should learn from that. Whether this EIP will be included in the protocol remains uncertain, but it's definitely one to watch closely.

ERC-6900: Modular Smart Contract Accounts and Modules

As you now know, if you’ve made it this far, ERC-4337 introduces custom logic in the validation and execution stages of a transaction. It features modules like session keys, subscriptions, spending limits, and role-based access control. Currently, these modules vary across different smart account providers, creating uncertainty about module compatibility and potential duplication of development efforts. For example, imagine this situation: You visit Alchemy’s smart account interface and set up your new smart account. You also install a module from Alchemy that restricts you from spending more than 10 ETH in a single transaction. Later, you decide to try the Obvious Wallet interface to interact with your smart account, similar to how you might export your private key from Metamask to Rainbow for EOAs. However, when you use the Obvious Wallet interface to access your smart account, you find that the module you installed with Alchemy doesn’t work, and you can spend over 10 ETH in a transaction. This is because Obvious Wallet doesn’t recognize the module from Alchemy. Right now, if you're a developer wanting to create modules, you either get locked into developing for one wallet interface or you have to make separate modules with the same functionality, each compatible with a different wallet interface.

ERC-6900 aims to standardize these modules, simplifying the creation and management of them for developers. This would lead to a more streamlined user experience, as developers could create modules usable across any compliant smart account interface, reducing their workload and enhancing data portability. The standard splits the smart account into more modular components. At its base, the smart account remains simple, but users can add modules to enhance functionality. These modules come in three types:

• Validation Functions: Check whether the person or entity trying to use the smart account is authorized to do so

• Execution Functions: The core functions that dictate what the smart account actually does when it's used

• Hooks: Additional pieces of logic that execute before or after the validation or execution functions

Typically, smart accounts are accessed through the EntryPoint contract, though this isn't the only method. Owners of smart accounts, whether they are EOAs or other smart contracts, have the option to bypass the validateUserOp function. They can choose to directly invoke functions for executing transactions onchain. ERC-6900 is designed to support both these access methods. As a result, it defines more specific categories of validation functions, execution functions, and hooks to cater to these varied approaches. The diagram below illustrates all these specific types of functions. Following the diagram, I will provide a detailed definition of each, along with multiple examples to demonstrate their use and functionality:

• User Operation Validation Functions: Handle the validation of user operations in smart contract accounts. They are the main validators for ensuring the transaction complies with the contract's rules.

  • Examples: 

    • Passkey Secured Account: A User Operation Validation Function confirms the correct passkey for each transaction.

    • DeFi Credit: A function checks transaction criteria for Buy Now Pay Later services.

• Runtime Validation Functions: Executed just before the main execution step of a modular account function, particularly for calls that are not made through a UserOp (like direct smart contract interactions).

  • Example: 

    • Check whether the caller trying to modify important settings is indeed the account owner or a designated admin. If the caller is not authorized, the function would prevent the execution of the update.

    • Virtual Cold Storage feature: A Runtime Validation Function could verify high security measures (like 2FA or multi-sig) are met before allowing transactions with certain assets

• Execution Function: Defines the main execution step of a function for a modular account.

  • Example:

    • A function that performs a token transfer from the smart contract account to another address.

    • Dollar-Cost Averaging: The Execution Function would periodically execute buy orders for a specified cryptocurrency, following a user defined investment strategy.

• Pre User Operation Validation Hook Functions: Run before the main user operation validation functions. They are used for setting preconditions or carrying out initial assessments that might impact the validation process.

  • Example: 

    • Daily Transaction Limit: Checks whether the total value of transactions initiated from the account on that day has already reached the preset limit.

    • Timed Unlock: Verifies if the current date surpasses a predefined unlock date

• Pre Runtime Validation Hook Functions: Executed before the runtime validation functions, setting up preliminary conditions or checks for the validation process.

  • Example: 

    • In automated trading, a function could check current market conditions or a "trading suspension" flag. If active, it prevents the trade execution

    • For an Exploit Detection system, a Pre Runtime Validation Hook Function might check real-time security alerts. If an exploit is detected in the protocol being interacted with, it blocks the transaction to protect the user.

• Pre Execution Hook Functions: Run just before the main execution step of a transaction or operation in a smart contract account. They can perform preliminary actions or computations and optionally pass data to post execution hooks.

  • Example:

    • In Crowdfunding: Check if the campaign has reached its funding goal before allowing a new contribution. If the goal is already met, the function might either reject the transaction or redirect the funds to a different function. 

    • Automated Token Trading: A function that analyzes market conditions using external oracles before execution.

• Post Execution Hook Functions: Executed after the main execution step of a transaction or operation. They can handle cleanup, state resetting, or further processing based on the outcome of the execution and data received from pre execution hooks.

  • Example: 

    • In Crowdfunding: Responsible for sending a thank you message or a digital reward to the contributor after their contribution is successfully processed.

    • NFT Rental service: Handle the transfer of NFT access rights back to the owner after the rental period ends, ensuring the NFT is returned automatically.

These examples just scratch the surface of functionality developers can create using modules. For more inspiration, the Rhinestone team has compiled a list of ideas here. To understand the specific formatting requirements for modules, you can refer to the ERC documentation here. Keep in mind that this standard is still a work in progress. Modular account abstraction teams are actively refining the specifications, so it's important to stay updated with the latest information online.

Biconomy and Rhinestone are launching the Module Store, an app store for modules, backed by the Rhinestone Protocol. This protocol facilitates the lifecycle of smart account modules, from development to installation and monetization. The Module Store aims to ensure interoperability, security, and ease of use for modules. Starting in Q1 of 2024, all dapps and wallets built on Biconomy’s embedded smart account framework will have access to the Module Store. This marketplace will feature smart account modules, developed by various creators and secured by a network of auditors, offering a seamless plug-and-play solution for dapp developers. For further details on the store, you can read the announcement here.

Managing Smart Accounts Across Different Chains

In a future where Layer 2s are widely used and everyone has smart accounts, we encounter a significant challenge. If you wish to change the keys controlling your smart account on one L2, you currently have to repeat this process individually on each L2 you use. For example, if your smart account is managed by four EOAs and you decide to remove one, this change has to be implemented separately on each L2.

Vitalik’s Keystore Proposal

To solve this, Vitalik has suggested a Keystore Contract for each user, which could be located on either L1 or L2. This Keystore Contract would keep a record of your valid signing keys and the rules for changing them. Your smart account would then always reference the Keystore Contract to verify the current valid signing keys. Vitalik discusses various methods for this, including secure cross-chain message transmission, choosing the best proof methods, ensuring privacy, and more. For an in depth understanding, you can read his full post.

Module Solution

The Multichain Validation Module developed by Biconomy offers a solution for managing smart accounts across various blockchain networks and rollups. It allows for the authorization of multiple operations on different chains with a single user signature. This is achieved by using Merkle Trees to combine multiple UserOp hashes into one Merkle Root, which the user signs. This method enables actions such as deploying and configuring smart accounts on several chains or issuing session keys with different permissions across chains, using just one signature. The module employs a trust model similar to the general ERC-4337 flow, where users must trust the app generating the Merkle Root to not include any malicious UserOp hashes. For more.

ERC-1271: Verifying Signatures from Smart Contracts (Accounts)

There are times when a user signs a transaction offchain, and then someone else, like another user or a relayer, submits the signed message on behalf of the user onchain. For example, imagine a user wants to buy a specific Pudgy Penguin NFT for 3 ETH on OpenSea. They sign a message about this offer offchain and send it to OpenSea's servers. Later, when the owner of the Pudgy Penguin decides to accept this offer, they use the signed message and their signature to instruct the OpenSea contract to complete the purchase. Another scenario could involve a DeFi app offering gasless transactions for their users. In this case, users sign messages offchain for actions like trades or loan requests, then send these signed messages to the DeFi protocol's servers, which subsequently submits them to the blockchain, covering the gas fees. In both these situations, and others similar, the traditional method of handling signed messages onchain, before the introduction of ERC-1271, involved using the ecrecover precompile function in Solidity. ecrecover takes the signature and message and returns the signer's address. However, this method has its limitations, as it works only with transactions signed by EOAs and not with those originating from smart contracts (which is what smart accounts technically are).

ERC-1271 is a crucial standard for fully realizing the benefits of account abstraction. Although smart accounts are now first class citizens in the EVM with ERC-4337, this alone isn't sufficient if smart contract developers continue to use ecrecover for signature validation. Unlike EOAs, smart contracts don't have private keys and therefore can't create standard Ethereum signatures. ERC-1271 enables smart contracts to 'sign' data. ERC-1271 allows them to define their own criteria for what constitutes a valid signature. A smart contract following ERC-1271 includes a isValidSignature function. When another contract needs to confirm a signature claiming to be from a specific smart contract, they call its isValidSignature function inputting the data's hash and the signature. If the isValidSignature function deems the signature valid, it returns a special value, 0x1626ba7e. Otherwise, it should return a different value, such as 0xffffffff. This function contains custom logic to determine the validity of a given signature, which can vary based on the contract. For instance, a multi-signature contract might verify if the signature matches any of its approved signers. Or it could involve calling other functions within the contract, examining the contract's own state, or even interacting with external contracts to assess a signature's validity.

Let's revisit the OpenSea Pudgy Penguin example to clarify how this process works. Suppose a user has a smart account where Face-ID passkeys act as the signer. When this user decides to make an offer to buy a Pudgy Penguin NFT for 3 ETH, they create a commitment or instruction stating, "I agree to buy this NFT for 3 ETH." This commitment is signed using their Face ID and both the commitment and signature are submitted to OpenSea's servers. Later, when the current owner of the NFT decides to accept this offer, OpenSea begins processing the transaction. This involves interacting with the buyer's smart account. The smart account has an isValidSignature function, which is compliant with the ERC-1271 standard. This contract's isValidSignature function would be similar in functionality to ecrecover, but in this case, it would most likely call out to an external contract (or, perhaps by the time you're reading this, EIP-7212 has been implemented and there's a precompile to verify signatures made by passkeys), inputting the message and signature and outputting a public key. This external function would use ECDSA on the secp256r1 curve. If the output matches the public key stored in the smart account, it will return 0x1626ba7e, signaling that the signature is indeed valid. Once verified, OpenSea executes the transaction on the blockchain. This action transfers the NFT from the seller to the buyer and moves 3 ETH from the buyer's wallet to the seller.

Enshrining Account Abstraction

ERC-4337 offers a significant advancement in Ethereum's functionality, but it's not without its drawbacks. One of the main challenges is that existing users cannot seamlessly transition from their current EOAs to this new system. They would need to transfer all assets and activities from their EOAs to smart accoun. Additionally, using ERC-4337 costs more gas than the traditional method – approximately 42k for basic user actions, which is nearly double the 21k needed for standard transactions. It also reduces effectiveness of anti-censorship methods like crLists, depends on fewer nodes, and uses of unconventional methods such as eth_sendRawTransactionConditional. Another compatibility issue arises with tx.origin or contracts dependent on it, as ERC-4337 uses the address of a bundler. Given these considerations, it’s essential to explore different proposals and implementations that could integrate an account abstraction solution directly into the Ethereum protocol. In the following sections, we'll dives into these alternatives and their potential to enhance Ethereum's user experience.

RIP-7560: Integrating Account Abstraction into EVM-like Rollups

RIP stands for Rollup Improvement Proposal (yes, I know, we're not great at naming in Ethereumland, get used to it). It's different from EIPs in that RIPs propose upgrades specifically for EVM-like rollups. Rollups can more easily upgrade their protocol compared to Ethereum's base layer, which is stricter and undergoes extensive testing to minimize the risk of bugs. In a sense, rollups can use RIPs to 'test' new upgrades for Mainnet. Successful implementations on rollups might later be adopted by the base layer. This particular RIP, proposed by Vitalik and others, aims to integrate account abstraction directly into the protocol, rather than as an upstream layer like in ERC-4337. It addresses some issues with ERC-4337 while facilitating an easy transition from ERC-4337 to RIP-7560.

This proposal introduces a new transaction type, that looks similar to a User Operation, named AA_TX_TYPE. This type includes several fields, including chainId, sender, nonce, builderFee, callData, paymasterData, deployerData, maxPriorityFeePerGas, maxFeePerGas, validationGasLimit, paymasterGasLimit, callGasLimit, accessList, and signature. It also proposes a new approach to managing nonces for smart accounts with a two-dimensional system utilizing a key and a sequence value. The NonceManager, a dedicated contract, administers this system, tracking these nonces to ensure their correct application.

Here’s process for nonce verification:

1. Initiate a transaction from your smart account and select a key that categorizes the transaction.

2. Check the current sequence value for that key using the NonceManager. 

3. Submit your transaction with the chosen key and the next sequential value.

4. The NonceManager verifies if the sequence value is correct (the next in line for that key) and then increments it for subsequent transactions.

Here’s the flow to verify and execute a transaction:

1. Validation Phase:

   1. Nonce Validation and Increment: Updates the transaction count for an account.

   2. Sender Deployment: If it's the sender's first time, in this step a new smart account is deployed.

   3. Sender Validation: Ensures the transaction details are accurate and validates signature.

   4. Paymaster Validation (Optional): A paymaster, if involved, validates its role in the transaction.

2. Execution Phase: 

   1. Sender Execution: Carries out the planned actions of the transaction.

   2. Paymaster Post-Transaction (Optional): The paymaster, if part of the transaction, carries out any needed actions after the transaction is done.

This RIP, while currently not fully detailed in every aspect, is essentially a proposal to incorporate the advantages of account abstraction into a rollup. It aims for a smooth transition from the existing ERC-4337 standard. I only gave you a high-level overview here, not touching on every aspect of the RIP. To get a deeper understanding of the proposal, you can read the complete RIP at this GitHub link. For the most recent updates on this proposal, keep an eye on the discussion thread at the Ethereum Magicians forum, available here.

zkSync Native Implementation

zkSync is an EVM compatible Layer 2 rollup. Unlike EVM equivalent rollups that closely mirror the Mainnet EVM, zkSync made specific design choices that slightly modify their virtual machine. These adjustments not only make its bytecode more SNARK-friendly but also allow for the inclusion of features absent in Ethereum's base layer. One notable feature is the native implementation of account abstraction. zkSync has already integrated smart accounts and paymasters, similar to what we're familiar with, but built directly into its protocol.

Similar to RIP-7560, zkSync also had to come up with a method for verifying the nonces of smart accounts. Their solution allows users to select any 256-bit number as a nonce, with the stipulation that each nonce can be used only once. To enforce this, they utilize an external contract named the NonceHolder. For developers working with zkSync, it is recommended to adhere to the account and paymaster interfaces as specified by zkSync.

Accounts on zkSync are required to implement specific methods. Here's a breakdown of them and their functionality:

• validateTransaction: Used during the transaction's validation phase. It sets the rules for programmable verification of transactions. If a transaction fails these verification rules, this method must revert the transaction.

• payForTransaction or prepareForPaymaster:

  • payForTransaction: Used when a transaction does not involve a paymaster. Accounts should implement it to manage the transaction fees themselves.

  • prepareForPaymaster: Called when a transaction involves a paymaster. If it executes without reverting, the system proceeds to call the paymaster’s validateAndPayForPaymasterTransaction method, passing along the necessary data.

• executeTransaction: Executes the actual transaction as per the defined instructions.

• executeTransactionFromOutside (Optional, but Recommended): Allows external entities to initiate transactions from the account. This functionality is similar to the standard Ethereum model, where an EOA can initate transactions from a smart contract.

For paymasters, the following methods are necessary:

• validateAndPayForPaymasterTransaction: Used to determine whether the paymaster is willing to cover the costs of a specific transaction. If the paymaster agrees to pay, it must transfer an amount no less than tx.gasprice * tx.gasLimit to the operator. Additionally, the method should return a 'context', which is used by the postTransaction method, provided the latter is implemented.

• postTransaction (Optional): Called after the transaction has been executed. It's used for any additional logic or actions the paymaster may need to perform post-transaction. This could include steps like cleanup or bookkeeping.

Here's an explanation of each step in the transaction flow:

1. Validation Step:

   1. Nonce Check: The system first checks the transaction's nonce using the NonceHolder. It confirms the nonce hasn't been used before.

   2. validateTransaction Method: The system calls the validateTransaction method of the account involved to validate the signature. If this method does not revert, the process moves forward.

   3. Nonce Usage Verification: After the validation, the NonceManager marks the nonce as used, updating its status in the system.

   4. Fee Payment (Without Paymaster): For transactions that don't involve a paymaster, the payForTransaction method of the account is called to handle the transaction fees.

   5. Fee Payment (With Paymaster): If a paymaster is involved in the transaction, the system first calls the prepareForPaymaster method of the sender's account. If successful, the system then proceeds to call the validateAndPayForPaymasterTransaction method of the paymaster.

   6. Bootloader Fee Verification: The system checks whether the bootloader (responsible for transaction execution) has received the required transaction fees, calculated as tx.gasPrice * tx.gasLimit. If the fees are appropriately received, the transaction successfully passes the validation phase.

2. Execution Step:

   1. executeTransaction Method: The system executes the executeTransaction method of the account, which contains the actual logic of the transaction.

   2. Post-Transaction (With Paymaster): For transactions involving a paymaster, the postTransaction method of the paymaster is called. This step is typically used for refunding any unused gas to the sender, especially relevant when transaction fees are paid in ERC-20 tokens rather than ETH.

EIP-3074

EIP-3074 is still in the review phase and aims to introduce two new opcodes to the EVM that will allow smart contracts to send transactions in the context of an EOA. Essentially, this means that when these new opcodes are used, a smart contract can send a message or call another smart contract, and it will appear as if the message is coming from an EOA, not from the calling smart contract. This is a significant change because it means you don't need a smart contract account to perform these actions. You can simply use what's known as an invoker contract, which is a straightforward, secure type of smart contract that can execute transactions on behalf of your account. EIP-3074 doesn't create a new type of transaction, it simply adds two new opcodes to the EVM.

To illustrate how it works from a high level, here's a walkthrough of a simple example. In a ERC-20 contract, the transfer function might look like this:

function transfer(address _to, uint256 _value) public returns (bool success) {
  require(balances[msg.sender] >= _value);
  balances[msg.sender] -= _value;
  balances[_t0] += _value;
  balances[recipient] = _balances[recipient].add(amount);
  emit Transfer(msg.sender, _to, _value);
  return true;
}

With EIP-3074, you can sign a message from your EOA indicating a desire to transfer tokens. This signed message is sent onchain to your invoker contract. The invoker contract then executes the actions, which include calling the transfer function of the ERC-20 contract. Normally, msg.sender in the ERC-20 contract's transfer function would refer to the invoker contract. However, EIP-3074 changes this: msg.sender can be set to your EOA, even though the call to the ERC-20 contract is made by the invoker contract. This allows you to transfer tokens from your EOA by calling the ERC-20 contract through your invoker contract, changing the traditional understanding of msg.sender. Therefore, In this system users don't need to transfer assets out of their EOAs to take advantage of it.

The two new opcodes in EIP-3074 are AUTH and AUTHCALL. AUTH is used to set up a special kind of permission using a digital signature, specifically an ECDSA signature. This process establishes an authorized context in the EVM for a particular user account. To use AUTH, a signature and a hashed message, known as a commit, are required. The EVM uses this information to identify the signer of the message, and this signer's address is marked as authorized.

Following this, AUTHCALL comes into play. It allows transactions or messages to be sent as if they are coming from the authorized user account, not the smart contract that is actually initiating the action. It's similar to the call opcode, but it sets the authorized context address as the msg.sender. This is a major shift because it means that the actions look like they are coming from a regular user's EOA rather than from a smart contract. When another smart contract receives a message or transaction and checks the sender (using msg.sender), it sees the address of the authorized EOA, not the smart contract that made the call. This mechanism allows smart contracts, known as invokers, to perform actions that were previously exclusive to user accounts, allowing a lot of the benefits of account abstraction to be unlocked.

A basic flow to send one or more transactions looks like this:

Under the EIP-3074 system, who sends a transaction to a contract is not important as long as the signature from the EOA is valid. This flexibility allows a transaction to be sent by someone else or a different account, not just the account owner. However, it's important to note that currently, you can't use EIP-3074 to send ETH directly from an EOA. This limitation is due to the need to maintain certain key assumptions in the Ethereum network, like how a transaction's validity is determined. Instead, any ETH involved in these transactions comes from the balance of the invoker, the smart contract initiating the action. Although you can't directly send ETH from an EOA using EIP-3074, you can still transfer ETH to the invoker contract. The invoker can then use this ETH as needed for the transactions it handles. For more information, you can read the full EIP post here and follow the subsequent Ethereum Magicians discussion here.

Conclusion

Hopefully, you now have a solid understanding of Ethereum's accounts and transactions. We've looked at how they worked before ERC-4337, how they function with the adoption of ERC-4337, and what the future holds for account abstraction. It's been a challenging journey toward account abstraction. Sometimes, I wonder how the Ethereum user experience might have looked if Vitalik and the other founders had managed to launch Ethereum with built-in account abstraction, as they originally intended. Looking at zk-Sync's clean and straightforward in-protocol implementation of account abstraction, it's clear what could have been. However, the developers are already stretched thin, and I'm grateful for ERC-4337, despite its complexities, for bringing us the benefits of account abstraction today.

The development of Ethereum is thrilling to me, and I can't imagine dedicating my time to anything else. Just last year, Ethereum accomplished a monumental technological feat by transitioning from proof of work to proof of stake. Next year, the protocol is set to scale like never before, introducing a new dedicated temporary dataspace for rollups. This change will significantly reduce the cost of transactions on layer two. Meanwhile, the user experience is undergoing a major transformation. ERC-4337 is live, and now it's about building applications that leverage it. I'm excited for the next wave of users who won't have to worry about writing down 12 words on a piece of paper or needing to click multiple times just to swap tokens. A new era has arrived, and it's time to start building.

Part 1: How We Got Here

Ethereum was initially designed with the idea that a single party would handle the entire process of block creation. This entailed aggregating transactions from the mempool, crafting the block header, and either finding the golden nonce in proof of work or simply signing the block header in proof of stake. For its initial years, block building was straightforward: mining nodes pulled transactions from their mempool, ordered them based on gas price, which signifies the computational work of each transaction, and stayed within the gas limit per block. However, with the rise of decentralized finance (DeFi), this approach to block building has undergone significant changes.

The Centralizing Threat of MEV

In DeFi, the sequence in which transactions are ordered can make a big difference. Let's say there's a transaction waiting in the mempool that aims to swap 1 ETH for BITCOIN (I'm talking about HarryPotterObamaSonic10Inu, of course) on UniSwap. The amount of BITCOIN you'd receive is based on the current ETH to BITCOIN ratio in the UniSwap pool. If someone else’s transaction, swapping 2 ETH for BITCOIN, gets processed right before yours does, you'll end up with fewer BITCOIN because the ETH to BITCOIN ratio has changed. Given the significance of transaction order, and miners control this ordering, it led to the emergence of what we call MEV, or Miner/Maximal Extractable Value. MEV represents the potential profit a miner can make by choosing which transactions to include, exclude, or rearrange.

MEV might seem harmless at first. Heck, it could even appear as a booster for network security, more incentives for mining or validating, right? Besides the usual block rewards and transaction fees, now there's MEV up for grabs. But the reality is far from harmless. If left uncontrolled, MEV could become a potent centralizing force. Here's a story to illustrate this: Imagine you've just got wind of this MEV game and hear that validators are raking in more than 10% APR because of it. Tempting, right? You're all in! So, you send your 32 ETH to the staking contract and kick off a validator node. But wait a minute... You're only seeing a 4% return. When your turn to propose a block comes around, the transactions simply line up by their gas price. No MEV magic. You're not armed with the intricate algorithms and tactics to mine that MEV gold. Without the know-how, you're stuck with the default: ordering transactions by gas price.

Here's where the centralizing pull kicks in. Even if you're a quant, your simple computer, maybe a raspberry pi, doesn't hold a candle to their supercomputers running next level MEV extraction plays. The obvious end game here is to turn off your validator and instead send your ETH to these super powered setups that promise a share of the MEV pie. Fast forward, and you might see a handful of these behemoths essentially running the network, a truly unsettling centralized outcome. If this is where things head, then Ethereum's foundational goals have failed. A network dominated by a select few might as well be a centralized database at that point.

The Birth of Flashbots

Phil Daian, a Ph.D. student at Cornell with a specialization in smart contract security, was among the early identifiers of the MEV issue. In August 2017, he published a blog titled "The Cost of Decentralization in 0x and EtherDelta." This blog was inspired by the front-running vulnerabilities he identified during the 0x ICO.

Front-running involves spotting a transaction in the mempool that aims to swap Token A for Token B. A front-runner then programmatically initiates a similar transaction that offers a higher gas price. This strategy ensures that the front-runner's transaction is processed before the original one. After the initial transaction is processed, the front-runner can immediately trade Token B back for Token A, ending up with a larger quantity of Token A than they began with. This tactic is sometimes called a sandwich attack, as the user's transaction gets sandwiched between two transactions initiated by the front-runner. As a result, while the front-runner gains profit, the individual behind the original transaction receives less of Token B. While sandwich attacks are common, there are various strategies individuals can use to extract MEV effectively.

During the ICO boom, Phil and a team deployed a bot that earned about a million dollars annually. After sharing their methodology in the blog post I mentioned earlier, several similar bots emerged, creating a competitive landscape where bots would outbid each other's gas prices to achieve transaction priority. This prompted Phil to deploy nodes globally, capturing real time transactional data. This research culminated in his famous "Flash Boys 2.0" paper, which delved deep into the MEV challenges caused by decentralized exchanges.

Here's a fun related story Phil shared when he was a guest on the Chopping Block. When Hayden Adams, the founder of UniSwap, shared his design for what's now the most popular decentralized exchange on ethresear.ch. Phil immediately messaged his concerns to both Vitalik and Hayden. Phil believed that UniSwap's design would cause a significant amount of MEV, making it a prime target for exploitation and putting users at risk of transaction reordering and sandwich attacks. Vitalik responded suggesting that these could just be looked at as an additional fee mechanism to use the blockchain. Phil was so pissed at this response and he thought powerful financial entities like Goldman Sachs would come in and eat retails lunch just like the current financial system. However, with time, Phil has come around to Vitalik’s perspective (all praise lord Vitalik).

Recognizing the importance and challenges of the MEV space, Phil co-founded Flashbots, a company focused on research and solutions in the MEV arena. Flashbots realized that MEV is going to exist and Flashbots it’s mission to make sure that the existence of MEV doesn’t lead to a system where being a bad person or creating negative externalities is both better for you individually and is more profitable than being a good actor. An example of this is in TradFi, the most profitable strategies often involves exploiting the system's edges. Also Flashbots thought that there might be a way to harness the energy of MEV for the users and to subsidize people who secure the network and also to subsidize transactions on the network to get people better prices to give people the execution they want in these systems. If designed right, MEV could be part of what makes crypto outperform traditional systems.

Harnessing MEV: The Role of Auctions and Proposer-Builder Separation

Flashbots recognized that miners' monopoly over transaction ordering was a valuable resource. Their first step to democratizing MEV involved creating an auction system for transaction ordering rights. This led to the creation of MEV GETH, which first introduced the concept of proposer-builder separation (PBS). Ethereum Foundation's Barnabé Monnot describes PBS as: “A design philosophy where protocol participants might use third-party services during their consensus duties.” Up until this point, miners had complete control: they decided on the transaction order, did the hashing, and then added the block. But MEV GETH switched things up. It introduced outside actors, called searchers, who paid for the right to have their bundle of transactions included in the miners block.

With MEV GETH, miners had a new endpoint. They could receive transaction bundles optimized for MEV from searchers. Each bundle would also contain a transaction that provided miners a fee, incentivizing them to select this particular bundle. Naturally, miners chose the bundle offering the highest fee. When searchers compete for MEV opportunities in the public mempool, their bids naturally escalate due to this competition. This competition ensures that miners receive the lion's share of MEV benefits.

Let's break this down with an example: Imagine Alice is a searcher and spots an arbitrage opportunity between two decentralized exchanges. She could profit 0.07 ETH by buying Token X on UniSwap and then immediately selling it on SushiSwap for a higher price. So she creates a transaction bundle optimized for the 0.07 ETH MEV opportunity and is willing to pay a miner 0.05 ETH to prioritize her transactions in the next block. Bob, another searcher, identifies the same opportunity. He constructs a similar bundle but offers a 0.06 ETH payment to miners for the same privilege. Alice and Bob both send their MEV optimized transaction bundles to miners. On the other end, a miner receives these bundles and has to decide which one to include in the next block. Naturally, the miner chooses Bob's bundle due to the higher fee offered, ensuring the miner reaps maximum benefit. It's a win-win situation. The miner captures the majority of the MEV opportunity, receiving 0.06 ETH out of the 0.07 ETH opportunity. Meanwhile, the searcher secures a net profit of 0.01 ETH, which they otherwise wouldn't have been able to obtain. The essence of the MEV GETH mechanism is this competitive bidding. Alice and Bob compete against each other, offering incentives to the miner, thus ensuring the miner captures a significant portion of the MEV benefits.

However, if they simply opened up an endpoint for anyone to send the miners bundles, malicious actors might exploit this openness to overload their system, potentially launching a DOS attack. To address this vulnerability, Flashbots introduced the Flashbots Relay. This relay serves a crucial filtering role: it assesses incoming transaction bundles based on their potential profitability for miners, the validity of the transactions, and the offered fee. Only the optimal bundles are then forwarded to the miners. This method does introduce a level of centralization, as the process is dependent on the Flashbots Relay to screen out undesirable or potentially harmful traffic. Interestingly enough, a level of PBS already existed between the mining pool operator and their workers. Typically, the operator constructed the block body, including the bundles sent from the relays, hashed the block header once, and dispatched it to workers to continue hashing and find the golden nonce.

Part Two: The Current Landscape

When Ethereum transitioned from Proof of Work (PoW) to Proof of Stake (PoS), the landscape of transaction validation and block proposal significantly changed. While PoW relied on miners and computational power (hash rate) to validate and add new blocks to the blockchain, PoS shifted this responsibility to validators who would stake their ETH to become block proposers.

MEV GETH was being used by nearly all the mining pools, but with Ethereum transitioning to PoS, the system required modifications. PoS was designed to accommodate solo stakers: individual validators operating on low resource devices like a Raspberry Pi. PoS was designed with the goal of ensuring a balanced landscape: whether you're a solo staker or part of a substantial staking pool, there would be no inherent advantage in the validation process for any participant. Prior to the PoS transition, a few mining pools dominated the hash rate. This allowed for a trusted relationship between these pools and the Flashbots Relay. Any dishonest actions, such as a mining pool stealing MEV from a searcher, could jeopardize this relationship. Say a miner received a bundle with a sandwich attack from a searcher. If the miner further sandwiched the searcher with their own transactions, it would bring short term gain, but it would sever ties with Flashbots, costing them future MEV earnings because they would lose access to the Flashbots Relay.

Introducing MEV Boost

Solo stakers, unlike large mining pools, might not have long term motivations to maintain trust. In certain scenarios, they could find it more profitable to exploit the MEV from a builder and subsequently disappear from the network. This action would result in them being fully slashed, losing all 32 ETH, but in some cases, the potential profit from stealing the MEV can outweigh this loss. This indeed occurred in April, when a rogue validator swiped $20M from a sandwich bot before shutting down their validator. Further reading on this incident.

In response to this new attack vector, Flashbots rolled out MEV Boost, a system designed for an environment with solo stakers.

The Mechanics of MEV Boost:

1. Relays: Unlike the previous system where only Flashbots acted as the relay, MEV Boost democratizes this. Now, anyone can serve as a relay, broadening participation and security. Flashbots has also open-sourced their relayer code.

2. Builders: A new role emerges - the Builder. These entities collect transaction bundles from searchers and combine them into complete blocks.

3. Auction System: Builders make bids to include their full block and submit them to the relays. The relays perform a crucial verification step to ensure block validity.

4. Validator Interaction: The relays forward the highest bid, along with the respective block header, they receive from the competing builders to the validator who’s turn it is to propose a block to the Ethereum network.

5. Block Commitment: The designated validator signs the block header, which is a commitment. Once signed, they are bound to that block. If they attempt to sign a another block that would be seen as a malicious act and they would be slashed.

6. Final Proposal: With a commitment in place, the relay sends the full block details to the validator, and it’s formally proposal to the network.

This setup introduces trust issues:

• Builder-Relay Trust: Builders need to trust that relays won't steal their MEV. Consider a scenario where a relay, after receiving a block from a builder, swaps out the builder's address in a sandwich transaction for its own. Then they pass manipulated header on to the proposer.

• Proposer-Relay Trust: Proposers, on the other hand, must trust that the block headers they sign are valid. Proposing an invalid block would result in the forfeiting the block rewards since the network would reject such a block.

PBS designs see a recurring challenge: while interactions between the proposer and transaction ordering actors are a given, there's a clear need for a mechanism where:

1. Proposers can commit to a builder's block without knowing its contents but remain assured of the block's validity.

2. Builders can safely send their block to the proposer, confident that their MEV won’t be stolen.

Before diving deeper into MEV Boost, it's essential to understand the default way Ethereum creates blocks without the use of MEV Boost. This setup hinges on the collaboration between a validators Execution Client and Consensus Client. When a transaction is received by the Execution Client, it checks the format, adds it to its mempool, but doesn't process it. Simultaneously, the Consensus Client handles the PoS consensus, picking a validator to create the next block. The selected validator's Execution Client then arranges transactions by gas price into a new block, which is then forwarded to the Consensus Client and put forth to the network. Other validators attest to the block's accuracy, and once verified, it becomes the chain's newest link.

This process changes if the validator opts to use MEV Boost. Validators integrating MEV Boost do so with their consensus client. When they're up to propose a block, they don't rely on their Execution Client anymore and instead connect to a network of relays. Validators can choose which relays to connect to.

MEV Boost is optional, but 95% of validators are utilizing it. Essentially almost every validator, except those run by Vitalik, are delegating block building to a third party. This delegation indicates that a core function of the Ethereum protocol, block building, is now primarily conducted outside of the Ethereum system itself. One key player in this setup is the relay and their role somewhat contrasts with Ethereum's foundational principles. Presently, there are around 9 active relays, but only 6 of them have >9% share of blocks relayed.

Breakdown of Top Relays and Builders by Market Share in the past 7d. Source: https://www.relayscan.io/

Trust becomes an issue since the relationship between the relays and the builder and the relay and the validator isn't trustless. There's also a concern about censorship resistance. Relays, during their auctions, have the discretion to determine the validity of blocks. This discretion allows them to exclude blocks with transactions linked to sanctioned addresses. A case in point is when the OFAC Tornado Cash sanctions happened some relays exercised this power. Recent data shows that 38% of blocks in the past week adhered to OFAC guidelines due to such relay imposed censorship.

Part Three: Looking Ahead

Ethereum is devising a strategy to reincorporate the processes currently operating outside its core protocol. The goal is to mandate that proposers obtain blocks from builders, essentially letting the protocol handle the relay's current duties. The relay system as it stands has its vulnerabilities. For instance, a relay might not properly validate a block, misverify the builder's bid in relation to the payment intended for the proposer, or even delay or fail in block delivery. On top of this, running a relay doesn't come cheap. As of now, there's a lack of a sustainable funding model for them. The Ultrasound Relay, the most utilized relay, says its operating costs are estimated to be between 70k-80k euros annually, and that's excluding other expenses like software maintenance. Relays currently operate as public utilities.

It's also worth noting that since MEV Boost is external software developed by a company (Flashbots) it isn't as rigorously tested as software within the protocol. This was evident with the Prism client post the Shapella upgrade: an integration bug with MEV Boost caused issues with the proposer's signature, leading to missed slots and slashing. The goal of integrating this process into the Ethereum protocol is to address these challenges, ensuring that even if an agreement between the proposer and builder falls apart, the proposer remains reimbursed. So, if a builder provides a faulty block, the proposer still gets the full bid, leaving the builder to bear the consequences. While the specifics of this integration, referred to as ePBS (enshrined proposer-builder separation), are still being researched, and possibly a couple of years from realization, there are already many different ideas of how it could possibly look.

How to Enshrine Proposer-Builder Separation

To understand potential ePBS implementations, it's essential to first understand some basic components of Ethereum’s PoS algorithm. In Ethereum time is segmented into 12 second intervals called slots. 32 of these slots come together to form an epoch. In each slot, a validator is randomly selected to propose a block. Simultaneously, a committee is designated to attest to the validity of the block they deem compliant with Ethereum's PoS fork choice rules, ideally attesting to the most recently proposed block as the blockchain's head. If a block isn't proposed in the given slot, then 4 seconds in, the attesting validators attest to the previous block.

Now, onto ePBS designs. The most favored model spans two slots. First there’s a bidding phase, where builders send their bids to the validators. Then Slot 1 begins with the proposer picking a bid and committing to it by publishing a block that commits to that builder’s bid. A group of attestors then cast their vote in favor of this block, ensuring its place in the chain. In Slot 2, the builders see the bid that was committed in the proposer's committed block and the attestations on it. Recognizing the proposer's irreversible commitment, the builder whose bid was selected releases their block and is assured that their MEV can’t be stolen. Finally, attestors validate this new block.

A newly released model is similar to the two slot approach but introduces a payload-timeliness committee. First, a builder's bid is selected and committed to by the proposer, and then the committee of validators gives its attestation. Subsequently, the builder reveals the block's payload (its transactions), and the payload-timeliness committee confirms that the payload was provided on time and its validity. The other differences between these two methods lie in the specifics of Ethereum's Proof of Stake operations, but that's beyond the scope of this post.

Another design revolves around the concept of a slot auction. Here builders, during their bid, commit to a slot in the epoch without specifying the block. They essentially pledge to create a block during their allocated slot, offering a certain price to do so. This offers adaptability, especially for cross domain MEV which requires real time action.

So far all the ePBS designs grant the builder full control over the block's transactions. A potential workaround is the use of an inclusion list. This list, sent by the proposer to the builder, ideally all the transactions currently in the mempool or doesn’t have to be, contains transactions that must be part of the builders block if there’s space. If the builder's block is full, they must indicate so, affirming they acknowledged the list. Such a method strengthens the network censorship resistance. If a builder wants to censor a transaction it will become difficult and costly to do so over time. Due to EIP 1559, consecutively filled blocks will cause the base fee to exponentially rise. Therefore if a builder continually censors a transaction by filling up a block with dummy transactions, the escalating costs make this infeasible overtime.

There might be instances where the proposer wants to have some influence on block creation. Another ePBS feature might involve the proposer making a section of the block (either the start or end) and delegating the remainder to a builder. All of these designs and features aren't mutually exclusive, it's more about balancing their benefits and drawbacks.

The Optimistic Relaying Approach

Another take on ePBS leverages our existing trusted relays. The idea is to incrementally reduce the responsibilities of the relay until it primarily serves as an optimizer, rather than a crucial component. In its first phase, we shed the relay's duty of verifying block validity. This greatly reduces the cost of running a relay as there’s no longer a need for block simulation to ensure its validity. Plus, it streamlines the relay’s role, shaving off about 100 to 200 milliseconds of latency in their communications with the proposers and builders. So, how do we ensure the proposer gets their payment if a block turns out to be invalid? The builders would be mandated to post collateral, equal to their bid, when they bid. If the block is invalid, the collateral covers the payment the proposer would've received. This concept is termed Optimistic Relaying V1.

Pushing optimistic relaying a step further to V2, we can eliminate the relay’s need to download the block, reducing another 50 to 100 milliseconds of latency. The same assurances apply: if a block never downloads, the builder's collateral pays up.

Ultimately, the end game for Optimistic Relaying starts looking a lot like the payload-timeliness committee model I touched on earlier. Here’s the sequence: Builders submit their bids on a peer to peer layer. The proposer accepts a bid and follows up with a signed header. Then, the builder rolls out the block. At this stage, the relay's sole job is overseeing the peer to peer layer mempool, basically clocking when different activities occur. The relay's role becomes super lightweight, it just needs to keep tabs on the mempool. It makes the relay operate a lot like the payload-timeliness committee. All these steps build towards a future where the relay is replaced by the payload-timeliness committee, streamlining the entire protocol.

Leveraging Builders for Additional Protocol Enhancements

PBS emerged as a response by Flashbots to the centralizing effects of MEV, aiming to attempt to harness MEV for positive outcomes. Given the new role in Ethereum specializing in block building, there's an opportunity for these entities to act like supercomputers, contrasting the lightweight validators. Protocol designs are surfacing that capitalize on these powerful builders. The idea is to keep validators uncomplicated and straightforward (some might even say cucks), while builders, having no such restrictions, can function at a much higher computational level. A primary application for these enhanced builders is for scaling.

Ethereum Researcher Dankrad Feist’s Danksharding design suggests that these high resource intensive builders can construct one big block that contains all the data. That data is then segmented and committed to by multiple KZG commitments. Constructing this block requires considerable resources, but validating them is relatively inexpensive. Lightweight validators can then apply Data Availability Sampling to inspect a small section of the block and be nearly certain of the entire dataset's accessibility, yielding an added ~16x boost in data throughput from Proto-Danksharding. The intricacies of Danksharding are complicated and not covered here, but the key point is that these advanced builders can be delegated additional roles to further enhance the network.

Another idea to take advantage of the builders is the potential realization of based rollups. A few years back, Vitalik discussed rollup sequencing models, coining the term for one of them Total Anarchy, in which anyone can publish a rollup block and the first sequence that hits the chain is the official block. This approach had many drawbacks, like onchain spam and ambiguity over the winning sequence. However, Justin Drake's recent article on based rollups highlighted a more efficient strategy taking advantage of the builders. In this model, the builder on layer one functions as the rollup sequencer, cherry picking the optimal sequence to include onchain. This ensures only the optimal sequences are incorporated.

Beyond rollups, the introduction of powerful builders can spur other innovative structures, like stateless clients. They empower nodes to operate as usual but without the baggage of preserving outdated states. These allow the nodes to be more lightweight and hinge on the builder's ability to generate specific cryptographic proofs.

PEPC: Protocol-Enforced Proposer Commitments

Protocol-enforced proposer commitments (PEPC, pronounced pepsi) is a concept introduced by Ethereum Foundation researcher Barnabé Monnot in October 2022. You can delve deeper into Barnabé's original post here. At its core, PEPC aims to grant proposers a greater say in block building, that they’ve lost by selling the entire task to specialized builders. In PEPC, proposers can add extra conditions for a block to be deemed valid, apart from the usual Ethereum requirements. If a block fails to meet any of these extra conditions, it's considered invalid, and attestors should reject it. This is different from EigenLayer commitments where validators with extra commitments either lose some staked ETH for noncompliance or get rewarded for fulfilling them. However, the block remains valid regardless of these commitments.

Imagine Alice is a proposer in the Ethereum network. With PEPC, Alice has the flexibility to make a specific commitment for the upcoming block. She could commit that her block will contain at least three transactions pertaining to a particular smart contract, and she's willing to allocate 70% of the block's gas for these. She communicates this commitment, and it becomes part of her block's validity conditions. Now, Bob, a Builder, sees Alice's commitment. He packages together a bundle of transactions fitting Alice's criteria and sends it her way. If Alice's block, after being constructed, aligns with her commitment (i.e., contains the specified transactions consuming the designated gas), then the block is deemed valid and can be added to the blockchain. If not, Alice's block won't be accepted, ensuring that she adheres to her declared commitments.

One key difference between ePBS and PEPC lies in the commitments nature. In ePBS, proposers and Builders follow a fixed, uniform procedure. It's a kind of one size fits all approach. A proposer commits to a specific block hash, and the builder then produces a matching payload. However, PEPC introduces variety. Each proposer can set unique conditions, offering a lot more flexibility. It's crucial to note that PEPC's existence depends on ePBS, they complement each other. The exact workings of PEPC are still under discussion and research.

Conclusion

PBS isn't a specific implementation, it's a design philosophy. It says that there are incentives for the division of labor and that protocol actors will delegate some responsibilities to more specialized external entities. The protocol's aim is to offer a reliable, as trustless as possible interface to ensure this delegation is smooth, fair, and inclusive. Without this, some actors might have an edge, leading to the centralization issues first observed with MEV before the PBS era. At its core, PBS emphasizes fairness and decentralization. While the exact elements to be integrated into the protocol will be seen in future Ethereum updates, Ethereum’s overarching goal remains clear: accessible, open, trustworthy stateful computing, overseen by a decentralized group of lightweight validators.

Resources for Deeper Understanding

https://notes.ethereum.org

State of research: increasing censorship resistance of transactions under proposer/builder separation (PBS) - HackMD

State of research: increasing censorship resistance of transactions under proposer/builder separat

https://ethresear.ch

Proposer/block builder separation-friendly fee market designs

Special thanks to Justin Drake and the Flashbots team for feedback and discussion. A major risk threatening the ongoing decentralization of consensus networks is the economics around miner extractable value (MEV), sophisticated tricks to extract profit from the ability to choose the contents of the next block.

https://arxiv.org

Ethereum's Proposer-Builder Separation: Promises and Realities

With Ethereum's transition from Proof-of-Work to Proof-of-Stake in September 2022 came another paradigm shift, the Proposer-Builder Separation (PBS) scheme. PBS was introduced to decouple the roles of selecting and ordering transactions in a block (i.e., the builder), from those validating its contents and proposing the block to the network as the new head of the blockchain (i.e., the proposer).

We are on the cusp of a revolutionary shift in the Ethereum landscape. Applications once considered unfeasible due to the network's limited throughput are about to become viable. The tradeoff between scalability, decentralization, and security, known as the blockchain trilemma, has long been a characteristic of blockchain networks. Ethereum chose to prioritize decentralization and security, amassing nearly 1 million validators and making a 51% attack prohibitively expensive (it would cost over $40 billion). However, this focus came at the cost of scalability. During peak usage, Ethereum transaction fees have soared to over $300. Even in the depths of a bear market, interacting with a smart contract could cost several dollars. Vitalik Buterin once famously stated that "the internet of money should not cost more than 5 cents per transaction." Fortunately, Ethereum has been striving for scalable solutions since its inception.

The Ethereum Foundation has been contemplating various sharding designs since 2016, with the first phase of data sharding slated for implementation in the coming months. According to Justin Drake, a researcher at the Ethereum Foundation, Layer 2 rollups may soon be so inexpensive that companies operating their sequencers could absorb the costs, making transactions free for users.

Note: Assuming you're familiar with how rollups work, this article will dig into Proto-Danksharding (PDS), its role in scaling Ethereum, and why its implications are not yet fully understood. If you're not familiar with rollups, you may want to pause and read my earlier post on the topic here.

Ethereum's final form envisions a data layer where rollups can post temporary data, secure in the knowledge that a global network of nodes and cryptoeconomic security protecting it. The word temporary might have made you pause, but yes, the days of a freshly initiated Ethereum node having access to the complete transaction history are numbered. PDS introduces a new space for rollups to post data and the pruning historical data is crucial for achieving low cost rollup fees and is a feature of PDS. This data pruning occurs after approximately 18 days (4096 epochs), which is more than adequate for both major types of rollups to fully function. Specifically, optimistic rollups only require data to be available for one week to finalize the state, while zk-rollups allow for immediate fund withdrawals. This 18 day period ensures that anyone can download the data if they want to. Additionally, it's worth noting that preserving historical data operates on a 1-of-n assumption, meaning you only need one entity among all possible options, be it rollups or block explorers, to retain this data to make it accessible in the future.

Currently rollups use calldata to post their data, and each Ethereum block contains about 10 KB used for calldata. In PDS, each message of data that a rollup wants to post is termed a blob. Each blob holds approximately 125 KB of data. With a targeted inclusion of 3 blobs per block and a maximum capacity of 6 blobs, this implies that on average, each block will contain about 375 KB of data. This is a substantial increase, a 37.5x jump, compared to the 10 KB used for calldata today and it's worth noting that not all of that calldata is utilized by rollups. The reason for this dramatic data increase, without significantly ramping up hardware requirements, lies in the transitory nature of data storage. Nodes will need slightly more storage to store these data blobs for the 18 days, but the storage doesn't perpetually expand with the progression of the chain due to the pruning mechanism.

How PDS Works Technically

In PDS, a new transaction type is introduced within the execution client (EVM), known as a blob-carry transaction. When rollups aim to post new data, they must perform two separate steps. First, they initiate a blob-carry transaction that includes the conventional transaction components like the sender, receiver, nonce, and gas bid along with two new fields specifically designed to facilitate data posting. The first of these new fields is max_fee_per_blob_gas, which is the bid that the sender is willing to pay to post their data blob. The second field, called blob_version_hashes, is essentially a list of hashes of the blobs to be posted. A single transaction can post multiple blobs.

These data blobs are a new transaction type on the execution chain. However, they don't add extra tasks for the execution process. The EVM looks only at the commitment tied to these blobs. In PDS, consensus clients fully download these data blobs. Instead of being fully packed into the Beacon block body, the blobs are simply referenced there. Their contents are sent separately, like a “sidecar” accompanying the main data. Each block in PDS has one such blob sidecar that is downloaded in full.

Instead of using a straightforward hashing approach to commit to the data, PDS employs a more intricate process. The data is first transformed into a polynomial, and then a Kate commitment (KZG) is generated for it. Finally, this commitment is hashed. While this procedure might sound complicated, it's not merely for robust cryptographic assurance. It's a necessary step for future upgrades aimed at facilitating Danksharding. The polynomial and KZG processes lay the groundwork for these upcoming features. If you're intrigued by the specifics of these cryptographic techniques, additional resources will be provided at the end of this article.

Sample Blob-Carry Transaction

{ 
"transaction_type": "blob-carry",
"sender": "0xAbcd1234...",
"receiver": "0xDef5678...", 
"nonce": 42,
"gas_bid": 100000,
"max_fee_per_blob_gas": 2000,
"blob_version_hashes": [ "0x019f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a", "0x011679091c5a880faf6fb5e6087eb1b3c3a77f5a4d7f8f0a4d4a478e0484368f" 
], 
"signature": "0x1f67d0..." 
} 

Blob Gas: A New Fee Market in Ethereum’s PDS

PDS introduces a separate fee market exclusively for blobs, independent of the primary Ethereum fee market. This means that if the main Ethereum layer is congested, let's say due to a surge in transactions for the latest meme coin AnimeButtPirate69Inu, the blob fee market remains unaffected. Blob pricing follows a mechanism resembling EIP-1559, using a unit called blob gas. The cost of blob gas is dynamically calculated based on a running tally of excess blobs, those exceeding the target of 3 blobs per block. While each block aims to include 3 blobs, there's a hard limit of 6 blobs per block. A header field in each block keeps track of how many blobs have been included over or under the target. This tally then serves as an input to an exponential function that determines the price of blob gas for the subsequent block. In essence, the function is designed to make it increasingly costly to include additional blobs, helping to maintain an average close to the intended target of 3 blobs per block.

Let's consider a simplified Ethereum universe where we have just 5 blocks to look at:

Block 1:

• 3 blobs included

• Running Tally of Excess Blobs: 0 (since it matches the target of 3)

• Blob Gas Price: Low (determined by a function of the tally, which is 0)

Block 2:

• 4 blobs included

• Running Tally of Excess Blobs: 1 (1 more than the target)

• Blob Gas Price: Slightly Higher (the tally is now 1, so the function increases the price a bit)

Block 3:

• 6 blobs included (the maximum burst limit)

• Running Tally of Excess Blobs: 4 (3 more than the target, adding to the existing 1)

• Blob Gas Price: Higher (now the tally is 4, and the function makes it much more expensive)

Block 4:

• 2 blobs included

• Running Tally of Excess Blobs: 3 (1 less than the target, reducing the existing 4)

• Blob Gas Price: Moderately High (the tally is reduced to 3, so the function adjusts the price downward but it's still high)

Block 5:

• 1 blob included

• Running Tally of Excess Blobs: 1 (2 less than the target, reducing the existing 3)

• Blob Gas Price: Lower (the tally is now 1, so the function makes it cheaper)

PDS introduces an entirely new resource, complete with its own separate fee market. Initially, this resource is unlikely to be fully consumed, leading to exceptionally low fees required for rollups to access it. As a result, transactions could potentially be free for the first 6 to 12 months following its introduction. This is because posting a blob may be so inexpensive that rollups can afford to subsidize the fees for their users.

The Impact

The impact of PDS goes far beyond just making transactions cheaper. This isn't some minor adjustment, it’s unlocking a whole new level of possibilities on the blockchain. Think about it: tipping someone a few cents for a helpful online comment or leaving a review (attestation) could become as easy as clicking a button. Artists won't have to worry about high fees when they create new NFTs. But that's just scratching the surface. PDS makes it possible for completely new types of apps to exist. Decentralized social media platforms could become far more user friendly, removing the financial barriers that kept people away. Real time voting systems on the blockchain could turn into a reality, making decentralized governance more feasible than ever. Even in the world of finance, we could see the rise of platforms for high frequency trading that are fully decentralized. Remarkably, all of this can be achieved on a highly decentralized network, safeguarded by millions globally including solo stakers and full nodes operating on devices as simple as Raspberry Pis. Just a short while ago, such a vision was deemed unattainable.

I often reflect on a talk by Vitalik where he emphasizes the same point I'm highlighting. We should begin conceptualizing and creating apps today that might seem impractical now, but will become viable in a few months when transactions become 100x (or more or free) affordable.

Conclusion

But let's not forget, this is just the beginning. PDS is a stepping stone towards the ambitious goal of full danksharding, which aims to further increase the amount of data that can be posted. In essence, some of the promises of blockchain technology that seemed too ambitious in 2017 and 2018 may have simply been ahead of their time.

Additional Resources

https://domothy.com

Blobspace 101

Introduction

https://members.delphidigital.io

The Hitchhiker's Guide to Ethereum - Delphi Digital

Ethereum's roadmap is a lot to keep track of. This is your technical crash-course on everything from danksharding to KZGs to statelessness and so much more.

https://notes.ethereum.org

Proto-Danksharding FAQ - HackMD

Proto-Danksharding FAQ [TOC] ## What is Danksharding? Danksharding is the new sharding design p

Rollups this, rollups that – you've probably know that they're a way to scale Ethereum, but what exactly is a rollup? How does it work in a technical sense that's still accessible to understand? That's what this post aims to explain.

Overview of Rollups

Ethereum currently allows a maximum of 30M gas per block, which comes out to around 25 transactions per second. In essence, rollups enable more transactions to fit into an Ethereum block without increasing the gas limit. They achieve this by allowing computation (actually executing the transaction, which is very gas expensive) to occur offchain.

To understand how rollups work, imagine that there are two rollup transactions in a batch of 50 that get sent to a L1 smart contract. In the first transaction, address 0x123 calls a Uniswap contract with 10 ETH as the input. In the second transaction, address 0x456 calls an Aave smart contract with 100 DAI as the input. If these transactions were to occur directly on L1, the validators and full nodes on the network would need to run these transactions through the EVM (Ethereum Virtual Machine) to get the output. This process of running transactions through the EVM is highly resource intensive, and it's one of the reasons why Ethereum blocks can only contain a limited number of transactions.

Rollups process these transactions through a virtual machine (not necessarily the EVM) off L1 and then summarize the results in a compact form. For example, they would post to their L1 smart contract something like: '0x123 calls a Uniswap contract with 10 ETH as the input and the output is 100 USDC to 0x123,’ and '0x456 calls an Aave smart contract with 100 DAI as the input and the output is 50 LINK to 0x456.’ These summaries are presented as blobs of data. In theory, if you are someone simply observing their smart contract and seeing this data blob come in, you wouldn't know whether that's the correct output. Rollups then use proofs, either zk or fraud, to ensure that the execution of the transactions was done correctly.

In a rollup, several transactions are bundled and compressed into one single transaction on Ethereum Mainnet (for example, '0x789 calls a Compound contract with 20 ETH as the input and the output is 200 DAI to 0x789,' '0x321 calls a Sushiswap contract with 50 ETH as the input and the output is 500 LINK to 0x321,' '0x654 calls a MakerDAO contract with 30 DAI as the input and the output is 5 ETH to 0x654', …). This single L1 transaction contains all the necessary information about the multiple offchain transactions, including a summary of the current state of the rollup as a merkle root. A merkle root is a cryptographic way to keep track of the current state of something in a condensed form, encapsulating large amounts of data into a single hash. All rollups use one smart contract on Ethereum Mainnet to maintain the rollup state, hold the ETH sent to bridge to the rollup, and allow for an emergency escape from the smart contract, which I will explain later.

The calldata of the smart contract is where they post the compressed transactions and state roots. In a normal smart contract, the calldata is a specific area used to indicate which function you want to call and with what arguments, essentially conveying the details of the interaction with the smart contract. However, rollups use the calldata in their Ethereum L1 smart contracts differently. They utilize it as a data blob to post their transactions and state roots, enabling a more compact and efficient representation of offchain activities.

To interact with a rollup, a user sends a transaction to the rollup's sequencer node. The transaction is then placed in the sequencer's mempool, where it waits to be executed, ordered with other transactions, and summarized before being sent to L1. To update the rollup state as transactions are made, the sequencer sends details about all their transactions to their L1 smart contract. This includes transaction information you’d find on Etherscan, such as the sender, recipient, value, outcome, etc., along with an updated state root. Since all the transaction information needed to update the new state is posted to L1, in theory, anyone watching the smart contract could execute the transactions themselves and recompute the state. By performing much of the computation offchain and then posting the results to the Ethereum Mainnet, rollups greatly enhance scalability and efficiency, enabling more robust and responsive decentralized applications.

Verifying Correctness: Proofs

Since computation is done offchain by the rollup, verification of correctness becomes crucial. The system must ensure that the rollup nodes process transactions correctly and can't include fake ones. This is where proofs come into play.

ZK Proofs: These are straightforward. When a ZK rollup sends a transaction to its L1 smart contract, it includes the compressed multiple transactions information, the new state root, and a zk-proof. The zk-proof verifies the handling of the transactions and confirms the updated state is valid.

Fraud Proofs: This involves economic games. Optimistic rollup nodes need to stake some ETH, essentially saying, "If I'm lying and you prove it, you get my stake." It relies on people examining the L1 smart contract and recreating the state's transition. If fraud is found, they can initiate a fraud proof game by also staking some ETH. If the rollup is found to be lying, the accuser receives the rollups stake, and if wrong, they lose their posted stake. Optimistic rollups depend on at least one person checking the chain, and transactions are not considered final until a week has passed, allowing time for the fraud-checking game.

You may have heard the term 'Data Availability' before. Essentially, this means that the complete transaction information and state roots need to be posted and visible for a sufficient amount of time, allowing people to recreate the state if necessary. This requirement is an essential aspect of both ZK rollups and optimistic rollups, ensuring that the information is accessible and transparent for validation purposes.

What Happens When a Rollup Goes Offline?

Rollups not only need to post data onchain to summarize transactions but also to ensure data availability in case the rollup's server goes offline. In such a situation, having the data onchain enables the generation of inclusion proofs, allowing users to safely withdraw their funds from the rollup back to L1. This data posting mechanism is critical for maintaining a secure and trusted environment, making it possible for users to interact with rollups without fear of losing access to their assets.

Upgradable Multisig Contracts and Associated Risks

For most rollups, the L1 smart contract is currently an upgradable multisig contract. This presents an obvious risk, as changes to the contract could potentially lead to unintended consequences or vulnerabilities within the rollup. Teams are actively working to mitigate this risk, with various strategies being employed to ensure that the contract remains secure and functions as intended. One of the most popular methods currently in use involves allowing token holders to vote on changes to the smart contract. By incorporating a governance mechanism where token holders have a say, it brings a degree of decentralization and community oversight to the process. Decisions are not made unilaterally but must pass through a democratic process, where token holders' voices are heard.

Furthermore, to add an additional layer of safety, many projects implement a time delay on decisions. If a change to the smart contract is approved, it does not take effect immediately. This delay provides a window of opportunity for those who disagree with the decision to exit the system. If you are against a decision, you have the time to withdraw your funds and disengage from the rollup, reducing your exposure to any potential negative impact from the change. This approach to governance and the implementation of time delays are seen as robust safeguards, balancing the need for flexibility and upgradability in the smart contract with the necessity to protect users and maintain trust in the rollup system.

Sequencer Decentralization

The discussion around decentralizing the sequencer is gaining momentum. Sequencer decentralization is vital for censorship resistance. Currently, if a sole sequencer ignores your transaction, you can submit a request back to L1 using a merkle proof. What this entails is providing proof to the smart contract that you possess ETH within the rollup and that you want it sent back to your EOA (Ethereum Address) on L1. While this option is positive, the objective in decentralizing the sequencer is to minimize its power to censor transactions.

Fraud proofs already ensure that there are no invalid state transitions, so rollups don't require thousands of nodes like Ethereum Mainnet does. The goal is to have the minimum amount of nodes (sequencers) necessary to prevent transaction censorship. By keeping this number low, the UX of the rollup can remain high, the whole purpose they exist in the first place. A small number of trusted, whitelisted sequencers, approved by token holders may be an acceptable compromise to keep costs low, given the security benefits from the L1. While anyone can be a validator on Ethereum Mainnet, rollups need not follow the same model. Some rollup teams might be awaiting EIP 4844, an improvement to Ethereum that is likely to be implemented later this year or early next. Which will allow for more space for rollups to post data, potentially increasing scalability by 10x and mitigating the effects of additional sequencers.

Conclusion

Rollups have emerged as an exciting and innovative solution to some of Ethereum's most pressing challenges. By enabling offchain computation, they significantly increase the network's efficiency and scalability, making decentralized applications more robust and responsive. The integration of mechanisms like fraud proofs, governance strategies, and sequencer decentralization ensures that the system maintains a high level of trust, transparency, and community oversight. As the technology continues to evolve, rollups may very well become a fundamental aspect of Ethereum's growth and success. By understanding the intricacies of how they function, we can better appreciate the remarkable strides being made in the world of decentralized finance and blockchain technology.

Glossary

• Rollup: A Layer 2 scaling solution that enables more transactions on Ethereum by performing computation offchain and then posting the results to the Ethereum Mainnet.

• Gas: A measure of computational work on Ethereum, required to process transactions.

• EVM: Short for Ethereum Virtual Machine, a decentralized computer that runs on the Ethereum network, executing smart contracts and processing transactions.

• Merkle Root: A hash that summarizes a large set of data, allowing for efficient and secure verification of contents within that data set.

• Calldata: A specific area in a smart contract that typically indicates the function being called and its arguments. In the context of rollups, this area is used to post transaction data, the state root, and, in the case of ZK rollups, the accompanying zk-proof.

• Sequencer: In the context of rollups, a node that orders and transactions and sends compressed details to the L1 smart contract.

• ZK Proofs: Short for Zero-Knowledge Proofs, a cryptographic method that verifies the validity of a transaction without revealing any information about the transaction itself. In the context of zk-rollups, ZK Proofs are used to post a concise proof that all the transactions and the new state transition are valid.

• Fraud Proofs: A system of checks and incentives to ensure that rollup nodes process transactions correctly and honestly.

• Data Availability: The requirement that complete transaction information and state roots are posted and visible for a sufficient amount of time for validation purposes.

• Multisig Contract: A smart contract that requires multiple signatories to approve changes or transactions.

• EOA: Externally Owned Account, an account controlled by a private key on Ethereum.

• EIP 4844: A proposed Ethereum Improvement Proposal that will have an impact on rollup scalability.

1. Overview

The aim of this tutorial is to demonstrate how to use the Sismo Connect Server Library to create a mini private "Only Fans" application. The main feature you're aiming for is to validate if a user owns a certain NFT (Pudgy Penguins, in this case) and offer them a discount based on their holdings. This project preserves user privacy and security using Zero-Knowledge Proofs (ZK Proofs) and offchain verification.

Note: For a comprehensive understanding, we recommend users watch the YouTube video linked in the tutorial. If you're seeking the full code, it's available on my GitHub repository.

https://github.com

GitHub - ChaskinOnChain/sismo_offchain_only_penguins

Contribute to ChaskinOnChain/sismo_offchain_only_penguins development by creating an account on GitHub.

2. Prerequisites

• Node.js

• Npm

• MetaMask browser extension

3. Installation and Database Setup

Clone the Tutorial Repository

This step involves retrieving the application source code from GitHub:

Clone the Repository: git clone https://github.com/ChaskinOnChain/sismo_offchain_only_penguins.git

Navigate into the Directory: cd sismo_offchain_only_penguins

Checkout the Specific Commit: git checkout fee4c374be8839fe305a5a5b1c8d53d9c276d06a

This ensures you're working on the same codebase version as described in the tutorial.

Install Dependencies

Your application relies on various libraries and packages, primarily from the Next.js framework:

Install Next.js Dependencies: npm i

This command fetches and installs all necessary dependencies as mentioned in the package.json file of the cloned repository.

Database Setup on PlanetScale

The heart of most applications is the database. Here's how to set it up on PlanetScale:

• Access the Platform:

  • Go to PlanetScale's website.

• Account Setup:

  • If you're new to PlanetScale, sign up. Otherwise, log in.

• Creating a Database:

  • Click on "See how PlanetScale works."

  • This tutorial essentially acts as a guide for beginners.

  • Keep progressing through the tutorial steps by pressing the presented buttons.

  • When prompted to create a database, name it appropriately (for example, onlypenguins).

  • Choose the 'Hobby' tier, which is free.

• Database Connection Setup:

  • Once your database is ready, you'll see an option saying "Ready to connect to your database?".

  • Click on it and then click "create Password."

  • For the connection method, ensure "Connect with Prisma" is selected. Click on .env and subsequently click on the clipboard icon.

  • This action copies the connection string, which looks like DATABASE_URL=”mysql://…”.

• Configure Connection in Your Local Environment: Switch back to your code editor. In the root directory of your cloned repository, create a .env file. Paste the copied DATABASE_URL connection string into this file.

This .env file stores sensitive environment variables, in this case, the connection string for your database.

Update Database with Prisma:

• Next, you want your local setup to recognize and structure the database accordingly.

• To produce the Prisma Client from your Prisma schema for type-safe database access: npx prisma generate

• To update the database schema to match your Prisma schema without using migrations: npx prisma db push

4. Launching the Local Application

After completing the installation and database setup, you are set to launch the application locally and interact with its integrated features.

• Run the Application: npm run dev

  • This command initiates the Next.js application. The app has preset server routes located in app/api/verify/route.ts and app/api/paid/route.ts. Once the command is executed, the application should be accessible on your local machine.

• Access the Application:

  • Using any web browser, visit http://localhost:3000. Here, you'll experience the tutorial application in action, already integrated with Sismo Connect.

• Experiment with the Local App:

  • The application comes with Sismo Connect integration. To personalize the experience:

    • Navigate to the Sismo.tsx file located in app/components/.

    • In this file, find line 28, where you'll see an address parameter. Change this 'to' address to your own Ethereum address. This modification ensures that any transactions (payments) made within the app will be directed to your personal address.

    • Reminder: Always make sure you are on a testnet when experimenting with such changes. This way, you avoid unnecessary expenses of real Ether (ETH).

• Enjoy Your Subscription:

  • After making the necessary modifications and ensuring you're on a testnet, go ahead and try subscribing to "Only Penguins".

• Dive Deeper:

  • With the basic setup and operations out of the way, you can now delve deeper into how Sismo Connect is integrated within the application. The tutorial likely offers insights into the workings behind the scenes and ways to further refine and expand the integration.

5. Sismo Connect Configuration

Configuring Sismo Connect in Your Application:

• Access the Configuration File:

  • Navigate to app/components/Sismo.tsx in your application.

• Setting Up Application in the Sismo Factory:

  • If you wish to use Sismo Connect in your application, it's essential to first set up an application within the Sismo Factory.

  • Obtain the unique appId for your application from the Sismo Factory.

  • For those unfamiliar with this process, there's a tutorial available here. However, for the sake of this tutorial, we're utilizing an already defined appId which is 0xbffb8652509c7e27e0b0485beade19c2.

• Integration using the Library:

  • The library, @sismo-core/sismo-connect-react, considerably simplifies the integration of Sismo Connect. It includes a convenient React button that facilitates the request for proofs of user data.

  • This button is designed to uphold user privacy, ensuring only necessary data is accessed without compromising sensitive information.

6. Sismo Connect React Button Configuration

Configuring the Button for User Data Proof Requests

This button serves as an essential bridge allowing your application to interact with the Sismo Connect and request proofs.

• Button Configuration:

  • In your application, locate the Sismo Connect configuration that employs the appId obtained from the Sismo Factory. If you're unfamiliar with this configuration, refer to this configuration guide.

• Proof Request Mechanism:

  • Auth Mechanism: The auths attribute facilitates the generation of proofs validating a user's specific vault id. Delve deeper into the concept of vault ids here.

  • Handling Responses: The onResponse attribute outlines how the application should react upon acquiring the proof. For instance, in this tutorial, once a proof is received, the server situated at /api/verify is invoked with the proof being sent as the body. The server then ascertains the presence of the user's vault and acts accordingly: retrieving an existing user's vault id and payment status or creating a new user record.

• Optional Discounts Based on Pudgy Penguin Ownership:

  • The objective here is to present users with a discount depending on their Pudgy Penguins ownership. Specifically, a discount rate of 0.001ETH is applied for each Pudgy Penguin token they possess in the account with the most Pudgy Penguin tokens. This discount considers all accounts in the user's vault, not necessarily the one executing the payment.

  • To implement this, begin by sourcing a proof from the user's account possessing the highest number of Pudgy Penguin tokens. Acquire the proof by identifying the groupId of the "Pudgy Penguins Nft Holders" group on the Sismo Factory here and subsequently initiating a claim request. Within your application's SismoConnectButton component, introduce a new claims prop. This prop should encapsulate details of the Pudgy Penguin ownership claim: This prop should define the specifics of the Pudgy Penguin ownership claim. In the object for this prop, you'll be configuring several properties:

    • groupId: Set this to the variable pudgyPenguinsGroupId which represents the identifier of the Pudgy Penguin group on the Sismo Factory.

    • claimType: Configure this to ClaimType.GTE, which stands for "greater than or equal to". This type ensures the proof validates that the user has at least a specified number of tokens.

    • isOptional: Set this to true, implying that the claim is not mandatory for the user to provide.

    • value: Configure this to 1, indicating that the proof should validate the user has at least one Pudgy Penguin token.

    • isSelectableByUser: This is set to true to grant users discretion in revealing the quantity of their tokens. For instance, some users may be major Pudgy Penguin holders, and disclosing the entirety of their tokens might inadvertently reveal their identity. By making this selectable, you allow users to choose the specific amount they wish to reveal, but they must disclose at least one token.

This configuration ensures a flexible and user-centric approach to revealing Pudgy Penguin token holdings, balancing between utility and user privacy.

• Impersonating Vaults for Demo Purposes:

  • For demonstration objectives, this tutorial suggests populating the data vault with specific addresses that you might not own. Sismo Connect simplifies the impersonation of such accounts. Within the SismoConnectButton's configuration (config object), introduce a vault key paired with another object named impersonate. This object should house an array of addresses for demonstration purposes. Examples include Ethereum addresses in hex format, ENS names, and social media handles (like Twitter or GitHub) with a suitable prefix.

  • As an illustration, let's integrate nansen.eth and jebus.eth into our vault - renowned Ethereum accounts with substantial Pudgy Penguin ownership.

⚠ Caution: Prior to deploying in a production setting, ensure all impersonated accounts are duly removed. Post impersonation, it becomes necessary for our database to monitor the number of tokens the user opts to reveal. The server extracts this value from the proof and relays this information to the frontend, which we'll further detail in upcoming backend amendments.

7. Backend Database Updates

Reflecting Token Ownership in the Database

The application's backend needs to account for the token ownership of each user. This requires updating the database schema.

Steps:

• Schema Update:

  • Navigate to prisma/schema.prisma. Update the User model to include a new entry for token numbers.

  • This will keep track of how many tokens a user has chosen to reveal.

• Update Database with Prisma:

  • Run the commands npx prisma generate and npx prisma db push to reflect changes in the database.

Located at app/prisma/schema.prisma

8. Server-side Verification: Processing and Verifying the ZK Proofs

The server is responsible for verifying the Zero-Knowledge (ZK) proof submitted by the front-end. Here's a step-by-step guide to achieve this:

Steps:

• Setup Sismo Connect for Server:

  • Navigate to app/api/verify/route.ts. Utilize the sismo-connect-server package, which facilitates server-side proof verification. The process for setting up on the server is akin to what's done on the front-end:

    • Initialize the sismoConnect variable by assigning it to SismoConnect from the package.

    • Feed it an object that contains the configuration (which includes your appId and the vault impersonation details, if any) that mirrors the front-end setup.

• ZK Proof Verification:

  • Using the sismoConnect variable, invoke the verify function. Supply it with the ZK proof (or response) obtained from the front-end. Also provide an object containing additional setup details (like auths and claims) that were used when creating the front-end.

    • It's imperative that this server-side setup aligns with the front-end to ensure accurate proof verification. Any discrepancy can result in the proof getting rejected.

• Data Extraction:

  • From the results of the verification, you can retrieve the vaultId. To extract the number of tokens the user opts to reveal, use result.claims[0].value.

  • Given that the token claim is optional, a user might choose not to submit one. They might refrain from doing so either because they don't possess tokens or they might not want the discount. Hence, set the tokens variable dynamically: assign it to zero if no claim is presented, or assign it the revealed token value if there's a claim.

• User Database Update & Response:

  • Augment the create function to incorporate the tokens value, enabling it to be saved in your database.

  • Subsequently, return the tokens value to the front-end for further processing or display.

Note: If you deploy the Impersonation Mode, the vaultId will be randomized. This means a distinct user will be stored in the database each time a subscription is made. Always remember to handle this mode judiciously to prevent unwanted discrepancies.

9. Final Frontend Integration: Adjusting Payment Logic for Discounts

To ensure a seamless user experience, you need to adjust the frontend to dynamically incorporate any potential discounts for NFT holders. Here's how to achieve this:

Steps:

• Update Payment Logic:

  • Navigate to Sismo.tsx located in app/components/Sismo.tsx.

  • Given that the number of tokens is stored as a state variable, you can dynamically adjust the price. Specifically, for each token the user owns, you'll provide a saving of 0.001ETH.

  • In the subscribe function, right after setLoading(true), introduce a constant price variable. It should be defined as:

    const price = Math.max(0.1 - (tokens || 0) * 0.001, 0)

    This equation adjusts the price based on the discount, but will cap the price at a minimum of 0, especially for users who own 100 tokens or more.

  • Now, adapt the payment function to use this dynamic price. Convert the price to the appropriate format using:

    parseEther(price.toString())

• Display Discounts:

  • If a user is authenticated, integrate an h4 HTML element just above the button. This element will display the quantity of tokens the user has unveiled, the savings they've achieved, and their adjusted total payment.

10. Recap and Conclusion

The integration process is complete!

In summary, an offchain Sismo Connect integration involves:

• Creating an App in the Sismo Factory: The primary goal here is to obtain the crucial appId.

• Configuring Sismo Connect: This configuration must be done both on the frontend and the server. You'll use the obtained appId and, if required, enable the "impersonation mode" with selected accounts. This makes testing more straightforward.

• React Button Configuration: Set up the React button. Determine which proofs you need to request from your users.

• API Creation for Proof Verification: You'll need to set up an API that can verify user proofs offchain.

And with that, we've reached the finish line. Congratulations! 🎉

To recap, you've transformed a straightforward request for vaultId into a more sophisticated multi-request system that includes vaultId + group membership. This transformation lets you craft a mini "Only Fans" style platform that offers optional discounts derived from privately-aggregated data. Most importantly, every request made respects user privacy. At no point is the user's Ethereum address ever shared or exposed, all thanks to the data aggregation capabilities of Sismo's Data Vault.

Six months have elapsed since OpenAI released ChatGPT. As an open-access online chatbot, ChatGPT enables users to pose questions and seek content. Within two months of its public launch in late November 2022, ChatGPT exceeded 100 million monthly users, thus setting a record as the fastest-growing web application globally. This sparked an intense discussion about AI, with OpenAI's CEO, Sam Altman, even addressing the topic in front of Congress earlier this month. The world buzzes with speculation and debate, focusing particularly on the potential for AI to induce massive job losses due to the productivity surge that large language models (LLMs) could instigate. While this long-term concern may have some basis, I contend that in the short term, this technology will not merely refrain from replacing you but will also assist you in acquiring the skills for your dream job.

For a reasonable investment of $20 per month, individuals worldwide can now benefit from a personal tutor, equipped with knowledge on virtually every internet topic. This tutor can provide practice problems, simplify intricate concepts, critique your work, devise a lesson plan, and offer much more. Since its launch, I've been utilizing it as my tutor, and it has proven to be a game-changing resource. The self-taught software development journey I embarked on a year and a half ago would have been considerably more streamlined and fruitful had this tool been available from the beginning.

According to a survey conducted by the Pew Research Center in March, while about 58% of U.S. adults are aware of ChatGPT, only 14% have given it a try. This is a largely untapped resource offering substantial opportunities that most people are overlooking. By seizing this opportunity, you'll position yourself advantageously in your pursuit of your dream job.

To provide a clear picture of my learning process using ChatGPT, let's take the example of learning to code backend servers. I start by watching a YouTube tutorial on the subject, taking notes on a second monitor with ChatGPT ready for questions. As I progress through the tutorial, any doubt or question that arises is promptly posed to ChatGPT for a simple explanation. If the first explanation is insufficient, I delve deeper with follow-up questions until I've grasped the concept. Once the tutorial ends, the practical application of the skills I've just learned begins.

Before I dive into the coding itself, I use ChatGPT to craft multiple-choice questions that gradually increase in difficulty, fortifying my comprehension and readiness for the tasks ahead. Whenever I confront difficulties or need additional clarification, ChatGPT serves as my go-to resource. Moving on to the practical phase, I request ChatGPT to come up with a simple project for me to code. But it doesn't stop there; ChatGPT assists in devising an outline or a roadmap to approach the problem efficiently. This approach ensures a systematic process in problem-solving, critical in coding. Once prepared, I transition into the coding phase. If I encounter an error, need guidance, or a code review, ChatGPT is at the ready. After I finish my coding, a review session with ChatGPT is mandatory—it invariably offers feedback to improve my work. If I need further practice, I ask ChatGPT for a more challenging problem, continuing this iterative and responsive learning process to ensure my steady progress.

The emergence of powerful AI tools like ChatGPT brings us to a crossroads. We find ourselves faced with an important decision, one that could have significant ramifications for our personal and professional lives. On one hand, there is the fearful narrative of job loss due to AI-driven automation, which, while plausible, overlooks the other side of the coin: the untapped potential of these tools as tremendous facilitators of growth and learning. By embracing AI like ChatGPT, we can turn a potential threat into an invaluable ally. Instead of succumbing to AI-induced job loss, we can utilize these tools to enhance our skills and secure our dream jobs. The choice is indeed ours

Screenshots of Interactions with ChatGPT:

Imagine owning all your social media data, seamlessly importing it from one app to another. No more losing followers when switching platforms or getting locked out by a site's whims. Welcome to the power of Web3 social media—a game-changer for creators. You can carry your followers, posts, and comments with you while monetizing your content like never before.

Dive into how Lens Protocol, a Web3 social protocol, is shaking up the social media landscape. Traditional platforms like Twitter, Facebook, and Instagram control both their web applications and underlying databases, leaving user data at their mercy. Web3 social media disrupts this model by giving users control of their data on a decentralized database. Built on smart contracts deployed on Ethereum's Polygon sidechain, Lens Protocol enables anyone to create applications that interact with its smart contracts, accessing and using data stored on the blockchain. This results in permissionless, public data available for anyone to use in their apps.

This open accessibility introduces a new level of competition, as anyone can build a web application that interacts with the database. Social media giants like Facebook, Twitter, and Instagram have remained relatively unchanged because they've dominated the market without needing to innovate. Web3 social media, however, forces companies to continuously improve their products or risk being outpaced by new competitors. This constant competition drives innovation and ensures a better user experience.

Creating a profile on Lens involves using smart contracts to generate a token storing your profile information. Your wallet owns this token, giving you full control over your data—a stark contrast to platforms like Facebook. One significant advantage of this new model is the ability for creators to retain their followers, even when switching platforms. Picture a creator with 5 million Vine followers. As the platform fades and TikTok emerges, they don't have to start from scratch. With Lens Protocol, they can log in and retain all 5 million followers, maintaining their brand momentum.

Lens Protocol's modularity unlocks creative freedom, allowing users to customize their posts and how they can be collected. Content creators can tokenize their work, introducing scarcity and additional revenue streams. For example, Taylor Swift could tokenize an announcement for her upcoming comeback tour, limiting the supply to 10 collectible posts at $100 each. Fans would likely pay far more than $100 to collect that post, generating a new monetization form for creators. Users can set rules about who can follow them, creating a Patreon or OnlyFans-style platform without a single company controlling it.

But there's a catch. Building an app on Lens Protocol isn't as simple as directly interacting with the blockchain. Instead, the team combines a Web2 stack with the blockchain layer. Reading data from Lens involves accessing their internal database, powered by PostgreSQL, Redis, and GraphQL. Writing data still happens directly on the blockchain, but you need to ensure your interactions are in the correct format for Lens' "indexer" (smart contract event listener). You might question Lens' centralization, given the use of an internal database. While Lens' database gets all of its data from the blockchain, it's worth pondering whether this setup offers the same security level as a DeFi app or if it's more susceptible to hacking. Answers depend on your perspective and concerns. As for speed, transactions can take 2+ minutes to finalize, even on the Polygon sidechain, which may raise short-term scalability concerns.

In conclusion, Lens Protocol revolutionizes social media by empowering users to own their data, decentralize storage, and foster openness and collaboration among applications. This user-centric approach provides creators with innovative ways to monetize their work and connect with audiences. Lens Protocol paves the way for a more equitable, transparent, and flexible digital landscape, shaping the future of social media.

First, I would like to begin this post by paying tribute to Takeoff. RIP and thank you for inspiring the title of this piece. As the Arbitrum airdrop is set to launch tomorrow, I wanted to create a post explaining the concept of an airdrop and its significance. Most cryptocurrency companies generate revenue by utilizing a token that enables token holders to vote on company decisions. This establishes a flat, democratic structure where each token represents a vote. A unique aspect of tokens is the practice of distributing them to early adopters through a process known as an "airdrop."

Since the blockchain is public, companies can identify addresses using their product and directly send tokens to those users. Arbitrum, a layer 2 solution on Ethereum, is airdropping 11.62% of its total tokens to early users. Users will receive tokens simply for trying out the product. At a predetermined block number, a smart contract will allow eligible users to claim ARB tokens based on the specific criteria set by the project developers. This method of rewarding early adopters is made possible by the transparent nature of blockchain technology, which allows companies to identify users and airdrop tokens directly to them.

Why is the concept of airdrops important? To understand this, let's first take a look at how companies traditionally distribute value to their users in conventional markets, such as through equity. The company's ownership starts with the founders, who then sell a portion of the company to venture capitalists, and eventually, some shares are offered to the public through an initial public offering.

For instance, consider Uber. When you first used Uber, it was likely due to a friend sending you a $10 referral link. If you enjoyed the service, you continued using it. For just $10, Uber could potentially retain you as a customer, reaping various benefits. Your usage data helps the company pitch to VCs for more funding, while your continued use allows them to test new features, all at the cost of a mere $10 referral bonus. Users' first opportunity to acquire equity in a product they've been using for a long time comes late in the company's life cycle during its IPO, and they often face the risk of being dump on by insiders.

Now, imagine if instead of a $10 bonus, early Uber drivers and riders received company shares for being early adopters and testers of the product. This is how airdrops work in the crypto space. Users receive tokens that represent a stake in the project, and as they use the platform more, the more tokens they can potentially receive. Take the example of Arbitrum. When it went live, many people wanted to test all the dApps on the platform for various reasons, including the possibility of an airdrop. The fact that Arbitrum built a good product kept users in the ecosystem, and they were ultimately rewarded with tokens.

Airdrops enable crypto companies to align their interests with those of their users, fostering a stronger sense of commitment and engagement. Users are incentivized not only to try new products and services but also to continue using and supporting them, as they stand to benefit from the project's success. This creates a win-win situation, where both the company and its users share the upside of the project's growth and development. Consider a scenario where there are two different Ubers—one offers a $10 discount on your first ride, while the other provides a possibility of earning equity in Uber through an airdrop. Which app would you choose to use?

Furthermore, tokens distributed through airdrops are often more evenly spread across a broader user base, ensuring a more decentralized network. A more decentralized network can result in increased security, resilience, and fairness within the ecosystem. Instead of venture capitalists or wealthy individuals holding a majority of the equity and upside, a wider range of participants can benefit from the project's success. In conclusion, airdrops present a transformative approach to rewarding early adopters in the crypto space, fostering stronger commitment and engagement while aligning the interests of both companies and their users.

Countless articles discuss why blockchains embody freedom technology, but I want to offer my distinct perspective. Our story starts with the first financial crisis in 2008, as we might be navigating a second one now. When depositing money in a bank, your banking app displays your balance, but did you know the entire sum isn't physically in the bank? Before 2008, large banks needed to hold only 10% of these funds. However, since the COVID pandemic, this requirement has dropped to 0%. Theoretically, if everyone requested their money back, the bank couldn't provide it.

Satoshi Nakamoto believed there must be a better way. The first block of Bitcoin includes the message, "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks." For the first time in the digital age, you can genuinely own something online without a third party – Bitcoin and this asset is available to anyone.

Before exploring the blockchain world, I didn't realize the numerous restrictions on asset ownership for Americans and people globally. In the US, individuals earning less than $200k cannot invest in private companies, hedge funds, venture capital funds, and some real estate investments. Internationally, the list expands. While Americans enjoy the US dollar's stability, not everyone can access it. Some countries enforce currency controls, limiting foreign currency purchases or investments in US stocks, bonds, or mutual funds. Others necessitate regulatory approval or impose higher taxes on foreign investments. Bitcoin provides a universally accessible asset without ownership disputes. Issues like disagreements over country recognition, such as Israel and Palestine, don't apply to the Bitcoin network. Anyone can run a Bitcoin node, view the blockchain, and verify ownership, ensuring a truly fair and unrestricted system.

This asset, Bitcoin, can never be subject to hyperinflation. It’s written in it’s code that there will only ever be 21 million in existence. Inflation is wreaking havoc across the globe, eroding people's purchasing power, exacerbating economic inequality, and causing the cost of living to soar. This makes it difficult for individuals and families to afford basic necessities, pushing them into poverty and hindering their ability to achieve financial stability. Countries like Zimbabwe and Venezuela have experienced hyperinflation, while G20 nations such as Turkey and Argentina have seen their currencies inflate over 80% annually. Bitcoin offers an alternative that cannot be inflated away, providing a potential safeguard against such economic turmoil.

Another aspect worth considering is international payments. Traditional methods, like Western Union, require fees of $20-30 and take weeks to process. Bitcoin doesn't differentiate between sending to a nearby computer or a company across the globe. For a small fee, transactions complete within 30 minutes to an hour without a third party.

The US government, through an entity called OFAC, prohibits interaction with countries like Iran. If you attempt to send money to support female protesters there, your payment will be blocked. However, this limitation does not apply to Bitcoin, as it enables transactions that cannot be censored or blocked by any government authority. We rely on Venmo, Cash App, and PayPal, which can become problematic. The Canadian trucker protest demonstrated that governments can seize one's freedom to transact. This sets a precedent where individuals can lose their transactional freedom without due process. On the Bitcoin network, such scenarios are impossible, preserving our freedom to transact – a liberty we surrendered when transitioning online.

However, Bitcoin consumes significant energy to maintain the network and is limited in programmability, only allowing sending and receiving. Bitcoin paved the way for Ethereum, a more versatile and energy-efficient option.

Ethereum provides all the benefits of Bitcoin, along with several additional features. First, let's discuss the energy consumption and security of Ethereum compared to Bitcoin. Proof of Stake (the consensus algorithm the network uses for coordination) consumes 99.988% less energy than Proof of Work (used by Bitcoin). Gold mining uses 240 annual TWh, Bitcoin 130, YouTube 244, while Ethereum consumes only 0.0026. As of March 16, 2023, Ethereum is also more resistant to 51% attacks (an attack where someone could hijack the network). To carry out such an attack on Ethereum, you'd need to spend $103 billion, while attacking Bitcoin would cost around $53 billion, almost half the price.

The most significant innovation Ethereum introduced is programmable money. For the first time, you have all the benefits of Bitcoin, plus the ability to create apps that use your funds. Anyone can develop a decentralized app (dApp) and deploy it to the Ethereum network for users to interact with. These dApps enable the exchange of digital assets (money or NFTs) based on specified conditions. Just as we've programmed apps to perform tasks when buttons are clicked, the same can be done with money without the use of a third party.

So far, people have created tokens (custom currencies for various purposes), borrowing/lending platforms (decentralized protocols allowing users to earn interest on deposits and borrow assets), decentralized exchanges (DEXes, which enable direct wallet-based token trading), and non-fungible tokens (NFTs, unique digital assets) among others. It might seem unnecessary for those with access to traditional financial services, but 1.7 billion people worldwide lack banking access. For them, the ability to securely access USD via USDC and earn interest through platforms like Aave and Compound represents a revolutionary shift in financial opportunities.

Even for people in developed countries like the United States, using dApps can be a more straightforward and efficient alternative to traditional financial services. Opening a high-yield savings account can be complicated and time-consuming, with unclear terms and conditions. On the other hand, using a dApp to earn yield is as simple as connecting your wallet, depositing funds in a borrowing/lending protocol, and withdrawing your assets whenever you want.

As the world becomes increasingly digital, there are three potential outcomes in terms of currency: company-specific tokens (e.g., Amazon or Meta bucks), Central Bank Digital Currencies (CBDCs), or cryptocurrencies. The first two options can result in individuals being "debanked" for various reasons, whereas the latter provides more freedom. Which option do you think offers the most liberty?

The world is becoming more centralized, and people can be banned with just the click of a button. Consider the taxi industry a decade ago – a decentralized sector with little knowledge about its customers. You just paid some cash and hopped in the yellow cab. While Uber and Lyft revolutionized transportation, a future dictator could easily ban people from these platforms, but not from traditional taxis. This principle also applies to Facebook, Apple, Amazon, and Microsoft. While these businesses have created trillions of dollars in value, they are vulnerable to being hijacked by those with malicious intent. For instance, upon the request of the Chinese government, Apple restricted the ability of Chinese protesters opposing COVID lockdowns to use the AirDrop feature for sharing information about the protests.

Before concluding, let's touch on NFTs. Society often struggles to adequately compensate creative professionals, despite the joy and value they bring to our lives. NFTs offer artists a new way to generate additional income. They can create digital collectibles or exclusive content, fostering a direct connection with their fans and supporters. By offering limited editions and personalized experiences, artists can build loyalty and encourage long-term patronage. Additionally, when an NFT is resold on a secondary market, creators can receive royalties, ensuring continued income from their work.

Cryptocurrencies and NFTs have introduced unprecedented levels of freedom into society. These innovations enable individuals worldwide to utilize programmable money as they deem appropriate, regardless of their location. Just as there is no CEO governing email usage due to the immense power it would concentrate, the same principle should apply to digital currency. Nevertheless, this future is not a foregone conclusion, and I am committed to contributing my efforts to make it a reality.