improve(Dataworker): Remove 0-value refunds and 0-value empty-message slow fills #1957
Conversation
… slow fills Implements optimizations to [UMIP-179](UMAprotocol/UMIPs#606) The goal here is protecting dataworker from performing extra computations where no on-chain state changes can happen, in the case of 0-value refunds and 0-value empty-message slow fills.
|
+1. How do we synchronise this change on chain? I also have UMAprotocol/UMIPs#602 open - I got stalled on it because it also requires synchronisation - i.e. we need to identify when the transition would occur. We could do this by mainnet block number, or some change to the config store (bumping the VERSION field?). |
I don't think we need any special logic to be honest, we likely don't need to run the dataworker code on any previous bundles anymore (I'll check no stuck leaves) and we can time this with a bundle with no 0-value refunds/0-value slow fills. This way we can avoid the version bump |
nicholaspai
requested review from
mrice32,
pxrl and
james-a-morris
as code owners
| }); | ||
| // Do not create slow fill leaves where the amount to transfer would be 0 and the message is empty | ||
| deposits | ||
| .filter((deposit) => deposit.inputAmount.gt(0) || !utils.isMessageEmpty(deposit.message)) |
There was a problem hiding this comment.
can eventually use the isZeroValueDeposit function from the sdk once released
implements optimizations to UMIP-179
The goal here is protecting dataworker from performing extra computations where no on-chain state changes can happen, in the case of 0-value refunds and 0-value empty-message slow fills.