Transaction persistence across Childchain upgrades/failures

[0x234]

During Childchain upgrade or failure events transactions that have been added to the mempool but not written into a Plasma block & published to the rootchain could be lost. The user receives a txhash response which indicates that the transaction has been successful.

• The transaction is submitted via /transaction.submit
• The client receives a successful response from the Watcher/Childchain
• This transaction is not wrapped into a Plasma block and Merkleised to Ethereum during an upgrade/outage

This mandates that the user has access to a Watcher to verify the transaction was successful. As we're having conversations around the OMG.State module now for Childchain redundancy, we could include support for atomic transactions or other such persistence mechanisms to ensure that if a txhash is returned to the user we can afford them reliability.

[Pongch]

For additional clarity on this issue: From the user (client) perspective, this issue is a previous design choice that puts the responsibility of checking if transaction is successful to the end user (tx response does not mean the transactions will be included by the operator in case of failure/ upgrade).

Pros

• solving this would mean that IF client got back a response, there is a guarantee that transaction will eventually be included
• client has no need to implement retry logic for transactions (making lighter/dumber client implementation possible)

Cons

• significant increased in latency of the response.

[InoMurko]

@Pongch two things. Ethereum clients work in a way where they return the transaction hash immediately, but it is up to the user to check if the transaction hash returns a successful result or not. Meaning that after you've sent a transaction or invoked a contract method it's up to you to check a successful result. That implies an asynchronous flow - would it suffice?

[Pongch]

I get your point, to an extent the current design was made to be congruent with Ethereum client implementation. With that said, I believe the Watcher's responsibility is different from an Ethereum client in that it can be viewed as an ultimate source of truth for a user's financial transaction (where a tx on watcher can be considered 'settled' or 'secured' ) while the flow of a typical user on Ethereum require he/she to check up on Etherscan for a certain level of guarantee (checking that n blocks have been confirmed).

There is pro's and cons for both sides. Let me hash it out more thoroughly on the comment above ☝️so we get better picture