Another recent suggestion is for Gitcoin to run a Gitcoin branded instance of clrfund for the upcoming GR14 grants round, scheduled for some time in June/July. The proposed round would run in parallel with the normal centralized Gitcoin grants round, along with an instance of their new dgrants platform. Similar to how they ran GR12.

Kevin, and others from Gitcoin, have shown a desire to experiment with and embrace different funding mechanisms in parallel and to collaborate with clrfund on trying out MACI-powered QF in the context of Gitcoin grants rounds.

At face value, this seems a great opportunity to try clrfund out in a new context with a large userbase already familiar with web3 and QF. However, @Daodesigner raised some valid concerns around how running rounds in parallel like this might actually have a negative impact on the perception of QF using MACI. In large part due to the potential for it to turn into a head to head comparison between the “performance” of clrfund vs dgrants and/or cgrants, given their would likely be a strong bias towards the less frinctionful and more well established options.

I tend to be of the opinion that this is a good opportunity to add an option for private, collusion-resistant, QF to Gitcoin Grants rounds, and am hopeful that it would lead to more focus on privacy and collusion-resistance in QF and the web3 ecosystem more broadly. Longer-term, I would love for privacy to be the default behaviour of these systems, rather than just an option, or the current status-quo of none at all.

Anyway, this feels like a pretty pivotal decision for clrfund, so I’d love to hash it out here with the community.

What are your thoughts?

I agreed with @Daodesigner in that the experiment result may not provide meaningful insight in regards to MACI-backed or not because MACI is backend implementation.

The experiment result may show which platform has better UX, because that’s what visible to the users from the frontend.

I’m curious to know more about the concerns. Why would it have a negative impact on the perception of QF using MACI?

auryn

March 4, 2022, 6:22pm #4

There are at least a couple of compounding concern:

1. there are several UX challenges for rounds using MACI, as compared to Gitcoin’s current grants setup: donations can only be made on one chain, signup flow is necessarily frictionful for sybil resistance, you can only contribute once to the round (although you can update you allocations as many times as you like), etc.

2. MACI is private by design, it reveals very little about the way that users interact with the system. We have no insight into who allocated funds to who, all we see is the amount that each user contributes to the round and final output of the round (the distribution).

In concert, these two things make it very difficult to do comparisons between MACI and the existing mechanisms that go deeper than volume of users, volume funds contributed, and final distribution. Such a shallow comparison would almost certainly favour the more well established options with less friction for users. In short, it would not be an apples to apples comparison.

That said, I personally still think it’s worth running the round. We just need to be very deliberate about how we communicate the round. It should not be positioned as a head-to-head comparison of the performance of different mechanisms, at least not based on volume-based metrics. I do think it would be interesting and useful to compare the ratios of the distributions between mechanisms and to get qualitative feedback from users and recipients. But most importantly, I think it’s important for us to get more real-world experience coordinating MACI-based rounds and this feels like a great opportunity to do it in the context of a community that is already familiar with web3 and QF.

I would like to start by saying we are grateful to gitcoin for funding clrfund development, I hope this can be cleared up quickly and we can continue to collaborate and drive mainstream privacy/QF adoption. So my main concern here, and why I asked to move the conversation to the forum, is the framing of this by @owoki as “VS”.

On the call we had, this was brought up as “the search for the best QF mechanism” with the idea presented being we would run two rounds in parallel (both branded as gitcoin) and see which one users prefer. The framing was explained as “ [clrfund] MACI vs [gitcoin] pairwise” which I don’t agree with on principle. It’s not the first time the head to head mentality, or conversation about MACI/privacy not being a good fit for gitcoin, has been presented behind closed doors (was Scott’s suggestion last time) while posturing as collaborative in public. In my opinion the ‘experiment’ is flawed because the user doesn’t need to know that there is MACI under the hood, that’s the entire goal.

It could very well be that I’ve misunderstood the opportunity presented here, and would love to give gitcoin another chance to present the idea to our community and help them toward MACI adoption!

owocki

March 8, 2022, 5:22am #6

Hi from Gitcoin.

I regret that I’ve not had a chance to comment when this was first posted, and that most of the discussion on this post has focused on the discussion of “[clrfund] MACI vs [gitcoin] pairwise”.

Long term, I DO think it’d be meaningfully impactful to the ecosystem to speedrun some experiments to “the search for the best QF mechanism possible relative to our values”, but as people rightly pointed out above, we perhaps are nowhere near being able to run a real experiment on MACI & pairwise given the current setup. Perhaps it was naive to suggest this during our most recent CLRFund/Gitcoin brainstorm. Let me repeat back the reasons I heard from you all:

1. As auryn noted “there are several UX challenges for rounds using MACI, as compared to Gitcoin’s current grants setup”

