RPC endpoint for querying cheque information

[holisticode]

#1444 is about defining and implementing the cheque exchange protocol.

This issue is about creating and implementing an RPC endpoint to query cheque information. Currently this information includes:

• Number of pending cheques (order by debit/credit)
• Cumulative amount of pending cheques (order by debit/credit)
• Number of cheques cashed in
• Cumulative amount of cheques cashed in
• Number of cheques issued
• Cumulative amount of cheques redeemed
• List all cheques
• See cheque information per peer
• Get individual cheque information (probably by peer)

It should be evaluated if this set of information is sufficient / appropriate. Node operator stakeholders could be interviewed to get to more targeted / relevant info sets.

[mortelli]

Updates & comments:

* Number of pending cheques (order by debit/credit)

I don't believe we currently have an indicator of which cheques are pending and which are not. I am assuming pending means not cashed.

If we want this for both cheques our own node writes and checks written to it, then asking the chequebook contract might be the best solution (if this is possible).

Relvant issue: #1634.

* Cumulative amount of pending cheques (order by debit/credit)

See above.

* Number of cheques cashed in

As far as I know, we don't have this information on the go side. I'm not sure whether this can be deduced in the smart contract.

We could divide the amount of honey over the payment threshold, but as I understand it, both the eth-to-honey conversion and the thresholds can fluctuate. This would derive in eventually bogus results.

* Cumulative amount of cheques cashed in
* Number of cheques issued
* Cumulative amount of cheques redeemed

Same as above. Note that we could probably deduce this on the go side and save (our version of it) in the store, but it seems a better idea to get it from the chequebook if possible.

* List all cheques

This is covered (or is being implemented) by the functions: SentCheques, ReceivedCheques and Cheques functions.

* See cheque information per peer

This is covered by the SentCheque, ReceivedCheque and PeerCheques functions.

* Get individual cheque information (probably by peer)

Not sure how this one differs from the previous one.

It should be evaluated if this set of information is sufficient / appropriate. Node operator stakeholders could be interviewed to get to more targeted / relevant info sets.

I invite @ralph-pichler, @Eknir, and anyone else who would like to chime in, to comment on both my notes above as well as this last point.

Relevant PR: #1863.

[ralph-pichler]

* Number of pending cheques (order by debit/credit)

I don't believe we currently have an indicator of which cheques are pending and which are not. I am assuming pending means not cashed.

If we want this for both cheques our own node writes and checks written to it, then asking the chequebook contract might be the best solution (if this is possible).

We cannot ask the contract because it doesn't know about the cheques until they are actually cashed. For now we don't store which cheques are pending and which are not (it doesn't make sense anyway if we cash everything immediately). Once the cashing logic is rewritten this should become possible, then we can do it for cheques we received. Not sure if this makes sense for cheques sent.

Same for "Cumulative amount of pending cheques (order by debit/credit)"

* Number of cheques cashed in

As far as I know, we don't have this information on the go side. I'm not sure whether this can be deduced in the smart contract.

We could divide the amount of honey over the payment threshold, but as I understand it, both the eth-to-honey conversion and the thresholds can fluctuate. This would derive in eventually bogus results.

I'm not sure this is a useful metric. There is little reason to care about the number of cashed in cheque, only the latest cumulative amount is really relevant. The only useful purpose I see would be to check if we pay too much fees by cashing too often. In that case it might be more useful to keep track of how much we paid in fees.

* Cumulative amount of cheques cashed in
* Number of cheques issued
* Cumulative amount of cheques redeemed

Same as above. Note that we could probably deduce this on the go side and save (our version of it) in the store, but it seems a better idea to get it from the chequebook if possible.

The number of cheques can only be counted from the go side. Tracking the Cumulative amount of cheques redeemed (I assume that means cheques that counterparties cashed in) is possible but would require much more sophisticated tracking of our chequebook contract than we have right now. It's also not that useful, we should consider the money spent the moment we issue the cheque anyway.

Cumulative amount of cheques cashed in is difficult right now but at some point we'll have to save the last cashed cheque (or at least its cumulative) in addition to the last received. Then we can just do that on the go side.

* List all cheques

This is covered (or is being implemented) by the functions: SentCheques, ReceivedCheques and Cheques functions.

That should be sufficient for now. Perhaps later we can add the last actually cashed cheque to the set of "all" cheques.

[mortelli]

@ralph-pichler thank you very much for your feedback.

given that at least some of these have to wait, i am going to promote PR #1863, which is big enough already.

i suggest we leave this issue open until we either discard or implement all of the calls (we can add more, too).

more feedback is welcome

[Eknir]

I have read this feed and want to propose one RPC method which is not discussed here but very useful. As a node operator, you must have the possibility to query the unspent balance of your chequebook.
This metric is calculated by subtracting the cumulative value of all cheques sent (info from the node) from the total amount ever deposited in your chequebook (info from the chequebook contract). Obviously, this is under the assumption that all cheques are sent by the Swarm process that lists this metric, but I think we can assume this.

This metric is informative for the user because it will allow him to know when / if he has to top up and/or how much money he can withdraw without risking that cheques will bounce.

[mortelli]

We've decided to close this issue with the current set of implemented cheques RPC calls:

• Available Balance
• Peer Balance
• Balance
• Peer Cheques
• Cheques

If needed, individual issues can be opened to add new calls or modify—maybe remove—existing ones, or their implementations.

Regarding the remaining suggested calls:

Number of pending cheques (order by debit/credit)

Neither the go nor the smart contract side currently supports querying this information. This can be revisited once the cashing strategy evolves.

Cumulative amount of pending cheques (order by debit/credit)

Neither the go nor the smart contract side currently supports querying this information. This can be revisited once the cashing strategy evolves.

Number of cheques cashed in

As of now, we have little use for this information. If we care about checking if we pay too much fees by cashing too often, we should instead track how much we're paying in fees.

Cumulative amount of cheques cashed in

Can be done from the go side, but we don't actively store this data. We currently have no pressing need to implement this one, but it can be revisited if needed.

Number of cheques issued

Can only be done from the go side, but we don't actively store this data. We currently have no pressing need to implement this one, but it can be revisited if needed.

Cumulative amount of cheques redeemed

Interpreting this as cheques that counterparties cashed in: it's possible, but requires changes to the contract that are not worth the hassle right now. It can be implemented once there is a pertinent need.

[holisticode]

Although I agree to the current state and to close this issue, we should really be thinking about historical data for the user. I do think it is important for the end user to be able to monitor and gather analytics about the node's performance.

I suggest creating a new issue which focuses on that.