Merge 880cd56 into dcf80d9

Author: kamilsa

EIPS/eip-8070.md

@@ -79,64 +79,16 @@ Tenured transactions MAY be subject to resampling in other to test for liveness
 
 ### Execution clients :: Local block builders
 
-> TODO: config specification needed.
-
-Client implementations MUST provide configuration options for local block builders to specify a blob inclusion policy when proposing a block. Implementations SHOULD support at least these policies:
-
-1. Conservative: include only blob transactions for which all blob data is fully available locally (equivalent to today's behaviour).
-2. Optimistic: also include blob transactions that have been successfully sampled.
-3. Proactive: resample prior to blob proposal time in order to assess network-wide confidence of blobs potentially selected for inclusion. This requires an additional Engine API extension for the CL to notify the EL of upcoming proposer duty (TODO).
+**Eager mode for block builders.**
+A block builder MUST switch its fetch policy to eager mode at least 2-3 slots ahead before assembling execution payload: it acts as a provider (`p = 1.0`) for every type 3 transaction it intends to include, fetching the full blob payload unconditionally regardless of its normally configured `p` value. This guarantees that the builder holds complete blob data for all transactions in the payload.
 
 ### Engine API extensions
 
-> TODO: This specification will be moved out to the Execution APIs repo and linked to from here.
-
-**Method `engine_blobCustodyUpdatedV1`**
-
-Called by the Consensus layer client to inform the Execution layer of the indices of their current blob column custody set at startup, as well as subsequent changes during live operation.
-
-Request:
-
-- method: `engine_blobCustodyUpdatedV1`
-- params:
-  - `indices_bitarray`: uint128, interpreted as a bitarray of length `CELLS_PER_EXT_BLOB` indicating which column indices form the custody set.
-- timeout: 150ms
-
-Response:
-
-- result: no payload
-- error: code and message set in case an error occurs during processing of the request.
-
-Specification:
+The CL notifies the EL of its custody column set via the `custodyColumns` parameter on `engine_forkchoiceUpdatedV4`. This parameter is a 16-byte `DATA` value interpreted as a bitarray of length `CELLS_PER_EXT_BLOB`, or `null` if the CL does not provide custody services.
 
-1. The Consensus client MUST call this method whenever its custody set changes. Additionally, it MUST call it on start, on restart, and when an Engine API interruption is detected.
-2. The Execution client MUST return an Ok response if the request is well-formed. All subsequent sampling requests MUST adopt the new custody set. Queued sampling requests MAY be patched to reflect the new custody set.
-3. For type 3 transactions pending in the blobpool:
-    1. If the custody set has expanded, the Execution client MUST issue new sampling requests for the delta. It SHOULD broadcast updated `NewPooledTransactionHashes` announcement with the new available set.
-    2. If the custody set has contracted, the Execution client MAY prune dropped cells from local storage, but only AFTER it has broadcast an updated `NewPooledTransactionHashes` announcement with the reduced available set. This is to avoid peers from perceiving an availability fault if they happen to request those previously announced cells.
-4. The Execution client MUST treat a request to update the custody set to the current value as a no-op operation returning an Ok.
+The `engine_getBlobsV4` method is used by the CL to retrieve blob cells from the EL blobpool.
 
-**Method `engine_getBlobsV4`**
-
-Called by the Consensus layer client to retrieve blob cells from the Execution layer blobpool.
-
-Request:
-
-- method: `engine_getBlobsV4`
-- params:
-  - `versioned_blob_hashes`: []bytes32, an array of blob versioned hashes.
-  - `indices_bitarray`: uint128, a bitarray denoting the indices of the cells to retrieve.
-- timeout: 500ms
-
-Response:
-
-- result: `[]BlobCellsAndProofsV1`
-- error: code and message set in case an error occurs during processing of the request.
-
-**Data structure `BlobCellsAndProofsV1`**
-
-- `blob_cells`: a sequence of byte arrays `[]bytes` representing the partial matrix of the requested blobs, with `nil` entries for missing cells.
-- `proofs`: `Array of DATA` - Array of `KZGProof` as defined in [EIP-4844](./eip-4844.md), 48 bytes each (`DATA`)
+Both are specified in the [Execution APIs](https://github.com/ethereum/execution-apis) repository. See the [Amsterdam Engine API specification](https://github.com/ethereum/execution-apis/blob/main/src/engine/amsterdam.md) for details.
 
 ### Parameters
 
@@ -204,11 +156,15 @@ TBD
 
 ### Attack scenarios and threat model
 
+The goal of threat modeling is to identify potential attack vectors and vulnerabilities in the proposed sparse blobpool mechanism that may hurt the security, availability, or integrity of the type 3 transaction propagation. The threat model assumes a permissionless environment where adversaries can freely join the network, create multiple identities (Sybil attacks), and behave maliciously. Adversaries may aim to disrupt the network, degrade performance, censor transactions, or manipulate the availability of blob data. Below are some potential attack scenarios and their implications:
+
 **DoS attacks.** An important consideration in all mempool sharding mechanisms is the possibility of DoS attacks. This refers to the case where a malicious sender posts a transaction to the mempool disclosing only part of it, which makes the transaction impossible to be included in any future block, while still consuming mempool resources. In this system, such a sender can be detected by nodes that request the full payload of the transaction.
 
-**Selective withholding attacks.** TODO
+**Selective withholding attacks.** A malicious peer might selectively withhold full blob data for certain type 3 transactions (e.g. produced by a certain L2), thus slowing down their propagation and potentially leading to reduced availability. This can be mitigated by ensuring a sufficiently large and diverse peerset.
+
+**Eclipse attacks.** Malicious peers can try to isolate a victim node by controlling all its connections, serving only partial blob data and preventing it from obtaining the full payload. This hurts the victim's ability to propagate transactions and can lead to reduced availability of blob data and potential censorship of the honest peer. However, periodic rotation of connections and keeping track of neighbor peer's rate of full payload announcements can help mitigate this attack.
 
-**Eclipse attacks.** TODO
+**Free rider attacks.** A peer can send an excessive volume of blob data requests without reciprocating with announcements, thus consuming bandwidth without contributing to the network. This can be mitigated by keeping track of the requests to announcements ratio of peers and disconnecting those that exceed a certain threshold.
 
 ### Peer disconnection policies