Figure out RPC client and TLS

[Mirko-von-Leipzig]

Our public testnet and devnet RPC endpoints now use https and therefore require clients with TLS support. In the tonic crate this means enabling one the tls related features, and the client automatically gains TLS support e.g. cargo add tonic --features tls-native-roots.

Some users are using the gRPC client from our rpc crate -- however this crate does not enable TLS because internally our infrastructure is still http only. This means users of this client need to additionally override tonic with the TLS features. This is obscure and the client errors aren't very helpful in pointing out the issue since its just a connection rejection.

RPC client

We have a few options to improve this. Firstly though we should decide what the public interface of the rpc crate should be. The primary goal of the crate is to provide the RPC component of the node -- and despite the name, this is not meant as the canonical RPC client. Its intended to be the node's RPC server component.

Our options here:

1. Remove the RPC client from the rpc crate. Users should generate their own client using rpc-proto.
2. (1) but also add the client generation to the rpc-proto crate.
3. Keep as is.

TLS features

If we go with (2) or (3) from above then we should also improve the TLS situation to make it easier to get right. Some options:

1. Only document the cargo add tonic .. trick.
2. Add proxy features and choose what the default should be to minimize surprises.

There are three tonic TLS features:

• tls: Enables the rustls based TLS options for the transport feature. Not enabled by default.
• tls-native-roots: Adds system trust roots to rustls-based gRPC clients using the rustls-native-certs crate. Not enabled by default.
• tls-webpki-roots: Add the standard trust roots from the webpki-roots crate to rustls-based gRPC clients. Not enabled

The latter two automatically configure TLS using the system or the mozilla certificate stores respectively. I'm unsure how these features combine, if at all. The former allows users to configure their own certificate (and is enabled as part of the other two as well).

[igamigo]

1. Remove the RPC client from the rpc crate. Users should generate their own client using rpc-proto.

A good alternative for replacing this may also be to use the client's RPC (enabled with the tonic feature) since it already is meant to be used against the network nodes. They can just use the RPC client and ignore other features.

[bobbinth]

1. Remove the RPC client from the rpc crate. Users should generate their own client using rpc-proto.

A good alternative for replacing this may also be to use the client's RPC (enabled with the tonic feature) since it already is meant to be used against the network nodes. They can just use the RPC client and ignore other features.

Agree that this could be a good solution especially since it already handles conversion of some of the auto-generated types into miden-base types. But we'd need to make sure we cover all of the endpoints available on the node's RPC component. For example, I don't believe we currently expose GetBlockByNumber endpoint from there.

Our options here:

1. Remove the RPC client from the rpc crate. Users should generate their own client using rpc-proto.
2. (1) but also add the client generation to the rpc-proto crate.
3. Keep as is.

I think we should definitely do (1) - unless it causes some issues, and if (2) is negligible amount of work, we could do this too.

[igamigo]

1. Remove the RPC client from the rpc crate. Users should generate their own client using rpc-proto.

A good alternative for replacing this may also be to use the client's RPC (enabled with the tonic feature) since it already is meant to be used against the network nodes. They can just use the RPC client and ignore other features.

Agree that this could be a good solution especially since it already handles conversion of some of the auto-generated types into miden-base types. But we'd need to make sure we cover all of the endpoints available on the node's RPC component. For example, I don't believe we currently expose GetBlockByNumber endpoint from there.

Should we implement this (and any missing endpoint) on the client regardless of the solution for this issue?

[bobbinth]

Should we implement this (and any missing endpoint) on the client regardless of the solution for this issue?

Yes! Let's do that!