HIP-1046 gRPC Web Proxy Endpoints

[SimiHunjan]

GRPC-WEB HIP - Frontend applications using the Hedera JavaScript SDK face challenges due to browser security sandbox rules, which block mixed content (i.e., HTTP requests from HTTPS pages) and do not permit direct gRPC requests. Browsers also require TLS endpoints to be signed by trusted certificate authorities, necessitating fully qualified domain names (FQDNs).

Currently, gRPC-Web servers work around these limitations, but the endpoints are not supported in the Hedera Address Book. To circumvent this, gRPC-Web endpoints are hard-coded in the JavaScript SDK, which is neither scalable nor efficient. This approach requires manual updates and coordination, which will become increasingly problematic as Hedera decentralizes and more independent nodes operate.

To address this issue, we propose enhancing the Hedera address book to include gRPC-Web endpoint information, allowing the JavaScript SDK to dynamically determine the appropriate endpoints

[steven-sheehy]

We should consider an alternative design for how to populate web proxy endpoints. The current design suggests the grpc_proxy_endpoint field added to node create and update:

repeated proto.ServiceEndpoint service_endpoint = 4;
...
proto.ServiceEndpoint grpc_proxy_endpoint = 8;

There's a few problems with this new field:

1. It's not repeated. In the future we might find the need to support multiple web proxies per node.
2. Logically a web proxy endpoint is still a "service endpoint". That is, they both process HAPI requests and not gossip requests.
3. The service_endpoint field already contains multiple types of endpoints with different connection behavior: secure and insecure. These two require entirely different protocols to communicate, much like web proxies.
4. This change is not reflected in the NodeAddress for 0.0.101 and 0.0.102. We might want this to go out before dynamic address book or even if on or after to support both simultaneously for a period.
5. It requires more changes to downstream systems. Mirror nodes have to create and populate an extra table and update multiple APIs to add a new list structure. SDKs have to update to look at multiple places in the API response depending upon whether they want web or regular proxies. If they want both proxies, they have to merge the lists.

Therefore, I suggest we not add a specific grpc_proxy_endpoint field and instead add the web proxy endpoints to the current repeated proto.ServiceEndpoint service_endpoint field. To discriminate against different types of service endpoints, we should not rely purely upon the port value. Relying upon the port will cause issues when we go permission-less since node operators might not use the standardized ports for various reasons. Instead, we should add a new ServiceEndpointType enum to the ServiceEndpoint message. The exact enum value names can be debated.

enum ServiceEndpointType {
    GOSSIP = 0;
    SERVICE_SECURE = 1;
    SERVICE_INSECURE = 2;
    WEB_PROXY = 3;
}

message ServiceEndpoint {
    ...
    ServiceEndpointType type = 4;
}

[jsync-swirlds]

We did consider this approach.
At the time, the consensus was that platform and services made very strong assumptions about the content of the service_endpoint field (including what order endpoints are in), and changing that content requires a pretty wide-ranging change to the system.
The platform shift to using a roster instead of the AddressBook changes the calculus, however, and perhaps it would be reasonable to do this now, after the change to roster for platform, with related dynamic address book and/or TSS updates for services.

[jsync-swirlds]

Note, after an online discussion, we've presented an update to the HIP to incorporate this idea.

[rbair23]

Based on the current API, and in an effort to avoid any failure modes in the API, what if we do this:

// TLS might not be specific enough. Is it over GRPC? Or over HTTP? I don't know.
enum Protocol {
    PLAIN = 0;
    TLS = 1;
}

message ServiceEndpoint {
    ...
    Protocol protocol;
}

// Also update node update transaction body, state object, etc.
// For new DAB entities
message NodeCreateTransactionBody {
    ...
    repeated proto.ServiceEndpoint web_grpc_endpoint = 9;
}

// For file 101 until we no longer use it
message NodeAddress {
    ...
    repeated ServiceEndpoint webGrpcEndpoint = 11;
}