The Zorro Protocol is still under initial development. This draft reflects current thinking and will be updated without versioning as the protocol is implemented.
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.
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.
Proof of Personhood can enable critical societal infrastructure, for example:
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 which is plutocratic and leads to all sorts of problems.
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.
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.
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.
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!
Registering on Zorro should be:
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.
Credit: Zorro's design was greatly inspired by Proof of Humanity and the crowdfunding/crowdvouching communities that emerged around it. Zorro is mainly an extension of those ideas.
The initial implementation of Zorro runs on the Ethereum L2 StarkNet.
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.
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:
SUBMISSION_DEPOSIT_SIZE
(~$30 of eth to start)cid
pointing to:
After a waiting period of length PROVISIONAL_PERIOD
(~3 days), whoever submitted the profile can reclaim their security deposit.
PROVISIONAL_PERIOD
.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 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.
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:
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.
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.
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 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.
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:
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 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:
If the challenge was successful:
PROVISIONAL_PERIOD
, the submission deposit is guaranteed to be present still, and it is revoked from the submitter and sent to the challenger.After a profile is settled, it's possible for anyone to challenge the profile again with new evidence. This isn't a griefing vectoring:
PROVISIONAL_PERIOD
are 'presumed innocent' after being challenged, that is, they are still considered verified until the adjudicator or super adjudicator speak.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.
The initial application of Zorro (using it in Snapshot voting strategies) 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.
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:
Implementing this feature is a high priority. Draft technical design with more detail
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
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:
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.
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.
PROVISIONAL_PERIOD
continues to be considered verified while the challenge is being resolved.If repeated challenges remain a nuisance, the protocol could be adjusted to double the deposit required for each subsequent challenge.
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.
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.
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:
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')
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.)
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.
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.)
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.
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.
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.
Here are the known points of centralization alongside rough plans for removing them.
StarkNet currently has a number of points of centralization:
These points of centralization should dissipate over time as Starkware decentralizes StarkNet. Their roadmap addresses all of these items.
The open source backend server is intended to be shut down once its functionality has been decentralized. It currently serves four purposes:
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.
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.
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.
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.
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.