2. as auryn noted “MACI is private by design, it reveals very little about the way that users interact with the system.” and “In concert, these two things make it very difficult to do comparisons between MAC”

3. as yuetloo noted “the experiment result may show which platform has better UX, because that’s what visible to the users from the frontend.”

4. as daodesigner noted it compares “[clrfund] MACI vs [gitcoin] pairwise” in a co-mingled way.

So lets take the (in hindisight, rather naive) idea to test pairwise & MACI off the table.

With that out of the way - I would ask to reorient the conversation to the reason to start with why. Why did we even start talking about doing this in the first place? Why do we care about interop between Gitcoin & CLRFund?

First, the designs that someone put together of Gitcoin Grants using CLRFund look deeply cool.

Second, In the proposal for GitcoinDAO to issue a 40k GTC Grant to CLRFund, the proposal listed the following reasons to engage:

1. Extend previous friendly contact between Kevin Owocki and Auryn MacMillian to formally affirm that Gitcoin & CLRFund are friendly projects built around similar missions.

2. Change the narrative created by other competitive projects working on the same domain. That is the misguided belief that we must have sharp elbows - boxing each other out from each other’s users and demonstrate loud social media clap-backs.

3. It is possible that the goodwill between the two projects could be extended into a formal integration or partnership one day - especially with the Decentralize Gitcoin workstream gaining speed.

4. By pushing new tech and solutions on top of QF (such as MACI), CLRFund can act as a testbed/testnet for future gitcoin features and visa-versa.

The proposal continued: It is our assertion that CLRFund’s implementation of Quadratic Funding is complementary to Gitcoin. Most notably, in the following ways.

• It is pushing forward MACI.

• It is pushing forward sybil resistance & collusion resistance.

• It is funding public goods in the Ethereum ecosystem.

• It is iterative and increasingly effectively proven itself, having run 7 rounds so far.

• Gitcoin Grants has funded CLRFund $33k in the past.

• The CLRFund has taken UI/design inspiration from Gitcoin Grants, and extended them to their decentralized QF protocol.

• Given that Gitcoin’s existing Grants product is centralized, and work to decentralize is ongoing, a partnership with CLRFund could be a fruitful way to accelerate the decentralization of Gitcoin Grants - and also to make Quadratic Funding in the Ethereum ecosystem more anti-fragile (similar to how there are many client implementations of ETH2).

<- end proposal text ->

I agree with the proposal author & I believe in the above statements.

The third & final “why do this?” from my POV: Our current our thinking has led us to an explicit embrace of Pluralism & Client Diversity in the public goods funding stack - both within the QF public goods funding space, but also through the embrace of Effective Altruism, NFT public goods, retro public goods & others. Our latest thinking on Gitcoin Grants 2.0 puts this pluralism into practice by proposing interoperability with other Grants/project registries.

So if we believe in the above “why”, then the next question to my mind is “what” and “how”.

With most projects we try to interopt with, we focus on

1. social interop

2. technology interop

3. token interop

After the above discussion, I’m not sure what next steps (if any) the CLRFund community would prefer, but I am open to discussing direction together. Do others agree with our “why”? Why or why not? If yes, then “what” do we do & “how”?

My personal take is that the designs that someone put together of Gitcoin Grants using CLRFund look deeply cool + I like the idea of doing a small round together to send a signal to the market that were in it for the same mission & finding ways to coordinate. I also have a deep admiration for MACI intellectually & think it’d be cool to learn some practical zk stuff. But if the time is not right, or our values are too different, I understand also.

All my best,
owocki

Flattery will get you everywhere . Thank you for clearing this up. I was the one that originally put the designs together to model what a Gitcoin Grants round using CLRFund tech stack might look like, this was done a few months ago, as part of an internal proposal to get gitcoin to run GR12 on our tech stack.

There is 100% room for collaboration, and our values are definitely aligned (no need to quote off the original grant proposal ). Would love to hear your thoughts on grant round details (number of projects, timeline, matching pool, etc).

Small design alpha with the rest of your branding:

owocki

March 8, 2022, 6:57pm #8

thanks for doing this - i didnt realize it was you or id have given you credit in the OP - your work is very beautiful, and i think conveys the gitcoin brand well aesthetically + also the potential of a combined co-branded experience.

Would love to hear your thoughts on grant round details (number of projects, timeline, matching pool, etc).

let me circulate this thread to ppl who plan gitcoin grants rounds + see what they think a good starting place would be.

annika

March 9, 2022, 9:46pm #9

Hey all! Jumping in here representing the Grants program from the Gitcoin DAO, to chat more about co-running a round. Been chatting with @owocki and figured I’d share some of my thinking here.

To start, I’m in agreement with @auryn & @owocki that there’s an opportunity here for co-experimentation here. In terms of round framing, strong +1 on the below comment; we should be clear that this is collaborative and not competitive.

Ideal timing on our end would be June 8-23, to coincide with when we are running GR14, our next quarterly grants round. The next round would be in September, if June ends up being too tight.

I would suggest we run this as an experimental ‘ecosystem round’, probably targeting a pretty small pool (maybe $25K to start?) in a specific domain (for example: in GR13 we are running rounds for Open Gaming, NFT Ecosystem… probably something net new, TBD, open to collabing on ideas here).

We are pretty busy at Gitcoin this week kicking off GR13 which starts today, but I’ll loop back with the team and we’ll have more to share in the coming week or two.

Excited by the prospect of working together!

auryn

March 18, 2022, 6:59pm #10

I agree. This seems like a great starting point for the Gitcoin community to kick the tires on clr.fund.
Do you have any suggestions on which domain might be best suited? Given the proposed scope of the round, I want to make sure it’s something where that amount of money can still be impactful. So I think “gaming” or “NFT ecosystem” might be too broad.

There are quite a few folks in the space who do community / governance facilitation across a whole bunch of different projects, perhaps this round could be targeted at individuals whose contributions are particularly valuable to the broader community? Austin Griffith, antiprosynthesis, and Chris Blec are three examples of individuals who have received funds via Gitcoin grants in the past for their contributions to the ecosystem.

Another option, along a similar line, could be funding for new and young developers in the space. Something akin to padawan DAO but in QF form. Essentially, each recipient should detail who they are, what they’re passionate about in and around web3, and how the money will help them push toward that passion.

I guess I like the idea of a round of this scale being targeted at individuals because it seems like it still have potential to be impactful in a way that it might not if it’s funding organisations.

That said, totally open to other suggestions as well.

annika

March 21, 2022, 3:44am #11

Yeah, I love this thought. Definitely agree with being intentional about it being impactful and keeping it smaller-scale in order to do so.

I really like both of these ideas - around community / gov facilitation, and new / young devs, and think either one could work - let’s jam further on these at our next Gitcoin <> clr.fund touchpoint!

GOOD ,Is surely worth a try。

yea it should be done as soon as possible.

TL;DR - CLRFund 第 8 轮绝对是过山车。我们打破了记录，不断地达到我们的 RPC 节点的速率限制，烧毁了一些 CPU，取得了令人难以置信的效率提升，未能证明链上，创造了一些很棒的 NFT，得到了 16,000 美元的合同，收回了其余的，学到了吨，并最终为以太坊的一些最佳公共产品项目分配了大量资金。

全面审查

将这一轮称为过山车几乎是轻描淡写的。这一轮经历了很多事情，我们几乎不从哪里开始知道。

开始...

1,183 1,114 以领先优势超越在 Tornado 之前，我们进入了第 1 轮现金记录。

在第 8 个小时内，clr 无法应用程序，因为之后我们几乎启动了 RPC 名家疯狂的孩子的贡献，并立即开始使用资金。幸运的是，来自口袋。 network 的位置让我们可以访问一些容量，因此 xai 的 RPC 节点应该应用程序从那里顺利进行。

我们在第一天就打破了之前的贡献者数量记录，以 6,137 名的贡献者、投了 5 万个指标、贡献了 33,562.00 wxDai、分配了 33,594.45 wxDai 的池匹配结束了这一点。几乎每个人的新记录。

然而，就在这一轮结束后，我们遇到了一个喜剧问题。

生成证明

我们开始第一次尝试在一台普通的消费类笔记本电脑、台式机和裸机服务器上并行生成证明（为冗余而设计）。出于某种原因，服务器不断给我们一个核心转储错误。经过无数次的新发行版安装和几天的集体努力，我们意识到 Iden3 的 ZKP 库使用了一些英特尔汇编语言，而服务器使用英特尔芯片，它落后了几代，显然没有库使用的完整指令集。

Generating proofs of message processing...
Progress: 1 / 6216; batch index: 49720
Illegal instruction (core dumped)

Nevertheless, it was running fine on the laptop and desktop, with one little caveat. After letting it run for a few hours, we estimated it was going to take more than 110 days to generate the proofs.

The first bottleneck we identified was that the MACI scripts make use of a single processor thread. We couldn’t change this for this round, but we could find the absolute fastest single-thread VPS we could get our hands on (an Amazon Z1d, just in case you were wondering). This gave us a modest improvement, but we were still over 100 days.

