Skip to content

Conversation

@Giulio2002
Copy link
Contributor

@Giulio2002 Giulio2002 commented Mar 24, 2024

This PR also does the following additional things:

  • Introduces correct JSON marshalling/unmarshalling to all objects
  • BaseFeePerGas marshalled as integer on json caplin-wise
  • Reduced dumpSlotsStates from 32 to 4 for better performance during reorgs
  • Added full lock for OnAttestation

Block Production

This section highlights how GET eth/v3/validator/blocks/{slot} creates a block and then publishes it.

The validator client will do execute 2 steps when producing a beacon block.

  1. Production step: tell the beacon client to create a block and return it.
  2. Publishing step: Sign the block with the proposer private key, and send it back for publishing to other nodes.

Block creation

Let's first look at how block creation happens.

So Caplin needs to do 2 things to successfully create a block:

  1. Asking the Execution Layer for the Execution block
  2. Retrieve Consensus Operations to include in the block (Attestations/VoluntaryExits, etc...)

Execution block

For the execution block, it is quite simple, we ask Erigon to produce us a block through the AssembleBlock function avaiable on the Erigon Eth1 API. We treat erigon as a black box so we do not need to worry too much about this. However, we also need to handle Blob bundles, so that later, when we need to publish a block. we can publish the bundles alongside the block (it is important that peers both receive block and the blob or we will fail a check). (Erigon will also gives us the bundle). Right now, we store the blob bundle in an LRU which has size set to 8 blocks worth of blobs. Note: we use an LRU for the convenient eviction policy.

Operations

TODO.

Operations inclusion has not been implemented yet, the execution block is the only thing being delivered.

Block publishing

After we produce the beacon block, we will send it back to the Validator Client, which will sign it and re-forward it to the rest of the network.

The flow is straightforward, when we receive the block we simply:

  1. pack the block with the blobs the Execution Layer gave caplin during block production
  2. Start a separate thread where we import the block into Caplin's database and forkchoice alongside the blobs..
  3. Publish blobs and blocks to the P2P.

@Giulio2002 Giulio2002 marked this pull request as draft March 24, 2024 15:13
@Giulio2002 Giulio2002 marked this pull request as ready for review March 24, 2024 19:49
@Giulio2002 Giulio2002 requested review from bayram98 and domiwei March 24, 2024 19:49
@Giulio2002
Copy link
Contributor Author

Screenshot 2024-03-24 at 20 52 01

Proof-of-Work

@Giulio2002 Giulio2002 enabled auto-merge (squash) March 24, 2024 21:12
@Giulio2002 Giulio2002 merged commit 0a2ffa0 into devel Mar 25, 2024
@Giulio2002 Giulio2002 deleted the fix-gnosis-fall-sync branch March 25, 2024 11:04
yperbasis pushed a commit that referenced this pull request Mar 27, 2024
This PR also does the following additional things:

* Introduces correct JSON marshalling/unmarshalling to all objects
* BaseFeePerGas marshalled as integer on json caplin-wise
* Reduced dumpSlotsStates from 32 to 4 for better performance during
reorgs
* Added full lock for `OnAttestation`

## Block Production

This section highlights how `GET eth/v3/validator/blocks/{slot}` creates
a block and then publishes it.

The validator client will do execute 2 steps when producing a beacon
block.

1) Production step: tell the beacon client to create a block and return
it.
2) Publishing step: Sign the block with the proposer private key, and
send it back for publishing to other nodes.


### Block creation

Let's first look at how block creation happens.

So Caplin needs to do 2 things to successfully create a block:

1) Asking the Execution Layer for the Execution block
2) Retrieve Consensus Operations to include in the block
(Attestations/VoluntaryExits, etc...)

#### Execution block

For the execution block, it is quite simple, we ask Erigon to produce us
a block through the `AssembleBlock` function avaiable on the Erigon
`Eth1` API. We treat erigon as a black box so we do not need to worry
too much about this. However, we also need to handle **Blob** bundles,
so that later, when we need to publish a block. we can publish the
bundles alongside the block (it is important that peers both receive
block and the blob or we will fail a check). (Erigon will also gives us
the bundle). Right now, we store the blob bundle in an `LRU` which has
size set to 8 blocks worth of blobs. **Note: we use an LRU for the
convenient eviction policy**.

#### Operations

TODO.

Operations inclusion has not been implemented yet, the execution block
is the only thing being delivered.

### Block publishing

After we produce the beacon block, we will send it back to the Validator
Client, which will sign it and re-forward it to the rest of the network.

The flow is straightforward, when we receive the block we simply:
1) pack the block with the blobs the Execution Layer gave caplin during
block production
2) Start a separate thread where we import the block into Caplin's
database and forkchoice alongside the blobs..
3) Publish blobs and blocks to the P2P.
yperbasis added a commit that referenced this pull request Mar 27, 2024
Cherry pick PR #9796 into the release

Co-authored-by: Giulio rebuffo <giulio.rebuffo@gmail.com>
Kakkarrot pushed a commit to covalenthq/erigon that referenced this pull request Apr 17, 2024
Cherry pick PR erigontech#9796 into the release

Co-authored-by: Giulio rebuffo <giulio.rebuffo@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants