Agree on final design spec of new remote functionality for "full node" wallets and block explorers

[idky137]

Several options have been discussed:

• A wrapper around the ReadStateService from Zebra, either hyper or a gRPC implementation. Offering a 1-2-1 correlation of functionality provided by the ReadStateService would provide a tidy way for "cli-wallets" to access chain data either locally or remotely but adds dev time duplicating functionality already offered by the lightwallet gRPC service.

• Extending The lightwallet gRPC service with functionality required by "cli-wallets" and block explorers to provide a single unified API would lead to a more concise and easier to maintain service but would require extra dev by consumers to implement both local and remote functionality. (This could be nullified by adding a set of public methods in Zaino-State with a 1-2-1 correlation with the extended wallet gRPC service.)

[idky137]

A possible gRPC implementation:

• Update the current lightwallet RPC protocol to include:
  • A subset of the current services to be defined in Agree on LightWallet gRPC Services to be Deprecated. #70 and Agree on transparent tx service for wallets #71.
  • A new set of services to be defined in Enumerate the set of indices required by "full node" wallets and block explorers. #72.
  • A feature gated get_custom_index RPC that exposes ReadStateService functionality to build custom indexes.
• Implement identical pub methods and gRPC services based on this new specification in Zaino-State and Zaino-Serve.

This would allow any wallets or block explorers to have a simple interface to fetch data both locally and remotely and allow for more complex indices to be built when running code privately. But would also stop public Zaino servers that will replace lightwalletd from exposing potentially dangerous functionality.

[arya2]

A simple wrapper for the ReadStateService seems best. Multiple encodings could be supported by tonic as long as there are From and Codec impls for them (though tonic doesn't yet support selecting a codec with the content-type header so it would need to use different endpoints or rust cfg flags).

[idky137]

Having thought more Ive come round to this idea of using a simple wrapper for the "RemoteReadStateService", as it should only ever be Zaino using this implementation.

There is the separate issue of the wallet / Block explorer RPCs that Zaino will be taking responsibility for serving. Currently Zcashd and Zebrad use JsonRPC for this. We at Zaino would prefer to implement all remote services using gRPC.

This will allow for much more efficient server build and will simplify implementing these services over TOR / NYM. We are not completely fixed on this but do strongly advocate for this approach.