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

Update HeaderWithProof with latest spec changes #1672

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

njgheorghita
Copy link
Collaborator

@njgheorghita njgheorghita commented Feb 7, 2025

What was wrong?

Specs have been updated to the HeaderWithProof type

  • Removing the None type for the proof
  • Removes the ssz union

How was it fixed?

  • Updated the HeaderWithProof type
  • Renamed PreMergeAccumulatorProof -> HistoricalHashesAccumulatorProof to better match the specs
  • I tested these locally against the test vectors in Update the header_with_proof test vectors after SSZ Union removal portal-spec-tests#34 but this pr will have failing tests until that is merged
  • portal-bridge / some test utils have a temporary invalid proof. The next step is to update the bridge to generate valid proofs, but I didn't want to combine these two prs otherwise it would get pretty large. Next, I'll work on updating the bridge and then update all the invalid proofs to be valid

To-Do

@njgheorghita njgheorghita marked this pull request as ready for review February 7, 2025 21:54
@njgheorghita njgheorghita requested review from KolbyML, morph-dev and ogenev and removed request for KolbyML February 7, 2025 21:54
@njgheorghita
Copy link
Collaborator Author

Ready for an intial review on this pr. The failing tests pass locally when I use ethereum/portal-spec-tests#34 as a source for test vectors. But I'm happy to wait until that's merged to merge this one through

@KolbyML
Copy link
Member

KolbyML commented Feb 7, 2025

  • portal-bridge / some test utils have a temporary invalid proof. The next step is to update the bridge to generate valid proofs, but I didn't want to combine these two prs otherwise it would get pretty large. Next, I'll work on updating the bridge and then update all the invalid proofs to be valid

I am not aware of a reason why you would need to but I didn't want to combine these two prs otherwise if you updated the bridge to generate valid proofs first. They could be separate PR's regardless, so I am a little confused by the claim, that this PR was made first so it was possible to make 2 separate PR's. I am fine with this order, I am just a little confused with the wording I guess.

Copy link
Member

@KolbyML KolbyML left a comment

Choose a reason for hiding this comment

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

:shipit: PR looks good. I am a little confused by this statement But I'm happy to wait until that's merged to merge this one through, because I thought it was assumed we wait for CI passing to merge, so the message is making me second guess myself, but I will ignore that feeling.

Copy link
Collaborator

@morph-dev morph-dev left a comment

Choose a reason for hiding this comment

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

Left some high level comments.

I plan to work on top of this PR, and I might suggest some changes if they are blocking my work.

@@ -40,21 +46,26 @@ impl ssz::Encode for HeaderWithProof {
}

#[derive(Debug, Clone, PartialEq, Decode, Encode, Deserialize)]
#[ssz(enum_behaviour = "union")]
#[ssz(enum_behaviour = "transparent")]
Copy link
Collaborator

Choose a reason for hiding this comment

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

We will need both old type (with union and SszNone) until we are done with migration. Otherwise, I won't be able to do the migration (meaning, I won't be able to successfully decode content from the db).

I would also remove Decode from derive, because now that it's no longer union, we can't decode it (we need header timestamp). Technically, this is not accurate as format is different enough (I believe) so that only one would decode correctly. But we shouldn't try to decode this object directly, so better not to implement the trait.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Thinking more about this, I think that old type should remain the same, and the new type should have new name

Copy link
Collaborator

Choose a reason for hiding this comment

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

I checked the spec and it seems that ExecutionBlockProof is different for BlockProofHistoricalRoots and BlockProofHistoricalSummaries, while we still use the some type.

Are all updated specs tests passing? Do we cover all these types in them?

let header: Header = Decodable::decode(&mut header_rlp.as_slice()).map_err(|_| {
ssz::DecodeError::BytesInvalid("Unable to decode bytes into header.".to_string())
})?;

let proof = if header.timestamp <= MERGE_TIMESTAMP {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should this be <= or <? At least intuitively for me, MERGE_TIMESTAMP should be the timestamp of the first post-merge block (but I don't know if that's try in practice).

Either way, I think we should have tests to cover these corner cases, meaning have a test case for the last pre-merge and first post-merge blocks (also shanghai)

HistoricalRootsBlockProof(HistoricalRootsBlockProof),
HistoricalSummariesBlockProof(HistoricalSummariesBlockProof),
}

#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
pub struct PreMergeAccumulatorProof {
pub struct HistoricalHashesAccumulatorProof {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not strictly part of this PR, but can't we replace this structure with:

pub type HistoricalHashesAccumulatorProof = FixedVector<B256, typenum::U15>;

@morph-dev
Copy link
Collaborator

I applied some of my suggestions in my local work:
njgheorghita/trin@hwp-remove-none...morph-dev:pr/1672

It's not polished at all, so feel free to take a look and take some or all of it. A lot of the changes are refactoring not really related to this PR/work (I might extract them into separate PR if I get to it.

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