Written collaboratively by Phil Kelly and Jack Servia, with thanks to contributors and reviewers from Snickerdoodle Labs.
Until now, the practice and economics of the Web2 browsing environment have inherently compromised privacy through the use of products that monitor user behavior. Browser data is being used to build, centralize, and then sell comprehensive user profiles to administer targeted and retargeted ads and generate leads for vendors.
This is causing consumers to rapidly reject this approach, and Google to start deprecating third-party cookies. Meanwhile, alternative engagement mechanisms based on self-sovereign identities are, after false starts over recent years, finally emerging.
Snickerdoodle Labs (SDL), an O(1) Labs partner, is one of these projects working to address user data concerns and moving beyond outdated cookies. They have designed a system to allow consumers to own their data in a self-custody wallet. When visiting a site, consumers decide whether to share their data and can define situation-specific policies on sharing data entirely or partially, plainly or with obfuscation, and pseudonymously, anonymously, or with open identity. Snickerdoodle Labs is rolling out the first of what may be a bigger set of zk-based capabilities to help with this.
How zk delivers value in the Snickerdoodle solution
Without zk technology, information shared during a browser or native application session today can inherently leak identifying information. This inevitably happens because data points must be shared with a unique identifier so that duplicate responses are not logged and accurate audience segmentation can take place for the purposes of digital marketing and customization. Traditionally this is handled with first- and third-party cookies.
Snickerdoodle Labs has designed a novel protocol implemented in the form of a lightweight client-side software module (called a Data Wallet) and an on-chain consent registry where consumers can opt-in to share information with a specific business or organization. The protocol works as follows:
When a user opens a website or native application powered by Snickerdoodle’s Data Wallet module, they are presented with an opt-in request. If the user accepts, their Data Wallet creates an identity commitment which is cached locally and is also relayed to that business’ consent registry through an arbitrary gas relay. The business can “query” its network of users by broadcasting an instructional event (from their consent registry) to all audience members.
This event is detected and processed by the user’s data wallet client and an appropriate response is sent to a callback location (specified by the business in their query event) with a special zk proof-of-membership (built with o1js) that prevents duplicate responses without linking the user to a persistent unique identifier. The proof-of-membership is generated using the entries in the publicly available consent registry, and the secret nullifier is combined with a hash of the business’ query inside the zero knowledge proof (ZKP) to generate a public nullifier which allows the business to deduplicate responses.
Any information shared from a user’s Data Wallet client is pre-processed to remove all identifying information like wallet addresses or social media handles. Thus, Snickerdoodle powered by o1js provides a production-grade system that can perform audience segmentation and look-alike targeting to as high a degree as legacy data management platforms, but importantly without explicitly tracking individuals around the internet!
This technique can be used for gaining valuable business insight on a user base while preserving user privacy and also underpins dependent activities such as high-quality targeted airdrops of digital assets to boost user engagement while mitigating nefarious “airdrop farming” behavior. Additionally, the zk proof-of-membership module embedded in Snickerdoodle’s Data Wallet client can be trivially coupled with verifiable credentials for a wider variety of business use cases.
The architecture and coding
o1js’ easy-to-use approach allowed Snickerdoodle to go from idea to implementation quickly with most of the scaffold code (out-of-the box code) generated automatically by the zkApp CLI and the heavy lifting accomplished with only three lines of truly custom zk circuit code you see below. And, because their code is TypeScript, it can run in the browser without sacrificing performance or requiring a trusted setup.
The following snippet of code simply verifies that the user has opted into the study, that they haven’t already sent a package of usage data (a signal), and that they haven’t tampered with it:
// we check that the identity is contained in the committed Merkle
Treepath.calculateRoot(identity.leaf()).assertEquals(merkleRoot);
// now we check that the signalNullifier was computed properly to prevent double tapping (order matters)
Poseidon.hash([identity.identityNullifier, epochNullifier]).assertEquals(signalNullifier);
// check that the communicated signal has not been tampered
withsignalHash.mul(signalHash).assertEquals(signalHashSquared);Source: Snickerdoodle’s repo
High-Level Architecture Diagram:
Snickerdoodle shares their experience working with o1js
Among the factors that make developing with o1js a positive experience for Snickerdoodle Labs are:
- Speed of development: High-level, expressive, familiar (TypeScript) language, with a library of pre-built components, such as scaffold and in this case a nullifier. Very little engineering is required.
- Ease of integration into a web app: o1js is written in TypeScript, with benefits in cost, time, and skill requirements.
- Code and documentation quality: Very little debugging required so far.
- Support and partnership: Snickerdoodle Labs found O(1) Labs very supportive as an official partner, with help getting started, demonstrating practical options for applying the technology, and troubleshooting.
- Future potential:
- Recursion will make future, more sophisticated modules very efficient
- Mina allows low-cost verification and persistence of proofs in a readily available, neutral environment to allow credentialing to work anytime, anywhere.
Future Use of zk for Snickerdoodle Labs:
Proof of consent with off-chain verification is just the first step in Snickerdoodle Lab’s adoption of zk. Future innovations could for example include:
- Voluntarily adding credentials to the Snickerdoodle wallet to enrich the profile and the rewards that a user can earn with data permissioning. Credentials can be proven with zkOracles.
- Communicating credentials in a generalized form (e.g., using a range proof to prove to a site I am over 18, but not what my date of birth is). Proofs can be verified and the verifications stored on the Mina protocol, and as self-sovereign user profiles become more comprehensive, users can prove the validity of data or statements about data to third parties, e.g., entering a bar. These “verifiable credentials” can in turn increase the value of the insights generated by the users who own them (because insight buyers may want data that is specific to a particular demographic).
- Allowing users to opt-in to aggregate data sets, with privacy-preserving proofs of the characteristics of the population
- Proving the veracity of generated insights using recursive proofs, possibly even posting them on-chain.
In Conclusion
With the launch of Snickerdoodle’s platform and many other projects on the horizon, it’s an exciting time to be in the zk space. Coupled with opportunities like the recently announced Mina Navigators program and the O(1) Labs Partner Program, developers get support in building zkApplications with o1js. Additionally, with the successful launch of Mina’s Testworld Track 3 last week, we truly are setting the stage for an exciting journey ahead. Finally, we’ll be at ZK Hack in Istanbul next month, so please reach out if you are interested in exploring zkApp use cases with us, we are hungry for use case innovation!