Filecoin How Filecoin Works, 27 Jul 2022

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: How Filecoin Works: Part 1

Description

In Part 1 of this talk by led by Nicola of Protocol Labs, learn about how the Filecoin protocol is both a Decentralized Storage Market, and a Storage Based Consensus. This section covers an introduction, the blockchain basics, as well as Filecoin Virtual Machine (FVM) components.
Part 2 Coming Soon
Resources: Join Protocol Labs Launchpad: https://pl-launchpad.io/ , Filecoin Docs: https://docs.filecoin.io/, Filecoin Spec: https://spec.filecoin.io/

Chapters
00:00 Introduction to the Filecoin Products
01:54 The Filecoin Blockchain: Basics of Mining & Messages
02:05 Filecoin Messages
03:04 Epochs
05:54 The Filecoin Virtual Machine
07:35 FVM Components: Actors, Addresses, State, & Execution
08:19 Actors
09:55 Addresses
12:35 Actor Methods
14:56 The Execution Model

A

Hey everyone: this is the five coin protocol school and this is nicola all right. We're going to go through the introduction, high level of the mining cycle, deep dive into the mining cycle and deep dive into the actors, we're looking into the storage power aspect of the protocol, everything that has to do with mining without uh accounting for block generation. So this is the the five coin logic that gives powers to the miner.

A

All right, so there are two parts, and maybe this is clear for everyone, but this is very important to understand. There are two parts to the five coin protocol. One part is that it is market for storage, which means that you ask the network to store a file, and you find the miner to sort the file. The miner stores the file, and they give you a guarantee that the file will be stored through time and so far the products are very simple, which is store, a file and retrieval file.

A

The second part is that filecoin is a storage based consensus. There is proof of work, proof of stake and proof of storage, and we are the first proof of storage protocol that deployed in the real world. Just in case you want to brag about this and the storage based consensus. Does the idea is the following: if you're a miner and you're storing someone's data, you can reuse the same space from which you're storing someone's data to mine into the protocol.

A

That's that's the idea, and, and so we want to make sure that the people this is philosophy, but it's very important, the people they have power, they have control on. What's going to be in the next block or more or more theoretically, what would be the change into the protocol are the people that provide services into the protocol. They provide storage into the protocol. That's the important part.

A

There is two billion file coin, there's a particular amount. Sixty million is a great in supply. We're gonna look later at some stats on space gap, so for those that have like fresh from blockchain. I will give you like a very quick presentation on on the blockchain system, but with a particular eye into the filecoin, uh the filecoin blockchain, when in fact, transactions are not called transactions, we call them messages uh we'll see. Why and a message is from an act from an actor to another actor. An actor is an entity on the blockchain.

A

Everything that talks to each other on the blockchain is an actor. So you have a transaction that you want to send money to the lead. uh You send this this transaction into the network. The network accumulates these transactions in something that we call the mempool and the mempool is this. uh Every miner has uh somehow receives uh these transactions and then picks some of them to try to make a block if they win a block, they they put a list of transaction in the block and they add this block to the blockchain and the filecoin.

A

Blockchain is uh different from other blockchains. That have, we may have multiple blocks at each particular epoch.

A

So, instead of instead of instead of saying block one block, two block three, we call uh time in in in fight coin through epochs, an epoch is a collection of is a cool, is a set of blocks um and one block. So the next block will link to the two previous blocks in the previous epoch.

A

So and how many blocks are there in every single epoch? It could be zero blocks, so no one gets to win or, and so no one gets to win. It could be one winner. It could be ten winners, but on expectations there is five wins. There's five winners, so five blocks per ebook, so in ethereum what's happening is the following. I I receive a block from miners. I see the block, I execute the block in fight coin. You cannot execute the block because you don't know if you're gonna have more than one block.

A

Okay, so what's happening is that in file coin, you receive several blocks for epoch x. You need to wait until you see the first block on the next epoch. The links to the previous blocks to sort those blocks and execute them blocks are sorted in hash order. I think, and and transactions are executed by the order of the blocks if a transaction appears in one block it's executed, if it appears in a second block, this is the second transaction is not considered, is excluded. It gets deduplicated.

