Canister consensus = lots of duplicate calls?

Hi, I’m very new. Reading and trying to get my mind around everything, haven’t touched the code yet. A lot of my questions have been asked already, but one concept has me lost.

As I understand it, each canister will have a minimum of 7 to 151 (Edit: 7 to 28) duplicates for redundancy and consensus. Every message will operate on lots of canisters at once, and their memory pages all (or most) have to be identical by the end.


  1. Everything that a canister can call will need to be able to be very idempotent. Every update must be written as an upsert?
  2. As the architecture gets deeper and we have many canisters built on top of each other, does consensus occur for every call? Will one call to my canister, become 10, become 100 to a canister I use, become 1000 to a canister it uses? It has to be this way, right? Or else there wouldn’t be any security I’d think.
  3. For something like a logging service, is there an existing way to de-dupe multiple duplicate messages? I haven’t looked super closely at the interfaces, will the 1000 calls share a guid of some sort?
  4. Update calls don’t return values, or they do if you wait on the future promise, wouldn’t the IC say that the majority response of an update respond “No change” and one, ignored as an outlier, responded with “Inserted”?

Hey there!

Where this comes from?

So, normal canisters would be minimum 7 to 28. Or maybe much more, this is how many nodes. I haven’t found great details on the consensus and blockchain details anywhere.

Yeah, maybe 10x to 1000x that number

Here is the consensus paper with all the details.

And also I recommend you to see the Genesis Launch Event YT video (here is the part about consensus Talk | Inside the Internet Computer: Consensus (Manu Drijvers) - YouTube).

There’s also a more recent paper here which you might find useful:

1 Like

Thanks for the quick replies! Looks like I’ll be reading for a while! :slight_smile: