New work out! We (royally) show that Fiat-Shamir transformation is insecure for a class of proof systems for *generated* relations (including variants of commonly deployed protocols for R1CS).
A thread to explain where this applies
https://t.co/lm8jKYg84q
Neoclouds have limited cybersecurity. Next time agents successfully go rouge, they'll try taking over a neocloud to run more copies. This is bad.
Thus: neoclouds should greatly strengthen their cybersecurity and every company with strong cyber models should help with that.
here’s one trick you can use if it is suitable for your case:
- instead of inserting leaves into tree immediately you queue those leaves onchain
- only after a certain size of queue, say batch size of x, you accumulate that batch into the tree
- but the catch is you don’t accumulate batch of leaves by classical insertion method/algo
- instead you produce a zk proof that attests that in a merkle tree which is at state s1, when inserted a batch x of leaves, goes into state s2
(state s here being the root of tree)
choose a batch size x such that:
Cost(verify_batch_insert(..)) < x * Cost(insert(..))
@luhelminger i think public reputation should only reveal tier (low/mid/high) at max - if at all
exact score must be private - attestation via zkp should be more than enough for most apps
this is amazing!!
although imo most latency in shielded pool apps come from: fetching leaves/commitments to construct tree & discovering notes. both worsen with increasing no. of tx to the pool.
former can be solved by syncing full tree state in a suitable db coupled with an ohttp api
for latter i think zcash’s tachyon efforts are worth looking over :)