Sweep proof Ethereum transaction costs reimbursments

[pdyraga]

38 focuses on ECDSA staker rewards every sortition pool member receives. Some on-chain Ethereum actions may require additional reimbursements for operators. One such action is an expensive sweep proof transaction that needs to validate SPV proof, update Bank balances, and potentially mint TBTC for various depositors.

We need to figure out how to incentivize operators to call this function.

Some potential ideas below.

Select operator responsible for submitting sweep proof based on sweep TX id

The order in which operators are supposed to submit DKG result is enforced on-chain. The first member eligible to submit the DKG result is a member with index hash(new_group_pubkey) % group_size, then also (hash(new_group_pubkey) % group_size) + 1. For example, if hash(new_group_pubkey) % group_size = 62, group_size = 64, members are becoming eligible in the following order: 62, 63, 64, 1, 2, 3, 4, 5, 6, 7, 8, ..., 61.

We could use the same approach replacing hash(new_group_pubkey) with hash(tx_id).

The problem with this approach is that the reward has to be hefty enough so that operator who was selected to submit the proof is a winner, and not a loser. This is hard because the gas price fluctuates and we never know how many transactions are in the sweep. We are constantly overpaying or operators are underpaid.

Operator responsible for submitting proofs selected for a weekly period

We select the operator responsible for submitting the proof for a week. If they do not perform their duty, wallet can decide to mark them as ineligible for rewards by voting. Another variation of this approach is when operators auction for being selected for the next week.

The disadvantage of this approach is on-chain complexity for situations when operators do not perform their duties because gas price changed and elections need to be performed again.

Willing maintainers submit the proof based on increasing reward

(This is my personal favorite but it needs to be specified more, especially by simulating gas prices and rewards the DAO can afford.)

We will let anyone submit the proof at any time and the reward will increase from min to max (or without a max?).

This has the advantage that the maintainer decides when it is profitable to submit the transaction and we do not need to adjust the reward based on the fluctuating gas price.

Another advantage is that maintainers are volunteers and can be deployed outside of Keep Network - all info they need is available on-chain. ECDSA client operators does not need to spend any ETH on sweep proofs if they do not want to.

The disadvantage is the increased complexity of the maintainer - it needs to know what is the gas cost estimate, what is the current gas price, and it needs to be taken into account when doing gas price bumps. Complexity off-chain is generally better than complexity on-chain though, given the transaction costs.

[eth-r]

I agree that 3 is clearly the best option.

Something to note about the cost is that theoretically all of these have to cost more or less the same: the reward (either directly for submitters or indirectly through "submit or lose your normal rewards") has to outweigh the cost of the gas fees. Option 1 has unreliable reward amounts so I'd expect the average reward payout to be higher; option 2 increases the on-chain complexity which again has to be paid for. Option 3 would theoretically in the absence of maintainer collusion only pay out the minimum for gas + maintainer profit regardless of what the prices are. I would recommend having a maximum (e.g. set by governance) just to cover weird edge cases like "a bug made all the maintainers go down and now the reward is absurdly huge".

Because everything costs at least as much as 3, I don't think we need to calculate "what the DAO can afford" as much as "how to make the DAO afford this".

[pdyraga]

The problem with the third option is that we do not really know when the sweeping started off-chain, so we do not know where to start increasing rewards (if we'd decide for increasing reward option) or when to start marking operators as eligible to submit the result (if we decided to enforce the result submission order).

One option to address this problem would be to have an auction every 48h or so for how much T maintainers will do "all necessary operations" for the next 48 hours. The lowest bid wins. If someone stops doing their duty, then any other maintainer can take their place and win the reward at the end. Bitcoin blocks are not that reliable when it comes to timestamps ([1], [2]) but we could have a timeout of e.g. 6 hours. Say: if someone is submitting the sweep proof to Ethereum 6 hours later than the timestamp in Bitcoin block headers says the TX was mined, it means the maintainer stopped doing their work. We would need to add some sanity checks to the bidding mechanism, for example, that the bid can not be lower than some reasonable, governable minimum. But other than that, we'd let the market decide how expensive it is in T based on the previous data and activity in the network.

Another option could be to expect depositors to provide a deposit fee in ETH. We would estimate the cost of sweep proof transaction, added some safety margin (say 25%), estimated the current gas price, and presented it in the dApp as an accumulating fee before the sweep can happen. Say: 70% of the fee is paid, we need x ETH more to proceed with the sweep. This would allow people who want their TBTC minted as soon as possible to pay 100% of the sweep fee and have their sweep executed immediately.

This approach has one more nice feature - the operator who is supposed to submit the proof is a winner if they get some % on the top of the fee they paid for submitting the proof. We do not need to rotate this role too often, or even do not rotate at all if not absolutely needed, and have that single operator, attested on-chain, to propose a 25-block target fee for the off-chain network or even propose the batch content for the sweep off-chain. This would simplify off-chain client upgrades as we do not have to worry about the consensus - one client is proposing, the rest is validating.

This approach is operator-friendly because if I am an ECDSA node operator, I want to spend as little ETH as possible and I do not want to enter TBTC<>ETH<>gas price position that I'd have to enter if I were reimbursed in TBTC and not in ETH. On the other hand, if I am a TBTC depositor, I want a simple mechanism of fees. Ideally, I'd pay with a cut on my TBTC amount/bank balance but only if I know the precise amount I'll receive before I start the deposit flow.

[beaurancourt]

I think we're good here after the work in #115 - we make this a public facing transaction according to RFC-6 that can be handled by operators (informal agreement to submit in sortition order to not front-run each other) and we refund the eth spent on the transaction.