|
1 | 1 | ---
|
2 | 2 | description: >-
|
3 |
| - A blockchain is a distributed database that is shared among the nodes of a |
4 |
| - computer network. This page covers how the Filecoin blockchain is designed, |
5 |
| - and the various functions it has. |
| 3 | + A blockchain is a distributed database shared among nodes in a computer network. This page covers the design and functions of the Filecoin blockchain. |
6 | 4 | ---
|
7 | 5 |
|
8 | 6 | # Blockchain
|
9 | 7 |
|
10 | 8 | ## Tipsets
|
11 | 9 |
|
12 |
| -The Filecoin blockchain is a chain of tipsets rather than a chain of blocks. A tipset is a set of blocks with the same height and parent tipset. Therefore, multiple storage providers can produce blocks for each epoch to increase network throughput. |
| 10 | +The Filecoin blockchain consists of a chain of tipsets rather than individual blocks. A tipset is a set of blocks with the same height and parent tipset, allowing multiple storage providers to produce blocks in each epoch to increase network throughput. |
13 | 11 |
|
14 |
| -Each tipset is assigned a weight, so the consensus protocol directs nodes to build on the heaviest chain. This provides a certain level of security to the Filecoin network by preventing a node from intentionally intervening with other nodes to produce valid blocks. |
| 12 | +Each tipset is assigned a weight, enabling the consensus protocol to guide nodes to build on the heaviest chain. This adds a level of security to the Filecoin network by preventing interference from nodes attempting to produce invalid blocks. |
15 | 13 |
|
16 | 14 | ## Actors
|
17 | 15 |
|
18 |
| -An Actor in the Filecoin Blockchain is the equivalent of the smart contract in the Ethereum Virtual Machine. It is essentially an ‘object’ in the Filecoin network with a state and a set of methods that can be used to interact with it. |
| 16 | +An actor in the Filecoin blockchain is similar to a smart contract in the Ethereum Virtual Machine. It functions as an ‘object’ within the Filecoin network, with a state and a set of methods for interaction. |
19 | 17 |
|
20 |
| -### Built-in actors |
| 18 | +### Built-in Actors |
21 | 19 |
|
22 |
| -There are several built-in system actors that power the Filecoin network as the decentralized storage network. |
| 20 | +Several built-in system actors power the Filecoin network as a decentralized storage network: |
23 | 21 |
|
24 |
| -* System Actor - general system actor. |
25 |
| -* Init actor - initializes new actors and records the network name. |
26 |
| -* Cron Actor - a scheduler actor that runs critical functions at every epoch. |
27 |
| -* Account Actor - responsible for user accounts (non-singleton). |
28 |
| -* Reward Actor - managing block reward and token vesting (singleton). |
29 |
| -* Storage Miner Actor - storage mining operation and validate storage proofs. |
30 |
| -* Storage Power Actor - keeping track of the storage power allocated at each storage provider |
31 |
| -* Storage Market Actor - managing storage deals. |
32 |
| -* Multisig Actor - responsible for operations involving the Filecoin multi-signature wallet. |
33 |
| -* Payment Channel Actor - set up and settle payment channel funds. |
34 |
| -* Datacap Actor - responsible for datacap token management. |
35 |
| -* Verified Registry Actor - responsible for managing verified clients. |
36 |
| -* Ethereum address Manager (EAM) Actor- responsible for assigning all Ethereum compatible addresses on Filecoin Network, including EVM smart contract addresses and Ethereum account addresses. |
37 |
| -* EVM Account Actor - a non-singleton built-in actor representing an external Ethereum identity backed by a secp256k1 key. |
| 22 | +- **System Actor**: General system actor. |
| 23 | +- **Init Actor**: Initializes new actors and records the network name. |
| 24 | +- **Cron Actor**: Scheduler that runs critical functions at every epoch. |
| 25 | +- **Account Actor**: Manages user accounts (non-singleton). |
| 26 | +- **Reward Actor**: Manages block rewards and token vesting (singleton). |
| 27 | +- **Storage Miner Actor**: Manages storage mining operations and validates storage proofs. |
| 28 | +- **Storage Power Actor**: Tracks storage power allocation for each provider. |
| 29 | +- **Storage Market Actor**: Manages storage deals. |
| 30 | +- **Multisig Actor**: Handles Filecoin multi-signature wallet operations. |
| 31 | +- **Payment Channel Actor**: Sets up and settles payment channel funds. |
| 32 | +- **Datacap Actor**: Manages datacap tokens. |
| 33 | +- **Verified Registry Actor**: Manages verified clients. |
| 34 | +- **Ethereum Address Manager (EAM) Actor**: Assigns Ethereum-compatible addresses on Filecoin, including EVM smart contract addresses. |
| 35 | +- **EVM Account Actor**: Represents an external Ethereum identity backed by a secp256k1 key. |
38 | 36 |
|
39 |
| -### User-programmable actors |
| 37 | +### User-Programmable Actors |
40 | 38 |
|
41 |
| -Along with the maturity of FVM, developers can write actors and deploy them to the Filecoin network in the same way as other blockchains. Other blockchains refer to these programs as _smart contracts_. User-programmable actors can also interact with built-in actors using the exported API from built-in actors. |
| 39 | +With the maturity of the FVM, developers can write actors and deploy them on the Filecoin network, similar to other blockchains' smart contracts. User-programmable actors can interact with built-in actors via the exported API from built-in actors. |
42 | 40 |
|
43 |
| -You can check out this talk on How Filecoin Actors Work to learn more: |
| 41 | +## Distributed Randomness |
44 | 42 |
|
45 |
| -## Distributed randomness |
46 |
| - |
47 |
| -Filecoin uses distributed and publicly verifiable random beacon protocol - [Drand](https://drand.love) as the randomness beacon for the leader election during the [expected consensus](blockchain.md#expected-consensus) to produce blocks. This randomness guarantees that the leader election is secret, fair, and verifiable. |
| 43 | +Filecoin uses the [Drand](https://drand.love) protocol as a randomness beacon for leader election in the [expected consensus](blockchain.md#expected-consensus) process. This randomness ensures leader election is secret, fair, and verifiable. |
48 | 44 |
|
49 | 45 | ## Nodes
|
50 | 46 |
|
51 |
| -Nodes in the Filecoin network are primarily identified in terms of the services they provide to serve the Filecoin storage network, including chain verifier nodes, client nodes, storage provider nodes, and retrieval provider nodes. Any node participating in the Filecoin network should provide the chain verification service as a minimum. |
| 47 | +Filecoin nodes are categorized by the services they provide to the storage network, including chain verifier nodes, client nodes, storage provider nodes, and retrieval provider nodes. All participating nodes must provide chain verification services. |
52 | 48 |
|
53 |
| -Filecoin is targeting multiple protocol implementations to guarantee the security and resilience of the Filecoin network. Currently, the actively maintained implementations are: |
| 49 | +Filecoin supports multiple protocol implementations to enhance security and resilience. Active implementations include: |
54 | 50 |
|
55 |
| -* [Lotus](https://lotus.filecoin.io/) |
56 |
| -* [Venus](https://github.com/filecoin-project/venus) |
57 |
| -* [Forest](https://github.com/ChainSafe/forest) |
| 51 | +- [Lotus](https://lotus.filecoin.io/) |
| 52 | +- [Venus](https://github.com/filecoin-project/venus) |
| 53 | +- [Forest](https://github.com/ChainSafe/forest) |
58 | 54 |
|
59 | 55 | ## Addresses
|
60 | 56 |
|
61 |
| -In the Filecoin network, addresses are used to identify actors in the Filecoin state. The address encodes information about the corresponding actor, providing a robust address format that is easy to use and resistant to errors. There are five types of addresses in Filecoin. Mainnet addresses begin with the letter `f`, and Testnet addresses begin with the letter `t`. |
| 57 | +In the Filecoin network, addresses identify actors in the Filecoin state. Each address encodes information about the corresponding actor, making it easy to use and resistant to errors. Filecoin has five address types. Mainnet addresses start with `f`, and Testnet addresses start with `t`. |
62 | 58 |
|
63 |
| -* `f0/t0`: an ID address for an actor in a more “human friendly” way. For instance, f0123261 is the ID for a storage provider. |
64 |
| -* `f1/t1`: a secp256k1 wallet address with encrypted key pair. Essentially, this is a wallet address generated from the secp256k1 public key. |
65 |
| -* `f2/t2`: an address represents an actor (smart contract) and is assigned in a way that makes it safe to use during network forks. |
66 |
| -* `f3/t3`: a BLS wallet address generated from a BLS public encryption key. |
67 |
| -* `f4/t4`: the addresses which were created and assigned to user-defined actors by user-definable “address management” actors. This address can receive funds before an actor has been deployed to the address. |
68 |
| -* `f410/t410`: the address space managed by Ethereum Address Manager (EAM) built-in actor. The original Ethereum addresses can be cast as f410/t410 addresses and vice versa to enable existing Ethereum tools to interact seamlessly with the Filecoin network. |
| 59 | +- **`f0/t0`**: ID address for an actor in a human-readable format, such as `f0123261` for a storage provider. |
| 60 | +- **`f1/t1`**: secp256k1 wallet address, generated from an encrypted secp256k1 public key. |
| 61 | +- **`f2/t2`**: Address assigned to an actor (smart contract) in a way that ensures stability across network forks. |
| 62 | +- **`f3/t3`**: BLS wallet address, generated from a BLS public key. |
| 63 | +- **`f4/t4`**: Address created and assigned to user-defined actors by customizable "address management" actors. This address can receive funds before an actor is deployed. |
| 64 | +- **`f410/t410`**: Address space managed by the Ethereum Address Manager (EAM) actor, allowing Ethereum-compatible addresses to interact seamlessly with the Filecoin network. Ethereum addresses can be cast as `f410/t410` addresses and vice versa, enabling compatibility with existing Ethereum tools. |
69 | 65 |
|
70 | 66 | ## Consensus
|
71 | 67 |
|
72 |
| -Let’s quickly cover how consensus works in the Filecoin network. |
73 |
| - |
74 |
| -### Expected consensus |
| 68 | +### Expected Consensus |
75 | 69 |
|
76 |
| -Expected consensus (EC) is the underlying consensus algorithm used by Filecoin. EC is a probabilistic Byzantine fault-tolerant consensus protocol that runs a leader election among a set of storage providers to submit a block every epoch. Like proof-of-stake, Filecoin uses proof-of-storage for the leader election, meaning the likelihood of being elected depends on how much provable storage power a miner contributes to the network. The storage power of the network is stored in the storage power table and managed by the Storage Power Actor. |
| 70 | +Expected Consensus (EC) is the consensus algorithm underlying Filecoin. EC is a probabilistic, Byzantine fault-tolerant protocol that conducts a leader election among storage providers each epoch to determine which provider submits a block. Similar to proof-of-stake, Filecoin’s leader election relies on proof-of-storage, meaning the probability of being elected depends on how much provable storage power a miner contributes to the network. This storage power is recorded in the storage power table, managed by the Storage Power Actor. |
77 | 71 |
|
78 |
| -At a high level, the consensus process relies on [Drand](https://drand.love) to provide distributed and verifiable randomness to keep leader election secret, fair and verifiable. All the election participants and their power are drawn from the Power Table, which is calculated and maintained over time by the Storage Power Consensus subsystem. Eventually, EC takes all valid blocks produced in this epoch and uses a weighting function to select the chain with the highest weight to add blocks. |
| 72 | +At a high level, the consensus process uses [Drand](https://drand.love) to provide distributed, verifiable randomness, ensuring that leader election is secret, fair, and unbiased. Election participants and their storage power are drawn from the Power Table, which is continuously calculated and maintained by the Storage Power Consensus subsystem. Ultimately, EC gathers all valid blocks produced in an epoch and applies a weighting function to select the heaviest chain, adding blocks accordingly. |
79 | 73 |
|
80 |
| -### Block production process |
| 74 | +### Block Production Process |
81 | 75 |
|
82 |
| -The process of producing a block for each epoch can be briefly described as follows: |
| 76 | +The block production process for each epoch is as follows: |
83 | 77 |
|
84 |
| -* Elect leaders from eligible miners. |
85 |
| -* Miners need to check if they are elected. |
86 |
| -* An elected miner gets the randomness value to generate WinningPoSt. |
87 |
| -* If all above is successful, miners build and propagate a block. |
88 |
| -* Verify whether a miner won the block and verify the leader election. |
89 |
| -* Eventually, select the heaviest chain to add blocks. |
| 78 | +- Elect leaders from eligible miners. |
| 79 | +- Miners check if they are elected. |
| 80 | +- Elected miners generate WinningPoSt using randomness. |
| 81 | +- Miners build and propagate a block. |
| 82 | +- Verify the winning miner and election. |
| 83 | +- Select the heaviest chain to add blocks. |
90 | 84 |
|
91 | 85 | ### Finality
|
92 | 86 |
|
93 |
| -EC enforces a version of soft finality whereby all miners at round `N` will reject all blocks that fork off before round `N - F`. `F` is set to `900`. This is important to enforce finality at no cost to chain availability and functionality. |
| 87 | +EC enforces soft finality, where miners at round `N` reject blocks forking off before round `N - F` (where `F` is set to `900`). This ensures finality without compromising chain availability. |
94 | 88 |
|
95 | 89 | ## Proofs
|
96 | 90 |
|
97 |
| -As a decentralized storage network, Filecoin is built on the proof-of-storage in which miners contribute their vacant storage space to the network to store data and then provide proofs for the client to verify if their data has been stored throughout a period. |
| 91 | +Filecoin operates on proof-of-storage, where miners offer storage space and provide proofs to verify data storage. |
98 | 92 |
|
99 |
| -### Proof of replication |
| 93 | +### Proof of Replication |
100 | 94 |
|
101 |
| -Using proof-of-replication (PoRep), storage providers prove that they have created a unique copy of the client’s data and stored it on behalf of the network. |
| 95 | +With proof-of-replication (PoRep), storage providers prove they have created a unique copy of the client’s data for the network. |
102 | 96 |
|
103 |
| -### Proof of spacetime |
| 97 | +### Proof of Spacetime |
104 | 98 |
|
105 |
| -Storage providers also need to continuously prove that they store clients’ data for the whole lifetime of the storage deal. There are two types of challenges as part of the proof-of-spacetime (PoSt) process: |
| 99 | +Storage providers must continuously prove that they are storing clients' data throughout the entire duration of the storage deal. The proof-of-spacetime (PoSt) process includes two types of challenges: |
106 | 100 |
|
107 |
| -* Winning PoSt guarantees that the storage provider maintains a copy of data at a specific time. |
108 |
| -* Window PoSt is used as proof that a copy of the data has been continuously maintained over time. |
| 101 | +- **Winning PoSt**: Verifies that a storage provider holds a copy of the data at a specific point in time. |
| 102 | +- **Window PoSt**: Confirms that the data has been consistently stored over a defined period. |
109 | 103 |
|
110 | 104 | ### Slashing
|
111 | 105 |
|
112 |
| -If storage providers fail to provide reliable uptime or act maliciously against the network, they will be penalized by slashing. Filecoin implements two kinds of slashing: |
113 |
| - |
114 |
| -* Storage fault slashing to penalize storage providers for not being able to maintain healthy and reliable storage sectors for the network. |
115 |
| -* Consensus fault slashing to penalize storage providers to sabotage the liveness and security of the consensus process. |
116 |
| - |
| 106 | +If storage providers fail to maintain reliable uptime or act maliciously, they face penalties through a process called slashing. Filecoin enforces two types of slashing: |
117 | 107 |
|
| 108 | +- **Storage Fault Slashing**: Penalizes providers who fail to maintain healthy and reliable storage sectors. |
| 109 | +- **Consensus Fault Slashing**: Penalizes providers attempting to disrupt the security or availability of the consensus process. |
118 | 110 |
|
119 |
| -[Was this page helpful?](https://airtable.com/apppq4inOe4gmSSlk/pagoZHC2i1iqgphgl/form?prefill\_Page+URL=https://docs.filecoin.io/basics/what-is-filecoin/blockchain) |
| 111 | +[Was this page helpful?](https://airtable.com/apppq4inOe4gmSSlk/pagoZHC2i1iqgphgl/form?prefill_Page+URL=https://docs.filecoin.io/basics/what-is-filecoin/blockchain) |
0 commit comments