add: add behaviour

Author: healthykim

caps/eth.md

@@ -125,25 +125,52 @@ relayed by the peer.
 
 ### Blob Transaction and Cell Exchange
 
-Blob transaction carries one or more large objects called blobs, in addition to the normal 
-transaction payload. Blobs are not sent directly with the transaction. Instead, they are 
-split into cells using the erasure code defined in [EIP-7594], and these cells are exchanged 
-separately between peers. Since a transaction can carry multiple blobs, cell exchange is 
-handled at the transaction level, which means that cells in the same transaction should be 
-delivered together.
-
-When a blob transaction is added to a peer's pool, availability of its cells should be 
-announced to the network using the `cells` field in the [NewPooledTransactionHashes] message. 
-If a bit is set, it indicates that the peer holds the corresponding cell for all blobs 
-included in the announced transactions. 
-All peers that receive the message can then request the cells whose indices are 
-specified in the cells field using the [GetCells] message. Clients can selectively store 
-cells according to their local parameters.
-
+Blob transaction contains one or more 128KiB fixed sized objects call blobs. Blobs can be 
+split into cells using the erasure code defined in [EIP-7594]. Currently, the size of cell 
+is defined as 2KiB, which makes the blobs to be consisted in 128 cells combined with 1/2 code 
+rate. A cell can be identified in the erasure-coded blob by its order (index).
+
+Blobs also carry metadata such as cell proofs and a commitment required to verify whether a 
+cell is part of blob data.
+
+- Commitment: Commitment is a cryptographic value bound to a blob. It is used in inclusion 
+verification to ensure that any given cell is part of the original blob.
+
+- Proof: Proof is a cell-specific proof used during the inclusion verification of associated cell.
+
+Blob transaction exchange must be initiated only through the [NewPooledTransactionHashes] 
+message. The peer should also announce availability of its cells using the `cells` field 
+in the message. If a bit in the field is set, it indicates that the peer holds the 
+corresponding cell for all blobs included in the announced transactions.
+
+Response to [GetPooledTransactions] for blob transactions include traditional transaction 
+payload and blob metadata. However, the corresponding blob data can only be obtained as cells, 
+via [GetCells]. Since a transaction can carry multiple blobs, cell exchange is handled at the 
+transaction level, which means that cells in the same transaction should be delivered together.
+
+Upon receiving the [NewPooledTransactionHashes] message with new blob transaction hashes, 
+the node starts to fetch cells in parallel with transaction fetch described above. 
+The node first makes a probabilistic decision. 
+If it decided to fetch the full blobs with probability $p$, the node request 
+them using the [GetCells] message, setting more than 50% of total cell indices as 1 in 
+the `cells` field. Recommended probability $p$ is 0.15.
+
+If it decided not to fetch the full blobs, it must request its custody cells from peers 
+that announced overlapping availability using [GetCells] message, but only after it 
+observes N(TBD) distinct full-availability announcements. 
+Custody cells refer to the cells whose index is in a custody index set of their 
+associated consensus node id.
+The node must also request an excess of N random columns in addition to its custody set. 
+This is to mitigate targeted and selective data attacks. The node must only announce onwards 
+once it has obtained all its custody cells. 
+
+A node must only request a maximum of 4(TBD) columns per peer per transaction. 
 A node should never announce availability to a peer that it can infer to already 
-have the associated cell. This can be achieved by remembering set of versioned hashes 
+have the associated cell. This can be achieved by remembering set of transaction hashes 
 and cell indices announced by each peer.
 
+Some nodes might need to store 
+
 ### Transaction Encoding and Validity
 
 Transaction objects exchanged by peers have one of two encodings. In definitions across
@@ -548,9 +575,9 @@ The `cells` element, a bitmap, specifies indices of the requested cells.
 This is the response to [GetCells]. 
 Each element must match the txhash and cells specified in the request.
 The sender can skip any indices that are not available, so the requester can fetch them 
-from other peers. Skipping is allowed only at the index level. The sender must return the 
-corresponding cells for all blobs included in the transaction and cannot skip cells belonging 
-to specific blobs.
+from other peers. However, skipping is allowed only at the index level. 
+The sender must return the corresponding cells for all blobs included in the transaction 
+and cannot skip cells belonging to specific blobs.
 
 ## Change Log