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.
- 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
- Fetching recipient information isn’t trivial - we must query events, which gets tricky if recipients have been updated
- 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.