Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Upala anti-sybil integration #7888

Open
owocki opened this issue Nov 16, 2020 · 6 comments
Open

Upala anti-sybil integration #7888

owocki opened this issue Nov 16, 2020 · 6 comments

Comments

@owocki
Copy link
Contributor

owocki commented Nov 16, 2020

specced at upala-digital-identity/upala#3
@porobov
Copy link

porobov commented Dec 17, 2020

Moving the specs above here...

There are two options that Upala can be integrated with Gitcoin. These options can be used as alternatives or as stages - one after another. Both options follow the same strategy which is explained below. The integrations are explained further. And some future thoughts are included even furtherer.

Bribe bots to leave

As proposed earlier in this tweet the strategy is as follows:

  1. Set. Assign Upala score to each of the verification methods.
  2. Wait. See how many users will explode*.
  3. Repeat. Tweak scores for each verification method.

*Explode = run away with the score (money), delete Upala ID, delete Gitcoin ID.

Set

Setting the score for the first time is just guessing. But it makes sense to start with low scores for verification methods. It is fairly simple to increase the scores at any time. But If the scores are too high we'll see too many explosions from the start (and will not be able to do anything until attack window expires - presumably 1 hour).

Wait

At this stage users are gonna explode, take their explosion rewards (which are equal to their scores) and delete both their Upala and Gitcoin accounts. This is the time to analyze stats.

If a verification method is too easy to exploit, we'll see a lot of users verifying themselves and creating new gitcoin accounts just for the sake of explosion reward. That would mean that we have to lower that verification method score. And we can increase the score for stronger verification methods.

Repeat

Here are proposed global parameters to quickly asses and reset the score:

Period. Time-frame during which the explosions analytics is gathered. We could tie this period to Matching Rounds or make it as short as 1 hour. The only constraint here is Upala's front-run prevention, which requires a 1 hour pause (bot attack window) before new scores take action.

Explosion rate. Metrics for each verification method. Could be measured as

( total explosions reward payed ) / ( number of people verified )

Threshold. Desired explosion rate for every verification method.

Step. A step or a factor by which scores are increased or decreased for the next period when crossing the threshold.

Benefits

Refine your audience. As some users will decide to get the money rather than participate in Gitcoin there will be a number of bots leaving the platform. But the remaining ones are your super-users. They value their IDs higher than their scores. It is safe to give them more privileges.

Metrics. Treat a new verification method as an investment and measure its "ROI". Compare explosion rate and activity of users withing the category.

Fairer trust bonus. Tweak trust bonuses according to the price-of-forgery of a verification method.

1. Assess existing verification methods

It's the first option of Gitcoin and Upala integration. Here we use current active verification methods to set Upala user score.

After some Set-Wait-Repeat stats is gathered, we establish a fixed ratio between Upala score and trust bonus. Then reset all trust bonuses accordingly. Thus the trust bonus will reflect the trustworthiness of a verification method (as the score provided by the method represents its forgery price).

Scores and trust bonuses for the active verification methods
Scores and trust bonuses for the active verification methods (Notion)

Boosted bonus

When first introduced, Upala may provide additional scores to all other methods. This would create an additional incentive to use all verification methods and to use Upala (in order to start gathering stats early).

Upala on Gitcoin

2. Add other verification methods through Upala

Another way to integrate Upala is to have an Upala group with it's own verification methods. This could be used as an alternative to the above integration or as an extension of it. Any number of verification methods could be added here (those could be provided via Multipassport interface).

Verification methods
Verification methods (Notion)

*Existing users - the ones that existed before implementing Upala.

3. Use other Upala score providers (from future)

Gitcoin may approve other Upala groups (not owned by Gitcoin) as its score providers. If a user manages to increase their score outside Gitcoin, their trust bonuses could be increased accordingly.

Gitcoin as a score provider

Upala score provided by Gitcoin group will be instantly available to other DApps if they chose to trust Gitcoin (why wouldn't they?). Gitcoin may charge DApps for this. Pretty cool!

Upala + Gitcoin user base = Sybil-proof Ethereum

...or Gitcoin may decide not to provide scores into the outside world.

Tech details (for option 1)

  • User registers Upala ID on Gitcoin Trust Bonus page
  • Gitcoin periodically assigns scores to all registered Upala IDs off-chain and publishes a Merle root of IDs and scores on-chain.
  • Users make a transaction with a Merle proof to assign scores to themselves.
  • Trust Bonus page reads user score from Upala.

Smart-contract draft here.

Off-chain front-end, back-end - https://github.com/trustlines-protocol/merkle-drop

More info:

Join us:

@porobov
Copy link

porobov commented Dec 17, 2020

Working on this made me think of using Merkle drop on a protocol level. That would allow better anonymity, instant score assignment and updates. In terms of gas it is much cheaper for group managers, but more expensive for users.

...which is kinda pivotal and needs a stress-test. Would be very happy to hear your thoughts on that.

Probably Merkle drop is not even the best solution. What do you think would be better? Is it a good idea at all to ditch the old scoring mechanism at all? Please check out the doc. https://www.notion.so/UIP-15-Protocol-level-Merkle-drop-305af5fbb2f34a24a93a5bf35e7ff28a

@owocki
Copy link
Contributor Author

owocki commented Mar 17, 2021

@porobov are you still interested in doing this integration? i dont see any open PRs so i think it must not have happened

@porobov
Copy link

porobov commented Mar 22, 2021

@owocki OMG sorry for the long reply. The notification went into spam on Gmail...

I am certainly interested in integration. But I'm still building the protocol.
A lot of work ahead (roadmap), and I'm trying hard to strip unnecessary things off.
Also having the first Upala community call this week (Wednesday, March 24th, 12:00 PM ET). Trying to build community and team...

@owocki
Copy link
Contributor Author

owocki commented Mar 22, 2021 via email

@porobov
Copy link

porobov commented Mar 23, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@owocki @porobov