Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose Marketplace's config on the API #1056

Open
AuHau opened this issue Jan 1, 2025 · 2 comments
Open

Expose Marketplace's config on the API #1056

AuHau opened this issue Jan 1, 2025 · 2 comments
Labels
API Marketplace See https://miro.com/app/board/uXjVNZ03E-c=/ for details

Comments

@AuHau
Copy link
Member

AuHau commented Jan 1, 2025

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?

@markspanbroek
Copy link
Member

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.

@AuHau AuHau added Marketplace See https://miro.com/app/board/uXjVNZ03E-c=/ for details API labels Jan 6, 2025
@AuHau
Copy link
Member Author

AuHau commented Jan 6, 2025

Then, I have a correct understanding.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Marketplace See https://miro.com/app/board/uXjVNZ03E-c=/ for details
Projects
None yet
Development

No branches or pull requests

2 participants