Globally deduplicate *ReceiverSeen events

[CodeSandwich]

The problem

When multiple users have identical drips or splits configurations, DripsReceiverSeen and SplitsReceiverSeen events are emitted for each of them, which wastes gas and causes noise in events.

The solution

The simplest approach is to add to storage a mapping(bytes32 => bool) seenHashes. Whenever a drips configuration is configured, check the value of seenHashes[configHash]. If it's true, do not emit the *ReceiverSeen events. If it's false, set it to true and emit the events.

The advantages

• If a configuration contains just 2 or more items and it has been used before, gas is being saved. Not emitting the events saves more gas than costs reading the content of seenHashes.
• In setSplits if a configuration has been seen before, we can assume that it's valid and we don't need to analyze it.
• Additional data can be store in seenHashes. For splits it can be the sum of the weights, this way function Splits.splitResults doesn't need to accept currReceivers anymore and by extension neither does DripsHub.collectableAll.
• Consumers of events don't need to perform any deduplication.

The disadvantages

• If a configuration hasn't been seen before, it costs 22K gas to set the value of seenHashes. This cost may never be recouped if the configuration is short or not shared by many users.

[witwiki]

Hi there! I see this issue has been open since June 3rd. Is it still open to work on?

[CodeSandwich]

Hi @witwiki, First of all, thanks for stopping by! Yes, it's still open, nobody's working on it. It's currently frozen, because we haven't managed to find a good solution. The proposed one would work, but in the end usually it wouldn't make much sense, see the disadvantages. Do you have a better design in mind?

[witwiki]

Not particularly. I'm still trying to understand the contracts and how they related. I thought I'd give it a try since I've gone beyond the basics of solidity.

[witwiki]

Hey @CodeSandwich, I had a question about the configs. Sorry still trying to figure this out.

Are configs meant to be an open ended feature where others attributes would be added in the future in addition to drips and splits?

Appreciate any help with understanding it, cheers :-)

[CodeSandwich]

I'm not sure if I understand the question, but the drips and splits configurations aren't supposed to get extended with new attributes. We also don't plan to add more features on top of dripping and splitting.

[CodeSandwich]

This issue seems unsolvable without huge costs, closing.