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

Return proof hash on deposits #80

Open
mfornet opened this issue Nov 23, 2021 · 1 comment
Open

Return proof hash on deposits #80

mfornet opened this issue Nov 23, 2021 · 1 comment
Assignees

Comments

@mfornet
Copy link
Contributor

mfornet commented Nov 23, 2021

For the frontend it is useful to filter txs by proofs. But proofs usually are very large so indexer tools struggle to allow fast filtering under this key. What we can do on the smart contract side is find the hash of the proof (sha256(rawProof)), and when a tx is successful and the proof is consumed, return this hash which will be included in the receipt.

This will allow filtering fast through the proofs from regular indexer tools.

Note: beware that the result of this receipt can't be used to prove unexpected information on the other side of the bridge.

@mfornet mfornet self-assigned this Nov 23, 2021
@mfornet
Copy link
Contributor Author

mfornet commented Dec 16, 2021

There are some problems with this proposal. The transaction is recorded on in the middle of a sequence of cross contract calls, so it is not possible to return the proposed value at this point (so it becomes a receipt).

Alternatives:

  1. Make a parallel cross-contract call to self (in the factory) after the proof is recorded, with the hash of the proof so a receipt is emitted.
  2. Emit a log with the hash after the cross-contract call.

1 is far from ideal, since it incurs in more gas consumption, with is complex enough with regard to the number of cross-contract calls that are made in a deposit txs.

2 is less invasive, the problem is that the current indexer doesn't store logs, so it is impossible to search/filter through them.

My proposal here is to use option 2, and improve the tooling locally, such that it is possible to filter by logs.

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

1 participant