Kleros Curate Bridge or Batch Deposits?

general
#1

When round 2 completes, we will have checked off each of the milestones before increasing the size of the funding matching pool.

However, when laying out the roadmap, we hadn’t accounted for the massive increase in gas prices and volatility over the past few months.

We’re now at a crossroad with a few different options on how to proceed before increasing the matching pool:

  1. Stay on xDai and (wait for Kleros to) develop a bridge contract to read Kleros Curate data from mainnet.
  2. Stay on xDai and deploy some alternate to Kleros on xDai.
  3. Move back to mainnet now and just deal with gas price volatility for the time being.
  4. Implement a scaling solution (Barry’s Batch Deposits, for example) prior to moving back to mainnet.

My preference is option 4, since this will give clr.fund the most long-term benefit. There is also a chance that Kleros will implement a bridge in the mean time so we can query the mainnet contracts from xDai.

1 Like
#2

Option 4 is my preference as well. Batch deposits along with other gas usage improvements will be implemented in MACI 1.0 which is currently under development.

#3

Do we have any idea of an ETA on MACI 1.0?

#4

image

Given this discussion, perhaps we should do 1 or 2 while we wait on batch deposits?

This may not always be useful for the canonical instance, but it will very likely be useful for other instances that want to run on other networks / L2s.

It would be nice if the xDai instance of clr.fund could persist, even after we move back to mainnet (perhaps funding xDai public goods), in which case 2 might be the preferable option.

#5

FYI, batch deposits (which we’re calling the AccQueue technique) does significantly reduce the gas cost of signups and voting, but not massively. The fundamental blocker is the cost of our snark-friendly hash function which is expensive in the EVM.

In the current development version of MACI 1.0, signups cost 182051 gas (compared to 372477 gas originally) and publishing a message costs 307348 gas (compared to 502659 gas). As such, I’d recommend a L2 solution either way.

#6

Another feature that can help with reducing gas costs is allowing the coordinator to relay a batch of signups on behalf of a group of users. Same with voting. I’ll have to get back to you with the gas benchmarks for these.

2 Likes
#7

Is this cost something that could potentially be reduced in an upcoming hardfork?
If so, do you think it could/would be reduced enough to make a more significant impact on the cost of these transactions?

I agree. This is significantly cheaper, but I think it would need to be an order of magnitude cheaper to not be a significant blocker for many potential contributors.

At the current ETH price (~$644) and gas price (~100 gwei), that’s about $30 in transaction fees for each contributor.

tx gas ETH USD
Signup 182,051 0.0161 $11
Message 307,348 0.0307 $19
Total 489,399 0.0468 $30

@weijiekoh do you have any insight or preferences on which L2 options would be most suitable for this?

Does this feature offer gas savings beyond the amortization of the base transaction fee? If not, it would only end up saving ~$2 per user in the above example.

#8

I think optimistic rollups are the best scaling solution for clrfund. There are two projects that offer full EVM compatibility:

1 Like
#9

I’m sure we could get on Optimism’s testnet if we ask nicely. I’ll ask Karl.

1 Like
#10

One of the features that we will need on rollup chain is L1 <=> L2 communication mechanism (it is required for integration with Kleros registry which is on L1). However, according to docs it has not been yet implemented on either chain:

In our initial Rollup release, we are not supporting transaction calls from contracts in an Arbitrum chain to Ethereum contracts. In the future, support for this functionality will be added.
https://developer.offchainlabs.com/docs/ethereum_interoperability#transaction-calls-from-arbitrum-to-ethereum

Communication between L1 and L2, also known as deposits and withdrawals, are not yet implemented in the OVM.
https://docs.optimism.io/developer-documentation/erc20-tutorial/limitations#parent-child-chain-communication

Additionally, we’ll need support for block.number and/or block.timestamp global variables. Arbitrum supports them but OVM doesn’t.

1 Like
#11

If Kleros or 1Hive will deploy their subjective oracles to xDai, we can try to integrate with them. However I’m not interested in long-term maintainance of any xDai infrastructure.

There are other things that can be implemented while we’re waiting for a better scaling solution:

1 Like
#12

I think we’ll be able to use 1Hive’s TCR when it’s ready. Thinking longer-term though, I wonder if it is worth us looking into deploying our own if we decide to deploy on a rollup chain. (assuming there is not one already available on the L2 that we settle on).

Here are some other ideas.

  1. The allocator contract that Austin and I were working on the other day
  2. Load project meta from ENS records
  3. more robust key management
  4. EPNS integration
  5. Gnosis Safe CPK integration (so we can batch transactions)
  6. Subgraph
  7. Leaderboards
  8. Move tx modals to the cart drawer so users can interact with the app while they wait for confirmations
  9. create a constant receiving address that can be approved or transferred to.
1 Like
#13

How do you want to use it in clrfund?

#14

clr.fund will receive funding from it.

#15

But clrfund already can receive funding from it. Nothing needs to be done on our side to support it.

#16

I know, I’m more talking about the allocator contract itself.
It should be reviewed, audited, and improved if there are any issues.

#17

Someone asked about the state of L1 <=> L2 communication on Offchain Labs Discord, and they replied that they are actively working on it:

Yes, we’re actively working on that. We’ll support that in our mainnet release, if not earlier.

When implemented, this should allow us to trustlessly register recipients from Kleros TCR on mainnet.

#18

@xuhcc, just wanted to share this repo from Optimism.
https://github.com/ethereum-optimism/optimism-integration

Apparently it has everything we need to integrate and test clr.fund with Optimism.

I’ll try it out at some point over the next week. Still don’t have an ETA on when optimism will go live though.

#19

Hi!

Apologies for the late response, I was heads down building out v1.0.

I agree with the direction of using L2. If you’re still eyeing the OVM, please keep in mind the caveats involved: https://hackmd.io/@scopelift/Hy853dTsP#the-porting-process

BTW, I can further reduce the gas costs for signups and voting to:

Signup gas cost: 151158
PublishMessage gas cost: 137202

This can be achieved by using SHA256 instead of our snark-friendly hash function for the first 2 levels of the trees, and also using SHA256 to hash messages. This saves several dozen thousand gas per transaction. The tradeoff is that message processing and vote tallying will be more computationally intensive. A conservative estimate is that the number of circuit constraints will double.

I doubt that any upcoming hardforks will reduce the cost of snark-friendly hash functions because the community strongly values consensus safety at the base layer.

2 Likes
#20

A conservative estimate is that the number of circuit constraints will double.

FYI, I think this technique would more than double the number of circuit constraints. I’m not going to prioritise it for v1.0 but I’d look into using SHA256 (or even Blake2s) to save gas on message hashing (which can certainly bring the gas costs of PublishMessage to around 138k gas).

2 Likes