EIP4844: Refactor verify_kzg_proof() to receive bytes (used in precompile)

[asn-d6]

We received reports by client devs that the precompile was annoying to implement because of the modular reductions that had to be done outside of the crypto layer.

This PR makes verify_kzg_proof() bit more high-level so that client devs can interact with it by just passing bytes to it.

Note: Client devs still have to check the assert kzg_to_versioned_hash(data_kzg) == versioned_hash when implementing the precompile.

[roberto-bayardo]

I assume there will be a sister change for the EIP-4844 itself which still has the precompile function doing the conversion to field element?

FWIW, one could just put PointEvaluationPrecompile itself in the kzg library for all clients to share (which was what I was doing in our geth fork), as it already has a bytes api:

def point_evaluation_precompile(input: Bytes) -> Bytes:

But this change still makes sense if one wants to separate the EL and CL concerns of 4844.

Our EIP-4844 Golang bytes-api implementation from geth which is also by our Prysm fork can be found below. It's a work in progress but feedback is welcome. I've updated it to incorporate the changes proposed here.

https://github.com/mdehoog/go-ethereum/tree/more-kzg-2/crypto/kzg

[asn-d6]

I assume there will be a sister change for the EIP-4844 itself which still has the precompile function doing the conversion to field element?

Yep, for sure we also need to update the EIP!

Afte we stabilize the crypto API again on the consensus-specs side (pretty much just this ticket and #3093 remaining) we will sync up the EIP.

FWIW, one could just put PointEvaluationPrecompile itself in the kzg library for all clients to share (which was what I was doing in our geth fork), as it already has a bytes api:

Yep, that's another reasonable approach. No strong opinion here. Whatever is easier for client devs. Let's raise it on the next call?