Vitalik Buterin's Nanyang Technological University Speech Transcript: "Ethereum's Past and Present"
TechFlow Selected TechFlow Selected
Vitalik Buterin's Nanyang Technological University Speech Transcript: "Ethereum's Past and Present"
From the birth of Ethereum to the vision and realization of "smart contracts," and the transformation of Ethereum's "consensus mechanism," these milestones destined to be recorded in blockchain history are narrated by Vitalik himself.
Navigating Web3 tides with focused insightsTranslation: fanfan
Produced by: DeThings
Editor's note: This article is a keynote speech delivered on September 6 by Ethereum co-founder Vitalik Buterin at Nanyang Technological University in Singapore. Unlike his talk at KBW (Korea Blockchain Week) on September 5, which focused on "challenges and solutions facing Ethereum," this presentation was broader in scope—titled “Ethereum’s Past and Present.” He walked through Ethereum’s origins, from the early vision of smart contracts to their implementation, and the evolution of Ethereum’s consensus mechanism—milestones that are destined to be recorded in blockchain history. Revered as the "V God" in China's blockchain community, he seems always dressed in T-shirts, shorts, and sneakers. The nascent crypto world has gone through multiple cycles, with countless people rising and falling along the way, but this pioneer has never stopped walking forward.
Below is the full transcript of the speech:
The Birth of Ethereum
Today I’d like to look back at Ethereum’s history—starting from its beginnings in 2013 and 2014, some of the changes the project has undergone since then, and how our thinking about certain problems has evolved compared to five or ten years ago.
We released the Ethereum white paper in 2014, which basically laid out our initial vision for Ethereum. However, the white paper didn’t go into detail about the underlying ideas behind some of these concepts. Ethereum is a decentralized system, similar to Bitcoin. It's a blockchain, but unlike earlier systems that tried to support just one application, Ethereum allows users to build their own applications. This means users can write their own application code and upload it onto the blockchain, where the application can then run autonomously.
At the beginning of the white paper, I mentioned several ideas proposed by others, as well as one idea I started exploring: issuing custom assets on top of Bitcoin. Today on Ethereum we have ERC-20 tokens, but back then there were Colored Coins—an early attempt to issue new assets on Bitcoin. Interestingly, a specific version of Colored Coins has recently been reintroduced into the Bitcoin protocol, so they seem to be regaining attention. But Colored Coins were just one application. You could use them to represent ownership of physical items—what was then called smart property. You could also have other types of assets, such as domain names. You could build a system on the blockchain to register websites, usernames, track user reviews and app ratings, and more.
From Vision to Reality: The Journey of “Smart Contracts”
All of these applications can be implemented in a distributed manner on the blockchain. The concept of smart contracts is that you can have computer programs on the blockchain that directly control digital assets. An asset doesn't need to be owned by an individual—it can be owned by a program. This idea of smart contracts enables many more complex applications. For example, you can create prediction markets, financial instruments like stablecoins and leveraged products, and much more—all definable via smart contracts. Additionally, there's the concept of DAOs (Decentralized Autonomous Organizations), which essentially use smart contracts to implement voting or governance logic for entire organizations on the blockchain. Instead of relying on legal systems to resolve internal disputes, you can conduct voting directly at very low cost.
Many of these application-level concepts have persisted and continue evolving. We once had Colored Coins; now we have ERC-20 tokens. We once had smart property—which didn’t make much progress—but today we have the on-chain domain name system (ENS), which many people use. My blog, for instance, has been uploaded and may already be accessible via ENS. If you're using an Ethereum-supporting browser like Brave, simply typing eth.link will bring up the front-end interface of my blog.
These are usable tools involving smart contracts and DAOs. Around the world, various types of DAOs are operating using different logics. While they haven’t yet seen large-scale adoption outside the ecosystem, they do exist—and some have been functioning for years. These are some of the applications we see today. Clearly, new applications have emerged, some of which surprised me. For example, NFTs (non-fungible tokens) are one such case. Yet many things existing today closely resemble what we imagined ten years ago. The same goes for research into consensus mechanisms. Today, Ethereum has finally become a proof-of-stake chain. Proof-of-stake greatly enhances security and reduces Ethereum’s energy consumption by over 99.9%. Previously known as “the Merge,” before this transition Ethereum consumed nearly 40% of Singapore’s electricity usage. Now it’s reduced to almost zero. Thus, the state transition is complete—but this was the result of nearly a decade of work within the ecosystem. The first five years of proof-of-stake research were mostly theoretical—we tried to understand the nature of proof-of-stake and explore various design options, eventually converging on a specific version that actually works.
The Evolution of “Consensus Mechanisms”
In a 2015 blog post, we described a mechanism called “consensus mechanism,” aiming to encourage validators to send a series of messages expressing confidence in specific block heights, enabling more efficient consensus. Later, we found that our original consensus mechanism had many issues—it was too complex and ultimately less effective than Casper, the protocol it later evolved into. But this was a step forward as we deepened our understanding of the field.
In fact, in 2018, I published a series of tweets reviewing the progress of Ethereum’s proof-of-stake research, tracing how we moved from initial exploration to proof-of-stake chains and finally settled on a concrete algorithm.
First came the research phase. Then, for the next four years, the focus shifted to scalability. Scalability is critical for Ethereum because, even today, Ethereum can only process between 10 and 20 transactions per second (depending on transaction complexity and size, this may range from 10 to 50). This level of scalability is extremely limited. To support mainstream finance, mainstream payments, and global systems, we need to handle around 100,000 transactions per second. At only 20 transactions per second, it would take approximately 4 million seconds—about 13 years—for a population of one million people to each execute a single transaction on Ethereum. Therefore, improving scalability is crucial.
Early attempts to improve scalability were called “sharding,” and what we’re doing now still falls under a form of sharding—though many different designs and modifications have been incorporated into the mechanism since then. The basic idea is that traditional blockchains, like Bitcoin, require every computer in the network to process every transaction, limiting scalability.
We changed this design. Instead of every node processing every transaction, each node processes only a small subset. This is similar to how BitTorrent works: data is split into chunks and shared among users, so no single person needs to store the entire file—even when demand is high. The challenge lies in maintaining a coherent historical record while preserving consensus on the order of events—essential for building financial systems and more. This is a technical hurdle. One of our earliest concepts was sharding, where transactions are divided into groups, each handled independently by separate sets of nodes. It was an extremely complex idea. Since then, we’ve worked hard to reduce complexity. We had to make things as simple as possible because we knew that if writing a specification took two months or two weeks, development might take two years—but if specification took six weeks, development could stretch to six years. We made great efforts to simplify, accepting many trade-offs, and eventually arrived at today’s architecture.
Technical Progress and Challenges Facing Ethereum
Interestingly, the topics we discuss today regarding Ethereum’s technical progress are remarkably similar to those discussed six years ago. This slide comes from an Ethereum conference—I believe it was around the time I outlined some of Ethereum’s key challenges: privacy, consensus, smart contract security, and scalability. If you asked me or anyone else today what Ethereum’s biggest challenges are, you’d get essentially the same answers: privacy, consensus, smart contract security, and scalability.
These challenges remain the same today as they were six years ago. But at the same time, I find it interesting to reflect on the progress made since 2017. For example, in 2017, privacy was purely a technical challenge. There was a new type of cryptography called zero-knowledge proofs, specifically zk-SNARKs. These allow you to create cryptographic proofs of certain mathematical properties about your data without revealing any other information about the data itself. This was first used by Z.cash, a privacy-focused cryptocurrency launched in 2016, which employed zk-SNARKs to achieve anonymity. How did it work? When spending a coin in Z.cash, instead of directly referencing the spent coin, you provide a proof that you’re spending an unspent coin—without disclosing any additional details about that coin. You prove exactly what needs to be proven to maintain a sound monetary system, while keeping all other information private.
Back in 2017, the challenge was simply bringing this technology to Ethereum and making zk-SNARKs functional. These techniques rely on complex mathematical theories, particularly elliptic curve cryptography. To apply them, we added layers called “zero-knowledge statements”—code that enables the use of zk-SNARKs on the blockchain. So, using smart contracts, developers could actually build applications on Ethereum with the same privacy-preserving logic. That was the state in 2017. By 2023, the technological landscape has advanced significantly, with sophisticated zk-SNARK libraries, development environments, tools, and protocols. We now have a long list of exciting technologies including StarkWare, ZK Rollups, Cairo, and more. In fact, privacy may now face another bottleneck—not technical, but legal—related to whether tokens generated by these systems are accepted by the broader financial system. For example, Tornado Cash faces legal issues and can be viewed as a privacy layer on Ethereum due to its use by hackers.
As a result, a concept called “proof of innocence” has emerged. The goal of proof of innocence is to let users prove their tokens passed through a privacy system but did not originate from a hacker. You prove you’re not one of the bad actors, without fully disclosing where your tokens came from. A paper on this idea will soon be released. Several companies have already proposed different solutions. Much work remains to tweak these systems so that users transferring tokens to exchanges can do so without raising excessive suspicion from the exchanges.
Additionally, significant work is being done on verifying zk-SNARK proofs efficiently—aiming to lower verification costs. This is driven partly by zk-Rollups and aggregation protocols. The difference between 2017 and 2023 is that in 2017 we were merely trying to get the basic building blocks to function, whereas by 2023, those components already work well. Our focus now is optimizing them and doing more advanced integration work to better connect with the mainstream world. On consensus security, in 2017 we were finishing the research phase of proof-of-stake development and just beginning implementation. By 2023, Ethereum has fully transitioned to proof-of-stake and is now entirely based on it. But challenges remain: reducing protocol complexity, enhancing security, addressing centralization risks, making participation easier, and simplifying something called PDS (perhaps referring to staking delegation or similar), so users don’t need to run complex algorithms to optimize returns.
Regarding smart contract security, solving this problem has likely seen the slowest progress among the four. In 2017, it had only been a year since the DAO hack, when the DAO—a smart contract managing about $150 million in funds—was compromised. The hacker attempted to flee with the funds, but ultimately the Ethereum community collaborated to return the money to the original owners.
That was the only incident of its kind in Ethereum’s history at the time, so in 2017 it was still fresh in everyone’s memory. People were deeply concerned about security, leading to widespread efforts to improve programming language safety and overall project robustness. By 2023, much of this work has paid off. I believe the frequency of hacks has dropped significantly. When attacks do occur, they usually involve projects that are far more complex—about 20 times more complex than those in 2016. If your project today isn’t 20 times more complex than those from 2016, it’s generally quite secure. Many systems have operated for years without being hacked—an impressive achievement. Other security improvements have also taken place.
Shortly after the DAO incident, there was an event known as the “Shanghai DoS attack,” where attackers exploited multiple vulnerabilities in the Ethereum protocol itself, sending transactions designed to slow down the entire blockchain. We spent months releasing updates almost daily. I knew hackers were finding new exploits every day, so we continuously fought back and patched minor issues. After four years of effort, through a series of changes and improvements, these security flaws were finally resolved. EIP-2929 brought many enhancements to DeFi codebases. Gas optimizers have also done remarkable work. Overall, many security issues have been quietly fixed over time.
When transitioning from proof-of-work to proof-of-stake, the major event was “the Merge.” On the security front, there was no major incident—because the goal was precisely to avoid any disruption. Sometimes it’s important to remember that nothing happening *is* good news. So I believe real substantive improvements have been made, although many ongoing issues persist.
Going back to 2017, sharding was just an idea. Back then, we also heavily discussed state channels and adders—large-scale layer-2 solutions. Around 2020, everyone shifted toward Rollups. Today, there are various Rollups—ZK-Rollups, Optimistic Rollups, and others. These Rollups are beginning to shed training wheels, becoming truly decentralized and taking important steps in that direction. This year, Polygon also made significant strides. Currently, we’re continuing to work on decentralizing these systems, strengthening the security of proof systems, and speeding them up—so that proving a block currently taking five hours might take only two minutes in the future, and perhaps eventually just 12 seconds.
While we’ve made substantial progress, problems remain—but huge advances have occurred in each area. There’s also extensive work in other areas, such as Verkle trees. Five or six years ago, stateless clients were just a concept. Now, Verkle trees have become a full-fledged project involving hundreds of people and thousands of lines of code, with deep consideration on how to integrate them into Ethereum. They could become operational within one or two years. There are also improvements to the EVM—maximizing and simplifying it. Account abstraction is a very important direction, and everyone who supports it has their own reasons. I support account abstraction because it’s fundamentally very flexible. The goal of account abstraction is to replace key-controlled accounts with accounts controlled by computer programs. With program-controlled accounts, users can define custom logic for approving transactions. You wouldn’t just have one key—you could have three keys, some controlled by others. You could implement multi-factor authentication. You could store keys in trusted hardware modules present in modern smartphones, use hardware wallets, or even combine multiple hardware wallets. You could authenticate using complex methods like email accounts—even using an email account to verify an Ethereum address.
Back to Reality and Practical Applications
Turning to real-world and practical applications, one story I often mention is my trip to Argentina around 2021. I was struck by how many locals were actively using Ethereum—they were genuinely using cryptocurrency. I remember on Christmas Day, most places were closed, so I was looking for a café. The first one I found, the owner recognized me. He told me he had encrypted a wallet, so I asked if I could pay in Ethereum—he said yes, and we completed the transaction using Ethereum. But here’s the catch: he wasn’t using the Ethereum mainnet—he was using Polygon. I appreciate what DeFi has achieved, as it makes cryptocurrency more accessible to people without banking systems. Without DeFi, they’d have no alternatives. I think providing these options is valuable.
But at the same time, I believe as an ecosystem, our goal should be to gradually reduce single points of failure in the future. I think even the Ethereum Foundation agrees with this. Decentralization has been increasing steadily. We’re working on solving this, but the reality is that truly decentralized access doesn’t actually exist for someone like that café owner. Even though technically greater decentralization is possible, the pathways to decentralization aren’t accessible to these token holders. So, genuinely improving things and making them better for the people on-chain remains a major challenge.
So, fundamentally, I don’t know whether we can enable these token holders to actually use the chain, benefit from its decentralization and global permissionless advantages, and whether we can realize a world where people truly benefit from all the application areas we’ve been thinking about since 2013. Can we turn these concepts into genuinely beneficial applications that serve real people?
This technical work has followed a remarkably consistent direction over the years, which I find fascinating. The tools have changed—we weren’t even considering these issues ten years ago—but the principles remain the same. Now, however, I believe greater emphasis must be placed on actual adoption and usage. Solutions involve technical work, but they’re more distributed across different layers. This means the Ethereum Foundation, core Ethereum development teams, and client teams are no longer the sole entities doing critically important work. Wallet companies are doing vital work. Application developers are doing vital work. Even those building enterprise blockchains contribute meaningfully. This is something people have tried for years. But I think if we view such efforts as Layer 3s built atop Ethereum, it becomes possible to make them viable—delivering real decentralization benefits to those who want to use them and making the whole system truly functional.
These are some of the biggest shifts we’ve seen over the past decade—from an initial concept to a gradual process of tackling real-world usage challenges. It’s been a long and slow journey. I hope that in the next five years, we’ll be able to resolve most of these challenges.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@DethingsNews
