Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep track of submitted logs #6

Open
s1na opened this issue Sep 22, 2018 · 1 comment
Open

Keep track of submitted logs #6

s1na opened this issue Sep 22, 2018 · 1 comment

Comments

@s1na
Copy link
Member

s1na commented Sep 22, 2018

Now

Any log can be submitted to network infinite times, and the subscriber would be invoked every time.

Goal

  • Keep track of every submitted log.
  • Check if log has been submitted before in submitLog.
  • And let relayers know (by emitting events) which ones have been submitted.

Possible solutions

  • Store the root of a sparse merkle tree on-chain.
    • Relayers would have to, in addition to submitting log proofs, provide proof of non-inclusion of log in the SMT.
    • Contracts wouldn't be able to query ethbase to see if a log has been emitted recently.
    • Each block, only one transaction would modify the merkle root, and the rest of txes will fail, as their proof becomes invalid. Discussion regarding this issue.
@HarryR
Copy link

HarryR commented Sep 30, 2018

Building any tree structure on-chain will be more expensive than a simple dictionary/mapping check of 'has log been submitted before'. Keep it simple, if you want to prevent replays, use a dictionary of 'events which have been relayed'. e.g. building a tree on-chain will cost at least O(log2(N)) storage operations per insert, whereas just keeping a simple mapping is O(1). The average and worst cases for on-chain SMT are much higher than the KISS solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants