Ethereum Finality

[ppca]

Context:
We want to make sure that we are confident about the response we get for a signature request. Currently, we poll for respond event, once we receive it, we immediately return.
Typically this is a huge problem in the context of transactions that involve funds. Because if the chain re-organizes, then the fund that's been recognized as paid would actually be dropped, or double spending can become possible.

Our problem:
In our case, since we are just a signature business, the worst thing that can happen when a chain reorganize is that the signature that was sent in the respond event that got reverted would end up not being in the blockchain. But the signature would still be valid even if it's not in the canonical chain.

Finality on Ethereum:
On Ethereum chain, let's say the block is in epoch N. It will be finalized when the first block (also called checkpoint) of epoch N+2 gets 2/3 votes from validators. Each epoch is ~6.4 mins, so finalization of a block will take 2 x 6.4 ~= 13 mins.

What products do about long finalization time:
There's a 12-confirmations rule going around in the industry. Binance for example has claimed that it typically waits for 12-15 block confirmations(~2.5 min) before crediting a user's account, but may adjust it during times of congestion (since chance of chain reorg is higher during congestion): https://www.binance.com/en/support/announcement/detail/d57bbb741ecf408c8599e97e8dcc9083.
This stackexchange discussion has more material to read about: https://ethereum.stackexchange.com/questions/319/what-number-of-confirmations-is-considered-secure-in-ethereum. Basically the more you wait, the more secure it is.

My suggestion:
I think we can give users the choice of standard v.s. strict.
a) if they want a signature with standard guarantee of finality, then in our client, we wait 12 blocks before we return the response. This is industry standard, and is not bad.
b) if they want a signature with strict guarantee of finality, then in our client, we will wait until the block that contains the respondEvent to become final.

@volovyks @jakmeier @ailisp

[ppca]

But I do want to clarify what is the major risk with our respondEvent not in canonical chain in the event of chan re-org. Because seems to me even in that case, the signature we provide is still valid? @DavidM-D

[DavidM-D]

@ppca if I burn 1 wBTC to generate a signature which withdraws a bitcoin on Ethereum, then a reordering makes that transaction invalid but the signature still exists, then I've just stolen 1 wBTC.

I like using exchanges rules, but we might have trouble measuring congestion at the moment. Long term I think we're going to have to have an optimistic and a final setting, where optimistic is historically always secure and final where we follow the spec exactly.

[ppca]

if I burn 1 wBTC to generate a signature which withdraws a bitcoin on Ethereum, then a reordering makes that transaction invalid but the signature still exists, then I've just stolen 1 wBTC.

To confirm I get it, this is the order of actions: 1) burn 1 wbtc; 2) generate signature that authenticates the tx to withdraw btc on ethereum; 3) withdraw btc on ethereum. And if reordering makes 1) invalid, but we already generate 2), then 3) can still happen. So the user gets 1 btc on ethereum without giving away 1 wbtc.

Then I guess the part that needs finality guarantee of some sort is 1), not 2). If that's the case, then we need to apply the finality rule to whatever action that need to happen before we generate a signature, which is 1) in this case. Finality guarantee of the signature respond event itself is not necessary.

[DavidM-D]

Oh yeah, the respond event being read before the chain is canonical is completely fine. My apologies, long day.

[jakmeier]

I like the approach to give the user the choice. Finality requirements very much depend on the use case and probably we should not limit it to one size fits all.

But even just 12 block confirmations, it seems to me it's already too slow for an interactive system. Before settling on specific numbers, I suggest we talk to those who will use it and ask what their preferred trade-off is.

[jakmeier]

Oh and it might make sense to consolidate the discussion between this issue about ETH finality and block reorgs in general (#265). Future code historians will thank us if there are not too many parallel discussions on the same topic at the same time. ;)

[volovyks]

We agreed to wait for finality on Ethereum and other blockchains.