search

DIN-center / din-sc

1 stars 0 forks source link

Documenting On-Spec and non-spec services - the din_ namespace #14

Open twhay opened 7 months ago

twhay commented 7 months ago

Examples: There are no native endpoint for Token Balances - multiple providers do this and do their own implementation.

L1 and L2 fee structures (which goes upstream to the settlement). Roll-up passes the gas fees to the L2. No standardized spec, each data provider implements their own spec. Each Roll-up is different from the RPC spec. A DIN_endpoint namespace should only be for methods where there are multiple providers who can support the method as implemented.

It would need to have at least two providers in order to create it, including writing the watcher tests.

twhay commented 7 months ago

An example which would not fit would be the NFT floor price API. It would be difficult to get this to the DIN namespace due to it being proprietary. There would be verifiable services (standard methods and services) and non-verified services that would be accessible via DIN.

twhay commented 7 months ago

Paying a fee to help build the DIN namespace is a worthwhile fee that providers are willing to pay or received benefit for building the namespace, and some sort of benefit of participation in building the namespace.

twhay commented 7 months ago

debug_trace, _trace, and other really high computational methods. Indexed transactions hashes - only query for transactions in the default range (this might be an archive vs full node discussion).

twhay commented 7 months ago

RPC gas limits - running Eth Calls with gas limits is necessary. Well-bound and non well-bound methods need to be investigated, and included.

Need to see what these looks like in Polygon