Content
@
0 reply
20 recasts
20 reactions
MunicipalBondLagrange
@eulerlagrange.eth
Hey everyone, I figured out a fairly simple way to achieve ZK frame interaction. IMO, anon frame use will be very important as the protocol scales. It's also a potential way to break recast to use frame. See: https://warpcast.com/eulerlagrange.eth/0xea60f72d https://github.com/farcasterxyz/protocol/discussions/145
3 replies
6 recasts
34 reactions
Sergey Potekhin
@fastfourier.eth
Can you provide more details about how the Semaphore is used here? Also, there is only one key for each FID which may become a problem considering that we have a decentralized protocol with a variety of clients. What if we associate a new key with a signer instead of an FID?
2 replies
0 recast
0 reaction
MunicipalBondLagrange
@eulerlagrange.eth
The semaphore identity is pretty straightforward. The identity consists of a trapdoor and nullifier (private key), and the key on-chain is just the hash of the two instead of a eddsa public key. To use the identity you do a PoK ZKP. https://docs.semaphore.pse.dev/guides/identities
1 reply
0 recast
1 reaction
MunicipalBondLagrange
@eulerlagrange.eth
Continuing on. Semaphore identity is basically hashing a secret, and “signatures” of the identity is a PoK that you know the secret. The idea is the validator will insert the identity into a sparse merkle tree, so using the semaphore identity is a PoK, inclusion proof, and non-inclusion of revocation
1 reply
0 recast
1 reaction
Sergey Potekhin
@fastfourier.eth
Awesome, thank you for the explanation! I was thinking is there a way to use existing keys instead of adding a new one? By somehow deriving all the properties from the signer Ed key. As I see in the current scheme each user needs to add a new key (=send a transaction), which seems like a lot of friction to me.
1 reply
0 recast
0 reaction
MunicipalBondLagrange
@eulerlagrange.eth
Using existing keys is possible. Simplest approach is to index them into a sparse merkle tree offchain similar to the revocation tree in my proposal. Might still need a new key type for fid replay protection. My concern here is interacting with a frame w/ zk eddsa will be a lot slower and use a lot of power.
1 reply
0 recast
1 reaction
MunicipalBondLagrange
@eulerlagrange.eth
Also, maybe write these comments in the GitHub? Haha so we have it in one place. Open to exploring alternatives. This particular proposal was optimizing for client side proof speed.
2 replies
0 recast
1 reaction
