Messing with the new data types: Pointer, GraphEntry, Scratchpad

1

As I start using the new data types I’ll share comments and ask questions here. Feel free to join in if you are working with the above types.

Some comments about pointers

The purpose of the ‘count’ provided when creating a pointer is not clear, but I infer that in order to update a pointer you must provide a higher value for ‘count’ than the current value on the network. See:

  • is that correct? If so, when you get a pointer you increment the count by one before putting it. So I think the process for getting updating and putting a pointer involves making a new pointer using ‘count() + 1’ from the old pointer.

  • count is u32 and will eventually wrap around to zero, so pointers have a limited life of 2^32 = 4,294,967,296-1 updates - assuming each update increments the count by one. If those were seconds that’s about 136 years which seems fine… although with acceleration compute speed we might in a few years see a pointer being updated tens, hundreds or maybe even thousands of times per second. I’m less concerned having made this calculation, but still wonder if count should be u64.

Uneccessary use of SecretKey

I was curious why some APIs require the SecretKey of the owner, but see that this appears to be changing so I’ll list ones that still require but do not need SecretKey:

Client::pointer_cost()
Client::graph_entry_cost()
Client::scratchpad_cost()
Client::vault_cost()

Monitoring payments

I opened an issue a long time ago suggesting that the APIs should allow a limit to be set on the fee charged, and also that operations should report the fee charged on completion.

I don’t think the issue was responded to and the APIs don’t support this. I think a way to monitor actual cost and protect a wallet would be useful, especially now that doing this by drip feeding a wallet is expensive (whereas with native token it was to be free).

2

wasn’t that u64 at some point?! (for scratchpad)

might look a bit like overkill right now … but it’s both one of the most basic data types where everything else builds up onto …?

In any case it looks a bit inconsistent

1 Like
3

@dirvine I’m seeing in the latest merge requests that counters are still of type u32 for pointer and u64 for scratchpad; imho u64 would be the choice where it’s really hard to imagine we can run into issues … but in any case I’d assume we would want those to be consistent … (or are there reasons to make scratchpad more future-proof than pointers (?) )

1 Like