You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per the changes made in #1394 the structure of the "blob" has been modified such that the first byte in the blob indicates whether or not the following bytes represent the batch in encoded or raw form. Essentially, if blob[0] == 1 then blob[1:] are the zstd-encoded form of the batch bytes, while if blob[0] == 0 then blob[1:] are the raw batch bytes.
This naturally means that batch274 that previously used to produce an exactly full blob post-encoding will now be a single byte more than a full blob.
As a result, the test for the "full blob", i.e. len(blob_bytes) == 4096*31 was disabled. Refer:
// TODO: enable this once we have another deterministic case of batch -> blob (fully
// packed).
// First blob is purposely constructed to take full blob space
// if idx == 0 {
// let blob_data_bytes_len = batch_data.get_blob_data_bytes().len();
// assert_eq!(
// blob_data_bytes_len, N_BLOB_BYTES,
// "should be full blob: expected={N_BLOB_BYTES}, got={blob_data_bytes_len}",
// );
// }
What to do
We need to use a batch that basically encodes to just 1 byte less than "full blob" so that after prepending the first byte (enable_encoding = 1) we arrive at a "full blob".
We could modify batch274 slightly such that in its encoded form, we have 4096*31 - 1 bytes. It is not trivial because as soon as we change any single byte, the encoder may perform much better or much poorer, resulting in either less or more bytes than required.
After we have found a batch that satisfies "full blob" criteria, we should enable the commented out code.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Describe the feature you would like
Background
As per the changes made in #1394 the structure of the "blob" has been modified such that the first byte in the blob indicates whether or not the following bytes represent the batch in encoded or raw form. Essentially, if
blob[0] == 1
thenblob[1:]
are the zstd-encoded form of thebatch
bytes, while ifblob[0] == 0
thenblob[1:]
are the rawbatch
bytes.This naturally means that
batch274
that previously used to produce an exactly full blob post-encoding will now be a single byte more than a full blob.As a result, the test for the "full blob", i.e.
len(blob_bytes) == 4096*31
was disabled. Refer:zkevm-circuits/aggregator/src/tests/blob.rs
Lines 275 to 285 in 0b9ff11
zkevm-circuits/aggregator/src/tests/blob.rs
Line 308 in 0b9ff11
zkevm-circuits/aggregator/src/tests/blob.rs
Lines 322 to 331 in 0b9ff11
What to do
We need to use a batch that basically encodes to just 1 byte less than "full blob" so that after prepending the first byte (
enable_encoding = 1
) we arrive at a "full blob".We could modify
batch274
slightly such that in its encoded form, we have4096*31 - 1
bytes. It is not trivial because as soon as we change any single byte, the encoder may perform much better or much poorer, resulting in either less or more bytes than required.After we have found a batch that satisfies "full blob" criteria, we should enable the commented out code.
Additional context
No response
The text was updated successfully, but these errors were encountered: