Do cannisters run like Lambda functions?


I was looking at Motoko and some of the example code bases. It all seems very functional in nature. After looking through the docs on canisters I see that they run the code and carry state. I was wondering if they run like Lambda functions (in say AWS): as in they only run and scale when something is interacting with them. vs an EC2 instance which is a server that is always running and does not automatically scale.

From the docs I am inferring that canisters are paid with cycles for the amount of requests, CPU, disk space those canisters are using in IC. Efficiency is gained by using resources where they are needed, rather than provisioning them all of the time for when they might be needed. Very much like a functional lambda server-less model.

If non-tech people ask: why is this cheaper than AWS? I think it would be easy to say “well they run like Lambda or Firebase the function inits and runs when it is interacted with, and you are only charged for that time”.

I found this A Closer Look at Software Canisters, an Evolution of Smart Contracts | by DFINITY | The Internet Computer Review | Medium but would like more of a deep dive on canisters running as processes.


  1. Be able to explain why IC is cheaper and more efficient than a traditional provider.
  2. Understand more about canister runtime within IC.

It does seem like AWS Lambda, but on the theoretical question of why IC is cheaper and more efficient, somehow I have the sense that the various nodes in the subnet are all running the same code and somehow have to agree on the outcome before anything can get written to the chain. Maybe I’ve misunderstood, but its hard to see how it could be fficient running the same thing multiple times as running it once like AWS Lambda does. Id be curious to hear from someone who knows on this question.

It’s impossible for IC to be more energy efficient than traditional cloud service provider. You guys have spot it.

For trustless property, some one need to re-execute the logic to verify. This alone implies, computational efficiency wise, IC is bound to be inferior.

Whether IC service will be economically cheaper, that is determined by the market.

Unlike eth, cycles are not paid out to dfinity node owners. Cylces are just burned. So the pricing is not directly related to computational cost. Cycle cost is determined through voting proposal in NNS.

Node owners are paid with freshly minted ICP. ICP price is backed by cycle consumption, but its pricing “by the market” will surely bare more surplus/speculative value than just that.

So, as long as node owners are happily paid enough ICP, they wouldn’t might to keep the cycle cost low, since that does not directly affect their income. They’d care more about how much ICP is minted to them, which is determined independently by other proposals in NNS.

This is why IC could theoretically be economically cheaper.

1 Like