Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Devnet6 #4404

Merged
merged 165 commits into from
Jun 29, 2023
Merged

Devnet6 #4404

merged 165 commits into from
Jun 29, 2023

Conversation

realbigsean
Copy link
Member

Issue Addressed

Which issue # does this PR address?

Proposed Changes

Please list or describe the changes introduced by this PR.

Additional Info

Please provide any additional information. For example, future considerations
or information useful for reviewers.

realbigsean and others added 30 commits March 28, 2023 18:29
if self.blocks.contains_key(&block.block_hash()) {
return Err(format!("{:?} is already known", block.block_hash()));
} else if block.parent_hash() != ExecutionBlockHash::zero()
if block.parent_hash() != ExecutionBlockHash::zero()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rejecting duplicates ends up being a big a pain in tests if we re-use a mock el between test beacon chains for example

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth adding a comment here just in case we add another test in the future that requires rejecting duplicates?

@@ -410,8 +405,7 @@ impl<T: EthSpec> ExecutionBlockGenerator<T> {
}

pub fn get_blobs_bundle(&mut self, id: &PayloadId) -> Option<BlobsBundleV1<T>> {
// remove it to free memory
self.blobs_bundles.remove(id)
self.blobs_bundles.get(id).cloned()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also ended up causing issues, I'm not sure it's worth saving the memory in our tests, but maybe in other tools that may use this? not sure

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is fine. Pinging @ethDreamer since he wrote this part initially

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is fine. Pinging @ethDreamer since he wrote this part initially

rand::thread_rng().fill_bytes(&mut blob_bytes);
// Ensure that the blob is canonical by ensuring that
// each field element contained in the blob is < BLS_MODULUS
for i in 0..FIELD_ELEMENTS_PER_BLOB {
blob_bytes[i * BYTES_PER_FIELD_ELEMENT + BYTES_PER_FIELD_ELEMENT - 1] = 0;
for i in 0..T::Kzg::FIELD_ELEMENTS_PER_BLOB {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The blob endianness switch necessitated this

Copy link
Member

@pawanjay176 pawanjay176 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good 🚀 Just a couple of questions

@@ -16,10 +16,11 @@ serde_derive = "1.0.116"
ethereum_serde_utils = "0.5.0"
hex = "0.4.2"
ethereum_hashing = "1.0.0-beta.2"
c-kzg = {git = "https://github.com/ethereum/c-kzg-4844", rev = "fd24cf8e1e2f09a96b4e62a595b4e49f046ce6cf" }
c-kzg = { git = "https://github.com/michaelsproul/c-kzg-4844", rev = "9c47e976fe1133148742866c0ad10568ce182950" , features = ["mainnet-spec"]}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can point this to the main repo now since Michael's PR got merged

@@ -93,6 +94,16 @@ impl<T: EthSpec> BlobSidecar<T> {
Self::default()
}

pub fn random<R: Rng>(rng: &mut R) -> Self {
let mut blob_bytes = Vec::with_capacity(T::Kzg::BYTES_PER_BLOB);
rng.fill_bytes(&mut blob_bytes);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could end up being an invalid blob. You would need to do something like this
https://github.com/ethereum/c-kzg-4844/blob/main/bindings/rust/src/bindings/mod.rs#L544C5-L553C6

@@ -93,6 +94,16 @@ impl<T: EthSpec> BlobSidecar<T> {
Self::default()
}

pub fn random<R: Rng>(rng: &mut R) -> Self {
let mut blob_bytes = Vec::with_capacity(T::Kzg::BYTES_PER_BLOB);
rng.fill_bytes(&mut blob_bytes);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could end up being an invalid blob. You would need to do something like this
https://github.com/ethereum/c-kzg-4844/blob/main/bindings/rust/src/bindings/mod.rs#L544C5-L553C6

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good shout!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realized the test where I'm using this doesn't interpret blob bytes at all, so I'm opting to just use BlobSidecar::default there since the blob size is fixed. I did a litter refactor here to make the code you linked a bit more accessible to anyone trying to test with random valid blobs.

beacon_node/beacon_chain/src/kzg_utils.rs Show resolved Hide resolved
let shanghai_time = spec.capella_fork_epoch.map(|epoch| {
HARNESS_GENESIS_TIME + spec.seconds_per_slot * T::slots_per_epoch() * epoch.as_u64()
});
let deneb_time = spec.deneb_fork_epoch.map(|epoch| {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little pedantic here, but should this be cancun?

@@ -410,8 +405,7 @@ impl<T: EthSpec> ExecutionBlockGenerator<T> {
}

pub fn get_blobs_bundle(&mut self, id: &PayloadId) -> Option<BlobsBundleV1<T>> {
// remove it to free memory
self.blobs_bundles.remove(id)
self.blobs_bundles.get(id).cloned()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is fine. Pinging @ethDreamer since he wrote this part initially

if self.blocks.contains_key(&block.block_hash()) {
return Err(format!("{:?} is already known", block.block_hash()));
} else if block.parent_hash() != ExecutionBlockHash::zero()
if block.parent_hash() != ExecutionBlockHash::zero()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth adding a comment here just in case we add another test in the future that requires rejecting duplicates?

snapshot_cache.get_cloned(block_parent_root, CloneConfig::committee_caches_only())
})
{
if snapshot.beacon_state.slot() == blob_slot {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering why we need to clone the state if we don't need to advance it in this case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling get_state_for_block_processing evicts the state from the snapshot cache which we don't want because we want to use the same state for block and all blob verification. This is actually making me realize we want to make sure we aren't evicting the state during block processing or we will always get cache misses here 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tree states would end up making this a lot simpler... i'm not really sure how we should be handling this here..

.get_beacon_proposer_index(blob_slot, &chain.spec)?,
snapshot.beacon_state.fork(),
)
if let Some(mut snapshot) = chain
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trying to understand why the snapshot_cache is better than the cacnonical head in this case. Is it because it has less lock contention?
P.S. I don't remember why I used the cached_head in the first place 😂

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we need to make sure we are getting shuffling based on the parent state of this blob we're verifying, and our cached head might not be the one this blob builds on, but we still need to verify it. So we could use the cached head and fall back to the snapshot cache if the cached head isn't what the blob builds on but I figured this was simpler.

&chain.spec,
)?;
(
state.get_beacon_proposer_index(blob_slot, &chain.spec)?,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we prime the proposer cache here as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we should... I'm wondering if we should separate this state-loading issue into a new task/pr.. what's here should work but is probably pretty suboptimal in practice. I'm not sure we should block merging this on this

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good.

Copy link
Member

@pawanjay176 pawanjay176 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to merge this and handle the blob states loading in another PR

@realbigsean
Copy link
Member Author

Thanks for the review @pawanjay176 !

@realbigsean realbigsean merged commit adbb62f into sigp:deneb-free-blobs Jun 29, 2023
4 of 29 checks passed
@realbigsean realbigsean mentioned this pull request Jun 29, 2023
8 tasks
@realbigsean realbigsean deleted the devnet6 branch November 21, 2023 16:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants