feat: HubService.GetInfo to report contract addresses

[vrypan]

What is the feature you would like to implement? I would like HubService.GetInfo to report the contract addresses used: IdRegistry, KeyRegistry, StorageRegistry, Bundler and SignedKeyRequestValidator

Why is this feature important?

1. It will allow any client to discover these addresses and not rely on hardcoded settings.
2. It will make any migration to new smart contracts easier
3. It can provide an additional sanity check between hubs.

Will the protocol spec need to be updated?? Yes. Depending on how this feature will be implemented, 3.2.3 RPC Endpoints will have to be updated.

How should this feature be built? (optional) I suggest a new endpoint HubService.GetOnChainEndpoints is implemented to avoid breaking backwords compatibility.

rpc GetOnChainEndpoints(Empty) returns (OnChainEndpoints);

message OnChainEndpoints {
    bytes IdRegistry = 1;
    bytes KeyRegisty = 2;
    bytes StorageRegistry = 3;
    bytes Bundler = 4;
    bytes SignedKeyRequestValidator = 5;
}

[Bitcex]

Your proposal to implement the "HubService.GetOnChainEndpoints" endpoint to retrieve contract addresses dynamically is well-structured. Here is a detained explanation on how you can pull this:

DESCRIPTION OF NEW FEATURE UPDATE

Enhance "HubService.GetInfo" to include the retrieval of contract addresses for critical components such as "IdRegistry", "KeyRegistry", "StorageRegistry", "Bundler", and "SignedKeyRequestValidator". Introduce a new RPC endpoint, "HubService.GetOnChainEndpoints", specifically designed to return these addresses in a structured format. Its importance has already been stated abo

UPDATE PROTOCOL SPECIFICATION

• New Endpoint Definition: Introduce "HubService.GetOnChainEndpoints" as a new RPC endpoint. This ensures compatibility with existing implementations by segregating new functionality.

• Message Definition ("OnChainEndpoints"):

  rpc GetOnChainEndpoints(Empty) returns (OnChainEndpoints);
  
  message OnChainEndpoints {
     bytes IdRegistry = 1;
     bytes KeyRegistry = 2;
     bytes StorageRegistry = 3;
     bytes Bundler = 4;
     bytes SignedKeyRequestValidator = 5;
  }

  • Explanation: The "OnChainEndpoints" message defines fields for each contract address. These fields ("IdRegistry", "KeyRegistry", etc.) will contain the actual contract addresses in bytes format.

Steps For Implementation

1. Backend Logic:

   • Implement the logic to fetch contract addresses for "IdRegistry", "KeyRegistry", "StorageRegistry", "Bundler", and "SignedKeyRequestValidator".
   • Ensure error handling is robust to manage cases where addresses cannot be retrieved or are invalid.

2. Integration Testing:

   • Test the "HubService.GetOnChainEndpoints" endpoint thoroughly to validate correct retrieval and formatting of contract addresses.
   • Verify interoperability with existing client implementations and hub configurations.

3. Documentation Update:

   • Update the protocol specification ("3.2.3 RPC Endpoints") to include details of the new "HubService.GetOnChainEndpoints" endpoint.
   • Provide clear guidance on how clients should integrate and utilize this new functionality.

4. Deployment and Rollout:

   • Deploy the updated hub service with the new endpoint implemented.
   • Communicate changes to stakeholders and clients, including any necessary SDK updates or client-side adjustments.

Other factors to consider for effective implementation

• Security Consciousness: Ensure sensitive contract addresses are securely handled and transmitted.
• Versioning: Provisions should be put in place for future enhancements or updates to "HubService.GetOnChainEndpoints" while maintaining backward compatibility.
• Client Adoption: Provide support and resources for clients migrating to or integrating with the updated hub service.

By following this structured approach, you can successfully implement the feature, and support easier maintenance and migration processes for contract addresses in the future.

[Rufusemmanuel]

Why haven’t this been treated. This needs to be treated urgently