Generating proofs of message processing...
[2021-11-01 16:43:58] 
[2021-11-01 16:43:58] Progress: 1 / 6216; batch index: 49720
[2021-11-01 17:08:54] Up to loadJson 0.01805599999999999913
[2021-11-01 17:08:54] Items : 21
[2021-11-01 17:08:54] Total 0.40599899999999999878
[2021-11-01 17:08:56] Loading circuit from /mnt/nvme1n1p1/maci/circuits/params/batchUst32.r1cs...
[2021-11-01 17:08:58] Proving...
[2021-11-01 17:09:16] Saved /mnt/nvme1n1p1/maci/circuits/params/1635786534498.proof.json and /mnt/nvme1n1p1/maci/circuits/params/1635786534498.publicSignals.json
[2021-11-01 17:09:17] Proof is correct
[2021-11-01 17:09:17] 
[2021-11-01 17:09:17] Progress: 2 / 6216; batch index: 49712

~25 minutes per batch~57.6 batches per day~107.92 days to generate proofs for this round

Then Wei Jie came to our rescue with a series of on-the-fly incremental improvements to MACI’s proving scripts. First reducing the proving time to about thirty days; still long, but much more manageable. And then later improving again down to about three days.

Three days later, proofs in-hand (and backed up multiple times) we were ready to prove on chain. But the rollercoaster doesn’t stop there.

(Not) Proving On-Chain

After generating the proofs, the next step is to prove them on-chain. The CLRFund smart contracts then use those proofs to validate how much each recipient should receive from the round.

With the proofs finally generated, we were expecting smooth sailing from here on out. Then this happened.

Submitting proofs of message processing...
Progress: 1/6216
(node:13838) UnhandledPromiseRejectionWarning: Error: transaction failed

可以查看交易返回ERROR_INVALID_BATCH_UST_PROOF = "E02"

几天的非常努力的集体努力，导致我们由于调试会话，然后发现工具，部署了我们的工具，我的 MAC 的部署出现错误。

MACI 存储库这些包含 Poseidon.sol，PoseidonT3 和 Poseidon 实现 T6，都是。Poseidon 库是 Circom 库的知识，这是设置库用于零证明的工具。

当使用它们的 compileSol 脚本编译 MACI 时，这两个空库被巧妙地替换为它们的真实对应物。

有一段时间，我们使用了子工具，我们在让任何人启动他们自己的 CLRFund 实例的前端，调轮部署了 Poseidon 库的。

每次，消息贡献者投票时，都会向默克尔树添加一个新消息，并更新消息根。

而在这个例子中，由于我们的海神库是的，更新了我们的工作状态根本无法正常工作，整个工作状态保持不变。

状态与这个结果中证明在这个根之间的不匹配意味着我们无法证明在链上。

这是什么中文？

第8轮取消

在用尽所有其他选项后，我们最终不得不取消第 8 轮。

可以声明对您的所有作者的贡献，562.0 wxDai（33 在此声明您的）。

大约有3个我们人在这个结果将轮毂中的一个安装。

这在第 8 期中所希望的结果，但不是我们肯定验证了我们的选择，因为我们有几种全新的脚本技术组合轮。设施我们学到了很多东西，它改进了设备基础、MACI 合同、证明、我们的部署流程、CLRF基金，扩展未来轮次使用自发生在。

很多人也进行了一次捐赠的团队贡献，进行了我们的下周将完全采用的应用程序，并在本次中继续使用以太坊。大的计划。

很快就会有更多信息。

泳池派对 NFT

跟前轮几领一样，在第8轮中为项目贡献AP的所有人都会收到一份。现在就认你的！

我们还一直在与ps共同执行的工作人员主题供应商的秘密任务，为我们的共同贡献者创造以物品池Pro为的POAP和NFT。

可以查询到你池面的地址，并且可以通过这个沙丘查看符合所有条件的地址。

通过以求的NFT 将抽奖的每个人资助给梦想共同的匹配者共同贡献。票证列表。

为了选择选择者输入，我们使用drand.love次1,444,000（在推特上提前发布JS）的每一个数字作为前（最左）函数的下面几张。

Math.floor((drand_randomness / 0xffff) * 8491) + 1

是的前两字节1,444,000是0x8251。

所以，金池面去... *鼓卷...票号*4323。恭喜bykur.eth。

最后，4 名贡献者各自获得了一个特殊的池前容量 NFT，其灵感来自以太坊的一些精神动物。

1. 黄金独角兽- 0xigor.eth- 10k xwDai

2. 这只虾- bitpush.eth- 20 wxDai

3. 总督- 0xd63d28282eeeace4d4d2c67ebb798f3a2ca782b1- 200 wxDai

4. 摩洛克- 0xa6a0111f3401b9ede35aca7734436e26549a9a55- 166 wxDai

非常感谢所有参与并为这一轮贡献的人。

迫不及待地想在几周内进入第9轮。

加入我们！

想建立或您为未来的 CLRFFund 轮次在Twitter 上贡献我们吗？可以在论坛、Discord、GitHub、我们找到的论坛和Telegram上。

订阅 clr.fund

将帖子直接发送给您的最新消息