Use jsonrpsee as the RPC server impl

[ljedrz]

While I still need to do some research around applying constraints outlined in https://github.com/AleoHQ/snarkOS/issues/1597, I can already provide some insight into how the jsonrpsee-powered implementation is going to look like. The decision to finally make the switch was motivated by the crate no longer warning about its instability and the required functionalities becoming too advanced for a hand-written implementation (which was always only intended to be temporary in the first place).

This PR closes https://github.com/AleoHQ/snarkOS/issues/754 and likely https://github.com/AleoHQ/snarkOS/issues/1597 as well, though that could also be applied as a follow-up.

[niklasad1]

Hey, you shouldn't enable serde-json/arbitrary-precision when using jsonrpsee, see paritytech/jsonrpsee#480.

You will likely run into weird errors for instance when the request id is a number.

[ljedrz]

Hey, you shouldn't enable serde-json/arbitrary-precision when using jsonrpsee, see paritytech/jsonrpsee#480.

You will likely run into weird errors for instance when the request id is a number.

I don't even know why we need that one, everything seems to compile just fine without it; @howardwu?

[ljedrz]

Ok, I now know where that feature might be used:

thread 'rpc::tests::test_get_block_template' panicked at 'called `Result::unwrap()` on an `Err` value: Error("u128 is not supported", line: 0, column: 0)', src/rpc/rpc_impl.rs:165:12

[ljedrz]

Ok, I think the PR is ready for reviews; for now:

• the temporary JSON-RPC server is replaced with jsonrpsee
• a basic, quite conservative limit of 10 concurrent requests is introduced, with each request just counting as 1
• the serde-json/arbitrary-precision feature is an open point; to remove it, we could just not serve cumulative_weight or send it as a hex-encoded String (I implemented the latter for now)

[ljedrz]

Some jobs seem to be failing for unrelated reasons:

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Could not connect to archive.ubuntu.com:80 (91.189.88.152), connection timed out Could not connect to archive.ubuntu.com:80 (91.189.88.142), connection timed out

[niklaslong]

Left some comments, looks good other than that u128 panic in the tests.

[ljedrz]

Left some comments, looks good other than that u128 panic in the tests.

I already proposed the hex-encoding solution in ProvableHQ@fb1ec16.

[niklaslong]

I already proposed the hex-encoding solution in fb1ec16

My bad, didn't update my local branch after your recent push 👍

[dvdplm]

Happy to see this happen, we (Parity) are fans of Aleo and would love to see you as users. Let us know if we can do anything to help. :)

[howardwu]

LGTM.

Due to the number of systems depending on the current format for cumulative_weight (as a u128 rather than a hex-string), I've included arbitrary-precision to prevent breakages. Note that existing systems already pass in the id as a string for RPC, so the numeric id shouldn't be an issue. (Our documentation also reflects a string id in its examples)

We should investigate a real solution to displaying a u128 without breakage of the id field, as the cumulative_weight is likely the most important value returned from getnodestate (it defines how heavy the canonical chain is, which is read by the explorer, miners, and mining pool operators)