# Zorro Whitepaper :::warning The Zorro Protocol is still under initial development. This draft reflects current thinking and will be updated without versioning as the protocol is implemented. ::: ## Introduction to Proof of Personhood ### Sybil attacks Many services and protocols suffer from attackers generating many accounts and using them to manipulate votes, extract resources, promulgate disinformation, etc. These are are known as [sybil attacks](https://en.wikipedia.org/wiki/Sybil_attack). To secure themselves against sybil attacks, services would like to have evidence that each of their accounts is backed by a unique person acting under their own volition, i.e., to have some kind of *proof of personhood* for each account. ### Why Proof of Personhood matters Proof of Personhood can enable critical societal infrastructure, for example: - Democratic governance in DAOs - Universal basic income - Quadratic funding of public goods (e.g. Gitcoin) - Fair airdrops - Bot-resistant social media Many DAOs want to govern themselves with the aid of proof of personhood, but they lack good options for doing so and instead rely on [coin voting](https://vitalik.ca/general/2021/08/16/voting3.html) which is plutocratic and [leads to all sorts of problems](https://www.coindesk.com/business/2021/11/11/curve-wars-heat-up-emergency-dao-invoked-after-clear-governance-attack/). More broadly, there are many wonderful services that *don't even exist* because their would-be creators know that they'd just be wrecked by sybils. ### Common misconceptions #### CAPTCHAs Solving a CAPTCHA can prove that a user is a person, but it can't prove that they're a *unique* person (since one person could create many accounts and solve a CAPTCHA for each one). This means it can't be used to e.g. protect a democratic vote. Proof of Personhood aims to offer the stronger guarantee that each account belongs to a unique person. #### Identity Proving personhood does *not* require authenticating someone's identity (official name, etc). Proving personhood only requires showing that someone is *a* unique person, not *which* person they are. ## The Zorro Protocol ### Purpose To date, there hasn't been broad adoption of proof of personhood. This is a loss because proof of personhood allows protocols and services to center more on *people* — on their preferences, their needs, their perspectives. One reason for lackluster adoption of proof of personhood is that many existing solutions are quite demanding, requiring some e.g. a multi-day wait periods, significant funds, attendance of scheduled events, pre-existing connections, or technical knowledge. Protocols and services are reluctant to require such hoops because they anticipate that many people won't be willing (or able) to jump through them. Zorro is an experiment to see if making proof of personhood fast (<5 minutes) and cheap (free) will lead to more adoption. The aim is to increase adoption of proof of personhood quickly, while web3 norms, governance, and culture are still developing. Hopefully, giving naescent institutions the tools they need to focus on people will result in those institutions being more prosocial. If protocols can't count people, people won't count! ### Design goals Registering on Zorro should be: #### Frictionless: - **Free:** for people without much money - **Fast:** for people without much time - **Intuitive:** for people who aren't that technical #### Inclusive: - **Accessible:** to people who speak any language, have a speech disorder, etc - **Non-discriminatory:** not biased by ethnicity, gender, etc - **Pseudonymous:** for people that don't want to be publicly known #### Trustworthy: - **Robust:** sybil attacks should be expensive - **Legible:** it should be clear how things work - **Auditable:** decisions should be visible - **Available:** difficult to halt or censor - **Decentralized:** power should be distributed - **Forkable:** in case the project goes awry In practice, these various goals conflict and it's necessary to make tradeoffs. Zorro's intent is to occupy a pragmatic and pareto-efficient point in the space of possible designs. ### How it works: brief overview :::warning Credit: Zorro's design was greatly inspired by [Proof of Humanity](https://www.proofofhumanity.id/) and the crowdfunding/crowdvouching communities that emerged around it. Zorro is mainly an extension of those ideas. ::: 1. Registrants submit a photo and video of their face to a public registry. (<5 min, costs covered by the protocol) 2. People keep an eye on the registry to make sure there are no duplicates or invalid submissions — if they find one, they can get paid for challenging it successfully. Challenges are ultimately adjudicated by [Kleros](https://kleros.io/). 3. After registering, people can pseudoanonymize themselves to protect their privacy. ### How it works: more detail #### StarkNet The initial implementation of Zorro runs on the Ethereum L2 [StarkNet](https://starknet.io/). StarkNet was chosen because it mostly inherits Ethereum's security while having low transaction fees due to its efficient use of L1 calldata space. Low tx fees are important for sustainably offering registration to people for free, which is a major design goal. #### How registration works Registration can be fast and free to end users thanks to a relay service known as the *protocol notary*. (A trust-minimized fallback is available.) The protocol notary service checks to make sure that a profile is valid and then relays it to the Zorro contract on behalf of the user, paying the tx fee and a temporary security deposit on their behalf. If the notary is out of operation or if a user believes they are being censored, they can opt to submit their own profile, but this requires that they pay their own transaction fee and deposit. Notice that Zorro is 'aspirationally free' — as long as it has eth in its coffers, it won't charge end users — but if the protocol goes broke, it will fall back on charging people. The transaction to submit a profile to Zorro includes the following, which is stored on-chain in StarkNet: - An eth security deposit of `SUBMISSION_DEPOSIT_SIZE` (~$30 of eth to start) - A *public profile* consisting of: - An ethereum address whose private key is controlled by the person - An [IPFS](https://ipfs.io/) `cid` pointing to: - A clear photo of the person's face in which they are facing the camera - A video of the person raising their right hand and proclaiming, "I swear that this is my first time registering on Zorro" After a waiting period of length `PROVISIONAL_PERIOD` (~3 days), whoever submitted the profile can reclaim their security deposit. #### Which profiles are considered verified - Profiles submitted by the protocol notary service have one small advantage: they are considered verified immediately, without a waiting period. (The protocol is designed to degrade gracefully in the event that the notary misbehaves; see 'Attacks' section) - Profiles submitted by other parties are considered verified if they go unchallenged during `PROVISIONAL_PERIOD`. - Any profile (notarized or otherwise) which is challenged early on, *during* its provisional time window, is presumed *unverified* until the challenge is resolved one way or the other. - Any profile which is challenged later than that is presumed verified until the challenge is resolved one way or the other. #### How Zorro excludes sybils: challenges, adjudication, appeals, etc Zorro aims to maintain a robust registry that excludes invalid profiles, duplicate accounts, deepfakes, etc by allowing anyone to *challenge* any profile. Challenges are preliminarily decided in a quick inexpensive way by a semi-trusted protocol actor known as the *adjudicator*. There's a trust-minimized fallback pathway: the adjudicator's decision can be appealed, and the ultimate decision is in the hands of the decentralized court system [Kleros](https://kleros.io/) on Ethereum L1. If the challenge is successful, the challenger will receive back their security deposit and in most cases win an award (See "Settling"). This award incents people to challenge invalid profiles. This diagram illustrates the states that a profile can be in. Transitions between states are described in the subsections immediately following. ```graphviz digraph dg{ graph [ranksep=0.8]; edge [ labeldistance=2.5 labelangle=0 fontsize=8 fontname="Courier New"]; node [ shape=rect fontsize=11 fontname="sans-serif" margin="0.4,0.2"]; start -> not_challenged [ taillabel="submit() "]; not_challenged -> challenged [ taillabel="challenge() "]; challenged -> adjudication_round_complete [ taillabel="adjudicate() "]; challenged -> adjudication_round_complete [ taillabel=" timeout" color=gray fontcolor="gray"] adjudication_round_complete -> appealed [ taillabel="appeal() \nL1->L2 " labeldistance=3]; adjudication_round_complete -> appeal_opportunity_expired [ taillabel=" timeout" labeldistance=3 color=gray fontcolor="gray"]; appealed -> super_adjudication_round_complete [ taillabel="super_adjudicate() L1->L2 "]; super_adjudication_round_complete -> settled [ taillabel="settle() " labeldistance=3.5]; appeal_opportunity_expired -> settled [ taillabel=" settle()" labeldistance=7.8]; settled:e -> challenged:e [ label=" challenge()" constraint=false]; start [shape=diamond margin="0.2,0.1"]; {rank=same; appealed, appeal_opportunity_expired} } ``` ##### Challenging The challenger includes a deposit of `CHALLENGE_DEPOSIT_SIZE`, alongside *evidence* (in the form of an IPFS `cid` pointing to a document, video, etc) which describes why the profile should be excluded. For example, a challenger could posit: - The profile is missing a picture or video - The profile was deepfaked - The profile is a duplicate of a different profile - The profile's private key was leaked - etc ##### Adjudicating After a challenge, a semi-trusted protocol actor known as the *adjudicator* is charged with making a preliminary decision as whether or not the challenge is valid. - Prior to making its decision, the adjudicator may opt to collect additional evidence from the profile owner. - The decision made by the adjudicator determines, for the time-being, whether or not the profile is considered valid. - An IPFS `cid` pointing to evidence in support of the adjudicator's decision is filed along with their decision. The adjudicator is akin to a local circuit court judge — they're nearby (also on StarkNet) and can make a quick determination with low tx fees. These low adjudication tx fees reduce the necessary submission deposit, which makes the protocol more inclusive. ##### Appealing The purpose of appeals is to serve as a check on decisions made by the adjudicator. If anyone thinks the adjudicator decided wrongly *given the information that they had at hand*, they can appeal. If no appeal is made within `APPEAL_PERIOD`, the adjudicator's decision becomes final, and the challenge can be settled (See: "Settling"). Appeals are submitted directly on Ethereum L1 along with a deposit, which creates a [Kleros](https://kleros.io/) court case. The appealant is required to put up a deposit/court fees. Once an appeal has been initiated by the appealant, the Zorro protocol will automatically take the other side of the Kleros dispute (i.e., the Zorro protocol will always act to defend the decisions made by its adjudicator). The Zorro contract inside StarkNet is notified of the appeal via a StarkNet L1->L2 message. ##### Super Adjudicating Kleros on L1 is the protocol *super adjudicator* who is charged with deciding whether the adjudicator made the correct decision. A custom Kleros court arbitration policy indiciates to Kleros jurors how they should make their decision. A full description of Kleros is out of scope, but in brief it implements an economic escalation game: - In the first round, it randomly selects a small number of Kleros jurors from among those who have staked Kleros' token. These jurors make an initial decision - Anyone can appeal the decision, which requires double the deposit, and also results in double the number of jurors being randomly selected. - This process repeats until no one appeals or until *all* Kleros jurors are called to the case. At this point, Kleros jurors have a strong economic incentive to make a decision that maintains the reputation of the Kleros court system. (Poor decisions would drive people away from the court, causing the value of the jurors' tokens to drop.) Super adjudication does not serve to determine the validity of the profile, rather, it serves to determine *whether the adjudicator made the correct decision, given the evidence that was in front of them*. For this reason, the Kleros arbitration policy indicates that no additional evidence should be taken into account during super adjudication. (If additional evidence has arisen that is pertinent to the validity of the profile, then the profile can later be re-challenged with this evidence included.) When the Kleros case resolves, the appealant (or defender) is rewarded on L1, and notice of the result is passed back to StarkNet in an L1->L2 message. ##### Settling Settling a challenge returns any deposits that should be returned, revokes any deposits that should be revoked, and disburses any rewards that should be rewarded. If the challenge was unsuccessful: - The challenger's deposit is swallowed by the protocol and added to the *security bounty pool* (described later) If the challenge was successful: - The challenger's deposit is returned - An additional reward is sent to the challenger: - If the profile was challenged during `PROVISIONAL_PERIOD`, the submission deposit is guaranteed to be present still, and it is revoked from the submitter and sent to the challenger. - If the submission deposit is not present, the challenger's reward is funded from the shared security bounty pool. The purpose of this pool is to ensure there's a reward for challenging old profiles that made it past their provisional period. ##### Re-challenging After a profile is settled, it's possible for anyone to challenge the profile again with new evidence. This isn't a griefing vectoring: - Profiles older than `PROVISIONAL_PERIOD` are 'presumed innocent' after being challenged, that is, they are still considered verified until the adjudicator or super adjudicator speak. - Spurious challenges will just result in the challenger losing their deposit ### How it works: Pseudonymization The goal of pseudonymization is for someone to be able to prove that they are *a* person without revealing *which* person they are. This matters because otherwise all of someone's activity would be linked to a picture/video of their face. #### Short term The initial application of Zorro ([using it in Snapshot voting strategies](https://snapshot.org/#/strategy/zorro)) will offer a limited form of privacy which relies on a third party server. If that server had corrupt operators or was compromised, it would link people's Snapshot votes to their public profiles. #### Medium / long term: in-browser zero knowledge proofs The goal is to allow each user multiple pseudonyms, each for particular purposes. For example, a user might generate one pseodynm for use with Gitcoin and a different pseudonym for use with CityDAO. In brief: - The contract can maintain a merkle tree of all valid profiles inside StarkNet - The user can then generate a proof that they know: - (a) a secret preimage whose hash shows up in one of the profiles, - (b) the merkle path from that profile up to a merkle root which is listed in the on-chain contract Implementing this feature is a high priority. [Draft technical design with more detail](https://personhood.slite.com/api/s/note/Bi21mXUWdzzgxL9CtyPNXy/Privacy-v0) ## Sybil attack vectors and defenses Security is often an economic game. The goal of Zorro is to make the cost of obtaining additional profiles as high as possible (without over-sacrificing frictionless, inclusivity, etc). For a general economic analysis see: [The Economic security of Proof of Personhood services](https://hackmd.io/@RoboTeddy/S1EsAilTO) ### Puppeteer attack An attacker (the puppeteer) can obtain an additional profile by paying or tricking someone else (a puppet) into handing over a photo/video that can be used to register. This is a pernicious attack. We're not aware of any bulletproof defenses, but there are a number of possibilities that can stack together to increase the cost of attack. For example: - **Live video registration:** Rather than registering via static video, there could be a live video session with a community notary who can ask the registrant whether they're here of their own accord, etc. - **Oaths:** Having people swear an oath live on video with a notary that they're registering of their own accord. Puppeteers will have to pay more if they're forced to find people who are willing to break an oath. - **Vouching:** Requiring new registrants to obtain vouches from existing registrants would make things tougher for puppeteers (at the cost of being more exclusive and having more friction). In particular, it would make it easier to identify networks of puppets. - **Reclaiming:** Puppets can be offered a means of reclaiming their own profile from a puppeteer. - **Reverifying:** Users can be required to reverify on occasion, which would cause puppet profiles to expire unless the puppeteer goes to the extra expense of maintaining an ongoing relationship with their puppets. ### Fake client attack An attacker could make a fake Proof of Personhood registration service that looks a lot like Zorro except that it has additional 'feature': it shares the user's private key with the attacker. Unlike in the puppeteer attack, where the puppet is witting, here the victim is unaware of what's occuring. One possible defense is to help the registrant authenticate their means of registration, e.g. by reading aloud the URL that they're connecting from. This may require e.g. a Zorro DAO that maintains a list of approved clients. Moderating clients may seem like an extreme measure, but consider that in e.g. Bitcoin, if someone downloads a false client, they are the only ones who suffer the consequences. In Zorro, on the other hand, a false client can call into question the legitimacy of the entire registry. Another possibility would be for the community to settle on a single client, e.g. `zorro.eth.limo`, which is run in a decentralized manner. ### Deepfake attack Although deepfakes are still somewhat detectable via the combined efforts of algorithms and humans, we expect that long term deepfakes will become indistinguishable from the real thing. There are a number of possible defensive measures, but *ultimately we expect we'll need to transition to an entirely different means of registration*. To help buy more time for the current means of registration, we won't describe defensive measures until they launch. ## Other attack vectors ### Challenge griefing - To prevent griefing, a profiles which is challenged *after* `PROVISIONAL_PERIOD` continues to be considered verified while the challenge is being resolved. - Repeat spurious challenges could consume some of the adjudicator's bandwidth, but ultimately would cost the attacker money and help fund the protocol. If repeated challenges remain a nuisance, the protocol could be adjusted to double the deposit required for each subsequent challenge. ### Spamming the notary service If the notary relay service becomes inundated by spam, the protocol fails semi-gracefully by allowing registrants to fund their own submissions. The notary relay service could also defend itself using traditional "web2" means, e.g. CAPTCHAs. ### Pseudoanonymization attacks If a new public profile is made and then right afterwards a new pseudonymous alias is created, attackers can presume that the two are linked. For this reason, users that care about their privacy will need to wait some time to build a larger anonymity set. The required wait time can shrink as a greater number of people use the service. Users only face this required wait when they sign up to Zorro, and not subsequently. Once profiles are merklized in order to allow users to generate a zk proof in their web browser, clients will use some service (e.g. The Graph) to retrieve the the merkle path for their profile. Someone who can observe which such requests are made by which IPs could do some basic network analysis to learn which newly-created profiles likely belong to which IPs. To prevent this attack, clients can increase their anonymity set by always requesting a large random batch of merkle paths, only one of which belongs to them. ### Notary malfeasance If the protocol notary falsely denies registrants, they can opt to bypass the notary and submit their profiles directly. If the protocol notary falsely admits registrants, there will be incentive to challenge them and win the deposits, draining money from the notary. Each profile though would be considered valid up until it is challenged, and challenges will not be immediate. That means a malfeasant notary service could temporarily approve (and use) many profiles, at an eventual cost of `SUBMISSION_DEPOSIT_SIZE` per profile. Three defenses: - Rate-limiting the rate (or acceleration) of notarizations - Adjusting these limits depending on the rate of challenges - Decentralizing the notary service (described under 'Future Improvements') ### Adjudicator malfeasance Adjudicator malfeasance mostly won't affect the integrity of the registry because cases can be appealed to Kleros on L1. However, defending poor adjudicator decisions could cost the protocol money. The main defense would be to decentralize the adjudicator service (described under 'Future Improvements') ## Future improvements ### Handle liveness failures gracefully The protocol is sensitive to liveness failures in Ethereum or StarkNet because it relies on the ability of participants (e.g. challengers) to submit transactions during particular time windows. The protocol could be improved by automatically pausing in the event that a liveness failure is detected (this would require keepalive tx to be sent on a regular basis.) ### Handle registration MITM attacks An attacker that colludes with a notary or watches the StarkNet mempool (once it's public) could discover a registration photo/video prior to it being included on-chain and use it as part of their own registration. This attack could be handled by encouraging the legitimate participant (who clearly already wants to register) to challenge the profile created by the MITM. They'd be able to succeed in this challenge by e.g. demonstrating themselves reading a recent block hash. Note that the protocol would have to be designed not to pay out a bounty to people who challenge their own profiles. If this were an ongoing issue, it could be mostly solved by using a commit-reveal scheme. ### Stable external API The initial version of Zorro supports democratic voting on Snapshot by relying on an API which may not be permanent. The API will stabilize with the release of the zero-knowledge pseudonymity layer. (In the mean time, if you'd like to integrate, [just DM us](https://twitter.com/ZorroProtocol).) ### Bridge to L1 and other L2s It's is possible to make a trust-minimized bridge to Ethereum L1 and other L2s running on Etheruem so that applications there can use Zorro. ### Economic suffiency For Zorro to succeed over the long term, it needs enough revenue to cover its costs. Aspirationally, notary and adjudicator work will be taken on by mission-driven community members. If not, the protocol would need to raise more revenue externally in order to pay notaries and adjudicators — this though could hamper adoption, especially if it ended up requiring charging registrants. #### Costs - Notary: - Capital cost of deposits - Transaction fees - Notary human time - Adjudicator human time - Security bounty pool - Defending adjudicator's decisions against appeals #### Revenues - Charging DAOs (a la BrightID, which takes this approach) - Deposits of incorrect challenges - Deposits of incorrect appeals - Donations - Charging users - Gitcoin grants - Retroactive public goods funding At the start, the main source of protocol revenue will be donations. Over time it will be healthy for the protocol to mix in other sources to become more resiliant. The protocol is meant to operate for the public good rather than to extract money to enrich anyone. ### Decentralize further Here are the known points of centralization alongside rough plans for removing them. #### StarkNet StarkNet currently has a number of points of centralization: - Sequencer can censor L1->L2 messages - Sequencer can censor L2 transactions - Sequencer can halt - Sequencer may include transactions without publishing them (doesn't affect correctness but damages auditability) - StarkNet has an upgradeable contract - Prover is not open source These points of centralization should dissipate over time as Starkware decentralizes StarkNet. Their roadmap addresses all of these items. #### Remove backend server The open source backend server is intended to be shut down once its functionality has been decentralized. It currently serves four purposes: 1. Providing a modicum of privacy to users - Can be handled by in-browser zk snarks, as described earlier 2. Querying and caching StarkNet chain state - Can be handled by a solution like The Graph, once StarkNet supports events. 3. Storing profiles for a few minutes before they're relayed by the protocol notary - See: *decentralizing the notary* 4. Storing registrant contact information for notifying users of challenges, expirations, etc. - This is probably the most challenging bit to decentralize. Many applications face the same problem; our hope is that over time a solution will emerge, e.g. the [Ethereum Push Notification Service](https://epns.io/) #### Decentralize the notary At first, the notary is a simple account contract. It can be upgraded to become a fully-fledged contract of its own which admits new notaries (perhaps via a DAO voting process), automatically tracks their reptuations (notaries could be dismissed if they notarize profiles that are succesfully challenged at too high a rate), etc. There could be a rate limit on the number of submissions per notary, which would distribute power across a number of separate people. #### Decentralize the adjudicator The adjudicator can be decentralized similarly to the notary. This decentralization work is a bit lower priority because faulty adjudication decisions can be handled by appealing to Kleros on L1. #### Automatically incent appeals A registrant whose profile has been challenged will generally have an incentive to protect their own profile by appealing the adjudicator if a bad decision was made. However, that would require each registrant to be actively monitoring all decisions regarding their profile, and would also require the registrant to know the rules well enough to establish for themselves whether ther adjudicator messed up, and require the registrant to have enough money to fund the appeal. To prevent registrants from facing these issues, the protocol intends to maintain an incentive for *anyone* to appeal any bad adjudicator decisions. This incentive will be maintained in the short term by manually putting up funds to defend all adjudicator decisions. Longer term, these funds can be automatically drawn from a pool. #### Contract upgradeability Initially, contract upgrades will be managed by the creators of the project. Ultimately, the plan is to distribute this power over a larger number of people, perhaps in the form of an ENS/Gitcoin-style DAO where members delegate voting power to trusted community members by default. Aside from this explicit upgrade mechanism, Zorro is designed to be forkable so that the community can step in should anything go awry. #### IPFS pinning / decentralized backups Profile photo and video files are distributed by IPFS, but only if servers opt to pin the files. Proper decentralization might involve some combination of multiple pinning servers (a 1 of n trust assumption), and/or automatically storing to services like Filecoin or Arweave. ## Credits - Vitalik, [who outlined the need for anti-sybil systems on Ethereum back in 2014](https://github.com/ethereum/wiki/wiki/Problems/89fd07ffff8b042134e4ca67a0ce143d574016bd), and who more recently has emphasized the importance of this problem. - [Proof of Humanity](https://www.proofofhumanity.id/) and its inventors - The Proof of Humanity crowdvouching and crowdfunding communities - [The owner of the zorro.eth ENS name](https://twitter.com/zorro_aster_42), who was willing to pass it on to this project. - Too many more individual people to list!