feat(SpokePoolClient): Append messageHash to deposit events #846
Conversation
| @@ -54,6 +56,7 @@ const SortableEventSS = { | |||
| }; | |||
|
|
|||
| const V3DepositSS = { | |||
| messageHash: defaulted(string(), UNDEFINED_MESSAGE_HASH), | |||
There was a problem hiding this comment.
defaulted() will establish an instance of messageHash with the value <UNDEFINED_MESSAGE_HASH> (""). I looked at superstruct for ways of dynamically assigning this (i.e. computing on the fly based on the rest of the object). It kinda seems like superstruct can support this, but we have a lot of nested structures in our object validations and I lost patience with it.
In any case, this is backwards compatible because we can populate messageHash values for existing deposits that were not posted with the field. I'd also consider dropping it from data posted to arweave, since there is some odd redundancy between message and messageHash, but we don't expect to verify one from the other when we pull them down simultaneously.
| -1, | ||
| toBN(-1), |
There was a problem hiding this comment.
It seems like this was probably left out of the recent BigNumber depositId migration.
In anticipation of needing to use the deposit messageHash when matching fills to deposits, precompute the messageHash when deposit events are ingested.
`getRelayDataHash()` can no longer be used for hashing a SlowFillRequest because the new event types emit `messageHash` instead of `message`. This is OK in the SpokePoolClient because it only needs a very simple method of indexing SlowFillRequest events.
…depositMessageHash
pxrl
force-pushed
the
pxrl/depositMessageHash
branch
from
1476a3c to
696ec18
Compare
In anticipation of needing to use the deposit messageHash when matching fills to deposits, precompute the messageHash when deposit events are ingested.