Farcaster

I’ve come to the conclusion zk interaction with frames is going to be crucial. Particularly when payments are added to frames.

If the fid is known before a price is quoted, then it’s actually quite easy to charge more based on activity.

Many ways, but I can check onchain spending habits and adjust accordingly.

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:

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

Working on building zkTLS infra/products. A ruthless empiricist and meme connoisseur.

/opacity

and

/eulerlagrange

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?

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.

Full-time builder. @pimlico | @33bits | @66bits | farcaster-solidity | x.com/potekhin_sergey. Zero-knowledge and asynchronous transactions evangelist.

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.

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

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

There are a few ways around this but they introduce complexity.

1. Extend semaphore identity commitment for multiple identities (multiple clients)

2. Instead of trapdoor/nullifier, you add a public key. Then each client gets a trapdoor/nullifier signed by the private key

although replay protection is important but this restriction (one key per fid) would mean user cannot use multiple privacy clients at the same time?

also app developers would have to compete for users in a zero sum way which kinda sucks

I’ll write an answer to first question in the morning.

As for the second, each fid can have multiple signers. So associating a semaphore identity to the signer would allow for a fid to have multiple semaphore identities. 

In an anonymous poll, a fid could vote multiple times undetected.