Add Secondary Market Functionality to Broker Pallet #94
Conversation
|
There are a couple of reasons why I believe this isn’t a good idea. One might argue that I might be biased because I am working on a project that, among other things, addresses the issues mentioned in this RFC. However, I will do my best to genuinely review this RFC. The following list outlines why I don’t consider implementing marketplace functionality into the broker pallet to be a good idea:
The rationale for implementing the described functionality on the Coretime chain is not really convincing to me. The primary argument is that this approach is simpler than implementing it on a separate parachain. However, given Polkadot’s multi-chain architecture, we should leverage its structure along with technologies like XCM to develop multi-chain protocols and applications. We should not hesitate to distribute functionality across multiple chains where it makes sense, which, in my honest opinion, is the case for Coretime marketplaces. |
The fact that agile coretime is tradable and accessible to those beyond simply builders is a necessary attribute to it being "agile." This is a benefit to the chain builder as much, if not more so, as it is to the non-builder. There will always be an inherent advantage to a builder who utilizes the coretime for securing and validating a chain over a trader who cannot do anything with it besides resell it. The fact that cores are NFTs make a secondary marketplace possible, and something that has been in the works for thinkers in blockspace since before agile coretime's introduction. (ctrl+f=secondary) The ideal solution is to make trading as seamless as possible, and the building for competitive secondary coretime markets as simple as possible. This helps the builder who wants to trade their excess coretime just as much as the non-building trader.
Front-running is out of the scope of this RFC as this RFC does not enable, nor protect users from, front-running. Front-running protections can be established in other ways if desired, such as steeper lead-in periods. It could be argued that front-running could be beneficial to the market health of polkadot which does not have any value-extracting mechansims, dissuading a large part of the greater crypto market from participating in Polkadot. At the end of the day, front-running is a result of high-demand for high-value transactions, and would be a good problem to have in the future and "solve" or sort out in a future RFC. If on-demand coretime is available, there is no halting of any parachain's operations.
I would argue that crowdloans were precisely "parachains relying on a set group of people for coretime procurement," and this has nothing to do with decentralization.
Again, if on-demand coretime is available, there is no halting of any parachain's operations.
A simple descending cost model makes sense and is trivial to implement, aside from being obvious.
Since we are not talking about adding functionality to the relay chain, I fully agree that we should leverage the parachain structure, and in this case we are by adding functionality to the coretime PARACHAIN. System parachains are parachains, and it's up to the community what they should provide. It is in the community's wishes to stop further fragmentation and adding useful functionality to system parachains in an unbiased way makes sense.
Yes, one might argue this and I definitely believe that you are biased because this RFC would render much of your work outside of your sole control. We believe that Polkadot needs to be easier to develop on for its continued growth, and adding functionality to system chains is the easiest way to encourage growth and reduce the amount of technological gatekeeping that tends to occur with parachains feeling threatened by functionality that helps everyone. We need to understand that Polkadot is changing with JAM on the distant horizon which threatens the entire parachain model, and continuing a conservative approach will cause a split between JAM and Polkadot that we cannot afford. We must continue to adapt in order to maintain relevance. That being said, we look forward to feedback on improvements to this RFC from stakeholders without clear conflicts of interest. |
|
To add onto what @phillux metioned, firstly I believe that emphasizing the efforts made towards other solutions (by both Lastic and RegionX) is unproductive if those solutions are less optimal than what this PR proposes. Building a separate parachain to handle this functionality is inefficient and impractical. The only financial gains would be from secondary Coretime sales. However, to establish and sustain this parachain, significant costs are involved:
Therefore, such a chain is financially unsustainable and would require Treasury funding, which is unfair to the community. Additionally, developing a new chain for this functionality would take several months, whereas adding three functions to the broker pallet can be done in a few days. Moreover, creating a chain solely for this functionality would centralize the secondary marketplace, potentially excluding certain actors from participation. This contradicts the principles of decentralization. Building extended functionality on another system chain also lacks economic sense. Addressing specific concerns:
In conclusion, integrating the secondary market functionality directly into the broker pallet is more efficient, cost-effective, and aligned with the principles of decentralization. This approach reduces overhead, speeds up implementation, and maintains flexibility for future enhancements. |
This would require the parachains to dynamically switch from bulk to on-demand coretime. Solving this appropriately wouldn’t be as easy as you described.
It is not. It is important to consider how projects will actually procure coretime. If the team behind the parachain handles the coretime procurement, the issue of front-running doesn’t exist.
It really isn’t. It is called a crowdloan for a reason. Anyone who supports the project can contribute by allocating some of their own tokens to help it procure coretime (i.e., win the slot auction). It isn't dependent on the parachain team to finance the coretime procurement; instead, it is community-driven.
Parachains won’t be removed with JAM. There will still be a ‘parachain service’.
There is a reason why I am developing a project in a particular way. I have considered adding this functionality to the Coretime chain as well, but I decided against proposing it because I believe it is not the right approach for the reasons I mentioned. |
|
@poppyseedDev Thanks for the writeup. However, I think most of this is off-topic for this RFC. We can discuss it elsewhere. To answer your main concerns in short: No, the treasury won't have to pay for the Coretime procurement and other costs associated with running the parachain. Also, DOT token holders will vote on the parachain's code upgrades. If you have further questions or concerns about the parachain, we can discuss them somewhere more appropriate. |
|
My two cents: First of all I do think that having secondary markets live right on the Coretime chain would make perfect sense and this is also why I would love to see smart contracts enabled on Coretime. Until we have that, indeed the next best solution would be to include them in the runtime directly, but first of all I don't think that should go into the broker pallet, for at least a couple of reasons:
What could work is that teams wanting to offer secondary markets provide additional audited and reviewed pallets that can be deployed on the Coretime chain. Those pallets should be named after the team maintaining them, e.g. region_x_coretime_market/lastic_coretime_market, ....These pallets could then also introduce their own token or fee system, so that the teams maintaining the market get the necessary funding. There are benefits and downsides to this approach. On the upside, you don't need to run your own parachain, which means less cost, less complexity and better efficiency. On the downside: Less flexibility, slower iteration: The runtime needs to be trusted, hence any changes you make will need to be approved by the fellowship. So I would say this is only viable if those pallets stay small and will not evolve much. And obviously as this is a significant maintenance burden on the fellowship, it is also up to the fellowship to decide whether this is an option at all. In any case this does not scale too well, so mid term we should have smart contracts. Also as there would be maintenance burden on the fellowship it is not clear how this would go together with a for-profit system. TL;DR, my opinion: Secondary markets on the coretime chain: Yes. In the broker pallet: No. Directly in the runtime: Maybe a reasonable intermediate solution until we have contracts. |
Another benefit is simply the precedent of parity using this model somewhere. It's a great model for many things in the ecosystem outside of the core functionality of polkadot. |
|
Thanks for the feedback. How should we proceed with this issue? Does it make sense to close this PR and instead propose adding smart contract pallets to the Coretime chain? This could allow us to implement the secondary marketplace functionality more flexibly in the future. In the mid-term, we could add some basic functionality as a specific extension pallet, which would serve as an intermediate solution. Or, do you think it still makes sense to keep this issue open and present it as is? Your guidance on the best path forward would be greatly appreciated. |
"Audited" often precludes smart contracts, maybe folks want that eventually, but afaik they're all in flux now anyways. I'd focus upon (a) messaging endpoints that addressed the initial replies concerns, albeit with some latency, and (b) some really basic secondary market functionality. Afaik, we do not need anything complex like auctions or real matching here, maybe sell above some price, and buy below some price, with the buy choosing the oldest matching sell, or even the bbuy containg a list of acceptable ones, but buys can fail if all below that price or on the list disappear first. If you need the list, then the list could be encoded as a merkle tree, so then the collator can shrink the tx to just the sell it picks. @jonasW3F might've optinions. |
|
I think an RFC (or a wish for change) proposing to add smart contracts to the coretime chain and let the fellowship/token holders decide, certainly makes sense. You should also be aware of this one, currently having huge support. It would make perfect sense to have a wish for change to also add pallet-contracts to the coretime chain, while we are at it. This will not happen until end of year though, if we want something faster, we would need to do Frontier, with the caveats in referendum 885. For adding a pallet as an intermediate solution: I think this can be proposed to the fellowship. For pursuing this one: I am skeptical it will find support. For the additional pallet solution: I don't know, could go both ways. Contracts, given how 885 is going so far, might be the safest bet, but probably also the one with the longest timeline. |
|
Afaik AssetHub lacks our locks, staking, slashing, and governance, which makes 885 make more sense. Afaik we've never interfaced smart contracts directly to those pallets before, so maybe 885 should look somewhat like messages anyways.
Why not some message interface for the broker pallet? It already has some transfer function, right? |
@burdges would you mind expanding on this? I have expanded on the proposal to include the possiblity of having this be an extension pallet that would live on the Coretime chain. |
|
We'll anyways have the broker pallent recieve some messages, so then a market functionality could live on multiple other paracahins, right? Assuming this, what advantages does having a market on the same chain bring? |
After extensive deliberation and discussion at Lastic, we have concluded that integrating a secondary marketplace feature directly into the broker pallet is the most efficient approach. Given the limited scope of this addition and the minimal security risks involved, incorporating this functionality into the broker pallet is both practical and effective.
An alternative method could involve creating a separate chain with XCM functionality to handle core transfers and listings. However, maintaining such a solution would introduce significant financial and development overhead. For a feature of this scale, adding three functions directly to the broker pallet is a simpler and more sustainable solution.