We are very interested in a new set of HaLo chips that produce and store ZK-friendly signatures. This means introducing curves and operations that can be efficiently verified inside of a circuit.

Operations

The following operations would enable a new set of applications, starting with a successor to the original Zupass Stamps. We would also like to extend the capabilities of the cards to Semaphore-like identity managers as a replacement for something like zupass.org or a chrome extension, with applications to private voting and speech,. Finally, we are interested in E2E encrypted applications using ECDH operations that are more difficult to do with existing Ethereum wallets & identities. These are sorted in order of importance, with ZK-friendly curves being an order of magnitude more important/crucial than the others:

1. ZK-friendly curves

   • If the signatures from the card are being produced using ZK-friendly curves, it is much less computationally expensive to produce the following proofs + verify on EVM, which has a bn254 precompile
     • Proof of valid signature ownership from a specific chip’s public key
       • Can use Groth16 from snarkjs or halo2-kzg from PSE
     • Recursive proof that counts the number of signatures a user has
       • Would likely use a folding scheme like Nova instantiated over the Grumpkin/bn254 cycle
   • Candidates for curves, we need one whose group order is the same as the field order of bn254
     • Grumpkin, a curve that forms a cycle with bn254
     • Baby jub jub, a curve created for this purpose

2. Additional chip storage to write to

   • Want users to be able to store stamps they collect in a NFC chip, likely in the form factor of a bracelet or a necklace
     • Doesn’t need to be the same chip that produces ZK-friendly signatures
   • Avoids the need for encryption keys and storing on a server or decentralized storage
     • Currently, we are able use the write_latch command to back up a user’s encryption key to an NFC chip, which is honestly not a bad solution
   • User flow
     • Adding a stamp
       • User collects stamp on their phone from a passive NFC card
       • User is then prompted to add this stamp to their bracelet
       • Tap their phone to the bracelet, where it is stored
     • Viewing their stamps
       • Tap the bracelet to phone
       • View a display with all the different stamps on the card
       • Can view at any point, not only if they are logged in to some other account
       • Can view many years later with an NFC enabled device to see mementos!

3. No hashing of digest or ZK-friendly hash function

   • If the incrementing nonce concatenated with the RNG number in sign_random is signed either directly (i.e. no additional hashing) or with a ZK-friendly hash function, we can verify the nonce inside of the circuit
     • Otherwise need to do the SHA256 hash outside the circuit, in a contract or in separate code
     • Nice to keep the entire verification inside the zkSNARK to avoid additional verification work
   • Candidates for ZK-friendly hash functions
     • Poseidon

4. Generate the artifacts that PLUME needs using ZK-friendly curve

   • If done with ZK-friendly curve, can build a full Semaphore-like identity system
     • Also comes with signatures for free, which are more computationally intensive to create with Semaphore identities
   • Involves generating the various elliptic curve points necessary in for the PLUME nullifier to create a deterministic signature
   • Card can hold the identity, with which you can do different actions
     • Private voting on a ballot (akin to https://zupoll.org, built by me!)
       • Fill out your selection of votes on each poll
       • Tap your NFC card against your device to create the necessary PLUME artifacts for your
     • Private speech
       • Tap your card against device to login

5. Computing ECDH on ZK-friendly curve to allow for E2E encryption from your card

   • Using something like ERC-5360, allow users to generate an ECDH shared secret for decrypting and encrypting messages from the identity they have in a card
   • Using a ZK-friendly curve, we can efficiently verify that encryption was done correctly with a zkSNARK, thus avoiding the “junk encryption” problem
     • Otherwise you don’t have guarantees a real message was encrypted to your public key when someone sends you something
     • Can waste a lot of computational effort if spammed
   • For gated anonymous private messaging, can verify that the ephemeral key used in ECIES was generated by someone in a specific group like “Zuzalu residents” all within a zkSNARK
   • This is currently very hard to build with Ethereum wallets and identities; for example MetaMask deprecated this API access

Open questions

These questions are also sorted in order of importance; the earlier questions are more time sensitive than the later ones!

1. How soon can we get confirmation that we can produce chips using ZK-friendly curves? Or any of the other operations?

   • What sorts of costs will be incurred in determining this?
   • How much more expensive will the chips be?
   • How long before we can mass produce them on the scale of a conference?

2. In what ways could this collaborate/overlap with goals of arx.org?

   • From my understanding, arx.org is involved with some experiments around network states; this tech could definitely be used to enhance those projects as well!

3. What other form factors can we produce the chips in?

   • Aware of credit card and circular tag form factor
   • Interested in bracelet form factors, akin to an Apple watch where there’s one main technical element and a strap that connects to top and bottom
   • Also interested in necklace form factors

4. Is there any way to add security to an on-chip storage?

   • For example, making it so that only one phone can read the raw signatures or write to the chip so other people can’t steal or override the storage