Conversation
|
Hey @BlazeWasHere, this is cool! I would be happy to include this when it's ready. Out of curiosity, what will use these bindings? And another TODO item would be to add CI tests, see: https://github.com/ethereum/c-kzg-4844/tree/main/.github/workflows |
|
@jtraglia no worries, one main user would be elixir_ethers via ExWeb3/elixir_ethers#178. also saw that lambdaclass used c-kzg-4844 in their elixir consensus client but used bindings from c -> rust -> elixir in |
|
Okay nice. So this does have real value. Feel free to ping me if you have any questions. |
|
ok im struggling to find the reason for the segfault in DEBUG=1 iex -S mix test test/ckzg_test.exs:84 -b --trace
# run in shell
> System.pid
# another shell
lldb attach-pid <pid>
# run tests
cthen if you step till segfault and if you check where the location is (in eip4844.c) and the variables passed to Detailsok so it seems like the method is writing to read only data (writing to const region). but by definition C_KZG_RET compute_blob_kzg_proof(
KZGProof *out, const Blob *blob, const Bytes48 *commitment_bytes, const KZGSettings *s
);the only mutable data is in C_KZG_RET ret = compute_blob_kzg_proof(
(KZGProof *)proof, (Blob *)blob.data, (Bytes48 *)commitment.data, settings
);
ERL_NIF_TERM proof_term;
unsigned char *proof = enif_make_new_binary(env, BYTES_PER_PROOF, &proof_term);
if (proof == NULL) return make_error(env, ckzg_atoms.out_of_memory);so im very confused on how the segfault is happening. maybe data misalignment? @jtraglia @alisinabh |
|
Hey @BlazeWasHere, I did some debugging myself and it appears that the issue is related to allocating the very large polynomials on the stack. I suspect we're surpassing the stack limit. I do not know how to raise this in Elixir though. We ran into several stack size issues when developing the Rust bindings too. I've pushed a commit which will dynamically allocate this. With this, it no longer crashes for me. If it's possible to fix this in these bindings somehow, that would be preferred. If not, we look into keeping this core implementation change. Also, I'm working on macOS & when I ran the tests it wanted a But overall, this is looking really great. Thanks for all of your work! |
|
@jtraglia thanks so much, i was going crazy thinking it was something on my end!
will fix this soon, thanks for reporting |
@jtraglia how was this solved? i dont see a stack size increase request |
Our solution there was to c-kzg-4844/bindings/rust/src/bindings/mod.rs Lines 447 to 457 in 8f8a2e5 |
jtraglia
left a comment
There was a problem hiding this comment.
Seriously great work. I have provided some small comments, but I am happy with the current state of this. If you're willing to make some little changes, I'll wait to merge. Otherwise happy to merge whenever. I see no real problems.
thanks for the review, will address changes in the coming days and will add some speedups and better VM interactions in another PR |
|
@jtraglia should i add publishing via CI to hex.pm in this PR or another? i also do not mind being a maintainer of the elixir bindings |
Up to you. But I think a subsequent PR would be better. And thank you! That would help a lot. |
Adds elixir bindings through an Erlang NIF
Was using the python bindings as a reference FFI implementation, not sure if i am missing some things
also not sure if this even cross compiles (i hope :cc_precompiler works)