Din Registry Network/Provider Metadata requirements

[natefikru]

There are a number of metadata values that will need to be stored within the din registry to be able to run DIN. all values should have upsert and get capabilities associated with them

Data can mainly be broken down to be stored in 3 different cases.

• DIN Network Data (Accessed by a DIN admin)
• Individual Network Data (Accessed by a DIN admin)
• Provider Data (Accessed by a DIN admin and the Verified Provider)
• Provider Network Data (Accessed by a DIN admin and the Verified Provider)

Din Network Data

TBD

Individual Network Data

This metadata will describe configurable values that a network/service will have associated with it. Most of these values can be overwritten in the proxy by explicit static Caddyfile configuration.

• enabled: bool Determines whether or not the network is enabled within the din protocol

• proxy_alias: string This is the name of the network as it will be referenced from within a din proxy gateway. for example zksync-mainnet, mantle-sepolia, eth, holesky.

• healthcheck_method: string This is the method that the proxy will use for health checking a network provider's latest block number/heigh/count.

• healthcheck_interval: uint8 Default health check interval in seconds for determining how often a block number/height/count request is executed along with the other health check evaluation logic.

• block_lag_limit: uint8 Default value that allows a network provider to be behind the given network's latest block according to the proxy while being deemed healthy.

• request_attempt_count: uint8 Default value for the total number of request attempts that the proxy allows for a given request before deeming the request dead and returning a failed attempt error.

• max_request_payload_size_kb: uint16 Default value for the max number of kilobytes allowed in the request payload body for a given network.

Provider Data

This metadata describes values that are associated with a provider's identity within the din registry

• name: string (Already implemented) value that is the front facing name of the provider

• auth: string authentication type supported by this provider endpoint. "siwe" should be applied by default until we support other authentication protocols.

Provider Network Data

metadata associated with a Provider's implementation of a Network

• uri: string Provider URI for their accessible JSON-RPC endpoint

• enabled: bool Determines whether or not the provider network endpoint is enabled within the din protocol

[cds-amal]

Should hc_interval be health_check_interval?

[natefikru]

Should hc_interval be health_check_interval?

yeah that 100% viable, we can technically name these values anything.

[cds-amal]

Would the Gateway/proxy need CRUD operations on all of these?

[twhay]

For Individual Network Data, there are two additional fields needed. Currently, we are providing these two fields to our provider partners, so in a case where this information should be discoverable, it should be added to the Individual Network metadata for discoverability purposes.

1. block_gas_limit: The block gas limit as set by the network protocol.
2. max_gas_limit: The maximum gas that can be consumed by an eth_call. This number is the block_gas_limit multiplied an integer. For example, network_max_gas_limit = block_gas_limit * 10 should be the default. All providers will need to adhere to the max_gas_limit when configuring their nodes, as different max_gas_limits will result in some eth_call failing, depending on which provider the request is set to. See this thread for more information on how Infura handles the max_gas_limit.

[natefikru]

Would the Gateway/proxy need CRUD operations on all of these?

gateway only needs to be able to read this data.

[cds-amal]

For Individual Network Data, there are two additional fields needed. Currently, we are providing these two fields to our provider partners, so in a case where this information should be discoverable, it should be added to the Individual Network metadata for discoverability purposes.

1. block_gas_limit: The block gas limit as set by the network protocol.
2. max_gas_limit: The maximum gas that can be consumed by an eth_call. This number is the block_gas_limit multiplied an integer. For example, network_max_gas_limit = block_gas_limit * 10 should be the default. All providers will need to adhere to the max_gas_limit when configuring their nodes, as different max_gas_limits will result in some eth_call failing, depending on which provider the request is set to. See this thread for more information on how Infura handles the max_gas_limit.

@twhay , I think this belongs in a separate issue as its not related to the proxy/router, but instead configuration settings for various Node providers. It might be part of the tests to validate new Providers.