A

So this is very important this. This is the core of many problems that will come later in in filecoin. You don't execute blocks as you receive them, you you execute them once you're done with the e-book and then the next block links to the previous blocks, and now you can execute them.

A

Every block has a list of transaction and you want to update the balances and so on whenever you're done, updating the balances. Sorry, let's call this epoch x and the previous one is x, minus one. When you are at x, you execute all the blocks of the epoch x, minus one. You update all the balances when you update the balances.

A

There is something that is called the states, so part of the state is balances, but there is more states that will see they will see later, and so this block links to the previous blocks and the parent state rules and a state route is the root hash of the merkle tree of the states.

A

um But what I'm saying is that you can only update the states once you execute the previous blocks and and and every epoch you have an updated state. You have a new state. Can you have multiple states at each epoch? No, because, okay, this is this. This is the the last high-level introductory slide, which is you have the blockchain and the blockchain. You can think of it as um the list of all blocks, but as blocks come in, you must execute them. How do you execute these blocks? You execute them in the virtual machine.

A

What is the virtual machine? What is this complex name? It's just a state. You can think of it as a state machine where the block comes. The block has a set of transactions, you execute transactions in order and each transaction is executed in this environment, which is called the virtual machine in the virtual machine. You have a set of actors, so there is no transaction that doesn't speak to actors. So what is an actor? Your balance, your account where you spend tokens is an actor. The multisig is an actor. The miner is an actor.

A

The storage market, which is the actor to which you talk to make deals, is an actor and we have other actors and we're going to go through every actor in a second. But every single time you do an action on the blockchain you're you're, asking one actor to talk to another actor. So, for example, whenever you move money from one place to another place, you say from actor nicola to actor david and the function that is called on the actor. Each actor as a set of functionalities that can be triggered.

A

Methods that can be triggered is send when, when you, when you claim money from the multisig what's happening, is that you're, going from your accounts into you're, sending from a message from your accounts to the multisig actor and you're, saying you send me a message that says: withdraw.

A

So the general idea is that, with the blockchain in the blockchain we see sits the virtual machine. The virtual machine gets transactions from the blocks and updates every every everything that goes to the virtual machine updates. The the the the virtual machine states and the vista machine state is updated after every transaction that is executed and the final state of the of uh of an epoch gets stored into into the next block.

A

In other words, uh at every epoch, there is a one final state, and that is the result of the execution of all the messages through the virtual machine.

A

Okay, so the visual machine execute messages that are ordered by the blockchain, and each message is from an actor to another actor.

A

An actor is an entity on the blockchain which receives messages and an actor has callable methods that are sent by other actors and when this is interesting, but when you send a message to an actor, the actor may also send a message to another actor. For example, in the multisig you send a message to the multisig they say: withdraw and the multisig.

A

Actor sends a message to the actor to which you want to withdraw, which is a send message, so actors send messages within each other. You generally, the user triggers a sequence of messages, being a sequence of messages being called amongst actors generally. If the blockchain is sitting still actors wouldn't talk by themselves, there's only one actor that is not triggered by the user, which is chrono.

A

We have an actor, which is the crown actor and every block the crown actor decides to send some messages to the relevance to the relevant actors.

A

There are some actors: there are many of the same type so, for example, the account actor. There are many each one of you as an as an account actor. There are many of multisig actors, but there are some actors that are singleton, which is there is only one, and this is the crown actor this one crown actor. This is a power actor, and then there is a market actor there's one of each.

A

The actors soon actors, you reference them, there are two ways to reference to an actor: one is an incremental address and incremental address starts with t0. So if you are the first actor ever created, you get zero. If you add the second actor, you get t01 t0 t01 and if you uh so, for example, if we look at the sorry, it's not t anymore t was tested, it's f, f, zero, but generally an actor has two addresses. One is an incremental id and one is a is a is a robust address.

