kip-279: Clarify Blob p2p protocol

KIPs/kip-279.md

@@ -123,23 +123,24 @@ The Kaia chain internally processes the RLP encoding prefixed with `TxTypeEthere
 **Propagate BlobTxWithBlobs**
 
 - An RPC endpoint node, MAY accept a `BlobTxWithBlobs` via its `eth_sendRawTransaction` and `kaia_sendRawTransaction` JSON-RPC API.
-- A node SHOULD accept a `BlobTxWithBlobs` via its p2p `TxMsg`.
+- A node SHOULD accept a `BlobTxWithBlobs` via its p2p `TxMsg (0x06)`.
 - When a node receive a `BlobTxWithBlobs` via RPC or p2p, it MUST be validated, then propagated to its peers like any other transactions in the txpool.
 
-**Consensus**
+**Block consensus**
 
 - When a block proposer decides to include a `BlobTx`, the proposer MUST assure that the originating `BlobTxWithBlobs` is verified.
-- Block proposals SHOULD include the `BlobTxWithBlobs` so validators can verify it.
+- Block proposals in `IstanbulMsg (0x11)` SHOULD include the `BlobTxWithBlobs` so validators can verify it.
 - Validators MUST assure that the `BlobTxWithBlobs` is verified *before committing to the block*. Note that verifying a `BlobTxWithBlobs` does not require block execution.
 - As a result, whenever you see a `BlobTx` in a finalized block, you are sure that there exists a corresponding `BlobTxSidecar` because you trust the CNs' consensus.
 
 **Persist BlobTxSidecar**
 
-- When a node receive a finalized block with `BlobTx` inside, the node SHOULD persist the corresponding `BlobTxSidecar`.
-  - The `BlobTxSidecar` can come from the `BlobTxWithBlobs` in the node's txpool memory.
-  - The `BlobTxSidecar` can come from the peer over p2p.
-- Nodes MAY request peers for `BlobTxSidecars` in `BlobSidecarsRequestMsg = 0x15` p2p message. In turn, nodes SHOULD respond peers with `BlobTxSidecars` in `BlobSidecarsMsg = 0x16` p2p message, if available.
-- Nodes SHOULD NOT request peers for `BlobTxSidecars` whose block number is older than `BLOB_SIDECARS_RETENTION` before the known head block.
+- When a node receive a finalized block with `BlobTx` inside, the node SHOULD persist the corresponding `BlobTxSidecar`. The node can obtain the `BlobTxSidecar` from following sources:
+  - From the `BlobTxWithBlobs` in the node's txpool memory
+  - From a peer over p2p `NewBlockMsg (0x0b)`
+  - From a peer over p2p `BlobSidecarsMsg (0x16)`
+- Nodes MAY request peers for `BlobTxSidecars` via `BlobSidecarsRequestMsg (0x15)` p2p message. In turn, nodes SHOULD respond peers with `BlobTxSidecars` in `BlobSidecarsMsg (0x16)` p2p message, if available.
+- Nodes SHOULD NOT request peers for `BlobTxSidecars` whose block number is older than `BLOB_SIDECARS_RETENTION` before the head block.
 - Nodes MAY delete the `BlobTxSidecar` whose block number is older than `BLOB_SIDECARS_RETENTION` before the head block.
 
 ![blobtx_networking](../assets/kip-279/blobtx_networking.png)
@@ -164,7 +165,8 @@ Upon receiving a `BlobTxWithBlobs` via RPC or p2p, it is verified as follows.
 
 A `BlobTxWithBlobs` verification happens in these situations:
 - Receive via `eth_sendRawTransaction` RPC
-- Receive via [`TxMsg` p2p message](https://github.com/kaiachain/kaia/blob/v2.1.0/node/cn/protocol.go)
+- Receive via [`TxMsg` p2p message](https://github.com/kaiachain/kaia/blob/v2.1.0/node/cn/protocol.go#L61)
+- Receive via [`NewBlockMsg` p2p message](https://github.com/kaiachain/kaia/blob/v2.2.0-rc.1/node/cn/protocol.go#L89)
 - Receive via [`IstanbulMsg` p2p message](https://github.com/kaiachain/kaia/blob/v2.1.0/consensus/istanbul/backend/handler.go)'s [Proposal payload](https://github.com/kaiachain/kaia/blob/v2.1.0/consensus/istanbul/types.go). Note that the `type Proposal interface` is instantiated as `*types.Block` which includes the transactions inside. Since a `BlobTxWithBlobs` is treated as a transaction, the Proposal should naturally include Sidecars.
 
 ### Block validation