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.

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

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.

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