rpc: unify all ledger sequence types to uint32 and stop stringyfying integers < 53-bits wide

[2opremio]

What

Closes #1081

Why

Consistent is good plus it's cleaner to not stringify fields we don't need to (since they can be treated by javascript).

Known limitations

Downstream tickets are needed.

[leighmcculloch]

javascript doesn't handle uints that large

JS handles numbers safely up to Number.MAX_SAFE_INTEGER, that is 9,007,199,254,740,991.

Uint32 max is 4,294,967,295.

So I think JS will handle uint32's fine. Anything over 53-bit is a problem though.

[2opremio]

uint32 should ne enough for all practical purposes (in fact I think the XDR uses uint32 at some places?).

However, also if I recall properly, Horizon uses int64 everywhere (which is why I think we started using int64 in soroban-rpc). @Shaptic @tamirms , do you know why that is?

[leighmcculloch]

in fact I think the XDR uses uint32 at some places?

This is correct. The XDR uses uint32 for ledger seq.

https://github.com/stellar/stellar-xdr/blob/6a620d160aab22609c982d54578ff6a63bfcdc01/Stellar-ledger.x#L82

https://github.com/search?q=repo:stellar/stellar-xdr%20ledgerSeq&type=code

I imagine it would be such a heavy lift to change from uint32 to uint64 in the XDR that for a future change like that updating Horizon and Soroban RPC's APIs in support of that would probably be a small job in comparison to everything else.

But I also think it's reasonable to have the RPC API use strings for all integers irrespective of their bit size. I just wanted to surface that 32bit and ledger seq would fit if it was preferred to be a number.

[leighmcculloch]

Horizon uses int64 everywhere

It appears Horizon uses 32-bit for ledger seq too:

• https://github.com/stellar/go/blob/69266de4154fdf4dd5e8f39ada37f642cb421ca1/protocols/horizon/main.go#L344C10-L348
• https://github.com/stellar/go/blob/69266de4154fdf4dd5e8f39ada37f642cb421ca1/protocols/horizon/main.go#L505

[Shaptic]

We may have conflated account sequence with ledger sequence: the former needs to be int64 (see Horizon) because it can be set to any value, while the latter is guaranteed to grow sequentially and is uint32 in the XDR as you guys have mentioned.

I don't think there's anything wrong with leaving it stringified, but it is not necessary because all languages can handle them being encoded as integers (while JS has issues with values over 53 bits, like Leigh said).

[Shaptic]

I will leave it up to you whether or not we want to keep them JSON-encoded as strings! I'm just glad we are consistent, now.

[2opremio]

It think it's cleaner to not stringify them but ... at this point it may cause too much turmoil.

@Shaptic you are dealing with downstream tickets nowadays, wdyt?

[Shaptic]

@2opremio imo it's all the same: we have to issue a downstream ticket no matter what for at least a single field, so we might as well fix them all while we're there, and the maintainers are all very responsive.

[2opremio]

Alright. Uint32 it is then!

[2opremio]

OK, I changed all ledger sequences types to uint32 and removed the stringification of any field with a width less that 53 bits.

I still need to fix the tests though.

[2opremio]

@Shaptic can you please create downstream tickets? I will update the documentation.

[Shaptic]

@2opremio draft is here, please double-check it! I will also cross-reference it with the doc updates once you make them.