Skip to content

Erigon-CL tracking #5965

@Giulio2002

Description

@Giulio2002

Erigon embedded validator client

Objective: Embedd a Eth2 Consensus Layer into Erigon and enabling embedded validators without having to run any validator client and consensus client alongside it.

Main Milestones:

  • Embedded consensus full client security.
  • Embedded validator client within the former.

Full-Client Sync Protocol

1) Checkpoint sync

Erigon already uses checkpoint sync by default from the lightclient, the only difference is that the state is not discarded it is stored in the Database.

2) First sync download

First Sync is going to be exactly lightclient sync, this is to allow us to immediately verify the block before the head. once that is done we can use the ParentRoot of that block to reverse-sync download the missing blocks that separates the fetched state from the head of the chain. This allows us to sync up any number of blocks by doing only 1 BLS verification (which is the main bottleneck). Basically by having a block verified that close to the head, will allow us to to just download all blocks by just checking that the parent root of the successive block is equal to the root of the current block and so on, until we reconnect with the state.

3) First sync processing

process each block in order by slot against our state once we reconnected it to the state we have.

4) Sync

If we are close enough we can just sync each block one by one, by just requesting future slots and process them against our state.

Then rinse and repeat.

Here is a schematic on how to do the Sync:

Validator section TBD.

Progress tracking

  • Full Request protocol implemented.
  • Full Gossip subscription and propagation implemented.
  • Full Response protocol implemented.
  • BLS utilities.
  • Automatic Checkpoint Sync.
  • Sync up algorithm to current slot.
  • State transition function
    • Process functions.
    • BLS Signature verification.
    • Block collector during gossiping/requesting.
  • Database model (mostly unsure about most of it)
    • States stored at finalized checkpoints.
    • Store signed block for Resp protocol but discard when db gets too large.
  • Keystore for validators (Still too unsure)
  • Embedded Validator (Still too unsure)
  • Extra: Separation of DiscV5

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions