Transaction Status RPC #1
Conversation
…n from Rust RFCs with modifications
|
RPC isn't a good match for transaction status. Clients shouldn't poll for status, they should subscribe to status updates and get them pushed to client, using e.g. WebSockets. |
|
Agree, but one off RPC request should be possible, too. |
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| One paragraph explanation of the feature. |
There was a problem hiding this comment.
improvement, process or standard
| @@ -0,0 +1,77 @@ | |||
| - Feature Name: (fill me in with a unique ident, `my_awesome_feature`) | |||
| @@ -0,0 +1,77 @@ | |||
| - Feature Name: (fill me in with a unique ident, `my_awesome_feature`) | |||
| - Start Date: (fill me in with today's date, YYYY-MM-DD) | |||
| - NEP PR: [nearprotocol/neps#0000](https://github.com/nearprotocol/neps/pull/0000) | |||
There was a problem hiding this comment.
is this suppose to be updated after you created PR? Probably useful to mention somewhere that process is:
- create PR 2) update "NER PR" field
| - Feature Name: (fill me in with a unique ident, `my_awesome_feature`) | ||
| - Start Date: (fill me in with today's date, YYYY-MM-DD) | ||
| - NEP PR: [nearprotocol/neps#0000](https://github.com/nearprotocol/neps/pull/0000) | ||
| - Issue: [nearprotocol/<relevant_repo>#0000](https://github.com/nearprotocol/<relevant_repo>/issues/0000) |
There was a problem hiding this comment.
Should mention that this is not required and also can be many
| 3. Add your NEP to your fork of the repository. Template TODO. | ||
| 4. Submit a Pull Request to [this repo](https://github.com/nearprotocol/NEPs). | ||
|
|
||
| * For the NEPs repo; |
There was a problem hiding this comment.
what does this line mean?
was it suppose to be "To contribute to NEPs repo:" without *?
| @@ -0,0 +1,118 @@ | |||
| - Feature Name: `transaction-status` | |||
| - Start Date: 2019-06-11 | |||
| - NEP PR: [nearprotocol/neps#0000](https://github.com/nearprotocol/neps/pull/0000) | |||
| [motivation]: #motivation | ||
|
|
||
| Detailed transaction status is required for good UX as users want the status being updated the second they submit a transaction until this transaction is completed entirely. | ||
| All UI tools including console-based tools, like NEAR shell would use this feature. |
There was a problem hiding this comment.
and Near SDKs (like nearlib)
| will return the following (notice how we allow incomplete hash in the RPC): | ||
| ```json | ||
| [ | ||
| {"ReceivedByNonValidator": {"node_id": "some_node_id"}}, |
There was a problem hiding this comment.
we need a convention here - are we using camel case or underscore.
| create overloads of this RPC based on verbosity. So the following RPC call `tx_details` with `{"tx_hash": "04ffa4f"}` | ||
| will return the following (notice how we allow incomplete hash in the RPC): | ||
| ```json | ||
| [ |
There was a problem hiding this comment.
This format doesn't really make sense to me.
Who are you going to query to get this information? Are we going to query the whole network to find which nodes see what?
In reality transaction is in:
- Unknown state
- In mempool of the given node we query. Here we may have extended mempool for non-validating nodes (right now we don't have that), just so that this nodes can resend transactions if they were not received by current validators (right now it's up to the end client to resend). But the node doesn't really know if it was received (anything that validators says it's not enforceable anyway), so they must decide to resend them based on received chunks back. There is also caveat that this node may not track the shard this TX is aimed at, meaning it actually may not know at all if this Tx was included.
- included in chunk
- included in block
And then for each receipt DFS: - receipt included in chunk (e.g. we transition into this, when receipts from previously produced chunks actually got processed by another chard)
- receipt included in block
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| If the user does not own the node that they use to query such information from Wallet or Near shell then it is unclear what | ||
| would be the incentive system for such nodes to reply. It is clear that we need some incentive system for non-validating nodes to |
There was a problem hiding this comment.
the cut of transaction fee for propagation is generally interesting idea, but requires a lot more economics to work. Saito built their whole protocol around such idea actually.
There are problems with censorship and centralization in this case - when big nodes who are validators will be "cheaper" to send to (because they will be validators and won't take the cut of re-trasmission) - so people will send to them and they can freely censor what they want. And there will be high geographic grouping (because server around the corner will be way faster to send TX to), which means political censorship will be enforce on those. Now, you still can send to other nodes in the network, if you think the local one censors you. But it's possible that by the fact that central nodes will become such dominant they will actually gain % of the stake and just push out independent nodes.
|
I would like to put my 2 cents into the RPC & PubSub design. I have designed a few semi-public APIs over the course of last years and my experience is that it is cumbersome to add PubSub into the RPC design after the fact. PubSub requires to manage a ton of connections and keep track of what you should send there. There are well-established storages for messaging (*MQ [RabbitMQ, ZeroMQ], Kafka), and even feature-complete solutions for PubSub + RPC APIs: WAMP, NATS. I chose to use WAMP for NEAR Explorer, and it works fine there. There is also Rust implementation of WAMP router (i.e. the server which handles the connections), so we can integrate it into nearcore; another approach would be to deploy WAMP router as a standalone component and just push events from nearcore (this keeps nearcore simple to audit, but the deployment gets another moving part). UPDATE: There is also RSocket from Facebook, but it does not have implementations for Rust and Python (if that matters) |
ilblackdragon
changed the title
|
Closing it until we get back to implementing extended transaction status. CC @frol |
No description provided.