bump up MAX_CHUNK_SIZE at the merge as well

This commit is contained in:
Danny Ryan 2021-10-27 10:44:55 -06:00
parent bda07e15ad
commit d58b1c57ef
No known key found for this signature in database
GPG Key ID: 2765A792E42CE07A
1 changed files with 24 additions and 2 deletions

View File

@ -27,6 +27,8 @@ Readers should understand the Phase 0 and Altair documents and use them as a bas
- [Design decision rationale](#design-decision-rationale) - [Design decision rationale](#design-decision-rationale)
- [Gossipsub](#gossipsub) - [Gossipsub](#gossipsub)
- [Why was the max gossip message size increased at the Merge?](#why-was-the-max-gossip-message-size-increased-at-the-merge) - [Why was the max gossip message size increased at the Merge?](#why-was-the-max-gossip-message-size-increased-at-the-merge)
- [Req/Resp](#reqresp)
- [Why was the max chunk response size increased at the Merge?](#why-was-the-max-chunk-response-size-increased-at-the-merge)
<!-- END doctoc generated TOC please keep comment here to allow auto update --> <!-- END doctoc generated TOC please keep comment here to allow auto update -->
<!-- /TOC --> <!-- /TOC -->
@ -44,7 +46,8 @@ This section outlines modifications constants that are used in this spec.
| Name | Value | Description | | Name | Value | Description |
|---|---|---| |---|---|---|
| `GOSSIP_MAX_SIZE_MERGE` | `10 * 2**20` (= 10,485,760, 10 MiB) | The maximum allowed size of uncompressed gossip messages starting at the Merge upgrade | | `GOSSIP_MAX_SIZE_MERGE` | `10 * 2**20` (= 10,485,760, 10 MiB) | The maximum allowed size of uncompressed gossip messages starting at the Merge upgrade. |
| `MAX_CHUNK_SIZE_MERGE` | `10 * 2**20` (= 10,485,760, 10 MiB) | The maximum allowed size of uncompressed req/resp chunked responses starting at the Merge upgrade. |
## The gossip domain: gossipsub ## The gossip domain: gossipsub
@ -108,7 +111,12 @@ details on how to handle transitioning gossip topics for the Merge.
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_range/2/` **Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_range/2/`
Request and Response remain unchanged. Request and Response remain unchanged unless explicitly noted here.
Starting at the Merge upgrade,
a global maximum uncompressed byte size of `MAX_CHUNK_SIZE_MERGE` MUST be applied to all method response chunks
regardless of type specific bounds that *MUST* also be respected.
The Merge fork-digest is introduced to the `context` enum to specify the Merge block type. The Merge fork-digest is introduced to the `context` enum to specify the Merge block type.
Per `context = compute_fork_digest(fork_version, genesis_validators_root)`: Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
@ -164,3 +172,17 @@ slightly lower than 10 MiB. Considering that `BeaconBlock` max size is on the
order of 128 KiB in the worst case and the current gas limit (~30M) bounds max blocksize to less order of 128 KiB in the worst case and the current gas limit (~30M) bounds max blocksize to less
than 2 MiB today, this marginal difference in theoretical bounds will have zero than 2 MiB today, this marginal difference in theoretical bounds will have zero
impact on network functionality and security. impact on network functionality and security.
## Req/Resp
### Why was the max chunk response size increased at the Merge?
Similar to the discussion about the maximum gossip size increase, the
`ExecutionPayload` type can cause `BeaconBlock`s to exceed the 1 MiB bounds put
in place during Phase 0.
As with the gossip limit, 10 MiB is selected because this is firmly below any
valid block sizes in the range of gas limits expected in the medium term.
As with both gossip and req/rsp maximum values, type-specific limits should
always by simultaneously respected.