Moved configuration into network preset instead of constants. (ethere…

…um#3394)

* Moved configuration into network preset instead of constants.

Now that `MAX_CHUNK_SIZE` and `GOSSIP_MAX_SIZE` are in configuration, we no longer need separate constants to represent them in the spec when they change in Bellatrix.

I've changed the usage, and put the values into the presets, but I'm not sure if I've updated the descriptions in the best way...

This is following on from the work in ethereum#3375 where a number of constants got moved into configuration, so we no longer need these constants to be separately represented, they can simply be updated in presets.

* Update presets/minimal/bellatrix.yaml

Co-authored-by: Hsiao-Wei Wang <[email protected]>

* Update presets/mainnet/bellatrix.yaml

Co-authored-by: Hsiao-Wei Wang <[email protected]>

* Moved preset items into the correct section and updated TOC.

It looked like the items listed in configuration about the max size and chunk size were no longer needed since we're updating preset values now and the preset changes seem to only be listed in the changes at the top.

* review feedback

* hopefully correct this time!  Moved the 2 fields from configs into presets completely as suggested.

* WIP - changing back to being in config and updating the phase 0 value... I think this should be close but want to see what's outstanding.

* fix intellij's formatting of table.

* more fixes

---------

Co-authored-by: Hsiao-Wei Wang <[email protected]>

configs/mainnet.yaml

@@ -98,16 +98,16 @@ DEPOSIT_CONTRACT_ADDRESS: 0x00000000219ab540356cBB839Cbe05303d7705Fa
 
 # Networking
 # ---------------------------------------------------------------
-# `2**20` (= 1048576, 1 MiB)
-GOSSIP_MAX_SIZE: 1048576
+# `10 * 2**20` (= 10485760, 10 MiB)
+GOSSIP_MAX_SIZE: 10485760
 # `2**10` (= 1024)
 MAX_REQUEST_BLOCKS: 1024
 # `2**8` (= 256)
 EPOCHS_PER_SUBNET_SUBSCRIPTION: 256
 # `MIN_VALIDATOR_WITHDRAWABILITY_DELAY + CHURN_LIMIT_QUOTIENT // 2` (= 33024, ~5 months)
 MIN_EPOCHS_FOR_BLOCK_REQUESTS: 33024
-# `2**20` (=1048576, 1 MiB) 
-MAX_CHUNK_SIZE: 1048576
+# `10 * 2**20` (=10485760, 10 MiB)
+MAX_CHUNK_SIZE: 10485760
 # 5s
 TTFB_TIMEOUT: 5
 # 10s

configs/minimal.yaml

@@ -99,16 +99,16 @@ DEPOSIT_CONTRACT_ADDRESS: 0x1234567890123456789012345678901234567890
 
 # Networking
 # ---------------------------------------------------------------
-# `2**20` (= 1048576, 1 MiB)
-GOSSIP_MAX_SIZE: 1048576
+# `10 * 2**20` (= 10485760, 10 MiB)
+GOSSIP_MAX_SIZE: 10485760
 # `2**10` (= 1024)
 MAX_REQUEST_BLOCKS: 1024
 # `2**8` (= 256)
 EPOCHS_PER_SUBNET_SUBSCRIPTION: 256
 # [customized] `MIN_VALIDATOR_WITHDRAWABILITY_DELAY + CHURN_LIMIT_QUOTIENT // 2` (= 272)
 MIN_EPOCHS_FOR_BLOCK_REQUESTS: 272
-# `2**20` (=1048576, 1 MiB) 
-MAX_CHUNK_SIZE: 1048576
+# `10 * 2**20` (=10485760, 10 MiB)
+MAX_CHUNK_SIZE: 10485760
 # 5s
 TTFB_TIMEOUT: 5
 # 10s

presets/mainnet/phase0.yaml

@@ -85,4 +85,4 @@ MAX_ATTESTATIONS: 128
 # 2**4 (= 16)
 MAX_DEPOSITS: 16
 # 2**4 (= 16)
-MAX_VOLUNTARY_EXITS: 16
+MAX_VOLUNTARY_EXITS: 16

presets/minimal/phase0.yaml

@@ -85,4 +85,4 @@ MAX_ATTESTATIONS: 128
 # 2**4 (= 16)
 MAX_DEPOSITS: 16
 # 2**4 (= 16)
-MAX_VOLUNTARY_EXITS: 16
+MAX_VOLUNTARY_EXITS: 16

specs/bellatrix/p2p-interface.md

@@ -14,7 +14,6 @@ Readers should understand the Phase 0 and Altair documents and use them as a bas
 
   - [Warning](#warning)
   - [Modifications in Bellatrix](#modifications-in-bellatrix)
-    - [Configuration](#configuration)
     - [The gossip domain: gossipsub](#the-gossip-domain-gossipsub)
       - [Topics and messages](#topics-and-messages)
         - [Global topics](#global-topics)
@@ -41,15 +40,6 @@ Refer to the note in the [validator guide](./validator.md) for further details.
 
 ## Modifications in Bellatrix
 
-### Configuration
-
-This section outlines modifications constants that are used in this spec.
-
-| Name | Value | Description |
-|---|---|---|
-| `GOSSIP_MAX_SIZE_BELLATRIX` | `10 * 2**20` (= 10,485,760, 10 MiB) | The maximum allowed size of uncompressed gossip messages starting at Bellatrix upgrade. |
-| `MAX_CHUNK_SIZE_BELLATRIX` | `10 * 2**20` (= 10,485,760, 10 MiB) | The maximum allowed size of uncompressed req/resp chunked responses starting at Bellatrix upgrade. |
-
 ### The gossip domain: gossipsub
 
 Some gossip meshes are upgraded in Bellatrix to support upgraded types.
@@ -61,11 +51,6 @@ All topics remain stable except the beacon block topic which is updated with the
 
 The specification around the creation, validation, and dissemination of messages has not changed from the Phase 0 and Altair documents unless explicitly noted here.
 
-Starting at Bellatrix upgrade, each gossipsub [message](https://github.com/libp2p/go-libp2p-pubsub/blob/master/pb/rpc.proto#L17-L24)
-has a maximum size of `GOSSIP_MAX_SIZE_BELLATRIX`.
-Clients MUST reject (fail validation) messages that are over this size limit.
-Likewise, clients MUST NOT emit or propagate messages larger than this limit.
-
 The derivation of the `message-id` remains stable.
 
 The new topics along with the type of the `data` field of a gossipsub message are given in this table:
@@ -130,10 +115,6 @@ down-scoring or disconnection.
 
 Request and Response remain unchanged unless explicitly noted here.
 
-Starting at Bellatrix upgrade,
-a global maximum uncompressed byte size of `MAX_CHUNK_SIZE_BELLATRIX` MUST be applied to all method response chunks
-regardless of type specific bounds that *MUST* also be respected.
-
 Bellatrix fork-digest is introduced to the `context` enum to specify Bellatrix block type.
 
 Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
@@ -171,17 +152,12 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
 
 With the addition of `ExecutionPayload` to `BeaconBlock`s, there is a dynamic
 field -- `transactions` -- which can validly exceed the `GOSSIP_MAX_SIZE` limit (1 MiB) put in
-place at Phase 0. At the `GAS_LIMIT` (~30M) currently seen on mainnet in 2021, a single transaction
+place at Phase 0, so GOSSIP_MAX_SIZE has increased to 10 Mib on the network. 
+At the `GAS_LIMIT` (~30M) currently seen on mainnet in 2021, a single transaction
 filled entirely with data at a cost of 16 gas per byte can create a valid
 `ExecutionPayload` of ~2 MiB. Thus we need a size limit to at least account for
 current mainnet conditions.
 
-Geth currently has a [max gossip message size](https://github.com/ethereum/go-ethereum/blob/3ce9f6d96f38712f5d6756e97b59ccc20cc403b3/eth/protocols/eth/protocol.go#L49) of 10 MiB.
-To support backward compatibility with this previously defined network limit,
-we adopt `GOSSIP_MAX_SIZE_BELLATRIX` of 10 MiB for maximum gossip sizes at the
-point of Bellatrix and beyond. Note, that clients SHOULD still reject objects
-that exceed their maximum theoretical bounds which in most cases is less than `GOSSIP_MAX_SIZE_BELLATRIX`.
-
 Note, that due to additional size induced by the `BeaconBlock` contents (e.g.
 proposer signature, operations lists, etc) this does reduce the
 theoretical max valid `ExecutionPayload` (and `transactions` list) size as

specs/phase0/p2p-interface.md

@@ -189,11 +189,11 @@ This section outlines configurations that are used in this spec.
 
 | Name | Value | Description |
 |---|---|---|
-| `GOSSIP_MAX_SIZE` | `2**20` (= 1048576, 1 MiB) | The maximum allowed size of uncompressed gossip messages. |
+| `GOSSIP_MAX_SIZE` | `10 * 2**20` (= 10485760, 10 MiB) | The maximum allowed size of uncompressed gossip messages. |
 | `MAX_REQUEST_BLOCKS` | `2**10` (= 1024) | Maximum number of blocks in a single request |
 | `EPOCHS_PER_SUBNET_SUBSCRIPTION` | `2**8` (= 256) | Number of epochs on a subnet subscription (~27 hours) |
 | `MIN_EPOCHS_FOR_BLOCK_REQUESTS` | `MIN_VALIDATOR_WITHDRAWABILITY_DELAY + CHURN_LIMIT_QUOTIENT // 2` (= 33024, ~5 months) | The minimum epoch range over which a node must serve blocks |
-| `MAX_CHUNK_SIZE` | `2**20` (=1048576, 1 MiB) | The maximum allowed size of uncompressed req/resp chunked responses. |
+| `MAX_CHUNK_SIZE` | `10 * 2**20` (=10485760, 10 MiB) | The maximum allowed size of uncompressed req/resp chunked responses. |
 | `TTFB_TIMEOUT` | `5` | The maximum duration in **seconds** to wait for first byte of request response (time-to-first-byte). |
 | `RESP_TIMEOUT` | `10` | The maximum duration in **seconds** for complete response transfer. |
 | `ATTESTATION_PROPAGATION_SLOT_RANGE` | `32` | The maximum number of slots during which an attestation can be propagated. |