feat(rln-relay): use batch operations API #617
Conversation
Jenkins BuildsClick to see older builds (28)
|
richard-ramos
force-pushed
the
rln/atomics
branch
3 times, most recently
from
c7ac05a
to
9b6ee32
Compare
richard-ramos
force-pushed
the
rln/atomics
branch
from
9b6ee32
to
7863549
Compare
richard-ramos
force-pushed
the
rln/atomics
branch
from
7863549
to
b96c5b0
Compare
| } | ||
| indexes = append(indexes, event.Index.Uint64()) | ||
| indexes = append(indexes, uint(event.Index.Uint64())) |
There was a problem hiding this comment.
Won't this cause truncation in future if someone uses a 32bit machine and membership set size grows?
There was a problem hiding this comment.
hm. indeed. I'm gonna change go-zerokit-rln to receive uint64 instead of only uints
There was a problem hiding this comment.
nvm. Looking at the implementation in zerokit, the functions that accept indexes receive an uintptr_t value which will depend on the platform architecture...
@rymnc - do you think we should change zerokit's FFI api to use u64 instead of usize for the indexes? what's the maximum number of leaves that a merkle tree can have?
There was a problem hiding this comment.
by default, the tree_height is 20, so 1_048_576
I think we fixed the issue of serialization for usize's 🤔
There was a problem hiding this comment.
indeed, serialization should be fine, but i wonder if in this case (ffi), it would be a problem, as you'd be limited to a maximum index of 2^32-1 in a 32b machine, due to using usize 🤔
There was a problem hiding this comment.
I don't believe we'd cross 2^32 ~ since 2^20 is the max tree height
|
Also , looks like SHA has to be updated for the nix build to be successful. |
richard-ramos
force-pushed
the
rln/atomics
branch
from
b96c5b0
to
2e2a76f
Compare
richard-ramos
force-pushed
the
rln/atomics
branch
from
2e2a76f
to
2b71b1b
Compare
Replace inserting/removing members individually by using batch operations with zerokit's
atomic_write