search

unlock-protocol / unlock

Ʉnlock is a protocol for memberships built on a blockchain.
https://unlock-protocol.com
MIT License
839 stars 248 forks source link

Lag after transaction has been submitted and transaction has been "detected" #1394

Closed julien51 closed 5 years ago

julien51 commented 5 years ago

As part of the web3Service split, we have introduced a clear distinction between the act of "sending" and transaction (thru walletService) and reading a transaction (thru web3Service). We also only use data from web3Service to actually build objects such as the locks or the keys, in order to make sure each object can always be constructed after a browser refresh for example, since no data is stored anywhere.

Right now, we also identify the changes performed by a transaction only when it has been mined... and mining takes from a couple seconds to a couple hours! During that time, the user has no idea that their transaction is actually happening... and this is annoying (to say the least!).

The initial approach I was thinking about was to building the object on sendTransaction. This would solve the problem of the lag... until the user refreshes, where all data would be lost until the transaction has been mined.

Another approach would be to look for pending transactions (not mined yet) and decode them based on the receipient's address (this can help us determine which smart contract the transaction was sent too and which method was invoked).

julien51 commented 5 years ago

This will be useful to fix https://github.com/unlock-protocol/unlock/issues/1198

julien51 commented 5 years ago

There are 3 "states" for a transaction:

  1. submitted (sent to the network, not visible on all nodes yet). Lasts at most a couple seconds.
  2. pending (all nodes know about it, but has not been mined yet). This can last hours, depending on gas prices
  3. mined (added to a block).

The problem exposed in that issue are for 1. and 2. I have for now pushed 1. to the sideline and focused on 2.

For 2. there are 2 sub-problems: a. Knowing about the transaction, b. Knowing what the transaction is about.

Knowing about the transaction is not a problem until the user refreshes the page. However, once the user reloads the page, we have no way of knowing the hash of the transaction (or even that one exists) . One solution considered was to see if there was a way to query the user's wallet (metamask), but that would fail if the user used another device, and there does not seem to exist a clear API for this.

The second solution was to use our locksmith for this so that as soon as a transaction has been created, it is sent to locksmith, and as soon as a user is identified, we retrieve the past transaction hashes for them. This has been implemented (https://github.com/unlock-protocol/unlock/commit/a4d4f988661498e61b02092b7c2a23dc93e8eccb and https://github.com/unlock-protocol/unlock/pull/1455).

For the second part of the problem (knowing what the transacion is about), we introduced a way to parse the input of the transaction in web3Service. See https://github.com/unlock-protocol/unlock/commit/4db983ec260450ade0044d0f5348d4ef7fb79aa1

This then leaves us to solve the part 1. of the initial problem: being able to show what a submitted transactions's content is about, until it becomes "pending".

The only way to do that is to pass the input for a newly created transaction from the walletService to the web3Service.