Preventing vouchallenges while incentivizing a web of trust

Proof of Humanity
1

Disclaimer: This post aims to open a discussion. In a future, a formal HIP should be crafted. This discussion also assumes that Proof of Humanity will be deployed, along with Kleros, in an L2 solution, so I suggest to avoid thinking in high fees and other problems related to Ethereum L1.

Preventing vouchallenges while incentivizing a web of trust

Currently vouching a profile has almost no consequences. This has a negative aspect (like vouchallenges, that will be introduced in a moment) and a kind of positive aspect (people easily vouching for other people that needs a vouch).

Vouchallenge

A vouchallenge, that’s how it’s known in PoH telegram channels, is a kind of attack where the attacker acts as voucher and challenger at the same time. I call it attack because I assume it’s something that we don’t want to happen in the protocol.

The attacker finds a wrong profile (for example, with a typo in the address) and proceeds to vouch it. Why does him vouch it? Because that enables him to perform the challenge afterwards (only vouched profiles can be challenged).

I guess, in theory, voucher loses some UBI when vouching a profile that then ends removed. However, a vouchallenger swaps all his UBI for another currency before performing the attack.

Proposed solution: vouch deposits

I propose a simple solution, easy to understand by the community as it uses similar mechanisms as for submitting a profile.

Basically, I suggest that when someone vouches for a profile, deposits an amount of money greater than the challenger reward. If profile is accepted, deposit is returned to the voucher. Otherwise, if profile is rejected, the voucher lose the deposit.

Consequently, suppose someone wants to execute a vouchallenge attack, will vouch depositing some amount X. Then challenges the vouched profile.
A successful vouchallenge will make the attacker to earn an amount Y, but at the same time, as he vouched the profile, will lose an amount X. So, if X > Y (i.e. vouch deposit greater than successful challenge reward), then a successful vouchallenger will lose X - Y money.

The result: no more incentives to do a vouchallenge.

Burning UBI

In the previous section I avoided to mention the currency for the vouch deposits. Probably the natural (and easy to implement) thing is to require a deposit in ETH.

However, an interesting experiment could be to require the deposit in UBI. So then, if the profile is rejected, the UBI deposited is burned.

This will help to increase the demand (or reduce the supply) which has a direct impact in the price, as people maybe wont sell UBI as fast as now, because maybe will want to vouch for someone soon, or some people will buy UBI for vouching others.

Note: Using UBI instead of ETH makes the implementation a little bit more complex, because will need some price oracle to verify the amount of UBI represent more money than the challenge reward (maybe Uniswap’s oracles could be used).

Web of Trust + Less submitter deposit loses

The fact that the voucher is risking some money when vouching for someone will make vouchers to prefer risking only for people known in real life (friends, family, etc). For me, this is a feature for Proof of Humanity, not a bug.

Increasing the link between submitter and voucher will lead to a more trusted registry, which is really important because is the almost the goal of PoH. And because of the six degrees of separation theory we can think that in middle term wont be difficult to know someone who is already in the registry.

In addition, people will care about the quality of the profile they are vouching for. Otherwise, will lose the deposit. As consequence, voucher will take the time to verify the submission is following the rules (something that now does not really happen, and ends up by having a lot of people losing their deposits).

People that don’t know anyone already in the registry, could go to the telegram group and make a video call with a voluntary voucher, who after verifying the submission could decide to help risking his deposit.

Discussion

As I said in the disclaimer at the beginning of the document, the goal of this post is to start an informal discussion around this proposal. Please correct me if I’m wrong about something. I look forward to read your thoughts.

8 Likes
2

Thanks for writing this! Will love to see the discussion that comes from it.

I would like to add a parenthesis:

This discussion also assumes that Proof of Humanity will be deployed, along with Kleros, in an L2 solution, so I suggest to avoid thinking in high fees and other problems related to Ethereum L1.

On an L2, we could instruct users to use the “crowdfund” option to crowdfund themselves after they receive a proper vouch. This will not stop vouchallenge attacks of course, but it might reduce them to a negligible number. On L1 this costs 20% more than self funding, on an L2 it might be negligible, with no further inconveniences, costs or complexity.

4 Likes
3

Hey! Thanks for bringing this idea over here. I like it a lot.

It was talked on Telegram channels, I think, about using a deposit to vouch. It is an even better one with this burning mechanism.

How could it be implemented? Does it need a new contract to be deployed?

I asked you about this because for the last couple of months (probably since the start of the discussion of HIP27 by @mizu) there is the topic of the voucher as the first layer of curation of the list being discuss. Some ideas we had were about penalising or rewarding bad or good vouchers, aiming to a greater responsability from the community when vouching and not just hitting a button:

  • Decreasing or increasing the % of UBI being dripped.

  • Bad vouchers cant vouch no more.

  • Bad vouchers wont drip UBI for X amount of time.

But, at least, this three items needed the PoH code to be V2ed

So, how would you implement your idea?

Thanks again!

3 Likes
4

On an L2, we could instruct users to use the “crowdfund” option to crowdfund themselves after they receive a proper vouch. This will not stop vouchallenge attacks of course, but it might reduce them to a negligible number (…)

I understood you are mentioning moving to L2 wont stop vouchallenges. But, why do you think it will reduce them? I mean, vouchallenger will have even better incentives (lower fees, so reducing costs is kind of raising returns) and people will probably “crowdfund themselves” after having one vouch (independently of who vouched for them I guess).

Maybe I’m missing something, please let me know. I want to clarify I’m assuming no communication with the submitter (I read in the telegram group that sometimes you can reach the submitter, warn him about some error and save his deposit, but in an ideal case, in terms of privacy, we wont have enough info to contact people).

5

It was talked on Telegram channels, I think, about using a deposit to vouch. It is an even better one with this burning mechanism.

Yeah. I think I proposed the idea in the telegram group a couple of times, promising to write a more detailed post here. Glad to hear you like it.

Some ideas we had were about penalising or rewarding bad or good vouchers, aiming to a greater responsability from the community when vouching and not just hitting a button

I wasn’t aware about the other ideas like decreasing/increasing dripping rate or unallowing dripping/vouching for N amount of time. They are interesting. Maybe we can combine them, like requiring a deposit and then use the other kind of penalizations for the cases where the profile is challenged after being accepted (so deposit was already returned to the voucher).

How could it be implemented? Does it need a new contract to be deployed?

Yes, for sure, a new PoH version is needed. I think we should design PoH v2 to make it easier to perform modifications in the protocol. For example having the storage with the registered profiles in a separate contract, so we don’t need to do any kind of migration in the future.

But well, definitely needs a PoH v2. I think we should focus on the protocol improvements now and then when we decide/vote what things to change, start working on the code and think about what is the best strategy for the implementation/upgrade, etc.

6

This was not my original point, but I would like to expand on this. With lower fees, it’s very likely that we will reduce the bounty for challenges as well, since gas fees are a factor that we use to calculate the “bounty” amount. Another factor that increases the bounty is how much the gas prices vary, since we need to make sure it is profitable even when gas is unusually high.

So in general, challengers will have a reduced incentive to challenge. I’m not sure if this will have any effects on “vouch + challenges”. Maybe the “vouching” part will be seen as a bit more costlier than it is now?

I was assuming that we could guide people to only fund their profiles after they receive a vouch from someone they know, or someone they expect a vouch from (when using a telegram group, for example). We could call this option “safe fund/crowdfund”, and use the UI to recommend it. The UI could also call “self-fund” the “expert” option.

The profile without a deposit would be something that people could share around, and gather feedback from others, without having the risk of being “vouch challenged” in the process. For example, we could have a telegram group where people vote with a :+1: or :-1: very quickly on profiles.

I believe most of the mistakes would be caught in this stage, but to be honest it’s hard to know. It adds a bit of friction for people that want to be safe, and almost none for “experts”.

2 Likes
7

In the previous section I avoided to mention the currency for the vouch deposits. Probably the natural (and easy to implement) thing is to require a deposit in ETH.
However, an interesting experiment could be to require the deposit in UBI. So then, if the profile is rejected, the UBI deposited is burned.

Now this could be paid in ETH and be burned with the UBI Burner. I agree with vouch deposits, it will probably slow down the adoption in my opinion, but in early stage it maybe desirable.

I was assuming that we could guide people to only fund their profiles after they receive a vouch from someone they know, or someone they expect a vouch from (when using a telegram group, for example). We could call this option “safe fund/crowdfund”, and use the UI to recommend it. The UI could also call “self-fund” the “expert” option.

I like this idea too, thinking in a low fees scenario.

1 Like
8

You are right. I think best approach would be denominate all in ETH, much more easier to implement, then send everything to the DAO, which can choose how to use it (burning UBI is just one option).

9

I think could be interesting this kind of restricted vouching. So you submit and you say “I only accept vouches from the following addresses/profiles”.

10

Actually it’s a lot more simple than that: you submit your profile without a deposit, share your profile around so people can comment on it. Ask your friend to vouch for you, and only then you fund it fully.

This requires no policy changes, no HIPs, only UI changes and a change on our guides.

It’s around 20% more expensive on mainnet than making a self-fund submission - which I suppose is the reason why people prefer not to do it right now, but on Gnosis that’s a negligible difference.

Full idea below:

1 Like