Geth Statement on EIP-8070

# Geth Statement on EIP-8070 - Geth has implemented an initial prototype of EIP-8070 (Sparse blobpool). - We hope EIP-8070 to be SFIed. The main advantage of this proposal is that it reduces bandwidth usage for non-proposer nodes while preserving the current role of the blobpool, which is the pre-propagation of custody columns. - We have reviewed scenarios involving attackers pretending as providers, and developed local heuristics to defend against them. ## Prototype https://github.com/ethereum/go-ethereum/pull/34047  ### Key Changes - The blobpool[^1] stores custody cells instead of full blobs. - There is no change to the format of blob transactions submitted by users; cells are computed and stored internally. - Accordingly, the Get operation has two modes: returning a transaction without blobs, or returning cells. - Blob fetcher[^2] has been introduced to schedule cell exchange. - There are two possible approaches: 1) Fetching cells and transactions asynchronously 2) Fetching transactions first, then fetching cells - The issue with the first approach is that validation of cells depends on commitments and proofs exchanged along with transactions. Conversely, transaction validation also depends on the presence of cells. The current prototype adopts the first approach, adding a buffer to temporarily store each component.[^*] - When a custody update occurs, all cells corresponding to the union of the two custody sets are retained for a certain period (TBD). - For transactions selected for partial fetch, if k providers cannot be secured, the process switches to full fetch. - This acts as a safeguard against this rare event (e.g., p=0.15, k=2 results in 0.3%). --- [^1]: Geth’s mempool consists of multiple sub-pools, including a dedicated sub-pool (blobpool) for storing blob transactions. [^2]: Geth uses a module called tx fetcher to schedule transaction exchange in the eth protocol. [^*]: Would it be beneficial to integrate https://eips.ethereum.org/EIPS/eip-8094? For example, PooledTransactionHash could include vhash, and GetCells could use vhash as an identifier. While this would increase the amount of metadata in announcements, it would enable more accurate request scheduling. (Currently, since the number of blobs is unknown, requests may be larger or smaller than expected. The original idea of using tx hash was based on the assumption that custody requests would be identical for all blobs of a given transaction.) If this is included in EIP-8070, clients could internally implement the functionality intended in EIP-8094 using this message type. ## Security Evaluation - As outlined in Security Considerations section, the EIP itself considers multiple attack scenarios. - Additionally, we analyzed [this attack](https://hackmd.io/@yZzECM-fQt2ePeYIwC4CUw/ByufNL90le), and considered the following local heuristics as possible candidates to defend against it: - Scoring for detecting malicious peers, based on 1. How many of their announced transactions are included in blocks. 2. How frequently they respond to GetPooledTransactions and GetCells requests. *Those ideas are currently being explored by @Csaba - Removal of transactions injected by malicious peers: 1. If the lowest nonce transaction is a partial blob transaction, limit the number of transactions that account can accumulate. Also limit transactions from such accounts to a certain percentage of the entire blobpool. See [here](https://hackmd.io/@bosulmun/SJ_g80k5Wg) for a more detailed analysis. 2. Partial blobs are periodically selected at random for full fetches. If a fetch fails, the blob is dropped. The longer a partial blob stays in the pool, the less likely it is to avoid these checks. ## Future Considerations ### Rollout Strategy Although the eth protocol itself does not require a fork, eth72 depends on the number of peers signaling availability. Therefore, it is necessary to simulate network behavior in environments where eth71 and eth72 coexist. For example, the following rules could be applied: - Always perform full fetch for eth71 peers, and only announce transactions with full availability for them.  - For partial blob transactions, if the number of providers exceeds k, check whether there are eth72 peers that have announced overlapping availability for the transaction. Otherwise, switch to full fetch. ### Block Building The safest option under this EIP is to build blocks based on full blobs. Risk profiling is required for building blocks based on partial blobs. ## Questions We would like to ask other client teams the following: - Is it realistic to implement this, assuming snap/2 is being worked on? - Do you think this proposal should move to SFI? If not, what are your reasons? - Besu and Nethermind have assigned this proposal an A-tier rating, while Erigon and Reth have not assigned any tier. Therefore, this question is mainly directed at Erigon and Reth.

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.