A

What's the difference between an incremental id and a robust address, whenever you say, whenever you receive a theme, the email that you you've been added to the multisig, this many uh dollars, you get a robust, robust address, the difference between a robust address and a um and an incremental id is the robust address. It's um it's a very long address and it's a unique address and the incremental id it's a very short address. Now the incremental id gets assigned through the consensus. So what happens?

A

If uh alfonso creates uh a new multisig, he will get in the whenever he creates a new multisig. He will get us assigned an incremental id, but what happens if there is a fork in the blockchain? And then iran gets the same id so incrementing like this gets assigned by the blockchain, and you need to wait for a long time which we call finality before they're finalized.

A

So if someone up comes to you and say hey, this is my my f zero address. You want to make sure that they have been having the f0 address for at least a day. Otherwise it could be that you're sending money to someone else.

A

These f1 addresses are um addresses generated with a particular key, which is secpi, which is probably um there is another ad which is probably what you all have with ledgers. And then there is some other addresses which are generated with the bls. It's a different signature scheme and then t2 um is the address that that gets assigned to to multi-leagues and things and and and so on. So the difference is: whenever you create your own account actor. There are the robust address of your account.

A

Actor is the hash of your public key zero addresses are for incremental from 0 to 99, they are reserved to protocol labs and to do special actors stuff in the future and so on.

A

Now each actor has some methods that you can call so, for example, the account actor has a as a method which is send and then a constructor method, which is whenever you create the account that the constructor is created. But the idea is that there is a list of there's a each actor as a list of methods and they in and they can be, they can be called.

A

um There are different actor types. This you can create many accounts, many minor actors, many multisig actors, many payment channel actors- these are the the ones that you can you can you can create. You can create an account actor. You create an account actor every single time that you want to. uh You have a new, a new key, and now there are the genesis actors. These are actors that are in the protocol to stay, which is the.

A

I don't know what the system actor does. The init actor, I think, is the actor used to create new actors. The reward actor is the actor that correctly calculates and distribute the block rewards. The crown actor is like a clock: every block every epoch they decide to do. He decides to send some messages, we'll see later what with the power actor, which takes into account how much power the network has and how much power each individual miner has um so sorry, it takes account. What is the total power in the network?

A

It takes account what total power in the network. So every single time, a miner adds storage. The storage gets added into the power actor. We will go into details of this, and then there is the market actor. We were not gonna talk about it. uh There's the verified registry, which is the file coin plus. We will not talk about it, and then there is the super famous f099, which is burnt funds every single time you pay fees or whether it is um fees due to gas.

A

uh Some of the parts the super famous base fee, which probably will not touch into it, but every single time that you pay fees the they are burnt. This money go into the burn fund. It would be cool eventually to choose what to do with this burnt money. Maybe we can give them back to the to the I don't know it would be cool to see to see a reuse of these funds.

A

I'm gonna skip gas, the execution model. I think I told you already what the execution model is, which is you have a in an epoch? You wait for the next epoch in order to execute the previous blocks and what you do you go transaction by transaction. You execute the transactions and, after you, you're done with the transaction, so you can think of it as a uh as a program that goes in uh step of one e-book, so we are epoch zero and there is a particular state which is, for example, uh was a total power.

A

How much money have people in their accounts and so on. We go through the set of transactions, and at the end of that we create a new state and the new state has the updated power, the updated list of transactions, and so on. We have a new new set of blocks. We update the new states at every epoch, a new state is generated and the state is.

A

We often call it state three, because the state you can think of it as a large um sorry as a large dog and a message triggers, could trigger state updates and when people send the message they pay gas and what is gas gas is how much it costs to do. A state update how much it costs to uh how much it costs to to compute the message execute the message function that gets called with the inputs that are in the message they update the states.

A

Good question: every actors cannot actors only update their own states, you can send the message to another actor and that message triggers the state updates, but you don't write the memory of another actor.

A

The state three is is the c3 is a the least of all actors and, and each actor is a dag of the content that they that they care.