Add EIP-7594 (PeerDAS) related changes

[0x00101010]

Summary

Introduces updates to rpc and engine API definitions for EIP-7594, changes defined in ethereum/EIPs#9378

• Adjusts schemas for blob transactions (blob.yaml) and references to ensure consistency across all updated files.
• Added osaka.md to describe api changes

Notes for reviewers

This PR introduces backward incompatible changes to engine_getPayloadV4, that returns new BlobsBundleV2 with cell proofs instead of blob proofs

[ImTei]

I’ve added a few suggestions to slightly improve readability and clarity—mostly minor points for precision. None of them are strictly necessary, so please feel free to accept or ignore them based on your preference!

[g11tech]

i am not sure what the relevance of this method is in peerdas unless this is meant to provide support for distributed block building https://notes.ethereum.org/@dankrad/BkJMU8d0R in which case the request/response format will fully change

[fradamt]

Why would it change?

[g11tech]

if EL dosen't has all the blobs this is not useful or may be am I missing something? in distributed block building scenario the mempools will only sync their custody columns and there won't be a blob to return

so this api would essentially change towards fetching the column custodies from the EL

[fradamt]

Those are ideas for the future, we are not going to be sharding the mempool in Fusaka.

[g11tech]

right, then this will be useful only if we get all blobs from the EL if my understanding is correct?

[0x00101010]

That is correct, and it could be used to do distributed blob publishing, happen on nodes who have all the blobs available locally

[Rjected]

have a question / request for clarification on the eth_sendRawTransaction semantics

[Rjected]

Suggested change

	- [BlobsBundleV1](#blobsbundlev1)
	- [BlobAndProofV1](#blobandproofv1)
	- [BlobsBundleV2](#blobsbundlev2)
	- [BlobAndProofV2](#blobandproofv2)

[0x00101010]

This is where the latest change is, the idea is not to bump the version of BlobsBundle and BlobAndProof message, just directly adding a new field to it, it could help simplify implementation quite a bit, and also more adhering to idiomatic protobuf conventions.

I'm working on related beacon-APIs, builder-specs changes along with example PR (both on prysm / geth) side to showcase this.

Let me know if you think otherwise (we should do it like before with new message version)

[Rjected]

This is where the latest change is, the idea is not to bump the version of BlobsBundle and BlobAndProof message, just directly adding a new field to it, it could help simplify implementation quite a bit, and also more adhering to idiomatic protobuf conventions.

I see, it's not clear to me that this makes anything simpler, it seems like bumping a version is trivial, do you mind expanding on why this would be simpler? Is there an implementation that's made complex as a result of this?

[Rjected]

ah I see, this suggests not even adding a new method

engine_getPayloadV4

This might be fine then

[0x00101010]

Yeah, not only does this simplify EL side, also on CL side it avoids quite a lot of new APIs catered just to a new BlobsBundle / BlobAndProof V2 with an additional field, same applies to builder side as well

[jimmygchen]

Agree with @g11tech. I think version bump is a bit cleaner (from the CL side) than having an extra field that's always going to be empty from Fulu.

[jimmygchen]

How do people feel about keeping the same field name (proofs), but bumping the API version?

From the CL side, I feel like we could potentially get the best of both worlds with this - easy validations, while keeping the structure unchanged. Separately, we also have a BlobsBundle in the Builder API, which is currently identical to this, and we could keep the SSZ encoding unchanged if the field remains the same (max length of list does not affect SSZ encoding).

[hangleang]

IMO, I prefer bump the version. instead of modify and/or add fields to existing types.

[rkrasiuk]

strong preference on bumping the API versions

[Rjected]

After thinking about it, also much prefer the bump, since semantics are changing.