status-im/nimbus-eth2
2
0
Fork 0
mirror of https://github.com/status-im/nimbus-eth2.git synced 2025-01-10 14:26:26 +00:00
Code Issues Projects Releases Wiki Activity
nimbus-eth2/beacon_chain/consensus_object_pools
History
zah 8771e91d53
Support for driving multiple EL nodes from a single Nimbus BN (#4465) 
* Support for driving multiple EL nodes from a single Nimbus BN

Full list of changes:

* Eth1Monitor has been renamed to ELManager to match its current
  responsibilities better.

* The ELManager is no longer optional in the code (it won't have
  a nil value under any circumstances).

* The support for subscribing for headers was removed as it only
  worked with WebSockets and contributed significant complexity
  while bringing only a very minor advantage.

* The `--web3-url` parameter has been deprecated in favor of a
  new `--el` parameter. The new parameter has a reasonable default
  value and supports specifying a different JWT for each connection.
  Each connection can also be configured with a different set of
  responsibilities (e.g. download deposits, validate blocks and/or
  produce blocks). On the command-line, these properties can be
  configured through URL properties stored in the #anchor part of
  the URL. In TOML files, they come with a very natural syntax
  (althrough the URL scheme is also supported).

* The previously scattered EL-related state and logic is now moved
  to `eth1_monitor.nim` (this module will be renamed to `el_manager.nim`
  in a follow-up commit). State is assigned properly either to the
  `ELManager` or the to individual `ELConnection` objects where
  appropriate.

  The ELManager executes all Engine API requests against all attached
  EL nodes, in parallel. It compares their results and if there is a
  disagreement regarding the validity of a certain payload, this is
  detected and the beacon node is protected from publishing a block
  with a potential execution layer consensus bug in it.

  The BN provides metrics per EL node for the number of successful or
  failed requests for each type Engine API requests. If an EL node
  goes offline and connectivity is resoted later, we report the
  problem and the remedy in edge-triggered fashion.

* More progress towards implementing Deneb block production in the VC
  and comparing the value of blocks produced by the EL and the builder
  API.

* Adds a Makefile target for the zhejiang testnet
2023-03-05 01:40:21 +00:00
..
vanity_logs
more withdrowls (#4674)
2023-03-02 17:13:35 +01:00
attestation_pool.nim
more eip4844 -> deneb module references (#4690)
2023-03-02 21:09:24 +01:00
block_clearance.nim
rename ConsensusFork.EIP4844 to ConsensusFork.Deneb (#4692)
2023-03-04 13:35:39 +00:00
block_dag.nim
more eip4844 -> deneb changes (#4666)
2023-02-25 03:03:34 +02:00
block_pools_types_light_client.nim
remove Nim 1.2-compatible push raises and update copyright notice years (#4528)
2023-01-20 14:14:37 +00:00
block_pools_types.nim
more eip4844 -> deneb changes (#4666)
2023-02-25 03:03:34 +02:00
block_quarantine.nim
Remove blobsSidecar from orphans table (#4670)
2023-02-27 06:10:22 +00:00
blockchain_dag_light_client.nim
rename most eip4844Data to denebData (#4693)
2023-03-04 22:23:52 +00:00
blockchain_dag.nim
rename ConsensusFork.EIP4844 to ConsensusFork.Deneb (#4692)
2023-03-04 13:35:39 +00:00
consensus_manager.nim
Support for driving multiple EL nodes from a single Nimbus BN (#4465)
2023-03-05 01:40:21 +00:00
exit_pool.nim
batch-verify BLS to execution change messages (#4637)
2023-02-17 13:35:12 +00:00
light_client_pool.nim
remove Nim 1.2-compatible push raises and update copyright notice years (#4528)
2023-01-20 14:14:37 +00:00
README.md
automated update of v1.3.0-rc.2 to v1.3.0-rc.3 consensus spec URLs (#4647)
2023-02-21 16:43:21 +00:00
spec_cache.nim
automated update of v1.3.0-rc.2 to v1.3.0-rc.3 consensus spec URLs (#4647)
2023-02-21 16:43:21 +00:00
sync_committee_msg_pool.nim
automated update of v1.3.0-rc.2 to v1.3.0-rc.3 consensus spec URLs (#4647)
2023-02-21 16:43:21 +00:00

README.md

Consensus object pools

This folder holds the various consensus object pools needed for a blockchain client.

Object in those pools have passed the "gossip validation" filter according to specs:

After "gossip validation" the consensus objects can be rebroadcasted as they are optimistically good, however for internal processing further verification is needed. For blocks, this means verifying state transition and all contained cryptographic signatures (instead of just the proposer signature). For other consensus objects, it is possible that gossip validation is a superset of consensus verification (TODO).

The pools presenet in this folder are:

  • block_pools:
    • block_quarantine: for seemingly valid blocks that are on a fork unknown to us.
    • block_clearance: to verify (state_transition + cryptography) candidate blocks.
    • blockchain_dag: an in-memory direct-acyclic graph of fully validated and verified blockchain candidates with the tail being the last finalized epoch. A block in the DAG MUST be in the fork choice and a block in the fork choice MUST be in the DAG (except for orphans following finalization). On finalization non-empty epoch blocks are stored in the beacon_chain_db.
  • attestation_pool: Handles the attestation received from gossip and collect them for fork choice.
  • exit_pool: Handle voluntary exits and forced exits (attester slashings and proposer slashings)