From c67444c1c5dd20ce68af39c4932d8e1a4362c185 Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Tue, 4 Aug 2020 20:31:14 +0100 Subject: [PATCH 01/15] Repository blockchain update --- content/systems/filecoin_nodes/repository/_index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/systems/filecoin_nodes/repository/_index.md b/content/systems/filecoin_nodes/repository/_index.md index 85f226ab7..14498dc8a 100644 --- a/content/systems/filecoin_nodes/repository/_index.md +++ b/content/systems/filecoin_nodes/repository/_index.md @@ -10,10 +10,10 @@ dashboardTests: 0 # Repository - Local Storage for Chain Data and Systems -The Filecoin node repository is simply an abstraction denoting that data which any functional Filecoin node needs to store locally in order to run correctly. +The Filecoin node repository is simply an abstraction of the data which any functional Filecoin node needs to store locally in order to run correctly. -The repo is accessible to the node's systems and subsystems and acts as local storage compartementalized from the node's `FileStore` (for instance). +The repository is accessible to the node's systems and subsystems and acts as local storage, which, for example, is compartmentalized from the node's `FileStore`. -It stores the node's keys, the IPLD datastructures of stateful objects and node configs. +The repository stores the node's keys, the IPLD data structures of stateful objects as well as the node configuration settings. {{}} From c997b966f2324808455e94f629b0e1a807097e3c Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Tue, 4 Aug 2020 20:31:51 +0100 Subject: [PATCH 02/15] key store update --- .../repository/key_store/_index.md | 21 +++++++------------ 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/content/systems/filecoin_nodes/repository/key_store/_index.md b/content/systems/filecoin_nodes/repository/key_store/_index.md index 3e6177230..9726f0387 100644 --- a/content/systems/filecoin_nodes/repository/key_store/_index.md +++ b/content/systems/filecoin_nodes/repository/key_store/_index.md @@ -9,26 +9,21 @@ dashboardTests: 0 # Key Store -The `Key Store` is a fundamental abstraction in any full Filecoin node used to store the keypairs associated with a given miner's address and distinct workers (should the miner choose to run multiple workers). +The `Key Store` is a fundamental abstraction in any full Filecoin node used to store the keypairs associated with a given miner's address (see actual definition further down) and distinct workers (should the miner choose to run multiple workers). -Node security depends in large part on keeping these keys secure. To that end we recommend keeping keys separate from any given subsystem and using a separate key store to sign requests as required by subsystems as well as keeping those keys not used as part of mining in cold storage. +Node security depends in large part on keeping these keys secure. To that end we strongly recommend: 1) keeping keys separate from all subsystem, ii) using a separate key store to sign requests as required by other subsystems, and iii) keeping those keys that are not used as part of mining in cold storage. {{}} Filecoin storage miners rely on three main components: -- **The miner address** uniquely assigned to a given storage miner actor upon calling `registerMiner()` in the Storage Power Consensus Subsystem. It is a unique identifier for a given storage miner to which its power and other keys will be associated. -- **The owner keypair** is provided by the miner ahead of registration and its public key associated with the miner address. Block rewards and other payments are made to the ownerAddress. -- **The worker keypair** can be chosen and changed by the miner, its public key associated with the miner address. It is used to sign transactions, signatures, etc. It must be a BLS keypair given its use as part of the [Verifiable Random Function](vrf). +- **The storage miner _actor_ address** is uniquely assigned to a given storage miner actor upon calling `registerMiner()` in the Storage Power Consensus Subsystem. In effect, the storage miner does not have an address itself, but is rather identified by the address of the actor it is tied to. This is a unique identifier for a given storage miner to which its power and other keys will be associated. The `actor value` specifies the address of an already created miner actor. +- **The owner keypair** is provided by the miner ahead of registration and its public key associated with the miner address. Block rewards and other payments are made to the `ownerAddress`. +- **The worker keypair** is the public key associated with the storage miner actor address. It can be chosen and changed by the miner. The worker keypair is used to sign transactions and signatures. It must be a BLS keypair given its use as part of the [Verifiable Random Function](vrf). -While miner addresses are unique, multiple storage miner actors can share an owner public key or likewise a worker public key. +Multiple storage miner actors can share one owner public key or likewise a worker public key. -The process for changing the worker keypairs on-chain (i.e. the workerKey associated with a storage miner) is specified in [Storage Miner Actor](storage_miner_actor). Note that this is a two-step process. First a miner stages a change by sending a message to the chain. When received, the key change is staged to occur in twice the randomness lookback parameter number of epochs, to prevent adaptive key selection attacks. +The process for changing the worker keypairs on-chain (i.e. the worker Key associated with a storage miner actor) is specified in [Storage Miner Actor](storage_miner_actor). Note that this is a two-step process. First, a miner stages a change by sending a message to the chain. When received, the key change is staged to occur in twice the randomness lookback parameter number of epochs, to prevent adaptive key selection attacks. Every time a worker key is queried, a pending change is lazily checked and state is potentially updated as needed. -{{}} -TODO: - -- potential reccomendations or clear disclaimers with regards to consequences of failed key security - -{{}} \ No newline at end of file +Key security is of utmost importance in Filecoin, as is also the case with keys in every blockchain. **Failure to securely store and use keys or exposure of private keys to adversaries can result in the adversary having access to the miner's funds.** From 6192462f015076808ea7f5757e0099b8906784f7 Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Wed, 5 Aug 2020 08:35:47 +0100 Subject: [PATCH 03/15] ipldStore update --- .../filecoin_nodes/repository/_index.md | 6 ++++++ .../repository/ipldstore/_index.md | 21 ++++++++++++------- .../repository/key_store/_index.md | 2 ++ 3 files changed, 22 insertions(+), 7 deletions(-) diff --git a/content/systems/filecoin_nodes/repository/_index.md b/content/systems/filecoin_nodes/repository/_index.md index 14498dc8a..5fa5f3a1c 100644 --- a/content/systems/filecoin_nodes/repository/_index.md +++ b/content/systems/filecoin_nodes/repository/_index.md @@ -16,4 +16,10 @@ The repository is accessible to the node's systems and subsystems and acts as lo The repository stores the node's keys, the IPLD data structures of stateful objects as well as the node configuration settings. + \ No newline at end of file diff --git a/content/systems/filecoin_nodes/repository/ipldstore/_index.md b/content/systems/filecoin_nodes/repository/ipldstore/_index.md index 9e906fac2..107e08de8 100644 --- a/content/systems/filecoin_nodes/repository/ipldstore/_index.md +++ b/content/systems/filecoin_nodes/repository/ipldstore/_index.md @@ -10,7 +10,16 @@ dashboardTests: 0 # IPLD Store - Local Storage for hash-linked data -IPLD is a set of libraries which allow for the interoperability of content-addressed data structures across different distributed systems. It provides a fundamental 'common language' to primitive cryptographic hashing, enabling data to be verifiably referenced and retrieved between two independent protocols. For example, a user can reference a git commit in a blockchain transaction to create an immutable copy and timestamp, or a data from a DHT can be referenced and linked to in a smart contract. +The InterPlanetary Linked Data (IPLD) is a set of libraries which allow for the interoperability of content-addressed data structures across different distributed systems an protocols. It provides a fundamental 'common language' to primitive cryptographic hashing, enabling data to be verifiably referenced and retrieved between two independent protocols. For example, a user can reference an IPFS directory in an Ethereum transaction or smart contract. + +IPLD is fundamentally comprised of three layers: + +- the Block Layer, which focuses on block formats and addressing, how blocks can advertise or self-describe their codec +- the Data Model Layer, which defines a set of required types that need to be included in any implementation - discussed in more detail below. +- the Schema Layer, which allows for extension of the Data Model to interact with more complex structures without the need for custom translation abstractions. + +Further details about IPLD can be found in its [specification](https://github.com/ipld/specs). + ## The Data Model @@ -22,13 +31,11 @@ Applications interact with IPLD via the Data Model, and IPLD handles marshalling ## IPLD in Filecoin -On the Filecoin network, IPLD is used in two ways: - -- All system datastructures are stored in [IPLD](https://ipld.io) format, a data format akin to JSON but designed for storage, retrieval and traversal of hash-linked data DAGs. -- Files and data stored on the Filecoin network may also be stored in IPLD format. While this is not required, it offers the benefit of supporting [selectors](https://github.com/ipld/specs/blob/master/selectors/selectors.md) to retrieve a smaller subset of the total stored data, as opposed to inefficiently downloading the data set entirely. - -IPLD provides a consistent and coherent abstraction above data that allows Filecoin to build and interact with complex, multi-block data structures, such as HAMT and Sharray. Filecoin uses the **DAG-CBOR** codec for the serialization and deserialization of its data structures and interacts with that data using the IPLD Data Model, upon which various tools are built. IPLD [Paths](https://github.com/ipld/specs/blob/master/data-model-layer/paths.md) are also used to address specific nodes within a linked data structure. +IPLD is used in two ways in the Filecoin network: +- All system datastructures are stored using DAG-CBOR ( an IPLD codec). DAG-CBOR is a more strict subset of CBOR with a predefined tagging scheme, designed for storage, retrieval and traversal of hash-linked data DAGs. +- Files and data stored on the Filecoin network are also stored using various IPLD codecs (not necessarily DAG-CBOR). +IPLD provides a consistent and coherent abstraction above data that allows Filecoin to build and interact with complex, multi-block data structures, such as HAMT and AMT. Filecoin uses the DAG-CBOR codec for the serialization and deserialization of its data structures and interacts with that data using the IPLD Data Model, upon which various tools are built. IPLD Selectors can also be used to address specific nodes within a linked data structure. ### IpldStores diff --git a/content/systems/filecoin_nodes/repository/key_store/_index.md b/content/systems/filecoin_nodes/repository/key_store/_index.md index 9726f0387..59b792a26 100644 --- a/content/systems/filecoin_nodes/repository/key_store/_index.md +++ b/content/systems/filecoin_nodes/repository/key_store/_index.md @@ -13,7 +13,9 @@ The `Key Store` is a fundamental abstraction in any full Filecoin node used to s Node security depends in large part on keeping these keys secure. To that end we strongly recommend: 1) keeping keys separate from all subsystem, ii) using a separate key store to sign requests as required by other subsystems, and iii) keeping those keys that are not used as part of mining in cold storage. + Filecoin storage miners rely on three main components: From 24a4610847ceb0fb133e01dfaf1957e50bf87224 Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Wed, 5 Aug 2020 12:00:09 +0100 Subject: [PATCH 04/15] network interface and clock update --- .../systems/filecoin_nodes/clock/_index.md | 3 +- .../systems/filecoin_nodes/network/_index.md | 53 ++++--------------- 2 files changed, 10 insertions(+), 46 deletions(-) diff --git a/content/systems/filecoin_nodes/clock/_index.md b/content/systems/filecoin_nodes/clock/_index.md index ff3dc4824..7d566f79e 100644 --- a/content/systems/filecoin_nodes/clock/_index.md +++ b/content/systems/filecoin_nodes/clock/_index.md @@ -30,7 +30,7 @@ In order to allow miners to do the above, the system clock must: 1. Have low enough clock drift (sub 1s) relative to other nodes so that blocks are not mined in epochs considered future epochs from the persective of other nodes (those blocks should not be validated until the proper epoch/time as per [validation rules](block#block-semantic-validation)). 2. Set epoch number on node initialization equal to `epoch = Floor[(current_time - genesis_time) / epoch_time]` -It is expected that other subsystems will register to a NewRound() event from the clock subsystem. +It is expected that other subsystems will register to a `NewRound()` event from the clock subsystem. ## Clock Requirements @@ -45,7 +45,6 @@ Computer-grade clock crystals can be expected to have drift rates on the order o - `time.google.com` (more on [Google Public NTP](https://developers.google.com/time)) - `ntp-b.nist.gov` ([NIST](https://tf.nist.gov/tf-cgi/servers.cgi) servers require registration) - We further recommend making 3 measurements in order to drop by using the network to drop outliers - - See how [go-ethereum does this](https://github.com/ethereum/go-ethereum/blob/master/p2p/discv5/ntp.go) for inspiration - clients MAY consider using cesium clocks instead for accurate synchrony within larger mining operations Mining operations have a strong incentive to prevent their clock from drifting ahead more than one epoch to keep their block submissions from being rejected. Likewise they have an incentive to prevent their clocks from drifting behind more than one epoch to avoid partitioning themselves off from the synchronized nodes in the network. diff --git a/content/systems/filecoin_nodes/network/_index.md b/content/systems/filecoin_nodes/network/_index.md index 013e6585b..880bd110d 100644 --- a/content/systems/filecoin_nodes/network/_index.md +++ b/content/systems/filecoin_nodes/network/_index.md @@ -9,52 +9,17 @@ dashboardTests: 0 # Interface + +Filecoin nodes use several protocols of the libp2p networking stack for peer discovery, peer routing and block and message propagation. Libp2p is a modular networking stack for peer-to-peer networks. It includes several protocols and mechanisms to enable efficient, secure and resilient peer-to-peer communication. Libp2p nodes open connections with one another and mount different protocols or streams over the same connection. In the initial handshake, nodes exchange the protocols that each of them supports and all Filecoin related protocols will be mounted under `/fil/...` protocol identifiers. -Filecoin nodes use the libp2p protocol for peer discovery, peer routing, and message multicast, and so on. Libp2p is a set of modular protocols common to the peer-to-peer networking stack. Nodes open connections with one another and mount different protocols or streams over the same connection. In the initial handshake, nodes exchange the protocols that each of them supports and all Filecoin related protcols will be mounted under `/fil/...` protocol identifiers. - +The complete specification of libp2p can be found at [https://github.com/libp2p/specs](https://github.com/libp2p/specs). Here is the list of libp2p protocols used by Filecoin. -- Graphsync: - - Graphsync is used to transfer blockchain and user data - - [Draft spec](https://github.com/ipld/specs/blob/master/block-layer/graphsync/graphsync.md) - - No filecoin specific modifications to the protocol id -- Gossipsub: - - block headers and messages are broadcasted through a Gossip PubSub protocol where nodes can subscribe to topics for blockchain data and receive messages in those topics. When receiving messages related to a topic, nodes process the message and forward it to peers who also subscribed to the same topic. - - Spec is [here](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) - - No filecoin specific modifications to the protocol id. However the topic identifiers MUST be of the form `fil/blocks/` and `fil/msgs/` -- KademliaDHT: - - Kademlia DHT is a distributed hash table with a logarithmic bound on the maximum number of lookups for a particular node. Kad DHT is used primarily for peer routing as well as peer discovery in the Filecoin protocol. - - Spec TODO [reference implementation](https://github.com/libp2p/go-libp2p-kad-dht) - - The protocol id must be of the form `fil//kad/1.0.0` -- Bootstrap List: - - Bootstrap is a list of nodes that a new node attempts to connect to upon joining the network. The list of bootstrap nodes and their addresses are defined by the users. -- Peer Exchange: - - Peer Exchange is a discovery protocol enabling peers to create and issue queries for desired peers against their existing peers - - spec [TODO](https://github.com/libp2p/specs/issues/222) - - No Filecoin specific modifications to the protocol id. -- DNSDiscovery: Design and spec needed before implementing -- HTTPDiscovery: Design and spec needed before implementing -- Hello: - - Hello protocol handles new connections to filecoin nodes to facilitate discovery - - the protocol string is `fil/hello/1.0.0`. - -## Hello Spec - -### Protocol Flow - -`fil/hello` is a filecoin specific protocol built on the libp2p stack. It consists of two conceptual -procedures: `hello_connect` and `hello_listen`. - -`hello_listen`: `on new stream` -> `read peer hello msg from stream` -> `write latency message to stream` -> `close stream` - -`hello_connect`: `on connected` -> `open stream` -> `write own hello msg to stream` -> `read peer latency msg from stream` -> `close stream` - -where stream and connection operations are all standard libp2p operations. Nodes running the Hello Protocol should consume the incoming Hello Message and use it to help manage peers and sync the chain. - -### Messages -{{}} - - -When writing the `HelloMessage` to the stream the peer must inspect its current head to provide accurate information. When writing the `LatencyMessage` to the stream the peer should set `TArrival` immediately upon receipt and `TSent` immediately before writing the message to the stream. +- Graphsync: Graphsync is a protocol to synchronize graphs across peers. It is used to reference, address, request and transfer blockchain and user data between Filecoin nodes. The [draft specification of GraphSync](https://github.com/ipld/specs/blob/master/block-layer/graphsync/graphsync.md) provides more details on the concepts, the interfaces and the network messages used by GraphSync. There are no Filecoin-specific modifications to the protocol id. +- Gossipsub: Block headers and Transaction messages are propagating through the Filecoin network using a gossip-based pubsub protocol acronymed _GossipSub_. As is traditionally the case with pubsub protocols, nodes subscribe to topics and receive messages published on those topics. When nodes receive messages from a topic they are subscribed to, they run a validation process and i) pass the message to the application, ii) forward the message further to nodes they know off being subscribed to the same topic. Furthermore, v1.1 version of GossipSub, which is the one used in Filecoin is enhanced with security mechanisms that make the protocol resilient against security attacks. The [GossipSub Specification](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) provides all the protocol details pertaining to its design and implementation, as well as specific settings for the protocols parameters. There have been no filecoin specific modifications to the protocol id. However the topic identifiers MUST be of the form `fil/blocks/` and `fil/msgs/` +- Kademlia DHT: The Kademlia DHT is a distributed hash table with a logarithmic bound on the maximum number of lookups for a particular node. In the Filecoin network, the Kademlia DHT is used primarily for peer discovery and peer routing. In particular, when a node wants to store data in the Filecoin network, they get a list of miners and their node information. This node information includes (among other things) the PeerID of the miner. In order to connect to the miner and exchange data, the node that wants to store data in the network has to find the Multiaddress of the miner, which they do by queering the DHT. The [libp2p Kad DHT Specification](https://github.com/libp2p/go-libp2p-kad-dht) provides implementation details of the DHT structure. For the Filecoin network, the protocol id must be of the form `fil//kad/1.0.0`. +- Bootstrap List: This is a list of nodes that a new node attempts to connect to upon joining the network. The list of bootstrap nodes and their addresses are defined by the users. +- Peer Exchange: This protocol is the realisation of the peer discovery process discussed above in the Kademlia DHT point. It enables peers to find information and addresses of other peers in the network by interfacing with the DHT and create and issue queries for the peers they want to reach out to. From 319e47cb74ec579658d3ebfa92b46e0fc6fc4d3c Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Wed, 5 Aug 2020 13:10:07 +0100 Subject: [PATCH 05/15] node types update --- content/systems/filecoin_nodes/_index.md | 6 +++--- .../filecoin_nodes/node_types/_index.md | 20 ++++++++++++++++++- 2 files changed, 22 insertions(+), 4 deletions(-) diff --git a/content/systems/filecoin_nodes/_index.md b/content/systems/filecoin_nodes/_index.md index 6387c2e3b..2faaeaa21 100644 --- a/content/systems/filecoin_nodes/_index.md +++ b/content/systems/filecoin_nodes/_index.md @@ -10,8 +10,8 @@ dashboardTests: 0 # Filecoin Nodes -This section is providing all the details needed in order to implement any of the different Filecoin Nodes. Although node types in the Filecoin blockchain are less strictly defined than in other blockchains, there are still a few different types of nodes each with its own features and characteristics. +This section is providing the required details in order to implement any of the different Filecoin nodes. Although node types in the Lotus implementation of Filecoin are less strictly defined than in other blockchain networks, there are different properties and features that different types of nodes should implement. -In this section we also discuss issues related to storage of system files in Filecoin nodes. Note that by storage in this section we do not refer to the storage that a node is commiting for mining in the network, but rather the local storage that it needs to have available for keys and IPLD data among other things. +In this section we also discuss issues related to storage of system files in Filecoin nodes. Note that by storage in this section we do not refer to the storage that a node is committing for mining in the network, but rather the local storage repositories that it needs to have available for keys and IPLD data among other things. -The network interface and how nodes connect with each other and interact using libp2p, as well as how to set the node's clock is also discussed here. +In this section we are also discussing the network interface and how nodes find and connect with each other, how they interact and propagate messages using libp2p, as well as how to set the node's clock. diff --git a/content/systems/filecoin_nodes/node_types/_index.md b/content/systems/filecoin_nodes/node_types/_index.md index 05d642c46..93f6e5ee5 100644 --- a/content/systems/filecoin_nodes/node_types/_index.md +++ b/content/systems/filecoin_nodes/node_types/_index.md @@ -8,4 +8,22 @@ dashboardAudit: n/a dashboardTests: 0 --- -# Node Types \ No newline at end of file +# Node Types + +Two types of nodes: full node and miner node. Full (validation) node is a repository, interacts with miner. Full nodes read the chain. Full node needs to reach consensus and do chain sync. + +Miner creates nodes. A different repository. Does full validation, extends the chain. + +Fundamentally, there are only two major node types in the Filecoin network and this is how the Lotus implementation is realising _node types_ in the strict sense of the word. These are: + +The **Full Node:** this is the chain validation or chain verifier node. In essense, this type of node is a repository that interacts with one or more miner node(s). A Full Node must synchronise the chain (ChainSync) when it first joins the network. From then on, the node must read the chain and reach consensus state. +The **Miner Node:** Miner nodes are the backbone of the Filecoin blockchain network. They have all the functionality of the Full Node, but also extend this functionality to create blocks, submit blocks to the blockchain and ultimately extend the blockchain. + +In order to realise the full potential of the Filecoin network, there is more functionality that needs to be added on top of the _base_ node types described above. Different node types are not mutually exclusive to each other, meaning that one physical node might have to implement more than one type of node functionality. + +A Filecoin implementation should support the following types of nodes: + +- **Chain Verifier Node:** this is the **Full Node** described above. This type of node cannot play an active role in the network, unless it implements **Client Node** functionality, described below. +- **Client Node:** this type of node builds on top of the **Full or Chain Verifier Node** and must be implemented by any application that is building on the Filecoin network. This can be thought of as the main infrastructure node (at least as far as interaction with the blockchain is concerned) of applications such as exchanges or decentralised storage applications building on Filecoin. The node should implement and interact (as a client) with the Storage and Retrieval Markets, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. +- **Retrieval Miner Node:** this node type is extending the **Full or Chain Verifier Node** to add _retrieval miner_ functionality, that is, participate in the retrieval market. As such, this node type needs to implement the retrieval market provider subsystem, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. +- **Storage Miner Node:** this type of node is building on top of the Miner Node described above and must implement all of its functionality for validating, creating and adding blocks to the blockchain. It should implement the storage mining subsystem, the storage market provider subsystem, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. From cd866f57b741b1a0afc6528d50623fc4ae46466e Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Wed, 5 Aug 2020 13:17:06 +0100 Subject: [PATCH 06/15] remove empty subsection --- .../filecoin_nodes/node_types/node_types.md | 18 ------------------ 1 file changed, 18 deletions(-) delete mode 100644 content/systems/filecoin_nodes/node_types/node_types.md diff --git a/content/systems/filecoin_nodes/node_types/node_types.md b/content/systems/filecoin_nodes/node_types/node_types.md deleted file mode 100644 index 410ace9a7..000000000 --- a/content/systems/filecoin_nodes/node_types/node_types.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Examples -weight: 2 -dashboardWeight: 1 -dashboardState: wip -dashboardAudit: n/a -dashboardTests: 0 ---- - -# Examples - -There are many kinds of Filecoin Nodes ... - -This section should contain: - -- what all nodes must have, and why -- examples of using different systems - From a1cab52ae7fb96481ffeed494b9bba86993c56e1 Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Tue, 11 Aug 2020 07:19:48 +0100 Subject: [PATCH 07/15] mikeal's comments addressed --- .../systems/filecoin_nodes/repository/ipldstore/_index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/systems/filecoin_nodes/repository/ipldstore/_index.md b/content/systems/filecoin_nodes/repository/ipldstore/_index.md index 107e08de8..68221ca72 100644 --- a/content/systems/filecoin_nodes/repository/ipldstore/_index.md +++ b/content/systems/filecoin_nodes/repository/ipldstore/_index.md @@ -2,7 +2,7 @@ title: IPLD Store weight: 3 dashboardWeight: 1 -dashboardState: wip +dashboardState: stable dashboardAudit: wip dashboardTests: 0 --- @@ -10,7 +10,7 @@ dashboardTests: 0 # IPLD Store - Local Storage for hash-linked data -The InterPlanetary Linked Data (IPLD) is a set of libraries which allow for the interoperability of content-addressed data structures across different distributed systems an protocols. It provides a fundamental 'common language' to primitive cryptographic hashing, enabling data to be verifiably referenced and retrieved between two independent protocols. For example, a user can reference an IPFS directory in an Ethereum transaction or smart contract. +InterPlanetary Linked Data (IPLD) is a set of libraries which allow for the interoperability of content-addressed data structures across different distributed systems and protocols. It provides a fundamental 'common language' to primitive cryptographic hashing, enabling data structures to be verifiably referenced and retrieved between two independent protocols. For example, a user can reference an IPFS directory in an Ethereum transaction or smart contract. IPLD is fundamentally comprised of three layers: @@ -32,7 +32,7 @@ Applications interact with IPLD via the Data Model, and IPLD handles marshalling ## IPLD in Filecoin IPLD is used in two ways in the Filecoin network: -- All system datastructures are stored using DAG-CBOR ( an IPLD codec). DAG-CBOR is a more strict subset of CBOR with a predefined tagging scheme, designed for storage, retrieval and traversal of hash-linked data DAGs. +- All system datastructures are stored using DAG-CBOR (an IPLD codec). DAG-CBOR is a more strict subset of CBOR with a predefined tagging scheme, designed for storage, retrieval and traversal of hash-linked data DAGs. As compared to CBOR, DAG-CBOR can guarantee determinism. - Files and data stored on the Filecoin network are also stored using various IPLD codecs (not necessarily DAG-CBOR). IPLD provides a consistent and coherent abstraction above data that allows Filecoin to build and interact with complex, multi-block data structures, such as HAMT and AMT. Filecoin uses the DAG-CBOR codec for the serialization and deserialization of its data structures and interacts with that data using the IPLD Data Model, upon which various tools are built. IPLD Selectors can also be used to address specific nodes within a linked data structure. From 36d97091f775d72309ef7a33c68e5204fb3105cd Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Mon, 17 Aug 2020 04:40:20 +0100 Subject: [PATCH 08/15] remove scratchpad --- content/systems/filecoin_nodes/node_types/_index.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/content/systems/filecoin_nodes/node_types/_index.md b/content/systems/filecoin_nodes/node_types/_index.md index 93f6e5ee5..bfdbbc89c 100644 --- a/content/systems/filecoin_nodes/node_types/_index.md +++ b/content/systems/filecoin_nodes/node_types/_index.md @@ -10,10 +10,6 @@ dashboardTests: 0 # Node Types -Two types of nodes: full node and miner node. Full (validation) node is a repository, interacts with miner. Full nodes read the chain. Full node needs to reach consensus and do chain sync. - -Miner creates nodes. A different repository. Does full validation, extends the chain. - Fundamentally, there are only two major node types in the Filecoin network and this is how the Lotus implementation is realising _node types_ in the strict sense of the word. These are: The **Full Node:** this is the chain validation or chain verifier node. In essense, this type of node is a repository that interacts with one or more miner node(s). A Full Node must synchronise the chain (ChainSync) when it first joins the network. From then on, the node must read the chain and reach consensus state. From 16825263335a5a33c3bd387e35dd3c7f0e696686 Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Mon, 17 Aug 2020 05:28:51 +0100 Subject: [PATCH 09/15] revised for clarity and addressed schomatis comments --- content/systems/filecoin_nodes/node_types/_index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/systems/filecoin_nodes/node_types/_index.md b/content/systems/filecoin_nodes/node_types/_index.md index bfdbbc89c..c5878273a 100644 --- a/content/systems/filecoin_nodes/node_types/_index.md +++ b/content/systems/filecoin_nodes/node_types/_index.md @@ -10,14 +10,14 @@ dashboardTests: 0 # Node Types -Fundamentally, there are only two major node types in the Filecoin network and this is how the Lotus implementation is realising _node types_ in the strict sense of the word. These are: +Fundamentally, there are only two major node types in the Filecoin network and this is how the Lotus implementation is realising _node types_ in the strict sense of the word. Nodes are identified with a repository (directory) in the host in a one-to-one relationship - that is one repo belongs to a single node. That said one host might realise multiple Filecoin nodes by having the corresponding repositories. The two major node types are: -The **Full Node:** this is the chain validation or chain verifier node. In essense, this type of node is a repository that interacts with one or more miner node(s). A Full Node must synchronise the chain (ChainSync) when it first joins the network. From then on, the node must read the chain and reach consensus state. +The **Full Node:** this is the chain validation or chain verifier node. A Full Node must synchronise the chain (ChainSync) when it first joins the network to reach current consensus. From then on, the node must constantly be fetching any addition to the chain (i.e., receive the latest blocks) and validate them to reach consensus state. The **Miner Node:** Miner nodes are the backbone of the Filecoin blockchain network. They have all the functionality of the Full Node, but also extend this functionality to create blocks, submit blocks to the blockchain and ultimately extend the blockchain. -In order to realise the full potential of the Filecoin network, there is more functionality that needs to be added on top of the _base_ node types described above. Different node types are not mutually exclusive to each other, meaning that one physical node might have to implement more than one type of node functionality. +In order to realise the full potential of the Filecoin network, there is more functionality that needs to be added on top of the _base_ node types described above. This extra functionality can be thought of as a service or subsystem that run on top of the two node types above. We refer to a node that realises extra functionality as _node_ too, for clarity. However, note that different node types are not mutually exclusive to each other, meaning that one physical node might have to implement more than one type of node functionality. -A Filecoin implementation should support the following types of nodes: +A Filecoin implementation should support the following subsystems, or types of nodes: - **Chain Verifier Node:** this is the **Full Node** described above. This type of node cannot play an active role in the network, unless it implements **Client Node** functionality, described below. - **Client Node:** this type of node builds on top of the **Full or Chain Verifier Node** and must be implemented by any application that is building on the Filecoin network. This can be thought of as the main infrastructure node (at least as far as interaction with the blockchain is concerned) of applications such as exchanges or decentralised storage applications building on Filecoin. The node should implement and interact (as a client) with the Storage and Retrieval Markets, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. From 65e65bdf30cea6fab7096e1211c9fe65bea14447 Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Tue, 25 Aug 2020 23:11:04 +0300 Subject: [PATCH 10/15] FIL node description update - nodes from services --- .../filecoin_nodes/node_types/_index.md | 95 ++++++++++++++++--- .../repository/ipldstore/_index.md | 1 - 2 files changed, 84 insertions(+), 12 deletions(-) diff --git a/content/systems/filecoin_nodes/node_types/_index.md b/content/systems/filecoin_nodes/node_types/_index.md index c5878273a..cc5aff027 100644 --- a/content/systems/filecoin_nodes/node_types/_index.md +++ b/content/systems/filecoin_nodes/node_types/_index.md @@ -3,23 +3,96 @@ title: Node Types weight: 1 bookCollapseSection: true dashboardWeight: 1 -dashboardState: wip +dashboardState: stable dashboardAudit: n/a dashboardTests: 0 --- -# Node Types +Nodes in the Filecoin network are primarily identified in terms of the services they provide. The type of node, therefore, depends on which services a node provides. A basic set of services in the Filecoin network include: +- chain verification +- storage market client +- storage market provider +- retrieval market client +- retrieval market provider +- storage mining -Fundamentally, there are only two major node types in the Filecoin network and this is how the Lotus implementation is realising _node types_ in the strict sense of the word. Nodes are identified with a repository (directory) in the host in a one-to-one relationship - that is one repo belongs to a single node. That said one host might realise multiple Filecoin nodes by having the corresponding repositories. The two major node types are: +Any node participating in the Filecoin network should provide the _chain verification_ service as a minimum. Depending on which extra services a node provides on top of chain verification, it gets the corresponding functionality and Node Type "label". -The **Full Node:** this is the chain validation or chain verifier node. A Full Node must synchronise the chain (ChainSync) when it first joins the network to reach current consensus. From then on, the node must constantly be fetching any addition to the chain (i.e., receive the latest blocks) and validate them to reach consensus state. -The **Miner Node:** Miner nodes are the backbone of the Filecoin blockchain network. They have all the functionality of the Full Node, but also extend this functionality to create blocks, submit blocks to the blockchain and ultimately extend the blockchain. - -In order to realise the full potential of the Filecoin network, there is more functionality that needs to be added on top of the _base_ node types described above. This extra functionality can be thought of as a service or subsystem that run on top of the two node types above. We refer to a node that realises extra functionality as _node_ too, for clarity. However, note that different node types are not mutually exclusive to each other, meaning that one physical node might have to implement more than one type of node functionality. +Nodes can be realized with a repository (directory) in the host in a one-to-one relationship - that is, one repo belongs to a single node. That said, one host can implement multiple Filecoin nodes by having the corresponding repositories. A Filecoin implementation should support the following subsystems, or types of nodes: -- **Chain Verifier Node:** this is the **Full Node** described above. This type of node cannot play an active role in the network, unless it implements **Client Node** functionality, described below. -- **Client Node:** this type of node builds on top of the **Full or Chain Verifier Node** and must be implemented by any application that is building on the Filecoin network. This can be thought of as the main infrastructure node (at least as far as interaction with the blockchain is concerned) of applications such as exchanges or decentralised storage applications building on Filecoin. The node should implement and interact (as a client) with the Storage and Retrieval Markets, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. -- **Retrieval Miner Node:** this node type is extending the **Full or Chain Verifier Node** to add _retrieval miner_ functionality, that is, participate in the retrieval market. As such, this node type needs to implement the retrieval market provider subsystem, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. -- **Storage Miner Node:** this type of node is building on top of the Miner Node described above and must implement all of its functionality for validating, creating and adding blocks to the blockchain. It should implement the storage mining subsystem, the storage market provider subsystem, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. +- **Chain Verifier Node:** this is the minimum functionality that a node needs to have in order to participate in the Filecoin network. This type of node cannot play an active role in the network, unless it implements **Client Node** functionality, described below. A Chain Verifier Node must synchronise the chain (ChainSync) when it first joins the network to reach current consensus. From then on, the node must constantly be fetching any addition to the chain (i.e., receive the latest blocks) and validate them to reach consensus state. +- **Client Node:** this type of node builds on top of the **Chain Verifier Node** and must be implemented by any application that is building on the Filecoin network. This can be thought of as the main infrastructure node (at least as far as interaction with the blockchain is concerned) of applications such as exchanges or decentralised storage applications building on Filecoin. The node should implement the _storage market and retrieval market client_ services. The client node should interact with the Storage and Retrieval Markets, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. +- **Retrieval Miner Node:** this node type is extending the **Chain Verifier Node** to add _retrieval miner_ functionality, that is, participate in the retrieval market. As such, this node type needs to implement the _retrieval market provider_ service, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. +- **Storage Miner Node:** this type of node must implement all of the required functionality for validating, creating and adding blocks to extend the blockchain. It should implement the chain verification, storage mining and storage market provider services, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. + +# Node Interface + +{{}} + +# Chain Verifier Node + +```go +type ChainVerifierNode interface { + FilecoinNode + + systems.Blockchain +} +``` +{{}} + +# Client Node + +```go +type ClientNode struct { + FilecoinNode + + systems.Blockchain + markets.StorageMarketClient + markets.RetrievalMarketClient + markets.MarketOrderBook + markets.DataTransfers +} +``` +{{}} + +# Storage Miner Node + +```go +type StorageMinerNode interface { + FilecoinNode + + systems.Blockchain + systems.Mining + markets.StorageMarketProvider + markets.MarketOrderBook + markets.DataTransfers +} +``` +{{}} + +# Retrieval Miner Node + +```go +type RetrievalMinerNode interface { + FilecoinNode + + blockchain.Blockchain + markets.RetrievalMarketProvider + markets.MarketOrderBook + markets.DataTransfers +} +``` + +# Relayer Node + +```go +type RelayerNode interface { + FilecoinNode + + blockchain.MessagePool + markets.MarketOrderBook +} +``` + diff --git a/content/systems/filecoin_nodes/repository/ipldstore/_index.md b/content/systems/filecoin_nodes/repository/ipldstore/_index.md index 68221ca72..39773da01 100644 --- a/content/systems/filecoin_nodes/repository/ipldstore/_index.md +++ b/content/systems/filecoin_nodes/repository/ipldstore/_index.md @@ -9,7 +9,6 @@ dashboardTests: 0 # IPLD Store - Local Storage for hash-linked data - InterPlanetary Linked Data (IPLD) is a set of libraries which allow for the interoperability of content-addressed data structures across different distributed systems and protocols. It provides a fundamental 'common language' to primitive cryptographic hashing, enabling data structures to be verifiably referenced and retrieved between two independent protocols. For example, a user can reference an IPFS directory in an Ethereum transaction or smart contract. IPLD is fundamentally comprised of three layers: From a373f5c44a504d93a2f3fffc450c12396a3188ef Mon Sep 17 00:00:00 2001 From: yiannisbot Date: Tue, 25 Aug 2020 23:15:15 +0300 Subject: [PATCH 11/15] deleting thin files - integrated in _index --- .../filecoin_nodes/node_types/client_node.md | 22 ------------------- .../systems/filecoin_nodes/node_types/node.md | 12 ---------- .../filecoin_nodes/node_types/relayer_node.md | 19 ---------------- .../node_types/retrieval_miner_node.md | 21 ------------------ .../node_types/storage_miner_node.md | 22 ------------------- .../node_types/verifier_node.md | 18 --------------- 6 files changed, 114 deletions(-) delete mode 100644 content/systems/filecoin_nodes/node_types/client_node.md delete mode 100644 content/systems/filecoin_nodes/node_types/node.md delete mode 100644 content/systems/filecoin_nodes/node_types/relayer_node.md delete mode 100644 content/systems/filecoin_nodes/node_types/retrieval_miner_node.md delete mode 100644 content/systems/filecoin_nodes/node_types/storage_miner_node.md delete mode 100644 content/systems/filecoin_nodes/node_types/verifier_node.md diff --git a/content/systems/filecoin_nodes/node_types/client_node.md b/content/systems/filecoin_nodes/node_types/client_node.md deleted file mode 100644 index 0aed3608f..000000000 --- a/content/systems/filecoin_nodes/node_types/client_node.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Client Node -weight: 4 -dashboardWeight: 1 -dashboardState: wip -dashboardAudit: n/a -dashboardTests: 0 ---- - -# Client Node - -```go -type ClientNode struct { - FilecoinNode - - systems.Blockchain - markets.StorageMarketClient - markets.RetrievalMarketClient - markets.MarketOrderBook - markets.DataTransfers -} -``` diff --git a/content/systems/filecoin_nodes/node_types/node.md b/content/systems/filecoin_nodes/node_types/node.md deleted file mode 100644 index 3aaa6e2a5..000000000 --- a/content/systems/filecoin_nodes/node_types/node.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Node Interface -weight: 1 -dashboardWeight: 1 -dashboardState: wip -dashboardAudit: n/a -dashboardTests: 0 ---- - -# Node Interface - -{{}} diff --git a/content/systems/filecoin_nodes/node_types/relayer_node.md b/content/systems/filecoin_nodes/node_types/relayer_node.md deleted file mode 100644 index fa59f6a60..000000000 --- a/content/systems/filecoin_nodes/node_types/relayer_node.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Relayer Node -weight: 7 -dashboardWeight: 1 -dashboardState: wip -dashboardAudit: n/a -dashboardTests: 0 ---- - -# Relayer Node - -```go -type RelayerNode interface { - FilecoinNode - - blockchain.MessagePool - markets.MarketOrderBook -} -``` diff --git a/content/systems/filecoin_nodes/node_types/retrieval_miner_node.md b/content/systems/filecoin_nodes/node_types/retrieval_miner_node.md deleted file mode 100644 index 24575ab54..000000000 --- a/content/systems/filecoin_nodes/node_types/retrieval_miner_node.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Retrieval Miner Node -weight: 6 -dashboardWeight: 1 -dashboardState: wip -dashboardAudit: n/a -dashboardTests: 0 ---- - -# Retrieval Miner Node - -```go -type RetrievalMinerNode interface { - FilecoinNode - - blockchain.Blockchain - markets.RetrievalMarketProvider - markets.MarketOrderBook - markets.DataTransfers -} -``` diff --git a/content/systems/filecoin_nodes/node_types/storage_miner_node.md b/content/systems/filecoin_nodes/node_types/storage_miner_node.md deleted file mode 100644 index 841a2aedb..000000000 --- a/content/systems/filecoin_nodes/node_types/storage_miner_node.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Storage Miner Node -weight: 5 -dashboardWeight: 1 -dashboardState: wip -dashboardAudit: n/a -dashboardTests: 0 ---- - -# Storage Miner Node - -```go -type StorageMinerNode interface { - FilecoinNode - - systems.Blockchain - systems.Mining - markets.StorageMarketProvider - markets.MarketOrderBook - markets.DataTransfers -} -``` diff --git a/content/systems/filecoin_nodes/node_types/verifier_node.md b/content/systems/filecoin_nodes/node_types/verifier_node.md deleted file mode 100644 index 0fed0d0d8..000000000 --- a/content/systems/filecoin_nodes/node_types/verifier_node.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Chain Verifier Node -weight: 3 -dashboardWeight: 1 -dashboardState: wip -dashboardAudit: n/a -dashboardTests: 0 ---- - -# Chain Verifier Node - -```go -type ChainVerifierNode interface { - FilecoinNode - - systems.Blockchain -} -``` From ba12eff47d111df64e81cf1db2ee10314ea73290 Mon Sep 17 00:00:00 2001 From: yiannis Date: Thu, 10 Sep 2020 00:31:09 +0300 Subject: [PATCH 12/15] Small edits and corrections There were a few inconsistencies and links to outdated code which this commit fixes. --- content/systems/filecoin_nodes/_index.md | 6 ++-- .../systems/filecoin_nodes/clock/_index.md | 17 ++-------- .../systems/filecoin_nodes/network/_index.md | 24 +++++++------- .../filecoin_nodes/node_types/_index.md | 31 ++++++++++--------- .../filecoin_nodes/repository/_index.md | 16 +++------- .../repository/config/_index.md | 14 --------- .../repository/config/config.id | 9 ------ .../repository/ipldstore/_index.md | 4 ++- .../repository/key_store/_index.md | 7 ++--- 9 files changed, 44 insertions(+), 84 deletions(-) delete mode 100644 content/systems/filecoin_nodes/repository/config/_index.md delete mode 100644 content/systems/filecoin_nodes/repository/config/config.id diff --git a/content/systems/filecoin_nodes/_index.md b/content/systems/filecoin_nodes/_index.md index 2faaeaa21..b99f3d9d9 100644 --- a/content/systems/filecoin_nodes/_index.md +++ b/content/systems/filecoin_nodes/_index.md @@ -3,15 +3,15 @@ title: Filecoin Nodes bookCollapseSection: true weight: 1 dashboardWeight: 1 -dashboardState: wip +dashboardState: reliable dashboardAudit: n/a dashboardTests: 0 --- # Filecoin Nodes -This section is providing the required details in order to implement any of the different Filecoin nodes. Although node types in the Lotus implementation of Filecoin are less strictly defined than in other blockchain networks, there are different properties and features that different types of nodes should implement. +This section starts by discussing the concept of Filecoin Nodes. Although different node types in the Lotus implementation of Filecoin are less strictly defined than in other blockchain networks, there are different properties and features that different types of nodes should implement. In short, nodes are defined based on the set of _services_ they provide. -In this section we also discuss issues related to storage of system files in Filecoin nodes. Note that by storage in this section we do not refer to the storage that a node is committing for mining in the network, but rather the local storage repositories that it needs to have available for keys and IPLD data among other things. +In this section we also discuss issues related to storage of system files in Filecoin nodes. Note that by storage in this section we do not refer to the storage that a node commits for mining in the network, but rather the local storage repositories that it needs to have available for keys and IPLD data among other things. In this section we are also discussing the network interface and how nodes find and connect with each other, how they interact and propagate messages using libp2p, as well as how to set the node's clock. diff --git a/content/systems/filecoin_nodes/clock/_index.md b/content/systems/filecoin_nodes/clock/_index.md index 7d566f79e..d8bd52979 100644 --- a/content/systems/filecoin_nodes/clock/_index.md +++ b/content/systems/filecoin_nodes/clock/_index.md @@ -2,23 +2,20 @@ title: Clock weight: 4 dashboardWeight: 1 -dashboardState: wip +dashboardState: reliable dashboardAudit: missing dashboardTests: 0 --- # Clock -{{}} -{{}} - - Filecoin assumes weak clock synchrony amongst participants in the system. That is, the system relies on participants having access to a globally synchronized clock (tolerating some bounded drift). Filecoin relies on this system clock in order to secure consensus. Specifically the clock is necessary to support validation rules that prevent block producers from mining blocks with a future timstamp, and running leader elections more frequently than the protocol allows. ## Clock uses + The Filecoin system clock is used: - by syncing nodes to validate that incoming blocks were mined in the appropriate epoch given their timestamp (see [Block Validation](block#block-syntax-validation)). This is possible because the system clock maps all times to a unique epoch number totally determined by the start time in the genesis block. @@ -44,16 +41,8 @@ Computer-grade clock crystals can be expected to have drift rates on the order o - `time.cloudflare.com:1234` (more on [Cloudflare time services](https://www.cloudflare.com/time/)) - `time.google.com` (more on [Google Public NTP](https://developers.google.com/time)) - `ntp-b.nist.gov` ([NIST](https://tf.nist.gov/tf-cgi/servers.cgi) servers require registration) - - We further recommend making 3 measurements in order to drop by using the network to drop outliers + - We further recommend making three (3) measurements in order to drop outliers - clients MAY consider using cesium clocks instead for accurate synchrony within larger mining operations Mining operations have a strong incentive to prevent their clock from drifting ahead more than one epoch to keep their block submissions from being rejected. Likewise they have an incentive to prevent their clocks from drifting behind more than one epoch to avoid partitioning themselves off from the synchronized nodes in the network. -## Future work - -If either of the above metrics show significant network skew over time, future versions of Filecoin may include potential timestamp/epoch correction periods at regular intervals. - -When recoverying from exceptional chain halting outages (for example all implementations panic on a given block) the network can potentially opt for per-outage "dead zone" rules banning the authoring of blocks during the outage epochs to prevent attack vectors related to unmined epochs during chain restart. - -Future versions of the Filecoin protocol may use Verifiable Delay Functions (VDFs) to strongly enforce block time and fulfill this leader election requirement; we choose to explicitly assume clock synchrony until hardware VDF security has been proven more extensively. - diff --git a/content/systems/filecoin_nodes/network/_index.md b/content/systems/filecoin_nodes/network/_index.md index 880bd110d..c90de7370 100644 --- a/content/systems/filecoin_nodes/network/_index.md +++ b/content/systems/filecoin_nodes/network/_index.md @@ -2,24 +2,24 @@ title: Network Interface weight: 3 dashboardWeight: 1 -dashboardState: wip -dashboardAudit: wip +dashboardState: stable +dashboardAudit: n/a dashboardTests: 0 --- -# Interface - - +# Network Interface Filecoin nodes use several protocols of the libp2p networking stack for peer discovery, peer routing and block and message propagation. Libp2p is a modular networking stack for peer-to-peer networks. It includes several protocols and mechanisms to enable efficient, secure and resilient peer-to-peer communication. Libp2p nodes open connections with one another and mount different protocols or streams over the same connection. In the initial handshake, nodes exchange the protocols that each of them supports and all Filecoin related protocols will be mounted under `/fil/...` protocol identifiers. The complete specification of libp2p can be found at [https://github.com/libp2p/specs](https://github.com/libp2p/specs). Here is the list of libp2p protocols used by Filecoin. -- Graphsync: Graphsync is a protocol to synchronize graphs across peers. It is used to reference, address, request and transfer blockchain and user data between Filecoin nodes. The [draft specification of GraphSync](https://github.com/ipld/specs/blob/master/block-layer/graphsync/graphsync.md) provides more details on the concepts, the interfaces and the network messages used by GraphSync. There are no Filecoin-specific modifications to the protocol id. -- Gossipsub: Block headers and Transaction messages are propagating through the Filecoin network using a gossip-based pubsub protocol acronymed _GossipSub_. As is traditionally the case with pubsub protocols, nodes subscribe to topics and receive messages published on those topics. When nodes receive messages from a topic they are subscribed to, they run a validation process and i) pass the message to the application, ii) forward the message further to nodes they know off being subscribed to the same topic. Furthermore, v1.1 version of GossipSub, which is the one used in Filecoin is enhanced with security mechanisms that make the protocol resilient against security attacks. The [GossipSub Specification](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) provides all the protocol details pertaining to its design and implementation, as well as specific settings for the protocols parameters. There have been no filecoin specific modifications to the protocol id. However the topic identifiers MUST be of the form `fil/blocks/` and `fil/msgs/` -- Kademlia DHT: The Kademlia DHT is a distributed hash table with a logarithmic bound on the maximum number of lookups for a particular node. In the Filecoin network, the Kademlia DHT is used primarily for peer discovery and peer routing. In particular, when a node wants to store data in the Filecoin network, they get a list of miners and their node information. This node information includes (among other things) the PeerID of the miner. In order to connect to the miner and exchange data, the node that wants to store data in the network has to find the Multiaddress of the miner, which they do by queering the DHT. The [libp2p Kad DHT Specification](https://github.com/libp2p/go-libp2p-kad-dht) provides implementation details of the DHT structure. For the Filecoin network, the protocol id must be of the form `fil//kad/1.0.0`. -- Bootstrap List: This is a list of nodes that a new node attempts to connect to upon joining the network. The list of bootstrap nodes and their addresses are defined by the users. -- Peer Exchange: This protocol is the realisation of the peer discovery process discussed above in the Kademlia DHT point. It enables peers to find information and addresses of other peers in the network by interfacing with the DHT and create and issue queries for the peers they want to reach out to. +- **Graphsync:** Graphsync is a protocol to synchronize graphs across peers. It is used to reference, address, request and transfer blockchain and user data between Filecoin nodes. The [draft specification of GraphSync](https://github.com/ipld/specs/blob/master/block-layer/graphsync/graphsync.md) provides more details on the concepts, the interfaces and the network messages used by GraphSync. There are no Filecoin-specific modifications to the protocol id. + +- **Gossipsub:** Block headers and Transaction messages are propagating through the Filecoin network using a gossip-based pubsub protocol acronymed _GossipSub_. As is traditionally the case with pubsub protocols, nodes subscribe to topics and receive messages published on those topics. When nodes receive messages from a topic they are subscribed to, they run a validation process and i) pass the message to the application, ii) forward the message further to nodes they know off being subscribed to the same topic. Furthermore, v1.1 version of GossipSub, which is the one used in Filecoin is enhanced with security mechanisms that make the protocol resilient against security attacks. The [GossipSub Specification](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) provides all the protocol details pertaining to its design and implementation, as well as specific settings for the protocols parameters. There have been no filecoin specific modifications to the protocol id. However the topic identifiers MUST be of the form `fil/blocks/` and `fil/msgs/` + +- **Kademlia DHT:** The Kademlia DHT is a distributed hash table with a logarithmic bound on the maximum number of lookups for a particular node. In the Filecoin network, the Kademlia DHT is used primarily for peer discovery and peer routing. In particular, when a node wants to store data in the Filecoin network, they get a list of miners and their node information. This node information includes (among other things) the PeerID of the miner. In order to connect to the miner and exchange data, the node that wants to store data in the network has to find the Multiaddress of the miner, which they do by queering the DHT. The [libp2p Kad DHT Specification](https://github.com/libp2p/go-libp2p-kad-dht) provides implementation details of the DHT structure. For the Filecoin network, the protocol id must be of the form `fil//kad/1.0.0`. + +- **Bootstrap List:** This is a list of nodes that a new node attempts to connect to upon joining the network. The list of bootstrap nodes and their addresses are defined by the users (i.e., applications). + +- **Peer Exchange:** This protocol is the realisation of the peer discovery process discussed above at Kademlia DHT. It enables peers to find information and addresses of other peers in the network by interfacing with the DHT and create and issue queries for the peers they want to connect to. diff --git a/content/systems/filecoin_nodes/node_types/_index.md b/content/systems/filecoin_nodes/node_types/_index.md index cc5aff027..f498d342c 100644 --- a/content/systems/filecoin_nodes/node_types/_index.md +++ b/content/systems/filecoin_nodes/node_types/_index.md @@ -8,6 +8,8 @@ dashboardAudit: n/a dashboardTests: 0 --- +# Node Types + Nodes in the Filecoin network are primarily identified in terms of the services they provide. The type of node, therefore, depends on which services a node provides. A basic set of services in the Filecoin network include: - chain verification - storage market client @@ -20,18 +22,18 @@ Any node participating in the Filecoin network should provide the _chain verific Nodes can be realized with a repository (directory) in the host in a one-to-one relationship - that is, one repo belongs to a single node. That said, one host can implement multiple Filecoin nodes by having the corresponding repositories. -A Filecoin implementation should support the following subsystems, or types of nodes: +A Filecoin implementation can support the following subsystems, or types of nodes: - **Chain Verifier Node:** this is the minimum functionality that a node needs to have in order to participate in the Filecoin network. This type of node cannot play an active role in the network, unless it implements **Client Node** functionality, described below. A Chain Verifier Node must synchronise the chain (ChainSync) when it first joins the network to reach current consensus. From then on, the node must constantly be fetching any addition to the chain (i.e., receive the latest blocks) and validate them to reach consensus state. - **Client Node:** this type of node builds on top of the **Chain Verifier Node** and must be implemented by any application that is building on the Filecoin network. This can be thought of as the main infrastructure node (at least as far as interaction with the blockchain is concerned) of applications such as exchanges or decentralised storage applications building on Filecoin. The node should implement the _storage market and retrieval market client_ services. The client node should interact with the Storage and Retrieval Markets, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. - **Retrieval Miner Node:** this node type is extending the **Chain Verifier Node** to add _retrieval miner_ functionality, that is, participate in the retrieval market. As such, this node type needs to implement the _retrieval market provider_ service, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. - **Storage Miner Node:** this type of node must implement all of the required functionality for validating, creating and adding blocks to extend the blockchain. It should implement the chain verification, storage mining and storage market provider services, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. -# Node Interface +## Node Interface -{{}} +The Lotus implementation of the Node Interface can be found [here](https://github.com/filecoin-project/lotus/blob/master/node/repo/interface.go). -# Chain Verifier Node +## Chain Verifier Node ```go type ChainVerifierNode interface { @@ -40,9 +42,9 @@ type ChainVerifierNode interface { systems.Blockchain } ``` -{{}} +The Lotus implementation of the Chain Verifier Node can be found [here](https://github.com/filecoin-project/lotus/blob/master/node/impl/full.go). -# Client Node +## Client Node ```go type ClientNode struct { @@ -51,13 +53,12 @@ type ClientNode struct { systems.Blockchain markets.StorageMarketClient markets.RetrievalMarketClient - markets.MarketOrderBook markets.DataTransfers } ``` -{{}} +The Lotus implementation of the Client Node can be found [here](https://github.com/filecoin-project/lotus/blob/master/node/impl/client/client.go). -# Storage Miner Node +## Storage Miner Node ```go type StorageMinerNode interface { @@ -66,13 +67,12 @@ type StorageMinerNode interface { systems.Blockchain systems.Mining markets.StorageMarketProvider - markets.MarketOrderBook markets.DataTransfers } ``` -{{}} +The Lotus implementation of the Storage Miner Node can be found [here](https://github.com/filecoin-project/lotus/blob/master/node/impl/storminer.go). -# Retrieval Miner Node +## Retrieval Miner Node ```go type RetrievalMinerNode interface { @@ -80,19 +80,20 @@ type RetrievalMinerNode interface { blockchain.Blockchain markets.RetrievalMarketProvider - markets.MarketOrderBook markets.DataTransfers } ``` -# Relayer Node +## Relayer Node ```go type RelayerNode interface { FilecoinNode blockchain.MessagePool - markets.MarketOrderBook } ``` +## Node Configuration + +The Lotus implementation of Filecoin Node configuration values can be found [here](https://github.com/filecoin-project/lotus/blob/master/node/config/def.go). \ No newline at end of file diff --git a/content/systems/filecoin_nodes/repository/_index.md b/content/systems/filecoin_nodes/repository/_index.md index 5fa5f3a1c..d1499030c 100644 --- a/content/systems/filecoin_nodes/repository/_index.md +++ b/content/systems/filecoin_nodes/repository/_index.md @@ -3,23 +3,17 @@ title: Repository weight: 2 bookCollapseSection: true dashboardWeight: 1 -dashboardState: wip +dashboardState: stable dashboardAudit: n/a dashboardTests: 0 --- -# Repository - Local Storage for Chain Data and Systems +# Node Repository -The Filecoin node repository is simply an abstraction of the data which any functional Filecoin node needs to store locally in order to run correctly. +The Filecoin node repository is simply local storage for system and chain data. It is an abstraction of the data which any functional Filecoin node needs to store locally in order to run correctly. -The repository is accessible to the node's systems and subsystems and acts as local storage, which, for example, is compartmentalized from the node's `FileStore`. +The repository is accessible to the node's systems and subsystems and can be compartmentalized from the node's `FileStore`. The repository stores the node's keys, the IPLD data structures of stateful objects as well as the node configuration settings. - \ No newline at end of file +The Lotus implementation of the FileStore Repository can be found [here](https://github.com/filecoin-project/lotus/blob/master/node/repo/fsrepo.go). \ No newline at end of file diff --git a/content/systems/filecoin_nodes/repository/config/_index.md b/content/systems/filecoin_nodes/repository/config/_index.md deleted file mode 100644 index 5f2f27cf1..000000000 --- a/content/systems/filecoin_nodes/repository/config/_index.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Config -weight: 1 -dashboardWeight: 1 -dashboardState: wip -dashboardAudit: n/a -dashboardTests: 0 ---- - -# Config - Local Storage for Configuration Values - -Filecoin Node configuration - -{{}} \ No newline at end of file diff --git a/content/systems/filecoin_nodes/repository/config/config.id b/content/systems/filecoin_nodes/repository/config/config.id deleted file mode 100644 index 7c2273866..000000000 --- a/content/systems/filecoin_nodes/repository/config/config.id +++ /dev/null @@ -1,9 +0,0 @@ -type ConfigKey string -type ConfigVal Bytes - -type Config struct { - Get(k ConfigKey) union {c ConfigVal, e error} - Put(k ConfigKey, v ConfigVal) error - - Subconfig(k ConfigKey) Config -} diff --git a/content/systems/filecoin_nodes/repository/ipldstore/_index.md b/content/systems/filecoin_nodes/repository/ipldstore/_index.md index 39773da01..0c3e1dd8b 100644 --- a/content/systems/filecoin_nodes/repository/ipldstore/_index.md +++ b/content/systems/filecoin_nodes/repository/ipldstore/_index.md @@ -7,10 +7,12 @@ dashboardAudit: wip dashboardTests: 0 --- -# IPLD Store - Local Storage for hash-linked data +# IPLD Store InterPlanetary Linked Data (IPLD) is a set of libraries which allow for the interoperability of content-addressed data structures across different distributed systems and protocols. It provides a fundamental 'common language' to primitive cryptographic hashing, enabling data structures to be verifiably referenced and retrieved between two independent protocols. For example, a user can reference an IPFS directory in an Ethereum transaction or smart contract. +The IPLD Store of a Filecoin Node is local storage for hash-linked data. + IPLD is fundamentally comprised of three layers: - the Block Layer, which focuses on block formats and addressing, how blocks can advertise or self-describe their codec diff --git a/content/systems/filecoin_nodes/repository/key_store/_index.md b/content/systems/filecoin_nodes/repository/key_store/_index.md index 59b792a26..dfd3c158b 100644 --- a/content/systems/filecoin_nodes/repository/key_store/_index.md +++ b/content/systems/filecoin_nodes/repository/key_store/_index.md @@ -2,7 +2,7 @@ title: Key Store weight: 2 dashboardWeight: 1 -dashboardState: wip +dashboardState: reliable dashboardAudit: missing dashboardTests: 0 --- @@ -11,11 +11,8 @@ dashboardTests: 0 The `Key Store` is a fundamental abstraction in any full Filecoin node used to store the keypairs associated with a given miner's address (see actual definition further down) and distinct workers (should the miner choose to run multiple workers). -Node security depends in large part on keeping these keys secure. To that end we strongly recommend: 1) keeping keys separate from all subsystem, ii) using a separate key store to sign requests as required by other subsystems, and iii) keeping those keys that are not used as part of mining in cold storage. +Node security depends in large part on keeping these keys secure. To that end we strongly recommend: 1) keeping keys separate from all subsystems, 2) using a separate key store to sign requests as required by other subsystems, and 3) keeping those keys that are not used as part of mining in cold storage. - Filecoin storage miners rely on three main components: From 783873fdcc0bb25820d8f1d93ba68dd8d1328908 Mon Sep 17 00:00:00 2001 From: yiannis Date: Thu, 10 Sep 2020 11:36:17 +0300 Subject: [PATCH 13/15] deleting old .id and .go files --- .../filecoin_nodes/clock/clock_subsystem.go | 24 ---------------- .../filecoin_nodes/clock/clock_subsystem.id | 19 ------------- .../systems/filecoin_nodes/network/hello.id | 17 ----------- .../systems/filecoin_nodes/network/network.id | 3 -- .../filecoin_nodes/node_base/filecoin_node.id | 15 ---------- .../node_base/network_params.go | 28 ------------------- .../node_types/storage_miner_node.id | 14 ---------- .../repository/key_store/key_store.id | 8 ------ .../repository/repository_subsystem.id | 10 ------- 9 files changed, 138 deletions(-) delete mode 100644 content/systems/filecoin_nodes/clock/clock_subsystem.go delete mode 100644 content/systems/filecoin_nodes/clock/clock_subsystem.id delete mode 100644 content/systems/filecoin_nodes/network/hello.id delete mode 100644 content/systems/filecoin_nodes/network/network.id delete mode 100644 content/systems/filecoin_nodes/node_base/filecoin_node.id delete mode 100644 content/systems/filecoin_nodes/node_base/network_params.go delete mode 100644 content/systems/filecoin_nodes/node_types/storage_miner_node.id delete mode 100644 content/systems/filecoin_nodes/repository/key_store/key_store.id delete mode 100644 content/systems/filecoin_nodes/repository/repository_subsystem.id diff --git a/content/systems/filecoin_nodes/clock/clock_subsystem.go b/content/systems/filecoin_nodes/clock/clock_subsystem.go deleted file mode 100644 index 0820db7fe..000000000 --- a/content/systems/filecoin_nodes/clock/clock_subsystem.go +++ /dev/null @@ -1,24 +0,0 @@ -package clock - -import "time" - -// UTCSyncPeriod notes how often to sync the UTC clock with an authoritative -// source, such as NTP, or a very precise hardware clock. -var UTCSyncPeriod = time.Hour - -// EpochDuration is a constant that represents the duration in seconds -// of a blockchain epoch. -var EpochDuration = UnixTime(15) - -func (_ *UTCClock_I) NowUTCUnix() UnixTime { - return UnixTime(time.Now().Unix()) -} - -// EpochAtTime returns the ChainEpoch corresponding to time `t`. -// It first subtracts GenesisTime, then divides by EpochDuration -// and returns the resulting number of epochs. -func (c *ChainEpochClock_I) EpochAtTime(t UnixTime) ChainEpoch { - difference := t - c.GenesisTime() - epochs := difference / EpochDuration - return ChainEpoch(epochs) -} diff --git a/content/systems/filecoin_nodes/clock/clock_subsystem.id b/content/systems/filecoin_nodes/clock/clock_subsystem.id deleted file mode 100644 index 4c95d9071..000000000 --- a/content/systems/filecoin_nodes/clock/clock_subsystem.id +++ /dev/null @@ -1,19 +0,0 @@ -type UnixTime int64 // unix timestamp - -// UTCClock is a normal, system clock reporting UTC time. -// It should be kept in sync, with drift less than 1 second. -type UTCClock struct { - NowUTCUnix() UnixTime -} - -// ChainEpoch represents a round of a blockchain protocol. -type ChainEpoch int64 - -// ChainEpochClock is a clock that represents epochs of the protocol. -type ChainEpochClock struct { - // GenesisTime is the time of the first block. EpochClock counts - // up from there. - GenesisTime UnixTime - - EpochAtTime(t UnixTime) ChainEpoch -} diff --git a/content/systems/filecoin_nodes/network/hello.id b/content/systems/filecoin_nodes/network/hello.id deleted file mode 100644 index 16676095b..000000000 --- a/content/systems/filecoin_nodes/network/hello.id +++ /dev/null @@ -1,17 +0,0 @@ -import cid "github.com/ipfs/go-cid" - -// HelloMessage shares information about a peer's chain head -type HelloMessage struct { - HeaviestTipSet [cid.Cid] - HeaviestTipSetWeight BigInt - HeaviestTipSetHeight Int - GenesisHash cid.Cid -} - -// LatencyMessage shares information about a peer's network latency -type LatencyMessage struct { - // Measured in unix nanoseconds - TArrival Int - // Measured in unix nanoseconds - TSent Int -} diff --git a/content/systems/filecoin_nodes/network/network.id b/content/systems/filecoin_nodes/network/network.id deleted file mode 100644 index 0a0d54cee..000000000 --- a/content/systems/filecoin_nodes/network/network.id +++ /dev/null @@ -1,3 +0,0 @@ -import libp2p "github.com/filecoin-project/specs/libraries/libp2p" - -type Node libp2p.Node diff --git a/content/systems/filecoin_nodes/node_base/filecoin_node.id b/content/systems/filecoin_nodes/node_base/filecoin_node.id deleted file mode 100644 index 421632246..000000000 --- a/content/systems/filecoin_nodes/node_base/filecoin_node.id +++ /dev/null @@ -1,15 +0,0 @@ -import repo "github.com/filecoin-project/specs/systems/filecoin_nodes/repository" -import filestore "github.com/filecoin-project/specs/systems/filecoin_files/file" -import clock "github.com/filecoin-project/specs/systems/filecoin_nodes/clock" -import libp2p "github.com/filecoin-project/specs/libraries/libp2p" -import message_pool "github.com/filecoin-project/specs/systems/filecoin_blockchain/message_pool" - -type FilecoinNode struct { - Node libp2p.Node - - Repository repo.Repository - FileStore filestore.FileStore - Clock clock.UTCClock - - MessagePool message_pool.MessagePoolSubsystem -} diff --git a/content/systems/filecoin_nodes/node_base/network_params.go b/content/systems/filecoin_nodes/node_base/network_params.go deleted file mode 100644 index d08392e69..000000000 --- a/content/systems/filecoin_nodes/node_base/network_params.go +++ /dev/null @@ -1,28 +0,0 @@ -package node_base - -import ( - addr "github.com/filecoin-project/go-address" -) - -// Parameters for on-chain calculations are in actors/builtin/network_params.go - -///////////////////////////////////////////////////////////// -// Global -///////////////////////////////////////////////////////////// - -const NETWORK = addr.Testnet - -// how many sectors should be challenged in surprise post (if miner has fewer, will get dup challenges) -const SURPRISE_CHALLENGE_COUNT = 200 // placeholder - -const EPOST_SAMPLE_RATE_NUM = 1 // placeholder -const EPOST_SAMPLE_RATE_DENOM = 25 // placeholder -const SPOST_SAMPLE_RATE_NUM = 1 // placeholder -const SPOST_SAMPLE_RATE_DENOM = 50 // placeholder - -///////////////////////////////////////////////////////////// -// Consensus -///////////////////////////////////////////////////////////// - -const FINALITY = 500 // placeholder -const SPC_LOOKBACK_TICKET = 1 // we chain blocks together one after the other diff --git a/content/systems/filecoin_nodes/node_types/storage_miner_node.id b/content/systems/filecoin_nodes/node_types/storage_miner_node.id deleted file mode 100644 index 300ed00c7..000000000 --- a/content/systems/filecoin_nodes/node_types/storage_miner_node.id +++ /dev/null @@ -1,14 +0,0 @@ -import node_base "github.com/filecoin-project/specs/systems/filecoin_nodes/node_base" -import storage_mining "github.com/filecoin-project/specs/systems/filecoin_mining/storage_mining" - -type StorageMinerNode struct { - FilecoinNode node_base.FilecoinNode - - SMS storage_mining.StorageMiningSubsystem - - // TODO: finish - // systems.Blockchain - // markets.StorageMarketProvider - // markets.MarketOrderBook - // markets.DataTransfers -} diff --git a/content/systems/filecoin_nodes/repository/key_store/key_store.id b/content/systems/filecoin_nodes/repository/key_store/key_store.id deleted file mode 100644 index a6b26795b..000000000 --- a/content/systems/filecoin_nodes/repository/key_store/key_store.id +++ /dev/null @@ -1,8 +0,0 @@ -import filcrypto "github.com/filecoin-project/specs/algorithms/crypto" -import address "github.com/filecoin-project/go-address" - -type KeyStore struct { - MinerAddress address.Address - OwnerKey filcrypto.VRFKeyPair - WorkerKey filcrypto.VRFKeyPair -} diff --git a/content/systems/filecoin_nodes/repository/repository_subsystem.id b/content/systems/filecoin_nodes/repository/repository_subsystem.id deleted file mode 100644 index 87a5a5750..000000000 --- a/content/systems/filecoin_nodes/repository/repository_subsystem.id +++ /dev/null @@ -1,10 +0,0 @@ -import ipld "github.com/filecoin-project/specs/libraries/ipld" -import key_store "github.com/filecoin-project/specs/systems/filecoin_nodes/repository/key_store" -import config "github.com/filecoin-project/specs/systems/filecoin_nodes/repository/config" - -type Repository struct { - Config config.Config - KeyStore key_store.KeyStore - ChainStore ipld.GraphStore - StateStore ipld.GraphStore -} From 8c0bbb8bc306e82bfae82c20d2f7be04a1857834 Mon Sep 17 00:00:00 2001 From: yiannis Date: Thu, 10 Sep 2020 11:46:20 +0300 Subject: [PATCH 14/15] deleting reference to "market order book" after Hannah's comment --- content/systems/filecoin_nodes/node_types/_index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/systems/filecoin_nodes/node_types/_index.md b/content/systems/filecoin_nodes/node_types/_index.md index f498d342c..70563b04a 100644 --- a/content/systems/filecoin_nodes/node_types/_index.md +++ b/content/systems/filecoin_nodes/node_types/_index.md @@ -25,9 +25,9 @@ Nodes can be realized with a repository (directory) in the host in a one-to-one A Filecoin implementation can support the following subsystems, or types of nodes: - **Chain Verifier Node:** this is the minimum functionality that a node needs to have in order to participate in the Filecoin network. This type of node cannot play an active role in the network, unless it implements **Client Node** functionality, described below. A Chain Verifier Node must synchronise the chain (ChainSync) when it first joins the network to reach current consensus. From then on, the node must constantly be fetching any addition to the chain (i.e., receive the latest blocks) and validate them to reach consensus state. -- **Client Node:** this type of node builds on top of the **Chain Verifier Node** and must be implemented by any application that is building on the Filecoin network. This can be thought of as the main infrastructure node (at least as far as interaction with the blockchain is concerned) of applications such as exchanges or decentralised storage applications building on Filecoin. The node should implement the _storage market and retrieval market client_ services. The client node should interact with the Storage and Retrieval Markets, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. -- **Retrieval Miner Node:** this node type is extending the **Chain Verifier Node** to add _retrieval miner_ functionality, that is, participate in the retrieval market. As such, this node type needs to implement the _retrieval market provider_ service, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. -- **Storage Miner Node:** this type of node must implement all of the required functionality for validating, creating and adding blocks to extend the blockchain. It should implement the chain verification, storage mining and storage market provider services, keep the Market Order Book and be able to do Data Transfers through the Data Transfer Module. +- **Client Node:** this type of node builds on top of the **Chain Verifier Node** and must be implemented by any application that is building on the Filecoin network. This can be thought of as the main infrastructure node (at least as far as interaction with the blockchain is concerned) of applications such as exchanges or decentralised storage applications building on Filecoin. The node should implement the _storage market and retrieval market client_ services. The client node should interact with the Storage and Retrieval Markets and be able to do Data Transfers through the Data Transfer Module. +- **Retrieval Miner Node:** this node type is extending the **Chain Verifier Node** to add _retrieval miner_ functionality, that is, participate in the retrieval market. As such, this node type needs to implement the _retrieval market provider_ service and be able to do Data Transfers through the Data Transfer Module. +- **Storage Miner Node:** this type of node must implement all of the required functionality for validating, creating and adding blocks to extend the blockchain. It should implement the chain verification, storage mining and storage market provider services and be able to do Data Transfers through the Data Transfer Module. ## Node Interface From ab8d540c119a552058a348bd8bb8e964737a8ceb Mon Sep 17 00:00:00 2001 From: yiannis Date: Thu, 10 Sep 2020 19:21:39 +0300 Subject: [PATCH 15/15] fixes broken links --- content/appendix/network_params.md | 3 --- content/intro/systems/impl_systems.md | 6 +----- 2 files changed, 1 insertion(+), 8 deletions(-) diff --git a/content/appendix/network_params.md b/content/appendix/network_params.md index 862a65542..ee18c9ae6 100644 --- a/content/appendix/network_params.md +++ b/content/appendix/network_params.md @@ -16,9 +16,6 @@ Most are generated/finalized using the [orient framework](https://github.com/fil ⚠️ **WARNING:** Filecoin is not yet launched, and we are finishing protocol spec and implementations. Parameters are set here as placeholders and highly likely to change to fit product and security requirements. {{}} -## Code parameters - -{{}} ## Orient parameters diff --git a/content/intro/systems/impl_systems.md b/content/intro/systems/impl_systems.md index 7b272d532..feec70378 100644 --- a/content/intro/systems/impl_systems.md +++ b/content/intro/systems/impl_systems.md @@ -34,11 +34,7 @@ All Systems, as defined in this document, require the following: Systems expect to be initialized with a Clock from which to tell network time. Some systems (like Blockchain) require very little clock drift, and require _secure_ time. -For this purpose, we use the `FilecoinNode` data structure, which is passed into all systems at initialization: - -{{}} - -{{}} +For this purpose, we use the `FilecoinNode` data structure, which is passed into all systems at initialization. ## System Limitations