Recipient data storage

general
#1

Hey folks - I’ve been investigating the recipient registry contracts for the potential upcoming Eth2 CLR round. I’m focusing on the SimpleRecipientRegistry contract (which I think we’re most likely to use) but I suspect this should be consideration for other registry contracts as well.

This relates to a couple other discussions (e.g. ENS to identify recipients, recipient edit-ability) but I want to focus specifically on the topic of data storage for recipient metadata.

My understanding is that currently any metadata around a recipient is stored directly in the smart contract via the addRecipient function. I’m curious to know why we decided on this approach & what alternatives we’ve considered.

There’s a few issues I see with this approach.

  1. The information isn’t easily editable (am I correct this would require txs to remove & re-add the recipient with the updated metadata?) which requires additional gas
  2. Fetching recipient information isn’t trivial - we must query events, which gets tricky if recipients have been updated
  3. This largely prevents “rich” recipient profiles - e.g. I imagine embedding hyperlinks within a project description would be quite painful

I suspect there may be alternatives here, e.g. what if we did something as simple as storing recipient data in a JSON/CSV file within the Github repo? What vulnerabilities would this open up? The data would no longer be as tamper-proof as on chain data… but at least for the SimpleRecipientRegistry, the data is already centrally controlled by an owner, right? Seems to me that’s not much different than centralized CODEOWNERS in a Github repo.

Thoughts? What details am I missing? Appreciate any input or insight into this! Thanks in advance.

1 Like
#2

The related discussions I mentioned:

My post was limited to 2 hyperlinks :smirk:

1 Like
#3

You can create another recipient registry that will store only recipient IDs and no metadata. Here’s the recipient registry interface: https://github.com/clrfund/monorepo/blob/develop/contracts/contracts/recipientRegistry/IRecipientRegistry.sol
Then the GUI can retrieve metadata from your server by recipient ID.

2 Likes
#4

This approach was chosen for simplicity and is modeled on Kleros Curate’s TCR design.

That is correct. We’ve had a lot of discussion around this limitation, it’s far from optimal. Kleros is planning to add edit functionality to their TCR at some point soon. I’d like to see us do the same for our simple registry. The gas costs are only really a concern if this is running on mainnet. As a rule of thumb, if the network is too expensive to change the metadata in the simple registry, it’s probably not a suitable network to run clr.fund on.

I disagree. It seems like it would be pretty trivial to add a getter function to this contract.
A less trivial approach would be to build a subgraph for the registry.

Only in so far as there is a practical (and maybe financial) limit on the amount of data that can be included in a transaction. There is no reason that the descripiton could not be markdown formatted and you could always add extra fields to the metadata.

Absolutely. One alternative that I suggested a while back was to store metadata on ENS text records. Similar to @xuhcc’s suggestion above, the registry would only need to store an ID, an ENS name in this case.
This would allow for much lower friction editing of metadata without a trust compromise, although it would still be cost prohibitive for many projects as ENS is pricey on mainnet.

Storing the metadata in a Github repo is probably viable too, although I imagine it would make for a painful user experience if the only way to modify metadata is with a PR.

2 Likes