Interface changes to free the blobs #123
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
asn-d6
force-pushed
the
amortized_verification
branch
from
7cb5338
to
4d6bdd6
Compare
jtraglia
changed the title
|
The bindings have been updated to support the new interface. Additionally, I updated the benchmarks for Go/Rust/Java to reflect these changes. Didn't really do much with the tests; updated what I could but removed/commented out lots of them. I would like to focus on tests in a future PR, as this one is already quite big. If it compiles it should be fine, right? |
src/c_kzg_4844.c
Outdated
| /* Forward function definition */ | ||
| static void compute_powers(fr_t *out, fr_t *x, uint64_t n); | ||
| /* Input size to the Fiat-Shamir challenge computation */ | ||
| #define CHALLENGE_INPUT_SIZE 32 + BYTES_PER_BLOB + 48 |
There was a problem hiding this comment.
Would static const int be better here? or even enum?
There was a problem hiding this comment.
Hmm. I think it's standard (and reasonable) practice to have public constants as #defines. We do the same thing for BYTES_PER_COMMITMENT etc.
I don't see a clear benefit to making it static const int, and I'm not sure how we would use an enum.
There was a problem hiding this comment.
Some thoughts on the benefits can be found here https://stackoverflow.com/questions/1674032/static-const-vs-define-vs-enum. In this case I was thinking of it primarily because we're doing arithmetic (+) unlike BYTES_PER_COMMITMENT which is a bare integer literal. (BYTES_PER_BLOB however would face the same argument.) We count on the compiler to constant fold this arithmetic when using macros.
There was a problem hiding this comment.
No strong opinion here. I will defer to @jtraglia .
There was a problem hiding this comment.
yeah to be clear I don't really have a strong opinion either.
There was a problem hiding this comment.
No strong opinion either, but I'm leaning towards a static const. In my opinion it's safer. If you decide to stick with a macro, you should wrap it in parentheses in-case it's every used in a multiplication/division operation. This was a problem with BYTES_PER_BLOB at one point in time.
There was a problem hiding this comment.
ACK! Fixed in 5353434 .
|
I'm happy with the changes to |
jtraglia
force-pushed
the
amortized_verification
branch
from
132f10b
to
621d854
Compare
|
lgtm! |
This PR implements the specs changes from this PR: