fix(content): fix incorrect statements and clear "messages" "transations" (#1240)

- Remove some incorrect statements.
- Fix miner key text.
- Avoid calling "messages" "transactions". Some Filecoin messages are transactions, but not all.

Co-authored-by: Hugo Dias <[email protected]>

Author: Stebalien

content/algorithms/crypto/signatures.md

@@ -21,7 +21,7 @@ action like a storage deal.
 Filecoin uses signatures to verify the authenticity of the following objects (non
 exhaustive list):
 
-- Messages: Users authenticate their transactions to the blockchain.
+- Messages: Users authenticate their messages to the blockchain.
 - Tickets: Miner authenticates its ticket (see [Storage Miner](filecoin_mining)).
 - Blocks: Block leader signs over all data in the block.
 
@@ -37,7 +37,7 @@ Read more about this in [Randomness](randomness).
 Filecoin currently uses two types of signatures:
 
 - ECDSA signatures over the Secp256k1 elliptic curve to authenticate user
-  transactions, mainly for compatibility with external blockchain systems.
+  messages, mainly for compatibility with external blockchain systems.
 - BLS signatures over the BLS12-381 group of curves
 
 Both signature types fulfill the `Signature` interface
@@ -48,8 +48,8 @@ and each type have additional functionality as explained below.
 ### ECDSA Signatures
 
 Filecoin uses the ECDSA signature algorithm over the secp256k1 curve to
-authenticate the blockchain transactions. The main reason is to be able to
-validate transactions from other blockchain systems that uses secp256k1 (such as
+authenticate the blockchain messages. The main reason is to be able to
+validate messages from other blockchain systems that uses secp256k1 (such as
 Bitcoin or exchanges in general). ECDSA signatures offer an additional
 useful functionality as well: to recover the public key from a given signature.
 This feature can allow space to be saved on the blockchain by extracting the public

content/algorithms/cryptoecon/_index.md

@@ -42,7 +42,7 @@ The following table summarizes initial parameter recommendations for Filecoin. M
 | Sector Termination Fee                     | Estimated number of days of block reward that a sector has earned; capped at 90 days     |
 | Minimum Client Deal Collateral             | 0                                                                                        |
 | Minimum Provider Deal Collateral           | share of 1% raw byte-normalised circulating supply                                       |
-| Network Transaction Fee                    | Dynamic fee structure based on network congestion                                        |
+| Network Gas Fee                            | Dynamic fee structure based on network congestion                                        |
 
 ## Design Principles Justification
 
@@ -52,7 +52,7 @@ The following table summarizes initial parameter recommendations for Filecoin. M
 
 **Block Reward Vesting:** In order to reduce the initial pledge requirement of a sector, the network considers all vesting block rewards as collateral. However, tracking block rewards on a per-sector level is not scalable. Instead, the protocol tracks rewards at a per-miner level and linearly vests block rewards over a fixed duration.
 
-**Minimum Sector Lifetime:** The justification for a minimum sector lifetime is as follows. Committing a sector to the Filecoin Network currently requires a moderately computationally-expensive "sealing" operation up-front, whose amortized cost is lower if the sector's lifetime is longer. In addition, a sector commitment will involve on-chain transactions, for which gas fees will be paid. The net effect of these transaction costs will be subsidized by the block reward, but only for sectors that will contribute to the network and earn rewards for a sufficiently long duration. Under current constraints, short-lived sectors would reduce the overall capacity of the network to deliver useful storage over time.
+**Minimum Sector Lifetime:** The justification for a minimum sector lifetime is as follows. Committing a sector to the Filecoin Network currently requires a moderately computationally-expensive "sealing" operation up-front, whose amortized cost is lower if the sector's lifetime is longer. In addition, a sector commitment will involve on-chain messages, for which gas fees will be paid. The net effect of these messages costs will be subsidized by the block reward, but only for sectors that will contribute to the network and earn rewards for a sufficiently long duration. Under current constraints, short-lived sectors would reduce the overall capacity of the network to deliver useful storage over time.
 
 **Sector Fault Fee:** If stored sectors are withdrawn from the network only temporarily, a substantial fraction of those sectors' value may be recovered in case the data storage is quickly restored to normal operation — this means that the network need not levy a termination fee immediately. However, even temporary interruptions can be disruptive, and also damage confidence about whether the sector is recoverable or permanently lost. In order to account for this situation, the network charges a much smaller fee per day that a sector is not being proven as promised (until enough days have passed that the network writes off that sector as terminated).
 

content/algorithms/gossip_sub.md

@@ -11,7 +11,7 @@ dashboardAuditDate: '2020-06-03'
 
 # GossipSub
 
-Transaction messages and block headers alongside the message references are propagated using the [libp2p GossipSub router](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub). **In order to guarantee interoperability between different implementations, all filecoin full nodes must implement and use this protocol.** All pubsub messages are authenticated and must be [syntactically validated](message#message-syntax-validation) before being propagated further.
+Messages and block headers alongside the message references are propagated using the [libp2p GossipSub router](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub). **In order to guarantee interoperability between different implementations, all filecoin full nodes must implement and use this protocol.** All pubsub messages are authenticated and must be [syntactically validated](message#message-syntax-validation) before being propagated further.
 
 GossipSub is a gossip-based pubsub protocol that is utilising two types of links to propagate messages: i) _mesh links_ that carry full messages in an _eager-push_ (i.e., proactive send) manner and ii) _gossip-links_ that carry message identifiers only and realise a _lazy-pull_ (i.e., reactive request) propagation model. Mesh links form a global mesh-connected structure, where, once messages are received they are forwarded in full to mesh-connected nodes, realizing an "eager-push" model. Instead, gossip-links are utilized periodically to complement the mesh structure. During gossip propagation, only message headers are sent to a selected group of nodes in order to inform them of messages that they might not have received before. In this case, nodes ask for the full message, hence, realizing a reactive request, or "lazy pull" model.
 

content/glossary/_index.md

@@ -132,7 +132,7 @@ The term _Filecoin_ is used generically to refer to the Filecoin project, protoc
 
 ## Finality
 
-[Finality](expected_consensus#finality-in-ec) is a well known concept in blockchain environments and refers to the amount of time needed until having a reasonable guarantee that a transaction cannot be reversed or cancelled. It is measured in terms of delay, normally in epochs or rounds from the point when a transaction has been included in a block published onchain.
+[Finality](expected_consensus#finality-in-ec) is a well known concept in blockchain environments and refers to the amount of time needed until having a reasonable guarantee that a message cannot be reversed or cancelled. It is measured in terms of delay, normally in epochs or rounds from the point when a message has been included in a block published on-chain.
 
 ## `fr32`
 
@@ -310,7 +310,7 @@ The [_Storage Market Actor_](sysactors) is responsible for managing storage and
 
 ## Storage Miner Actor
 
-The [_Storage Miner Actor_](sysactors) commits storage to the network, stores data on behalf of the network and is rewarded in [FIL](glossary#fil) for the storage service. The storage miner actor is responsible for collecting proofs and reaching consensus on the latest state of the storage network. When they create a block, storage miners are rewarded with newly minted FIL, as well as the transaction fees they can levy on other participants seeking to include messages in the block.
+The [_Storage Miner Actor_](sysactors) commits storage to the network, stores data on behalf of the network and is rewarded in [FIL](glossary#fil) for the storage service. The storage miner actor is responsible for collecting proofs and reaching consensus on the latest state of the storage network. When they create a block, storage miners are rewarded with newly minted FIL, as well as the message fees they can levy on other participants seeking to include messages in the block.
 
 ## Storage Power Actor
 

content/systems/_index.md

@@ -16,7 +16,7 @@ In this section we are detailing all the system components one by one in increas
 - Filecoin Nodes: the different types of nodes that participate in the Filecoin Network, as well as important parts and processes that these nodes run, such as the key store and IPLD store, as well as the network interface to libp2p.
 - Files & Data: the data units of Filecoin, such as the Sectors and the Pieces.
 - Virtual Machine: the subcomponents of the Filecoin VM, such as the actors, i.e., the smart contracts that run on the Filecoin Blockchain, and the State Tree.
-- Blockchain: the main building blocks of the Filecoin blockchain, such as the structure of the Transaction and Block messages, the message pool, as well as how nodes synchronise the blockchain when they first join the network.
+- Blockchain: the main building blocks of the Filecoin blockchain, such as the structure of messages and blocks, the message pool, as well as how nodes synchronise the blockchain when they first join the network.
 - Token: the components needed for a wallet.
 - Storage Mining: the details of storage mining, storage power consensus, and how storage miners prove storage (without going into details of proofs, which are discussed later).
 - Markets: the storage and retrieval markets, which are primarily processes that take place off-chain, but are very important for the smooth operation of the decentralised storage market.

content/systems/filecoin_blockchain/chainsync/_index.md

@@ -9,10 +9,7 @@ dashboardTests: 0
 
 # ChainSync
 
-Blockchain synchronization ("sync") is a key part of a blockchain system.
-It handles retrieval and propagation of blocks and transactions (messages), and
-thus is in charge of distributed state replication.
-As such, this process is security critical -- problems with state replication can have severe consequences to the operation of a blockchain.
+Blockchain synchronization ("sync") is a key part of a blockchain system. It handles retrieval and propagation of blocks and messages, and thus is in charge of distributed state replication. As such, this process is security critical -- problems with state replication can have severe consequences to the operation of a blockchain.
 
 When a node first joins the network it discovers peers (through the peer discovery discussed above) and joins the `/fil/blocks` and `/fil/msgs` GossipSub topics. It listens to new blocks being propagated by other nodes. It picks one block as the `BestTargetHead` and starts syncing the blockchain up to this height from the `TrustedCheckpoint`, which by default is the `GenesisBlock` or `GenesisCheckpoint`. In order to pick the `BestTargetHead` the peer is comparing a combination of height and weight - the higher these values the higher the chances of the block being on the main chain. If there are two blocks on the same height, the peer should choose the one with the higher weight. Once the peer chooses the `BestTargetHead` it uses the BlockSync protocol to fetch the blocks and get to the current height. From that point on it is in `CHAIN_FOLLOW` mode, where it uses GossipSub to receive new blocks, or Bitswap if it hears about a block that it has not received through GossipSub.
 

content/systems/filecoin_blockchain/message_pool/_index.md

@@ -10,10 +10,10 @@ dashboardTests: 0
 
 # Message Pool
 
-The Message Pool, or `mpool` or `mempool` is a Pool of _Transaction_ Messages in the Filecoin protocol. It acts as the interface between Filecoin nodes and the peer-to-peer network of other nodes used for off-chain message propagation. The message pool is used by nodes to maintain a set of messages they want to transmit to the Filecoin VM and add to the chain (i.e., add for "on-chain" execution).
+The Message Pool, or `mpool` or `mempool` is a pool of messages in the Filecoin protocol. It acts as the interface between Filecoin nodes and the peer-to-peer network of other nodes used for off-chain message propagation. The message pool is used by nodes to maintain a set of messages they want to transmit to the Filecoin VM and add to the chain (i.e., add for "on-chain" execution).
 
-In order for a transaction message to end up in the blockchain it first has to be in the message pool. In reality, at least in the Lotus implementation of Filecoin, there is no central pool of messages stored somewhere. Instead, the message pool is an abstraction and is realised as a list of messages kept by every node in the network. Therefore, when a node puts a new message in the message pool, this message is propagated to the rest of the network using libp2p's pubsub protocol, GossipSub. Nodes need to subscribe to the corresponding pubsub topic in order to receive messages.
+In order for a message to end up in the blockchain it first has to be in the message pool. In reality, at least in the Lotus implementation of Filecoin, there is no central pool of messages stored somewhere. Instead, the message pool is an abstraction and is realised as a list of messages kept by every node in the network. Therefore, when a node puts a new message in the message pool, this message is propagated to the rest of the network using libp2p's pubsub protocol, GossipSub. Nodes need to subscribe to the corresponding pubsub topic in order to receive messages.
 
 Message propagation using GossipSub does not happen immediately and therefore, there is some lag before message pools at different nodes can be in sync. In practice, and given continuous streams of messages being added to the message pool and the delay to propagate messages, the message pool is never synchronised across all nodes in the network. This is not a deficiency of the system, as the message pool does not _need_ to be synchronized across the network.
 
-The message pool should have a maximum size defined to avoid DoS attacks, where nodes are spammed and run out of memory. The recommended size for the message pool is 5000 Transaction messages.
+The message pool should have a maximum size defined to avoid DoS attacks, where nodes are spammed and run out of memory. The recommended size for the message pool is 5000 messages.

content/systems/filecoin_blockchain/message_pool/message_storage.md

@@ -9,4 +9,4 @@ dashboardTests: 0
 
 # Message Storage
 
-As mentioned earlier, there is no central pool where messages are included. Instead, every node must have allocated memory for incoming transaction messages.
+As mentioned earlier, there is no central pool where messages are included. Instead, every node must have allocated memory for incoming messages.

content/systems/filecoin_blockchain/message_pool/message_syncer.md

@@ -9,20 +9,20 @@ dashboardTests: 0
 
 # Message Propagation
 
-The message pool has to interface with the libp2p pubsub [GossipSub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) protocol. This is because transaction messages are propagated over [GossipSub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) the corresponding `/fil/msgs/` _topic_. Every [Message](message) is announced in the corresponding `/fil/msgs/` topic by any node participating in the network.
+The message pool has to interface with the libp2p pubsub [GossipSub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) protocol. This is because messages are propagated over [GossipSub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) the corresponding `/fil/msgs/` _topic_. Every [Message](message) is announced in the corresponding `/fil/msgs/` topic by any node participating in the network.
 
-There are two main pubsub topics related to transactions and blocks: i) the `/fil/msgs/` topic that carries transactions and, ii) the `/fil/blocks/` topic that carries blocks. The `/fil/msgs/` topic is linked to the `mpool`. The process is as follows:
+There are two main pubsub topics related to messages and blocks: i) the `/fil/msgs/` topic that carries messages and, ii) the `/fil/blocks/` topic that carries blocks. The `/fil/msgs/` topic is linked to the `mpool`. The process is as follows:
 
-1. When a client wants to carry out a transaction in the Filecoin network, they publish a transaction message in the `/fil/msgs/` topic.
+1. When a client wants to send a message in the Filecoin network, they publish the message to the `/fil/msgs/` topic.
 2. The message propagates to all other nodes in the network using GossipSub and eventually ends up in the `mpool` of all miners.
-3. Depending on cryptoeconomic rules, some miner will eventually pick the transaction message from the `mpool` (together with other transaction messages) and include it in a block.
-4. The miner publishes the newly-mined block in the `/fil/blocks/` pubsub topic and the block message propagates to all nodes in the network (including the nodes that published the transactions included in this block).
+3. Depending on cryptoeconomic rules, some miner will eventually pick the message from the `mpool` (together with other messages) and include it in a block.
+4. The miner publishes the newly-mined block in the `/fil/blocks/` pubsub topic and the block propagates to all nodes in the network (including the nodes that published the messages included in this block).
 
-Nodes must check that incoming transaction messages are valid, that is, that they have a valid signature. If the message is not valid it should be dropped and must not be forwarded.
+Nodes must check that incoming messages are valid, that is, that they have a valid signature. If the message is not valid it should be dropped and must not be forwarded.
 
 The updated, hardened version of the GossipSub protocol includes a number of attack mitigation strategies. For instance, when a node receives an invalid message it assigns a negative _score_ to the sender peer. Peer scores are not shared with other nodes, but are rather kept locally by every peer for all other peers it is interacting with. If a peer's score drops below a threshold it is excluded from the scoring peer's mesh. We discuss more details on these settings in the GossipSub section. The full details can be found in the [GossipSub Specification](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub).
 
 NOTES:
 
-- _Fund Checking:_ It is important to note that the `mpool` logic is not checking whether there are enough funds in the account of the transaction message issuer. This is checked by the miner before including a transaction message in a block.
-- _Message Sorting:_ Transaction messages are sorted in the `mpool` of miners as they arrive according to cryptoeconomic rules followed by the miner and in order for the miner to compose the next block.
+- _Fund Checking:_ It is important to note that the `mpool` logic is not checking whether there are enough funds in the account of the message issuer. This is checked by the miner before including a message in a block.
+- _Message Sorting:_ Messages are sorted in the `mpool` of miners as they arrive according to cryptoeconomic rules followed by the miner and in order for the miner to compose the next block.