Seeking Community Insight on Coretime Price Simulation Model

Ecosystem
,
1

Hello Polkadot Community,

I’m Aurora Poppyseed, a magician (aka magikarp :fish:) at Lastic. I’ve developed a Python-based pricing simulation to decipher and emulate the pricing dynamics of Coretime. This tool is crafted to reflect the pricing functions within the Broker pallet, drawing upon:

Our goal was to create a tool that allows both ourselves and the community to interactively view and explore how different parameters impact core pricing.

The result of this effort is an application that provides our best attempts to closely mirror the actual code’s behavior and offers a hands-on experience for those who wish to delve into the pricing mechanisms. You can simulate different scenarios, modify parameters, and observe the outcomes in real-time.

However, I must admit that there’s a good chance I’ve overlooked something or made a mistake somewhere in the process. This admission isn’t just out of an abundance of caution; it stems from my discovery of what could potentially be a significant vulnerability. As it stands, the slow exponential increase in renewal prices, coupled with the proposed price cap, seems to allow for a scenario where, hypothetically, someone could substantially disrupt the Polkadot network with a rather low incremental cost increase—a factor that could be exploited in what I’ve termed a “50k attack.”

The conditions which would lead to such an attack are the following:

  • buy up all the cores
  • keep on renewing them indefinitely
  • the price will rise in a 1 year horizon only to 2 x Starting Price

Set parameters:

  • config values:
    • ideal_bulk_proportion: 60%
    • ideal_bulk_proportion: 7 days
    • interlude_length: 7 days
    • leadin_length: 28 days
    • limit_cores_offered: 50
    • region_length: 112
    • renewal_bump: 5% - proposed is even lower 2%
  • Start price of the Core you Bought (this is the starting price for which you bought the core in the previous sale - impacts the renewal price you are going to pay): 1000
  • Starting Price (Represents the starting price of the Coretime): 1000
  • Observe Blocks (represents block time each block of time the set parameter is only 4 block times per day - you can change this in code, it allows you): 1344 - with the parameter set at an example 1344 number we are looking at a one year time horizon
  • Cores renewed in each sale: 50 - this number
  • Cores sold in each sale: 0 - this number is capped depending on LIMIT_CORES - CORES_RENEWED_IN_EACH_SALE (in the picture you can see a 2 being there this should be a 0 there that’s probably one of the mistakes that need to be fixed - ignore that)

Screenshot 2023-11-06 at 18.47.20
Screenshot 2023-11-06 at 18.47.201750×2516 217 KB

This matter is something I’m eager to resolve and thoroughly understand. Therefore, I am reaching out to invite the community to provide their insights, scrutinize our Python implementation, and engage in a robust discussion about whether this is indeed an accurate representation of the intended pricing model—and, critically, the potential vulnerabilities therein.

Your expertise and perspective are invaluable, and I would greatly appreciate any input you can offer. Please find the application to play around with, along with our code, at the links below:

I’m looking forward to your feedback and thank you in advance for your time and contributions to this important discussion.

Best regards,
Aurora Poppyseed

10 Likes
2

Indeed. This sounds realistic! We had similar considerations in pricing for on-demand.

I guess we need to factor in demand for non split-up leases. If there is high demand for renewals, we need to adjust the price more aggressively.

In other words, it should be fine for 5 parachains to renew cheaply. It is still ok (but already more expensive for 10). It is getting real expensive at 40. Might even be a good idea in the non-malicious case. Forcing teams to reconsider, whether they really need a full lease for their application, resulting in better block space utilization when we need it. (High demand.)

This obviously contradicts the goal of price stability for parachains, but that’s probably hard to achieve fully, while still maintaining a robust system. A solution to this problem that comes to mind, is that parachains somehow have to prove their usefulness to get cheap renewals even in situations of high demand. But this is also likely a problem that can be solved later. If we have measures in place, that attacks are non-feasible, we should be fine demand wise for quite a time, considering core-sharing and on-demand/instantaneous.

1 Like
3

There are some things @Poppyseed and I have learned from playing around with this model that should be highlighted and maybe addressed. But there need to be some assumptions about the way cores will be sold.

Let’s assume:

  • Prices for cores will be set very low initially, e.g. $1000 USD
  • 51 Parachains are already taking up 51 Cores, and are likely to be renewed for the foreseeable future with a slow decline of “renewable cores”
  • About 10 new cores will be sold per month

If these assumptions are even relatively close to what will be the case, then there are some games that are relatively cheap to play, such as:

  • The ability for a dolphin (not even a whale) to buy up all available cores every month for a relatively cheap amount. Once they’ve done this, they do so again the next month, and again, in order to push up the available core price (open market price). Later, they can cash in on their renewal price by offering cores on a secondary marketplace only slightly cheaper than the open market price, yet much more expensive than the total cost. This isn’t necessarily an undesirable outcome, but it is something we should note. Even if this actor does NOT acquire all cores, simply making sure all available cores are sold every month is enough to incentivize this course of action.

Again, this is based on the assumptions listed above which I believe currently isn’t far from what’s expected to be deployed as of now on Kusama and Polkadot.

On another note, if anyone has suggestions or questions about the meanings of the parameters, just ask here!

1 Like
4

Hey guys,

thanks for making this application and providing a way to play around with parameters! The slow adjustment of the renewal price to market forces was also one of my concerns. I expressed those a while ago here. In this adjustment, I propose some adjustments that would enable renewal prices to scale more quickly with high demand, making this grieving attack much more expensive.

I’d be interested to get your perspective on these proposed changes.

Cheers
Jonas

1 Like
5

Hei Jonas, I have skimmed through your proposal. I thinks it’s a really great effort and I think it is nice because it resolves some things, however I am afraid that it deviates (adds) too much to the initial proposal and the code that is already written. Maybe it makes sense for now implementing only certain things that are proposed.

Or maybe it would make more sense to tweak certain parameters or change some functions that are already there in order to prevent the above mentioned from happening.

6

We just added a massive update to the Lastic Simulator!

Use the app at https://lastic.streamlit.app/ and read our blog for more information on what the parameters mean.

1 Like