|
8 | 8 | Instructs the beacon node to broadcast a newly signed beacon block to the beacon network,
|
9 | 9 | to be included in the beacon chain. A success response (20x) indicates that the block
|
10 | 10 | passed gossip validation and was successfully broadcast onto the network.
|
11 |
| - The beacon node is also expected to integrate the block into state, but may broadcast it |
| 11 | + The beacon node is also expected to integrate the block into the state, but may broadcast it |
12 | 12 | before doing so, so as to aid timely delivery of the block. Should the block fail full
|
13 | 13 | validation, a separate success response code (202) is used to indicate that the block was
|
14 |
| - successfully broadcast but failed integration. |
| 14 | + successfully broadcast but failed integration. The broadcast behaviour may be adjusted via the |
| 15 | + `broadcast_validation` query parameter. |
15 | 16 | parameters:
|
| 17 | + - name: broadcast_validation |
| 18 | + in: query |
| 19 | + required: false |
| 20 | + description: | |
| 21 | + Level of validation that must be applied to a block before it is broadcast. |
| 22 | +
|
| 23 | + Possible values: |
| 24 | + - **`gossip`** (default): lightweight gossip checks only |
| 25 | + - **`consensus`**: full consensus checks, including validation of all signatures and |
| 26 | + blocks fields _except_ for the execution payload transactions. |
| 27 | +
|
| 28 | + If the block fails the requested level of a validation a 400 status MUST be returned |
| 29 | + immediately and the block MUST NOT be broadcast to the network. |
| 30 | +
|
| 31 | + If validation succeeds, the block must still be fully verified before it is |
| 32 | + incorporated into the state and a 20x status is returned to the caller. |
| 33 | + schema: |
| 34 | + $ref: '../../../beacon-node-oapi.yaml#/components/schemas/BroadcastValidation' |
16 | 35 | - in: header
|
17 | 36 | schema:
|
18 | 37 | $ref: '../../../beacon-node-oapi.yaml#/components/schemas/ConsensusVersion'
|
|
0 commit comments