Proposal: Enable canisters to pay in ICP for external services

Developers
1

Objective

Enable canisters to pay in ICP for computing services outside the Internet Computer.

Background

After participating in the ICP.Lab Gaming & Metaverse, @ilbert and I realized that many developers in the IC ecosystem still rely on AWS - or similar services - for some parts of their dapps. This is due to the IC being not yet mature enough to serve all their needs. Current services outside of the IC include the HTTP Gateway and WebSocket Gateway - and any other networking protocol gateway like MQTT - game servers for multiplayer games and notification services.

We believe that the Internet Computer will eventually reach the point in which it can serve any developer’s needs. In the meantime, we are exploring whether developers would benefit from being able to pay for the off-chain services their dapps need using ICP instead of fiat. This would enable recipients of developer grants or SNS DAOs to pay for the Web2 services they depend upon.

With the following proposal we would like to start a discussion around alternative ways for developers to pay for the services that cannot yet be deployed on the IC and their dapps require.

Proposal

We are considering creating an orchestrator canister controlling non replicated compute instances which developers can use to run the service that they currently run on AWS. The canister is used to receive the ICP payments from developers who need a non replicated instance and takes care of creating the needed instance and running the code specified by the developer. These instances would not provide a replicated environment to run applications and therefore developers should consider them as centralized instances with a wrapper enabling the payment in ICP.

These instances would be servers provided by independent parties. To launch an instance, canisters would transfer ICPs to the orchestrator canister and specify some code to be run. The orchestrator canister would take care of launching the instance and running the code on it.

Conclusion

The goal is to provide an IC-like interface to run the parts of a developer’s dapp that currently cannot run on the IC. This way, developers could pay in ICP for the services they would otherwise pay with credit card and run them on sovereign hardware instead of AWS.

P.S. This is only a high level idea to start a discussion and understand the community’s feelings on this topic.

18 Likes
2

Anything that makes devx better is worth discussing, centralized or not. I’m definitely not in a position to talk about the detailed implementation, as I am not a developer. I am still not grasping why paying with ICP is much better than paying with a credit card.

3 Likes
3

After reading this post I still don’t understand if you suggest to create a wrapper for AWS(with payment in ICP) or some kind of non-replicated instance that would allow developers to run arbitrary code(say creating an UDP server which you cannot do on ICP)
If it’s a wrapper for AWS how would you define what aws service to run? There are tools like terraform for this already, configuration as a code.
There’s also a question of security - aws has an elaborate system of priviledges/authentication/etc
What would you do if someone abuses it and starts to run stuff that is against AWS ToS?

3 Likes
4

When the ICP price is cheap, paying with ICP may seem affordable for everyone, but when the ICP price increases, this will turn against developers. My idea is to ensure that developers can also be paid in the same way that node providers are receive payment. That is, depending on the SDR price, ICP payment is made. Payment must be made via ICP. This will have a positive impact on the ICP demand in the market, even

3 Likes
5

I agree, also left the ICP Lab with that idea.

Its a wrapper on AWS (or any other cloud / provider in a long term future).

The advantages are:

  • the orchestrater understands “controller” concept, and only run actions coming from a DAO for example.
  • the top ups being on ICP (or better yet, cycles) is a “native” and easy thing to do for other canisters. (A game can’t pay / verify an AWS Account)
  • the code of the orchestrator being public, and all the api requests having a public log, could allow for strong verification (like that the lamda shasum matches the repos shasum) of which code was run, when and it’s results. It’s not decentralized, but it’s publicly verifiable, which would be enough for many Web3 use cases / DAOs.

Nonetheless, it’s a hard work, very risky as mentioned and think we need to start small and focused. We had email/sms notifications service and don’t think it had much success.

One of the root problems comes with service discovery (that has been mentioned on other forum topics).

Hope some of this feedback helps. :pray:

4 Likes
6

Good point. If there were a way to directly pay for external services in ICP (without intermediaries being responsible for the exchange ICP → fiat), then dapps that depend on off-chain services would not require their developers to pay for those external services.

3 Likes
7

I didn’t want to suggest a specific implementation yet.

A wrapper for AWS would be fairly easy to do and test whether IC developers find it valuable but I think it misses the point. At the end, there would still need to be someone in charge of converting the ICPs paid by developers in order to pay the AWS bills.

