You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the signal service relies on the commitment (stored in the commitment store) to be a state root, however in reality commitments might in fact be a block hash or a hash for two values (which might include the state root).
We have no mechanism to extract a state root in the case the commitment is something other than a state root, therefore our current implementation might not work.
I see two options:
Make the verify signal function more generic as to what a commitment is, perhaps have a helper function to get the state root from the commitment (this might require additional info)
Decide now what a commitment is, this might impact how we verify signals
I think i prefer option 1 so we can remain unopinionated as to what a commitment is although finding a generic impl might be hard.
The text was updated successfully, but these errors were encountered:
Currently the signal service relies on the commitment (stored in the commitment store) to be a state root, however in reality commitments might in fact be a block hash or a hash for two values (which might include the state root).
We have no mechanism to
extract
a state root in the case the commitment is something other than a state root, therefore our current implementation might not work.I see two options:
I think i prefer option 1 so we can remain unopinionated as to what a commitment is although finding a generic impl might be hard.
The text was updated successfully, but these errors were encountered: