Zorro Protocol

Zorro is a fast way for people to prove that they're a unique person so they can obtain democratic DAO voting rights and other benefits.

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.
3. After registering, people can pseudoanonymize themselves to protect their privacy.

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.

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 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.

• 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.

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:

• 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

• 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.

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:

• 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 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.

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

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:

• 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

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:

• 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.

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.

• 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.

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:

• 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 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.

• Notary:
• Capital cost of deposits
• Transaction fees
• Notary human time
• Adjudicator human time
• Security bounty pool
• Defending adjudicator’s decisions against appeals

• 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.

Here are the known points of centralization alongside rough plans for removing them.

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.

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

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.