Open 0x234 opened 5 years ago
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
Cons
@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?
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
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.
/transaction.submit
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.