Build a back-end mechanism to save the off-chain Merkle roots

[cedoor]

No description provided.

[jdhyun09]

Thinking about an efficient way
When createGroup() is called, it will not save the merkle root to on-chain.(because there are no members at first.)

When addMember() is called, I will use dynamic scheduling 'Timeout' instead of 'cron' to save off-chain roots.

Once called, set the 'Timeout' to execute the task after 1 minute. (I think we need to find the right time at the production level.)
addMember() call is possible while 'timeout' is set and before task is executed.(Skip set 'timeout' if 'timeout' is already on schedule)

Stores off-chain roots of addedMember groups when executing tasks.
(@todo: Find an efficient way to find updated group root through cachedGroups)

Suggestion
After checking the off-chain group update event or finished task, how about updating group DB members at this time?
(Not update the DB at addMember() and reflect it in the DB when the root is stored on-chain.)

[cedoor]

Hey,

I will use dynamic scheduling 'Timeout' instead of 'cron' to save off-chain roots.

It makes sense! From what I understood, using that timeout within the addMember function should allow you to update the roots only when there are actually roots to be saved right?

I think we need to find the right time at the production level

Yes, we need to do it, but 1 min is ok for now imo

Find an efficient way to find updated group root through cachedGroups

I think the most efficient way is to mark the roots to be saved in a temporary key-value array (key: group id, which can be the hash of the group name, value: root hash), and then save just those roots.

After checking the off-chain group update event or finished task, how about updating group DB members at this time?

What would be the advantage? I feel like it could become more complex for no specific reason.

[jdhyun09]

It makes sense! From what I understood, using that timeout within the addMember function should allow you to update the roots only when there are actually roots to be saved right?

Yes right! It's like waking up when an actual roots change should happen. We can also accommodate many requests in a short period of time without wasting gas. Only 1 minute now, but it should not keep users waiting for a long time.

I think the most efficient way is to mark the roots to be saved in a temporary key-value array (key: group id, which can be the hash of the group name, value: root hash), and then save just those roots.

Makes sense! Temporary array would be good way. I will try this. Thanks!

What would be the advantage? I feel like it could become more complex for no specific reason.

I thought it would make sense to update the db when an off-chain root update actually occurs on-chain. But db is only used to show group information, and it seems that there is no advantage because the merkle proof generation for generating the actual semaphore proof will use cachedGroup. I agree. I will withdraw this!

[cedoor]

I thought it would make sense to update the db when an off-chain root update actually occurs on-chain. But db is only used to show group information, and it seems that there is no advantage because the merkle proof generation for generating the actual semaphore proof will use cachedGroup. I agree. I will withdraw this!

Yea, I'd say there is also another important point. Devs can decide to verify proofs off-chain, without using any contract. Those devs shouldn't wait for on-chain stuff.