I am muted. Yes. Okay. Am I ready to start? Okay. Hold on one just second. Let me open the slides up. Okay, perfect. So, thank you all guys for coming. It's great, glad to see so much interest in Ethereum from all of you guys in India and excited to see what happens out of both this week and all of the other projects that are happening on Ethereum in the country. This event I wanted to focus more on the academic side of things and really talk about ways in which Ethereum has benefited from its relationship with academia and a lot of academic ideas and researchers outside of academic contexts worldwide. And talk about what are some of the opportunities to collaborate between research and the use cases and needs in Ethereum in the future. So to start off, Ethereum has many academic dependencies, right? And over here I have a chart of what I think are some of the really important ones. I think about this as being about four categories. So starting from the right, we have economics. Cryptocurrency is currency and Bitcoin has from the start been a very economic experiment. Over in the Bitcoin community, I think people even value Bitcoin the asset much more than Bitcoin the blockchain. They see the blockchain as being a tool and the asset as really being the primary product. And Ethereum is much more general purpose, but ETH the asset is still a very essential part of the whole system. And I generally think of the economics in all blockchains as being split into a few parts. The two biggest ones: one is macroeconomics. This is both looking at the macroeconomics of what happens in a blockchain economy and how cryptocurrencies and blockchain-based assets could interact with the economy worldwide. What is the significance on the world that things like Bitcoin and Ethereum might have? How will they interact with existing currencies? How will they interact with international trade? These kinds of topics are I think even topics that people on the side talk about even more than for Ethereum, but it's I think also a really important topic in Ethereum itself. And I think as I'll talk about later, a different kind of macroeconomics is becoming very important for Ethereum as well. And then the second category is game theory and mechanism design, so much more like micro things. Here the core problem is basically how do you create incentives to make a blockchain safe? How do you create incentives for the miners, proof of stake participants, other actors in a blockchain to one, participate in the network and actually process transactions and run nodes, and two, to do this in a way that is actually honest and following the rules of the protocol instead of trying to cheat the system for their own gain. So that's economics. Second piece is consensus theory. Blockchains are distributed systems and the purpose of a blockchain is to come to agreement on some pieces of information. And there's been a decades-long branch of academic study that deals with algorithms for coming to these kinds of agreements in a distributed network, which is consensus theory. There's two major branches of this. There is synchronous and asynchronous, which basically have to do with what your model of the network is. Are you assuming low latency, high latency, variable, unknown latency? Bitcoin and blockchains of that type are very much in the synchronous category. They assume some cap on the network latency and Bitcoin sets that cap very conservatively and then the block time has to be some multiple of the cap, which is why the Bitcoin block time is 10 minutes. And in Ethereum with proof of stake, it's asynchronous. This is in the same lineage as what usually gets called BFT, even though all consensus has to be Byzantine fault tolerant. This includes things like Paxos, Tendermint, other fancier algorithms that have 1/3 fault tolerance. So a long 30-year branch of study here as well. These algorithms are key to making proof of work and proof of stake blockchains safe and to analyzing how safe specific ones are in practice. Then we have cryptography. Blockchains are cryptocurrency systems and cryptocurrencies use cryptography to verify who is the owner. There's two major types of cryptography that blockchains have historically depended on. One is hashes, algorithms like SHA-256, Keccak, and the other is signatures, which can prove that someone who owns the private key that's connected to some public key actually signs a particular message. And then the fourth is what I would call general computer science. I think the two big branches that Ethereum has benefited from: one is tree structures, so Merkle Patricia trees, key-value trees, different versions of binary trees. And then the other one is virtual machines. Bitcoin has stack-based Bitcoin Script, Ethereum has the stack-based Ethereum Virtual Machine. There's other virtual machines that are being designed. There's also high-level languages that compile to these virtual machines and there's a lot of compiler theory involved. So I would say these are the four major categories. Now what we've also seen is that there's many more subtle dependencies here. EIP-1559, the fee market, this is a feature that became part of Ethereum in 2021. This was inspired by academic auction theory. This was an idea that I had after going to SIGecom '18 at Cornell in the US. And this was also reviewed by Tim Roughgarden, a major mechanism design practitioner, and quite a lot of other people. So a lot of academic auction theory and a lot of mechanism design went into making EIP-1559 work. Then there were many academic contributions to the gas model. The gas model was something that started off being done in a way that was very intuitive and very non-rigorous. But then in 2016 there was a series of denial of service attacks that managed to really slow down the Ethereum chain and make it almost unusable for about a month and a half. And out of this, we started taking more seriously the problem of how to formalize the gas model more. We've actually seen contributions from all over the world for this, some from the US, some from Europe, quite a few from China recently. The gas model is one of those things where anyone can just go and poke at any particular part of it and see how it can be improved. And then also many refinements to the specific version of proof of stake Ethereum uses, Casper FFG and LMD-GHOST. Now SNARKs have changed a lot for Ethereum. The original SNARKs, succinct zero-knowledge proofs, have been this academic branch of computer science that has existed now for more than 30 years. The PCP theorem started the whole field from way back in the 1980s. And the SNARKs really became viable in 2013. There was this algorithm that was designed by Eli Ben-Sasson and others from Israel. This protocol was originally designed for a protocol called Zerocash, which would bring privacy to Bitcoin, and then that ended up turning into Zcash, which was an independent cryptocurrency that is still going to this day. SNARKs have really been important for basically all of the privacy use cases in Ethereum. If anyone has used Railgun, then it really depends on SNARKs. Also the most powerful and the safest scalability ideas for Ethereum depend on the verification feature of a SNARK: the fact that you can use a SNARK to generate a proof for a computation where even if the original computation was very complex, the proof can be very cheaply verified. Now, all of these dependencies, they're going to change a lot in the future. And so, one thing that's really important to appreciate is how Ethereum is changing completely over the first 15 years of its life. The Ethereum of 2030 is not the Ethereum of 2015. And you can see the differences between the two across all of the different categories. If you look at signatures, for example, in 2015 Ethereum used ECDSA. In 2030 we'll likely have quantum-resistant and probably hash-based signatures. Then for the hashes, in 2015 we used SHA-256, Keccak. Now we're using SHA-3, SHA-256, and I expect in the future we'll use a SNARK-friendly hash, most likely Poseidon. Then there's the virtual machine. 2015: the EVM. 2030: there's a lot of moves for using either RISC-V or some prover-optimized virtual machine. Now consensus: in 2015 we used proof of work. As of 2022 Ethereum has fully switched to proof of stake, and the proof of stake is continuing to optimize and we'll likely have single-slot finality by 2030. So in 2015, proof of work, moving into proof of stake. Now a really big change is how the chain is verified. The original Bitcoin and the original Ethereum verification happens through full re-execution: you verify that an Ethereum block is valid by personally re-executing every transaction. In 2030 this will change a lot and verification will happen through a STARK proof. A STARK is a type of SNARK except it uses hashes. So it's post-quantum, it does not have any trusted setup issues. Now another branch that is really important is peer-to-peer networking. The design in 2015 was fairly naive. The design in 2030 will likely use erasure coding and a lot of other techniques. One particular branch of computer science that is going to become very important for us is formal verification. We have this initiative, verified-zkvm.org, where we want to create a formally verified STARK prover for the EVM. We have grants and we have bounties for this. Anyone interested in participating is encouraged to go to verified-zkvm.org. The goal of this is basically to create a STARK prover for the EVM where we have very high assurance that it is secure. This is important because if it's not secure, then one bug in the prover could potentially break the whole chain. And so this is something that we are taking really seriously. And I think in general, all kinds of running code is becoming more and more important to all kinds of critical functions in both blockchains and in the world in general. And at the same time we have these more and more powerful tools to reduce and eliminate the number of bugs and vulnerabilities. And so we need to use these tools. Future areas to collaborate: Ethereum has had a lot of academic dependencies in the past. The ones in the future will be I think in many cases similar in categories but the specific emphasis is going to be different in a lot of cases. So we can start with economics. In economics, consensus mechanism design is always, was, and always will be an important field. This really started I think in 2013 where the selfish mining paper from Eyal and Sirer proved that though Bitcoin is Byzantine fault tolerant up to 49%, it's only game-theoretically secure in a rational model up to somewhere between 25 and 50% adversarial. And they proposed a design for just making that a hard 33%. And also macroeconomics. I think there is going to be a type of macroeconomics that will be important for Ethereum, which is basically the macroeconomy of Ethereum itself. This includes the interactions between staking and DeFi, the consequences of these things on the decentralization of the protocol, designing better proof of stake designs, and so on. Then we have peer-to-peer networking safety. Peer-to-peer networking safety is important and I think historically peer-to-peer networking has been the part of the protocol that we've paid attention to the least and this needs to change. I think ultimately we even need to formally verify peer-to-peer networking properties. We need much stronger forms of denial of service resistance. So a lot of important problems to go and work on. Then virtual machine design. I think the virtual machines for Ethereum in the future will be designed for two things. One is execution friendliness. One is prover friendliness. Execution means basically it needs to be possible to run the virtual machine both in powerful nodes that are building blocks and client-side. And so we want it to be friendly to run on any kind of hardware. And also prover friendliness: it needs to be friendly to generate SNARK proofs for. Then we want to formally verify everything: execution, consensus, everything. And then optimal cryptography everywhere. Basically, could we get hashes and signatures with less than 10x curve overhead? Actually, can we get less than 10x prover overhead for all categories of computation that matter, even including things like AI? Now you might think this is crazy but remember in an LLM almost all of the work is linear. It's matrix multiplication and linear operations are very friendly to doing all kinds of cryptography with. So I think it's more possible than it might seem. Eventually I think we also want extremely low overhead for and eventually in the very long term extremely low overhead even for obfuscation. So a lot of different things to work on that Ethereum needs, that applications on top of Ethereum need, and where I think this ecosystem really presents a lot of very natural use cases for these kinds of work. The categories here are basically the same as what we saw at the very beginning with the chart. Ethereum has computer science, it has economics, it has consensus theory, and it has cryptography. But if you look at the specific algorithms, the details change a lot. And I think we've seen that thanks to both the needs that blockchains bring and the resources that the crypto space has brought, cryptography has advanced massively over the last 10 years and blockchains really need to upgrade to take advantage of all of these new tools. And I think we're happy to collaborate with people who are interested in participating in any of these things. So, thank you.
Okay. Yes, very good questions both. So on the trade-off between execution and prover friendliness, I agree that that trade-off exists. So for example, the Poseidon hash function is far more prover friendly than SHA-256. It can be proven about 100 times more quickly than SHA-256 can. You can prove like 2 million hashes a second on the same laptop. But on the other hand, Poseidon is I believe about 10 times slower. And that's actually much better than it used to be. Before we switched to 32-bit fields, Poseidon was somewhere between 100 and a thousand times slower. But I think in the short term there are a lot of places where we have low-hanging fruit that are just massive wins for both. If you look at the idea of switching from the EVM to RISC-V, this is better for execution because you remove the overhead of an interpreter and it's also much better for provers because the EVM provers that exist today actually work by compiling EVM into RISC-V. And so if you do RISC-V directly, you can potentially remove an entire level of interpretation from the prover. Also on the hashing side, for example, moving from SHA to Poseidon will increase execution time slightly by maybe a couple of percent, but hashes are not the dominant part of execution time and so this is just much more than compensated by the fact that hashing is a huge bottleneck on prover performance together with the VM. So I think in the short term there are a lot of places that we have not taken that are just massive wins for both. But then in the longer term there are real trade-offs that we have to grapple with. On the VM side, for example, even RISC-V is not the optimal VM. There's another choice where we can take a VM that is designed to be prover-optimized and then we can try to trade off and make a design where this VM is both extremely prover-optimized and is friendly for writing RISC-V in that VM. And then if we do that, we'll probably get a little bit slower performance, but at the same time the prover friendliness for pieces that don't use RISC-V could end up being much higher. So I think there's always a balance in both of these cases. And I think the Ethereum core development process has implicitly discovered some ways to kind of formalize that trade-off. When designing gas schedules, for example, we already design around the assumption that we want a particular number of gas per second on a particular amount of hardware. And so I expect that that type of optimization will just turn into a two-dimensional optimization problem and we'll just have to have target numbers both for execution and for proving. On the formal verification side, I think formal verification definitely needs to break out of just being for smart contracts and also be for the layer 1. Because the verified ZKVM initiative that I mentioned, that is exactly for formally verifying a ZK prover of the EVM. This is something that we think is critical for Ethereum's long-term scalability and security. And ultimately, I think we also need to prove the consensus layer, for example. Prove that the Ethereum consensus layer does not have any bugs. Even prove the correctness and the equivalence of different implementations, potentially prove other properties of the system, and then eventually go full stack. So no, I think in the medium and long term these are hugely important problems for us.
