Store a list of the markets created

[QGarchery]

This idea:

1. allows to have an onchain getter of the market struct from the id. Onchain integrators interacting with only one market would only need to store the id instead of all the parameters.
2. allows to list all markets that have been created. This is possible offchain no matter what (by looking at events), but this makes it even easier, and it is currently not possible onchain. I am unsure if this use case is really that useful.
3. does not cost gas to the main functions, only in the create market function, because this set would not be used otherwise.

One implementation could be to do something similar to Enumerable Maps of OZ, and write something like: marketMap.set(id, market)

[Rubilmax]

There are 3 typical onchain integrators I have in mind: liquidators, routers, MetaMorpho vaults.
In the case of liquidators & routers, I expect market data to be given offchain as calldata. In the case of MetaMorpho vaults, there is the possibility that market data is stored for dynamic read/write in the vault (it is mutable).

But it seems to me that expecting integrators to only store an id is unrealistic: it doesn't give them the ability to have specific behavior depending on the market parameters (collateral, asset, oracles, irm, lltv) without having to CALL Blue. As an integrator, I would be better off storing this data in my contract rather than calling Blue after having SLOAD the stored market id.

So I don't think there's a pragmatic usecase defending 1.

I don't think 2. has a pragmatic usecase either (cc @oumar-fall @julien-devatom @mlgarchery @ghivert).

So for now, I am against adding code for no pragmatic usecase.

[MerlinEgalite]

It could be useful for oracle to have a mapping id => parameters to retrieve the relevant parameters while just passing an id.

[oumar-fall]

Regarding 2. Having to fetch the markets list from a subgraph is quite a nightmare imo (any dependency to a subgraph isn't really likely imo). The main reason is that it disallows us to work on past blocks or to work on a fork which is quite mandatory for testing purposes.

Idk what the offchain team thinks

[QGarchery]

It could be useful for oracle to have a mapping id => parameters to retrieve the relevant parameters while just passing an id.

It's still possible to pass the whole market data though, so maybe it does not have a real use case

[MerlinEgalite]

It could be useful for oracle to have a mapping id => parameters to retrieve the relevant parameters while just passing an id.

It's still possible to pass the whole market data though, so maybe it does not have a real use case

Sure but it's clearly less optimized, maybe the oracle just needs a few variables to work

[MathisGD]

Some thoughts:

• this is generally how blockchain protocols behaves I think. You don't have a way to have the list of accounts from the chain, neither the list of tokens, the list of minted tokenIds in a erc-721 etc.
• there is no way to get onchain the list of Uniswap pools (on v1 v2 v3 v4)

so I don't think that we should add this

[QGarchery]

I agree with the points above, and also it does not seem that useful to have that list (point 2) because there could be a lot of unused markets randomly created since it is permissionless. We can close this, unless you want to have more feedback from the offchain team

[MerlinEgalite]

I'm ok to close this issue as well

[julien-devatom]

Regarding 2. Having to fetch the markets list from a subgraph is quite a nightmare imo (any dependency to a subgraph isn't really likely imo). The main reason is that it disallows us to work on past blocks or to work on a fork which is quite mandatory for testing purposes.

Idk what the offchain team thinks

Uniswap uses a subgraph to list all created pairs and they upload them to an ipns node (like here) So this is ok to me to use a subgraph (or any event fetcher, not so hard)