Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(content): FIL VM System Actors Update #1061

Merged
merged 10 commits into from
Aug 31, 2020
27 changes: 20 additions & 7 deletions content/systems/filecoin_vm/sysactors/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,17 +3,30 @@ title: System Actors
weight: 6
bookCollapseSection: true
dashboardWeight: 2
dashboardState: incomplete
dashboardState: stable
dashboardAudit: 0
dashboardTests: 0
---

# System Actors
---

- There are two system actors required for VM processing:
- [InitActor](init_actor.md) - initializes new actors, records the network name
- [CronActor](cron_actor.md) - runs critical functions at every epoch
- There are two more VM level actors:
- [AccountActor](account_actor.md) - for user accounts (non-singleton).
- [RewardActor](reward_actor.md) - for block reward and token vesting (singleton).
There are eleven (11) builtin System Actors in total, but not all of them interact with the VM. Each actor is identified by a _Code ID_ (or CID).

There are two system actors required for VM processing:
- the [InitActor](init_actor.md), which initializes new actors and records the network name, and
- the [CronActor](cron_actor.md), a scheduler actor that runs critical functions at every epoch.
There are another two actors that interact with the VM:
- the [AccountActor](account_actor.md) responsible for user accounts (non-singleton), and
- the [RewardActor](reward_actor.md) for block reward and token vesting (singleton).


The remaining seven (7) builtin System Actors that do not interact directly with the VM are the following:

- `StorageMarketActor`: responsible for managing storage and retrieval deals [[Market Actor Repo](https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/market/market_actor.go)]
- `StorageMinerActor`: actor responsible to deal with storage mining operations and collect proofs [[Storage Miner Actor Repo](https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/miner/miner_actor.go)]
- `MultisigActor` (or Multi-Signature Wallet Actor): responsible for dealing with operations involving the Filecoin wallet [[Multisig Actor Repo](https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/multisig/multisig_actor.go)]
- `PaymentChannelActor`: responsible for setting up and settling funds related to payment channels [[Paych Actor Repo](https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/paych/paych_actor.go)]
- `StoragePowerActor`: responsible for keeping track of the storage power allocated at each storage miner [[Storage Power Actor](https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/power/power_actor.go)]
- `VerifiedRegistryActor`: responsible for managing verified clients [[Verifreg Actor Repo](https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/verifreg/verified_registry_actor.go)]
- `SystemActor`: general system actor [[System Actor Repo](https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/system/system_actor.go)]
6 changes: 4 additions & 2 deletions content/systems/filecoin_vm/sysactors/account_actor.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,14 @@
title: AccountActor
weight: 3
dashboardWeight: 2
dashboardState: incomplete
dashboardState: stable
dashboardAudit: 0
dashboardTests: 0
---

# AccountActor
---

{{<embed src="/modules/actors/builtin/account/account_actor.go" lang="go" >}}
The `AccountActor` is responsible for user accounts. Account actors are not created by the `InitActor`, but their constructor is called by the system. Account actors are created by sending a message to a public-key style address. The address must be `BLS` or `SECP`, or otherwise there should be an exit error. The account actor is updating the state tree with the new actor address.

{{<embed src="/modules/actors/builtin/account/account_actor.go" lang="go">}}
9 changes: 7 additions & 2 deletions content/systems/filecoin_vm/sysactors/cron_actor.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,17 @@
title: CronActor
weight: 2
dashboardWeight: 2
dashboardState: incomplete
dashboardState: stable
dashboardAudit: 0
dashboardTests: 0
---

# CronActor
---

{{<embed src="/modules/actors/builtin/cron/cron_actor.go" lang="go">}}
The `CronActor` is responsible for scheduling jobs for several operations that need to take place between actors. The `CronActor` can provide services to other actors related to task scheduling, such as `OnEpochTickEnd` call the `InitActor` to create a new actor, contact the `StoragePowerActor` to check if proofs have been submitted, or call the `RewardActor` to update parameters. This is primarily realised in the form of sending messages to other registered actors at the end of every epoch. The `CronActor` interfaces with the Storage Power Actor on `OnEpochTickEnd` to check:
- `CronEventPreCommitExpiry`: if the miner has submitted their `ProveCommit` proofs.
- `CronEventProvingPeriod`: the proving period identified,
- `CronEventWorkerKeyChange`: if a miner has submitted a worker key address change.
yiannisbot marked this conversation as resolved.
Show resolved Hide resolved

{{<embed src="/modules/actors/builtin/cron/cron_actor.go" lang="go">}}
8 changes: 6 additions & 2 deletions content/systems/filecoin_vm/sysactors/init_actor.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,16 @@
title: InitActor
weight: 1
dashboardWeight: 2
dashboardState: incomplete
dashboardState: stable
dashboardAudit: 0
dashboardTests: 0
---

# InitActor
---

{{<embed src="/modules/actors/builtin/init/init_actor.go" lang="go">}}
The `InitActor` has the power to create new actors, e.g., those that enter the system. It maintains a table resolving a public key and temporary actor addresses to their canonical ID-addresses. Invalid CIDs should not get committed to the state tree.
yiannisbot marked this conversation as resolved.
Show resolved Hide resolved

The actor should be able to construct a canonical ID address for the actor that will persist even in case of a chain re-organisation.
yiannisbot marked this conversation as resolved.
Show resolved Hide resolved

{{<embed src="/modules/actors/builtin/init/init_actor.go" lang="go">}}
12 changes: 7 additions & 5 deletions content/systems/filecoin_vm/sysactors/reward_actor.md
Original file line number Diff line number Diff line change
@@ -1,18 +1,20 @@
---
title: RewardActor
weight: 4
dashboardWeight: 2
dashboardState: incomplete
dashboardState: stable
dashboardAudit: 0
dashboardTests: 0
---

# RewardActor
---

RewardActor is where unminted Filecoin tokens are kept. RewardActor contains a `RewardMap` which is a mapping from owner addresses to `Reward` structs.
The `RewardActor` is where unminted Filecoin tokens are kept. The `RewardActor` contains a `RewardMap` which is a mapping from owner addresses to `Reward` structs.
yiannisbot marked this conversation as resolved.
Show resolved Hide resolved

`Reward` struct is created to preserve the flexibility of introducing block reward vesting into the protocol. `MintReward` creates a new `Reward` struct and adds it to the `RewardMap`.
A `Reward struct` is created to preserve the flexibility of introducing block reward vesting into the protocol. `MintReward` creates a new `Reward struct` and adds it to the `RewardMap`.

A `Reward` struct contains a `StartEpoch` that keeps track of when this `Reward` is created, `Value` that represents the total number of tokens rewarded, and `EndEpoch` which is when the reward will be fully vested. `VestingFunction` is currently an enum to represent the flexibility of different vesting functions. `AmountWithdrawn` records how many tokens have been withdrawn from a `Reward` struct so far. Owner addresses can call `WithdrawReward` which will withdraw all vested tokens that the investor address has from the RewardMap so far. When `AmountWithdrawn` equals `Value` in a `Reward` struct, the `Reward` struct will be removed from the `RewardMap`.
The award value used for the current epoch is updated at the end of an epoch through a cron tick. In the case previous epochs were null blocks this is the reward value as calculated at the last non-null epoch.
yiannisbot marked this conversation as resolved.
Show resolved Hide resolved

{{<embed src="/modules/actors/builtin/reward/reward_actor.go" lang="go">}}

{{<embed src="/modules/actors/builtin/reward/reward_actor.go" lang="go">}}