On-demand credits

[Szegoo]

Implementation of on-demand credits as described in RFC-1

[eskimor]

Looks good on a first pass. I was thinking about whether we need an ED here and I think the answer is no, because the credits are non-refundable, hence you have an implicit ED based on the minimum amount an on-demand core costs. This is less than the current ED on the relay chain, but it is also not a deposit, but actual spending.

[eskimor]

I think we might need adjustments to revenue tracking. Coretime bought with credits don't need a teleport, while coretime bought with balances does. We should also deprecate orders based on balances, to give people a heads up before later removal.

[Szegoo]

Ok, so we want to make place_order_allow_death and place_order_keep_alive deprecated so we can remove them later. This makes sense.

Just to confirm that I interpreted the first part of your comment correctly:

When using credits, the DOT used to purchase them is already on the Coretime chain. However, when using rc balance to make an order, the relay chain must transfer this revenue to the Coretime chain. So, if I understand correctly, you are saying that we need to adjust revenue tracking to account for this teleport when using rc balance?

[eskimor]

Precisely!

[Szegoo]

Given that the RC doesn't pay for notifying revenue, is there anything we should account for? UnpaidExecution

[eskimor]

I don't think so. What are you thinking about?

[Szegoo]

I was thinking about whether we need an ED here and I think the answer is no, because the credits are non-refundable, hence you have an implicit ED based on the minimum amount an on-demand core costs. This is less than the current ED on the relay chain, but it is also not a deposit, but actual spending.

I also thought of it, but I don't think it would be needed.

[ordian]

The implementation looks good, thank you!

I'd love to see an e2e test though, perhaps by modifying an existing zombinet-sdk test that does the purchase the old way to add a new way too.

[Szegoo]

I'd love to see an e2e test though, perhaps by modifying an existing zombinet-sdk test that does the purchase the old way to add a new way too.

Good idea, I'll add an e2e test.

[seadanda]

Looks good, thanks for taking care of this!

[Szegoo]

I'd love to see an e2e test though, perhaps by modifying an existing zombinet-sdk test that does the purchase the old way to add a new way too.

I am attempting to run the existing E2E test before modifying it; however, I am running into an issue. I am running it as follows:

cargo test -p polkadot-zombienet-sdk-tests --features zombie-metadata -- smoke::coretime_revenue::coretime_revenue_test

The error I am getting:

---- smoke::coretime_revenue::coretime_revenue_test stdout ----
Error: Metadata error: The generated code is not compatible with the node

Caused by:
    The generated code is not compatible with the node

Not sure if I need to set something up before running the test.

[ordian]

@Szegoo assuming you're running with ZOMBIE_PROVIDER=native, you might need to rebuild the polkadot/polkadot-parachain/polkadot-*-worker binaries from the latest commit that are exposed in your $PATH.