Filecoin Filecoin Virtual Machine - FVM, 7 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: FVM Technical Updates with Lead Developer Raul

Description

Filecoin Virtual Machine (FVM) Lead Developer Raul talks through the current technical status of the FVM and outlines the next steps.

Main Points:

🎉 FVM Milestone 1 (M1) code - the Skyr Upgrade, is going live on the Filecoin Network on Tuesday 5th July 2022.

🦄 Milestone 2.1 (M2.1) will introduce EVM-compatible programmability to the Filecoin Network, and is now the next priority of FVM.

💻 This decision was made to ensure the dev's are able to bring their current skillset and knowledge to the FVM as well as meaning that the current EVM tooling will be able to be used to build on FVM.

💫 We also want to ensure a seamless developer and tooling experience on the native Filecoin Virtual Machine, so this goal will be running in parallel alongside of building the EVM-compatible FVM release

✅ Follow & contribute to the design decisions being made on the FVM M2.1 release by subscribing to
⭐ FVM-specs: https://github.com/filecoin-project/fvm-specs
⭐ FIP's: https://github.com/filecoin-project/FIPs

🎁 An early (alpha) version of the evm-compatible fvm code has been open sourced: https://github.com/filecoin-project/fvm-evm/

🌐 You can see our milestone goals on the website at https://www.fvm.filecoin.io

💖 Want to help build out the native filecoin developer tools or infrastructure? RFPs are open: https://github.com/filecoin-project/devgrants/blob/master/rfps/fvm-open-tools-infra.md

============================================================
About the FVM:

Currently Filecoin is known for being a decentralised storage and retrieval network, providing over 17 EiB of distributed data storage capacity to the world through thousands of Storage providers globally.

And we can think of this distributed storage network as being the layer zero of the Filecoin Architecture Network because ..
Storage is really only the start!

We want to be able to compute and analyse over and with the data on the Filecoin network!

And this is the goal of the FVM - to enable users to be able to deploy their own smart contracts (or actors as they are termed in the Filecoin ecosystem) and unlock the ability to perform on-chain computation over state data.

This additional layer of capability - which we can consider to be the layer 1 of the network - adds programmability to the already robust, permissionless storage network that is Filecoin.

Smart contract + storage = FVM.

What will you build??

Links:
🌐 See more details on the website: https://fvm.filecoin.io
🦄 See the reference specification of FVM: https://github.com/filecoin-project/ref-fvm
👨‍👩‍👦‍👦 Join the chat: #fvm on the Filecoin Slack Channel (visit filecoin.io to join)

A

Yeah it's a quick update from from RN. Today we also had Steph in the call, um so so I think this is uh one of the first ones that he's joining, so he can kind of like complement uh what I say here as well uh with more with more depth uh but yeah. Basically, the the main update here is that we're going live with the VM M1 uh on Tuesday, so look out for that. uh The skirt upgrade is coming. uh We're very excited about that.

A

This basically installs the fpm technology to the network uh without still enabling user programmability uh that's coming with uh M 2.1. uh We are focusing on evm programmability first. This is basically there was um uh recurring feedback that we kept getting at conferences and events that uh there's a massive set of developedic pairs from that are.

B

A

Familiar with the ethereum development tools, and so on that wanna want to start hacking, four or five point and started building profile coins, so they were basically asking for ebm support uh right at the bat. uh That's why we decided to focus on the sense of first priority, and the other reason is also that um Native programmability.

A

Besides from the technical side inside the fem, it might seem a little bit simpler to implement. Given that you know we don't have to like cover for an entire new runtime at first, but then in terms of providing the development, the development experience that developers have come to expect.

A

That requires a ton, more tooling libraries and sandboxes and uh client libraries in sdks that we are able to deliver quickly. So what we want to do is have these threads of tooling, creating of like the creation of.

B

A

That is eventually going to support the native development Experience run in parallel with the delivery of evm to the network. So.

B

This gives us a little bit.

A

More time to nail the the tooling experience for Native developers, um while we still deliver programmability on the filecoin on the file Chrome Network. So this is the main strategic reason that we're focusing on ebm for 2.1. uh We still need to update this on the website, uh so the the Roadmaster Still Still reads as if 2.1 was native programmability, so just bear with us there uh and now in terms of technical updates. There's tons of design discussions uh going across the board right now.

A

So if you subscribe to IBM specs uh and if you subscribe as well to the Pips report, you'll see a ton of note. A ton of those a few key discussions that I wanted to highlight today is the account abstraction. So accountant, abstraction is the ability for uh actors on chain to validate transactions. uh So this means currently the protocol is validating transactions, uh which means that uh it is hard to support evm native ethereum Native transactions right at a box, unless we add support at the core protocol level.

A

The problem with this is that it basically marries uh it couples ethereum and Falcon at a very deep level, and the transaction model in ethereum is going to keep evolving the transaction. The model on Falcon is going to keep evolving and having that coupling at such a low level is going to be a nuisance going forward forever. uh So the idea here is uh to adopt the concept of account abstraction, which is any actor for for the first version.

A

It would be theory of actors would be able to uh to validate transactions and then act as the ultimate senders of the of the message onwards. So the way that this is going to look to validate native transactions and Native ethereum transactions is there is going to be a upgraded, an a new actor on chain. uh We still have to figure out the right name for now we're using a placeholder called e-account, which is ethereum compatible accounts, uh any SEC B, uh any SEC pe256 game, one account.

A

So this is an F1 address and filecoin will be able to upgrade to a new account and in order to support this upgrade we're also introducing a feature that we had talked about, but we plan on delivering later, but for this particular pathway is uh we we need to. We need to. uh We need to deliver this feature to support this specific pathway, and that is basically uh the ability for an actor to become another actor. So this is for an after for an actor to change to update the code CID that is packing it.

