eriktrautman
commented
5 years ago Transcribing @nearmax from discord:
Max:
given our system it's probably pointless to report states before "Transaction executed in block 12345"
@vgrichina I think it actually makes sense to at least report: transaction received by the validator. Because in rare cases the progress can get stuck there, specifically when validator censored it.
it is important thought that when transaction reported "success" it's still not necessary final and how much finality we need is going to be app-specific but for payments we definitely need to be explicit on whether it can be trusted (but it's more important on receiver side obviously)
@vgrichina This is very true. Because of the shards/chunks transaction can make into a block but can still be challenged within 20 blocks if it is a double spend. So for crucial transactions there is a stricter finality criteria. This however does not mean that all financial transactions will need to wait for 20 blocks. Only those that are super expensive.
What I imagine the naive implementation is something like a list of grayed-out checkboxes with state descriptions that get highlighted then checked off with a green checkmark in realtime as the transaction propagates through the various states so the user can see it happening. Then it disappears to the confirmation screen when all is well. But that's ultimately @Jake 's realm
@Eriktrautman This sounds like a very good UX.
so what I'm saying that for short/medium term the first such checkbox would be "included in the block", cause managing it more low level going to be too much work for almost no gain (cause this happens quickly enough).
[12:55 PM] Max: @vgrichina I agree, let's start with high-level statuses and gradually add granularity as we go. Many fine-grained statuses will be implementation specific, so as we complete the system we will be figuring out what to add.
Do you know if we get any kind of receipt when a transaction is received by a node? Because if your WIFI is down going through a tunnel and you don't know that, you might hang and not even know if you're waiting for it to send and should refresh the page or it's already been received, just hit congestion, and refreshing would double-send.
@eriktrautman A simple answer is what @Bowen said -- RPC is a two-way communication and supposed to return the status, like Ok or Err. However, in a long run users are not going to be submitting transactions directly to the validators (because validators are few and how more important things to do like validating blocks) so transactions are going to be submitted to the p2p network where they are going to be relayed to the validators. This gets tricky since we might not be able to get a confirmation status relayed back from validators to the user.
[12:55 PM] Max:
I don't know how they actually work behind the scenes. I suppose we could do it by polling constantly for a transaction's status... It'd be ideal if we could just wait to receive a call when that status is updated to avoid the network traffic.
@eriktrautman With transactions submitted through p2p (oppose directly to validators through RPC) this is going to be tricky since when user submits transaction to non-participating node and asks to relay it the node has no direct incentive to reply back with the status. Unless, we implement mechanism where user's wallet chooses one node to submit transactions to and then rotates to a different one if node is not cooperative. This will create some incentive to cooperate with user's wallet if we also add a small reward for non-participating node that received the transaction.
That's a good question. I think we'd have to think through specific cases for one versus the other and see what emerges. @eriktrautman We REALLY need the list of all use-cases including access keys, proxies, cross-contract calls speced out in some doc or file.
MaksymZavershynskyi
Story
As a user who has just clicked "confirm" to authorize a transaction (either inside an app or sending in wallet), I want to know what the status of that transaction is until it's final so I can understand why it's taking so long.
This is especially important for most naive UI's which will be implemented synchronously and thus have the user staring at a waiting screen for some period of time.
See NOTES below for discussion.
Acceptance Criteria
Assets
NOTES
When we send money, what waiting states do we actually have access to (now or possible in the future)? For example:
Transaction sent
Transaction received/acknowledged by the network (a node)
Transaction in block mempool (or equivalent)
Transaction executed in block 12345 [link]
Transaction was success with return_value_or_state_change or failure for reason.
This is important so we can provide users with clarity around what they're actually waiting for while we're making them wait for things.
Also important that some apps have different finality than others, so their UIs might prefer to implement immediate finality or they might wait until X blocks (or other criteria) passes before showing the user a confirmation. That's fine -- let's expose the raw blockchain stuff to start with and assume immediate finality and if the app doesn't want this, they can use those same hooks and modify the UI on top to wait a bit longer.
This is inspired by how AJAX has a clear 5-step state machine that defines its status and allows developers to build waiting icons and UI notifications against those states.
It sounds like there are RPC endpoints for transaction status so this can be done via polling. Can it be done via the nodes sending something back to avoid constant read pings?
Complication: For transactions that generate receipts for later, what is finality anyway? How do we model states for something that's inherently unclear when it will end (how many calls deep it will take, and they're async)?
Visual inspiration
These are dumb loading bars since they tend to only have a "% complete" but are the basic idea: https://www.downgraf.com/inspiration/25-beautiful-loading-bar-design-examples-gif-animated/
What I imagine the naive implementation is something like a list of grayed-out checkboxes with state descriptions that get highlighted then checked off with a green checkmark in realtime as the transaction propagates through the various states so the user can see it happening. Then it disappears to the confirmation screen when all is well. But that's ultimately @Jake 's realm