New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

The Future of Blockchain Execution: EVM vs. EVM+/- vs. non-EVM | Avi Zurlo - =nil; Foundation

Ethereum DenverWed, Oct 9, 2024, 12:00 AM

While EVM compatible chains continue to maintain their lead in the infrastructure race, new L1s and L2s powered by EVM +/- or non-EVMs (i.e. SVMs) have picked up steam. This talk will explore the trade-offs around the current and future state of the blockchain execution layer. APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN APPLY NOW https://ethdenver.com/apply

Transcript

Foundation he's going to be diving into the future of blockchain execution welcome AI is this on okay there we go uh Hey everybody I'm AI zurlo I'm a chief product officer at nil Foundation uh nil Foundation was founded in 2018 we've been pioneers of ZK technology ever since we built the world's first circuit compiler uh ZK lovm the world's first uh zero knowledge proof market and uh later this year we'll be releasing the world's first uh ZK sharding L2 for ethereum uh today I'm going to be talking a little bit about the future of blockchain execution uh and this talk is going to be focused primarily around the evm we are at eth Denver uh we are an evm chain and despite what you know you may have heard recently the evm is just fine um and we're going to talk a little bit about that [Music] today okay so to start uh some Basics and the first half of this presentation is going to be a little bit more technically focused if you're like a low-level engineer it's probably very redundant uh but we're just going to walk through a few of the basics of what what makes an execution environment what makes uh a virtual machine um a virtual machine is essentially a uh software computer that runs on top of physical Hardware um and uh it is able to access the resources of Hardware uh via hypervisor and it allows developers to build applications and use tools that may not be native to the hardware that they're actually operating over um and and so virtual machines are are used um for pretty much all programming development today but they're also used for blockchains and this is where we have uh the evm um now the evm is essentially the the rules of the uh correct State transition of ethereum uh the ethereum blockchain um it reads bite the ethereum bite code uh so solidity and Ule and and Viper code gets compiled down through an ethereum compiler uh into a bite code which the evm can read uh it's a stack-based uh machine uh it's fully Turing complete um meaning that can uh compute and process sort of arbitrary computations um and this is very important for smart contracts uh smart contract logic um and uniquely unlike traditional virtual machines it's run by thousands of nodes that uh process this state transition function in Lo step um and this is what gives the ethereum virtual machine its very unique characteristics of of global shared State and and decentralization and so on um now uh the state transition is an incredibly important component of the evm um or and of the ethereum blockchain it essentially takes the world and I'm going to flip to the next slide here it takes the uh the current world state uh some sort of transaction list it applies the state transition function which is essentially the ethereum virtual machine and then it computes the resulting World State and this is how ethereum builds blocks um and nodes process this in lock step and this is how we we move the the blockchain forward um a very another very important part about the ethereum virtual machine are our op codes these are essentially the middle length language and instructions that a program can use um there uh because evm is a a standard stack machine you have typical things that push and and pop uh information from the top of the stack but you also have blockchain specific operations um and these are things like address that pulls you know the current address uh block hash pulls the last 256 uh or hash for the last 256 blocks and every smart contract can be brok broken down into sort of a series of uh sequential oper op codes operations um and the evm uses a gas counter to essentially meter the number of operations that a given transaction can use so a user Smits a gas limit and this sort of caps the amount of op codes you could think um that uh that transaction can consume um and there's also sort of a limit on on how much gas a certain block can consume and there's a target of 15 million and so on but uh details aren't important for now okay so that was a i that thank you for bearing with me that was some of the technical background and Foundation um but why is the evm important well the evm does pretty much everything uh it touches everything uh about the ethereum blockchain it influences everything that a developers do um and this is directly from the EF website the ethereum protocol itself exists solely for the purpose of keeping the continuous uninterrupted and immutable operation of the evm uh so what what exactly does the evm touch it touches the developer experience for uh smart contracts it influences the speed at which the blockchain actually progresses granted uh the execution of of of the blockchain is is sort of a a minority share compared to consensus um it influences your your API compatibility and developer tooling compatibility so uh things like your developer environment uh your wallet support indexer support um these are all influenced by essentially the evm that you implement and then it also impacts Hardware requirements um in particular for ethereum validators and here I'm just going to have a this is a total side note but uh on client diversity which has sort of been a a Hot Topic as of late you may have heard of some concerns about the execution client uh concentration risk around gu um essentially what this means is the ethereum ethereum node is split into two clients execution and consensus execution is what's responsible for running the evm um and right now this is actually an outdated number I think it's maybe at like 64% but uh 64% of execution clients run gu and the risk here is if gu has a bug or vulnerability now the network at large is at risk um side note okay uh now on to some of the good stuff um what are evm alter alterations um what kind of alterations might we make um and and who's going to make them okay so to start uh uh who is actually responsible for these alterations um so historically the ethereum sort of cevs and core contributors were those who were responsible for maintaining the evm um and this lasted for for many years and still persists today um but we also have a number of other blockchains that now live in this universe of the evm uh and these are layer twos uh they are you know rollups and and they're even layer ones uh so now these are the people who and developer teams who are responsible for maintaining the evm um and we can begin to make alterations and the natural question is why well one reason why is that the alterations that happen outside of ethereum core can serve as sort of a test bed of experimentation for ethereum core itself for the layer one um and this is a really nice attribute uh and sort of relationship between L2 and other evm l1s in which uh ethereum core naturally has to be more conservative with how they introduce upgrades and alter the evm whereas l2s um and and and other you know ethereum evm based l1s they can be a little bit more aggressive right and try new things out um they can you know roll things back a little bit more quickly especially in these permission sort of setups um and we have this really nice sort of like you know Synergy between uh ethereum core and and the l2s um oh other way uh but we also have the opportunity for these you know non ethereum core evm blockchains to begin offering new types of functionality for users and developers and uh this is where things start to get really interesting right and so when we talk about evm alterations uh which I'm I'm going to walk through a few uh they're not necessarily for E the ethereum core itself they're for other blockchains who are running the evm who can be a little bit more aggressive in innovating on how the evm actually functions uh and you see here you know everybody maybe one day ends up with a slightly different version of the evm with some baseline standardization okay so what are those optimizations uh we have uh Native account abstraction uh paralyzed execution asynchronized communication between uh two independent state machines ZK optimizations and a few more um so uh Native account abstraction this is probably I mean who who's heard of native or who's heard of account abstraction okay yeah so this is one of the most you know popular exciting new technologies that come out of sort of the last cycle if if we're if we're back which looks like we're back um and this is has huge promise for improving the user experience uh we can eliminate seed phrases replace verification with Biometrics or or social recovery mechanisms uh we can have sort of shared accounts um we can uh give and delicate author authorization of smart contracts to interact with other smart contracts on a user's behalf um and and broadly speaking we have a bit more of a robust Foundation to improve security of uh of wallets um now why might we want to enshrine this into uh ethereum the evm itself um number one there's there's certainly some gas efficiency that we can squeeze out um now it's not huge um but it's there uh but the big one is code bug risk right if um we have a variety of different implementations of count abstraction um you know we're introducing with every sort of nuance and tweak uh sort of a vulnerability surface um that we then need to audit right and so this becomes actually very expensive whereas if we enshrine it into the protocol uh we you know agree on one standard which might have some coordination overhead uh but then we need to Auto it once and it lives there persistently um and this is already underway um there's a the rip which is rollup Improvement proposal uh for Native account abs scrash and ZK sync and starkware and I'm sure many others are are working on this uh at l2s today um who here has heard of paralyzed evm okay so not as many as cration but this is another really hot um area for sort of blockchain infrastructure development um um the idea is that we can take the sort of sequential execution of the evm which is single-threaded and multi-threaded right and run uh the execution of transactions in parallel and this you know holds you know some potential for you know very significant increases in throughput um it uh ultimately helps us solve State fragmentation uh which I'm not going to get too deep into uh but if we can allow a blockchain or in particular particular layer 2 to process more transactions we actually need less isolated uh rollup uh or L2 instantiations because we can fit it more on a general purpose uh Universal layer 2 uh and this is well underway uh I think polygon was actually the first so you know shout shout out to them um but recently monad and say which are uh sort of evm paralyzed evm l1s um having been getting quite a bit of attention um okay asynchronous communication uh this is I think who who who knows what asynchronous communication is okay so we're we're we're we're sliding in in in in the knowledge set but the this is super important um this is essentially core to enabling horizontal scalability um and horizontal scalability is sort of thought of as the most most optimal scaling solution for blockchains because uh we can scale by not increasing the hardware requirements of a particular node but rather adding new nodes to the system of interest um and we need asynchronous communication between these nodes that are essentially independent uh State machines or independent instantiations of the evm to communicate and today the evm does not have this ability to uh communic at asynchronously across uh instantiations um so uh there's actually been a lot of research that's gone into this from sort of ethereum core given their efforts throughout the years for sharding um and this is actually underway at nil uh where we use approvable sharding architecture um and make some modifications to the evm to allow for asynchronous communication and thus horizontal scalability um finally or I think we've got maybe a list of miscellaneous uh alterations but ZK optimizations right um who here is heard and agrees ZK is the endgame yeah um so uh ZK is you know incredibly important for scaling it's also very important for privacy um today the most popular sort of in implement ations of ZK for scaling or rollups ZK rollups those that use the evm uh essentially build a collection of ZK circuits which make up a ZK evm and uh those those circuits actually prove the evm and then and a little bit more essentially encapsulating the entire State transition function of uh of of of an ethereum blockchain right and this ethereum blockchain being a rollup or any other evm based blockchain uh unfortunately in the evm and its naive implementation is not very ZK friendly um in particular one of the biggest bottlenecks is the hash function which is katak so today most and I I want to say all but I didn't I didn't double check um most ZK EVMS uh actually switch out katak for Poseidon right and this allows you to uh sort of decrease proof generation costs as well as proof generation time um we can also and this isn't really an alteration to the evm but we can add alternate VM support uh to a layer two uh that's a little bit more snark friendly a little bit more ZK friendly uh and this is as I said pretty much underway at at every ZK rollup ZK L2 ZK evm project um and then we've got a little bit of time there's a few other uh alterations that uh an L2 might consider uh State size control uh so sort of accelerating State expiration and potentially veral trees um and this sort of decreases the requirements of of storage that a node uh is is sort of enforced uh to maintain adding BLS 12381 which is an elliptic curve that's very common um or more standardized and actually the curve that ethereum itself uses um adding uh uh secp 256 R1 this is the uh this is use widely in trusted Hardware right so if you want to do things inside of a trusted uh execution environment uh this is is a super important addition and then uh we can actually just add all new VMS get you know all together right which uh arbitrum has sort of done really great efforts in adding stylists uh which supports wum um and then uh you know I know we're at eth Denver um and we talked a lot about the evm but there are there are absolutely other virtual machines that hold a lot of Merit in improving the execution of blockchains um the two here I have listed are both sort of ethereum based rollups um I think I think maybe eclipse is now using Celestia but um movement uses the move M um and this sort of prioritizes security it's uh formally verifiable it also has paralyzed execution um Eclipse uh uses the svm the salana virtual machine uh you know big benefit of a paralyzed execution and also local fee markets um but uh I'm I'm here at my last slide um but I just want to end again on the note that the evm is is just fine uh the evm has the most robust ecosystem of developer tooling uh it has the most robust ecosystem of developers uh and you know it's maybe been slow to implement some more Innovative state-of-the-art um uh optimizations because l2s haven't had the opportunity to actually uh you know sort of experiment right in that you they've been focused on just shipping and getting things live now the layer 2 ecosystem are ethereum actually has a critical mass right and and so now I think is is really the right time uh for uh non- ethereum core evm based blockchains to begin experimenting uh you know with you know making the evm uh great again uh and that is all

Automatic transcript — names and jargon may be misspelled.