Update EIP-8070: Update EIP-8070#11444
Conversation
…e blob transaction concerns
Remove inline Engine API specification and point to the authoritative specification in the execution-apis repository (Amsterdam Engine API spec). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…and mitigation heuristics
…istic recommendations
github-actions
Bot
added
c-update
File
|
| ### Execution clients :: Local block builders | ||
|
|
||
| > TODO: config specification needed. | ||
| **Eager mode for block builders.** |
There was a problem hiding this comment.
Just a nitpick, but I think the categories could be structured as follows:
-
Building on full blobs
: This strategy only includes blob transactions for which the client has the full blob data when building an execution payload. To support higher blob throughput, the CL client may update its notified custody to Union(data indices, its own custody column indices), 2-3 slot ahead of being proposer. -
Building on partial blobs
: This requires further risk profiling, so we can defer including it for now.
So in strategy 1, the EL client always builds the payload based on the existing includable transactions for which it has full blob data. Whether the number of those txs should be maximized by eagerly fetching cells is up to the CL client's decision. I personally think this is clearer from the implementation perspective
There was a problem hiding this comment.
Building on full blobs
I clarified that builders should act as providers at least 2-3 slots ahead of the block they are building (or simply act as provider permanently)
Building on partial blobs
I don't see how builders can include partial blobs into their bids. Builders should possess all the columns, as once they see their block bid is approved they need to propagate them to the column subnets
There was a problem hiding this comment.
Before assembling an execution payload, a local block builder MUST switch its fetch policy to eager mode
What I meant to say is that we can relax this requirement, not making it strictly mandatory. Builders could construct a block based on the p portion of blob transactions that are fully available in their blobpool, and they could also maximize candidate transactions by switching to eager mode. The former option could be attractive for solo stakers with limited network resources.
I don't see how builders can include partial blobs into their bids. Builders should possess all the columns, as once they see their block bid is approved they need to propagate them to the column subnets
Builders could rely on the assumption that the partial blobs they are including are already widely propagated at the EL level, and that other nodes could retrieve and propagate those blob data via the getBlobs engine API (after the execution payload is revealed). However, we currently don't have a theoretical analysis to determine to what extent and under which conditions these assumptions hold.
There was a problem hiding this comment.
Builders could rely on the assumption that the partial blobs they are including are already widely propagated at the EL level, and that other nodes could retrieve and propagate those blob data via the getBlobs engine AP
IMO, this creates a risk that builder could be tricked to have an impression that the partial blobs he possesses are not actually present in the network, and then PTC would reject builder's block and slot could be left without a valid block
There was a problem hiding this comment.
I agree that there is such a risk. We were discussing giving this risky option to builders, acknowledging that it is risky, but with some mechanisms to mitigate the risk and a detailed explanation of how significant that risk is. However, I agree that we could simply omit it here and discuss it later.
|
|
||
| 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: | ||
| **Private blob transactions.** | ||
| A significant concern arises when blob transactions are delivered to the builder privately (i.e., bypassing the public mempool). In this case the builder is the sole holder of the full blob payload at the time the execution payload envelope is revealed. Nodes that were not previously exposed to these transactions via `NewPooledTransactionHashes` cannot satisfy custody columns via `engine_getBlobsV4`, and must instead fetch column data directly from the builder during the critical path of block validation. In the worst case, where all blob transactions in the payload are private, this creates a concentrated bandwidth spike on the builder at exactly the moment the envelope is revealed, competing with and potentially starving block and attestation traffic. |
There was a problem hiding this comment.
I have two questions regarding this part
-
Is this different from the process currently required to submit a private blob transaction?
I think this paragraph is intended to show that we can better support private blob transactions, since we can seed columns without providing full blobs, enabling pre-propagation of blob data, something that wasn’t possible before this proposal. If that was the intention, I don’t think it is emphasized enough. -
Can we actually provide this property?
First, if the builder is the only one announcing full availability, the blob cannot be sampled, since it does not pass the availability check.
Second, the proposal seems to say two contradictory things, “For maximal security, you can choose to drop transactions that do not appear to be available among peers / resample them / apply peer scoring to drop peers that frequently refuse fetch requests,” and “Private blobs can be pre-propagated without revealing their full content.” Even if the builder successfully pre-seeded its peers, those columns would not likely to be propagated beyond them, and will be dropped because those peers cannot see enough availability around them. If a peer requests a full fetch with prob. p, the builder would refuse to respond, which may lead to disconnection depending on the client’s design.
Aside from this, I think providing multiple options is a good thing. However, the options specified in the EIP should be things that are mutually consistent and have concrete use cases. If there are too many “may”s, it becomes difficult for both us and client teams to reason about all the possible combinations. So I’d like to take a closer look at the heuristics described below and related things to see whether some of them can be omitted, so that we can reason about those combinations more concisely.
There was a problem hiding this comment.
Let me drop this section to keep EIP cleaner, and not to enforce too many new rules for builders.
Private blobs are the worst case scenario. However, most blobs today are public. We might revisit that if we notice that portion of private blob transactions becomes significant, and this has a valuable effect on the speed of propagation of the data columns
…cution payload assembly
| #### H1 — Includability check | ||
|
|
||
| **Eclipse attacks.** TODO | ||
| Nodes SHOULD reject or deprioritize newly announced blob transactions that are clearly non-includable under current fee conditions. A simple implementation compares the transaction's blob fee against the current blob base fee, optionally with a local discount factor to tolerate small fee movements. Transactions failing this check SHOULD NOT be included in the blobpool, and nodes SHOULD avoid issuing further `GetCells` requests for them. Repeated floods of such transactions from the same peer MAY contribute to local rate-limiting or disconnection heuristics. This mechanism primarily mitigates pool-spam DoS attacks. |
There was a problem hiding this comment.
I don’t see why this should be included here. How is it relevant to the sparse blobpool? Also, this is something well-known and clients are already mitigating. Not including non-includable blob transactions is already an obvious principle in current transaction pool design in general.
The suggested attack is also not specific to sparse blobpool and already possible under the current pool, and it can be done not only through fees but also via various ways like low nonce.
I don’t think this needs to be mentioned in this EIP as a separate heuristic. If it is necessary, it could be included as one of the possible approaches for peer scoring part. And I this this has already been mentioned there.
There was a problem hiding this comment.
I think the attack vector and the heuristic are worth mentioning in general, but they should be suggested separately for each client implementations rather than as part of this EIP
| #### H2 — Corroboration / saturation check | ||
|
|
||
| ### The need for sampling noise | ||
| Nodes SHOULD avoid retaining newly announced blob transactions unless they are corroborated by additional peers within a bounded period. A simple implementation requires at least a minimum number of independent announcements from distinct peers before the transaction is granted longer tenure in the blobpool. Transactions that fail to reach this threshold SHOULD be evicted. |
There was a problem hiding this comment.
How is this different from our basic mechanism, which waits for enough provider announcements before fetching / storing the transaction?
| #### H3 — Randomized availability probing (sampling noise) | ||
|
|
||
| This simple mechanism reinforces key model assumptions (a provider is truly a provider) in exchange for negligible overhead per request (MAX_BLOBS_PER_TX x CELL_SIZE + proofs = ~12KiB). | ||
| When requesting cells for a transaction from a peer that claims provider-like availability, a node SHOULD include a small number of randomly selected extra columns (`C_extra`) in addition to its custody-aligned columns, while respecting the per-request cap (`C_req`). The purpose is to make requests less predictable and reduce the attack surface for selective withholding. |
There was a problem hiding this comment.
Above on " Execution clients :: Blobpool behavior", it says
When fetching from a provider, the node MUST request C_extra random columns in addition to its custody set (see “Sampling noise” in Rationale).
I would suggest using “SHOULD” above, to align with this section, or removing the description above, since it is already covered here as one of the heuristics.
|
The commit 880cd56 (as a parent of 00fdbfb) contains errors. |
4 participants
Execution client and block builder policy updates:
Engine API specification changes:
engine_blobCustodyUpdatedV1andengine_getBlobsV4methods, instead referencing the canonical Amsterdam Engine API specification in the Execution APIs repository.Security considerations and anti-abuse heuristics: