Proposal: allow consuming projects to fine-tune their security requirements

Proof of Humanity
1

(I initially posted this as a HIP, but after further thought I’m not sure it’s the right direction to go, so I removed the HIP tag. I’ll still leave it up as a jumping-off point for feedback/brainstorming.)

Simple Summary

Allow each project that depends on Proof of Humanity to decide for itself how large a challenge deposit/number of vouches it requires from users to count as “authenticated” for its specific use case.

Abstract

Right now, Proof of Humanity’s “public API” is a simple function isRegistered(address), which consuming projects can use to determine whether a specific address is registered with Proof of Humanity or not. Since this function just returns a binary true/false, all Proof of Humanity registrations are held to the same standard.

This proposal would add a new function to the public API meetsThreshold(address, minDeposit, minVouches). This function would allow projects where the cost of fraud is high to require registrants to meet stricter requirements, such as a larger challenge deposit or more community vouches. It would also allow projects where the cost of fraud is low (eg some NFT/token drops) to relax the PoH registration requirements for their users, instead prioritizing ease of use.

Motivation

There will always be some tension between the ease of onboarding with Proof of Humanity and the difficulty of creating a fraudulent account. Adding more onboarding requirements makes it harder to slip a fake account through, but also inconveniences legitimate users and could cause some projects not to adopt PoH out of concern for our impact on their signup funnel.

The right way to balance that tradeoff isn’t obvious a priori—that’s why parameters like requiredNumberOfVouches and submissionBaseDeposit were made tune-able. But the right tradeoff also depends on the damage a fraudulent account can do. And that number varies significantly depending on the use case.

For example, an artist who’s minting 1,000 low-value NFTs and wants to limit orders to one per customer might prefer making signup for her users super easy, even at the cost of many fraudulent accounts getting through. She could require a very small deposit and no vouches. At the other extreme, Gitcoin may care very deeply about avoiding fraud when assigning its matching grants, and thus require each user to have 5 vouches to qualify for the maximum match.

There’s another good reason to let users easily sign up for a “basic” PoH profile with a minimal (or no) deposit. Right now, PoH isn’t a widely-known protocol, and community trust and understanding will inevitably be low. Lowering the requirements for signing up with a basic profile allows users to “get their feet wet” before committing to a larger deposit and earning a higher-trust account.

Implementation

I’m happy to brainstorm more specifics in this thread, or if there’s broad consensus that this is a useful change I can write up a more formal HIP. A few important implementation details up front, though:

  • Registrants can earn a higher minDeposit number at any time by putting up a new, larger deposit. At the end of a 3-day challenge window, they can withdraw the collateral and their registration is assigned the higher minDeposit number. The minDeposit number also resets to 0 one year after they last posted a deposit, requiring a renewal to stay current.
  • Only accounts that have made a minDeposit large enough to attract potential challenges should be allowed to vouch. This cutoff can be determined by the submissionBaseDeposit parameter.
  • For backwards compatibility, the isRegistered function should be modified to return false for newly-registered addresses that don’t match the current requiredNumberOfVouches and submissionBaseDeposit parameters.
2 Likes
2

Very interesting proposal. Looks like it might need some relevant refactoring of the contract itself. Maybe it’s something to discuss regarding a roadmap for a PoH v2.

3

One of the competitive advantage of POH compared to other projects (ex BrightID) is that the contract is returning binary result as whether someone is or isn’t registered. For sure, there could always be some sort of intermediate contract which would perform the cutoff and then return a boolean but this would have the following issues:

  • In case of deposit increase this would require some actions from the users instead of the current behaviour keeping people who were already registered.
  • This would make the user experience way more complicated with users having to find out the level of security that dapps that they are likely to use would be likely to require.
  • This would cause a lot of frustration of registered users who would be barred access from some apps.
  • App integrating with POH would need to become POH experts in order to determine the appropriate level of security.
  • It would render challenges opportunities non fungible, thus complexify challenger tasks (which would mean higher deposits at constant security level).

One of the main interest of POH is that once you are registered, you can use all apps requiring POH. This makes you POH registration universal, you only pay once (in TX fees and your time) but can then access to the whole ecosystem of dapps using POH.

Finally having different security level for POH wouldn’t provide significant improvements on the way down (i.e. lower security). This is because POH is itself a POH user: POH uses POH to determine if a user can vouch (and that’s why we needed an initial registered user set as otherwise no one could get the 1st vouch).
This means that POH itself would have to determine a specific security threshold to allow people to vouch. So if some dapps were to require lower deposits/vouches, we could have an imbalance between the supply and demand of vouches were a bunch of users would get low level verification, requiring vouches, but not making new vouchers.
(for sure, we could then have different levels of vouchers, but that would make vouches non fungible and really complexify getting the right vouches)

So I believe POH is way better providing an uniformed security level and try to:

  • Lower registration costs (which can be made using a rollup).
  • Increase registration reward (help people who want to make dapps using POH).
4 Likes
4

I think this is too complex for now. The protocol is good enough for use, while the main problems lie in UI issues and community building. For me this looks like optimization before we know the real problems interfacing projects would face.
@Kyle do you have a concrete project in mind that reported this as an issue?