 The goal of the FVM is to bring programmability to the file point network. This is something that's been missing for a while where users can upload their data to the file point network and they can retrieve the data from file point network. But it's kind of hard to customize how the network behaves internally because you can't deploy the new smart contracts. So that's what the FVM's goal is. The FVM, or FFM as we call it, is trying to bring the EVM to file point so you can deploy existing EVM smart contracts to the file point network. But the way I like to talk about this is actually, we're not just trying to bring the EVM, we're trying to bring the entire Ethereum ecosystem. So if we just added support for the EVM, you might have to tweak your smart contract in a little way or you might have to use new tooling to write smart contracts that work with file point or your smart contracts may not interoperate correctly. But we want to make it so that you can literally just take like your ecosystem smart contracts, your MetaMask or your favorite developer tool and just start using that with the file point network without having to like build everything up from scratch. So first of all, I'm going to talk a little bit about the FVM itself just to give you some background on some of the interesting design decisions we made. So yeah, so the fundamentals. It's a WebAssembly based VM. It's not based on the EVM, it's based on WebAssembly. We did this because it gives us near native performance. WebAssembly is very, very fast. Even with like gas accounting, we were able to actually do it through a very fast instrumentation so it doesn't add too much overhead. That way we can basically run applications that effectively near native performance, which is a lot better than you can with the EVM. It's also enables static analysis and audits. So if you've ever tried to like look at EVM bytecode or try to understand what an EVM contract could do or can't do, it can be a bit hard. It's not well-structured. WebAssembly is very well-structured code so you can tell like what exactly can happen, what can't happen, like after you've compiled it. So it's really a better language for building smart contracts in our opinion. One of the goals with the FVM was to support multiple execution models and VMs in user space, not just to be sort of like stuck with our own custom VM. So this is another recent choose. WebAssembly, because it's so fast that we can literally run another VM inside of our VM and the performance isn't quite native, but it's still very good. One of the other parts of this is that we actually need to make sure that any of the features we add to, for example, support the EVM are general purpose and can be used to support whatever VM you might want to throw in there. We'll get into this a bit later. Wrong button. Yeah, so the FVM is based on, or is it really built on top of IPLD? I don't know how much you know about, or this audience knows about IPLD or what it is, but IPLD is our sort of abstraction over a Merkle link data structures. So a Merkle link data structure is just, it's a hash tree data structure. It's how the Ethereum stores its state tree. It's like how blockchains link themselves to each other where you have this chain of hashes. It's how Git stores its data. It's a very common data structure for your used and decentralized systems. We basically built this sort of abstraction over it called IPLD, that's the reason about these Merkle link data structures. We sort of general purpose tooling. The reason I bring this up is that in Ethereum, you can store your smart contract data in a sort of key value store. They just map 256 bit keys, 256 bit values. You can build whatever data structures you want on top of this, but you kind of need to kind of fit your application into this kind of funky way of storing data. With Filecoin, you can kind of create arbitrary state trees or arbitrary like Merkle trees in your state to lay out the data in the way that it works for you. This also lets you take advantage of data locality and stuff like that where you can like pack data together if it's relevant. It lets you have a little more control over how you store your data. The other part of this is that on Ethereum, if you want to send a message to the contract, you kind of have to copy all this data and send it over and they can parse through it. With IPLD, you can actually send a reference to some big data structure and then they can rifle through that data structure on their side. So that means I can set up a call back and forth and back and forth and back and forth. I can just send you like kind of an entire subtree. You can then rifle through that, even modify it and give back the modified version. So it allows us to like make some really nice and interesting performance applications with less like back and forth and like twisting. So that's the background on how the FVM works. This is the architecture that I'm not going to go into right now, but I can afterwards if you're interested. This kind of tries to cover like the whole system, but basically we have an executor on top that applies messages to a machine and it has a call manager per message. Gets a bit complicated. Okay, for the interesting part, the EVM. So what I talked about there was the FVM right now, actually the FVM does not allow users to deploy custom smart contracts. The FVM, we use it to run the built-in smart contracts right now, but we don't allow users to deploy smart contracts because we're not like 100% sure about the security of like how would it interact with user-deployed smart contracts? Actually we know that like we have not completely hardened it yet against user-deployed code and that's an ongoing process. So we're kind of like slowly opening it up. The first step here is the FEVM, which is basically taking the EVM and running that as a built-in contract on the FVM. The second step is actually allowing everyone to deploy whatever they want, but most of this talks about the FEVM. Okay, so this is the point of the talk. We are bringing the Ethereum ecosystem to the FVM. Part of this, or the first part is bringing the EVM to the FVMs or running the EVM on top of the FVM and the other part is enabling Ethereum tooling on the FVM. This comes in basically two parts. One is pluggable addressing and custom account types. I'll get into the details in a bit. For the first part, EVM inside the FVM, basically we take the EVM, compile it to WebAssembly, run it inside the FVM. One key part here is there's no special EVM support. We're trying to make sure that any features we add are generalizable so that in the future people can add their own VMs to the FVM network and we don't just have to use the blessed EVM or anything like that, they'll be able to deploy their own optimized or customized EVM. But this is M2.2, so we're currently targeting M2.1 where it's just the FEVM and M2.2 we're hoping to open or we are planning it opening and stuff so anyone can deploy whatever they want. The other part here is that the EVM is the first class. We're not making this sort of full sandbox where people can run their EVM contracts. If you deploy an EVM contract to the FVM network, it will get its own separate actor. It will be able to call the builds and contracts. It will use fill, it will use Filecoin gas, it's not gonna use any wrapped, whatever, it's gonna use all the real tokens and everything. You'll be able to also actually create Ethereum accounts effectively on the Filecoin network using Ethereum tooling. So this is really cool where you can literally just use MetaMask and send your message to a Lotus node. We're actually enabling this by using, by implementing the Ethereum JSON RPC API in Lotus and then adding something called account abstraction to allow you to basically allow the Filecoin network to process Ethereum messages and to actually include those in blocks and execute them. So this will really enable a lot of cross-chain tooling. Yeah, and the key part here is that we don't want to add trusted bridges or translations or anything like that. We want to just make this all work natively. Okay, so one key part here is plugable addressing. This can get a little bit technical, but basically what we're doing is we're adding the ability to add custom addressing schemes that are managed by actors to the Filecoin chain. So what you'll be able to do, this is M2.2, you'll be able to deploy your own M2.1. We will be deploying a single actor that will be using this plugable addressing, but in M2.2, you'll be able to deploy a custom actor that will control an entire sub namespace in the addressing scheme. So in this case, if you have an actor add ID address one, two, three, four, you will control everything under F4, one, two, three, four, dash, whatever you want. This allows you to take a addressing scheme or some other runtime, some other blockchain and just port it right in. They didn't even keep the addressing format so that everything continues to work with your tooling. And it also supports Ethereum counterfactuals, so all that stuff will continue to work. It supports Ethereum accounts, again, but the same address formats, so all that stuff will continue to work. The second part is custom account types. As I said before, we've been inspired by EIP4337 to create a system where you can basically deploy a custom account that's a validate function that can validate off-chain messages. They don't necessarily use the standard signature formats. This again allows us to send the messages from Ethereum tooling and it just works. Okay, so that covers the basics. Now I guess we can talk a little bit about beyond the FEVM. Or sorry, yeah, beyond the FEVM, so this is looking forward to M2.2. Yeah, so in M2.1, this is Q1 next year. That's when we'll be launching the FEVM and that will allow users to deploy EVM smart contracts to the FEVM. In M2.2, we will allow users to deploy arbitrary native smart contracts, so they could be able to deploy their own custom wasn't smart contracts. The reason people might want to do this is you get better performance because you're not running inside a FEVM, inside a FEVM, you're running directly on the root VM, and you also be able to take advantage of a lot of these native features, like IPLT support. Beyond that, I'm hoping to also see more optimized EVMs or alternative runtimes. For example, I'm really interested in something called Gorg. It's this really cool JavaScript-based runtime, actually. I'm not a huge fan of JavaScript, personally, but the runtime itself is really cool because it basically lets you have a bunch of small JavaScript objects interact with each other, but are all, due to the way they set it up, they're all somewhat sandboxed from each other, but it's as if you have one big object more into the programming system, so it makes it really easy to write secure and complicated smart contracts that have me to think about multiple actors, because literally every single object is a little isolated thing. It's really cool, you should look at it and check it out. Even beyond that, we're looking into things like parallelism support. One way to do this is to have parallelism within a single actor, we can run up a bunch of parallel jobs. Another way of doing this is you can have multiple tracks of execution, you can have some async execution. This is stuff that we haven't figured out yet, but we've been doing a lot of design work. Another interesting thing is on-chain task scheduling, something Juan has already brought up. We really want to allow users to schedule messages to run at arbitrary times. We actually have a couple of solutions here. One solution is you can buy gas futures, so we could have a system where you basically buy gas in the future, register something to be run in the future, then it gets run. You can also have on-chain message pool situations where you submit a message, it goes into a queue, and then when there's a chain bandwidth available, it gets executed. You can also have a system where some off-chain system submits your messages at a specific time. We generally prefer on-chain systems just because you get some work guarantees there, but yeah, we've been doing a lot of talking about that, and then finally, hierarchical consensus. I don't know how much you've heard about hierarchical consensus, but it's another project that Protocol Apps is working on to bring basically change sharding. This is still in its early stages of trying to figure out exactly how to make this work, but the FEM enables this kind of thing by basically allowing you to plug in other blockchains into the FEM using custom smart contracts. So basically, the smart contract will govern another sub-blockchain, and in that blockchain, you can have the smart contract that governs another sub-blockchain so you can build these kind of like trees of chains. Yeah, so that's it for me in terms of the technical side of things. Does anybody have questions? Do we still have time? Okay. I know I went kind of fast there. I have a question. So when you're thinking about looking at the Ethereum sub-smart contracts that are already out there and porting them in, I'd be interested to know what are the ones that, like day one, when it goes live, you're gonna copy and paste and bring in. Are you already doing that with your reference implementation? Are you just doing kind of like hello world stuff? Are you going and taking Uniswap and copying it in and testing with that? At the moment, most of the testing is hello world stuff. We also have an entire early builders program. Where they're literally already building things at the top of the Filecoin network and really on top of the FVM and some of the FVVM and trying to see what they can do with that. I don't actually know which ones we're gonna try to port in. I don't know if we'll be porting. We're planning on leaving a lot of stuff to the community. There are always regulatory concerns around what we actually deploy ourselves. So as a team, I don't know if we'll be deploying into those ourselves, but yeah, basically we're trying to set it up. So yes, on day one, we expect a lot of people to just drop stuff. There's also, we're trying to build at a sort of a builder's network, ideally launching at the end of this year, more in November. This is still not well known yet, so pretty new. But yeah, like there, we're hoping to basically spin up a small network where people can start playing around and building things so that when the FVM launches on main net, we'll be able to just like take everything there and just port it over. Hi, very interesting talk, man, thanks. I just have a question. I don't know if I misunderstood something, but if I use the FEVM to run an Ethereum smart contract, does it get executed in the Filecoin or in the Ethereum network? And if it gets executed in the Filecoin network, do I have to pay gas in both Ethereum network and the Filecoin network or just? Yeah, so it gets executed in the Filecoin network and you pay Filecoin gas with Filecoin. So basically it brings the programming and all the tooling to the Filecoin network, but it's not a bridge between Ethereum and the Filecoin network. We're not trying to extract value out of the Ethereum network or anything like that. We're just trying to reuse all the tooling and all the stuff people have already built in the Filecoin network so people don't have to rebuild everything from scratch. Thank you. Is there any additional overhead of porting the EVM onto running on top of the FVM, like extra gas costs and stuff? Yes, yeah, there is overhead. The initial implementation we had was very bad. We have now 10x that in terms of performance and we're really hoping to 10x it again. Yeah, like there's a lot of room for optimization and right now it's still in the early stages of like trying to do that. Luckily again, WebAssembly is actually very fast. Adding gas accounting to it makes it a bit slower but you can play a lot of games with instrumentation where like you literally take WebAssembly, like instrument it with the new instructions that call gas accounting functions that like don't like, like basically you don't actually do gas accounting for instruction instead like you can look at a block of code and then at the very beginning of the block of code charge for the gas that the entire block of code might take. So it's pretty fast.