Add idToMarket getter

[MerlinEgalite]

Fixes #208

[pakim249CAL]

I don't think the suggestion was to put this in the main contract. From what I understand, the suggestion is to put this in a periphery, and would be a good fit for the bulker contract.

[MathisGD]

The issue with putting it in the periphery is that nothing can enforce that it is stored at the market creation. That's why I'm proposing to add it here. In any case, the feasibility and gas improvement of such a thing must be tested first.

[pakim249CAL]

The issue with putting it in the periphery is that nothing can enforce that it is stored at the market creation. That's why I'm proposing to add it here. In any case, the feasibility and gas improvement of such a thing must be tested first.

I question whether there is even a need for it to be stored at market creation. If we assume that our hashing scheme is cryptographically secure (which I believe is a safe assumption), then any contract can verify and store this information without it being inside the core contract. Which I believe is exactly what is being suggested by @ncitron

[MerlinEgalite]

The issue with putting it in the periphery is that nothing can enforce that it is stored at the market creation. That's why I'm proposing to add it here. In any case, the feasibility and gas improvement of such a thing must be tested first.

I question whether there is even a need for it to be stored at market creation. If we assume that our hashing scheme is cryptographically secure (which I believe is a safe assumption), then any contract can verify and store this information without it being inside the core contract. Which I believe is exactly what is being suggested by @ncitron

Agree that he's suggesting to add an external contract, but that would require some management while here there's not management at all for a relatively small gas cost.

[pakim249CAL]

Though there is some management, the management would basically be permissionless. Anyone should be able to submit a market that hashes to the Id, and then the market can be cached inside storage.

If I understand correctly, the main contract cannot even use this storage variable at all. It is only useful for a periphery, and only on a rollup where calldata optimization is prioritized. Therefore I think it should be managed by a periphery.

[MerlinEgalite]

Though there is some management, the management would basically be permissionless. Anyone should be able to submit a market that hashes to the Id, and then the market can be cached inside storage.

If I understand correctly, the main contract cannot even use this storage variable at all. It is only useful for a periphery, and only on a rollup where calldata optimization is prioritized. Therefore I think it should be managed by a periphery.

Good point. I find it quite annoying though, because you lose some synchronicity. I mean you can't build a contract that assumes that the mapping is correct.

[pakim249CAL]

There is a cryptographic guarantee that the mapping is either correct, or that it is uninitialized though. It should not be possible to find two market structs that hash to the same Id. In the case that it is uninitialized, the getter can simply revert with an error that signals to the user that the slot must be initialized with a market struct.

[Rubilmax]

Some naming suggestions

[MerlinEgalite]

Note that for this PR we must compute what is the gas cost of passing market as input VS retrieving it onchain (through a bulker for instance) before interacting on blue on a L2.

[makcandrov]

As mentioned here, if we're adding this mapping I think we should also add a list of the ids of the created markets

[MathisGD]

LGTM