Add gRPC transport/support for TronWeb (alongside HTTP/JSON-RPC)

[psavva]

TronWeb currently interacts with full nodes primarily over HTTP/JSON endpoints. I’d like to request first-class, optional gRPC support in TronWeb (e.g., a GrpcProvider / GrpcClient transport), so applications can choose gRPC when it’s a better fit.

The Benefits of gRPC:

1. Lower latency & better throughput

   • gRPC uses HTTP/2 with efficient binary serialization (Protobuf), which can reduce payload size and improve performance for high-frequency calls (block/event polling, account queries, contract calls).

2. Streaming support (real-time updates)

   • gRPC enables server-side streaming patterns that are awkward/inefficient over plain HTTP polling.
   • This is useful for near-real-time consumption of new blocks, events/logs, or transaction status updates.

3. More reliable connections vs repeated polling

   • Long-lived HTTP/2 connections can reduce overhead from repeated HTTPS requests, improving stability under load (especially for backend services).

4. Typed API contracts

   • Protobuf schemas provide strongly-typed request/response structures, improving correctness and developer experience (especially in TS projects), and helping prevent subtle “shape changed” bugs.

5. Better fit for backend/microservice environments

   • Many production stacks already use gRPC internally; having TronWeb support it natively would simplify integration and reduce custom glue code.

Proposed scope (suggestion)

• Add a transport abstraction so TronWeb can support multiple providers:
  • HttpProvider (existing)
  • GrpcProvider (new)
• Support key read/query operations first (e.g., get account, get block, get transaction, trigger constant contract).
• Support streaming APIs where available (blocks/events), with a TS interfaces (AsyncIterator / EventEmitter).

[Stan202310]

Thanks for the suggestion. We’ll take this into consideration.