Would be better to incentivize people to provide servers that others can use. Basically what the IC does, but these nodes would be in “subnets” of one and would be a separate network from the IC. Maybe this could be a good way to make something out of all the IC nodes that are currently not part of any subnet. Otherwise, we were thinking to use existing services for renting independent instances. Flux is an example of this but I just started looking into it so I don’t know if it’s actually a viable option.

7 Likes
8

I guess fees for using the instances would be adjusted depending on the ICP price so that the monthly costs would remain stable for developers but honestly I haven’t thought much about this yet.

Not sure what you mean

9

Yes, great summary but I think we can do more than a wrapper for AWS or other clouds.

I agree, that’s why maybe it would be worth doing a quick PoC with the AWS wrapper and see how it goes.

What do you mean? Developers of a dapp would also write the off-chain code and deploy it on these instances so I’m not sure why there is a need for a service discovery.

1 Like
10

Payments made to cloud servers are calculated based on SDR (IMF money). However, the payment is paid as ICP equivalent to the calculated SDR value. My suggestion is that developers should also pay their payments using the same method as ICP.
The reason I make this suggestion is because
Currently, node providers are paid using this method. Therefore, the aim is to standardize this payment method on the ICP platform by using the same method for all kinds of services purchased and sold.

4 Likes
11

Payments made to cloud servers are calculated based on SDR (IMF money). However, the payment is paid as ICP equivalent to the calculated SDR value. My suggestion is that developers should also pay their payments using the same method as ICP

1 Like
12

My last comment on Service discovery was “how will current and future IC Devs know that your AWS wrapper exists”?

Its an issue on usage, that has been an issue on the whole IC. There are some ongoing attempts to improve this, so we don’t need to go off topic :sweat_smile:

3 Likes
13

Yes but I guess the first question is “do developers need this service?”. If that’s not the case there is no need to worry about service discovery🤣. But I agree that discovery is in general a problem.

1 Like
14

Having the capability to pay for off-chain services via canisters is an interesting idea. This might be for external infrastructure or more generally any services/APIs integrated. Besides developers, there could well be quite some use cases for end users for this. I don’t know enough about payment providers to really assess how realistic this is and I guess this also expands the proposal. The external payments here would be for the sovereign hardware (which would thus accept to be paid in ICP)? Have you thought about broader payment integrations?

Looking at the market shares, integrating with traditional cloud infrastructure where needed could make a lot of sense if it simplifies developers’ work in building on two separate infrastructures otherwise and if it allows complementing the IC’s capabilities. The latter could also be useful to prioritize IC feature development (i.e. if certain off-chain capabilities are being used regularly, this could indicate that these should be prioritized on the IC roadmap) and bridge wait times until new IC features are rolled out. Having this integration might also be an on-ramp for developers who host their apps on traditional infrastructure currently. I think it’s a good idea to get this conversation going early and I’d be interested as well to learn which off-chain services/capabilities IC devs mainly use.

6 Likes
15

I was thinking that the payment would not go directly to the node provider. Instead the payments are sent to the orchestrator canister and this takes care of periodically rewarding the providers, similar to what the NNS does This enables the payment towards the orchestrator to be performed in ICP, cycles, … while the node providers could be rewarded in ICP, native token, …

Yes this would be the really first goal: an IC-like interface for traditional cloud infrastructures.

That’s what we are trying to figure out. In case anybody wants to share their experience they are welcome :slight_smile:

5 Likes
16

Ive been saying this for quite a while - but this is another time where we need a stablecoin on ICP. Not sure what ended up being the blocker on getting one, centralized or decentralized.

17

While the subject of payment is on the subject, I wrote down my idea that I have been thinking about for a long time. I guess it wasn’t understood. In the future, with the intensive use of the ICP protocol, service fees such as storage, commission fees and hosting fees will be brought to the agenda again with the intense fluctuations of the crypto market. These service fees should be calculated in SDR and paid in ICP. Such a method will also regulated the ICP price. It will act as a shield against excessive price drops.

4 Likes
18

I don’t know much about this. Could you explain how you would calculate the fees in SDR and how this would stabilize the price of ICP? Specially in this scenario in which we have to reward non-replicated instances and therefore we cannot do it simply based on what they declare as they might cheat.

19

Very important. And should:

1 - envision the usage of the IC oracle exchange rate (a official source) for fiat price calculation

2 - use IC as multichain payments option

3 - offer to users to pay for the services in ICP and others as fiat based value (similar to the cycles schema of IC).

3 Likes
20

Update:

1 Like