EIP4844: Update cryptography API and Fiat-Shamir logic#3038
EIP4844: Update cryptography API and Fiat-Shamir logic#3038asn-d6 merged 35 commits intoethereum:devfrom
Conversation
Co-authored-by: Kevaundray Wedderburn <[email protected]>
Co-authored-by: Kevaundray Wedderburn <[email protected]>
Co-authored-by: Kevaundray Wedderburn <[email protected]>
Co-authored-by: Kevaundray Wedderburn <[email protected]>
|
Closes #3026 |
djrtwo
left a comment
There was a problem hiding this comment.
Good separation of concerns 👍
can you give more on the debate over ssz vs domain separators vs neither?
Currently we all agree to remove ssz from the Fiat-Shamir function as this allows for client teams to not implement any of the cryptography. The debate is on whether these separator labels that we append just before we add a serialised point or field element or polynomial into the bytes array, add any extra security vs having no label at all. The argument for having them is that you want a precise mapping from your higher level objects to the bytes array. For example, if I was adding a point into the byte array, I could simply serialise the point as 48 bytes then append onto the byte array, or I could first append a label "POINT" and then add the 48 bytes. In this way, the byte array also encodes the types. Although this seems like a reasonable thing to do, there is no strong rationale as to whether it improves security, and seems to lean on the side of being "extra safe" |
|
As of two minutes ago, I think we now have enough information to come to a conclusion on how to proceed with this |
…pt hash to second Fiat-Shamir stage in eval protocol
The barycentric comment error was found here:
protolambda/go-kzg#25 (comment)
| # Generate random linear combination challenges | ||
| r = hash_to_bls_field(blobs, kzg_commitments) | ||
| r_powers = compute_powers(r, len(kzg_commitments)) | ||
| r2 = int(r_powers[-1]) * r % BLS_MODULUS |
There was a problem hiding this comment.
- Is there any better name than
r2? 😅 You also call the return valuer2in the caller function. - It seems a bit confusing that we use
rfor the result (blob_to_polynomial) and the random number (r2) in this file.
|
|
||
| def retrieve_blobs_sidecar(slot: Slot, beacon_block_root: Root) -> BlobsSidecar: | ||
| pass''' | ||
| return "TEST"''' |
There was a problem hiding this comment.
return type is wrong. how about:
def retrieve_blobs_sidecar(slot: Slot, beacon_block_root: Root) -> Optional[BlobsSidecar]:
return None # Testing'''There was a problem hiding this comment.
Hmm, slightly annoying because None could also mean that the sidecar is not available (I know in python we would do this by raising an exception but not all languages would have that available).
|
|
||
| | Name | Value | | ||
| | - | - | | ||
| | `BYTES_PER_FIELD_ELEMENT` | `uint64(32)` | |
There was a problem hiding this comment.
Does bytes_to_bls_field function make BYTES_PER_FIELD_ELEMENT must be 32?
There was a problem hiding this comment.
Hmm, not sure exactly what you mean here. BYTES_PER_FIELD_ELEMENT being 32 is essentially a parameter of the BLS field we are using.
There was a problem hiding this comment.
my 2c.
I think the point is that if you specify BYTES_PER_FIELD_ELEMENT as a preset, you should expect different values to be potentially configured. But thebytes_to_bls_field only works if BYTES_PER_FIELD_ELEMENT is strictly 32.
So I see two options:
BYTES_PER_FIELD_ELEMENTbecomes a constant- generalize
bytes_to_bls_field
There was a problem hiding this comment.
my 2c. I think the point is that if you specify
BYTES_PER_FIELD_ELEMENTas a preset, you should expect different values to be potentially configured. But thebytes_to_bls_fieldonly works ifBYTES_PER_FIELD_ELEMENTis strictly 32. So I see two options:1. `BYTES_PER_FIELD_ELEMENT` becomes a constant 2. generalize `bytes_to_bls_field`
Ah, that makes sense! Thanks!
Seems like BYTES_PER_FIELD_ELEMENT was added as a preset in cbc170b, but I agree that it's not really a configurable value. Maybe it was done as a quick way to fix the tests if I read the commit correctly.
I mean like in theory we could encode field elements in 64 bytes or whatever, but I don't see why we would ever do that.
I think it's a good idea to leave it as a constant (which it already seems to be in polynomial-commitments.md).
| #### `evaluate_polynomial_in_evaluation_form` | ||
|
|
||
| ```python | ||
| def evaluate_polynomial_in_evaluation_form(polynomial: Polynomial, |
There was a problem hiding this comment.
[not-strong suggestion] Since Polynomial is defined as "a polynomial in evaluation form", I think you can make this function name shorter, e.g., evaluate_polynomial or evaluate_polynomial_at_point.
There was a problem hiding this comment.
No strong opinion either. Inertia won and I left it as is.
|
Where is |
|
Merged! Thanks everyone! |
This PR does a few things with the cryptography of EIP-4844.
Most importantly, it changes the public API of the KZG library to the following high-level API:
compared to the old much more low-level API:
This means that all the cryptographic logic (including Fiat-Shamir) is now isolated and hidden in the KZG library and the
validator.mdfile ends up being significantly simplified, only calling high-level KZG functions.Some additional things that this PR does:
Future TODO tasks:
test_validator.pythat tests the high-level API