FIL VM Message Validation Update

content/systems/filecoin_vm/message/_index.md

@@ -2,7 +2,7 @@
 title: Message
 weight: 4
 dashboardWeight: 1.5
-dashboardState: incomplete
+dashboardState: stable
 dashboardAudit: 0
 dashboardTests: 0
 ---
@@ -13,38 +13,73 @@ A message is the unit of communication between two actors, and thus the primitiv
 in state. A message combines:
 
 - a token amount to be transferred from the sender to the receiver, and
-- a method with parameters to be invoked on the receiver (optional).
+- a method with parameters to be invoked on the receiver (optional/where applicable).
 
 Actor code may send additional messages to other actors while processing a received message. 
-Messages are processed synchronously: an actor waits for a sent message to complete before resuming control.
+Messages are processed synchronously, that is, an actor waits for a sent message to complete before resuming control.
 
-The processing of a message consumes units of computation and storage denominated in gas. 
-A message's gas limit provides an upper bound on its computation. The sender of a message pays 
+The processing of a message consumes units of computation and storage, both of which are denominated in gas. 
+A message's _gas limit_ provides an upper bound on the computation required to process it. The sender of a message pays 
 for the gas units consumed by a message's execution (including all nested messages) at a
 gas price they determine. A block producer chooses which messages to include in a block and is
 rewarded according to each message's gas price and consumption, forming a market.
 
 ## Message syntax validation
 
 A syntactically invalid message must not be transmitted, retained in a message pool, or
-included in a block.
+included in a block. If an invalid message is received, it should be dropped and not propagated further.
+
+When transmitted individually (before inclusion in a block), a message is packaged as
+`SignedMessage`, regardless of signature scheme used. A valid signed message has a total serialized size no greater than `message.MessageMaxSize`.
+
+```go
+type SignedMessage struct {
+	Message   Message
+	Signature crypto.Signature
+}
+```
 
 A syntactically valid `UnsignedMessage`:
 
 - has a well-formed, non-empty `To` address,
 - has a well-formed, non-empty `From` address, 
-- has a non-negative `CallSeqNum`,
 - has `Value` no less than zero and no greater than the total token supply (`2e9 * 1e18`), and
-- has a non-negative `MethodNum`,
-- has non-empty `Params` only if `MethodNum` is zero,
 - has non-negative `GasPrice`,
 - has `GasLimit` that is at least equal to the gas consumption associated with the message's serialized bytes,
 - has `GasLimit` that is no greater than the block gas limit network parameter.
 
-When transmitted individually (before inclusion in a block), a message is packaged as
-`SignedMessage`, regardless of signature scheme used. A valid signed message:
 
-- has a total serialized size no greater than `message.MessageMaxSize`.
+```go
+type Message struct {
+	// Version of this message (has to be non-negative)
+	Version uint64
+
+	// Address of the receiving actor.
+	To   address.Address
+	// Address of the sending actor.
+	From address.Address
+
+	CallSeqNum uint64
+
+	// Value to transfer from sender's to receiver's balance.
+	Value BigInt
+
+	// GasPrice is a Gas-to-FIL cost
+	GasPrice BigInt
+	// Maximum Gas to be spent on the processing of this message
+	GasLimit int64
+
+	// Optional method to invoke on receiver, zero for a plain value transfer.
+	Method abi.MethodNum
+	//Serialized parameters to the method.
+	Params []byte
+}
+```
+
+There should be several functions able to extract information from the `Message struct`, such as the sender and recipient addresses, the value to be transferred, the required funds to execute the message and the CID of the message.
+
+Given that Transaction Messages should eventually be included in a Block and added to the blockchain, the validity of the message should be checked with regard to the sender and the receiver of the message, the value (which should be non-negative and always smaller than the circulating supply), the gas price (which again should be non-negative) and the `BlockGasLimit` which should not be greater than the block's gas limit.
+
 
 ## Message semantic validation
 
@@ -63,14 +98,23 @@ Message pools may exclude messages from an actor that is not yet present in the
 
 There is no further semantic validation of a message that can cause a block including the message 
 to be invalid. Every syntactically valid and correctly signed message can be included in a block and 
-will produce a receipt from execution. 
-However, a message may fail to execute to completion, in which case it will not effect the desired state change.  
+will produce a receipt from execution. The `MessageReceipt sturct` includes the following:
+
+```go
+type MessageReceipt struct {
+	ExitCode exitcode.ExitCode
+	Return   []byte
+	GasUsed  int64
+}
+```
+
+
+However, a message may fail to execute to completion, in which case it will not trigger the desired state change.  
 
 The reason for this "no message semantic validation" policy is that the state that a message will
 be applied to cannot be known before the message is executed _as part of a tipset_. A block producer
 does not know whether another block will precede it in the tipset, thus altering the state to
 which the block's messages will apply from the declared parent state.
 
-{{<embed src="message.id" lang="go" >}}
 
-{{<embed src="message.go" lang="go" >}}
+{{<embed src="/modules/lotus/chain/types/message.go"  lang="go">}}