The relayer must calculate the new state root and generate the corresponding proof. The proof generation process is pretty resource intensive and time-consuming, and furthermore all of the transactions and proof must be processed in a strict order since the old root value is used as an argument to a new proof. This create a potential bottleneck and a risk of interference between users, that could lead to system degradation, increased latency and so on.
There is no way to avoid the problem altogether but there could be some improvements and trade offs to be made. Specifically in the first version we introduce a so called "Optimistic client/relayer state" which seems like a a reasonable tradeoff between a much better UX and a slightly worse reliability.
With optimistic state the relayer always assumes that a transaction will be eventually mined, unless proven otherwise ( thus the name "optimistic"). This solution implies that the client sees a prnding transaction and pending balance, which could be potentially rolled back by another invalid transaction, that was processed by the relayer a little earlier. Such an invalid transaction leads to cancallation of all of the subsequent transations in the queue, so the user will have to resend those transactions once more.
A little too technical description
The client sends a transaction
The relayer
[x] receives a transaction
[x] #22
[x] #20
[x] #35
[x] #26
The client periodically synchronizes the state and sees the transaction as "pending", the balance is unchanged
The async worker 1 ( currently powered by channels m to be changed in favor of persistent message queue later)
[x] receives a transaction request from channel/queue
[x] #23
[x] #24
[x] #25
[x] #27
The async worker 2
[x] #28
[x] #29
[x] #30
The client eventualy loads the updated transaction status. If the transaction was successful , then the balance is updated, otherwise the transaction is shown as failed
Optimistic state
The problem
The relayer must calculate the new state root and generate the corresponding proof. The proof generation process is pretty resource intensive and time-consuming, and furthermore all of the transactions and proof must be processed in a strict order since the old root value is used as an argument to a new proof. This create a potential bottleneck and a risk of interference between users, that could lead to system degradation, increased latency and so on.
There is no way to avoid the problem altogether but there could be some improvements and trade offs to be made. Specifically in the first version we introduce a so called "Optimistic client/relayer state" which seems like a a reasonable tradeoff between a much better UX and a slightly worse reliability.
With optimistic state the relayer always assumes that a transaction will be eventually mined, unless proven otherwise ( thus the name "optimistic"). This solution implies that the client sees a prnding transaction and pending balance, which could be potentially rolled back by another invalid transaction, that was processed by the relayer a little earlier. Such an invalid transaction leads to cancallation of all of the subsequent transations in the queue, so the user will have to resend those transactions once more.
A little too technical description