You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was thinking of exposing the whole Marketplace config through the API because it can communicate the properties of the network to the user - for example, how many slashes is needed to vacate the filled slot etc. For sure not everything will be really useful for everybody, but at the same time I don't think there is any "secret" here or something that could go wrong with exposing it. Also, the structure of the config will change only with breaking releases as that will require the contract's redeployment, so IMHO no problem from "stableness of API" POV.
But I noticed a pattern that the Marketplace contract's config is not really exposed but rather its specific properties are, which sort of prevents me to do this so I am wondering what is the reasoning for it and can we expose it in its fullness? @markspanbroek could you give me please some context here?
The text was updated successfully, but these errors were encountered:
Hey @AuHau, I think you're talking about the Market abstraction, right? My reasoning was that it should be the interface between the codex node and the on-chain marketplace. But with as little specifics about the solidity implementation as possible, to keep it from becoming tightly coupled with this implementation. This allows for more freedom to change and experiment with the marketplace implementation, and I think it also leads to better code because it makes the dependencies explicit. This is why I like to make explicit exactly what properties we use from the configuration, to make sure that every time we add a property we have to think whether we really want this on the interface or not.
I generally agree with this approach. But... The smart contract and its configuration define the network's behavior. Not everything in the config is relevant to the node (for example, the slashing configuration), but it is relevant to the node's user (eq. he might want to know when he will be slashed etc). So my question is, how do we go about these properties? Should those be part of the market's abstraction and add new properties even though the node does not utilize it? And then exposing all those through some "info" endpoint?
Looking at the configuration IMHO pretty much everything is relevant except maybe the zkeyHash property.
I was thinking of exposing the whole Marketplace config through the API because it can communicate the properties of the network to the user - for example, how many slashes is needed to vacate the filled slot etc. For sure not everything will be really useful for everybody, but at the same time I don't think there is any "secret" here or something that could go wrong with exposing it. Also, the structure of the config will change only with breaking releases as that will require the contract's redeployment, so IMHO no problem from "stableness of API" POV.
But I noticed a pattern that the Marketplace contract's
config
is not really exposed but rather its specific properties are, which sort of prevents me to do this so I am wondering what is the reasoning for it and can we expose it in its fullness? @markspanbroek could you give me please some context here?The text was updated successfully, but these errors were encountered: