You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -48,63 +44,6 @@ Each box is a process. If it has children, it's a supervisor, with it's restart
48
44
49
45
If it's a leaf in the tree, it's a GenServer, task, or other non-supervisor process. The tags in the edges/arrows are the init args passed on children init (start or restart after crash).
50
46
51
-
### High level interaction
52
-
53
-
This is the high level interaction between the processes.
This section contains sequence diagrams representing the interaction of processes through time in response to a stimulus. The main entry point for new events is through gossip and request-response protocols, which is how nodes communicates between each other.
@@ -296,10 +235,6 @@ Explained, a process that wants to request something from Libp2pPort sends a req
296
235
297
236
The specific kind of command (a request) is specified, but there's nothing identifying this is a response vs any other kind of result, or the specific kind of response (e.g. a block download vs a blob download). Currently the only way this is handled differentially is because the pid is waiting for a specific kind of response and for nothing else at a time.
298
237
299
-
## Checkpoint sync
300
-
301
-
**TO DO**: document checkpoint sync.
302
-
303
238
## Validators
304
239
305
240
Validators are separate processes. They react to:
@@ -351,6 +286,85 @@ In the proposing slot:
351
286
- The deposits and eth1_vote are fetched from `ExecutionChain`.
352
287
- The block is signed.
353
288
289
+
## Execution Chain
290
+
291
+
The consensus node needs to communicate with the execution client for three different reasons:
292
+
293
+
- Fork choice updates: the execution clients needs notifications when the head is updated, and payloads need validation. For these goals, `engineAPI` is used.
294
+
- Deposit contract tracking: accounts that wish to become validators need to deposit 32ETH in the deposit contract. This happens in the execution chain, but the information needs to arrive to consensus for the validator set to be updated.
295
+
- Eth 1 votes: consensus nodes agree on a summary of the execution state and a voting mechanism is built for this.
296
+
297
+
Let's go to this communication sections one by one.
298
+
299
+
### Engine API: fork choice updates
300
+
301
+
The consensus node does not live in isolation. It communicates to the execution client. We implemented, in the `ExecutionClient` module, the following primitives:
302
+
303
+
-`notify_forkchoice_updated(fork_choice_state)`: first message sent to the execution client right after exchanging capabilities. It returns if the client is syncing or valid.
304
+
-`notify_forkchoice_updated(fork_choice_state, payload_attributes)`: sent to update the fork choice state in the execution client (finalized and head payload hash). This starts the execution payload build process. Returns a `payload_id` that will be used at block building time to get the actual execution payload. It's sent in the slot prior to proposing. It might return a null id if the execution client is still syncing.
305
+
-`get_payload(payload_id)`: returns an `{ExecutionPayload.t(), BlobsBundle.t()}` tuple that started building when `notify_forkchoice_updated` was called with payload attributes.
306
+
-`notify_new_payload(execution_payload, versioned_hashes, parent_beacon_block_root)`: when the execution client gets a new block, it needs to check if the execution payload is valid. This method is used to send that payload for verification. It may return valid, invalid, or syncing, in the case where the execution client is not yet synced.
307
+
308
+
### Deposit contract
309
+
310
+
Each time there's a deposit, a log is included in the execution block that can be read by the consensus layer using the `get_deposit_logs(range)` function for this.
311
+
312
+
Each deposit has the following form:
313
+
314
+
```elixir
315
+
%DepositData {
316
+
# BLS Credentials publicly identifying the validator.
317
+
pubkey:Types.bls_pubkey(),
318
+
# Public address where the stake rewards will be sent.
319
+
withdrawal_credentials:Types.bytes32(),
320
+
# Amount of eth deposited.
321
+
amount:Types.gwei(),
322
+
# Signature over the other fields.
323
+
signature:Types.bls_signature()
324
+
}
325
+
```
326
+
327
+
These deposits are aggregated into a merkle trie where each deposit is a leaf. After aggregation we can obtain:
328
+
329
+
- A `deposit_root`: root of the merkle trie.
330
+
- A `deposit_count`: the amount of deposits that were processed in the execution layer.
331
+
332
+
This aggregation structure is useful to send snapshots cheaply, when performing checkpoint sync. See [EIP-4881](https://eips.ethereum.org/EIPS/eip-4881). It can also be used to send cheap merkle proofs that show a deposit is part of the current deposit set.
333
+
334
+
### Eth 1 voting
335
+
336
+
Validators have a summarized view of the execution chain, stored in a struct called `Eth1Data`:
337
+
338
+
```elixir
339
+
%Eth1Data{
340
+
deposit_root:Types.root(),
341
+
deposit_count:Types.uint64(),
342
+
block_hash:Types.hash32()
343
+
}
344
+
```
345
+
346
+
This is the full process of how this data is included in the consensus state:
347
+
348
+
- There's a voting period each 64 epochs. That is, 2048 slots, almost 7 hours. There's a period change when `rem(next_epoch, epochs_per_eth1_voting_period) == 0`.
349
+
- Each proposer include their view of the chain (`Eth1Data`) in the block they propose (`block.body.eth1_data`). They obtain this data from their own execution client. This is sometimes called their "eth 1 vote".
350
+
- When state transition is performed using that block, the vote is included in the `beacon_state.eth1_data_votes` array, which contains the votes for the whole voting period. If a single `eth1_data_vote` is present in more than half of the period slots, then it's now considered the current `eth1_data`, which means it's assigned as `beacon_state.eth1_data` in that state transition.
351
+
- After an eth1 data vote period finishes, the `beacon_state.eth1_data_votes` are reset (the list is assigned as empty), regardless of there being a winner (new eth 1 data after the period) or not.
352
+
353
+
Everything related to state transition is performed by beacon nodes even if they're not validators, and need no interaction with the execution chain, as they only apply blocks to states as a pure function.
354
+
355
+
However, validators that include their view of the execution chain in a block being built, do need access to the latest blocks, as described in the [eth1 data section](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/validator.md#eth1-data) of the validator specs. To summarize:
356
+
357
+
- The consensus node gets blocks from the execution client and builds `Eth1Data` structs.
358
+
- A proposer at a slot `N` will need to build its eth1 vote for the voting period that started at slot `s = div(N, EPOCHS_PER_ETH1_VOTING_PERIOD)`. It will take into account the execution blocks that are `ETH1_FOLLOW_DISTANCE` behind the current voting period.
359
+
- The vote is selected using the following priority:
360
+
- An `eth1_data` that is present in the execution client and also in the beacon state `eth1_data_votes` list. If more than one match, the most frequent will be selected. That ways it tries to match a vote by a different node if present.
361
+
- If no matches are found in the beacon state votes, it will default to the latest eth1 data available in the local execution client (within the expected range).
362
+
- If nothing is found in the execution chain for the expected range, the last default is voting for the current `beacon_state.eth1_data`.
363
+
364
+
## Checkpoint sync
365
+
366
+
**TO DO**: document checkpoint sync.
367
+
354
368
## Next document
355
369
356
370
Let's go over [Fork Choice](fork_choice.md) to see a theoretical explanation of LMD GHOST.
0 commit comments