Should we run pairwise or linear computation for our first Quadratic Funding mechanism?

[nfrgosselin]

Gitcoin rounds currently use pairwise QF calculations, which are computationally expensive. Is there a compelling reason for us to continue with pairwise vs linear calculations?

[nfrgosselin]

@gdixon / @thelostone-mc as a starting point, could you give an explanation of the trade-offs between the two methods?

[thelostone-mc]

@nfrgosselin If we look at it from a technical standpoint.

Linear Quadratic is better and I see no benefit in the pairwise :

Reason why:

• Less complex AKA quicker run time
• In theory could be calculated within a subgraph / maybe even explore contract level run for tally

What I'm looking at is a validation from product / ops on what benefits pairwise might offer us as opposed to going with the linear round.

• wtfisqf.com has a working example of how linear QF would work
• what we run on cGrants in pairwise QF

AKA we are looking at 2 flavours of QF.
The input data and output data of both the flavours are the same

Ops might need to do data validation / comparing results with both approached to make a better decision. (unless someone from FDD / operations already did this in the past )

[nfrgosselin]

Thanks @thelostone-mc! Can you unpack the calculation difference a bit more? Like is there any mathematical difference between the two?

Said another way, what's the argument in favor of pairwise?

[shavinac]

the benefit of pairwise is to reduce matching funds for grants that have very similar contributors - If two donors (a pair) donate to a set of similar grants, then the matching fund for that grant will be discounted by a certain amount (source)

vitalik goes thru the mathematical breakdown here.

Hence, the new scheme offers a clear bound (k ∗ (k−1) ∗ M) on the amount that the system loses to unexpected coordination between k agents (which could come completely illegitimately, eg. fake accounts, or more benignly, as in two people from the same family caring about each other). The emphasis of the CLR switches from assuming total non-coordination between individuals to being more robust against there being some level of existing coordination between individuals, and focusing on subsidizing coordination between individuals who would not normally coordinate.

it is still possible to "game the system" of pairwise QF though, for example, "forwarding" your contributions thru different people

[thelostone-mc]

A more detailed description:

Just a random thought when I was chatting up with the RPGF team.
Is there a pressing need for us to run pair-wise QF vs linear QF

I'm trying to have us justify

• why we need something that is computationally expensive
• what the diff is if we pick linear over pairwise

Given we have passport score + FDD for fraud.
Does the computationally expensive pairwise give a very different result from using regular QF.

A bigger question :

• Are we the only one's in the space who run pair-wise QF

The regular QF : https://wtfisqf.com/
who's code can be found at https://github.com/Anish-Agnihotri/quadratic-funding/blob/master/pages/index.js#L84-L121

We had already implemented a version of it on dgrants as well
https://github.com/dcgtc/dgrants/tree/main/dcurve

[shavinac]

Some resources on pairwise QF from Gitcoin:
https://gitcoin.co/blog/how-to-attack-and-defend-quadratic-funding/ (section: 2. Coordinating Fake Contributions with Real Users)
https://ethresear.ch/t/pairwise-coordination-subsidies-a-new-quadratic-funding-design/5553/24 (difference between regular vs pairwise QF using real grant round data)

[ccerv1]

A few thoughts:

Ops might need to do data validation / comparing results with both approached to make a better decision. (unless someone from FDD / operations already did this in the past )

This was done a few rounds ago. There's been discussion about FDD running this analysis again, but it hasn't been prioritized AFAIK.

Why we need something that is computationally expensive?

Could we do linear QF at the time of transaction for simple approximations and then do pairwise QF (or a more robust model) at the end of the round to finalize the payouts?

---

Eventually, I'd love to run all of the model in the appendix of the DeSoc paper!

[lthrift]

Could we do linear QF at the time of transaction for simple approximations and then do pairwise QF (or a more robust model) at the end of the round to finalize the payouts?

I'm interested in us exploring the experience flow similar to what Carl suggests here, in which there is a period after voting/contributing round closes and the final calculations are done.

One of the things the original grants platform has attempted to do is give real-time results indicators during the rounds, but I worry this could be skewing results in a way that are not intentional. If we shift towards enabling sharing of opinions of projects and "marketing" of projects away from actual results, would this better enable a neutral platform with results that indicate the true desires and opinions of the community?

[ccerv1]

I share your concern that this could skew results unintentionally. As a user, I often find myself favoring grants that have a higher match ratio. Has there ever been any A/B testing on how real-time results are displayed?

[nfrgosselin]

We haven't done an A/B test, but anecdotally our user interviews have supported the idea that the results indicators skew decision making. It's definitely something worth doing on the protocol

[nfrgosselin]

In the interest of a near-term resolution: I spoke with our next design partner (who will be the first users of the QF mechanism) and they are open to using linear QF for their next round. Given that, I'm opting to have v1 built as a linear solution — I think we can do a post-hoc analysis to learn a little bit more about different calculation approaches impact the distribution of that round.

[lthrift]

Sounds good to me. Would love to see a collab with Carl and/or Omni to do a post round data challenge similar to the way we're running the Trust Bonus experimentation rounds. Lindsey Thrift, VP of Product LinkedIn <https://www.linkedin.com/in/thriftlindsey/> | Telegram <https://t.me/lthrift> <https://gitcoin.co/>

…

On Mon, Sep 12, 2022 at 12:34 PM Nate Gosselin ***@***.***> wrote: In the interest of a near-term resolution: I spoke with our next design partner (who will be the first users of the QF mechanism) and they are open to using linear QF for their next round. Given that, I'm opting to have v1 built as a linear solution — I think we can do a post-hoc analysis to learn a little bit more about different calculation approaches impact the distribution of that round. — Reply to this email directly, view it on GitHub <#344 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWA66JETOJSRAXYVNN3HWNDV55ZULANCNFSM6AAAAAAQGYGFM4> . You are receiving this because you commented.Message ID: ***@***.***>