A

So this is a very unique feature that the Falcon protocol allows us to do, because that's just this decoupling between actors and the code behind actors, so an actor could decide to change the code. Cid that's backing it. Of course. The flow here is going to be very interesting because when an actor holds a Cisco to become another actor, uh it is gonna.

A

It is going to supply code CID and that uh and that uh code CID that code will have in order to support upgrades to it or updates to it will have a new entry point at the wasn't level. So this is a new awesome exported function, which is basically going to act as the intake function, and this function will evaluate if that operation is allowed and it will perform any state migration that might be necessary.

A

uh So you can imagine in the future- and this is like when, in the future, this mechanism also be used for upgrading, even built-in some built-in actors on chain right. There is a trade-off there um like. We know that you know, for example, Lee who's, a client implementer here right. You know the what the migration process looks like in network upgrades right, so it's like. Basically you dive into. In many cases you dive into the state of specific actor types and you you migrate.

A

The state object to a new object, so imagine putting this logic in the test in the code of the destination actor right. This is what the entry point will will be will be able to do um So. Eventually, when you put these pieces together, this means that a metamask wanted would be able to issue an ethereum transaction, so nothing Five, Point specific, is just an ethereum transaction that the filecoin network will be able to accept, because the thing that's validating that ethereum transaction uh would be this.

A

The actor that's backing the sender account, so the fem will have the smarts to realize. Oh, this actor is not supposed to be it's sorry. The this transaction is being sent with a type that is not. That does not contain a filecoin signature. It is an opaque blob to the protocol and it's.

B

A

As a as a transaction that needs to be so the transaction type that's used here, the message type, the signature type that's used here- is no.

B

Signature, so this.

A

Is basically a sender, a delegated signature? So now it's up to this, so the fbm is going to have the smarts to call this validation entry point in the sender in the sender actor so that the sender can then evaluate If. The message is correct and the sender in this case, if it's a me account, would be validating the ethereum signature and then you can deciding to continue the processing of that message. If you're in signature isn't valid, then it wouldn't, it would just error out and the message would be rejected by the network.

A

So that's basically one of the main uh one of the main developments here, um we're also uh working on a set of.

B

A

Designs that you might want to peek into things like, for example, how we're going to support ethereum logs, so the the file core network doesn't currently have support for logs and the style of ethereum in the sense that there's you know a bloom filter uh at a block level.

A

That is uh a that is serving as a quick data structure as a data structure to quickly evaluate if a particular event of Interest might be present in the execution of this block, and it also doesn't have support for outputting uh logs to or other transaction execution metadata to receipts. So these are the two things uh that you know kind of like ethereum does when it comes to logs. We want to go further than that. We want to introduce, like the main design.

A

Direction here is introducing the concept of execution artifacts, so not just logs in the future. When we we introduce things like, for example, the synchronous programming and callbacks, and maybe a user provided users applied prawn entries and event subscriptions and so on. The execution of those things could end up, outputting things like callback, IDs and things like callback, jobs and stuff. Like that right, so these are artifacts from execution.

A

This is a very early idea, but the point here is uh one One requirement here is to, and the thing that we're thinking through these days is how can we provide the right patterns of access for light clients on the 500 Network as well? So one thing that we want to be able to provide is the ability for a Lifeline to trustlessly be able to pre-read the network for a particular set of logs that have been emitted Maybe by an actor at a given height or um sorry.

A

There's some background, noise I think it's all right. You know thanks um so uh to be able to to query for logs that have been emitted by an actor.

A

A lot of that belong to a quick to to a particular topic that have some particular data, and these things should be a node should should be able to have a data structure like the change should be having a data, a set of data structures that allows a node to produce a vertical inclusion proof or an inclusion proof of some kind uh to to prove to the like clients that a particular set of logs is included in a block.

A

So right now so like these are the things that we're thinking through, um and this is kind of like a very, very loose brainstorm of some of those things so feel free to to to go into the ref sorry into the fvm specs repo subscribe to that look at the design discussions also the FIB uh discussions that are that are that are happening and feel free to to contribute. But that's uh where we are right now and I. Don't know if stab has something else that he wants to.

A

He wants to add to the technical update.

B

um You know that's the main thing we're focusing on right now. uh We're also trying to think through, like the final versions of things like it, creates this calls um uh and uh some changes to ibld. They have at least some people get punted out to to um M 2.2 um uh by one thing, that's on my mind is like the various uh constraints and contractors you might want to prove with great uh when uh you create actor, address and stuff like that.

B

So really, honestly, 90 of our work is around like actor addressing and creation logic try to figure out how to make that work.

B

A

And we also- and we also open sourced the fbm ebm Prototype. So this is the Prototype of the ebm runtime on the fem. uh This is currently using a early design iteration, which includes a bridge actor and a bunch of other things that are probably going to go away.

A

There's many there's like we've gone through several simplification rounds and we've determined that uh the bridge actor in this in this particular manifestation can probably go away and it could be turned potentially into a lightweight registry actor that is mapping addresses we're trying to get we're, trying to figure out some ways to to get even rid of that potential registry actor. If we can uh reconcile uh addresses at a more Elemental level, uh but that's that's basically what we are working.

B

On we kind of like.

A

Doing like um uh like a two-way process, Engineering Process here where we are designing, specs and, at the same time we're prototyping uh certain key problems uh that we wanna, that we know still have some unknowns behind them so that we can meet in the middle and like have this feedback cycle between implementation and and decide.